FAC P/PM Senior Level Course(s) Optional Reading Material Selections from MC Press books For course use only, not for distribution. Preface Management Concepts is pleased to provide this selection of chapters from MC Press published books to participants in the FAC‐P/PM senior‐level courses (6891 through 6894) as optional reading material. Participants in these senior‐level courses all have a working knowledge of the federal acquisition environment. This optional material, whether read prior to or following class, offers participants the opportunity to refresh and expand their knowledge and skills. The syllabus for each of the FAC P/PM senior courses outlines both the required reading and the specific suggested optional reading. Participants should refer to their course syllabus for the optional reading that supplements the course they are taking. This selection includes a range of readings that participants may find useful in conjunction with particular topics covered in the senior‐level courses. Please click on the bookmark in the left column to view a full table of contents and link to each chapter. In Right‐Brain Project Management the reader is introduced to the author’s belief that “we need to breathe life into projects. Life animates —an individual, a team, a project, or a company. Giving life to a project involves making it more human.” Further, since program management is all about decisions, you’ll learn how “our ability to make a decision is ultimately based on emotion.” What are the tools you can use to make sure you are striking the right balance between the right and left brain, given your program’s complexity? You will gain insights into how to address the challenge of embracing the paradox “that contemporary, complex projects need to be approached with both the right and the left brain … that complex projects need both structure and improvisation.” Aucoin, B. Michael. Right‐Brain Project Management: A Complementary Approach. Vienna, VA: Management Concepts, 2007. Chapter 1: What’s Wrong with Project Management? Chapter 3: Two Brains Are Better than One Chapter 6: Tools of the Trade: Working with the Right Brain Chapter 8: Making the Complex Simple Chapter 18: The Hero in Us All: The Moral of the Story In Project Decisions: the Art and Science, the reader gains an understanding that “project decision analysis is a scalable and flexible process that is both practical and effective. And it is important to understand that decision analysis is not a process that creates an additional level of bureaucracy.” The authors make the point that “decisions analysis is a broader exercise than risk analysis.” The key concepts in these chapters will enhance your ability to improve your decision‐making. Virine, Lev, and Michael Trumper. Project Decisions: the Art and Science. Vienna, VA: Management Concepts, 2008. Chapter 1: Project Decision Analysis: What Is It? Chapter 2: “Gut Feel” vs. Decision Analysis: Introduction to the Psychology of Project Decision‐
Making Chapter 3: Understanding the Decision Analysis Process Chapter 4: What is Rational Choice? A Brief Introduction to Decision Theory Chapter 5: Creativity in Project Management Chapter 6: Group Judgment and Decisions Chapter 7: Are You Allowed to Make a Decision? Or the “Frustrated Developer’s Syndrome” Chapter 20: Adaptive Project Management Chapter 21: Did You Make the Right Choice? Reviewing Project Decisions Conclusion: Does Decision Analysis Provide a Solution? In Acquisition Management the reader will gain an appreciation for the history of the complex federal acquisition system. The author notes that “to be effective and efficient in the 21st century, the federal acquisition process must be structured to cope with increasing competition for scarce budget dollars.” These excerpts offer an understanding of the endless challenges senior‐level managers face every day. Engelbeck, R. Marshall. Acquisition Management. Vienna, VA: Management Concepts, 2002. Chapter 1: Reform of the Federal Acquisition System Chapter 2: Introduction to the Federal Acquisition Process Introduction to IT Project Management provides an overview of the overall project management process, with emphasis on information technology. The first three chapters provide an overview that is aligned with the Project Management Institute’s (PMI) A Guide to the Project Management Body of Knowledge (PMBOK® Guide), which many federal agencies use as the basis of their project processes. Chapters on the key topics of scope, risk, and overall execution are also included. Stackpole, Cynthia, and Frank Parth. Introduction to IT Project Management. Vienna, VA: Management Concepts, 2007. Chapter 1: Projects and Operations Chapter 2: Organizational Structure and the Strategic Role of Project Management Chapter 3: Project Processes, Phases, and Life Cycles Chapter 5: Initiating and Planning Project Scope Chapter 10: Project Risk Chapter 12: Project Execution In Integrated Cost and Schedule Control in Project Management, defining scope is a key element in integrating cost and schedule control processes. The first three chapters provide a quick review of fundamental topics. The following chapters focus on the key areas of schedule, schedule risk analysis, and overall performance measurement. Kuehn, Ursula. Integrated Cost and Schedule Control in Project Management second edition. Vienna, VA: Management Concepts, 2011. Chapter 1: Basic Concepts Chapter 2: The Integrated Process Chapter 3: Defining the Scope Chapter 7: Building a Network Schedule Chapter 9: Analyzing Schedule Risk Chapter 11: Establishing a Performance Measurement Baseline Chapter 13: Collecting Cost and Schedule Performance Metrics Chapter 14: Performing Earned Value Analysis We hope these optional readings will enhance your understanding of the topics covered in the senior‐level courses and broaden your appreciation for the complex challenges we face in the federal acquisition environment. n
n
n
n
n
Right-Brain
Project Management
A Complementary Approach
n B. Michael Aucoin
8230 Leesburg Pike, Suite 800
Vienna, VA 22182
(703) 790-9595
Fax: (703) 790-1371
www.managementconcepts.com
Copyright © 2007 by Management Concepts, Inc.
All rights reserved. No part of this book may be reproduced or utilized
in any form or by any means, electronic or mechanical, including
photocopying, recording, or by an information storage and retrieval
system, without permission in writing from the publisher, except for brief
quotations in review articles.
Printed in the United States of America
Library of Congress Cataloging-in-Publication Data
Aucoin, B. Michael.
Right-brain project management : a complementary approach /
B. Michael Aucoin.
p. cm.
ISBN 978-1-56726-206-3
1. Project management.. I. Title.
HD69.P75A93 2007
658.4’04—dc22
2007007901
10 9 8 7 6 5 4 3 2 1
C h a p t e r
1
n What’s
Wrong with
Project Management?
n
n
n
If you want to make God laugh, have a definite plan.
Anonymous
n
S
am, the project manager, had a “deer in the headlights”
look as she prepared to address the stakeholder meeting
and deliver more bad news.
Her project, like many of her peers’ projects, was late and over
budget. Finishing the project would likely require that some features be abandoned or deferred. Sam felt bad about how things had
gone astray and feared that the stakeholders would decide to terminate her project.
She began to speak. “Let us start with the status of the project
and then talk about where to go from here.”
In this book, we will do just that: we will talk about the status
of the project (and, by extension, project management) and where
to go from here.
For too many projects and too many project managers, Sam’s
story is familiar. As someone who provides training in project management, it is a story that I sadly hear all too often.
n But, First ... What’s Right with
Project Management
To begin talking about what is wrong with project management,
let us first say that a lot is right with project management.
Right-Brain Project Management
Every year, numerous projects are completed to the satisfaction
of stakeholders and team members. These projects often proceed
to conclusion without trauma; many other projects hit close to the
mark with relatively little trouble.
Some projects even surpass all expectations and accomplish the
truly remarkable. Such efforts deserve close study to discover the
source of their energy, and we will spotlight examples of these projects in this book.
Clearly, effective management of projects, while elusive, is
attainable.
There is much reason to celebrate these project management
successes. If one gives any deference to either Murphy’s Law (whatever can go wrong, will go wrong) or Newton’s Second Law of
Thermodynamics (the universe tends toward disorder), then any
effort that overcomes these laws to accomplish something of value
is a testament to human ingenuity, will, and industry.
n Unmet Expectations
Notwithstanding the project management successes, we all
know that lots of projects are train wrecks. Of course, in any statistical population of performances, there will be those that underperform the mean. Nevertheless, this situation should not be acceptable
to those who invest their time or money in troubled projects. While
we cannot realistically expect every project to be phenomenal, it is
reasonable to expect that every project will at least meet agreedupon goals.
The prevalence of troubled projects suggests to many that if project management cannot produce success more reliably, then something is wrong with project management. “It is no exaggeration to
claim that project management as a discipline is in crisis ....”1
Let us say simply that the overall impression of projects and
project management is that they are disappointing. There is typically a mismatch between what is expected of projects, project man-
C h a p t e r 1 . What’s Wrong with Project Management?
agers, and project management, and what they actually deliver. This
mismatch can be viewed from three perspectives:
• Expectations are unreasonable.
• Performance is not sufficient.
• Both expectations and performance are out of line.
Many who manage or execute projects in today’s Church of
Real World Projects will eagerly stand and shout “Amen” to the
proposition that expectations on projects are unreasonable. Project
teams are expected to work miracles with unproven technologies on
a blazingly fast schedule with the barest of resources, not to mention
with team members who have never met because they are scattered
around the globe.
This approach might work if a successful outcome were somehow guaranteed. However, with increasing expectations comes
increasing uncertainty that the outcome will meet those expectations. These expectations also reduce the likelihood that the project
will finish at all.
Depending on one’s perspective, a case can be made either way
about the reasonableness of expectations on projects. Although it
is appropriate to be realistic about what can be achieved, the topic
eventually leads to a dead end for a simple reason: it is ultimately a
moot point.
It is certainly possible, and perhaps likely, that expectations are
unreasonable. It is also unlikely, however, that individuals with the
power to make decisions will lower their expectations.
Humans have an innate and endearing preoccupation with
greener grass. Someone, possibly the folks in the marketing department, will salivate over the opportunity to promise something
faster, better, or cheaper—or better yet, all three. Project sponsors,
customers, and upper management are typically willing partners in
the quest for the impossible or merely unlikely.
If there is little that can be done to push back on expectations,
project managers and teams have two options.
Right-Brain Project Management
The first option is to say no. Perhaps a widespread project
worker strike would convince those with unrealistic expectations to
back off, but such a strike is not likely to happen. Individual project
workers may say enough!—but it will likely be to the detriment of
their careers. Faced with such negative consequences, the second
choice, and the one taken by the vast majority of people, is to grit
your teeth and soldier on.
n Mediocre Performance
While it may be tempting to assign all the blame for substandard project performance to excessive expectations, we must also
conclude that the way project management is practiced leaves something to be desired. Consider the following statistics.
In its 2004 survey of 10,640 projects, PriceWaterhouseCoopers
found that only 2.5 percent of companies achieve budget, scope, and
schedule targets on all projects.2
The 2004 Standish Group survey of information technology
(IT) projects indicated that only 34 percent of such projects succeed
while 15 percent fail completely and 51 percent are challenged with
budget overruns, late delivery, or reduced benefits.3 Nevertheless,
this performance is a considerable improvement over previous experience for the ten years that Standish has conducted the survey.
It is reasonable to conclude that mediocre performance has
come to be expected as the experience of project management in
organizations.
Perhaps there is an interaction between unrealistic expectations
and mediocre performance. I once had a supervisor who stated that
he took any project schedule estimates given by a subordinate and
automatically cut them in half. His rationale was that engineers and
software specialists were always purposely pessimistic in their estimates to avoid having to stretch their limits. I was glad we had that
little conversation, because from that time forward, I automatically
doubled or tripled any estimate I gave him.
C h a p t e r 1 . What’s Wrong with Project Management?
The consequences of project failures and disappointments are
significant. In a revealing analysis, Oak Associates applied the results
of the Standish survey to financial performance.4 The impact of typical survey performance as compared with completing all projects
successfully is an astonishing 58 percent reduction in sales and a 92
percent reduction in profit!
To restate, if performance on the failed and underperforming
projects were improved so that all projects performed as expected,
the gain in sales would be 136 percent and the improvement in profit
would be an unbelievable 1135 percent!
It is amazing that companies can stay in business with mediocre
project performance. It is also no wonder that organizations have a
sense of disappointment in project management.
As shocking as these numbers are, perhaps the greatest effect of
poor performance reaches beyond the business bottom line. When
projects fail to meet financial and performance targets, morale suffers collateral damage. The most common intangible impacts are staff
cynicism and negative cultural effects.5 Considerable stress is associated with projects that go poorly, and the effects can become additive.
These consequences have a profound impact on the company environment and a detrimental effect on subsequent project work.
Companies that experience project failures also report that their
relationships with customers suffer through decreased customer satisfaction or loss of competitive advantage.
n Rules ... and More Rules
What is being done about project performance?
The majority of suggestions and recommendations in the project
management community aimed at improving performance involve
implementing better standard project management processes. This
approach focuses on improving the maturity of project processes
used in planning and executing the project.
Right-Brain Project Management
Without a doubt, maturation of project processes is valuable and
worthwhile, and it has been proven to increase the effectiveness of
project performance. The downside of this approach is that it takes
time and effort to make these improvements. Consider a widely used
measure of maturity, the Capability Maturity Model developed by the
Software Engineering Institute at Carnegie Mellon University. Using
this measure, the median maturity level across industries is level two,6
with level five being the highest level. The survey that determined
this median concluded that there is “… a relatively low degree of
project management maturity across industries.”7 For an organization to improve by one level in the maturity progression requires “a
very concerted effort”8 and may take a year or more.
Insights abound about the problems and limitations of project
management as it is practiced in organizations today. Fundamentally, it may be helpful to think about rewriting the rules.
Before we consider rewriting the rules, however, it is useful
to take a look at some different perspectives on what is troubling
project management. Why do so many people perceive that project management is failing to meet the mark? Four observations can
shed some light.
n Where Are the “Jump Out of Bed”
Projects?
One of the primary reasons for high expectations on projects is
that “... projects are important vehicles for implementing corporate
strategy and effecting change.”9 While this explains the expectations, something else is at work here.
Observation 1: Most projects lack a compelling motivation.
Projects, and organizations, often fail to work on what is really
important.
If you ask project stakeholders for the justification for their
project, they will likely refer to customer requirements or financial
C h a p t e r 1 . What’s Wrong with Project Management?
benefits. There is nothing wrong with such reasons, and they are
absolutely necessary.
But, as the timeless song says, “Is that all there is?”
Would projects be more successful if teams felt that what they
were doing was critical to someone? Would teams be more motivated if they felt some strong emotional push to achieve the end
results?
The motivation we’re talking about here is not just the rational
“I know this is in my best interest” type of reasoning. The motivation we seek is the impetus to get out of bed in the morning and get
into the office because the project is that important.
It may come as a bit of a shock that organizations often do not
work on what is really important. This is not to trivialize the projects that are done and the products they produce. It is simply an
observation that project management, strategic management, and
portfolio management do an inadequate job of establishing a compelling reason for the projects selected.
What do we mean by a compelling reason for the project? This
justification is far more than the benefits to the customer and the
financial benefits to the organization. The key issues are: What is it
about a project that makes us eager to work on it? What will make
us want to drop everything to work on this project? What will provide a satisfying reward for everyone at the end of the project?
Projects are often executed distantly removed from the “soul”
of the organization (if the organization can be said to have a soul).
This is largely a result of the misperception that project management is simply a method for executing a company’s operations.10
If the overall company strategy can be considered the soul of
the company, project managers and their projects are often considered cogs in the machine, not prime movers. This perspective is
illustrated in the PriceWaterhouseCoopers survey: organizational
considerations caused 59 percent of project failures.11 If projects are
important, why do organizations fail to support them well?
Right-Brain Project Management
If we take as a predicate that a company’s values are embodied in its strategy, then any disconnect between strategy and project
execution is serious indeed.
n Make Sense ... and Make Success
Organizations do an inadequate job of establishing a common
understanding in project teams and stakeholders of where the project is going. In project management circles, this is frequently cited
as poor communication. Good communication and common understanding are critical to project success, and poor communication is
a pervasive problem.
While many reasons contribute to the difficulty encountered
in reaching a common understanding of project goals, it seems that
what is commonly called poor communication is better approached
as difficulty in making sense of the project.
Observation 2: Projects and organizations have a
hard time making sense of the project.
While communication processes and techniques are important,
in reality the difficulty in communication comes largely from two
sources. First, poor communication is really a symptom of the lack
of compelling motivation. Second, project stakeholders pay far too
little attention to the processes of communication on a project.
The distinction between communication and sense-making is
important and valuable. A focus on communication implies that
early in the project there exists a definite and reliable embodiment
of what everyone is working on, presumably what is described in the
customer requirements or specifications. While this may be true for
some projects, it is often a fallacious assumption.
In reality, many projects are commissioned with an evolving understanding of the end point. There is nothing intrinsically
wrong with this approach, but it becomes a huge problem if everyone involved doesn’t understand this reality. The project processes
C h a p t e r 1 . What’s Wrong with Project Management?
must be consciously designed and executed to accommodate this
evolving understanding.
Improvement in communication focuses on technique; sensemaking focuses on collectively developing and understanding the
end point. Conventional communication remedies are predominantly aimed one way: to enhance the team’s knowledge of the documented end point. This is the perspective illustrated in the famous
line by the prison “captain” in the movie Cool Hand Luke, “What
we’ve got here is a failure to communicate.”
Sense-making assumes that everyone on the team has a valuable perspective to bring to the table. It is this network of the team
in conjunction with the customer, sponsor, and stakeholders that
together identifies and then creates the solution.
Observation 3: Project teams struggle with complexity
and ambiguity, as well as with pressures to
resolve these issues quickly.
Contemporary projects are affected to a significant degree by
complex and ambiguous issues. Many projects attempt to incorporate unproven technologies. Other projects commit to specific
results with only a rudimentary definition of what is to be accomplished. Virtual teams are assembled with no history of experience
together. Overlaid on these complexities is usually a tight schedule
and a paucity of resources.
These issues of complexity, ambiguity, and time pressure greatly
exacerbate problems of making sense. It is no wonder that most
teams vacillate between two approaches: running hard and hoping
to figure it out, and being frozen by the incomprehension of it all.
Project managers are typically taught to take steps to lower
project risks. Accordingly, a common approach is to attempt to
eliminate complexity and ambiguity. However, this approach is not
compatible with the real world.
None of us is clairvoyant. Even the most thoughtful, enlightened
planning process will not eliminate the unknown or unforeseen. To
10
Right-Brain Project Management
believe that we can “control” the future through planning is folly.
We are better off accepting this reality and adapting accordingly.
If the environment at the start of a project is uncertain, the
appropriate approach is to accept—and adapt to—the complexity
and ambiguity. Adaptation requires agility. Unfortunately, however,
many processes in an organization work against agility.
To a large extent, conventional project management is the
application of rules (and to an increasing extent bureaucracy) with
the aim of establishing predictability. In many cases, this approach
is important and necessary, but it stifles the ability of teams to be
quick and creative.
Organizations generally do not fully take advantage of the creativity and agility of their teams. This creativity is essential to dealing with complexity, ambiguity, and time pressure. Clearly, project
teams need tools to access creative skills successfully and to use them
effectively for project success.
In conventional project management, much attention is directed
to the uncertainties and risks that are inherent to the product of
the project, and relatively little to the interpersonal uncertainties.
In many cases, little can be done up front about the former. But by
directly and deliberately addressing the interpersonal uncertainties,
the team develops the ability to greatly improve its handling of the
product uncertainties.
n Limitations of Standard Approaches
As with just about any human activity, improvements can be made
in project performance. The relevant question is, “Which methods
will provide the benefits we seek with a reasonable effort?”
Peruse a project management bookshelf and you will find all
sorts of prescriptions for improving management performance.
Numerous courses are available to improve various aspects of project performance. The options available are dizzying.
C h a p t e r 1 . What’s Wrong with Project Management?
The vast majority of these methods are founded on a common
theme: improvement in the execution of the rules that embody project management processes. This approach is entirely valid and beneficial, and it has been proven time and again to be helpful in project
performance.
Yet many in the project management community express the
sense that these methods don’t quite scratch the itch. What is
needed is not just another rule-based approach. What is needed is
an entirely new approach that does not discount, but instead takes
advantage of, all the benefits of existing rule-based project management methods.
n What Is Missing?
What is it that separates the wildly successful projects from
those that fail, or those that are merely mediocre? Is it mature project processes? Good documentation? A skillful and charismatic
project manager?
While these ingredients can be helpful, they still may not be
sufficient.
The fundamental problem with project management is what is
missing, and what is missing is life, what is missing is people.
We need to breathe life into projects. Life animates—an individual, a team, a project, or a company. Giving life to a project
involves making it more human.
life?
When was the last time you described a project as being full of
Most projects in organizations are approached robotically, based
solely on financial projections, specifications, and earned value.
These ingredients are absolutely necessary to satisfy the business
requirements of any project. But is that all there is? “When a Boeing
engineer talks about launching an exciting and revolutionary new
aircraft, she does not say, ‘I put my heart and soul into this project
because it would add 37 cents to our earnings per share.’”12
11
12
Right-Brain Project Management
These elements, of themselves, do not animate people, projects,
or organizations. Something else is needed.
Observation 4: Project management has enough domain tools.
What is needed now for project success are maturity,
social skills, and passion.
The significant issues on projects involve people. These issues
either give life to the project or drain life from it. “[T]echnical
project management tools and methods are so well developed and
widely used that it is time to turn the focus on developing leadership
skills.”13
Here is where this book comes in.
Where does life come from on a project? Where do we find the
tools for mastery of the complex project? The answer to these questions is the right brain.
The inherent objective of any project is to bring smiles to the
faces and pride to the hearts of all those associated with the project.
The key to achieving this objective is the right brain.
The right brain provides access to the compelling motivation
that projects need for success. We connect and communicate most
effectively with other team members and stakeholders through the
right brain, which is the way we tap creativity. The right brain has
an amazing capability to handle complex, ambiguous problems and
to make decisions quickly on incomplete, “intuitive” information
using its impressive processing power.
The right brain is the vehicle for making the transition from
existing rules that are limited in their effectiveness for contemporary
projects, to discovering and applying new approaches that are more
suited for the world as it is. In essence, the right brain holds the key
for moving from conventional project management approaches to a
more effective, complementary project management style.
Our abilities to work collaboratively with others depends to a
large extent on right-brain processing, not the least of which is how
13
C h a p t e r 1 . What’s Wrong with Project Management?
we process information and situations that have a moral component. The ability to act according to the welfare of others guides
effective teamwork and leadership, which are crucial to projects in
organizations.
But more than all this, the right brain is the door through which
we embark upon and fulfill the personal development needed to
overcome the formidable challenges of today’s projects. In short, the
right brain is uniquely equipped to tackle all the challenging issues
faced by contemporary project management.
Unfortunately, the right brain is commonly not understood,
and is therefore treated with skepticism; its capabilities are ignored
or avoided. The irony is that we all use the right side of our brains,
knowingly or not.
This is not to say that project management should rely entirely
on the right brain. Not only is that not possible, but it is not desirable: left-brain approaches are equally valuable and needed.
Those who integrate right- and left-brain approaches to project management will realize many benefits on an individual level;
research and experience demonstrate that an integrated approach
also offers valuable business benefits. To practice right-brain project
management, you won’t need extensive training. In fact, you learned
long ago how to put your right brain to work. n
n Endnotes
1Lauri Koskela and Gregory Howell, “The Underlying Theory of Project
Management Is Obsolete,” Project Management Institute, http://www.
pmi.org. Accessed May 2006.
2“Boosting Business Performance through Programme and Project
Management,” PriceWaterhouseCoopers, 2004, http://www.pwc.com.
Accessed June 2006.
3“Standish: Project Success Rates Improved Over 10 Years,” http://www.
softwaremag.com. Accessed June 2006.
4John M. Nevinson, “The Business Benefits of Better Projects,” Oak Associates, Inc., 2005, http://www.oakinc.com. Accessed October 2005.
14
Right-Brain Project Management
5“Global IT Project Management Survey,” KPMG, 2005, http://www.pmi
.org. Accessed June 2006.
6Kevin P. Grant and James S. Pennypacker, “Project Management Maturity:
An Assessment of Project Management Capabilities Among and Between
Selected Industries,” IEEE Transactions on Engineering Management,
Vol. 53, No. 1, February 2006, pp. 59–68.
7Ibid., p. 66.
8Ibid.
9Peter Morris and Ashley Jamieson, Translating Corporate Strategy into
Project Strategy (Newtown Square, PA: Project Management Institute,
2004), p. viii.
10 Ibid., p. 3.
11 “Boosting Business Performance through Programme and Project
Management,” PriceWaterhouseCoopers, 2004, http://www.pwc.com.
Accessed June 2006.
12 James C. Collins and Jerry I. Porras, “Building Your Company’s Vision,”
Harvard Business Review, September–October 1996, pp. 65–77.
13 Irja Hyvari, “Project Management Effectiveness in Project-Oriented Business Organizations,” International Journal of Project Management, Vol.
24, 2006, pp. 216–225.
C h a pt e r
3
n Two
Brains Are Better
than One
n
n
n
Perhaps it is good to have a beautiful mind, but an even
greater gift is to discover a beautiful heart.
J o h n Na s h
n
I
t is capable of recalling every state capital and can wrestle
with weighty questions of consciousness, “self,” and the
meaning of life. It can establish the theory of relativity, or
catch the nuance of a double entendre. It has invented the wheel
and used it reliably in a million different applications. It shows off
by spelling antidisestablishmentarianism—backwards—and is responsible for falling head over heels in love.
Welcome to the marvels of the human brain.
Between your ears is the most powerful force in the world, a
processing juggernaut whose capabilities are believed to be almost
limitless. The human brain is capable of so much more than any
engineered computer in large part because of its multifunctional
processing style and its capability to build exponentially upon what
has been learned before.
The study of the human brain, its functions, and its capabilities
is a relatively new and exciting field. A limited understanding of the
brain was developed several decades ago, but only in the last ten
years have we made extensive advances in our understanding of how
it operates. It seems fair to say that our understanding of the brain is
still very limited, and much more remains to be learned.
What we do know about the brain and how it processes information is relevant to the study of project management, particularly
our focus on the complex, contemporary project.
38
Right-Brain Project Management
n Structure and Operation of the Brain
The mind and its astounding capabilities result largely from the
incorporation of two complementary but significantly different processing styles. From an evolutionary standpoint, these capabilities
have benefited humans enormously. While this incorporation offers
the benefit of some redundancy, its primary purpose is to provide
two different approaches to thinking, or two ways of looking at the
world.
Having two processing styles is very valuable, if not necessary,
for the functioning, survival, and growth of humans. We need to
be able to follow rules and structure as well as to be able to adapt
to unusual situations. Our brains have made it possible for us to
explore new worlds and then to create permanent communities
in those worlds. These complementary capabilities have enabled
humanity to adapt to significantly varying environmental conditions
and to complex and unprecedented threats, as well as to evolve in
intellectual capability.
At the same time, humans have been able to capture and exploit
the knowledge gained in each endeavor into rules that can be reliably communicated to peers and descendants to preserve and expand
on knowledge. Indeed, this complementary architecture of thought
makes it possible for us to live so well under conditions that range
from pleasant California to the South Pole, to the sea floor, and to
the surface of the moon.
One of the key structural features within the brain is the extensive interconnectedness of its components. This web of about one
quadrillion connections enables very powerful parallel processing
of information in ways that far exceed the capabilities of the most
powerful computers.
The cerebral cortex is the structure that separates the human
brain from the brains of other creatures. The cerebral cortex contains two symmetrical hemispheres: the right side and the left side.
The left and right hemispheres are connected by a structure called
the corpus callosum. With an interconnection of approximately 300
C h a p t e r 3 . Two Brains are Better Than One
million nerve fibers, the corpus callosum enables the two sides of
the brain to share information readily.
Research performed several decades ago developed the understanding that the two hemispheres function in different ways with
significantly different programming styles. These two “brains”
came to be known as the left brain and the right brain. This early
research has been shown to be overly simplistic; the reality is a bit
more complicated.
Later research confirmed that the brain has these two different processing styles, but found that they do not necessarily reside
in separate hemispheres. Furthermore, the human brain has an
incredible capacity to renew itself and develop alternate pathways to
respond to injury. Functions previously resident in one area of the
brain can be learned elsewhere if the need arises.
This is not a textbook on neuroscience, so we won’t go further into the physiology of the brain. For our purposes, it does not
matter where the functions are physically performed, only that the
processing styles of “left brain” and “right brain” are incorporated
within the brain. We will use these terms to refer to styles or functions of thinking and processing information, rather than the physical parts of the brain.
n Early Research on Brain
Specialization
The breakthrough in brain specialization originated from
research conducted by Roger Sperry in the 1960s. For this work,
Sperry received the Nobel Prize in 1981.
Sperry studied individuals who had suffered disease or injury
that disabled part of the brain. In other cases, he studied individuals
who had been treated for epilepsy; the treatment for these individuals at the time was to sever the corpus callosum, effectively stopping
communication between the left and right sides of the cerebral cortex. Other, non-invasive studies were performed on healthy indi-
39
40
Right-Brain Project Management
viduals using approaches that served to access one side of the brain
at a time. His work led to fascinating findings.
Sperry discovered that when one removes or disables the right
brain, verbal language is unimpaired but becomes more computerlike. The subjects he studied could not understand metaphors,
inflections, and emotional tone. Individuals with no right-brain
function also exhibited a flat personality and had limitations related
to conceptual insights, imagination, and initiative. Simple spatial
tasks became confusing.
Patients who lost their left-brain function lost the ability to talk
but remained completely conscious and able to function in a nonverbal way. They were able to communicate with pictures, and they
retained their personality and emotional processing.
Based on Sperry’s research, we can summarize the functions
of the two brains. The left brain processes information in words,
it is responsible for speech, and it processes step-by-step logic in
sequence. The left brain seeks to apply rules in its actions.
The right brain is non-verbal, it is more visual and emotional,
and it attempts to create new patterns or to recognize patterns from
disguised or fragmented pieces of information. The left brain is
unable to process information in this way. The right brain also recognizes concepts that are not easily put into words and is comfortable
with metaphors. These functions are critical aspects of creativity.
The left and right brains operate and communicate in different
ways. The left brain processes the literal meaning of words. The
right brain processes inferred meaning, tone, inflection, and body
language. The left brain processes information for logical and factual content, while the right brain processes information for emotional and conceptual content.
3-1.
The processing styles of the two brains are summarized in Table
C h a p t e r 3 . Two Brains are Better Than One
n
Table 3-1. Left-Brain and Right-Brain Processing Styles
Left brain
Right brain
Verbal communication, uses words
Uses visual, spatial, tactile
communication
Relies on logicProcesses emotions, offers intuition
Prefers to execute known rules
Seeks new associations, creative
thought
Comfortable with disconnected
Operates sequentially
information
Prefers predictable behavior
Comfortable with some ambiguity
Executes patterns
Learns patterns
Prefers what is explicit, concretePrefers abstract concepts, metaphor
Operates with complete information
Operates with incomplete information
Unable to make decisions independently Critical to decision-making
n Getting Emotional over Decisions
Although it seems counterintuitive, patients who lose rightbrain function also lose the ability to make decisions. Shouldn’t the
ability to make decisions reside in the logical left brain? Don’t people make decisions by gathering information and then considering
the advantages and disadvantages of options?
Of course we analyze information in decision-making. Nonetheless, our ability to make a decision is ultimately based on emotion.
Decisions are made based on the relative positive and negative
emotions associated with the available options. These emotions
reside in memories associated with similar situations and outcomes
from the past. Suppose I have bad news about a project that should
be conveyed to my boss. What emotions did I feel the last time I
broke bad news to him? While I may know logically the importance
of being forthright, if my last experience was unpleasant, I may very
well keep the information to myself.
41
42
Right-Brain Project Management
Dr. Antonio Damasio is a professor of neuroscience at the University of Southern California, where he directs the Brain and Creativity Institute. As a researcher, Damasio has studied the role of
emotion in thinking. He shares the fascinating story of a patient
he studied, a successful attorney named Elliot who had radical surgery to remove a brain tumor.1 The surgery required that parts of
the brain be removed and connections be severed. These actions
affected the part of the brain that processes emotions. The attorney
recovered from surgery and returned to normal life with no loss in
his intelligence or ability to speak; upon first encounter, there was
no indication of any change in him.
When one spent more time with Elliot, however, it became
clear that something was not right. He showed no range in emotion and apparently could not experience or understand emotion.
Unfortunately, his relationships began to suffer and his marriage
ended in divorce.
What also became clear was that Elliot lost the ability to make
decisions; even the most trivial decision would stump him. He would
get stuck on the simple task of scheduling an appointment. Simple,
logical pros and cons meant nothing to him and offered him no help
whatsoever. He had no emotional memory or frame of reference to
feel the consequences of any decision.
As Robert Keith Leavitt is often quoted as saying, “People don’t
ask for facts in making up their minds. They would rather have one
good, soul-satisfying emotion than a dozen facts.”
The fact that decision-making is based on emotion has significant implications for individuals and groups working on projects.
Consider the troubled project—one that is far over budget and far
behind schedule, with no end in sight.
Very strong emotions are in play among the project actors in
such a situation. One stakeholder has such a personal commitment
that she would not even consider terminating the project. Another
team member feels so frustrated over the stalled progress that he
wishes management would put an end to the pain. The project
manager, seeking to avoid the shame of failure, says publicly that
C h a p t e r 3 . Two Brains are Better Than One
a breakthrough is near while knowing privately that this is wishful thinking. It is strong emotion—and avoidance of addressing
the emotion—that keeps many a troubled project going long after
everyone knows it is doomed.
Organizations have trouble acknowledging this charged emotional environment. It is far easier to reach a decision on the project
based on a logical analysis of the situation, and leave the individuals
to handle the emotional fallout. However, the participants would
experience far fewer traumas if the organization were to acknowledge and address the emotional aspects in a healthy manner, regardless of the decision made regarding the future of the project.
n The Moral Brain
To delve further into how emotions affect our decisions and to
consider the interplay with morality, let us go back to the year 1848
and meet Phineas Gage.
Gage was the foreman for construction of a railroad line near
Cavendish, Vermont. In preparing an explosive charge to excavate
rock, he packed the charge with a three-foot long tamping iron.
Tamping created a spark that ignited the gunpowder and propelled
the iron completely through his head. Remarkably, Gage regained
consciousness within a few minutes and could speak. Despite this
unfortunate accident and serious injury, Gage soon recovered and
within a year returned to work. While his basic mental faculties
remained intact, his personality had changed dramatically. Before
the accident, Gage was considered an excellent foreman. After the
accident, he showed little concern for others and was profane in the
extreme. As described by friends and acquaintances, he was “no longer
Gage.” He lost his job and was eventually featured in a circus act.
The classic case of Phineas Gage provided the first insights into
what makes humans social or antisocial, or what we have come to
describe as moral intelligence. Our understanding of moral intelligence is evolving, but it has been enhanced significantly by intriguing findings in recent years from studies of the brain using functional
43
44
Right-Brain Project Management
magnetic resonance imaging (fMRI). Using fMRI, researchers can
observe which parts of the brain are active when a person is subjected to a stimulus or situation that has a moral component.
For the fMRI tests, normal adults viewed images of emotionally charged scenes with and without moral content. While certain
regions of the brain were active for both types of images, certain distinct areas fired only in response to the images with moral content.
Of even greater interest, the activation of these regions occurred
very quickly; it was an automatic response. When the same experiment was conducted with a group of individuals with diagnosed
antisocial disorders, their moral circuitry did not activate reliably.
These fMRI studies have led to the growing understanding that
“everyday” morality is essentially an instinctual, gut response.
While humans also reason according to moral values, such as
when trying to solve a dilemma, this processing is slower and is performed elsewhere in the brain. With such decision-making, rational
and emotional elements of the brain work together in an integrated
fashion.2
These findings lead us to the key issue of morality. It is one
thing to articulate values of right and wrong, but it is another thing
altogether to actually do the right thing. Anthropological studies
have shown that values of morality and interpersonal behavior are
surprisingly common across human societies and cultures. “Most
of us know right from wrong …. The essential challenge of moral
intelligence is not knowing right from wrong but doing versus
knowing.”3
How do we as individuals or organizations “walk the walk”?
One way is to make moral decisions personal.
Researchers often use hypothetical moral dilemmas to understand human moral reasoning. These studies lead to the curious result
that morality changes dramatically depending on our degree of closeness to others. We tend to be subjective in moral decisions involving
people we know and objective with people we do not know.
C h a p t e r 3 . Two Brains are Better Than One
A classic situation is the trolley dilemma. A runaway trolley is
headed for five people who will be killed if no one intervenes. The
only way to save them is to throw a switch that will guide the trolley
to another track—where it will kill one person instead of five. The
dilemma is posed to the subject of the study: kill one person or five?
Most people say they would minimize the effects of the tragedy by
throwing the switch.
Now the dilemma is changed ever so slightly. Again the trolley
is headed for five people, but this time, the observer stands overhead
on a footbridge with a bystander, a stranger, who is a larger person.
The trolley can be stopped only by pushing the stranger to the track
below in front of the trolley, but the stranger will die in the process.
Again the dilemma is: kill one person or five?
While the moral mathematics remain the same, in this situation
most people would not push the stranger to the track below, and
instead would allow the five to be killed. What has changed?
In the first case, the action taken by the observer is impersonal.
While human consequences will result, the action is taken on a
mechanism. In the second case, the action is personal: the observer
must force someone close at hand to their death. While strong emotions are involved in both dilemmas, the emotions are different and
lead to different moral decisions.
This model has been confirmed by fMRI studies. Similar activity was observed in the brain for moral/impersonal decisions and
non-moral decisions, while moral/personal decisions involved a
unique area of the brain. In short, the brain demonstrates a highly
regimented distinction between moral decisions that are “personal”
and those that are “impersonal.” We exhibit greater concern for the
welfare of those who are close compared with those who are not
close, and we are reluctant to cause direct harm to others.4,5
These findings suggest that we have brain networks that are
specialized for the generation of moral emotions, and these networks are different from those involved in basic emotions. “Moral
emotions differ from basic emotions in that they are intrinsically
interpersonal.”6
45
46
Right-Brain Project Management
In their book, Moral Intelligence, Doug Lennick and Fred Kiel
suggest the following four elements of moral intelligence, which are
universal across cultures:7
•
•
•
•
Integrity
Responsibility
Compassion
Forgiveness.
While emotional intelligence and moral intelligence overlap
considerably, there are important differences. Emotions are neutral
with respect to values, while moral intelligence embodies beneficial
human values. “Emotional skills can be used for good or evil. Moral
skills, by definition, are directed toward doing good …. Without a
moral anchor, leaders can be charismatic and influential in a profoundly destructive way.”8
Morality is a significant element of trust. For contemporary
projects to be successful, teams need a high level of trust. Team
members must be able to access and invoke personal, moral emotions, and to use moral skills to make good decisions. While we are
on the job, our neurons are firing with emotions and moral reactions. When we make a direct connection with other individuals
on our project team, with stakeholders, and with customers, we are
more likely to consider their needs and make project decisions that
are beneficial to them.
n Right Brain/Left Brain Partnership
If the human brain is the most powerful computer in the world,
the architecture of the brain can be considered to consist of two
coprocessors. For the most part, these coprocessors see the same
input data, but they use different programming languages. They
share information directly, but they have different processing algorithms. They output data in different languages, and they are both
capable of functioning independently.
The left and the right brains have an excellent partnership—a
working relationship that hands off tasks that are better suited to
C h a p t e r 3 . Two Brains are Better Than One
the other side. Part of the “programming” of the brain is to determine what type of processing is needed for a given task or situation.
While both sides of the brain can be involved in the task at hand, the
side that is more suited to the task will take control, and the other
side will defer. For example, if the task is to recite the letters of the
alphabet, the left brain will control. On the other hand, if the task is
to navigate at sea, the right brain will likely control.
Many tasks involve some combination of right-brain and
left-brain processing needs, for example, a task that includes both
known patterns and ambiguous situations. The processing architecture and the extensive interconnectedness of the brain make it
possible for us to simultaneously consider many pieces of information or constraints, each of which may be imperfectly specified and
ambiguous.9
n Consciousness
Consideration of left-brain and right-brain functions inevitably leads to questions about consciousness. It is commonly believed
that consciousness resides in the left brain and that the right brain
controls unconscious or subconscious thought. This view misses the
mark about how these two hemispheres operate.
Generally, we are conscious of thought from one side of the
brain at a time. This experience is a result of the brain architecture
and its extensive network of interconnections.
Many of us spend the majority of our time involved in left-brain
tasks. Therefore, it is reasonable to perceive that the left brain is
controlling conscious thought most of the time. But this does not
mean that the right brain is “unconscious.” It simply means that the
activities of the left brain are more immediately accessible.
Metabolic studies have shown that the right hemisphere consumes the same amount of energy as the left, implying that the
hemispheres perform the same amount of work. This finding has
been confirmed by measurements of the electrical activity on each
side of the brain.
47
48
Right-Brain Project Management
Part of what seems to be “unconscious” about the right brain
is simply that although we know that it processes information and
influences our behavior, we have difficulty verbally explaining its
actions and its information. Thus, right-brain information can at
times seem difficult to access and understand.
We can take steps to quiet the dominant left brain so we can
hear what the right brain has to say. For example, traditional psychological tests such as a Rorschach test and word association are
specifically designed to access right-brain processing.
Consider the analogy of an iceberg. The part of the iceberg that
is visible above the surface of the water can be likened to what we
perceive in conscious thought. The large part of the iceberg below
the water surface can be considered unconscious thought. Although
this thought is not perceived, it is nonetheless real and active.
n Learning and Applying:
The Two Brains at Work
The right brain excels at learning. By nature, learning new patterns or insights involves encountering information that is different
from what is already known. The right brain is called into action to
connect the new information to previously known patterns. The left
brain can then apply the new knowledge in the form of patterns or
rules. The right brain learns the patterns and the left brain applies
them reliably.
Different types of knowledge are suited to each brain style. For
example, studying the rules of professional golf regarding taking a
penalty for a shot out of bounds would go directly to the left brain.
On the other hand, the right brain is much better with knowledge that is complex, visual, or kinesthetic. These types of skills
are information-rich and holistic, and they are difficult to explain
with words alone. Often the best way to learn such tasks is to watch
someone who is skilled and attempt to copy his or her actions.
Learning to hit a golf ball is almost impossible for the left brain
to handle, because it is difficult to dissect the complex motions into
C h a p t e r 3 . Two Brains are Better Than One
discrete steps and rules. It is not uncommon for duffers to take lessons from a golf pro and find that their swing actually deteriorates
when they consciously think about particular steps using rules and
left-brain processing. It is not possible for the step-by-step left-brain
style to process all of the many muscle movements and perceptions
that go into the rather simple task of hitting a golf ball. The style of
learning needed is classically right brain.
n Do You Use Your Right Brain?
Many believe that there are “right-brain people” and “left-brain
people.” This distinction is typically used to describe differences in
skill, personality, and career preferences. It is true that some people
tend to be more skilled in logical rule functions, such as computer
programmers. Other people are more comfortable operating in a
creative space. However, all people are capable of operating in both
domains.
William “Ned” Hermann developed a helpful way to classify
dominant brain processing styles. The Hermann Brain Dominance
InstrumentTM (HBDITM)10 (see Table 3-2) is a model of the physiology of the brain and the thinking styles an individual prefers.11 The
four styles of brain dominance relate to the four quadrants created
from the right and left hemispheres and the front and back halves of
the brain. The front, or cerebral, half of the brain is the area where
most conscious thought takes place. The back, or limbic, half of the
brain controls emotional behavior. While most individuals gravitate
to certain preferred or dominant modes of thinking, we generally
operate to some extent in all four quadrants.
If you have a hard time thinking of yourself as a right-brain
person, simply remember the last time you drove a car.
Assuming that you’ve been a driver for some time, chances are
you don’t think that much about driving. People do all sorts of things
that occupy their attention while driving: talking on a cell phone,
eating, and yelling at kids in the back seat. Some people do quite
dangerous activities while driving, such as reading or even knitting.
I’ve seen a photo of someone who was eating a meal with chopsticks
while driving!
49
50
Right-Brain Project Management
n
Table 3-2. HBDITM Four-Quadrant Model of Thinking Preferences
Cerebral mode
Left
Right
Upper left
Upper right
(Rational)
(Experimental)
Logical
Visual
Analytical
Conceptual
Mathematical
Imaginative
Factual
Synthesizing
Lower left
Lower right
(Ordered)
(Feeling)
ControlledEmotional
Organized
Interpersonal
DetailedEmpathetic
SequentialExpressive
Left
Right
Limbic mode
While neglecting for a moment whether anyone should do
these things, how is it even possible to do anything else while driving? It’s because of the right brain.
The right brain can process a huge amount of visual and physical
information simultaneously and in real time, and can do so largely
without involving the driver’s attention. The next time you drive, be
thankful for your right brain.
n Intuition
As with conscious thought, the concept of intuition is rife with
misunderstandings. Intuition is also called a “gut feeling” or “sixth
sense,” and it is definitely a right-brain activity.
While it may be hard to get a grasp on intuition, it is a real
phenomenon. The right brain can analyze large amounts of data
quickly and make connections among disparate and incomplete sets
C h a p t e r 3 . Two Brains are Better Than One
of information to reach a conclusion almost instantaneously. The
whole process can seem somewhat mystical and difficult to understand, especially when considered in comparison to how the left
brain works. Therefore, intuition is often discounted, especially in
organizations.
This does not mean that intuition is always correct or always
useful; it simply means that it can be a powerful tool for individuals
and organizations to use.
n Connection to Personality
Just as individuals may operate more comfortably on one side of
the brain or the other, so too do we typically operate more comfortably with certain personality styles.
Personality can be considered a dominant or preferred style
of thinking or method of processing information. While the concept of personality has been studied most extensively for individuals, organizations also exhibit personality styles, as explained in the
book Companies Are People Too, by Sandra Fekete.12
One of the most widely recognized systems for classifying personality styles is the Myers-Briggs Type Indicator (MBTI®).13 The
MBTI® classifies personality types in four dimensions, with each
dimension having two poles. A given individual may exhibit a style
somewhere along the continuum of the two poles. The MyersBriggs classification is provided in Table 3-3.14
To explore personality, let us consider the Myers-Briggs dimension Intuitive/Sensing. This dimension considers the types of information an individual prefers. A Sensing person prefers concrete and
precise data, while an Intuitive person is most comfortable with general concepts. Both styles are valuable depending on the context.
Conflict can arise if people with opposite styles work together
but fail to appreciate their differences. A Sensing individual will
likely get frustrated trying to nail down the specifications for a product in a meeting with an Intuitive person who enjoys talking about
51
52
Right-Brain Project Management
n
Table 3-3. MBTI Personality Preferences
Extraversion (E) and Introversion (I)
Dimension: Preference for internal or external thought activity
We each have the world of thoughts and feelings inside ourselves and the
world of interactions and experiences outside. When we interact with or gain
energy from the world outside, we exhibit extraversion. When we reflect on
our thoughts or gain energy from self-awareness, we are exhibit introversion.
Sensing (S) and Intuitive (N)
Dimension: Preference for facts or concepts
We receive information through the five senses, but we can use the information in two different ways. A Sensing person prefers to process information in
a concrete, factual manner, while an Intuitive person prefers to use information to create abstractions.
Thinking (T) and Feeling (F)
Dimension: Decisions based on reason or values.
A Thinking person makes decisions based on logic and reason. A Feeling person makes decisions according to a value system, and often incorporates the
values of others into the decisions.
Judging (J) and Perceiving (P)
Dimension: Preference for planning or flexibility.
People who exhibit the Judging preference prefer order, through lists, schedules, and closure. Those who exhibit the Perceiving preference prefer flexibility and spontaneity.
new ways that the product can benefit a customer. When each person recognizes the value of the different styles and can move into
the other style, the team can accomplish dramatic results.
It is fascinating to see that personality styles can be considered
right-brain and left-brain styles. This observation applies to all the
Myers-Briggs dimensions except the Extravert-Introvert classification, which is an internal versus external orientation. The remaining three dimensions exhibit right- and left-brain characteristics, as
shown in Table 3-4. These classifications can give us insights into
how we work as individuals as well as how we can work more effectively in groups, including our project teams.
C h a p t e r 3 . Two Brains are Better Than One
n
Table 3-4. Left- and Right-Brain Personality Preferences
Left Brain
Right Brain
Sensing
Intuitive
Thinking
Feeling
JudgingPerceiving
In considering personality styles, it is important to emphasize
that there are no right or wrong styles. Each style has strengths and
weaknesses that are situational. We are also not “programmed” like
robots into a permanent way of thinking. People can deliberately
choose to exercise a non-dominant style or to appreciate another
person with a differing style. Such capabilities are crucial to success
for project teams.
n Application to Projects
Now that we understand the fundamentals of brain functioning
and thinking and personality styles, what are the implications for
project work?
Project work is performed by people, individually and in teams.
We can benefit from understanding how people think and what
styles lend themselves most readily to particular projects. Furthermore, there is much to be gained by using both sides of the brain as
appropriate on project work.
Left-brain techniques are perfect for those projects that involve
the application of known approaches with teams of people who are
familiar with each other. But what if a project involves new technology, processes, or team members? Relying on a left-brain style here
is somewhat like trying to force a square peg in a round hole: it can
be done, but the results are not necessarily what everyone wants. It
is much better to consider and apply techniques that are appropriate
to the need.
The MBTI® Perceiving style is helpful for a project that has a
significant component of ambiguity. While it is helpful to have indi-
53
54
Right-Brain Project Management
viduals with Perceiving preferences on the team, it is also important
to lead the team deliberately into acting more Perceiving. Having a
Judging preference on a project that requires experimentation and
adaptation will understandably frustrate the team.
Such an approach ties into maturity and emotional intelligence.
When a person starts to act in his non-dominant personality type,
he will likely feel anxious. If I am a Judging person trying to address
ambiguity on a project, and I decide to act more Perceiving, it may
very well feel uncomfortable. Here is a situation that calls for growth
in maturity, in terms of both personal development and emotional
intelligence.
To succeed, I must tolerate the ambiguity as well as see the
world from a new perspective. I must be able to master my anxiety
as I embark on new goals. I must also accept the inner conflict that
may come with new ways of thinking that may challenge my longheld beliefs.
To continue with our exploration into right-brain project management, we need to go to the source of energy for projects and
examine what makes people want to work on projects. We need to
understand motivation. n
n Endnotes
1Antonio Damasio, Descartes’ Error (New York: Putnam, 1994), pp. 34–43.
2David Pacchioli, “The Moral Brain,” Research Penn State Magazine, Penn
State University, October 2, 2006, http://www.rps.psu.edu/indepth/brainscans1.html. Accessed November 2006.
3Richard E. Boyatzis, foreword to Moral Intelligence, by Doug Lennick and
Fred Kiel (Upper Saddle River, NJ: Wharton School Publishing, 2005), pp.
xxiii–xxiv.
4Joshua D. Greene, R. Brian Sommerville, Leigh E. Nystrom, John M. Darley, and Jonathan D. Cohen, “An fMRI Investigation of Emotional Engagement in Moral Judgment,” Science, Vol. 293, Issue 5537, September 14,
2001, pp. 2105–2108.
5Joshua Greene and Jonathan Haidt, “How (and Where) Does Moral Judgment Work?” TRENDS in Cognitive Sciences, Vol. 6, No. 12, December
2002.
C h a p t e r 3 . Two Brains are Better Than One
6Jorge Moll, et al., “The Neural Correlates of Moral Sensitivity: A Functional
Magnetic Resonance Imaging Investigation of Basic and Moral Emotions,” The Journal of Neuroscience, Vol. 22, No. 7, April 1, 2002, pp.
2730–2736.
7Doug Lennick and Fred Kiel, Moral Intelligence (Upper Saddle River, NJ:
Wharton School Publishing, 2005), p. 7.
8Ibid., pp. 9–10.
9J. L. McClelland, D. E. Rumelhart, and G. E. Hinton, “The Appeal of Parallel Distributed Processing,” Parallel Distributed Processing, Vol. 1: Foundations, James L. McCelland, David E. Rumelhart, and the PDP Research
Group (Cambridge, MA: MIT Press, 1987), pp. 3–4.
10 Hermann Brain Dominance Instrument and HBDI are trademarks of Hermann International.
11 Ned Herrmann, The Creative Brain (Lake Lure, NC: Ned Herrmann
Group, 1993), pp. 47, 220.
12 Sandra Fekete, Companies Are People, Too (Hoboken, NJ: John Wiley &
Sons, 2003).
13 Myers-Briggs Type Indicator and MBTI® are registered trademarks of Consulting Psychologists Press, Inc.
14 Lenore Thomson, Personality Type: An Owner’s Manual (Boston: Shambala Publishing, 1998), pp. 27–55.
55
C h a pt e r
6
n Tools
of the Trade:
Working with the
Right Brain
n
n
n
We shape our tools and thereafter our tools shape us.
Ma r s h a l l M c L u h a n
n
A
s an indication of the power of right-brain processing,
consider the following story.
One morning, Paul McCartney awoke from a dream in which
he had composed the entire melody of a song. He quickly wrote it
down and recorded it before losing it to fading memory. The experience of writing a song while asleep seemed so bizarre and unexpected to him that he initially believed he must have heard the tune
somewhere before. Although he liked the melody, he did not want
to plagiarize someone else’s work.
In the coming weeks, he played the tune for a number of people;
perhaps someone else would recognize the melody and put an end
to the matter. But no one else had heard it before. Finally, McCartney accepted that the song must be his own.
He eventually put words to the tune. The other members of
the Beatles initially disliked the song, in part because it was such a
departure from their existing work.
McCartney’s creation has since become the most “covered”
song ever. More than 3,000 other versions of the song have been
recorded, and the clearinghouse BMI estimates that it has been performed some seven million times.
94
Right-Brain Project Management
Certainly, only a composer as gifted as McCartney could write
“Yesterday.” But what is so amazing about the song is that he slept
through the act of composing it. While he slept, his right brain was
truly busy constructing the pattern of notes that would become one
of the most memorable songs of our time, and in his own words,
“the most complete song I have ever written.”1
It is unlikely that a project sponsor would understand if I said I
needed to get some sleep to work on her challenging project. Since
there are few McCartney-esque project managers around, we mere
mortals can benefit from a set of tools that enables us to take advantage of the right brain during our waking hours.
Work on a phenomenal project demands a high degree of rightbrain processing. Drawing on motivation from emotional energy,
we apply creative abilities to sort and apply new patterns, using rich
communication and decision-making skills.
Such a project exercises the right brain to an extraordinary
degree, but this does not mean that the left brain takes a vacation.
On the contrary, if we look a bit more closely we can see that the
two hemispheres are working together. The left brain is quickly
applying the new patterns the right brain is creating.
One of the elements that may feel surprising when we exercise
the right brain more fully is the agility with which this process of
right brain/left brain coordination happens. Our brains are wired
for this kind of processing, and we have much to gain by working
with these natural processes.
As with any other skill, we become more proficient in the tools
of the right brain the more we use them. So how can we take advantage of all that these “tools of the trade” have to offer?
n Second That Emotion
Emotion. The mere mention of the word in the workplace makes
people uncomfortable.
C h a p t e r 6 . Tools of the Trade: Working with the Right Brain
Isn’t the office a place where emotions are kept in check? The
workplace culture allows appropriate, reserved expressions of emotion, but frowns upon emotional outbursts. There is nothing intrinsically wrong with this culture: emotional “freedom” is culturally
regulated in many places we frequent depending on context. However, the key issue with emotion in the workplace is not the expression of emotion so much as it is the appropriate acknowledgment of
emotion.
The marketplace is overwhelmingly a place where rationality
is valued over emotion; Descartes would feel very much at home
there. Emotionality is regarded as the “antithesis of rationality.”2
Companies view the components of organizational work from a
rational perspective, whether the topic is strategy, compensation
policies, competition, or any of a host of other issues.
But the reality is, humans experience emotions throughout
the workday. While we may keep our emotions in check inside the
office or factory, we certainly do not leave them outside the door.
Organizational life cannot be separated from emotion.
Recall the studies we discussed in Chapter 3 concerning fMRI
scans of individuals who were presented with various images. Their
neurons fired automatically, resulting in basic and moral emotions.
Other individuals presented with hypothetical moral decisions also
exhibited neurons that fired and caused moral emotions. In the
office or on the shop floor, we are constantly presented with images
and situations that form both basic and moral emotions.
For humans, emotions serve very important functions. Fear
keeps us out of danger, anger can bring about change, and joy is the
essence of what makes life worthwhile. If that is not enough reason
to value emotion, remember that emotion is necessary for making
decisions, even the most trivial ones.
On the other hand, emotions can get us in trouble. An individual with excessive fear can become virtually paralyzed. Inappropriate rage can be cause for termination, and out-of-place boisterous
laughter will lead to ridicule.
95
96
Right-Brain Project Management
This potential for dysfunctional experiences with emotions has
contributed to the dominance of rationality in the world of work.3
But excessive reliance on rational thought can likewise be dysfunctional. For example, in a crisis situation, a robotic reflection on the
pros and cons of various response options is likely to result in failure
or tragedy. What is needed in crisis situations is quick action that is
thoughtful but heavily dependent on emotion and intuition.
Consider also that humans avoid activities and environments
that seem robotic and devoid of emotion or idiosyncrasy. While Star
Trek’s Mr. Spock was a “fascinating” character, few people could
stand to be around him all the time. There is something inhuman
about extreme rationality.
Both emotionality and rationality therefore serve important
functions, but they can be dysfunctional depending on the context.
When we rely too heavily on rational thought, we tragically fail to
take advantage of the many benefits of appropriate emotional energy.
This blind spot is particularly relevant to contemporary, complex
projects because they sorely need appropriate emotion to succeed.
So how we can best use and apply emotion in the workplace? It
is helpful to acknowledge the role of emotion. It is even more beneficial to recognize that rationality and emotionality are very much
linked and work together powerfully.
The key to using emotion to advantage in project management is emotional intelligence. “Emotional intelligence essentially
describes the ability to effectively join emotions and reasoning,
using emotions to facilitate reasoning and reasoning intelligently
about emotions.”4 In other words, what we seek is not the absence
or neglect of emotion, but the active partnership of the rational and
emotional worlds.
as:
5
The ingredients of emotional intelligence can be summarized
• The ability to know one’s emotions
• The skill to manage one’s emotions appropriately
C h a p t e r 6 . Tools of the Trade: Working with the Right Brain
• The means to motivate oneself
• The perception to recognize emotions in others
• The skill to handle relationships competently.
This perspective is foremost a recognition and acknowledgment of the value of emotion in the life of the organization as well
as in the lives of individuals. The significant shift in thought is from
a generalized “all emotions are irrational” to the more targeted
“appropriate emotions are beneficial while dysfunctional emotions
are harmful.”
Consider a brief example of how emotional intelligence applies
and is important on the contemporary, complex project. Suppose
there are two projects with two project managers, Emily and Lee.
The projects are exactly the same, and they are both considered to
be complex and on aggressive schedules. The project managers have
the same domain knowledge and overall cognitive intelligence. The
only difference in the two scenarios is that Emily has a higher level
of emotional intelligence than Lee. Emily has learned to know and
manage her own emotions appropriately, while Lee has some difficulty in this area.
When faced with the ambiguity and pressure of this type of
project, many people will understandably feel anxious. As someone
with a low EI, Lee might have difficulty comprehending this anxiety
and taking steps to address it. Also, Lee might be unable to help
team members work through their anxiety. A persistent high level
of anxiety is likely to cloud good decision-making on the project
and drain away energy that is needed to work effectively. Emily, the
project manager with a higher EI, is more likely to recognize and
acknowledge the anxiety appropriately and lead the team through it
effectively.
In both cases, anxiety is present. When the project manager possesses emotional intelligence skills, he or she will be able to channel
the emotion of anxiety in conjunction with rational thought.
Considerable research backs up the beneficial effects of applying emotion appropriately. Executives who demonstrate higher
97
98
Right-Brain Project Management
levels of EI have been shown to be more likely to achieve desired
business outcomes and be judged as effective leaders by both subordinates and superiors.6 Enhanced emotional intelligence for a project manager has been shown to have a positive impact on project
performance.7
Project success is enhanced by a motivated team, good team
processes, good communication, and effective team decision-making. These elements are all facilitated by high levels of emotional
intelligence.
Interestingly, these elements are also components of leadership
abilities. Contemporary, challenging projects need good leadership,
and furthermore, they need good distributed leadership. While it is
great to have an outstanding leader as project manager, it is far better to have an entire team of individuals who are competent leaders.
Not coincidentally, research shows a linkage between maturity in
emotional intelligence and leadership abilities.8 This should come
as no surprise because good leadership is so dependent on people
skills.
As one example of the appropriate and effective use of emotion,
consider the progression of messages on safety signs. A number of
years ago, a safety sign near an electrical facility may have simply
said, “Danger – High Voltage.” In recent years, it has become standard practice to include on the sign the action to be avoided and the
consequence of interacting with the hazard. When one reads that an
action “… may result in death,” the message becomes very powerful. The content of the sign does not explicitly include emotion, but
it clearly engages strong emotions.
The management of emotion is an important element of effective projects and right-brain project management. While emotion is
important in many ways, let us focus on five benefits of exercising
emotion appropriately on projects:
• Motivation. Work on challenging projects requires considerable mental energy and commitment—in other words,
motivation. While rational thought helps, the true source of
motivation is emotion.
C h a p t e r 6 . Tools of the Trade: Working with the Right Brain
• Team processes. Humans are creatures with emotions. Awareness of one’s own emotions and the emotions of others
is critical for team communication and interactions to be
productive.
• Cohesiveness. A collection of individuals can work together,
but the transition to becoming a cohesive team is made
when the individuals share important experiences with significant emotional content.9
• Performance. Individuals and teams perform best when emotions are healthy and positive.
• Decision-making. If an individual needs emotion to make
decisions, so too does a team. Group decision-making is
facilitated when the emotional component of options is
taken into account.
Maturity in emotional intelligence is a skill that can be
improved upon much like any other skill. The process begins with
the acknowledgement of emotion in the workplace and an appreciation of its benefits. While such an approach may run contrary to
the dominance of rationality in the workplace, the advantages to be
gained are significant—and are therefore well worth our rational
consideration! They are advantages that are absolutely essential for
the contemporary project.
n Creativity and Pattern Discovery
Creativity is at its core divergent thinking. It is the decision to
take a known pattern or rule and break it in the quest to find a new
and useful pattern. To a large extent, this is an experimental process,
but the process starts with breaking the old pattern.
The greatest challenge to creative thought is temporarily turning off conscious or left-brain, rule-based thinking so that new
approaches can be considered and tried. At times, these patterns are
so ingrained and so automatic that it is necessary to perform deliberate interventions to access the right brain.
99
100 Right-Brain Project Management
Malcolm Gladwell, in his book Blink, talks about the unconscious processing of the right brain as activity that goes on behind
a locked door. But be certain that the processing is occurring. Our
task is to access it.
A number of interventions can stimulate creative thought when
attempting to solve a problem; the objective is to purposely bypass
the left brain and its rules. One set of interventions involves contradicting known patterns and assumptions to determine if new patterns may work. This process is often called provocation.
For example, on a project, consider the assumption that “Task A
will take at least 15 days to complete.” To start the creative process,
we break this assumption by saying, “Task A must take less than 15
days to complete.”
Suddenly, the left brain is out of commission. It doesn’t have a
pattern to apply to the new condition, and so it turns the problem
over to the right brain. This handoff starts a series of creative “what
if” questions in the right brain: What if we add staff to the task?
What if we use some new, efficient technology? What if we completely rethink the task from a different perspective?
The creativity guru Edward de Bono identified a continuum of
provocation, from the gentle “What if?” to a more extreme revision
of known reality—cases that seem impossible or illogical. He even
coined the word “po” (provocative operation) as a function to introduce such an extreme provocation. Po is a signal to those involved in
the creative exercise that the premise to follow is really wacky.10
In one example of this process, we start with an assumption of
something familiar, something we take as a given, and then we violate it. For example:
Cars have headlights.
Po, cars do not have headlights.
Creatively, we attempt to construct systems that might fill the
functions formerly performed by headlights. Perhaps cars might be
coated with paint that glows in the dark. We might include a sonar-
C h a p t e r 6 . Tools of the Trade: Working with the Right Brain
type instrument to alert us of an obstacle in the road ahead. We
won’t necessarily choose these options, but suggesting them may
uncover a breakthrough concept.
Pattern discovery goes hand in hand with creativity. If creative
thought is divergent thought, then pattern discovery is the effort to
bring the creative process to converge on something useful to the
need at hand.
One of the keys to appreciating pattern discovery in the right
brain is to recognize that we search for patterns according to context
and expectations.11 For example, letters can be distinguished faster
and more accurately when they appear in the context of a known
word rather than as a set of random letters or alone.
When this concept is applied in the project context, we search
creatively for new patterns for the problem we are solving. We do
so based on the context of the project as well as what we know has
worked in the past.
Pattern recognition within a context is directed toward a goal:
to solve the problem at hand. Once a suitable pattern is found, it
becomes part of the repertoire of the left brain for practice and skill.
It also becomes part of memory that the right brain can access in the
future for other pattern-discovery tasks.
n Metaphor
Suppose a spacecraft of friendly Martians landed and I wanted
to describe to them various aspects of life on earth. When I arrived
at the subject of a rose, I could convey the concept in several different ways.
I could quote them the definition of a rose: “Any of numerous
shrubs or vines of the genus Rosa, having prickly stems, pinnately
compound leaves, and variously colored, often fragrant flowers.”12
I could show them a photograph of a rose.
101
102 Right-Brain Project Management
I could hand them a rose and let them smell it and feel the soft
petals and prickly thorns.
Finally, I could quote Shakespeare from Romeo and Juliet:13
What’s in a name? that which we call a rose
By any other name would smell as sweet.
My new friends might say, “Whoa, back up. You were describing a rose and you lost us when you got into names and such.”
My friends are not familiar with the power of metaphor. In
two lines, Juliet uses the sweet smell of a rose to make a powerful
statement of her love for Romeo. The love between Romeo and
Juliet is forbidden because of their families of origin; for love of
Juliet, Romeo states that he will renounce his family and change his
name. She loves the person regardless of his name. The “thing” that
we call a rose will still be the same “thing” and will have the same
essence no matter what name we give it. But more than that observation, Juliet’s passing reference to an arbitrary designation for a
flower speaks volumes about the identity and character of a person,
as well as how the love in a relationship remains even when people
change their names.
This is the amazing power of metaphor. Had Juliet chosen a
left-brain approach, this passage might have taken several pages
using logical constructs to convey what she said in 18 words. Even
then, the logical description would not capture the richness of the
metaphor.
The left brain can process only the literal meaning of Juliet’s
words and would completely miss her expression of love and profound truth about identity. Metaphor is one of the most powerful
and economical ways to communicate and to understand using the
right brain.
A metaphor can be used in a straightforward manner, perhaps
in the form of a simile. For example, if our project is to design a
new electronic language translator, we could say that it will have a
user interface like that of an iPod. Right there, we have cut to the
C h a p t e r 6 . Tools of the Trade: Working with the Right Brain
chase and connected what is familiar with something that does not
yet exist.
The metaphor can be more indirect, conveying information
that is emotional in nature, and perhaps be more effective when it
comes to marketing. “Our translator is a door to foreign lands. Walk
through the door and onto the Champs-Élysées.”
That approach will connect back to the design project in terms
of features and interface. But the way that the user experience is
communicated has an emotional impact on the development team
as well. What is it about the translator that enables this virtual trip
to Paris? Is it a visual interface with scenes of Parisian streets? Does
the computer include the chatter of street sounds and Parisians talking? Perhaps an olfactory generator pumps out those unique molecules that create the aroma of freshly baked baguettes.
Using the metaphor and imagery, we have transformed a language dictionary into an experience replete with sensory and emotional richness. Advertisers work this magic on us all the time. One
can of beer becomes a winning touchdown, another is a pleasant
conversation with good friends, yet another is a drink from a pure
mountain stream.
Yes, it is magic—pure right-brain magic.
n Tell the Story
Closely related to metaphor is the rich communication style of
storytelling, which is an outstanding tool of the right brain. We will
look at stories in more depth later, but for now, let us briefly note
the reasons for adding storytelling to the project manager’s toolkit.
Storytelling is a powerful way to communicate complex ideas
or establish a case for change. It is also an excellent way to transmit
values and to encourage people to work together quickly and enthusiastically.14 Complex and aggressive projects need these benefits of
storytelling.
103
104 Right-Brain Project Management
When we talk about storytelling in an organizational setting,
we do not mean something that starts with, “Once upon a time ….”
Rather, it is the natural telling of events, objectives, and what they
mean. While good storytelling involves certain elements, anyone
can tell a story. The case studies of exceptional projects included in
this book are examples of storytelling.
Members of Generation Y, the children of baby boomers, are
particularly receptive to stories, and they are familiar and comfortable with the informal exchange of stories through, for example,
blogs.15 That’s a promising sign, as many believe that storytelling is
one of the most important skills needed by present-day and future
leaders.
n Non-Verbal Communication
While the left brain processes information verbally, through
words, the right brain can process information non-verbally, through
pictures, sensations, and spatial relationships. We generally attempt
to solve problems with verbal techniques, but it is often helpful to
switch to another form of communication to engage the right brain.
In many cases a combination technique is quite helpful.
One such technique is a mind map. A mind map is a visual representation of the components of an issue and the relationships and
dependencies among the components. The visual aspect of this tool
helps engage the right brain more than words alone. This technique
engages not only left-brain sequential processing but also rightbrain spatial processing. A mind map tool is also available in software that enables a user to organize ideas visually.16 An example of a
mind map is shown in Figure 6-1.
Some problems are far easier to solve visually than verbally.
When James D. Watson and Francis Crick cracked the genetic code
by determining the structure of DNA, they solved the problem spatially. They approached the problem by asking which atoms like to
sit next to each other; their main tools were a set of molecular models that resembled children’s toys.17
n
Market research
Meeting agenda
Objectives
Vision
Project charter
Corporate mission
Purpose & Objectives
Project planning
retreat meeting
Figure 6-1. Mind Map for a Project Planning Retreat Meeting
Presenters
Facilities
Participants
Facilitators
Speakers
Supplies
A-V equipment
Tables, chairs
Refreshments
Meals
Meeting room
Inform
Prepare
Schedule
C h a p t e r 6 . Tools of the Trade: Working with the Right Brain
105
106 Right-Brain Project Management
An important form of non-verbal communication is what is
commonly known as “body language.” If we are present with someone and listening to him or her talk, the left brain is processing
our literal understanding of the words. Meanwhile, the right brain
is picking up on various visual and auditory clues about the emotional content associated with the words. It is estimated that 80–90
percent of the content of a message is received in the form of body
language.
Visualizing the Project
Matt Glei
I find it very helpful to use visual approaches in project management.
One of my favorite techniques is to visualize an image of the end
product or service and work backwards to decompose the parts and
the order of attack. Sometimes this approach helps people flesh out
the totality of the project goals and remember them on a daily basis. It
also humanizes the goals, so they become much more than the elements of a project plan or checklist.
This visualization approach is instinctive. When we were kids and
wanted to build a dam across a creek, we didn’t stop and do a drawing, a work breakdown structure, and so forth. Instead, we would visualize and discuss what we wanted to do, and how cool it would look
when complete. The image enabled us to see where the spillway or
waterfall would be, and how we could catch crawfish, fish, or bugs in
the “reservoir.”
Visualizing the final product allowed us to think naturally about leftbrain items—I need rocks, sticks, leaves, and mud—for resource management and staging. It also prompted questions about how the work
would be accomplished: Do I need to get a bucket or can? (tools)
What size rock can I carry? (resource capabilities) How far away are
the rocks? (resource logistics) Can I get some help? (resource planning) Are there snakes around? (risk analysis) Kids don’t need project
management training to do this—it comes naturally. Of course, we
would make mistakes and learn better ways; then we would adapt
and change strategies before proceeding too far with the project.
C h a p t e r 6 . Tools of the Trade: Working with the Right Brain
I often intermingle right- and left-brain styles. For example, I may start
with product visualization and decomposition, and then switch to traditional task analysis, work breakdown structures, and resource leveling. Once this is done, I identify the milestones (or yardstones) and
use the yardstones to help guide and evaluate progress. Although
disconnected information can result, it is often better to use the plan
as a guide rather than completing the proper steps in order (unless
the specific order is critical to success). In this way, I use the plan to
make sure that no key part goes undone and I gauge progress from
achieving the yardstones. This is more efficient than tracking whether
my plan was flawless.
Risk analysis is another method that can be used in both left- and
right-brain ways. We can easily brainstorm the riskier parts of a product
or project at a high level and use that knowledge to think about how
to mitigate risks at the appropriate time in the project. Most of us don’t
need to prepare a 36-page, formal probability/severity/mitigation risk
document to understand what parts of the project are the riskiest and
what can be done to reduce or mitigate those risks.
One challenge that project managers often face occurs when a new
team member comes on board in the middle of a project. While the
new member may have a basic understanding of the project, he or
she lacks the detailed context of how decisions have been made.
Some excellent tools are available to assist a project team in visualizing the process. One approach that I particularly like is to use a
mind-mapping tool for documenting key decisions. This tool captures
the alternatives, and pros and cons, in the decision as well as who
participated in the decision. Mind mapping makes it easy to document
the decisions and provide important context. This tool is great for helping explain to a new team member what key decisions were and why
they were made.
It is also important to convey to new team members the philosophy
and purpose behind a product or project. Any approach that uses
images and metaphors to connect to emotions can be very powerful.
Rather than saying “this device measures blood oxygen levels noninvasively,” it is much more powerful to say “this device can prevent
the anesthesiologist from accidentally killing the patient.”
107
108 Right-Brain Project Management
In short, many of the most successful and innovative projects include
techniques from both sides of the brain. Right-brain approaches are
incredibly powerful, but they can’t do all the heavy lifting. What they
can do is help drive thinking in new ways, spotting possible risks and
opportunities that a left-brain approach alone may not uncover.
Matt Glei is Executive Vice President of Operations for Hoana Medical in
Honolulu, Hawaii. Hoana develops and markets medical devices for noncontact patient monitoring systems. Matt has over 30 years of experience in
the medical industry, with a focus on device product marketing and research
and development. His career has included positions with Honeywell Medical,
Hewlett-Packard, and Nellcor Puritan Bennett.
n Intuition
In 1969, The Who released what was billed as the first rock
opera. Tommy featured the story of a fictional “deaf, dumb, and
blind kid,” rendered that way by a traumatic childhood experience.
Tommy discovers that he has astounding skill at playing pinball and
becomes the champion “Pinball Wizard,” puzzling his competitors
because he “plays by intuition.”
To a certain extent, on the complex project we all operate as
the “deaf, dumb, and blind kid.” We encounter situations that are
unfamiliar, forces that seem to defy our control. We need a way to
see through the fog and operate with mastery.
An important technique in this environment is to play by
intuition.
If emotion is the ignored child in the workplace, then intuition
must be its first cousin. Whatever you call it—gut feeling, instinct,
or sixth sense—it is a form of guidance that is not consciously
derived. Intuition is “... direct knowing without any use of conscious
reasoning.”18
Intuition seems inexplicable, mystical, ephemeral, and at
times random or serendipitous. In other words, it is not rational.
Although anything that is not rational is generally avoided in the
workplace, intuition is actually used quite often (if not publicly
acknowledged).
C h a p t e r 6 . Tools of the Trade: Working with the Right Brain
Intuition is real, and it is very valuable (if misunderstood). It is
one of the powerful tools of the right brain, one that is exquisitely
tailored to the complex project.
To understand and appreciate intuition, recall that the right brain
can process vast amounts of information and do so holistically, in contrast to the stepwise left-brain style. The right brain often does this
work quietly, in the background, under the radar of consciousness. It
works particularly on those problems or challenges that involve some
novel element, and it is directed toward pattern recognition and solution. To arrive at the solution, intuition draws heavily on experiences
and the emotions associated with those experiences. In many cases,
the processing occurs with astounding speed.
The way the solution is reported may be puzzling to many.
For some people, intuition results in an emotion associated with
a thought. Intuition works through a part of the brain that is wired
into the viscera. A solution derived through intuition is communicated into the torso through this channel. So when someone says that
they have a gut feeling, they do in fact have a feeling in their gut!
Left-brain, rational thinking analyzes; right-brain, intuitive
thinking synthesizes. Intuitive thinking synthesizes disconnected
pieces of information and experience into an integrated picture.
Intuition can be divided into two types. Expert intuition is
the result of years of experience. When a slightly novel situation
arises, an expert can intuitively know how to react, without analytical thought. As an example, an individual who has operated the
same industrial plant for 25 years knows its functioning intimately.
If one day, an area of the plant shuts down unexpectedly, he will
likely experience a gut feeling about the cause.
The second type of intuition is entrepreneurial intuition, which
we experience in an entirely new situation. We have no definitive
rules or framework to operate from, but we do have our own personal years of experience. The right brain searches that experience
for patterns that are analogous in some way.
Intuition is highly valuable, if not necessary, in complex environments, especially those that are characterized as “high velocity.” These
109
110
Right-Brain Project Management
situations require that many options be processed based on limited
information. Intuition is needed when the problem is ill-defined and
has no precedent19—a description that could easily serve as the definition for a contemporary project! For stable, familiar environments,
intuition is not needed, and can actually be detrimental. In such
situations, a rational, analytical process works best.20
Once we rented the DVD for The Bourne Identity. After watching the movie, we watched the commentary by the director Doug
Limon. He made the comment that, when it came to filming, he
didn’t want to think too much—he believed it was important to be
instinctive.
In many cases, thoughtful planning and execution lead to a
good product. But after the planning is done, acting on intuition or
instinct may produce even better results.
It is important to note that intuition should not be relied on
to the exclusion of rational analysis. On the contrary, such analysis
plays an important role in making decisions; it is one of the mechanisms that intuition uses to synthesize all that is known and understood about the problem at hand.
Intuition relies to a large extent on emotional memories associated with experiences. This linkage is one of the critical elements
in the growth in maturity from novice to expert, whatever the skill.
If our experiences were detached from emotion, we would have
little motivation to push through our limitations and improve. But
when we deeply feel pride in accomplishment, or feel the remorse of
mistakes, those emotions lay the foundation for expertise. In other
words, it is because we care about the outcome that we progress
toward maturity.21
Interestingly, research has shown that memories associated with
negative emotions, such as shame or remorse, carry more weight
than those associated with positive emotions. For example, while we
might expect that investment decisions would be made rationally,
most people pay far greater attention to losses than to gains. In fact,
the emotional effect of a $250 gain is about the same as the emotional effect of a $100 loss.22
C h a p t e r 6 . Tools of the Trade: Working with the Right Brain
It is believed that intuition can be developed by repeated exposure to the complexity of real problems.23 It is also helpful to develop
ways to access intuition more reliably. Here is a simple trick to do
so: flip a coin.
The coin flip sounds silly, but it is a powerful tool. If you are
faced with a tough, complicated decision, it can be easy to get paralyzed by the ambiguity because analytical techniques will go only so
far. While agonizing over the decision in the conscious mind, the
right brain is processing patterns in the background. The coin toss
trick is what enables us to access what intuition has to say.
The trick works like this: the result of the coin toss is used to
trigger a feeling at the outcome. Our job is to be attentive to the
feeling triggered immediately on the result; this is the intuitive, gut
reaction. If “heads” means that we complete the troubled project,
and “tails” means we terminate, what is our immediate reaction
when the coin lands? Do we feel relief when the coin lands on tails?
Do we feel renewed purpose if the coin lands on heads and the project is given a new lease on life?
Shortly after our third child was born, my wife and I started
looking for a new, larger house for our growing family. We fell in
love with a beautiful property on two and a half acres. It was a little
out of our price range, but we put in an offer and signed the contract.
We were elated at the prospect of moving into our dream house.
A few days later we did a walkthrough with an inspector. His
first words were, “The prior owners have been hard on this house.”
He went on to show us several major problem areas, including some
evidence of water damage on the ceiling. Our dream house suddenly
became one that needed nightmare repairs.
We had one week from signing the contract to back out of the
deal and lose only a small fee. After this time, we would pay a hefty
penalty for terminating the deal. This deadline approached only 24
hours after the news from the inspector. For 23 hours we agonized
over the decision but were unable to decide. With one hour to go, I
pulled a coin from my pocket ... heads we proceed, tails we back out
of the contract.
111
112
Right-Brain Project Management
Nervously, I flipped the coin—tails. I didn’t know what I felt.
I was so agitated over this decision that it was difficult to access
my feelings. To get past my paralyzed left brain, I knew I had to
keep trying. I flipped again—tails again, but still no direction. By
the third toss, and the third result of tails, I was starting to perceive
relief. I wanted to be sure, so I continued.
Eight flips, and eight straight times the coin landed on tails.
This was not a cosmic message telling me to quit the deal; a coin
flip has an equal likelihood of hitting heads or tails on any given
toss. But after eight flips, I strongly felt the answer. I experienced a
definitive sense of relief and calmness for what I came to know was
the right choice: terminate the contract.
After 23 hours of decision paralysis, within two minutes the
coin toss revealed the answer. While this technique often illuminates a direction on the first toss, for particularly tough situations, it
may take several attempts, as happened in this case.
The coin toss enables us to experience the feeling of different
outcomes of the decision. The coin toss is a trick, but it is merely a
trick to quickly bypass conscious thought and all its ruminations, to
access the valuable insights that intuition has to offer.
n Striking the Balance
As we close this brief look at a few of the tools for engaging the
right brain on projects, let us note that it is the partnership between
the right brain and the left brain that serves us most beneficially for
our complex projects. For insight on this balance, let us turn to the
individual who has been recognized as the greatest genius in the history of the world, Leonardo da Vinci.24
Da Vinci was both an outstanding artist and an outstanding scientist. In our specialized world, we see these personas separately.
But in the human brain, they are intimately related and feed upon
one another. Da Vinci was an outstanding scientist because he was
an outstanding artist, and vice versa. This is yet another manifestation of Kant’s outlook.
C h a p t e r 6 . Tools of the Trade: Working with the Right Brain
The tools of the right brain and the tools of the left brain are
complementary in purpose. Working together, they accomplish
amazing feats in project management. n
n Endnotes
1“Yesterday,” Rolling Stone, http://www.rollingstone.com/news/
story/6595858/yesterday. Accessed October 2006.
2Blake E. Ashforth and Ronald H. Humphrey, “Emotion in the Workplace:
A Reappraisal,” Human Relations, Vol. 48, No. 2, 2000, p. 97.
3Ibid., pp. 97–125.
4Jennifer M. George, “Emotions and Leadership: The Role of Emotional
Intelligence,” Human Relations, Vol. 53, No. 8, 2000, p. 1033.
5Daniel Goleman, Emotional Intelligence (New York: Bantam Books,
1994), p. 43.
6David Rosete and Joseph Ciarrochi, “Emotional Intelligence and Its Relationship to Workplace Performance Outcomes of Leadership Effectiveness,” Leadership and Organization Development Journal, Vol. 26, No.
5, 2005, pp. 388–399.
7William Leban and Carol Zulauf, “Linking Emotional Intelligence Abilities
and Transformational Leadership Styles,” Leadership and Organization
Development Journal, Vol. 25, No. 7, pp. 554–564.
8Jennifer M. George, “Emotions and Leadership: The Role of Emotional
Intelligence,” Human Relations, Vol. 53, No. 8, 2000, pp. 1027–1055.
9Blake E. Ashforth and Ronald H. Humphrey, “Emotion in the Workplace:
A Reappraisal,” Human Relations, Vol. 48, No. 2, 2000, pp. 97–125.
10 Edward de Bono, Serious Creativity (Toronto: Harper Collins, 1992).
11 Nick Lund, Attention and Pattern Recognition (London: Routledge, 2001),
p. 75.
12 American Heritage Dictionary of the English Language, Third Edition
(Boston: Houghton Mifflin), p. 1568.
13 Romeo and Juliet (II, ii, 43–44), The Complete Works of William Shakespeare, The Cambridge Edition Text, edited by William Aldis Wright (Garden City, NY: Garden City Books, 1936), p. 325.
14 David Rymer, “Powerful Storytelling: Rich Connections Between Leaders and
Generation Y,” Leadership Compass, Banff Centre, Summer 2006, p. 25.
15 Ibid.
113
114
Right-Brain Project Management
16 MindJet MindManager, http://www.mindjet.com. Accessed October 2006.
17 Roger N. Shepard, “Externalization of Mental Images and The Act of Creation,” Visual Learning, Thinking and Communication, edited by Bikkar
S. Randhawa and William E. Coffman (New York: Academic Press, 1978).
18 Marta Sinclair and Neal M. Ashkanasy, “Intuition: Myth or Decision-Making Tool?” Management Learning, Vol. 36, No. 3, 2005, p. 353.
19 Ibid., pp. 353–370.
20Naresh Khatri and H. Alvin Ng, “The Role of Intuition in Strategic Decision
Making,” Human Relations, Vol. 53, No. 1, pp. 57–86.
21 Hubert L. Dreyfus and Stuart E. Dreyfus, “Expertise in Real World Contexts,” Organization Studies, Vol. 26, No. 5, pp. 779–792.
22Kenneth L. Fisher, The Only Three Questions That Count (Hoboken, NJ:
John Wiley & Sons, 2006), p. 88.
23Naresh Khatri and H. Alvin Ng, “The Role of Intuition in Strategic Decision
Making,” Human Relations, Vol. 53, No. 1, pp. 57–86.
24Michael Gelb, How to Think Like Leonardo da Vinci (New York: Dell,
1998).
C h a pt e r
n Making
Simple
8
the Complex
n
n
n
Everything is simpler than you think and at the same time
more complex than you imagine.
J o h a n n W o l f ga n g v o n G o e t h e
n
W
hen my wife was in labor with our second child, things
were happening way too fast. Even though we were
hurrying to leave the house, she felt the need to push
and was certain the baby was ready to come out.
The situation clearly called for creative driving to get to the
hospital in time. I drove way over the speed limit and ran red lights.
We made it to the hospital with little time to spare; the nurse delivered our daughter in the exam room long before the doctor arrived.
Had I followed the rules of the road, I would have had the unique
experience of delivering the baby in the car.
The challenge of driving to the hospital was at the same time
very complex and very simple. The task was complex because the
car had a manual transmission and I needed to help my wife breathe
through contractions while she squeezed my hand (tightly). I had
to navigate safely while driving aggressively and keeping her calm
so she wouldn’t start pushing as her body wanted to do. I had to be
concurrently hyperalert for traffic and hyperinvolved with my wife.
This was a complex and unique project, and yet it was somehow simple. The objective was crystal clear, and it had to be
accomplished.
Sometimes, the only way to get something done is to break the
“rules”—in this case, the rules of the road.
130 Right-Brain Project Management
What thought processes come into play when we need to break
the rules? In our mad dash to the hospital, I did violate a number
of traffic laws, but in doing so, I tenaciously tried to follow guiding
principles that would maintain safety for those in our car and in
other cars. For example, I looked very carefully before proceeding
through the red lights.
In other words, there are rules, and then there are Rules.
The project management profession has been successful at
learning how to expertly manage a large number of projects—those
projects that are familiar, predictable, and even those that are major
endeavors.
But the profession has struggled to tame those projects that
embody the unfamiliar, the unpredictable, and the urgent. Conventional techniques cannot successfully handle aggressive and dynamic
needs in a volatile environment. We can either attempt to apply
existing rules more emphatically or we can better understand the
Rules behind the rules.
In this light, let us offer a fresh approach—not to discard what
works, but to augment it with a new perspective and new tools. In
exploring right-brain project management, we will not tear down
left-brain approaches, but will attempt to supplement them in areas
where they are limited. With this fresh approach, we will build
a partnership between right-brain and left-brain approaches to
develop powerful capabilities in managing projects.
We need to make the complex simple.
n Where Are We in Project
Management?
The main perspectives we have covered so far highlight the
needs of projects in contemporary organizations.
Perspective 1. The needs and characteristics of people and
groups are the most important ingredients of project management.
C h a p t e r 8 . Making the Complex Simple
To improve the practice of project management, it is helpful
to study and understand people, how they work and interact. This
view does not in any way discount the need for domain expertise or
the need to understand the tools of project management. Rather,
what is most relevant to the improvement of project performance is
individual and group performance.
Perspective 2. Projects struggle with uncertainty,
complexity, and pressure.
Conventional techniques excel at executing projects that deal
with the familiar using sufficient resources and an adequate schedule. These techniques fail in the face of uncertainty, complexity, and
pressure. To make significant improvements with such projects, we
need to understand and accommodate these typically challenging
forces. Projects need creative thought, experimentation, and sensemaking to respond adequately.
Perspective 3. Projects in organizations must achieve a reliable
and predictable standard of performance, even in the midst of
uncertainty and seemingly unreasonable expectations.
While project managers and their teams understandably complain about runaway scope changes, insufficient project resources,
and unrealistic schedules, these are the realities of the workplace in
which we operate. It is too late (if it was ever possible) to constrain
the world to fit project management methodologies. We must adapt
to the world as it is and work with it.
Numerous projects have overcome daunting challenges—
improbable deliverables, inexperienced teams, impossible schedules—and delivered the goods. What is it about a project that makes
it a phenomenal performer? The answer to this question forms the
principles of right-brain project management. These principles can
be applied (as appropriate) to help any project.
To understand how the right brain can improve project management, we must understand and address the issues of complexity
and uncertainty in projects.
131
132 Right-Brain Project Management
n Understanding Complexity
The descriptive term “complex” is often used to describe projects. Complexity implies a project that is challenging to manage
because of size, complicated interactions, or uncertainties. Often,
anxiety goes hand in hand with complexity.
Although complexity will ultimately mean different things to
different project managers, we can develop a framework for categorizing types of complexity. Doing so will help us better understand
and manage project complexity, which is a significant aspect of handling the problems that plague contemporary projects.
n Categories of Complexity
Complexity can be viewed in terms of two major dimensions:
structure and uncertainty.1
Structural complexity concerns the composition of the project
elements, in particular the number of elements and their interdependencies.2 For example, a major construction project with many
task dependencies is structurally complex. The concept of structural
complexity can also be applied to the project organization (e.g., how
many stakeholders are involved in decisions) and to the product or
technology (e.g., the integration of subassemblies in the product).
Many project managers believe that uncertainty also dramatically compounds the complexity of a project. While the concepts of
complexity and uncertainty are somewhat different, we can readily
see how uncertainty increases complexity.
As an example, consider a general contractor who builds both
custom homes and “spec” houses. A custom home is built to the
requirements of the owner while a spec house is built to the requirements of the builder, typically without having a buyer identified until
after the house is complete. The custom home building process is
considerably more complex because much is uncertain prior to and
even during construction. More exploration of options and costs,
more negotiation, and more rework are typically involved. The
C h a p t e r 8 . Making the Complex Simple
builder must schedule more coordination with the subcontractors
to ensure that specific features are incorporated. In contrast, the
builder controls all aspects of the spec house, so much less uncertainty—and therefore complexity—is involved.
It can be enlightening to quantify the overall level of uncertainty
for a project. Baccarini and Archer offer one method that specifies
23 dimensions of a project and provides scores for characteristics of
each dimension.3 For example, on the “Uniqueness of the Product,”
a score of 5 could be given to a project that includes a “Prototype
Incorporating New Techniques,” while a score of 1 could be given
to a project that is intended to deliver “One of a Series of Repetitions.” The higher the numerical score, the higher the uncertainty
on the project.
The aggregate score can provide an excellent representation of
the degree of uncertainty involved in the project. Such a tool can
greatly assist the project organization in scoring candidate projects
and adapting management styles accordingly.
n Adapting Management to
Complexity
When an organization faces a complex project, it is often
tempting to smooth over the complexity and manage the project
with conventional approaches. Uncertainties are not adequately
addressed and major issues are deferred in the hope that they will
resolve themselves. While known issues are problematic enough,
issues that are unknown or just under the surface can be crippling
for a project.
It is important to be clear and honest about the project’s level
of complexity, and then to apply a management approach that is
appropriate to the complexity.
Turner and Cochrane provide an excellent way to categorize
uncertainties on projects. They divide types of uncertainties into
two categories: goals and methods. The goals of a project are its
133
134 Right-Brain Project Management
objectives. The methods are the processes used to manage and execute the project.
Let us highlight one aspect of the uncertainties in methods. A
significant source of uncertainty, and one that may be somewhat hidden, is the uncertainty associated with team interactions, especially
for those teams that are distributed geographically or that include
members who are new to each other. Regardless of what process
may exist on paper, the progress of work for such teams is tenuous
until informal working relationships are established in practice.4
Uncertainties in both goals and methods have profound implications for projects. If project objectives are ambiguous, for example,
inconsistencies may be evident in the deliverables. Uncertainties in
methods can have a significant effect on the progress of a project.
For example, one team member may believe she has the authority to
make a decision unilaterally, while the project manager may believe
otherwise.
Turner and Cochrane categorize projects into four types, as
summarized in table 8-1.5
Conventional project management techniques and tools necessarily fit into the Type 1 project category. Once goals and methods become certain, a project enters the Type 1 category and can
be managed with conventional techniques. Until that certainty is
achieved, however, the management styles for each of these categories will be accordingly different at the start of the project.
Table 8-1. Classification of Projects according to Uncertainties in Goals
and Methods
n
Type 1
Type 2
Type 3
Type 4
Both goals and methods are well defined (construction project).
Goals are well defined, but methods are not (product development).
Goals are not well defined but methods are (software development).
Neither goals nor methods are well defined (R&D).
C h a p t e r 8 . Making the Complex Simple
Turner’s and Cochrane’s suggestions for project start-up are listed
in Table 8-2.6 The metaphor noted in parentheses for each option
represents a model for the project manager’s role in each case.
n Complexity and Uncertainty in
Organizations
In my first career position in industry, I worked for a division of
General Electric that was developing a new computer-based power
system product. (I worked elsewhere in the division and was not
on the project team.) In the early 1980s, this was a state-of-the-art
development, and many significant technical and market issues represented unknowns throughout much of the effort. Management
approached what was clearly a research project as a product design
project, focusing on schedule to market. The result was a train
wreck that caused the sponsor to fire the entire development team.
The project was finally completed four years late.
In one study, project managers “… rated the ability to handle
ambiguity as very important in the performance of their roles as
project managers.”7 While ambiguity creates stress, this stress is
more manageable than the stress that comes with trying to act like a
project is predictable when it is not.
Table 8-2. Start-up Focus for Projects as a Function of Uncertainties in
Goals and Methods
n
Type 1 Focus on refining the definition of goals and methods into detail
(conductor).
Type 2 Focus on defining the scope of work and process for the team (football
coach).
Type 3 Focus on defining objectives and purpose (sculptor).
Type 4 Must address both goals and methods, using creativity and inspiration.
The process is inevitably iterative and should be directed toward moving the project into either a Type 2 or Type 3 category (eagle).
135
136 Right-Brain Project Management
To a significant degree, project difficulties arise from the mismatch between project complexity and the management model
used. Conventional project management methodology is predicated
on a project being orderly and predictable. This approach is entirely
understandable: when the environment is complicated, it is natural
to want to make it orderly and predictable. This tendency is particularly evident in an organization where decision-making tends
toward safety and predictability.
Let’s look at this from a different perspective. An organization
is most often modeled as a system in the aggregate: it has inputs, it
performs functions on the inputs, and it produces outputs. From a
macro perspective, there is cause and effect. Everyone associated
with the organization wants the operation to be as understandable,
profitable, and predictable as possible.
In many organizations, predictability is preferred over enhancements that are unpredictable. Through a collection of risk management strategies, an organization seeks to minimize financial risks
that arise from the volatility of the environment; however, it is more
challenging to address an unpredictable internal process.
Organizations apply this overall philosophy naturally to projects and project management. We want to believe that disciplined
processes will convert a project’s complexity into something that can
be planned reliably.
While it is better to acknowledge the complexity of the project
and plan accordingly, it is much more common to gravitate toward
the rational management style espoused by Taylor:
Many managers continue to manage by using reductionist
approaches (separating things into parts); by devising complex
planning activities based on the notion of a predictable world; and
in believing that cause and effect processes produce fairly foreseeable results …. [A] considerable number of managers appear to
have a mindset similar to the Taylorist model developed at the
beginning of the last century.”8
C h a p t e r 8 . Making the Complex Simple
n Describing the Uncertain
It is certainly possible to plan for uncertainty even if our plans
cannot articulate definitively the outcomes of that uncertainty.
The key to this planning is to use the right approach, and the right
approach begins by accurately describing the uncertainty.
Let us consider three different classes or representations of
projects: orderly, chaotic, and complex. These classes of projects can
be considered representations of systems.
For a project, the cause-effect relationship is embodied in the
project plan. From a macro perspective, if we provide inputs to the
project in the form of resources, the execution of the plan will supposedly result in the intended output. The plan is the transfer function, or the cause-effect operator.
An orderly system has a well-defined cause-effect relationship. Input-output relationships are well understood and plans can
be formulated that rely on these relationships. In a chaotic system,
there is no cause-effect relationship. What happens is seemingly the
result of chance (or the cause-effect relationship is so tenuous that
it is unusable).
For complex systems, the cause-effect relationship is not initially
known, but it can be discovered. We can see the patterns of causality
with the benefit of hindsight. In such systems, order emerges, but it
may not be explicitly repeatable.9
An orderly project is one in which the process to complete the
objectives is familiar, the team process is understood and has been in
practice, and there are no significant risk issues, such as with technology or schedule. In other words, the process from start to finish
is known, understood, and logical. Such a project can be successfully
managed with conventional project management practices in a reliable and predictable manner. As an example, when an experienced
contractor pours a concrete sidewalk, the project can be considered
orderly.
137
138 Right-Brain Project Management
A chaotic project is one in which the environment is so unfamiliar and dynamic that it challenges the very notion of management.
A chaotic project may be a serious and unique crisis that suddenly
presents itself, such as the terrorist attacks of September 11, 2001.
Such events can only be addressed through immediate action to gain
some control over the chaos.
A complex project may involve an unproven technology, team
members who are unfamiliar with one another, an aggressive schedule, or other significant risks. At the initiation of such a project, one
cannot (and should not) attempt to state the cause-effect relationship of the project in the form of a reliable project plan. Yet that is
exactly what typically happens.
A far better “plan” is to begin by making sense of the complexity—by exploring what is uncertain, making it certain, and making
the transition from what is complex to what is orderly.
The crux of the difference between managing orderly projects
and managing complex projects is the difference between exploitation and exploration. If a cause-effect relationship is known and
reliable, it can be exploited. If the relationship is ambiguous or not
reliably known, the environment must first be explored to determine the relationship. Only then can it be exploited.
Certainly, projects fall along a continuum of orderly and complex characteristics. Along the continuum are projects for which
there is hidden order10 or for which a cause-effect relationship is at
first unknown but is discoverable. The management approach for
these projects is like that for complex projects, but planning is somewhat more predictable.
n Management Approaches
It is important to characterize a project’s type or level of order
and then apply an appropriate management approach. This is in
essence a macro or big-picture step that should be taken very early
in a project or as part of a project office.
C h a p t e r 8 . Making the Complex Simple
Table 8-3 summarizes the macro methods for managing the
various types of projects.11
n Risk versus Uncertainty
The terms “risk” and “uncertainty” are sometimes confused
when discussing the complex project.
In conventional approaches, risk management is a fundamental
and well-known element of project management. A risk has been
defined as “an uncertain event or condition that, if it occurs, has
a positive or negative effect on a project’s objectives.”12 In other
words, a risk is a potential future event that can affect the achievement of the project objectives—if it occurs. The concept of risk is an
important one to address and consider in a project plan, but it does
not quite address the landscape of the complex project.
In contrast, uncertainty is best understood not as a future possibility but as a present reality. For example, we are uncertain now
about the features the customer values for product X. Typically, for
a project to progress, we must take steps to reduce the uncertainties.
These steps are different from those commonly practiced to manage risk.
We might say that there is a risk (future) to achieving project
objectives if we do not resolve the uncertainty (present and ongoing
until resolved) in product features.
n
Table 8-3. Project Types and Corresponding Management Approaches
Project Type Characteristics
Management Approach
OrderlyProjects that are well defined
Conventional techniques
ComplexProjects that have uncertaintiesExplore to determine
relationships
ChaoticProjects that are completely novel Act quickly to bring the
and dynamic, or out of control situation under control
(e.g., crisis situation)
139
140 Right-Brain Project Management
In conventional approaches, it is implicitly assumed that all
(or nearly all) ambiguity is resolved before the project commences.
While straightforward choices may be made during the course of
the project, the stakeholders have resolved substantive questions
about objectives or methods prior to approving the project plan.
In real organizations, many projects begin with considerable
uncertainty in play. Recognizing this (possibly inevitable) situation,
teams need a framework and tools that enable them to successfully
navigate projects in this environment.
Management of uncertainty on a project is often mixed with
management of risk, but it is better to address the concepts separately. Risk management involves planning to accommodate future
events that may or may not happen. Uncertainty management is
the proactive effort to make sense of the project and reduce ambiguity in the present. Experience has shown that a key success factor for projects is the recognition and proactive management of
complexities.13
n Uncertainty Management
In conventional project management, uncertainty is often considered a synonym for variability. For example, in the planning stage,
when estimating task durations, we can account for the probabilities of variations in the estimates. For our purposes, we will assume
that existing tools are more than sufficient for managing issues of
variability.
A critical source of uncertainty on many contemporary projects
is better understood with the synonym ambiguity. While variability
can be somewhat challenging, ambiguity has the potential to have
significant impact on the project.
The techniques for managing this concept of uncertainty are
primarily about sense-making—skills that are considerably different
from skills for managing risk and managing variability.
C h a p t e r 8 . Making the Complex Simple
Uncertainty management “... implies exploring and understanding the origins of project uncertainty before seeking to manage it,
with no preconceptions about what is desirable or undesirable.”14
This is the essential meaning of sense-making.
n Making Sense of Complexity
In essence, sense-making is the process of coming to a common
understanding of the appropriate direction forward.
As an example, in a product development effort, there is a
common tension between the engineers and the marketers. The
engineers, if they are true to stereotype, want to include technical
elegance in the product and take their time in development. The
marketers want a lot of features and to get to market quickly. It is
critical that the leader of this effort help the team collectively make
sense of the product, preferably giving the customer’s needs priority. If sense is not made, team members inevitably pull in different
directions.
Sense-making is predominantly a right-brain activity: it requires
seeing and developing patterns where no clear patterns exist. However, it is not a shot in the dark because the team relies on the collective values and purpose that form the foundation for the effort.
This stage of the effort requires some experimentation to determine
patterns.
This is an entirely different approach to project management,
and one that is well-suited to the right brain.
n A Fresh Perspective
Conventional project management “… is supposedly a systemic
approach to management of change but its foundation lies in the
traditional rational managerialism thus facing an increasing threat
of irrelevance unless newer models are developed to respond to
change and complexity.”15
141
142 Right-Brain Project Management
The reality of projects in contemporary organizations demands,
and can benefit from, a fresh perspective. There is no argument
that conventional project management approaches are excellent for
managing projects that are well-defined. But complex and aggressive projects need a different framework and assumptions for progress to be made.
The framework and assumptions for complex projects are best
handled through the right brain. To move toward the principles that
form the foundation of right-brain project management, we will first
study the factors that contributed to the phenomenal performance
of five projects. n
n Endnotes
1T. M. Williams, “The Need for New Paradigms for Complex Projects,”
International Journal of Project Management, Vol. 17, No. 5, 1999, pp.
269–273.
2David Baccarini, “The Concept of Project Complexity—A Review,” International Journal of Project Management, Vol. 14, No. 4, 1996, pp. 201–204.
3David Baccarini and Richard Archer, “The Risk Ranking of Projects: A
Methodology,” International Journal of Project Management, Vol. 19,
No. 3, 2001, pp. 139–145.
4Stephen Ward and Chris Chapman, “Transforming Project Risk Management into Project Uncertainty Management,” International Journal of
Project Management, Vol. 21, No. 2, 2003, pp. 97–105.
5J. R. Turner and R. A. Cochrane, “Goals-and-Methods Matrix: Coping with
Projects with Ill Defined Goals and/or Methods of Achieving Them,” International Journal of Project Management, Vol. 11, No. 2, May 1993, pp.
93–102.
6Ibid.
7Jane Helm and Kaye Remington, “Effective Project Sponsorship—An
Evaluation of the Role of the Executive Sponsor in Complex Infrastructure
Projects by Senior Project Managers,” Project Management Journal, Vol.
36, No. 3, September 2005, p. 56.
8Elizabeth McMillan, Complexity, Organizations and Change (London:
Routledge, 2004), p. 56.
C h a p t e r 8 . Making the Complex Simple
9Dave Snowden, “Strategy in the Context of Uncertainty,” Handbook of
Business Strategy, Vol. 6, Issue 1, 2005, pp. 47–54.
10 Ibid.
11 Ibid.
12 A Guide to the Project Management Body of Knowledge, Third Edition
(Newtown Square, PA: Project Management Institute, 2004), p. 373.
13 Ali Jaafari, “Management of Risks, Uncertainties and Opportunities on
Projects: Time for a Fundamental Shift,” International Journal of Project
Management, Vol. 19, No. 2, 2001, pp. 89–101.
14 Stephen Ward and Chris Chapman, “Transforming Project Risk Management into Project Uncertainty Management,” International Journal of
Project Management, Vol. 21, No. 2, 2003, pp. 97–105.
15 Ali Jaafari, “Project Management in the Age of Complexity and Change,”
Project Management Journal, Vol. 34, No. 4, December 2003, p. 56.
143
C h a pt e r
1 8
n The
Hero in Us All:
The Moral of the Story
n
n
n
God created people because he likes a good story.
Elie Wiesel
n
I
didn’t learn to swim until I was 34 years old. I took a few lessons as a kid but got sick and missed the last half of the class.
No one pressed the issue after that, and I grew to be afraid of
the water. In college, one of my best friends drowned, and that only
solidified my fear. As an adult, I avoided swimming and boating.
As an avid runner in my twenties and thirties, I developed knee
trouble. The doctor told me to stop running and take up some other
form of exercise; he highly recommended swimming.
While learning to swim is a common childhood experience for
many people, for me it had become something larger. It was not a
skill, it was a nemesis; it was a fear that needed to be overcome.
At the age of 34, I enrolled in an adult learn-to-swim class. To
my amazement, I found other adults who were also H20-challenged.
Like everyone else who has ever learned to swim, I inhaled water
and glubbed and blubbed, and finally graduated.
In the following days and weeks, I felt pride, but I felt something more. Something had been released inside; my Lex Luthor
had been defeated. Other challenges in my daily life seemed less
daunting. I started sweeping away problems like they were so many
autumn leaves on the sidewalk. Perhaps even more surprisingly, my
project work became more successful and rewarding.
I started to swim often; I started to swim a lot. Soon I could
swim a kilometer, then a mile. I signed up for a program to swim
286 Right-Brain Project Management
100 miles over a school year, and completed every mile—every last
one of 7,000 laps in the pool.
Sure, I learned a basic skill, one that is easily learned by many
five-year olds. But something much more profound had happened.
A message was imprinted in my brain, an image that I have relied
upon ever since:
If I can learn to swim, I can do ______.
Learning to swim became an important metaphor for me to
draw upon for strength to face far greater challenges of work and
of life.
In all humility, the simple skill of learning to swim built character in me.
n Becoming Better at Projects
To become better at managing or executing projects, we could
take a left-brain approach or a right-brain approach. The left-brain
approach might include taking a conventional course toward earning a PMP® certification.
The right-brain approach could include developing skills in
the seven principles we have discussed in this book. The rightbrain approach could also include something a bit different and
unexpected.
I learned to swim and became a better project manager.
We can become better at projects by becoming better people, by
maturing in character. We can become better at projects by maturing in emotional intelligence and moral reasoning.
n Developing Maturity
Let us briefly recall two subjects from Chapter 2, the stages
of maturity and the elements of emotional intelligence. Table
C h a p t e r 1 8 . The Hero in us All: The Moral of the Story
18-1 provides a description of Loevinger’s four highest stages of ego
development, and Table 18-2 provides a summary of the five elements of emotional intelligence.
Important components of personal development include the
ability to tolerate ambiguity, as well as the development of moraln
Table 18-1. Loevinger’s Highest Stages of Ego Development
Stage
Characteristics
ConscientiousHas goals, ideals, and sense of responsibility; sees self apart
from group and internalizes rules; sees self from other point
of view; sees motives of others; guilt is from hurting another,
not breaking rules
Individualistic
Can become distant from role identities; greater tolerance of
self and others; recognizes that relationships bring dependency; psychological cause and effect; awareness of inner
conflict
AutonomousTolerates ambiguity; concern for emotional interdependence;
self-fulfillment; integrates ideas and identities
IntegratedTranscends conflicts; self-actualizing
n
Table 18-2. Goleman’s Five Elements of Emotional Intelligence
Knowing one’s emotionsThe ability to identify one’s emotions; to
understand links among emotions, thought,
and actions
Managing emotionsThe capacity to manage one’s emotions; to
control emotions or to shift undesirable emotions to more effective ones
Motivating oneselfThe ability to enter into emotional states by
choice; to summon emotions toward the
attainment of goals
Recognizing emotions in othersThe capability to empathize; to read, and be
sensitive to, other people’s emotions
Handling relationshipsThe ability to sustain satisfactory and beneficial
relationships; to lead and influence the emotions of others
287
288 Right-Brain Project Management
ity and decision-making skills. Maturing in emotional intelligence
improves a person’s ability to work with others.
Research and experience correlate project success with maturation in ego development and emotional intelligence. But how do we
go about growing in these areas?
The easy answer (well, easy to say but difficult to do) is to experience life and to respond well to it. We develop in character to a
significant degree when we encounter events and experiences that
test us and give us the opportunity to grow.
n The Moral of the Story
Contemporary projects need a high level of trust, and the foundation of trust is a sense of benevolent morality, or moral intelligence, among the team members. Our moral decisions demonstrate
more consideration for others on the team when the team members
feel a personal connection with each other. While “everyday” morality is largely automatic and quick, the process of moral reasoning is
more deliberate. Individuals exercise moral reasoning in considering decisions, but groups must also process moral reasoning. Thus,
it is important for leaders to have maturity in moral reasoning and
to be able to help their groups mature in it.
Lawrence Kohlberg has offered a model of moral development
in people. This model and its underlying theory hold that the basis
for ethical behavior is moral reasoning, which matures through six
developmental stages (see Table 18-3).1 Under Kohlberg’s theory, a
person progresses sequentially through these stages. When facing a
moral dilemma that is not resolved with the reasoning available at
the previous stage, he or she seeks the next higher stage.
The typical stage of moral reasoning for adolescents and adults
is the conventional level, consisting of stages 3 and 4. In these stages,
morality is judged and moral reasoning is carried out according to
societal views and expectations. In the post-conventional level, the
C h a p t e r 1 8 . The Hero in us All: The Moral of the Story
n
Table 18-3. Kohlberg’s Levels of Maturity of Moral Reasoning
Level
Stage
1 Pre-conventional
1
2
2 Conventional
3
4
3 Post-conventional 5
(autonomous or
principled)
6
Description
Obedience and punishment orientation
Self-interest orientation (what’s in it for me)
Interpersonal accord and conformity (good boy/
good girl attitude)
Maintenance of authority and social order (law and
order morality)
Social contract orientation, awareness of relativism
of personal values
Universal ethical principles, conscience guided by
principle (e.g., Golden Rule)
individual perspective can take precedence over what society considers right and wrong, and ethics becomes more situational than
absolute.
In stage 6, the highest stage, a person exhibits behavior because
it is right, not because society or a law says it is right. Few people
consistently use stage 6 moral reasoning.
In Pretty Woman the change in Edward included a development in morality. He was able to see Morse as a human being to be
respected rather than as a unit of monetary value.
This development in morality corresponds to the maturation
from Taylor to MacGregor and Ouchi, and from scientific management to Theory Z. It is the recognition that human beings are not
cogs in the machine—that we can do better projects together when
we share a belief in and respect for the value and dignity of people.
Upon reflection, the link between morality and project success
is clear and profound. Human beings are the ones who execute projects and whose emotions are inextricably tied to project success. A
moral compass that builds people will also make it possible for us to
carry out better projects together.
289
290 Right-Brain Project Management
n Character Is the Story
Navigating the complex project is often hard work. It is challenging both intellectually and emotionally. These challenges come
as tests to our limits, and these tests often stir internal conflict. We
may feel that our values, perceptions, and beliefs are subject to trial.
Successfully navigating these waters takes a certain degree of personal poise and self-assurance, perhaps even a degree of courage.
Sigmund Freud captured this view when he said, “I am not really
a man of science, I am not an observer, I am not an experimenter, I
am not even a thinker. I am nothing but an adventurer—a conquistador—with all the boldness and the tenacity of that type of being.”2
This conversation about personal development can be framed
as the building of character. It is really about the discovery and
growth of the hero in us all. A great way to study the development
of character is through a story.
In the movies and in literature, character development comes
about through conflict that occurs in the performance or in the
story. As noted by Lagos Egri in The Art of Dramatic Writing, “A
character stands revealed through conflict; conflict begins with a
decision .... No man ever lived who could remain the same through
a series of conflicts … of necessity he must change, and alter his
attitude toward life.”3
Conflict tests us; it causes us to reflect on our values, our moral
reasoning. Through a conflict, we have the opportunity to mature,
but the decision to do so is entirely voluntary. Regardless of external
conflict, it is internal conflict that spurs the development of character. In other words, character development starts with trouble!
The classic structure of a dramatic story has three components:
1.Point of departure
2.Conflict
3.Point of destination.
C h a p t e r 1 8 . The Hero in us All: The Moral of the Story
Of course, external and visible elements contribute to the point
of departure for the story. However, the true story—where conflict,
decisions, and character development play out—is internal.
In the story, we see the character get in trouble and face options
for how to address the trouble. The choices the character makes
reveal and build maturity or integrity. The character struggles with
the conflict, then makes a decision that causes him or her to grow
in maturity.
Character development is a fundamental construct of storytelling, whether in a novel, a movie, or even cartoons. Viewed in this
way, the story is a change process. The character is different at the
end than at the start, hopefully different in a better way.
In the story, the external challenge makes apparent the internal flaws or missing pieces of the character. Through conflict and
through paradox, the character chooses growth that corrects the
flaws and fills in the missing pieces.
The classic story line typically follows what is called a character
arc (see Table 18-4 and Figure 18-1).4 The journey around the character arc is a progression of stages and experiences through which
the individual’s growth is revealed.
We see character development in the great stories that humans
have told over the ages. These are the stories of humans making
good decisions and poor ones. They are stories that stretch from
Greek mythology all the way through The Terminator. They are stories of spiritual survival.
While spiritual survival can take many forms, its underlying
theme is universal. Great writers over the centuries have understood this, and so it is possible for Shakespeare’s “To be or not to
be” to convey a similar concept to a theatre patron in Elizabethan
England and to a middle manager in the anonymous hierarchy of a
major corporation. As Lewis Carroll said through the character of
The Duchess in Alice’s Adventures in Wonderland, “Everything’s got a
moral if you can only find it.”
291
292 Right-Brain Project Management
n
Table 18-4. Steps in the Character Arc
1 Limited awareness of a challenge, problem, or flaw
2 Increased awareness of a challenge, problem, or flaw
3Reluctance to change
4 Overcoming reluctance
5 Committing to change
6 Initial experimentation with change
7Preparing for significant change
8Attempting significant change
9 Consequences of the attempt (improvements and setbacks)
10Rededication to change
11 Final attempt at significant change
12 Final mastery of the challenge, problem, or flaw
Many of the universal human stories were handed down as
myths centuries ago, but because the myths are timeless, they operate just as well in our modern technological world as they did in
Ancient Greece. The Greeks had their heroes and their stories of
good versus evil. We have the same in Star Wars and The Matrix.
Character development is evident even in comedies, from The Three
Stooges to Seinfeld.
Perhaps the most universal story is the hero story. In its dramatic versions, it involves great quests and dramatic victories. But
there are more mundane versions of the hero story, and they deal
just as much with internal conquests as external ones. These are
stories from everyday life where we choose better paths.
Mastery of the complex, contemporary project is just as much
the choice to overcome self-limiting perspectives as it is the solution
of challenging project content and process issues.
Increased awareness
Reluctance
Committing
Overcoming
Experimenting
Preparing
Attempting significant change
Consequences
Mastery
Final attempt
Rededication
Figure 18-1. Character Arc: Journey to Overcome a Challenge, Problem, or Flaw
Limited awareness
n
C h a p t e r 1 8 . The Hero in us All: The Moral of the Story
293
294 Right-Brain Project Management
n The Project Builds Character
If we choose to see the project as Frederick Taylor might have,
then a project team consists of workers who efficiently follow a script
and crank out what the script tells them to do. They may be motivated enough, but they are not emotionally invested in the project.
At the end of the project, they are no different than at the start.
Here is an alternative way to view the project.
In a manner similar to the story, we can see that the journey
through the project, especially the complex, contemporary project,
encounters conflicts and paradoxes. This journey presents opportunities for decisions and for growth through the development of
character and maturity.
What if we see a project as more than lines of code, the assembly of silicon chips, or the printing of a document? What if we see
what is hidden in the project, the external and internal challenges to
be overcome?
What if the project has a plot that describes a story of spiritual
survival? This kind of project presents the opportunity for us to
grow, to mature, and to develop. It engages the right brain in a powerful and profound way.
n Becoming Better at Projects
Conventional wisdom holds that the way to get better at managing projects is to improve in project management skills—to become
better at the skills of planning, estimating, making work breakdown
structures, and the like. The recommendation is to become more
mature, but in the context of domain skills.
We fully concur with the development of project management
maturity, but do not want to stop there. What about the value of
becoming more mature in the skills of life? Evidence shows a definitive link between our ability to manage projects successfully and our
C h a p t e r 1 8 . The Hero in us All: The Moral of the Story
level of maturity in life—not in chronological age, but in our progression through the stages of personal and emotional maturity.
Mohandas Ghandi said, “As human beings, our greatness lies
not so much in being able to remake the world … as in being able
to remake ourselves.”
Improving at managing projects is as much about character
development as it is about skill. While the character development
needed encompasses many dimensions of personal and moral maturity, it is just as much a skill in adapting to the changing landscape
of the project workplace.5
The complex project is the story; it may even be a heroic story.
It is the story of taming the uncertain and ambiguous into something useful and predictable. It is the exploration of the Wild West,
the landing on the moon, the discovery of penicillin.
It is unlikely that any of us will have the opportunity to slay a
dragon. The technology has not yet been developed for someone to
have a light saber fight with Darth Vader. Our characters and journeys
involve more mundane issues like deliverables and difficult clients.
But the internal issues are universal. They involve themes such
as the courage to overcome fear, the choice of right over wrong, and
the decision to trust.
The complex project environment offers many opportunities
for development and maturity. We just need to look for them.
n It’s Child’s Play
All this talk about conflict, maturity, character development,
and morality may sound a bit heavy, inaccessible, and not worth the
trouble. On the contrary, and in keeping with the paradoxical nature
of the topic, it is just as much the work of children as it is of adults.
We can cite dramatic examples of stories from Romeo and Juliet
and The Odyssey, but we can just as easily use examples from many
295
296 Right-Brain Project Management
children’s stories and movies. Themes of character development,
moral choices, and spiritual survival in Beauty and the Beast, The
Lion King, and The Mighty Ducks are just as relevant to the project
manager.
The story and storytelling have meaning throughout life from
childhood all the way through adulthood. They apply on the playground, in the home, and in the workplace.
In the movie, School of Rock, Jack Black plays Dewey Finn, a
rock musician who suffers for his craft. Needing money, he sets his
sights on winning the cash prize at a battle of the bands. But there is
one problem: his band members fire him because he is so musically
maniacal. To pay the rent, he masquerades as a substitute teacher at
a stuffy private school and goes through the motions. That is, until
he hears the 10-year-olds play in the classical music class. The crazy
idea comes to him to turn these little Mozarts into a rock band and
win the prize.
We could stop right there and highlight two relevant rightbrain project management points. Initially, Dewey’s interest in this
job is to collect a paycheck, but he becomes consumed when he
sees an outlet for his passion. We can also recognize this clever act
of project bricolage: with no band to take him, Dewey turns to the
only musicians around. But let us look to a third project management component, the hidden project.
Whatever the visible work, the hidden project goes straight to
the human element. The hidden project may have a variety of human
themes: the thrill of teamwork, a rewarding growth in confidence,
the pride of a new skill, or the achievement of greatness. It is often
nothing less than a hero story about overcoming a formidable challenge. The hidden project may be different for each of the actors on
the project, but it often involves personal development, emotional
connection with others, and the human touch.
Many contemporary projects test us and stretch our limits, and
in the process they can cause considerable self-doubt. These hidden project doubts threaten the accomplishment of the visible project. The reserved and geeky keyboard player Lawrence approaches
C h a p t e r 1 8 . The Hero in us All: The Moral of the Story
Dewey with his self-doubts about being in the band: “I’m not cool
enough. People in bands are cool. I’m not cool.” Lawrence believes
this because no one ever talks to him.
When the emotionally intelligent project manager hears these
words, he or she drops everything and attends to this task that has
suddenly appeared on the critical path: the task to find the way
through the self-doubt. Dewey tells Lawrence that after he performs in the band he will be one of the most popular kids in school.
We see Lawrence smile.
The hidden project is classically right-brain and serendipitous,
so it is the sort of thing that can’t be planned in any detail. But it is
always there. We need only to look out for it, make sense of it, and
be ready to nurture it.
Dewey and the band do not achieve the planned project; another
group wins the battle of the bands. But they do accomplish the right
project. Despite Dewey’s initial disdain for kids and teaching, he
grows into a wise, albeit unorthodox, mentor. The more dramatic
hidden projects involve the kids and their parents. The formerly stifled, straight-laced kids become respectable rockers, and their passion and self-confidence soar through their new, cool talents. The
parents learn to loosen their domineering control and, with pride,
let the kids blossom.
THE PROJECT CHALLENGE
Colin Funk
On many projects we reach the “project challenge,” a particular issue
unique to the project that requires an uncomfortable stretch or full
immersion into the project. Successful progress or completion of the
project requires something more of me, or requires that I invest myself
in the project in a personal way. It is really a “tipping point”—a shift
from a purely cognitive response to one that is often more on the
emotional and intuitive scale.
In managing projects when I reach such a point, I definitely get a sense
of cognitive dissonance. The space is pure paradox: it is at the same
297
298 Right-Brain Project Management
time both frightening and soul-enriching. It is a place that typically
requires creative thought to navigate through a relatively uncomfortable space. While it can be tempting to back away and find a more
comfortable or familiar path, I know that I must proceed through.
How do we get through the project challenge? I get through by becoming present to the challenge and by actively looking and waiting for the
tipping point.
I find it very helpful to draw upon my experience in the theatre.
As actors, we spend a great deal of our time in training, working
on enhancing our ability to quickly transform into various character
types. This takes considerable skill and practice, and is very much a
whole-brain process. This state of invoking the imagination to become
something other than yourself can be accessed in part through various mental exercises that help focus us on becoming the role, or in
this case, becoming present to a challenge. This process allows us to
break through prior limitations and restrictions and enter a new state
with new possibilities. We can then truly see the problem challenge
through another person’s eyes. It is a very creative place to be and one
that is rich with promise for solving problems.
As an example, in one recent project, our organization committed to
expand the areas used for our classes in leadership development. As
one might expect for a leadership course, it is very important that the
environment contribute to the learning experience. Being situated in
Banff National Park, we have a truly special environment and it is an
integral element of our path of leadership development.
My particular project challenge was to obtain approval from executive
management for the project. An executive in any organization gets
many requests for new proposals, so there is always competition for
projects. I wanted to differentiate my request and demonstrate our
special vision for the leaders in our program, but I was uncertain how
to do this. I could send a standard memo with an outline of my proposal, but I wanted to do something more. My project challenge was
to describe the vision and benefits in a way that would engage the
executives personally in the project.
C h a p t e r 1 8 . The Hero in us All: The Moral of the Story
After struggling for a bit, I decided to become present to the challenge
and the tipping point. I went to the proposed new space and tried
to experience it as it would ultimately be, to see and touch what the
participants and presenters would soon see and touch. Even more, I
wanted to experience the emotions that they would soon experience
in this place. This was a bit of daydreaming, but it worked—I became
part of the finished product.
As I did this, I passed through the tipping point and my own enthusiasm
for the project grew dramatically. I could now convey my experience in
words and pictures so that the executives would understand and appreciate the final product and grow in their own excitement for it.
By using more of a right-brain approach—visual images, being present,
and experiencing the emotions of future participants—I could communicate the rich information that the decision-makers needed. I encountered the project challenge, navigated the tipping point, and used my
right brain to succeed on a project.
Colin Funk is the Creative Programming Director for Leadership Development at the Banff Centre, located in Banff, Alberta, Canada. The Banff Centre
offers courses in leadership development for individuals from all types of
organizations, including many project managers.
n Common Thread: Repairing the
Disconnect
Our journey to follow many of the threads of contemporary project management has led us back to Descartes and the rise of rational,
reductionist thought. Our objective has been to retrace and examine
the steps that got us here. Descartes was not the first to place value on
rational thought, but he did elevate it to an unprecedented level. Descartes’ philosophy also introduced a disconnect: prevailing thought
recognized the integration of the rational mind with the whole person, while Descartes saw the rational mind as a separate and controlling mechanism of the person. It is this disconnect that is in need of
repair for success with the contemporary project.
299
300 Right-Brain Project Management
In Chapter 3, we introduced Antonio Damasio, the physician
who has studied the role of emotion in decision-making. Dr. Damasio wrote a book with the compelling title, Descartes’ Error: Emotion,
Reason and the Human Brain. While we have much to thank Descartes for, we now understand that his “error” was an imbalance or
a disconnect.
Take the famous Descartes quote, “I think, therefore I am.”
As Damasio points out, this quote sums up Descartes’ rationalist,
reductionist philosophy. It holds that we can disconnect the rest of
human experience from the left brain.6 We have come to discover
that in project work, we cannot separate the left brain from the right
brain. Adaptation kicks in where planning leaves off, emotion fuels
the drive to achieve objectives, and character is just as necessary as
the Gantt chart. We cannot separate project work from who we are
and what we experience as human beings. Pulling on the thread that
leads to Descartes makes it clear that we need to understand and
apply Kant.
What is wrong with project management as it is commonly
practiced is not that it takes a left-brain approach. Rather, it is that
project management relies on the left brain to the exclusion of the
right brain. This is the disconnect.
What is needed on contemporary projects is an integration of
left- and right-brain principles. Because the practice of contemporary project management relies so heavily on left-brain skills, we
have focused on developing right-brain skills, but always with the
understanding that an appropriate balance is optimal.
This concept in project management is similar to that of cross
training in sports. Many athletes who train intensely for one sport
or one activity have found that such training leaves them at a disadvantage and vulnerable to injury. A football player who only builds
muscle bulk can often be easily knocked over because he has weak
core muscles and poor balance. In recent years, emphasis has shifted
to conditioning athletes in a variety of ways to ensure balance, flexibility, and resilience. When you see football players practicing yoga,
you know that sports has already seen the disconnect in its domain
and is taking steps to readjust.
C h a p t e r 1 8 . The Hero in us All: The Moral of the Story
To improve the management of contemporary projects, we must
repair this disconnect between left- and right-brain styles, recognizing that in addition to a brain that can analyze and plan projects, we
also have a brain that can create, feel, make sense, visualize, motivate, improvise, and communicate in alternative ways.
It is a paradox that we have separate right and left brains but
they still form an integrated whole. We must embrace the paradox.
n Embracing the Paradox
When we encounter paradox, we often experience conflict, both
internal and external. The ability to tolerate and embrace paradox is
one of the skills that is so important to personal maturity as well as
to maturity as a project manager.
Paradox is persistent on the contemporary project. It is present
in the interplay between the external, visible project and the hidden,
internal project. It is there when we say that complex projects need
both structure and improvisation. The most critical paradox we
need to embrace is that the contemporary, complex project needs to
be approached with both the right brain and the left brain.
To really engage and apply the right brain on a project, think of
it this way: a project is as much about who we become as it is about
what we do. Embracing this paradox is what moves us through the
changes needed to master the complex project.
n The Project Is the Story
Taylor would see project work as the activity of cogs working
through a machine. Taylor has fallen out of favor because his treatment and his attitude toward humans was ... well, inhuman.
We now know that project work is an act of creation accomplished by thinking, feeling, creative, motivated, intuitive, emotional beings. It is:
301
302 Right-Brain Project Management
•
•
•
•
•
•
•
Discovering fire
Solving a mystery
Experimenting in the lab
Painting without numbers
Doing business with a handshake
Performing in the jazz ensemble
Leaving a legacy.
Through it all, we face challenges, and with them opportunities
to stretch beyond boundaries and work with others to accomplish
something special. Perhaps this is what most makes a project a rightbrain endeavor. When we choose to break through our limits, we
must summon emotional energy and we must create new patterns
of thinking. On the contemporary project, we ourselves change as
much as (or even more than) what we create through the project.
It is no less than leadership of our selves. “Ultimately, the driving
force of new leadership is the process of destroying one’s own mindset
to build a completely new picture.”7
The German philosopher Hegel said that contradiction is the
power that moves things. When we encounter paradox on projects,
when we enter the conflict and become part of the process of character development into maturity, we find the power to move the
things that make projects what they are.
It all makes for a good story.
In the typical style of the paradox, we have reached the end of
our journey together, but it is early in your journey of right-brain
project management.
What we call the beginning is often the end.
And to make an end is to make a beginning.
The end is where we start from.
—T. S. Eliot, Four Quadrants, 1943
C h a p t e r 1 8 . The Hero in us All: The Moral of the Story
Picture yourself as a jazz musician on stage during a performance. The ensemble has set up the structure of the song. It is now
time for your solo; it is your turn to improvise.
The spotlight turns to you. Have at it! n
n Endnotes
1Lawrence Kohlberg, Essays on Moral Development, Vol. 1: The
­Philosophy of Moral Development (San Francisco: Harper & Row, 1981),
pp. 17–19.
2E. Jones, Sigmund Freud, Life and Work (London: Hogarth Press, 1955).
3Lajos Egri, The Art of Dramatic Writing (Boston: The Writer, Inc., 1960),
pp. 60–61.
4Christopher Vogler, The Writer’s Journey, Second Edition (Studio City, CA:
Michael Wiese Productions, 1998), pp. 212–213.
5Jason Hughes, “Bringing Emotion to Work: Emotional Intelligence,
Employee Resistance and the Reinvention of Character,” Work, Employment and Society, Vol. 19, No. 3, 2005, p. 620.
6Antonio Damasio, Descartes’ Error (New York: Putnam, 1994), pp.
248–252.
7Bastiaan Heemsbergen, The Leader’s Brain (Victoria, BC, Canada: Trafford Publishing, 2004), p. 64.
303
Project Decisions
The Art and Science
Lev Virine
n Michael Trumper
n
8230 Leesburg Pike, Suite 800
Vienna, VA 22182
(703) 790-9595
Fax: (703) 790-1371
www.managementconcepts.com
Copyright © 2008 by Management Concepts, Inc.
All rights reserved. No part of this book may be reproduced or utilized
in any form or by any means, electronic or mechanical, including
photocopying, recording, or by an information storage and retrieval
system, without permission in writing from the publisher, except for
brief quotations in review articles.
Printed in the United States of America
10 9 8 7 6 5 4 3 2 1
Library of Congress Cataloging-in-Publication Data
Virine, Lev, 1964–
Project decisions : the art and science / Lev Virine, Michael Trumper.
p. cm.
Includes bibliographical references and index.
ISBN-13: 978-1-56726-217-9
1. Project management—Decision making. 2. Project management.
3. Decision making. I. Trumper, Michael, 1963– II. Title.
HD69.P75V568 2008
658.4'04—dc22
2007024670
Part 1
Introduction to Project
Decision Analysis
Chapter 1
Project Decision Analysis:
What Is It?
M
ost of us believe we are pretty good at making decisions, yet we continue to make poor ones. And over time our poor decisions become a
burden that we impose on each other, especially when the decisions
we make as managers are connected to large-scale projects that affect many
people. The process known as structured decision analysis—which is described
in detail in this book—can improve our ability to make better decisions, particularly in project management, where the decisions can be complex. Indeed,
today many organizations in both the public and private sectors use decision
analysis to solve their project management problems.
The Burden of Poor Decision-making
In 2004–2005, Governor Arnold Schwarzenegger of California was involved in a complex decision-making process. He was not considering a role for his next action movie,
nor was he selecting a new energy weapon to blast villains in a sci-fi movie. This was
something more serious: the governor involved himself in the design process for a new
bridge in San Francisco (Cabanatuan 2005).
This was not just any bridge. The $6.3 billion project (Figure 1.1) was to replace
the existing Bay Bridge. The original plans called for the section of the bridge east of
Yerba Buena Island to include a huge suspension span. Although the construction of
the foundations for the suspension span had started a few years earlier, the governor’s
office insisted that a simple viaduct would be cheaper and faster to build. Transportation officials did not agree, believing that a design change from a suspension span to
a viaduct would slow construction.
Early in 2005 the governor’s side appeared to
have prevailed: work on the foundation was
halted, and the contract was terminated. A few
months later, however, following a detailed analysis, both sides agreed to follow the original design,
which included the suspension span. In the end,
the fight over the bridge design cost $81 million
Wrong decisions are a
burden that we impose on
each other.
4
Project Decisions: The Art and Science
Figure 1.1 The New Bay Bridge
to stop and restart work on the foundations for the tower that will support the suspension span. State funds and increased toll revenue (tolls were raised to $4) from
state-owned bridges would cover the burden of the cost overrun from the governor’s
costly decision to delay the project.
If you don’t live in northern California, you may not be directly affected by
the Bay Bridge cost overrun. But, directly or indirectly, at some time you will
pay for somebody’s wrong decision regardless of where you live or what you
do. This is because, for example:
n
n
n
n
Costs related to problems in developing new drugs are passed on to
consumers in the form of higher prices for medications.
Dry wells lead to increased costs for oil and gas exploration and production, leading in turn to higher prices at the gas pump.
Governments sometimes implement ill-considered policies that can
adversely affect taxes.
You sometimes make wrong decisions yourself. The cheap brand of
deck coat that you used to save a couple of dollars is already peeling
off and you will have to paint your deck again next year (hopefully
with a better brand).
Project Decision Analysis: What Is It?
Problems result from poor decision-making, whether the decision-maker is
the manager at the pharmaceutical company, the geologist making a poor
choice of where to drill for oil, the ineffective government bureaucrat or legislator making policy for the wrong reasons, or even you trying to save a few
bucks by buying a low-priced deck coat.
We human beings have been making poor decisions since we first developed
the ability—and the necessity—to make choices. In the modern world, however, due to the complexity and cost of projects, the price we pay for poor
decisions has significantly increased. The overall cost of wrong decisions is
very hard to estimate, but it is undoubtedly enormous. Say, for example, we
design a multibillon-dollar oil pipeline but make a wrong decision about running it through a particular location. Then we have to move it—a step that
might increase the project costs by millions of dollars. Who pays that cost? It
is passed on to somebody—investors, consumers, or the government.
Poor decision-making in the medical field can have expensive, even fatal,
results. The causes of medical mistakes differ. Sometimes the cause is a flaw
in a hospital procedure. Most medical mistakes, however, are related to errors
in human judgment.
Annually, 44,000 to 98,000 deaths occur due to medical errors (Kohn, Corrigan, and Donaldson 2000). That number would represent approximately 1.8
to 4.0 percent of the 2.4 million deaths that the Centers for Disease Control
(CDC) reported in 1999. As a point of comparison for other causes of death,
the CDC also reported that in 1999 there were 68,399 deaths from diabetes,
63,730 from influenza and pneumonia, and 44,536 from Alzheimer’s disease.
A 2004 study (Adams 2004) put the number much higher, at 195,000 people
killed each year in U.S. hospitals due to medical errors.
Similar figures on the impact of poor decision-making are available from the
oil industry (Rose 2001). An exploratory well drilled some distance from an
existing field is called a wildcat. A wildcat chance represents the ratio of oil and
gas discoveries to wildcats (Table 1.1).
Exploratory drilling is always a risky business. Nevertheless, the wildcat
chance can be improved by making better decisions: for example, by avoiding
an incorrect interpretation of geological data, which was the primary source of
dry holes in more than 40 percent of cases (Rose 2001). Even a slight improvement in the process of deciding where to drill wildcats would have significant
economic benefits because drilling a well can cost millions of dollars.
5
6
Project Decisions: The Art and Science
Wildcats Drilled
Discoveries
1960s
12,250
2,955
1970s
13,864
3,734
1980s
19,297
5,117
1990–1999
15,842
3,794
Wildcat Chance
24%
27%
26%
24%
Table 1.1 Global Discoveries (excludes U.S. and Canada)
Why Do We Make Wrong Decisions?
Lawrence Phillips, a prominent decision analysis expert, cites a curious
paradox: Although the ability to make right decisions is considered a main
indicator of project-management professionalism, many project managers
are unwilling to try to improve the quality of their decisions (Goodwin and
Wright 2004). Phillips suggests that many people consider decision-making
to be merely an automatic process, as natural as breathing. And if we don’t
need to learn how to breathe, why do we need to learn how to make better
decisions? With such a blasé attitude, many project managers don’t make the
effort to understand decision analysis, or they believe that it is just a theoretical discipline with no practical use in their work.
If you were asked to rate your decision-making ability, most likely you would
rate yourself as “better than average.” The “better-than-average effect,” where
people tend to rate themselves as above average when asked to characterize
their abilities, is a common psychological bias (Massey, Robinson and Kaniel
2006) that is applicable not only to self-assessments of decision-making but
also to other activities. But if we believe that we are such good decision-makers, why do we often make poor ones?
The answer resides in the fact that most of today’s important project-management decisions are complex. Without proper analysis it is hard to make
choices between alternatives. Every day, project managers make numerous
decisions. Most of them are trivial and do not require sophisticated analysis.
If a component for your construction project is delayed, you might decide to
call the supplier. Obviously, in making this choice, you can rely on common
sense. You do not need to perform an advanced analysis, solve a few differential equations, or run a complex simulation model. But if you need to select
a new supplier, the situation is quite different. A great deal is at stake, and a
wrong decision could be very costly. Plus, there are many alternatives. Now,
Project Decision Analysis: What Is It?
relying solely on your intuition may not be enough; you probably should
perform a decision analysis.
Why is decision-making so complicated? There are a number of reasons:
n
n
n
n
Most problems in project management involve multiple objectives
(Goodwin and Wright 2004). An example of a project with multiple
conflicting objectives is General Motors’s EV1 electric-car program.
The car was introduced in 1997 to demonstrate GM’s corporate commitment to a clean environment and at the same time show the commercial viability of the technology (GM 2006). But GM pulled the plug
on the project in 2002, citing insufficient public support. The automaker
eventually collected and destroyed almost all of the 1,000 EV1 cars,
prompting the making of a documentary titled Who Killed the Electric
Car? The film was widely praised by environmentalists and others concerned about growing CO2 emissions and the country’s dependence on
oil. Later, GM Chief Executive Rick Wagoner admitted that killing the $1
billion EV1 program was his worst decision: Although it did not affect
GM’s profitability, it did hurt the company’s image.
Project managers deal with uncertainties. Predicting the future is not
an easy task. Selecting alternatives is the primary objective of decision
analysis. Decision analysis offers tools to help project managers deal
with uncertainties.
Project management problems can be complex. The number of alternatives you face in managing a project can be significant. Decisions are
usually made sequentially, based on previous decisions. But understanding how each decision will affect subsequent ones is difficult.
Most projects include multiple stakeholders. Project managers deal
with clients, project team members, project sponsors, and subcontractors, among others. All these stakeholders have different objectives
and preferences.
Approaches to Decision-making
In general, there are three approaches to decision-making. They are not delineated by any strict boundaries, but it is helpful to classify them to understand
how we make decisions.
1. The intuitive approach. A project manager is sitting in an office (or
cubicle) thinking about a decision that has to be made. After a few
vacant stares out the window and several laps around the office, the
7
8
Project Decisions: The Art and Science
manager finally feels comfortable with the alternatives and chooses
one that “feels” best. The manager may not have all the information
needed to make the decision, but intuitively he or she thinks that it
is the right way to go. Is it a good decision? It may be. Often, however, nobody knows the truth because the results are rarely reviewed.
Sometimes these types of “felt” decisions are made by groups, but that
does not change their intuitive nature.
2. The advocacy-based approach. This is the most common way that
decisions are made in organizations. The project manager states the
problem and asks team members to perform an evaluation. But, as in
the case with the intuitive approach, everything ultimately depends
on the manager’s gut feeling. If the manager agrees with the evaluation, he or she will take it and make a decision. Otherwise, the manager will request that the team rework the evaluation (Skinner 1999).
3. The decision analysis approach. Under the decision analysis process,
choices are made based more on the results of analysis and less on the
intuition of the decision maker. The decision analysis approach entails
a logical analysis of a correctly structured problem, identification of
creative alternatives based on reliable information, implementation of
the selected alternative, and an evaluation of the results.
Decision Analysis As a Process
Having explained what decision analysis encompasses, we must still ask:
What is it? First of all, decision analysis is a tool to solve problems. It is a
practical framework of methods and tools to promote creativity and help people make
better decisions (Keeney 1982).
As a project manager, you don’t need to know all the details about these methods and tools, some of which can be very complicated. It is important, however,
that you know two basic things that affect how decisions are made:
n
We are all subject to common psychological pitfalls. People come
hardwired with some psychological constructs that can mislead them
when they make project decisions. If you are estimating projects costs,
identifying possible risks, selecting viable alternatives, or identifying
the most important project objectives, you can make predictable mental mistakes. A basic knowledge of these pitfalls and how they can
affect decision-making will help you avoid them.
Project Decision Analysis: What Is It?
n
We can use decision analysis techniques to avoid those pitfalls. These
techniques will improve your ability to make better decisions. Moreover, most of these techniques can be applied in other areas of practice,
such as financial analysis.
What you really need to know in general is that project decision analysis is
a scalable and flexible process that is both practical and effective. And it is
important to understand that decision analysis is not a process that creates an
additional level of bureaucracy. It can be integrated into other processes that
are defined in the PMBOK ® Guide (Project Management Institute 2004). We
recommend that you begin to establish this process by improving your own
thinking processes rather than setting it up at the organizational level.
The process includes four major phases (which are discussed in the following
parts of this book):
1. Decision framing, or structuring the problem (Part 2)
2. Modeling the alternatives (Part 3)
3. Quantitative analysis (Part 4)
4. Implementation, monitoring, and review of the decisions (Part 5).
Each phase of the process involves several steps, which will be presented in
our discussion of each phase.
Often, project managers believe that decision analysis is a type of cost-benefit
analysis. Cost-benefit analysis is a technique used to compare the various
costs associated with a project with the benefits that it supposed to return.
In comparison, decision analysis is a much broader process that takes into
account many parameters and uncertainties. It focuses on developing a more
complete analysis of a project and understanding the ramifications of the possible choices facing a project manager.
Normative and Descriptive Decision Theory
The foundation of decision analysis is decision theory, which is the study of
how to make better choices when faced with uncertainties. Normative decision theory describes how people should make decisions; descriptive decision
theory describes how people actually make decisions.
To distinguish between the normative and the descriptive approaches, let’s
look at decisions related to recovering a hidden treasure. The movie “National
9
10
Project Decisions: The Art and Science
Treasure,” starring Nicolas Cage, follows a team of treasure hunters as they
methodically and logically unravel a series of extremely convoluted clues.
This is an example of normative decision theory because it shows how people
should behave if they want to recover a treasure. Stanley Kramer’s movie It’s
a Mad, Mad, Mad World (1963) is an example of descriptive decision theory,
for it shows how people actually behave when they try to recover a treasure.
In trying to find the treasure, instead of acting logically, the characters behave
spontaneously and irrationally. Chaos and hilarity ensue, but no treasure is
found.
Driving Forces behind Project Decision Analysis
Realizing that poor decision-making in large-scale projects can result in high
costs and cause harm, governments and private businesses are recognizing
the importance of instituting decision analysis techniques.
The U.S. Government Performance Results Act of 1993 states that “waste and
inefficiency in Federal programs undermine the confidence of the American
people in the Government and reduce the Federal Government’s ability to
address adequately vital public needs.” The first stated purpose of the act is
to “improve the confidence of the American people in the capability of the
Federal Government, by systematically holding Federal agencies accountable
for achieving program results.”
The act mandates that all major decisions made by government agencies be
properly justified in the public interest. One of the main outcomes of the act
is that there is a much wider adoption of decision analysis and risk management in government organizations.
Private companies also understand the importance of decision analysis to justify their decisions. It is not enough for a company’s management to report to
shareholders and Wall Street analysts that the company just spent X million
dollars on research and development and Y million on capital projects. Investors need to see assurances that money was spent wisely. Therefore, many
companies have started to establish structured decision analysis processes.
Many organizations use decision support tools such as Enterprise Resource
Management or Project Portfolio Management systems to improve their efficiencies. Six Sigma is a proven methodology to improve decision-making
related to quality. One of the main areas of improvement, especially in the
area of new product development, is the ability to successfully select which
projects should go forward.
Project Decision Analysis: What Is It?
Government regulations and pressure from investors have become the driving forces behind the wider adoption of decision analysis. As government
agencies and large companies implement the process, more information
about decision analysis is becoming available, more experience is being accumulated, and more businesses are starting to improve the efficiencies of their
projects though decision analysis.
A Little Bit of History
The fathers of decision analysis had lofty goals. In the 1700s, French-born
mathematician Abraham de Moivre and English Presbyterian minister and
mathematician Thomas Bayes tried to apply mathematics to prove the existence of God. Their work made important contributions to probabilities and
statistics. In 1718 de Moivre published The Doctrine of Chances, in which he
presented the concept of relative frequency for probabilities. De Moivre
became one of fathers of the frequentistic approach to the theory of probabilities and statistics. Thomas Bayes came up with a different concept, one
that would later become the foundation for the Bayesian theory in the field
of probabilities. Around the same time, Swiss mathematician and physicist
Daniel Bernoulli came up with idea of decision-making based on possible
outcomes of events. Their work became the foundation of decision analysis.
The publication of the Theory of Games and Economic Behavior in 1944 by John
von Neumann and Oskar Morgenstern was another significant step in decision science. After the theory was published, a number of scholars developed
expansions and variations on it (Savage 1954; Luce 1959; Fishburn 1984; Karmarkar 1978; Payne 1973; Coombs 1975). Contemporary decision theory was
introduced in the 1960s by Howard Raiffa and Robert Schlaifer of the Harvard Business School, who introduced the framework of decision analysis
methods and tools (Raiffa 1968; Schlaifer 1969). The advent of the computer
in the past few decades has also had a strong influence, and today decision
and risk analysis software has become a practitioner’s tool.
Interestingly, in 2002 the Nobel Prize for economics was awarded to a psychologist rather than an economist. Daniel Kahneman was awarded the prize
for “having integrated insights from psychological research into economic
science, especially concerning human judgment and decision-making under
uncertainty.” (The Sveriges Riksbank Prize 2002). The research, which Kahneman conducted with Amos Tversky and other psychologists, outlined the
basic psychological foundation behind decision-making, significantly changing our understanding of human behavior. It affected not only our understanding of economics but also other areas, including project management.
11
12
Project Decisions: The Art and Science
Decision Analysis Today
Built on the work of many scholars in numerous fields, decision analysis has
now become a practical framework that helps to solve many problems in
different areas, including project management. The methodology is widely
used by many companies—General Motors, DuPont, Boeing, Eli Lilly, AT&T,
Exxon Mobil, Shell, Chevron, BP Amoco, Novartis, Baxter Bioscience, BristolMyers Squibb, and Johnson & Johnson, to name a few—and in government
agencies such as the Department of Defense, Department of Homeland Security, and NASA. Because easy-to-use decision analysis software tools have
become widely available, the adoption of decision analysis methods in all
types of organizations, including small and medium-sized companies, has
accelerated (see Appendix A).
Many universities, including Stanford University, Harvard University, Duke
University, the London School of Economics and Political Science, UCLA,
and the University of Massachusetts, offer courses in decision analysis. And
a substantial number of scientific papers, textbooks, and reference works on
the subject have been published in recent years (Keefer and Kirkwood 2004).
Experts in decision analysis have joined together in a number of professional
organizations, one being the Decision Analysis Society. The Decision Analysis Society is a subdivision of the Institute for Operations Research and the
Management Sciences (INFORMS). It publishes the journal Decision Analysis and has group meetings in conjunction with INFORMS annual meetings.
Another professional group, the Decision Analysis Affinity Group (DAAG),
focuses mostly on practical aspects of decision analysis. Project decision and
risk analysis is a part of the agenda of the Risk Special Interest Group (RiskSIG) of the Project Management Institute (PMI). The Society for Judgment and
Decision-making (SJDM) focuses mostly on the behavioral aspects of decision
theory. DAAG, RiskSIG, and SJDM hold annual meetings where members
and invited experts share their research and practical applications.
Project Decision Analysis: What Is It?
n
n
n
n
n
13
Wrong decisions are a burden that people working in different industries
impose on each other and on society at large.
Making decisions related to real life problems is a complex process due to
multiple objectives, complex structures, multiple risks and uncertainties, and
multiple stakeholders.
The advocacy-based approach to decision-making often involves an intuitive
assessment of the problem and does not necessarily lead to better decisions;
the alternative to this approach is the decision analysis process.
Government regulations and industry pressure are the main driving forces
behind the active integration of decision analysis into organizational
processes.
Decision analysis is based on extensive research in mathematics, logic, and
psychology; today, decision analysis is a framework of methods and tools
that help people and organizations make quality decisions.
Chapter 2
“Gut Feel” vs. Decision Analysis:
Introduction to the Psychology
of Project Decision-Making
“The purpose of psychology is to give us a completely
different idea of the things we know best.”
—Paul Valery, French Poet
(1871–1945)
T
he root cause of almost all project failures is human error or misjudgment. These errors are hard to prevent, for they stem from human
psychology. But decision-making is a skill that can be improved by
training. By understanding how psychological heuristics and biases can affect
our judgment, it is possible to mitigate their negative effects and make better
decisions.
Human Judgment Is Almost Always to Blame
In his paper “Lessons Discovered but Seldom Learned or Why Am I Doing
This if No One Listens” (Hall 2005), David C. Hall reviewed a number of projects that had failed or had major problems. Among them were:
n
n
n
Malfunctions in bank accounting software systems, which cost millions of dollars
Space programs, including the Mars Polar Lander, Mars Climate
Orbiter, and Ariane 5 European Space Launcher, that were lost
Defense systems, including the Patriot Missile Radar system and
Tomahawk/LASM/Naval Fires Control System, which had serious
problems.
Hall listed the various reasons why projects are unsuccessful:
n
Sloppy requirements and scope creep
n
Poor planning and estimation
16
Project Decisions: The Art and Science
n
Poor documentation
n
Issues with implementation of new technology
n
Lack of disciplined project execution
n
Poor communication
n
Poor or inexperienced project management
n
Poor quality control.
Hall’s list includes only the results of human factors; he did not find any
natural causes—earthquakes, say, or falling meteorites or locust attacks—for
project failures in these cases. In his paper he also described a recent study
by the Swiss Federal Institute of Technology. The study analyzed 800 cases
of structural failures where engineers were at fault. In those incidents 504
people were killed, 592 injured, and millions of dollars of damage incurred.
The main reasons for failures were:
n
Insufficient knowledge (36%)
n
Underestimation of influence (16%)
n
Ignorance, carelessness, neglect (14%)
n
Forgetfulness (13%)
n
Relying upon others without sufficient control (9%)
n
Objectively unknown situation (7%)
n
Other factors related to human error (5%).
Extensive research on why projects fail in different industries leads to the
same conclusion: Human factors are almost always the cause (Wilson 1998;
Johnson 2006; Rombout and Wise 2007). Furthermore, there is actually one
fundamental reason for all these problems: poor judgment. Dave Hall asks,
“Why don’t more people and organizations actually use history, experience,
and knowledge to increase their program success?” The answer lies in human
psychology.
All project stakeholders make mental mistakes or have biases of different
types. Although the processes described in the PMBOK® Guide and many project management books help us to avoid and correct these mental mistakes,
we should try to understand why these mistakes occur in the first place. In
this chapter we will review a few fundamental principles of psychology that
“Gut Feel” vs. Decision Analysis: Introduction to the Psychology of Project Decision-Making
are important in project management. In subsequent chapters we will examine how each psychological pitfall can affect the decision analysis process.
Blink or Think?
In 2005 Malcolm Gladwell, a staff writer for The New Yorker, published the
book Blink: The Power of Thinking without Thinking (Gladwell 2005), which
instantly became a best seller. Gladwell focused on the idea that most successful decisions are made intuitively, or in the “blink of an eye,” without
comprehensive analysis. In a very short time, Michael LeGault wrote Think!
Why Critical Decisions Can’t Be Made in the Blink of an Eye (LeGault 2006), as a
response to Malcolm Gladwell. LeGault argued that in our increasingly complex world people simply do not have the mental capabilities to make major
decisions without doing a comprehensive analysis. So who is right—Gladwell
or LeGault? Do we blink or do we think?
Both LeGault and Gladwell raised a fundamental question: What is the balance between intuitive (“gut feel”) and controlled (analytical) thinking? The
answer is not straightforward. As the human brain evolved, it developed
certain thinking mechanisms—mechanisms that are similar for all people
regardless of their nationality, language, culture, or profession. Our mental
machinery has enabled us to achieve many wondrous things: architecture,
art, space travel, and cotton candy. Among these mechanisms is our capacity
for intuitive thinking. When you drive a car, you don’t consciously think about
every action you must make as you roll down the street. At a traffic light, you
don’t think through how to stop or how to accelerate. You can maintain a conversation and listen to the radio as you drive. You still think about driving,
but most of it is automatic.
Alternatively, controlled thinking involves logical analysis of many alternatives, such as you might do when you are looking at a map and deciding
which of several alternative routes you are going to take (after you’ve pulled
over to the side of the road, we hope). When you think automatically, and
even sometimes when you are analyzing a situation, you apply certain simplification techniques. In many cases, these simplification techniques can lead
to wrong judgments.
People like to watch sci-fi moves in part because by comparing ourselves with aliens
we can learn how we actually think. The Vulcans from the Star Trek TV series and
movies are quite different from humans. They are limited emotionally and arrive at
rational decisions only after a comprehensive analysis of all possible alternatives with
multiple objectives. In many cases, Vulcan members of Star Trek crews like Spock
from the original Star Trek (Figure 2.1), T’Pol from Enterprise or Tuvoc from Voy-
17
18
Bettmann/Corbis
Project Decisions: The Art and Science
Figure 2.1 Spock and the Star Trek Crew
ager, help save the lives of everybody on board. However, in a few instances, especially
those involving uncertainties and multiple objectives, human crew members were
able to find a solution when Vulcan logic proved fallible. In the “Fallen Hero” episode of Enterprise, the Vulcan ambassador V’Lar noted that the human commander
Archer‘s choice was not a logical course of action when he decided to fly away from
an enemy ship. Archer replied that humans don’t necessarily take the logical course of
action. Ultimately, in this episode, Archer’s choice proved to be the best one.
The balance between intuitive and analytical thinking for a particular problem is not clear until the decision-making process is fully examined. Significant intellectual achievements usually
combine both automatic and controlled thinking. For example, business
Project managers should
executives often believe that their deciresist the temptation to
sions were intuitive; but when they are
questioned, it can be demonstrated
make an intuitive choice
that they did perform some analysis
(Hastie and Dawes 2001).
when they feel there is a
When people think consciously, they
are able to focus on only a few things at
once (Dijksterhuis, Bos, et al. 2006). The
more factors involved in the analysis,
realistic opportunity for
further analysis.
“Gut Feel” vs. Decision Analysis: Introduction to the Psychology of Project Decision-Making
the more difficult it is to make a logical choice. In such cases, decision-makers
may switch to intuitive thinking in an attempt to overcome the complexity.
However, there is always the option to use different analytical tools, including decision analysis software, to come up with better decisions.
So, coming back to our original question—do we blink or think?—it is important not to dismiss the value of intuitive thinking in project management.
Ever since there have been projects to manage, managers have been making
intuitive decisions, and they will continue to do so. Intuition can work well
for most short-term decisions of limited scope.
Because project managers rarely have enough time and resources to perform a
proper analysis, and decision analysis expertise is not always available, there is
always the temptation to make intuitive decisions. Even if you have experience
with and knowledge of a particular area, some natural limitations to your thinking mechanisms can lead to potentially harmful choices. In complex situations,
intuition may not be sufficient for the problems you face. This is especially true
for strategic decisions that can significantly affect the project. In addition, intuitive decisions are difficult to evaluate: when you review a project, it is difficult
to understand why a particular intuitive decision was made.
Cognitive and Motivational Biases
Let’s imagine that you are a campaign manager for a U.S. senator. You organized a few very successful meetings with voters in local day care centers,
distributed one million “My Opponent Is a Degenerate” flyers, and released
$3 million worth of negative ads exposing your opponent’s scandalous
behavior when he was five years old. After all your hard work, you estimate that your senator has the support of at least 55% of the decided voters.
Unfortunately, your estimate happens to be
wrong: in reality you have only 40% supBias is a discrepancy
port. So what is the cause of this discrepancy
(Figure 2.2)? This is not only a mistake in
between someone’s
your estimate of the poll numbers; there is
judgment and reality.
also the question of whether you ran your
campaign (project) correctly.
Why did you make this mistake? There might
be a number of explanations:
n
You were overconfident, and your expectations were greater than
what was actually possible.
19
20
Project Decisions: The Art and Science
Reality
30%
35%
40%
45%
50%
55%
60%
70%
Your judgment
What caused this error in judgment?
Figure 2.2 Bias in Estimation of Poll’s Results
n
n
n
You did not accurately analyze your own data.
You were motivated to produce such positive estimates because you
didn’t want to be fired if the poll numbers were not good enough.
Your boss, the senator, told you what your estimates should be.
We can explain the discrepancy in your poll numbers, and perhaps other
problems in the campaign, by looking at some of the biases in your thinking.
Don’t worry—we’re not picking on you. These are biases that can occur in
anyone’s thinking.
There are two types of biases: cognitive and motivational.
Cognitive Biases
Cognitive biases show up in the way we process information. In other words,
they are distortions in the way we perceive reality. There are many forms of
cognitive bias, but we can separate them into a few groups:
Behavioral biases influence how we form our beliefs. An example is the illusion
of controlling something that we cannot influence. For example, in the past
some cultures performed sacrifices in the belief that doing so would protect
them from the vagaries of the natural world. Another example is our tendency to seek information even when it cannot affect the project.
Perceptual biases can skew the ways we see reality and analyze information.
“Gut Feel” vs. Decision Analysis: Introduction to the Psychology of Project Decision-Making
Probability and belief biases are related to how we judge the likelihood that
something will happen. This set of biases can especially affect cost and time
estimates in project management.
Social biases are related to how our socialization affects our judgment. It is rare
to find anyone who manages a project in complete isolation. Daniel Defoe’s
classic novel Robinson Crusoe may be the only literary example of a project carried out in complete isolation (aside from the occasional requirement raised
by the threats from the local island population). The rest of us are subject to
different biases about how people communicate with each other.
Memory biases influence how we remember and recall certain information.
An example is hindsight bias (“I knew it all along”), which can affect project
reviews.
An example of one of the more common perceptual biases in project management is overconfidence. Many project failures originate in our tendency to
be more certain than we should be that a certain outcome will be achieved.
Before the disaster of the space shuttle Challenger, NASA scientists estimated
that the chance of a catastrophic event was one per 100,000 launches (Feynman 1988). Given that the disaster occurred on the Challenger’s tenth launch
(NASA 2007), the 1 in 100,000 estimate now appears to be wildly optimistic.
Overconfidence is often related to judgment about probabilities, and it can
affect our ability to make accurate estimates. Sometimes we can be overconfident in our very ability to resolve a problem successfully (McCray, Purvis,
and McCray 2002).
Appendix B contains a list of cognitive biases that are particularly related to
project management. The list is not a comprehensive set of all possible mental
traps that pertain to project management. Instead, we offer it as a tool that can
help you understand how such traps can affect you and your projects.
Motivational Biases
Motivational biases are caused by the personal interests of a person expressing an opinion. They are often easy to identify but difficult to correct, as you
must remove the motivational factors causing the bias. If an opinion comes
from an independent expert, removing the bias will not be too difficult
because, by definition, an independent expert does not have any vested interest in the project outcomes. If you suspect that a member of the project team
is biased, however, corrective actions can be difficult to accomplish, as it is
hard to eliminate the personal interests of team members or managers from
the project without removing the individuals themselves. Motivational biases
21
22
Project Decisions: The Art and Science
are like an illness: You know that you have the flu, but there is very little you
can do about it.
Perception
Consider a situation in which you and your manager are in the midst of a
heated disagreement. You believe that your project is progressing well; your
manager thinks that it is on the road to failure. Both of you are looking at the
same project data, so you and your manager obviously have different perceptions of the project. Who is right?
Most people believe themselves to be objective observers. However, perception is an active process. We don’t just stand back passively and let the real
“facts” of the world come to us in some kind of pure form. If that were so,
we’d all agree on what we see. Instead, we reconstruct reality using our own
assumptions and preconceptions: What we see is what we want to see. This
psychological phenomenon is called selective perception. As a project manager,
you have a number of expectations about the project. These expectations have
different sources: past experience, knowledge of the project, and certain motivational factors, including political considerations. These factors predispose
you to process information in a certain way.
Psychologists try to understand how the process of making judgments actually works. One of the tools that can be used to model mental activities associated with project management is the lens model (Hastie and Dawes 2001).
Invented by Edon Brunswik in 1952 (Hammond and Steward 2001), the lens
model is not a comprehensive theory about how judgments are made, but
rather a conceptual framework that models how judgments are made under
uncertain conditions.
For example, let’s assume that you are working for a national intelligence
agency and are involved in a project to capture Osama bin Laden and his
fellow terrorists. Occasionally they issue a new tape that could provide some
information about their whereabouts. Your task is to analyze the tape to discover the location of his hideout. We can assess your task by applying the lens
model.
The lens model is divided in two: the left side represents the “real world”; the
right side represents events as you see them in your mind (Figure 2.3). You
try to see a true state of the world (the terrorist’s location) through the lens of
cues or items of information. On the right side of the diagram, information is
conveyed to you by cues in the form of estimates, predictions, or judgment
of the value of the input parameter. If, for example, you have an audiotape,
“Gut Feel” vs. Decision Analysis: Introduction to the Psychology of Project Decision-Making
you could try to listen for some external sounds specific to a geographical
location, certain features of the speaker’s voice, the content of the speech, or
anything else that might give an indication regarding the location. A videotape might give you more information or cues. However, the way that you
interpret these cues is predicated on the lens through which you view them.
For example, if a video came in showing Osama bin Laden sitting down with
a group of Islamic-appearing men drinking tea, the intelligence officer might
immediately infer that they are meeting to discuss Al Qaeda business, perhaps planning a future attack somewhere in the Pakistan–Afghanistan border
area, and will start to look for clues to confirm this perception. The reality
may be that they are merely discussing family matters in an entirely different
location.
This “lens of cues” is a certain mind-set that predisposes you to see information in a certain way. These mind-sets are unavoidable: It is impossible
to remove our own expectations from our prior judgments. Moreover, these
mind-sets are easily formed but very hard to change. You can come to an
assumption based on very little information (such as your certainty that bin
Laden is in Pakistan), but once formed, it is hard to change the perception
unless solid evidence to the contrary is provided. Therefore, if your manager
has come to an opinion about the project (for instance, he already believes
that bin Laden is in Pakistan) based on inaccurate or incomplete information,
it is hard to change this opinion. You probably know about this phenomenon
with regard to first impressions; when you judge people or somebody judges
you, original impressions are very difficult to change.
External World
Psychological Processes
Input
Judgment
Lens of Cues
Figure 2.3 Lens Model of Judgment
23
24
Project Decisions: The Art and Science
A project manager will manage a project based on how he or she perceives
the project. When a manager believes that everything is going well in spite
of evidence to the contrary, he or she will not see the need to take corrective
actions. In these cases, selective perception can lead to biases and eventually
to wrong decisions. A common upshot of this bias is a premature termination
of the search for evidence: We tend to accept the first alternative that looks
like it might work. We also tend to ignore evidence that doesn’t support our
original conclusion.
Before making a decision, therefore, it is important to pause and consider
these questions:
n
Are you motivated to see the project in a particular way?
n
What do you expect from this particular decision?
n
Would you be able to see the project differently without these expectations and motivational factors?
Bounded Rationality
Why do our cognitive abilities have limitations? Herbert Simon suggested the
concept of bounded rationality (Simon 1957)—that is, humans have a limited
mental capacity and cannot directly capture and process all of the world’s
complexity. Instead, people construct a simplified model of reality and then
use this model to come up with judgments. We behave rationally within the
model; however, the model does not necessarily represent reality. For example,
when you plan a project, you have to deal with a web of political, financial,
technical, and other considerations. Moreover, reality has a lot of uncertainties that you cannot easily comprehend. In response, you create a simplified
model that allows you to deal with these complex situations. Unfortunately,
the model is probably inadequate, and judgments based on this model can be
incorrect.
Heuristics and Biases
According to a theory Daniel Kahneman developed with Amos Tversky (Tversky and Kahneman 1974), people rely on heuristics, or general rules of thumb,
when they make judgments. In other words, they use mental “shortcuts.”
In many cases, heuristics lead to rational solutions and good estimates. In
certain situations, however, heuristics can cause inconsistencies and promote
cognitive biases. Kahneman and Tversky outlined three main heuristics.
“Gut Feel” vs. Decision Analysis: Introduction to the Psychology of Project Decision-Making
25
Availability Heuristic
Assume that you are evaluating project-management software for your company. You did a lot of research, read a number of detailed reviews, used a
number of different evaluation tools, and concluded that Product X is a good
fit for your organization. Then, just after you finished your report, you went
to a conference and met a well-known expert in the industry who had a different opinion: “Product X is a poor choice. It
is slow and difficult to use.” You feel relieved
that you had this conversation before you
According to the availability
handed in your recommendations, but your
real mistake may be in throwing out your
heuristic, people judge the
original recommendations. On the basis of
probability of the occurrence
the opinion of one individual, you are ready
to scrap the findings in your well-researched
of events by how easily these
and comprehensive report. You are giving
too much weight to this opinion because of
events are brought to mind.
the manner and the timing in which it was
presented to you. This is an example of a
bias that is related to the availability heuristic.
When we try to access the probability of a certain event or recall all instances
of an event, we first of all recall events that are unusual, rare, vivid, or associated with other events such as major issues, successes, or failures. As a result,
our own assessment of probabilities is skewed because the ease with which
an event can be recalled or imagined has nothing to do with actual probabilities of the event occurring.
When you see a slot machine winner holding up a poster-sized multimillion-dollar check, you might assume that you have a reasonable chance of
winning at the casinos. This belief can be formed because you have received
a vivid image or information related to a rare (and desirable) event: winning
the lottery. Add to this what you read and see in the media, and you have all
necessary means to misjudge your probability (or hope) of winning. If the
government really wanted to fight gambling, based on what we know about
the availability heuristic, it should erect huge billboards listing personal
bankruptcies and showing broken families in front of casinos. How would
you feel about your chances of winning if each time you went to the casino
you saw this sign:
Welcome to Our Friendly Casino
This year 168,368 people lost $560 million here.
5% of our guests divorced, 1% became alcoholics, and 0.4% committed suicide.
26
Project Decisions: The Art and Science
You might have second thoughts about your chances of winning the jackpot. Advertisers, politicians, sales people, and trial lawyers use the power of
vivid information all the time. Biases associated with availability heuristic are
extremely common in project management, primarily when we perform project estimations. We will review the psychology of estimating in Chapter 11.
(Here is a suggestion. If you want your project idea to be accepted, use a lot
of colorful images and details in your presentation. When the time comes for
management to decide which projects should go forward, they will have an
easier time remembering your presentation.)
Representativeness Heuristic
Let’s assume that you want to estimate the chance of success for a project
with the following description:
The project is managed by a project manager with ten years of industry experience.
He has PMP designation and actively uses processes defined in the PMBOK® Guide
in his management practices.
Based on this description, you categorize this as a well-managed project. You
will judge the probability of success of the project based on the category this
project represents (Tversky and Kahneman 1982). In many cases this representativeness heuristic will help you to come up with a correct judgment. However, it can lead to a number of biases. One type of bias related to this heuristic
is the conjunction fallacy.
Here is an example of a conjunction fallacy. A company is evaluating whether
to upgrade its existing network infrastructure and is considering two
scenarios:
A. New networking infrastructure will improve efficiency and security by providing increased bandwidth and offering more advanced monitoring tools.
B. New networking infrastructure will be more efficient and secure.
Statement A seems to be more plausible, and therefore more probable, than
the more general statement B. However, in reality, the more general statement
B has a higher probability of occurring. The conjunction fallacy states that
people tend to believe that scenarios with greater detail are also more probable. This fallacy can greatly affect your ability to manage projects in that if
you must select one project from a number of proposals, you may tend to pick
those proposals with the most detail, even though they may not have the best
chance of success.
“Gut Feel” vs. Decision Analysis: Introduction to the Psychology of Project Decision-Making
27
Anchoring and Adjustment Heuristic
How often have you gone to a store and found that an item you want is on
sale. For example, the suit you want is priced down from $399 to $299 with
a “sale” label attached to it. “What a great bargain,” you think, and you buy
the suit. However, from the store’s point of view, the original price of $399
served as a reference point or anchor, a price at which they would probably
never attempt to sell the suit. But by posting $399 and a “sale” sign on it, the
store is able to sell a lot of suits at $299. By
fixating on only a single piece of information,
Anchoring is the human
the price of $399, you probably did not stop
to consider whether the asking price of $299
tendency to rely on one trait
was a good value for your money. Further
or piece of information when
research might show, for example, that other
stores sell the same suit for $199, or that other
making a decision.
suits in the first store priced at $299, but not
“on sale,” are better values.
We always use a reference point when we try to quantify something. This
is called the anchoring and adjustment heuristic, and it can be very helpful in
many cases. Unfortunately, as with the other heuristics we have mentioned, it
often causes biases that are very difficult to overcome. One of them is related
to an insufficient adjustment after defining an initial value. Once we have determined a certain number or learned about a certain reference point, we don’t
significantly deviate from this value when we research a problem.
Behavioral Traps
Let’s say that you are managing a software project that includes the development of a component for creating 3-D diagrams. Four team members are
slated to work on this particular component for at least a year. The development of the component could easily cost more than $1 million when you add
up the salaries and expenses such as travel, computers, the Christmas party,
and other sundries. (If you are lucky, the team members are sitting in cubicles
somewhere in rural Montana. If they develop this component in Manhattan,
development costs will probably triple.) As luck has it, the project progresses
on time and within budget, and everything appears to be going extremely
well. Inadvertently, while browsing an industry website, you discover that
you could have purchased a similar component off the shelf, which not only
has better performance but also costs only $10,000. At this point, your project
is 90% complete, and you have spent $900,000. Should you halt your project and switch to the off-the-shelf solution or continue your project with the
added $100,000 investment?
28
Project Decisions: The Art and Science
When psychologists asked people a similar question, 85% chose to continue
with the original project (Arkes and Blumer 1985). But when the original
investment was not mentioned, only 17% of people chose to continue the
original project. This is a classic case in which you are asked to either “cut and
run” or “stay the course.”
This phenomenon is called the sunk-cost effect, and it is one of many behavioral
traps (Plous 1993). Behavioral traps occur when you become involved in rational activity that later becomes undesirable and difficult to extricate yourself
from. There are a number of different categories of behavioral traps in project
management. The sunk-cost effect belongs to the category of investment traps.
Walter Fielding, played by Tom Hanks in the 1986 film Money Pit, experienced an investment trap when he purchased his dream house. His original
investment was very small, but the incremental cost of the required renovations proved to be his undoing. A rational person would have walked away
once the real cost of the house became apparent.
Here are few other types of traps.
Time Delay Traps
Time delay traps occur when a project manager cannot balance long-term and
short-term goals. If you want to expedite the delivery of a software product at the expense of the software’s architecture, unit testing, and technical
documentation, you will jeopardize the long-term viability of the software,
even though you get the first (and possibly flawed) generation of it to your
customers on time. All project managers are aware of this tradeoff but often
ignore long-term objectives to meet short-term goals. In these cases, project
managers usually blame organizational pressure, customer relationships, and
so on, when it is really the result of a fundamental psychological trap. It’s like
when you postpone your dental cleaning appointment to save a few bucks
or because it’s inconvenient, and a few years later you end up having major
dental work done. Or when you use your credit cards for your Christmas
shopping and end up with an even larger debt.
Ignorance Traps
In 1972 the nonprofit organization Broward Artificial Reef proposed using old tires to
construct an artificial reef off the coast of Fort Lauderdale. The idea was to provide a
reef that would boost local marine life and at the same time dispose of two million old
tires. The project was approved by the U.S. Army Corps of Engineers and Broward
“Gut Feel” vs. Decision Analysis: Introduction to the Psychology of Project Decision-Making
County (Trenton 2006). More than two million tires were dropped over 36 acres of
ocean floor, approximately 7,000 feet offshore at a depth of 65 feet.
What at first seemed to be a good idea turned out to be an ecological disaster. The
metal clips that held the tires together corroded, and the tires spilled across the ocean
floor. The tires began moving with the tide, and the expected marine life never materialized. The tires emitted toxic substances that damaged delicate marine life in adjacent areas. Moreover, hurricanes deposited the tires hundreds of miles away. Previous
attempts to remove the tires were not completely successful, and now the U.S. Navy,
Broward County, and other groups are planning a large-scale project to remove the
tires that is estimated to take many years and cost a lot of money.
This is a good example of the ignorance trap, where project managers do not
realize the consequences of their decisions. After the original wrong decision
was made, it was very hard to reverse it. In these situations, if the project
managers try to maintain the status quo, delays can further exacerbate the
situation. These situations are different from time delay traps, where managers understand the potential long-term consequences of their decisions. To
avoid these traps, it is important to perform a comprehensive analysis and
evaluate your decisions regularly.
Deterioration Traps
Deterioration traps are similar to investment traps in that the expected cost
and benefits associated with the project change over time. During the course
of new product development, costs may grow substantially. And at the same
time, because of a number of unrelated marketing issues, there may be fewer
clients willing to buy the product. In this case, the results of the original analysis are no longer valid.
Deterioration traps are common in processes involving the maintenance of
“legacy” products. Should the software company continue releasing new
versions of its old software or develop completely new software? Releasing new versions of the old product would be cheaper. Over time, however, it can be more expensive to delay the new product. Should automakers
continue with an old platform or invest hundreds of millions of dollars to
develop a new one?
Frames and Accounts
As a project manager, you are probably a frequent flyer. Oil prices go up and
down, and airlines often impose fuel surcharges. They can do it two ways:
29
30
Project Decisions: The Art and Science
1. Announce a fuel surcharge of, say, $20 per flight when fuel prices go
up.
2. Advertise prices that already include a fuel surcharge and announce a
sale ($20 off) when fuel prices go down.
For the consumer, there is no financial difference between these two methods
of advertising, but we tend to perceive them differently. Tversky and Kahneman (1981) call this effect framing. They proposed that decision frames are the
ways in which we perceive a problem. These frames are controlled by different personal habits, preferences, and characteristics, as well as the different
formulation or language of the problem itself.
We apply different frames not only to our choices but also to the outcomes of
our choices. In the example that follows, consider three scenarios:
Scenario 1: You are involved in a construction project worth $300 million and
have discovered a new approach that would save $1 million. It will take you
a lot of time and effort to do the drawings, perform structural analysis, and
prepare a presentation that will persuade management to take this course.
Would you do it?
Scenario 2: You are involved in an IT project worth $500,000 and have discovered a way to save $80,000. You need to spend at least a couple of days for
researching and putting together a presentation. Would you do it?
Scenario 3: You are involved in the same construction project as in Scenario 1
and have found a way to save $80,000 (by replacing one beam). You need to
spend a couple of days on research and the presentation. Would you do it?
Most likely you would not bother with an $80,000 improvement for a $300
million project (scenario 3) but would pursue your ideas in scenarios 1 and 2.
This is because people have different frames and accounting systems for different problems. When we purchase a home, we don’t worry if we overspend
by $20 because it comes from our “home buying” account and $20 is a tiny
part. However, when we purchase a shovel, we are really concerned about an
extra $20 because it comes from our “home tools” account and $20 is a significant amount. Both accounts operate according to different mental rules, even
though everything technically comes from the same bank account.
Training for Project Decision-Making Skills
The CN Tower in Toronto (Figure 2.4) is the world’s tallest building at 1,815 feet
(553 meters). A glass-floored outdoor observation deck is located at a height
“Gut Feel” vs. Decision Analysis: Introduction to the Psychology of Project Decision-Making
Figure 2.4 Toronto’s CN Tower
of 1,122 feet (342 meters). There, you can walk on a glass floor and see what is
directly below your feet—the ground, more than a thousand feet below (Figure
2.5). At first, you would probably be afraid to step out onto the floor. But as you
realize that the glass is extremely strong (you might bounce a little to see how
Figure 2.5 The View from the CN Tower
31
32
Project Decisions: The Art and Science
rigid it is), you walk a few steps away from the edge. Finally, as you overcome
your anxiety, you start walking more or less freely. Still, you can see that more
people stay on the edge of the glass than actually walk on it.
All of us have inherited a fear of heights. We are afraid to fall, and this is a natural fear. This property of our mental machinery saves as from a lot of troubles. In Toronto’s CN Tower, you have started to teach yourself to overcome
this particular bias as your instinctive fear of heights is gradually replaced
with the logic that there is not any danger in this particular case.
This example illustrates a very important point. Decision-making is a skill
that can be improved with experience and training (Hastie and Dawes 2001).
Project managers can teach themselves to make better choices by overcoming
common mental traps. Many biases are hard to overcome, and it requires concerted effort and some experience to do so. As a first step, you need to learn
that these biases exist.
n
n
n
n
n
n
The fundamental reason for failed projects is poor judgment expressed by all
project stakeholders.
Intuitive thinking is an important mechanism that helps us solve many problems. However, intuitive thinking may lead to poor judgments in complex
problems.
Decision-makers make predictable mental mistakes called biases. Understanding different cognitive and motivational biases helps to reduce their
negative effect.
Our perception of a problem depends on our preferences and expectations.
As a result “we see what we what to see.” This phenomenon is called selective perception.
When people deal with complicated problems, they use certain simplified
mental strategies, or heuristics. In many cases, heuristics lead to fairly good
estimates. However, in certain situations, heuristics can cause predictable
biases.
Decision-making is a skill that can be improved with experience and
training.
Chapter 3
Understanding the Decision
Analysis Process
The Americans will always do the right thing . . .
after they’ve exhausted all alternatives.
— W i n s to n C h u r c h i l l
W
e want to make rational choices, we would like a transparent
decision-making process, and we want a mechanism for correcting mistakes. These goals can be accomplished through the decision analysis process: decision framing, modeling, quantitative analysis and
implementation, and monitoring and reviewing of decisions. Decision analysis is simple and adaptable to different types of project decisions.
Decision Analysis
An example of applying decision analysis to a complex project can be seen
at the National Aeronautics and Space Administration (NASA). The U.S.
Congress mandated that NASA be more accountable when it evaluates its
advanced technology projects. As a public agency, NASA is concerned about
maximizing the value it gets from its expenditures and cost reduction. But
taking risks is inherent in all space exploration, so eliminating risk would
mean eliminating NASA’s very purpose. (From another perspective, what
do you think was the primary objective of the Wright brothers—maintaining a healthy net present value or getting an airplane to fly?) To manage its
inherent risk, many NASA divisions have started applying decision analysis
methods to improve their ability to select courses of action.
Once a year, divisions of the Kennedy Space Center and their contractors submit as many as 50 project proposals for possible funding. To choose among
them, the Space Center uses a multi-criteria decision-making process for evaluating and prioritizing advanced technology projects (Tavana 2003). Project
evaluations are done by committees with 15 members: five permanent voting
and ten advisory (it sounds like the U.N. Security Council).
34
Project Decisions: The Art and Science
In the first phase of the process, the five permanent members of the committee, who are appointed by Kennedy Space Center management, perform a
preliminary review of the projects. They identify which stakeholder departments—such as safety, system engineering, cost saving, process enhancement, and reliability—should participate in the review. Ten representatives of
the stakeholder departments then join the committee as advisory members.
The committee decides what criteria should be considered in evaluating the
project. Examples of these criteria are “Eliminating the possibility of death or
serious injury,” “Reducing a system failure,” “Improving time to repair,” and
“Meeting proposed schedule.”
The committee assigns certain weighted coefficients to each criterion. It then
conducts brainstorming meetings to determine the probability of occurrence for each criterion in each project. Quantitative analysis tools are then
employed to analyze the projects and rank them. Finally, the committee submits recommendations for the approval of top management.
The decision analysis process at the Kennedy Space Center does not replace
human judgment in project selection. But, importantly, it enables decisionmakers to think systematically and, as a result, improve the quality of their
decisions.
When Decision-Makers Go Bad
Everybody wants to make good decisions, but in reality many project decisions turn out to be wrong. For example:
n
n
n
Why did a company decide to develop a product that it could not
sell?
Why did a project team decide to use supplies of poor quality?
Why did management appoint a project manager who does not understand the business?
You might say that the company did not really want a product it could not
sell, did not really wish to use poor-quality materials, or did not really intend
to appoint an incompetent project manager. But it did make those decisions,
using its own decision-making process.
The process that leads to such decisions is often cloaked. Decisions are frequently made behind closed doors, so it is difficult to know how, when,
where, and why a decision that had dire consequences was made. And once
people make a decision, they tend to stick to it, even in the face of mounting
evidence that it is wrong. This is a known psychological bias. People tend to
35
Understanding the Decision Analysis Process
be consistent, even if it means behaving irrationally; they don’t what to admit
that they made a bad decision. As a result, poor decisions tend to take on a life
of their own, which can exacerbate an already bad situation.
But there is a better way—decision analysis.
The Decision Analysis Manifesto
Here are three basic things you should want from a decision analysis process.
We call it the Decision Analysis Manifesto.
n
n
n
You want rational decisions. Quality decisions should lead to maximizing project value while minimizing expenditures. Good decisions
should be based on an unbiased assessment of all possible alternatives. They should benefit the whole business, not just the interests of
a specific individual or group.
You want transparent decision-making. You want to know how
decisions are made, who made them, and who should be accountable if a decision is wrong. You want to be able to participate in
decision-making.
You want a mechanism for correcting mistakes. If there is a problem
with the original decision, you should be able to recognize it and take
corrective actions in a timely manner.
In sum, what you want is a process. As with many other business processes,
decision analysis has a set of procedures and tools that an organization can
readily follow.
The “3C” Principle of Project Management
Decision analysis is not a single, fixed process, but rather an adaptable framework that
can be tailored by an organization to meet its
specific needs.
There is no exact recipe for how to structure
a decision analysis process. Different processes can be adopted for various companies,
types of projects, and the types of decisions
required. Your organization may already
have, if not a fully established process, some
components of decision analysis. For exam-
The decision analysis
process is an integrated
set of procedures, rules,
preferences, and tools that
help the organization make
a rational choice.
36
Project Decisions: The Art and Science
ple, how do you review project risks and uncertainties? How are decisions
made at product launch meetings?
But what does a “fully established decision analysis process” imply? Any
established or mature decision analysis process is based on three main
rules, which we call the “3C” principle: consistency, comprehensiveness, and
continuity.
Consistency
The decision analysis process should be standardized for similar kinds of
problems and opportunities. Inconsistency in decision-making can cause
projects to change directions unnecessarily, which can lead to failure. This
necessitates that organizations must have the same set of rules and preferences for making decisions in all similar types of projects.
Suppose, for example, an oil company has different offices around the world
evaluating exploration prospects. The company does not have enough
resources to drill everywhere at the same time, so it must make choices. The
evaluations on potential drilling prospects are forwarded from the various
outlying offices to the corporate planning headquarters, where decisions
about resource allocation are made. One of the main difficulties that the corporate planners face is that this information is submitted by different groups
looking to develop their prospects in different locations, which are often in
different countries. The planners don’t want to compare apples and oranges,
as the saying goes, so the company tries to ensure that the methods used
to generate the data regarding prospects are consistent across the organization. Otherwise it would be impossible to make a comparison of potential oil
reserves and make decisions on which prospects to develop (Rose 2001).
Comprehensiveness
Decision analysis processes should include a comprehensive assessment and
analysis of the business situation. Missing or incomplete information can lead
to incorrect decisions.
Let’s say that your manager approaches you and shows you a project schedule. He says, “We performed a comprehensive analysis on all of our possible
alternatives and have decided to go ahead with this particular one.”
After a brief look at the schedule, you say, “Looks like it’s a very tight schedule. Did you account for any risk events? Where is the contingency time?”
Understanding the Decision Analysis Process
“Don’t worry about contingencies,” he replies. “We covered everything. If
you recall, we have done some similar projects in the past and didn’t have
any problems. Plus, the decision has come down from up high, so it’s out of
our hands.”
Two days into the project, a major event occurs and the project is delayed.
Did upper management perform a comprehensive decision analysis as
claimed? No, because they relied simply on their experience of some past
projects and did not include risks and uncertainty. The analysis was not comprehensive, and therefore it was flawed.
Continuity
Decision analysis is a continuous process of evaluating and refining decisions
during the course of a project. High-quality results can be achieved only
through constant and consistent adaptive management.
Here’s an example of failing to use adaptive management.
You recently completed a project and presented it to your client. Unfortunately, the client is not very happy. Why? A couple of years ago, when the
project was initiated, somebody made an incorrect decision that appears to
have reduced the value of the project due to huge cost overruns. The person
responsible for that decision is no longer on the team, so it will be difficult to
understand the basis for it. And why were no corrective actions taken when
it became obvious that the evaluation of cost was flawed?
Upon further investigation, you discover that it is not a common practice
in your organization to revisit a decision once it has been made. In addition, when the problem surfaced, a great deal of resources had already been
expended, and there was a great reluctance at that point to change course.
The final result is that your project failed to meet its requirements because the
team did not adapt to changing circumstances.
Decision Analysis Process vs. the PMBOK® Guide’s Project
Risk Management
You may question how decision analysis differs from what is described in
the PMBOK® Guide, Chapter 11, “Project Risk Management.” Decision analysis and risk management both deal with uncertainties, but they do so from
different perspectives. So are both processes required? Could you imagine a
country with two presidents—one responsible for decision-making and the
37
38
Project Decisions: The Art and Science
In many aspects, decision
analysis enriches the
project management
process described in the
PMBOK® Guide.
other for managing risks? Just think, two White
Houses, two sets of Secret Service agents, and
two White House chefs. This might not be the
end of the world, for we have a lot of redundant government agencies and we could survive with two White Houses. However, the two
presidents would have a difficult time with
their appointed roles: You can’t make a decision without risk analysis, and you can’t manage risks without making decisions.
The good news is that you do not need two (or more) business processes to
manage related issues. You can integrate decision analysis into your overall project management process as described in the PMBOK® Guide. Decision
analysis and risk management processes have a significant overlap. A good
decision analysis should include risk analysis. In other words, decision analysis is a broader exercise than risk analysis.
In this book we do not discuss the PMBOK® Guide processes in detail. (A number of very good books on risk management are listed in the Future Reading
section.) We will, however, show you how the PMBOK® Guide’s risk-management processes parallel the decision analysis. We will mention all of the
PMBOK® Guide’s risk-management processes, so you will have a complete,
logical picture of how the two approaches relate to each other.
Decision Analysis and Other Business Processes
The PMBOK® Guide’s project management process is not the only process
practiced in organizations. Many organizations have established quality
management procedures and use different methodologies to improve quality, performance, reliability, and customer satisfaction.
One of these methodologies is Six Sigma (Pande and Holpp 2001; Pyzdek
2003), a rigorous and disciplined methodology that uses data and statistical analysis to measure and improve a company’s operational performance,
practices, and systems. Six Sigma identifies and prevents defects in manufacturing and service-related processes.
Many organizations have spent significant efforts implementing ISO 9000
(Hoyle 2005; Gupta 2006). ISO 9000 is a family of the ISO (the International
Organization for Standardization) standards for management systems. It
does not guarantee the quality of end products and services; rather, it certifies that consistent business processes that fall within the ISO 9000 guidelines
are being applied.
Understanding the Decision Analysis Process
Software development organizations use different business processes, including the Rational Unified Process (RUP) (Kruchten 2000; Larman 2002). The
Rational Unified Process is an iterative software development process created
by the Rational Software Corporation, now a division of IBM.
Because decision analysis is an adaptable framework, it can be integrated into
these different business processes; for example, it can share the same data and
analytical methods.
Phases of the Decision Analysis Process
The decision analysis process includes a number of phases, with each phase
containing a number of steps. We can illustrate the process with a project
you may be familiar with from your childhood, an incident involving Winnie the Pooh:
As you may recall, Pooh dropped in on Rabbit one day and ended up jammed in Rabbit’s doorway after helping himself to all of Rabbit’s honey. For Pooh, it was supposed
to be a very short project: (1) visit Rabbit; (2) consume honey; and (3) go home. But
Pooh, being Pooh, ate too much honey during the “consume honey” activity. This is
a good example of the psychological bias of overconfidence. As a result of this event,
the trivial activity (“go home”) could not be accomplished as scheduled, for Pooh was
firmly wedged in the doorway. Now Pooh and his friends had a decision to make: They
had to select the best alternative to solve this problem (Figure 3.1).
Let’s examine how a decision analysis process (Figure 3.2) would help identify the best solution for the problem facing Rabbit and Pooh.
Phase 1. Decision-Framing
Decision-framing helps decision-makers identify potential problems or
opportunities; assess business situations; determine project objectives, trade­
offs, and success criteria; and finally identify uncertainties. The project manager defines the scope of the decision. Depending on the situation, a project
manager alone, an independent expert, or a team of experts can perform the
decision framing. The processes of risk-management planning and risk identification described in the PMBOK® Guide can be accomplished along with
decision-framing.
n
Step 1.1. Identifying Potential Problems and Opportunities
In some cases it is difficult to identify problems and opportunities, especially
when they are related to a strategic decision. For example, what causes different projects within the organization to be consistently late?
39
40
Project Decisions: The Art and Science
Figure 3.1 Using Decision Analysis to Resolve Complex Problems
In our Pooh example, the problem was clear. Pooh was stuck and was not happy about
it (neither was Rabbit). Both of them need Pooh to be removed from Rabbit’s house as
soon as possible.
n
Step 1.2. Assessing the Business Situation
Before making a decision, it is important to assess the business environment
and define the constraints related to the problem. Business environments can
influence resource availability and costs. The assessment may also include an
analysis of markets, competition, prices, or anything else that can be related
to the problem or opportunity. During this step, it is important to list all external factors that may have an impact on the problem.
Who or what could be used to get Pooh out of his predicament? Of course, it could be
Christopher Robin and Pooh’s other friends. Wise Owl also had some project management experience. In addition, Gopher had the expertise and tools to provide some
engineering work.
41
Understanding the Decision Analysis Process
Steps of Decision Analysis Process
Decision
Framing
Modeling
the Situation
Quantitative
Analysis
Implementation
Monitoring
Review
Project Risk Management
Processes (PMBOK® Guide)
Identification of Problems or Opportunities
Assessing Business Situation
Risk Management Planning
Determining Success Criteria
Risk Identification
Identifying Uncertainties
Generating Alternatives
Creating Models for Project Alternatives
Quantifying Uncertainties
Determining What Is Most Important
Quantifying Risks Associated with Project
Determining the Value of New Information
Deciding on a Course of Action
Implementing the Best Alternative
Monitoring the Project Implementation
Review of the Decision Experience
Qualitative Risk Analysis
Quantitative Analysis
Risk Response Planning
Risk Monitoring and Control
Figure 3.2 The Decision Analysis Process
n
Step 1.3. Determining Project Objectives,Tradeoffs, and
Success Criteria
Projects usually have multiple objectives and therefore multiple criteria for
decision-making, which can make the analysis very complex. Decision-making criteria include project duration, cost, scope, quality, and safety, among
other parameters. Project managers should find the right balance between
these objectives and make tradeoffs when necessary.
In Pooh’s situation the success criteria were:
n
n
Remove Pooh from the doorway as soon as possible.
n
Do not harm Pooh during this process (safety concern).
n
Do not damage Rabbit’s dwelling.
Step 1.4. Identifying Uncertainties
Understanding uncertainties is the key to the decision analysis process. In the
decision-framing step, risks and uncertainties should be identified. Uncer-
42
Project Decisions: The Art and Science
tainties can be found in a project’s cost, scope, duration, quality, safety, or
environment .
In this project—removing Pooh—we primarily have uncertainties in time, as well as
uncertainties in cost.
n
Step 1.5. Generating Alternatives
In decision-framing, it is important to generate key alternatives. First, you
must identify what cannot be changed, that is, what the constraints are in the
particular decision analysis. Then you can determine potential alternatives.
Pooh needed to be removed one way or another. He could not be stuck in Rabbit’s
doorway forever. Therefore, project scope was a constraint. There was, however, the
possibility of bringing in additional resources to accelerate the project. As a result, we
have three potential project scenarios:
n
External contractor Gopher digs out Pooh.
n
Gopher blasts Pooh out with dynamite.
n
Christopher Robin’s suggestion—waiting until Pooh loses enough weight
and is slim enough to slip through the doorway.
Phase 2. Modeling the Situation
A mathematical model can help to analyze and estimate future events. To
understand how a structure withstands particular loads, engineers perform
structural analysis on buildings using mathematical models. They don’t want
to find out that a particular beam cannot bear a load after it has been put in
place because by then it may be too late to change it. The same situation exists
with any other projects.
n
Step 2.1. Creating Models for Each Project Alternative
Project managers constantly create mathematical or valuation models of projects. In most cases, it is simply the project schedule. A more comprehensive
model of a project includes a breakdown of resources, costs, and other project
variables.
Sometimes, quite elaborate models are required. For example, in the analysis
of a product’s lifecycle, comprehensive models will include not only product
development but also marketing and sales efforts.
Each model includes input and output variables, as well as a calculation algorithm. In the case of a project schedule, input parameters are tasks with their
Understanding the Decision Analysis Process
start and finish times, costs, and resources, and relationships among all the
tasks. Outputs include project cost, duration, start and finish times, critical
tasks, resource allocation, and other parameters.
Modeling the situation in general, and project scheduling in particular, can
be a very complex process. A model should be created for each project scenario; in most situations, however, these models are variations of a single
base model.
In the Pooh removal project, a schedule for each alternative was needed.
Based on Owl’s request, Gopher estimated the duration of the excavation alternative.
He did a review of the site and performed some exploratory excavation. He estimated
that the work would take two or three days. He also performed a cost analysis. He
based his calculation on his hourly rate and estimated project duration. He also added
overtime and 10% for contingency.
Gopher estimated that using dynamite would lead to a quick removal of Pooh, but
with uncertain effects on Rabbit’s doorway and Pooh’s rear end.
The slimming alternative, suggested by Christopher Robin, seemed to have the least
risk and cost, but the longest duration.
n
Step 2.2. Quantifying the Uncertainties
The uncertainties in a project, identified through the decision-framing process, should be quantified. One of the ways to quantify uncertainties is to
define ranges for their parameters. For example, define low (optimistic), base
(expected), and high (pessimistic) duration or cost estimates for each task.
Another way to define uncertainties is to list all the potential events that could
affect the project schedule, then quantify their probabilities and impact.
The PMBOK® Guide’s steps for risk management recommend using a qualitative risk-analysis process to assign probability and impact.
n
n
n
Gopher estimated the uncertainty in duration of the excavation as a range
(between two and three days).
The blasting alternative had minimal uncertainties in estimating duration.
There were several uncertainties with the last alternative (Pooh’s slimming
down). Nobody knew for certain how long before Pooh’s stout frame would
melt away enough to free him from the door. They were also faced with the
prospect that Pooh would continue to eat (on the sly) during the course of the
43
44
Project Decisions: The Art and Science
project. That risk, which should be given both a high impact and a high probability, could significantly increase project duration.
Phase 3. Quantitative Analysis
After the mathematical model is ready, the analysis may include a number
of steps, depending on the situation. It is possible to apply simulation techniques to analyze the project. These techniques can give project managers
enough data to make an informed decision.
Even with the most advanced analytical tools and techniques, interpretation
of the results of an analysis is performed subjectively by project managers;
therefore, it is subject to the types of mental traps discussed in Chapter 2. For
example, quantified analysis may show that the chance that a project will be
completed on time equals 80%. Is this acceptable? It may be in some projects,
not in others. In addition, the results of quantitative analysis must be communicated properly to decision-makers to minimize the potential for biased
decisions.
Quantitative methods such as sensitivity analysis, Monte Carlo analysis, and
decision tree analysis are described in Chapter 11 of the PMBOK® Guide.
n
Step 3.1. Determining What Is Most Important
A model of a project can include a considerable number of variables: large
numbers of tasks, resources, risks, and other parameters. Some of these
parameters may significantly affect the course of the project. For example,
certain risks will cause failure of the project, whereas other risks will have no
noteworthy effect. It is impossible for a project manager and a project team
to concentrate their efforts on mitigating all possible risks. The team should
therefore focus first on mitigating critical risks.
To determine which project parameters are the most critical, project managers
can use sensitivity analysis, which is described in detail in Part 4 of this book.
In the Pooh situation, the risk associated with feeding Pooh would probably have the
most effect on the project duration and was therefore a critical risk. To mitigate this
risk, Rabbit set up a poster, “Do Not Feed Bear.”
n
Step 3.2. Quantifying Risks Associated with the Project
Uncertainties associated with input parameters were already quantified during the modeling step. Now you need to analyze how the combination of
all these uncertainties could affect the project. The goal of this analysis is to
Understanding the Decision Analysis Process
create a “risk profile” of the project. You may need to know the following
information:
n
n
n
The chance that the project will be completed within a certain period
and on budget
The project’s success rate, or the chance that it will be completed
The low, average, and high estimates for duration, cost, and other
project parameters.
Again, a number of analytical techniques can be applied to this analysis.
Here is the result of the analysis of Pooh’s project based on the success criteria identified during the decision-framing stage. There were three alternatives:
n
n
n
n
“Excavate Pooh.” There was a 100% chance of damaging Rabbit’s home, a
significant chance of harming Pooh, and a very significant chance that the
project would be completed within a few days.
“Blast out Pooh.” There was a 100% chance of damaging Rabbit’s home, a
very significant chance of harming Pooh, and a very significant chance that
the project would completed almost instantly.
“Slim down Pooh.” There was zero chance of damaging Rabbit’s home, zero
chance of harming Pooh (although he might have an extended period of relative deprivation), and large uncertainties in the project duration.
Step 3.3. Determining the Value of New Information
A useful decision analysis technique is to assess the value of new
information.
For example, Gopher needed to estimate the duration of the excavation project to
remove Pooh from the doorway. Gopher could perform exploratory excavation, but
it could be costly and time-consuming. This analytical technique helps establish the
value of new information—how much money can be saved if additional information
is obtained through an exploratory excavation.
n
Step 3.4. Deciding on a Course of Action
In some cases, it is easy to select the most efficient alternatives based on the
results of risk analysis. The best alternative based on selected success criteria
may be obvious and can be easily selected without further steps.
In many situations, however, the selection between the alternatives is not so
easy. Sometimes, different scenarios are executed only if certain conditions
45
46
Project Decisions: The Art and Science
exist. In many cases, decisions are made using numerous criteria, which complicates the selection of the most efficient alternative.
In the Pooh example, the decision was based on multiple criteria. The safety of Pooh
was the first priority; therefore, the blasting alternative had to be rejected. The excavation alternative was also rejected because it did not provide adequate safety and could
cause substantial damage to Rabbit’s house. Therefore, despite concerns about project
duration, the slimming-down alternative was selected. Interestingly, in a Russian
cartoon version of the same Pooh story made in the early 1970s, Pooh’s friends and
Pooh himself decided that he would not be able to withstand the deprivation imposed
by the slimming alternative, so they just yanked him out, causing a great deal of
structural damage to Rabbit’s house in the process. Does this say something interesting about the differences between Western and Soviet psychology? Or perhaps the
producers of the cartoon were on a limited budget and decided that having the characters forcefully dislodge Pooh was cheaper to produce and therefore a better choice.
Phase 4. Implementation, Monitoring, and Review
Phase 4 involves two steps.
n
Step 4.1. Project Implementation and Monitoring
Now the decision has been made, and the selected course of action is under
way. But what if, in the middle of the project, an unforeseen event occurs,
causing the plan to deviate? Luckily, there is a valuation model of the selected
project alternative (created in step 1.5), and the project manager can update
the model, perform a new analysis, and make a decision. It is very important
to track project performance constantly and analyze all potential pitfalls and
opportunities. In many cases, a new decision-framing step will be required if
a new decision within the same project is required.
Tracking project performance helps you to forecast what could happen to the
project, even if some activities are only partially completed. Before the project
started, you had only one source of input information for the decision analysis process: historical data, which is either objectively defined based on certain records or is the result of expert judgment based on past experience. Now
the project manager can also use actual project performance to make decisions. This process for continually improving decisions by learning from the
outcomes of earlier decisions is why adaptive management is so powerful.
Pooh’s friends continually checked Pooh’s slowly shrinking girth, trying to estimate
when he would be slim enough to pop out. Eventually, when their measurements
indicated that the time was ripe, they managed to extract Pooh without damage to
either Rabbit’s home or Pooh himself.
Understanding the Decision Analysis Process
n
47
Step 4.2. Review of the Decision Experience
You need to know whether your analysis and decisions were correct. Otherwise, you will make the same mistakes all over again.
Apparently, in this situation, the decision was correct. Some small things could have
been done better. For example, the sign “Do Not Feed Bear” could have been installed
at the beginning of the project rather than after Gopher’s offer of food to Pooh.
Big and Small Decisions
When we ask project managers why a decision analysis process has not been
implemented in their organizations, they usually give some form of the following replies:
n
n
n
n
n
n
We don’t know what the decision analysis process means.
We already have processes, such as project management, and we don’t
need to introduce yet one more.
Decision analysis processes are not suitable for our organization or
our types of projects.
Our projects are small, and we make decisions based on our experience and intuition.
We are planning to implement the process in the future, but we are too
busy right now.
Decision analysis processes require significant resources, including
training that we don’t want to invest in right now.
Interestingly, most project managers use a number of answers from this list
instead of just one. However, the third answer (“Decision analysis processes
are not suitable for our organization or our types of projects”) happens to be
most common. Most managers believe that decision analysis is suitable only
for large projects. In their opinion, intuitive
decision-making is sufficient for small projects. But what differentiates a small project
from a large one? Is drilling one well that
Rule number one in project
costs $2 million a small project for a large
decision analysis: The
oil company? Maybe. But a $2 million software project is definitely a large project. So
process must be simple.
it is all relative to the particular industry or
organization.
48
Project Decisions: The Art and Science
We agree that small projects probably do not require as complex an analysis
as large projects. But we strongly advise against relying purely on intuitive
decision-making for a project of any size.
Table 3.1 offers some advice on how you can tailor the decision analysis process to different types of decisions:
In any case, remember that the process should be as simple as possible. If you
suggest a full-blown process for your organization, and your organization is
not ready for it, it will kill the whole idea (and any hope we have of selling
more books to your colleagues). In addition, remember that in 99 percent of
cases, project decision analysis is simply an exercise in rational thinking.
Type of Decision
Small tactical decisions
during the course of
projects
Important decisions
concerning small
projects or tactical
decisions in large
projects
Strategic project
decisions
Strategic enterprisewide decisions
Suitable Decision Analysis Process
Try to process information logically by
answering a few simple questions:
• What is the problem?
• What do we want to achieve?
• What are the uncertainties?
• What are the alternatives?
• What will happen if each alternative is
implemented?
You may use some components of
the process described in this chapter,
whatever you find easy to implement
and useful. For example, you may start
with decision-framing with some simple
analysis.
Apply the decision analysis process
described in this chapter for a
comprehensive evaluation of alternatives.
Use a consistent, continued, and
comprehensive decision analysis process
for all project decisions within a portfolio.
Table 3.1 Decision Analysis Process for Different Types of Projects
Some Comments
This is actually a thinking
exercise.You don’t need
to create any paperwork
or assemble a committee,
but you may have a
meeting with team
members.
This is the first step
toward a formalized
decision analysis process
in the organization.
If the complete project
depends on this decision,
a full decision analysis
process will be useful.
Enterprise-wide decisions
should be made based on
comprehensive analysis
of alternatives, with
continued monitoring of
results.
Understanding the Decision Analysis Process
49
The Value of Project Decision Analysis
We often hear this question: “Does a decision analysis process bring any benefits or it is just extra paperwork?”
Clemen and Kwit (2001) studied the use of decision analysis at the Eastman
Kodak company. They analyzed the decision-making in 178 projects that
were carried out over a period of ten years. The projects included new product brainstorming, vendor selection, emission-reduction analysis, process
analysis, and others. The project durations varied from 20 hours to one year.
Clemen and Kwit were trying to determine an incremental dollar value generated by decision analysis. In most cases it was hard to measure the actual
value added to Eastman Kodak’s business, but their estimate was that for
all the projects combined, decision analysis added more than $1 billion in
value. The average value per project was between $6.65 million and $16.35
million. In addition to the monetary benefits, the decision analysis added
value by promoting careful thinking about strategies, facilitating discussion
among stakeholders, and providing a common framework for risk analysis
and decision-making within the company. Clemen and Kwit concluded that
even though it was hard to measure value in specific projects, decision analysis brought substantial value to the company.
n
n
n
n
n
The decision analysis process is an integrated set of procedures and tools
that help project managers make rational choices. Decision analysis is not a
single, concrete prescriptive process, but rather an adaptable process framework that can be tailored to the specific needs of an organization.
Decision analysis can be integrated with other business processes, including
project management.
The fundamental principles of decision analysis are comprehensiveness,
continuity, and consistency. Decision analysis implies a comprehensive
and repeatable analysis of the business situation and an evaluation of
alternatives.
The four main phases of the decision analysis process are (1) decision-framing; (2) modeling the situation; (3) quantitative analysis; and (4) implementation, monitoring, and review of the decision.
Research shows decision analysis processes can add significant value to an
organization and can improve its performance.
Chapter 4
What Is Rational Choice?
A Brief Introduction to
Decision Theory
D
ifferent organizations and individuals use different preferences and
principles to select policy alternatives. We call those preferences and
principles an organization’s “decision policy.” An important part of
an organization’s decision policy is its attitude toward risk.
In this chapter we look at what it means to make rational decisions. We examine the concept of expected value and the normative expected utility theory,
which provides a set of axioms, or rules, for how rational decisions should be
made. Finally, we look at prospect theory, which is a descriptive approach to
understanding decision-making.
Decision Policy
Decision policy is the set of principles or
preferences that an organization uses when
selecting its policy alternatives. The organization’s attitude toward risk is a key component of its decision policy.
The art and science of
decision-making is applying
decision policy to make
rational choices.
A decision policy reflects the attitude of an
organization toward its objectives. The policy is a function of many parameters, such as
client requirements, corporate culture, organizational structure, and investor
relationships. In most cases, decision policies are not written; they an unwritten understanding that evolves over time with organizational changes, and
they are understood by the managers. However, even though decision policies are usually an informal understanding, they are very difficult to change,
even if directed by executive management.
In addition to an organization’s attitude toward risk, a decision policy includes
attitudes toward cost, customer satisfaction, safety, quality, and the environment, among other parameters. When an organization makes its choices, it
52
Project Decisions: The Art and Science
puts a premium on some parameters and downplays others. The problem is
that different objectives often conflict. For example, maximizing shareholder
value in the short term may conflict with a long-term research and innovation
agenda.
How much risk to take? How to protect against it? How to balance risk-taking with other organizational goals? Consider the example of Pfizer, one of
the world’s largest pharmaceutical companies.
In 2006 Pfizer was in the process of launching six new medications (Simons 2006a).
Each was expected to generate at least $1 billion in revenue annually. Interestingly,
only one of them, Champix, an anti-smoking drug, was discovered through Pfizer’s
own research division. The others were acquired when Pfizer bought other companies.
In this manner Pfizer acquired two of its most successful drugs—Lipitor, a cholesterol-lowering pill, and Celebrex, a pain reliever. In 2000, Pfizer acquired Lipitor
when it purchased Warner-Lambert for $84 billon. Since then, Lipitor has become one
of the top-selling drugs in the world, generating an estimated $12.9 billon in annual
revenue—more than world giants such as Marriott or Oracle.
The development process for new drugs is rife with risks and uncertainties.
Only a small percentage of medications that are pursued by researchers actually reach consumers. There are numerous tests, clinical trials, and finally a
complex Food and Drug Administration (FDA) approval process. The FDA
is under intensive public scrutiny and therefore is very risk-averse. If there
is any indication of significant side effects, new medications do not pass the
FDA approval process, an outcome that can dramatically affect the pharmaceutical company’s bottom line.
The drug-approval process does not apply to the production of other goods,
such as axes or shovels. Risks and uncertainties are present in every business,
but some involve much more risk than others. Designing and manufacturing
garden tools has some risks, but they are relatively much smaller—there is no
Axe and Shovel Administration to approve your tool. To get a medicine from
a research proposal through the final approval requires a pharmaceutical company to invest significant time and money. Alternatively, if there are not many
potential drugs in the pipeline, a pharmaceutical company like Pfizer can purchase a business with promising projects by paying a very hefty price.
In the Pfizer example, different companies were willing to take on varying
levels of risk depending upon their decision policy. For the most part, the
decision policy regarding tolerable risk levels is motivated by a desire to
create wealth; however, there are other objectives a business may want to
achieve.
What Is Rational Choice? A Brief Introduction to Decision Theory
Different companies have different attitudes
toward risk. Junior pharmaceutical companies are often less risk-averse than more
established ones. But the established companies may have the means to pay the companies that assumed this risk.
Decision policy is a set of
principles or preferences
used for selecting
alternatives.
For a different example, here are the basic
components of the decision policy of Don
Corleone’s enterprise in Mario Puzo’s The Godfather (Figure 4.1). This design
policy would include a strong emphasis on:
n
n
n
n
Profitability
Security of its own employees with a special concern for
management
Organizational structure, including clear definitions of roles, responsibilities, and reporting
Fostering good relationships with the local community.
And a low regard for:
n
The safety of adversaries
n
Legal rules and regulations.
53
What was Don Corleone’s decision policy? That is, what was his attitude
toward risk? Was he a risk-taker or a risk-averse leader?
Which Choice Is Rational?
All decision-makers try to make rational decisions. But before we can describe
how you can make rational decisions, let’s first try to understand what the
term rationality means.
Reid Hastie and Robyn Dawes (2001) define rationality as “compatibility
between choice and value” and state that “rational behavior is behavior that
maximizes the value of consequences.” Essentially, rational choice is an alternative that leads to the maximum value for the decision-maker. It is only
through the prism of an organization’s decision policy that we can judge
whether or not a decision is rational. Because decision policies can be different, your rational decision can appear completely irrational to your friend
54
Bettmann/Corbis
Project Decisions: The Art and Science
Figure 4.1 Marlon Brando as Vito Corleone in The Godfather
who works in another company. This holds true not only for organizations
but also for individuals, project teams, and countries. It is very important to
remember that when you work with a project team, decisions should be made
based on a consistent decision policy.
Returning to our Godfather example, were Vito Corleone’s decisions rational
or irrational? Our answer is that he was a rational decision-maker because,
according to our definition of rationality, he followed the decision policy of his
enterprise. In other words, he always followed the fundamental rules on which
his organization was based. What this analysis does not tell us is whether, from
the rest of society’s point of view, this was a good decision policy.
Expected Value
One method of evaluating multiple alternatives is to apply the concept of
expected value. Let’s begin our discussion of this concept with a simple example of a decision driven by a single objective. Consider that a big pharmaceutical company has two choices:
1. It can continue to develop a drug in which it has invested $200 million
in research and development. The chance that it will get FDA approval
is 80 percent. If the drug is approved, the company will earn $800 mil-
55
What Is Rational Choice? A Brief Introduction to Decision Theory
lion in profit (80 percent chance). But
if it fails, the company will have lost
the $200 million in development costs
(20 percent chance).
2. It can buy another company that has
already developed an FDA-approved
drug. The estimated profit of this transaction is $500 million.
Expected value is a
probability-weighted
average of all outcomes. It
is calculated by multiplying
each possible outcome by its
probability of occurrence and
then summing the results.
This problem can be represented by using
a decision tree (Figure 4.2). There is a simple
procedure to calculate the indicator. You simply multiply the probability by the outcome
of the event. In the first case, the company has an 80% chance (the probability
that the FDA will approve the drug) of earning $800M: therefore, the expected
value is $800M x 80% = $640M. If the FDA rejects the drug (20% chance), the
expected value will be $-200M x 20% = $-40M. From a probabilistic viewpoint, the company can expect to receive $600M from developing its own
drug: $640M – $40M = $600M.
This number ($600M) is the expected value of the drug development project.
Now we can compare this value to the alternatives. The expected value if the
company develops its our own drug ($600M) is higher than the profit forecasted if it buys the other company ($500M). If the objective is to maximize
revenue, the choice is clear; the company should develop its own drug. The
arrow on Figure 4.2 represents that choice. Outcomes can also be expressed
as duration, cost, revenue, and so on. If the outcome is defined in monetary
units, expected value is called expected monetary value, or EVM.
FDA Approval
80%
$800M
Develop own
No FDA Approval
Strategy
Decision
20%
Buy Company
Figure 4.2 Decision Tree
-$200M
$500M
56
Project Decisions: The Art and Science
Basically, we combined two outcomes using the probability of their occurrence. Because we cannot have a drug that is approved by the FDA and not
approved by the FDA at the same time, expected value does not represent
actual events. It is a calculation method that allows us to integrate risks and
uncertainties into our decision analysis of what might happen.
In the real world, drug companies perform a very similar process. Of course,
the underlying valuation models they use are much more complex with more
alternatives, risks, and uncertainties, so their decision trees can become quite
large. We will cover quantitative analysis using decision trees in Chapter 15.
The St. Petersburg Paradox
Almost 300 years ago, the Swiss scholar Nicolas Bernoulli came up with an
interesting paradox. He proposed a game, which looked something like this:
1. You toss a coin and if tails come up, you are paid $2.
2. You toss the coin a second time. If you get tails again, you are paid $4;
otherwise, you get nothing and the game is over.
3. If you get tails a third time, you are paid $8; otherwise, you get nothing and the game is over.
4. The fourth time you may get $16, the fifth time, $32; and so on.
In theory, you can continue indefinitely and might win a lot of money. In fact,
according to the expected-value approach, you can win an infinite amount of
money, as shown in Table 4.1.
Expected
Toss
Payoff
Probability
Value
1
$2
50%
$1
2
$4
25%
$1
3
$8
12.5%
$1
4
$16
6.25%
$1
Table 4.1 Bernoulli’s Coin Tossing Game
Total Expected Value
of the Game:
Sum of the Expected
Values after Each Turn
$1
$2
$3
$4
Infinite amount of money
What Is Rational Choice? A Brief Introduction to Decision Theory
Would you play this game? In reality, most people are not willing to risk a lot
of money when they play. If they win for a while and the payoff gets larger,
it becomes less likely that they are willing to stay in the game. The paradox
lies in the question of why people don’t want to try to win an infinite amount
of money if it costs them nothing to try. The only thing they risk is ending up
back where they were before they started the game.
This kind of game probably sounds familiar, for it is the basis for the popular
TV show Who Wants to Be a Millionaire? You can argue that the game is not the
same because the answers are not random. But unless you are a genius or an
extremely lucky guesser, as the payoff grows and the questions get more difficult, you will probably need a wild guess to win. Sometimes people want to
take a chance and give a random answer, but sometimes they don’t, so they
take the money instead of continuing to play the game. People like to watch
this game not only because of its interesting questions but also because of the
way it highlights this particular aspect of human psychology.
In 1738 Nicolas’s cousin, Daniel Bernoulli, proposed a solution to this problem
in the Commentaries of the Imperial Academy of Science of Saint Petersburg. This
game was named the “St. Petersburg Paradox.” Bernoulli suggested that we
need to take into account the value—or utility—of money to estimate how useful this money will be to a particular person. Utility reflects the preferences of
decision-makers toward different factors, including profit, loss, and risk.
Utility is a highly subjective measure. What is the relationship between utility and objective measures, such as wealth or time? Bernouilli’s idea was that
“twice as much money does not need to be twice as good.” The usefulness, or
utility, of money can be represented on a graph as a curved line (Figure 4.3).
As you can see, the value of additional money declines as wealth increases.
If you earn $1 million per year, an extra $10,000 will not be as valuable as it
would be to somebody who earns $100,000 per year.
We need to be able to measure utility. The scale of the utility axis can be measured by arbitrary units called utils. It is possible to come up with a mathematical equation that defines this chart. The chart of the mathematical equation is
called the utility function. The function represents a person’s or organization’s
risk preferences, or their risk policy. Risk policy is the component of decision
policy that reflects an attitude toward risk.
Risk-Taker vs. Risk-Avoider
We have discussed how some companies and individuals can be risk-avoiders or risk-takers depending on their risk policy, which is part of their general
decision policy. We can now explain it using the utility function (Figure 4.4).
57
58
Utility
Project Decisions: The Art and Science
Objective Measure
(Money)
Figure 4.3 Utility Function
1. A risk avoider will have a concave utility function. Individuals or businesses purchasing insurance exhibit risk-avoidance behavior. The
expected value of the project can be greater than the risk avoider is
willing to pay.
2. A risk-taker, such as a gambler, pays a premium to obtain risk. His or
her utility function is convex.
Utility
Risk Neutral Decision-Maker
Risk-Avoider
Risk-Taker
Objective Measure
Figure 4.4 Using the Utility Function to Depict Risk Behavior
What Is Rational Choice? A Brief Introduction to Decision Theory
3. A risk-neutral decision-maker has a linear utility function. His or her
behavior can be defined by the expected value approach.
Most individuals and organizations are risk-avoiders when a certain amount
of money is on the line and are risk-neutral or risk-takers for other amounts
of money. This explains why the same individual will purchase both an insurance policy and a lottery ticket.
An example of an ultimate risk-taker is James Bond. When the world is about
to be taken over by a villain, who are we most likely to see jumping into a
shark-infested pond with only swim trunks and a pocketknife to save the
day? According to Bond’s risk policy, the more dangerous the situation, the
more likely he is to take the risk.
Expected Utility
Utility function can be used in conjunction with quantitative analysis to
reflect a risk policy when selecting particular alternatives. Let’s try to apply
the utility function to the analysis of the strategic decision-making by the
pharmaceutical company we discussed above (see the decision tree shown in
Figure 4.2).
The risk policy of the pharmaceutical company is represented by the utility
function in Figure 4.5. Using this chart, we can get a utility associated with
each outcome. Arrows on the chart show how to get utility for the “buy company” outcome. The utility of the “buy”outcome of $500M equals 4.5. However, in most cases it is better to use a mathematical formula for the utility
function rather than the chart.
Table 4.3 shows the results of each outcome.
Expected utility is similar to expected value, except instead of using the outcomes,
it uses utilities associated with these outcomes. Expected utility is calculated by
multiplying the utility associated with each possible outcome by the probability of occurrence and then adding the results. In our case the expected utility of
the “develop own drug” alternative equals 0.50 (no approval outcome) + 3.68
(FDA approval outcome) = 4.18. The utility for the “buy company” alternative
is 4.5. So, based on utility theory, we should buy the company.
In this example we see an interesting phenomenon: Using the expected value
approach, the company should select the “develop own drug” alternative.
Using the expected utility approach, the company should select the “buy
company” alternative. Why? This company is risk-averse and the expected
59
60
Project Decisions: The Art and Science
4
Utility
3
2
1
0
-200
0
200
400
600
800
Revenue ($ millions)
Figure 4.5 Using the Utility Function to Select an Alternative
utility approach incorporated the company’s risk profile. The company does
not want to accept the risk associated with the potential loss that could occur
if it attempted to develop its own drug.
Expected Utility Theory
Euclid, the Greek philosopher and mathematician, developed the postulates
for plane geometry. They include all the necessary assumptions that apply
in plane geometry, from which the entire theory was derived. John von Neumann and Oskar Morgenstern attempted to do a similar thing in decision
science.
Axioms of the expected
utility theory are conditions
of desirable choices, not
descriptions of actual behavior.
In their book Theory of Games and Economic
Behavior, von Neumann and Morgenstern
proposed the expected utility theory, which
describes how people should behave when
they make rational choices. They provided a
set of assumptions, or axioms, which would
be the rules of rational decision-making. To
a certain extent, they were trying to build a
logical foundation beneath decision analysis
61
What Is Rational Choice? A Brief Introduction to Decision Theory
Outcome Name
Develop own drug (no FDA approval)
Develop own drug (FDA approval)
Buy company
Outcome
–$200
$800
$500
Utility
2.5
4.6
4.5
Probability
20%
80%
Table 4.3 Calculation of Expected Utility
theory. The book is full of mathematical equations. To avoid mathematical
discussions, we will cover just a few of their basic ideas:
1. Decision-makers should be able to compare any two alternatives based
on their outcomes.
2. Rational decision-makers should select alternatives that lead to maximized value in at least one aspect. For example, project A and project
B have the same cost and duration, but the success rate of A is greater
than the success rate of B. Therefore, project A should be selected.
3. If you prefer a 10-week project as opposed to a 5-week project, and a 5week project to a 3-week project, you should prefer a 10-week project
to 3-week project.
4. Alternatives that have the same outcomes will cancel each other out.
Choices must be based on outcomes that are different. If project A and
project B have the same cost and duration but different success rates,
the selection between the two projects should be based on the success
rate, the only differing factor.
5. Decision-makers should always prefer a gamble between the best and
worst outcomes to ensure an intermediate outcome. If project A has
guaranteed revenue of $100 and project B has two alternatives—a complete disaster or revenue of $1,000—you should select project B if the
chance of a complete disaster is 1/100000000000….
Some of these axioms are just common sense, but they are the necessary
building blocks of decision theory. Von Neumann and Morgenstern mathematically proved that violation of these principles would lead to irrational
decisions.
62
Project Decisions: The Art and Science
Extensions of Expected Utility Theory
A number of scientists have suggested that the axioms of Von Neumann and
Morgenstern unreasonably constrain the manner in which we make choices.
In reality, people don’t always follow the axioms, for a number of reasons:
n
n
Often, people make rational decisions, but not as von Neumann and
Morgenstern conceived them. They may not have complete or perfect
information about the alternatives. In addition, people often cannot
estimate the advantages and disadvantages of each alterative.
Even if people make rational decisions, there are still a number of
exceptions to the axioms.
In spite of these and other observations, scientists continued to come up with
explanations for the expected utility theory and developed a number of extensions to the theory. As a result, currently there is no single accepted expected
utility theory. Expected utility theory is now a family of theories explaining
rational behavior.
Leonard Savage (1954) focused his extension of expected utility theory on
subjective probabilities of outcomes. For example, if a type of project has
never been done, it is hard to determine the probability of the project’s success. However, according to Savage’s theory, it makes sense to consider subjectively defined probability.
How to Use Expected Utility Theory
The axioms of expected utility theory were intended to serve as the definition of a rational choice. In reality, project managers will never use the set
of axioms directly. If you need to select a subcontractor for a project, the last
thing you are going to do is open the Von Neumann and Morgenstern book,
peruse a dozen of pages of mathematical equations, and after couple of weeks
of analysis come up with your conclusion (which still has a chance of being
wrong). Doing such a thing would in itself be absolutely irrational.
When you take a measurement of a building’s wall, you don’t think about
Euclid’s axioms, but you do use methods and techniques derived from his
axioms. It is the same situation with expected utility theory when you are
attempting to understand how to best maximize the value of your projects:
n
You may read about best practices in one of the many project management books available.
What Is Rational Choice? A Brief Introduction to Decision Theory
n
Your consultant may recommend some useful project management
techniques.
n
You may use the quantitative methods described in this book.
n
You may try to avoid psychological traps when you make decisions.
Keep in mind that there is a foundation for all these activities. It is decision science, of which expected utility theory is one of the fundamental
components.
Descriptive Models of Decision-Making
Von Neumann and Morgenstern considered expected utility theory a normative theory of behavior. As we noted in Chapter 1, normative theories do
not explain the actual behavior of people; instead, they describe how people
should behave when they have made rational choices.
Psychologists have attempted to come up with descriptive models that explain
the actual behavior of people. Herbert Simon proposed that people search for
alternatives to satisfy certain needs rather than to maximize utility functions
(Simon 1956). As a project manager, you probably will not review all your previous projects to select the subcontractor that has the highest overall utility for
your project. Instead, you will choose the subcontractor that best satisfies your
immediate requirements: quality of work done, reliability, price, and so on.
Daniel Kahneman and Amos Tversky developed a theory of behavior that
helps to explain a number of psychological phenomena, which they called
the prospect theory (Kahneman and Tversky 1979). They argued a person’s
attitude toward risk is different from his or her attitude toward losses. Here is
a question for you as a project manager. Would you prefer:
A.A project with an absolutely certain NPV of $100,000
B. A project with a 50% chance of an NPV of $200,000?
Most likely you would select A. But let’s reframe the question. Which would
you prefer between these two:
A.A sure loss of $100,000
B. A 50% chance of loss $200,000?
Most likely, you would prefer option B. At least, this was the most frequent
answer from the people that participated in a survey.
63
64
Project Decisions: The Art and Science
This “loss aversion” effect can be demonstrated using a chart (Figure 4.6).
Kahneman and Tversky replaced the notion of utility with value, which they
defined in terms of gains and losses. The value function on the gain side is
similar to the utility function (Figure 4.3). But the value function also includes
a steeper curve for losses on the left side compared with the curve for gains.
Using this chart, you can see that losses of $100,000 felt much stronger than
gains of $100,000.
Unlike expected utility theory, prospect theory predicts that people make
risk-averse choices if the expected outcome is positive, but make risk-seeking
choices to avoid negative outcomes. Everything depends on how choices are
framed or presented to the decision-maker.
Another interesting phenomenon explained by prospect theory is called
the endowment effect, which asserts that “once something is given to me, it
is mine.” People place a higher value on objects they own than on objects
they do not. In project management, these can be resources. It explains why
most project managers continue to use materials they have purchased, even
though a better material may be available.
Value
-$100,000
Losses
Figure 4.6 Value Function in the Prospect Theory
+$100,000
Gains
What Is Rational Choice? A Brief Introduction to Decision Theory
65
Prospect theory also explains zero-risk bias, which is the preference for reducing a small risk to zero, rather than having a greater reduction to a larger
risk. It is important in project risk analysis because project managers usually
like to avoid smaller risks rather than expend effort to mitigate more critical
risks.
n
n
n
n
n
Different organizations and individuals have different decision policies, or
sets of preferences, for selecting alternatives.
Rational choice is an alternative that leads to maximum value for the decision-maker. Rational choices should be made based on decision policy.
Expected value helps to make a choice between different alternatives. In
many cases, it helps to come up with a good decision.
Expected utility theory is the family of theories of rational behavior.
Expected utility helps to incorporate risk profiles into the decision-making
process.
Tversky and Kahneman’s prospect theory is the most widely accepted alternative to expected utility theory. It provides a more accurate description of
how people actually make decisions.
Chapter 5
Creativity in Project
Management
Creativity is the power to connect the seemingly
unconnected.
—William Plomer, South African
author
(1903–1973)
C
reativity is an essential component of successful project management.
Psychologists have developed different theories explaining the process of creative thinking. Our ability to come up with creative solutions
can be constrained due to creativity blocks, such as stereotyping, inability to
see problems from another perspective, or fear of the “far out” alternative.
Cultural and organizational blocks such as those related to corporate culture
can significantly constrain the creative process in project management.
Creativity and Decision-Making
This book is about decision analysis processes, which we believe will help
you make better project decisions. But where does creativity fit in? Does decision analysis prevent the discovery of original, nonstandard solutions or the
selection of creative alternatives?
Creativity is related not only to technological innovations but also to the way
we manage projects. Consider these problems:
n
n
n
You have limited financial resources, but an ambitious project development plan. How do you spend these resources wisely?
How do you motivate a team that has gone through a number of painful project failures?
How do you break a seemingly endless chain of client-driven changes
without alienating your clients?
We usually think of creativity as it relates to art, science, and technology. In
this book we are concerned only about how it relates to project management.
68
Project Decisions: The Art and Science
We think that human creativity, or “thinking outside the box,” will improve
the project-decision process.
Psychology of Creativity
What is creativity in project decision-making? Although it is hard to come up
with a formal definition of creativity, it can be described as the ability to find
an alternative way to perform a project that has at least three attributes: it
should be (1) new, at least for the current project; (2) feasible; and (3) useful.
Understanding creativity is a new and growing
field of inquiry in psychology. Scientists trying
Creative project alternatives to explain it have come up with a number of
theories. One of the theories explains creativity
are new, practical ways
as a function of self-actualization. The psychologist Abraham Maslow (Maslow 1987; Davis
to perform the task more
2004) developed a hierarchy of human needs,
efficiently.
which is a model of wholeness and well-being.
At the bottom of the hierarchy are the most
basic needs for physical sustenance and safety.
At the top are esteem and self-actualization (Figure 5.1). Basically, self-actualization is the drive to reach one’s potential by fulfilling the desire to do
something unique.
SelfActualization
Esteem Needs
Belonging Needs
Safety Needs
Physiological Needs
Figure 5.1 Maslow’s Hierarchy of Needs
69
Creativity in Project Management
Some psychologists believe that creativity is related to our ability to make
new mental associations to an object or concept (Campbell 1960; Mednick
1962; Staats 1968). When people learn a new concept, their minds produce
variations in which they associate the concept with something they already
know. More creative people produce more of these variations. The range of
variations depends on a person’s experience, knowledge, and environment,
as well as some innate abilities.
As a project manager mulls over a problem, he or she comes up with a range
of solutions (Figure 5.2). These solutions can be generated by associating the
problem with similar ones in previous projects. Sometimes the solution can
be related to personal experience, knowledge of other business areas, or even
stories and anecdotes. (If you recall, we structured Chapter 3 around the story
of Pooh’s being stuck in Rabbit’s door as a way of illustrating how choices are
made.) The general idea is that the more variations available, the better the
chance that creative alternatives will be found.
Can you have too many creative ideas—so many and so innovative that you
lead your project, and maybe your company, right over the cliff? There are a
number of techniques that you can use to channel and control creative alternatives. One of most straightforward methods involves filters.
Block
Solution
Solution
Solution
Solution
Solution
Solution
Problem
Solution
Block
Block
Solution
Solution
Filter 1
Figure 5.2 Example of Creative Process with Blocks and Filters
Filter 2
70
Project Decisions: The Art and Science
Assume that you managed to come up with many creative alternatives. For
example, you have at least five ideas that address the problem of how to
complete a project on time with your existing resources. In creative decisionmaking, a filter is a set of conditions used to test a proposed solution. If the
solution does not satisfy these conditions, it will not pass through the filter
and will not be considered during later stages of the analysis. Examples of
these filters are:
1. Does this solution actually help to complete the project on time?
2. Is it possible to implement this course of action given project
constraints?
Individuals use a similar mental strategy to make intuitive choices. Psychologists call this heuristic elimination by aspect (Tversky 1972), which is discussed in
Chapter 19. The difference between elimination by aspect and the filter method
is that the filter technique is a formalized analytical approach. Filters need to be
set up very carefully to avoid blocking potentially good solutions.
A great example that demonstrates the process of creative thinking is Dan
Brown’s bestseller The Da Vinci Code (2003). In the book, symbologist Robert
Langdon is involved in a project to uncover ancient secrets. What is so interesting about his creative process?
n
n
n
n
Langdon uses creative analogies to come up with a significant number
of alternatives. Some of them are “far-out”; however, Langdon still
considers them before making a final judgment.
Langdon applies certain filters. He tests the solutions when he solves
the puzzles. In these tests, he analyzes whether these solutions actually make sense.
Langdon has the capability to come up with so many creative alternatives because he relies on his extensive knowledge and experience as a
symbologist.
Langdon’s creative abilities are stimulated by the considerable stress
brought about by the police and various shadowy figures who are
pursuing him. In Langdon’s case, finding creative solutions is not an
exercise in curiosity, but a matter of survival. (Figure 5.3).
Creativity Blocks
Despite our natural penchant to come up with creative solutions, our ability
to do so is often blocked. Certain creativity blocks will not allow us to come up
Creativity in Project Management
Figure 5.3 Finding Creative Solutions
with innovative solutions. One way to enhance our creativity is to remove or
at least weaken some creativity blocks. Clemen (1996) classified the blocks
this way:
Framing and Perceptual Blocks
These blocks affect how we perceive an original problem.
n
Stereotyping
A Microsoft staff photo taken in 1978 surfaced and made the rounds on the
Internet several years after it was taken. In it were 11 of the original Microsoft
staff, including Bill Gates and Paul Allen. Most of them were very young
and long-haired, and the group did not look like a very promising commercial enterprise, something like what is shown in Figure 5.4. The title of the
photo was “Would you invest in this company?” Typically, we try to fit all
potential solutions into a standard category. If we cannot fit something into
71
72
Project Decisions: The Art and Science
Figure 5.4 “Would You Invest in This Company?”
an existing category, we may block potentially good solutions. If you were an
investor, would the staff at Microsoft fit into your mental picture of a potentially successful company? Probably not, and because they didn’t fit into a
preconceived idea of what successful entrepreneurs look like, many investors
probably ignored Microsoft as a possible investment opportunity.
n
Tacit Assumptions
Let’s suppose that you are managing a software project. You are concerned
about the software’s performance, so you spend the majority of your efforts
to make it faster than that of any of your competitors. However, performance
may not be the appropriate consideration. Hardware performance is improving all the time, and there is a good chance that by the time you complete the
project most people’s computers will be so powerful that differences in the
software’s speed will be negligible. In this case you made an assumption—
speed is the most important thing—that might not have been appropriate.
Creativity in Project Management
n
Not Seeing the Forest for the Trees
As managers, we have to deal with a large volume of paperwork involving various organizational and management functions. While some of it may
be unnecessary, in many cases the pile of papers contains a huge number of
important project details that you need to know. Unfortunately, the amount
of information you need to analyze may be so great that you cannot see the
creative alternatives.
n
Inability to See the Problem from Another Perspective
Many project managers approach a problem from their own perspective.
Even if they think they are doing everything possible to satisfy their client’s
requirements, they may not be. Different project stakeholders have different objectives and their own ideas to contribute, and truly creative solutions
should satisfy as many of these as possible. However, if you are not able to
understand what other parties on your project want, you will be blocked from
finding creative solutions.
Value-Based Blocks
These blocks are related to our values and preferences. In some cases, these
values block our ability to find creative solutions.
n
Fear of the “Far Out” Alternative
Very often we block a good alternative because we consider it too risky or
impossible to implement. Sometimes we are even afraid to come up with an
alternative ourselves because we do not want to look silly. But not offering
risky or “far-out” alternatives can interfere with our ability to think creatively.
Offering risky alternatives is a technique that helps us better understand and
frame a problem.
n
“Do Nothing” Bias
Many people have an inherited bias toward the status quo. Basically, this is
another way of describing inertia. However, decision-making implies that at
least one alternative different from the status quo or “do nothing” should
be considered; otherwise, there is no need for a decision at all. Considering
alternatives to the status quo is part of the continuous improvement process,
which is one of the foundations of project management.
73
74
Project Decisions: The Art and Science
n
Response to Criticism
After spending considerable time and effort, you came up with what you
thought was a good suggestion, but your boss dismissed it: “What a silly
idea!” How would you react? If you are like most of us, you probably will
not bother again. Unfortunately, whether it was a bad suggestion or not, your
own reaction to this criticism may mean that your creative process becomes
blocked not only for this particular project but also for the many projects that
you will be part of in the future.
First of all, you should not block your creative thinking as a result of criticism.
If possible, continue to work with your idea. Add supporting information
and improve your presentation. Also, ask your manager for more detailed
information about why your idea was rejected. Let your manager know that
you are willing to consider constructive criticism and learn how to use it to
improve your creative process. Failing to do so may indefinitely block your
creativity.
Cultural, Organizational, and Environmental Blocks
In his book Think! (2006), LeGault mentioned a curious phenomenon—that
Americans often make judgments based on Hollywood influences, which is
not necessarily the best way to see things. In another example, Dan Brown
overcame cultural blocks or taboos when he talked about particular issues
related to Christianity (Jesus as a husband and father) in The Da Vinci Code.
The book is definitely controversial; however, its success is based on its creative views on some very controversial issues.
The environment in which we live and work affects our creative thinking and
in some cases can block the selection of creative alternatives. In project management, the environment is primarily the corporate culture. A company’s
environment can stimulate or block creativity. Lack of trust between coworkers, communication difficulties in project teams and between different project
stakeholders, and excessive bureaucracy can significantly limit the abilities
of project contributors to conceive creative alternatives. Implementing decision analysis processes as merely another bureaucratic procedure can actually have an opposite effect by blocking creativity in organizations. We will
discuss the role of corporate culture in decision-making in Chapter 7.
In science fiction movies, time or space travelers often travel to another parallel universe or another dimension, where the inhabitants are unable to see
their true reality. Unfortunately, this type of “bounded reality” effect occurs
not only to characters in science fiction movies but also to members of project
teams. If a project manager and team members have worked together in a
Creativity in Project Management
company for a long time, they can develop “blind spots” where they live in a
type of bounded reality. These blind spots prevent them from seeing the bigger picture. In other words, they are unable to see creative solutions because
they have become enmeshed in a certain routine.
This effect is similar to selective perception, where new data is assimilated
into existing mental images rather than understood for what it really means.
A similar effect can be associated with different project stakeholders: clients,
different project teams, or project sponsors. At its worst, an organization’s
management can live in one reality and everybody else in another. Bringing
in external consultants, promoting people, or allowing mixed roles in project
teams will help remove such creativity blocks.
Another block related to our organizational environment is called premature
closing (Heuer 1999). Often, project managers must make decisions quickly—
sometimes within days, sometimes within hours, sometimes almost instantly.
In these cases, the project managers do not have the time or information to
make a proper analysis and generate a creative alternative. Frequently, after
the project manager has made the initial decision, new information that affects
the original decision arrives.
In many cases, the project manager does not revise the decision because
the organization applies pressure to maintain a consistent project plan and
vision. For example, could you imagine a situation in which you have just
asked your manager for more resources to complete your project, but the next
day you come up with a creative idea that doesn’t require the extra resources?
Would you approach your manager again to release the resources? Probably
not, in which case a creative alternative is blocked. Corporate environments
that support creative thinking encourage changes for the right reasons, even
if it means reversing a previous decision.
n
n
n
n
Finding creative project alternatives is one of the fundamental skills of
project managers.
Creativity theories use various psychological processes, including the
notion of self-actualization, preconscious mental activities, and the
generation of mental associations of concepts.
Creativity blocks prevent decision-makers from finding a creative
solution to a problem.
By setting up various creativity blocks, corporate culture can significantly affect our ability to make creative project decisions. Among
these blocks are premature closing and blind spots.
75
Chapter 6
Group Judgment and Decisions
G
roup judgments can be different from individual judgments. Although
the basic heuristics and biases that apply to individuals also apply at
the group level, a number of biases are specific to groups. Group discussions such as brainstorming may lead to better decisions than if they were
made by individuals. Game theory is a mathematical theory of human behavior in competitive situations, such as project management, in which players
interact.
Psychology of Group Decision-Making
Project managers do not operate in a vacuum, and important decisions in
project management are rarely made individually. They usually involve a
number of people and are the result of discussions between different stakeholders. For example, project managers collaborate with project team members and communicate with clients to develop a balanced project plan.
If decisions are made in groups, are they subject to the same mental errors
as those made by individuals? For example, do heuristics such as availability and representativeness, which we discussed in relation to individuals in
Chapter 2, work at a group level? Simply put, the answer is yes, individual
heuristics and biases continue to operate at a group level. Moreover, these
biases can be even stronger in groups than in individuals (Plous 1993). For
example, when estimating the duration of an activity, you, working alone,
may use a certain number as a reference point or anchor (say, four days) and
then come up with the range of durations using a reference point of between
three and five days (Figure 6.1). This bias results from the anchoring heuristic
(which we discussed in Chapter 2). A group may use the same reference point
(four days) but come up with a wider range (between two and six days).
A number of biases are specific to groups. One of them is called group polarization (Moscovici and Zavalloni 1969), where people are more likely to advocate
risky decisions after participating in group discussions. This effect has major
implications in project management. Group polarization leads to greater risktaking on the part of the group than would occur with individuals. For example, project managers may be more inclined to agree to a risky extension of a
project scope after a discussion with peers.
78
Project Decisions: The Art and Science
Anchor
Individual Estimate
1 day
2 days
3 days
4 days
5 days
6 days
7 days
8 days
Group Estimate
1 day
2 days
3 days
4 days
5 days
6 days
7 days
8 days
Range of Durations
Figure 6.1 Developing a Range of Activity Durations
Group polarization affects more than risk-taking. Group discussions can
amplify the preferences or inclinations of group members. If a project team
member already had an opinion regarding a certain issue, after a discussion
in a group he or she may have a much stronger opinion about the issue. In
one experiment, simulated juries were presented with weak incriminating
evidence. They became even more lenient after group discussion. At the same
time, juries presented with strong evidence became even harsher (Myers and
Kaplan 1976).
With this knowledge, it is fair to ask whether group discussions actually
improve the quality of decisions. In other words, are several heads better than
one? The psychologists’ answer is a qualified yes. The qualification is that it
depends on the type and difficulty of the problem. Some problems are better
handled in groups, while others are not. Reid Hastie (1986) reviewed three
types of problems:
1. Judgment of quantities is related to the estimation of project cost, duration, and other parameters. Groups are usually more accurate than
individuals in these types of decisions. Psychologists estimate that
group judgments can be 23–32 percent more accurate than individual
judgment (Sniezek and Henry 1989, 1990).
2. Logical problems are related (in project management) to finding solutions to complex business or technical issues. Groups perform better
than the average individual; however, very skilled or experienced
team members who act alone usually outperform the team.
Group Judgment and Decisions
3. Judgments in response to general knowledge questions are related to
finding factual data relevant to a project. Groups perform better than
the average individual. But the best member of the team usually equals
or surpasses the performance of the team.
Aggregating Judgment
Members of project teams often express differing opinions. Is it possible to
mathematically calculate the judgment of a group based on the judgments of
its individual members? That is, can we average, say, the cost and duration
estimates offered by different members of a group? And would doing so even
be useful? Psychologists and decision scientists have extensively researched
this problem (Goodwin and Wright 2004) and concluded that it is possible to
do so if members of the group have similar expertise and work in the same
environment. However, simple averaging of individual judgments can cause
major errors. It is like the average body temperature in a hospital. It is always
normal. Why? Because, while somebody may have a fever, there is also probably someone who is dead and therefore cold.
Is there a best way to come up with group judgments? The solution is to
organize the discussion within a team where the group as a whole makes a
decision. For example, while the Supreme Court justices may have different
opinions on a particular case, they deliver a common ruling in which they
basically aggregate their judgments. The problem is that it is not always possible to come to a consensus as a result of a group discussion.
Group Interaction Techniques
Research in group judgment and decision-making confirms what we already
know intuitively: Group discussions can lead to better decisions. Now let’s
see what techniques can be used to facilitate these types of discussions. Based
on how team members communicate with each other, these discussions can
be separated into four categories:
1. Consensus. These are face-to-face discussions between group members where one judgment is eventually accepted by all members. This
is one of the most common techniques in project teams. Team members
meet regularly to discuss certain issues in anticipation that they will
come to a consensus. The problem with this method is that some team
members, who often happen to be managers, can monopolize the discussion and significantly influence the final judgment. This effect can
be called the “We discussed and I decided” outcome.
79
80
Project Decisions: The Art and Science
2. Delphi. The Delphi process helps to protect against the “We discussed
and I decided” effect. Group members don’t meet face-to-face. Instead,
they provide their opinions anonymously in a series of rounds until
a consensus is reached. Delphi techniques require a facilitator, who
sends out questionnaires to a panel of experts. Responses are collected
and analyzed, and common and conflicting viewpoints are identified.
The Delphi method was developed at the RAND Corporation, a nonprofit global policy think tank, at the beginning of the Cold War to
forecast the impact of technology on warfare. The name of the technique derives from the Oracle of Delphi.
3. Dialectic. In this technique members are asked to discuss those factors
that may be causing biases in their judgments. Group members holding differing opinions on a specific topic try to understand each other
and resolve their differences by examining contradictions in each person’s position.
4. Dictatorship. This process uses face-to-face discussions that lead to
the selection of one group member whose judgment will represent
that of the group. Interestingly, according to Sniezek’s research (1989),
judgments produced by the dictatorship technique were more accurate
than those produced by any of the other techniques. The dictatorship
technique may be useful when a project team is trying to solve business or technical issues that require specific knowledge or expertise.
In this case, it is important to identify the person with the best knowledge of the subject and discuss the issue under his or her guidance.
5. Decision conferencing. This technique has been proven to be effective
for analysis of complex problems (Decision Conferencing 2006). Decision conferencing involves having experts get together for one to three
days in face-to-face meetings that are moderated by a decision analyst.
The analyst acts as a neutral observer and applies decision analysis
methods and techniques during the meetings. The analyst creates a
computer-based model that incorporates the judgment of the experts.
It is extremely important that he or she does this in parallel to the
discussions so that the experts can examine the results as the discussions progress. Through examination of the models, experts are able
to create a shared understanding of the problem and to come up with
a decision. Essentially, the analyst is applying the decision analysis
process described in this book: framing decisions, creating a model,
and performing analysis in parallel with the decision conference.
Group Judgment and Decisions
Brainstorming
Brainstorming is a technique for creating a list that includes a wide variety
of related ideas. In theory, brainstorming can be performed individually, but
it is more effective if it is performed by a group. Brainstorming can be a very
effective method in project management. What is the best course of action in
a complex business situation? What features of the new product can be developed first? What are the potential risks and opportunities for this project?
A number of techniques and tools are used for brainstorming (Clemen 1996).
The main goal of these techniques is to promote creative thinking among
group members. All these techniques have the following rules:
1. Do not present detailed analysis of the ideas.
2. All ideas are welcome, even the absolutely “far out” ideas; groups
should come up with as many ideas as possible.
3. Group members are encouraged to come up with ideas that extend the
ideas of other members.
Psychologists have discovered that brainstorming can be more effective if
several people work on a problem independently and then share and discuss their ideas (Hill 1982). Many effective brainstorming techniques are built
around this idea.
Figure 6.2 describes a brainstorming technique we recommend as part of
project decision analysis. In it, each group member takes on a specific role.
These roles are defined well before the meeting, so each participant can mentally prepare for the process. There are at least six roles, although some can
be combined:
n
n
Idea Generator: develops as many ideas as possible but does not evaluate them
Erudite: provides more information about these ideas based on his or
her own factual knowledge
n
Devil’s advocate: criticizes the ideas presented
n
Positive reviewer: finds positive elements in the ideas
n
n
Facilitator: organizes the discussion and makes sure that all participants follow their roles
Scribe: writes down the ideas and distributes them to group members
in an easy-to-digest format.
81
82
Project Decisions: The Art and Science
Moderator
Positive
Reviewer
Idea
Generator
Erudite
Scribe
Devil's
Advocate
Figure 6.2 Brainstorming Technique
There are two important rules to follow when using this process:
1. Everybody has the right to move outside the boundaries of his or her
role occasionally; however, it is important to stay within one’s role for
the discussion of a particular topic or for the duration of a brainstorming session.
2. Two to four meetings, each with very short time frame (15–30 minutes), are conducted with breaks of a day or two in between. The limited time frame is strictly enforced. Long breaks between meetings
give participants the opportunity to think more about the ideas. Roles
can be changed for the next meeting.
Another brainstorming method is called the nominal group method (Delbecq,
Van de Ven, and Gustafson 1975). At the beginning, each group member
writes down as many ideas as possible. During the meeting the members
present these ideas, the group evaluates the ideas, and the moderator records
them. After the discussion every group member ranks the ideas. These rankings are then combined mathematically to select the best ideas.
If you and your team have not brainstormed before, you should not expect
miraculous results from the first meeting. Don’t be discouraged, for brainstorming requires a certain amount of practice. Therefore, if you believe that
83
Group Judgment and Decisions
brainstorming would be useful for your projects, we recommend beginning by practicing
on less important project issues before getting into complex problems. And the role of
the moderator is important, for an inexperienced moderator can block good ideas. Good
moderators set a positive tone for discussions
and encourage creative ideas.
Effective brainstorming is
an art. It takes practice to
achieve good results.
Tools for Facilitating Discussions
A number of tools can help with strategy planning, brainstorming, process
improvement, and meeting management. During discussions you can record
ideas and conclusions, create different diagrams and flowcharts, and share
them among others regardless of the particular geographical locations of
group members. In addition to analytical tools such as cause-and-effect diagrams and decision trees, there are tools that help to organize meetings by
creating agendas and minutes, facilitating online discussions, defining team
action items, and so on.
In recent years mind-mapping software tools have become popular in project
management. Vendors of this software have sold hundreds of thousands of
licenses, and we don’t believe that this is a temporary trend; apparently project managers have realized the benefits of mind-mapping tools. A mind map
is a diagram used to represent ideas, activities, risks, or other items linked to
a central theme. In a mind map, the central theme is often illustrated with a
graphic image. The ideas related to the main theme radiate from that central
image as “branches.” Topics and ideas of lesser importance are represented
as “sub-branches” of their relevant branch. The mind map shown on Figure
6.3 is based on a risk breakdown structure adapted from the PMBOK® Guide
(see Appendix C).
A mind map helps to record ideas in a structured way and to review them later.
You can find a list of vendors of these tools and other tools in Appendix A.
When we think about project management tools, we mostly recall software
tools, various paper templates, and checklists. But you don’t need expensive
or fancy software to facilitate discussions. A number of simple hardware tools
are useful. In addition to traditional flipcharts or chalkboards, many project
teams use electronic whiteboards, which automatically record information
written on the whiteboard to a computer.
84
Project Decisions: The Art and Science
Requirements
Technology
Estimating
Planning
Control
Complexity
Project
Management
Technical
Performance
Quality
Communication
Safety
Project Risks
Material
Personnel
Subcontractor
Project dependencies
Resources
Funding
Components
Organizational
Prioritization
External
Legal
Market
Customer relationship
Site specific issues
Figure 6.3 Mind Map of Project Risks
A Few Words about Game Theory
“Life is but a game,” said Hermann, a character in Peter Tchaikovsky’s opera
The Queen of Spades. Today we can view decision analysis through the lens
of modern game theory, a mathematical theory of human behavior in competitive situations that studies decisions made in an environment in which
players interact. In other words, it studies how an individual selects optimal behavior when the costs and benefits of each option depend upon the
choices of other individuals. While Hermann wasn’t thinking, or even aware
of, modern game theory, he was right. Game theory helps to analyze many
processes in the common conflicts we deal with in our lives, such as stock
market behaviors; political processes, including wars and elections; business
activities, such as negotiations, auctions, mergers, and investments; and, yes,
project management.
Game theory began with the classic Theory of Games and Economic Behavior,
by John von Neumann and Oskar Morgenstern (von Neumann and Morgenstern 1947). The RAND Corporation used game theory to help to define
nuclear strategies. Do you remember the movie A Beautiful Mind? It is the
biography of John Forbes Nash, Jr., a mathematical genius who fell victim to
schizophrenia after making amazing strides in game theory and economics.
In 1994, Nash shared the Nobel Prize in economics with John C. Harsanyi
and Reinhard Selten for their work in game theory. In 2005, Robert J. Aumann
and Thomas C. Schelling received the Nobel Prize “for having enhanced our
understanding of conflicts and cooperation through game-theory analysis.”
Group Judgment and Decisions
Why do some projects succeed in promoting cooperation while others suffer
from conflict between different stakeholders? Here is a very simple example
of a situation in which you could apply game theory:
You are the manager of an IT project. Your client wants to make a change that
he considers critical. You realize that this change will have major implications
for your system and could significantly delay the project. Is this a source of
potential conflict or is there a way to compromise? Your decisions as a project
manager are influenced by the choices and actions made by other stakeholders.
Or, the opposite, the decisions of all project stakeholders are influenced by your
decisions. The course of the project depends on the outcome of this “game.”
Game theory offers mathematical mechanisms that can be helpful in solving these issues. Here are few examples of simple games. Schelling (1971)
described the “mattress problem,” where there is a two-lane highway and
one lane is jammed as people slow down to gawk at a mattress that has fallen
from a car. The question is, who should stop to pick up the mattress? The
people at the back of the traffic jam are only aware that there is a problem
but do not know the cause. The people at the front can see the mattress but
want to get out of the traffic jam as soon as possible. By the time they are at
the mattress, they are at the end of the traffic jam, and it will take them less
time to ignore the mattress than to remove it. If they remove it, they will save
everyone behind them a great deal of time but at a cost to themselves.
The mattress dilemma can manifest itself in project management. If you have
a software project for which your team cannot easily find the time to develop
a testing tool, should you develop one anyway? You have completed your
project, so you don’t need the tool, and it will only be used to test someone
else’s software. When the application is done, why bother creating the testing
tool, which can be used for future applications developed by somebody else?
In psychology this effect is considered a mental trap, and this specific one is
called the collective trap.
Another example of a game is deciding when to buy a ticket for a train. There
are a limited number of trains leaving the station. If you arrive too late, you
may not get a ticket. If you arrive too early, you will have to stand in line
for a long time. So you want to arrive at the station when it maximizes your
chances of getting a ticket while minimizing the time you have to stand in line.
Your choice will depend upon when the other people decide to arrive. Game
theory helps to find a mathematical answer to these types of problems.
One of the important concepts of game theory is called the Nash equilibrium,
named after John Nash. The Nash equilibrium is a solution to a game where
no player gains by unilaterally changing his or her own strategy. In other
85
86
Project Decisions: The Art and Science
words, if each player has chosen a strategy and no player can benefit by
changing his or her strategy while the other players keep theirs unchanged,
then the current set of strategies with their corresponding payoffs constitutes
a Nash equilibrium. A Nash equilibrium can be reached in the train ticket
game, where everybody arrives at the station in such a way that all waiting
times are minimized.
As a project manager, you will most likely not use game theory directly.
Applications of game theory to project management are still under research,
but we believe that practical solutions and tools will soon be available for
project managers. If you want to read more about game theory, you will find
some references in the Future Reading section.
n
n
n
n
n
n
Psychological heuristics and biases that work at the individual level are
applicable to groups of people.
The group polarization bias is a tendency to advocate risky decisions after
participation in group discussions.
In many cases, group discussions lead to better decisions than those made
by individuals.
Brainstorming in project management helps us assess business situations,
identify risks and opportunities, and select a better course of action.
A number of software and hardware tools help facilitate discussions; among
them is mind-mapping software, which is used to record ideas in a structured manner.
Game theory is a mathematical theory of human behavior in competitive situations in which players interact. Such situations frequently occur in project
management.
Chapter 7
Are You Allowed to Make a
Decision? Or the “Frustrated
Developer’s Syndrome”
O
ur ability to make and implement project decisions depends on our
professional environment, in particular the corporate culture in
which we work. In many organizations, project teams are unable
to contribute to major decisions and are not properly rewarded for making
good choices. This significantly undermines the productivity and quality
of an organization’s projects. We call this effect the frustrated developer’s syndrome, or FDS, a dangerous disease affecting corporate culture. It is hard to
treat FDS, mostly because senior management tends to recognize the problem
only when it is very advanced.
What Is FDS?
After reading this book, you may become an expert in project decision-making, but will you be allowed to apply your newfound expertise? Will your
organization allow you to make a decision
or at least heed your advice? In other words,
will your manager continue to make deciFDS is a disease that can
sions for you and your team, leaving you
afflict the corporate culture.
with only one choice: implement the project
plan even if you disagree with it?
It affects decision-making,
Projects always have constraints. Often, for
efficiency, and productivity.
technical reasons you will be unable to perform certain tasks. Sometimes constraints
are related to market conditions, safety, or
environmental concerns. But all too often these constraints are artificial constructs imposed by upper management, and they make no practical sense.
As a result, potentially superior alternatives are excluded from the decisionmaking process.
Such constraints are not an isolated problem but rather one of many symptoms of a disease that can infect an entire organization. Because this disease
88
Project Decisions: The Art and Science
reveals its most acute forms in research and development projects, we call it
the frustrated developer’s syndrome, or FDS. FDS affects the “central nervous
system” of a company, which is its corporate culture. FDS manifests itself when
managers and members of project teams are unable to contribute to major
project decisions and are not properly rewarded for showing extra initiative
and making good decisions. As a result, organizations lose the ability to produce high-quality, innovative projects at a reasonable cost.
Table 7.1 presents a quick test to help you diagnose this disease in your organization. Take the test and score it. You can use it whether you are a project
manager or a project team member.
#
1
Symptom
Points
You made an outstanding contribution to the project using an innovative
technique, and due to your efforts the project was completed 30% quicker than
originally planned. For your efforts you receive:
0
A. Sense of a well-done job, praise from management, sizeable material
compensation (bonus, stock options, etc.).
1
B. Only the sense of a well-done job.
4
C. Nothing.
6
D. Big trouble, because if your innovation causes delays you will be held
accountable.
2 Critical business decisions related to the project you are working on are made:
0
A. Jointly by you, all other members of the project team, and upper
management.
2
B. By upper management, but your opinion is considered.
4
C. By upper management and you can express your opinion, but does anyone
listen to you?
5
D. Only by upper management. In theory you can make suggestions, but you
keep them to yourself because you value your job.
3 In your job responsibility:
0
A. You have your own focus area within the project team, but you have a
strong understanding of what other team members are doing and can help
them or take over their responsibilities if required.
2
B. You are working according to your job description and have limited input
to activities of other team members.
Table 7.1 Test to Diagnose FDS in Your Organization (continues)
Are You Allowed to Make a Decision? Or the “Frustrated Developer’s Syndrome”
#
Symptom
C. You do the tasks that are assigned to you and nothing else or you could
land in trouble.
4 In your relationship with the client:
A. You and all other members of project team are continuously engaged with
the client.
B. A person from your team communicates with the client and translates
requirements and feedback to you.
C. You know who is talking to the client, but you do not know exactly how
the requirements were gathered or what the client thinks.
D. You have a list of requirements.Your job is to implement it and not to ask
where they came from.
5 Knowledgeable people whom you really respect:
A. Enjoy working with you and the rest of the team.
B. A few have left, but that’s life.
C. Many have left, and why the others are still working here is a mystery.
D. Everybody has left, so what are you still doing here?
6 There is a problem with the project, so:
A. Let’s work together, including putting in extra time to meet the deadline.
B. If upper management explicitly asks, we can put in a little extra time.
C. Who cares except for upper management if there is a delay? The project
will be done as soon as it is ready.
7 Can you be promoted in your organization?
A. Everybody who is performing well has a chance to be promoted.
B. Promotion is possible after a couple of golf tournaments and cocktail
parties with upper management.
C. It is easier to get the Nobel Prize than to be promoted in this
organization. All positions are reserved for people parachuted in from the
head office.
8 Are you enjoying your work?
A. I am very lucky to have this job.
B. This place has some problems, but I like what I am doing.
C. If I could find a way to get the same money elsewhere, I would be long
gone.
Table 7.1 Test to Diagnose FDS in Your Organization
89
Points
3
0
1
2
3
0
1
2
3
0
1
3
0
2
3
0
2
4
90
Project Decisions: The Art and Science
Now add up your points. Use the key in Table 7.2 to get your FDS diagnosis.
Score
0–7
7–15
15–23
23–30
Diagnosis
You are lucky:You work in a good and vibrant organization without FDS.
It is not FDS yet, but there are some worrying signs.
Your organization is definitely infected, but there is a chance of recovery.
An extremely bad case. Treatment options are very limited.
Table 7.2 Test to Diagnose FDS in Your Organization: The Final Score
From taking the test you may have gathered that organizations that are free
of FDS display certain attributes:
n
n
Project decisions are made at the lowest level possible; a consensus of
project contributors is the optimal way of decision-making.
The environment is results-driven; the organization provides effective incentives (not necessarily financial) for valuable project
contributions.
n
Members of a project team have a sense of autonomy.
n
There is project commitment and a shared vision or goal.
n
n
There is effective communication within the team, within the organization, and with clients; and there is mutual trust and mixed roles
within a project team.
Team members have high levels of enjoyment.
Is FDS really that prevalent? One glib answer is that if FDS were not prevalent, Scott Adam’s Dilbert comic strip would not be so funny and popular.
Unfortunately, many organizations are infected with FDS. Most executives
are familiar with FDS, but have different terms for it. Disconcertingly, many
do not think that FDS is an important issue or a reason for concern.
Why FDS Is a Problem
When people are involved in simple activities—such as digging a trench, carrying logs, or roofing a house—you can motivate them to do good work with
minimum incentives. However, motivation becomes more difficult when the
activities involve creative thinking and decision-making. In these situations,
Are You Allowed to Make a Decision? Or the “Frustrated Developer’s Syndrome”
91
different types of incentives are required to
FDS is a problem because
motivate a project team. Every job has incenfrustrated project team
tives in place to motivate individuals to
perform at higher levels. But in many organimembers do not produce
zations these incentives are structured incorrectly and provide little motivation. This
good projects.
leads to frustration and eventually to FDS.
Table 7.3 presents motivators and incentives,
as expressed by project managers and team members (based on an example
of a software project manager).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Project Managers
Responsibility
Achievement
Work itself
Recognition
Possibility for growth
Interpersonal relationship
Advancement
Salary
Company policies and administration
Job security
Technical supervision opportunities
Status
Personal life
Working Conditions
General Population
Achievement
Recognition
Work itself
Responsibility
Advancement
Salary
Possibility for growth
Interpersonal relationship
Status
Technical supervision opportunities
Company policies and administration
Working conditions
Personal life
Job security
Table 7.3 Motivations and Incentives. Source: McConnell 1996.
As you can see from the table, purely financial rewards do not rank in the
top five incentives for either project managers or team members. Others—
“achievement,” “recognition,” “the work itself”—are more important. And
if organizations do not understand these underlying motivations of their
employees, they are ripe to come down with FDS. However, FDS is subtle
and does not instantly lead to the failure of the company, a fact that often
leads executives to believe that inadequate emphasis on incentives is not a
problem. Let’s examine how FDS could affect an organization using a simple
model.
92
Project Decisions: The Art and Science
A number of parameters help to distinguish good projects from bad. Let’s
draw and connect the nodes representing project objectives, such as cost,
time, innovation, usability, and quality. We do this in Figure 7.1. There are
other important objectives, e.g., safety and environment. Let us imagine a
box with hinges at the angles, similar to the one we have drawn in Figure 7.1.
The whole thing is unstable. If you apply a small force to one of the nodes,
the square will collapse. To maintain the stability of the box, you must somehow reinforce it with struts. In the case of a project, these struts or diagonal
elements are the reputation of the organization, good project financing, wellestablished processes, corporate culture, and so on. The stronger the struts,
the more stable the box. In projects, corporate culture is perhaps the most
important element in keeping the structure from collapsing upon itself.
Cost and Time
Reputation,
Financing,
Processes, etc.
Quality
Usabillity
Corporate
Culture
Innovation
Figure 7.1 The Risk of Weakening the Corporate Culture
Now, let’s assume that FDS has weakened the organization’s corporate culture.
The box will not collapse instantly, for the other struts will initially hide this
weakness, but a few nodes will start to be displaced. The most common result
will be an increase of cost and time: organizations with FDS usually deliver
projects much slower and for much higher cost. Innovation and usability are
usually compromised next, affecting the quality. Quality is achieved not only
by applying quality-control procedures, for frustrated project members rarely
deliver high-quality products.
The model in Figure 7.1 helps us understand why organizations with FDS
can survive for such a long time after the initial onset. The problem is that the
Are You Allowed to Make a Decision? Or the “Frustrated Developer’s Syndrome”
93
weakening or failure of one or a few components that contribute to a project’s
success will eventually lead to the failure of the other components and the
eventual collapse of the project, or even the organization. If an organization
consistently completes projects with cost overruns and delays, relationships
with its customers will suffer, eventually
leading to financial problems. This can take
some time, however, which can lead to a false
The manager in most cases
sense of security that the corporate culture is
should not be the primary
fine and does not need improvement.
decision-maker. Instead, the
Everybody agrees that a project manager
alone cannot understand all the details that
manager should facilitate
a project entails and needs to consult with
the project team members (Figure 7.2). Indijoint decision-making by the
vidual team members also may not undergroup . . . of experts.
stand the complete scope. But the team as a
whole should. A project manager should not
act as the chief decision-maker. Although he
or she is ultimately responsible for making a
decision, to come up with it the project manager should involve a decision
committee or review board as well as a panel of technical experts. In many
cases, primarily in small research and development projects, decision committees and a panel of experts constitute the full project team. This not only
Figure 7.2 Understanding Project Scope
94
Project Decisions: The Art and Science
improves the quality of the decision but also creates a sense of empowerment
among the team members. Remember, a sense of empowerment is one of
most important attributes of an FDS-free organizational culture.
How Does FDS Spread?
Most start-ups do not have FDS; if they do, they quickly fail. As an organization gets over its growing pains and starts to expand, more people join
the organization, more processes are established, and relationships between
people and between project teams become more formal and complex. In
many cases, FDS infection occurs as a company evolves from a start-up to a
steady-state company. If executives are not familiar with the creeping effects
of FDS, or if they don’t pay attention to it, an organization can quietly become
infected. In many cases, FDS infection occurs during an acquisition. If a company with FDS acquires an FDS-free organization and tries to impose its own
corporate culture on the smaller organization, FDS very quickly infects the
newly acquired entity.
There is a story about a young engineer fresh out of university who had just been
hired by a design company. On his first day the manager asked him, “What do you
want to do?” “I want to design a beautiful city with nice buildings, wide boulevards,
parks, and canals,” the engineer replied. “That’s great,” the manager answered, “but
for now you need to design a staircase.”
Three years later the manager repeated his question. “I want to design a beautiful building with large apartments and a big lobby with a fountain,” the engineer answered.
“That’s great,” the manager answered, “but for now you need to design a staircase.”
Three years later the manager again repeated his question. “I want to design a beautiful apartment with big windows and a nice bathroom,” the engineer answered.
“That’s great,” the manager answered, “but for now you need to design a staircase.”
Three years later the manager again asked the engineer, “What do you want to do?”
“I want to design a staircase,” the engineer replied.
Often when an organization becomes infected with FDS, people who like a
creative environment move out. Or, as in the case of our young engineer, they
become complacent.
Another effect of FDS is that people start concentrating on small technical
issues, which are the only things over which they can exert some influence.
The larger picture is often hidden from them by the management, which
often does not communicate sufficient information about the project with the
team. As a result, management’s and team members’ goals begin to diverge
and over time can become completely different. For example, management’s
Are You Allowed to Make a Decision? Or the “Frustrated Developer’s Syndrome”
goal is to develop an application that is simple and fast. On the other hand,
an individual programmer may have a different goal, wanting to introduce
a new programming tool that will improve the product. However, the tool is
more difficult to use and makes the code so complex that it adversely affects
the application’s performance. But the programmer persists. Why? He argues
that this new, innovative tool is “architecturally sound” or is “scalable,” but
in reality he simply needs to express himself, and choosing this software tool
is the only significant decision he can make.
When top managers do not realize there is a problem with the corporate culture, they start behaving irrationally. When sales go down, they think they
will solve the problem by shaking up the sales team. When this fails, they
look at the development process and start to implement additional and often
unnecessary steps. For example, if managers believe there is a communication problem within the organization, they often try increasing the number of
meetings and duration of meetings. What this really does is distract people
from their jobs as they get increasingly bored and irritated if the meetings
start to creep into their lunch times. When this approach does not work, management starts to look at external factors: market conditions, competition,
and other aspects that the organization cannot control directly, so nobody
within the company is held responsible.
Failing all else, management starts to reorganize. After one or two reorganizations nothing improves, and in fact the situation appears to have deteriorated.
This is because the reorganization itself is a project, which is just as infected
with FDS as all the rest of the projects. Upper management makes decisions
regarding the reorganization without consulting the project team members,
and very often it becomes just another bureaucratic initiative. Finally, after
FDS significantly reduces organizational performance, the company is converted to another form in one way or another. Large companies can sell assets
or spin off an FDS-infected division. A company can exist for quite a while as
a low-producing entity by surviving on old clients and projects. The tragedy
is that the executives who unwittingly worked so hard to spread the infection
often get other assignments and never realize that the dying organization is a
product of their dysfunctional decision-making process.
Three Common Myths about FDS
Myths about FDS abound. These are three of the most common ones.
Myth 1: Our organization is not suitable for an FDS-free
environment.
Some executive say that they are not a “dotcom” or a start-up, they have run
their company for many years, and the existing corporate culture works. In
95
96
Project Decisions: The Art and Science
reality, all organizations can be infected by FDS because corporate culture is
a function of interpersonal relationships, not the organization’s type, size,
or industry. Still, an environment that devalues motivators and incentives is
much more common in big companies than in small ones. Fortune magazine
maintains a list of the best companies to work for (Fortune 2006). The magazine has used a number of criteria to create this list, but it pays most attention
to corporate culture. Among large companies in the 2006 list are Genentech,
Qualcomm, Cisco Systems, SAS Institute, Intuit, Intel, Nike, and Autodesk.
Myth 2: When companies implement organizational processes,
FDS results.
Organizational processes such as those used by project management, including
decision-making processes, have nothing directly to do with the development
of FDS. In some cases, however, executives use the processes as an excuse to
diminish the system of motivators and incentives, which leads to FDS.
For example, a company can establish a hierarchical reporting system. There
is nothing wrong with such a system in and of itself; all well-organized companies should have one. But if the administrative hierarchy is used as a substitute for team decision-making and if small decisions require the approval
of upper management (which normally has only a remote idea of the individual needs of each team), FDS can result.
Myth 3: An FDS-free corporate culture leads to anarchy.
Some managers believe that they will lose control if they allow decision-making to occur at the project team level, encourage independent work, build a
sense of autonomy for each team member, and allow mixed roles. They also
think, for the same reason, that it is wiser to provide team members with
as little information as possible. The experience of most successful organizations illustrates that an FDS-free environment does not lead to anarchy. Such
a company can be well organized, and decisions can be well informed and
balanced because everybody takes part in the decision-making process.
In reality, FDS can be a primary cause of anarchy because management and
project team members do not share the same goals. Management tries to do
one thing, development does another thing, and sales has a completely different agenda. Upper management does not know about the state of the business because its subordinates are engaged in “creative” reporting. This is a
classic case of anarchy.
Are You Allowed to Make a Decision? Or the “Frustrated Developer’s Syndrome”
The Roots of FDS
FDS is not a natural phenomenon, like the flu. It is the result of management
actions. The questions that always arise are, “What were they thinking? Why
did management think that damaging corporate culture would improve the
business?”
Can you imagine a world without FDS? Companies would be so productive that humanity would already have settled on Mars, eradicated cancer,
reversed global warming, and perfected the sky hook. The only drawback
would be that Scott Adams wouldn’t have any more material for his Dilbert
comic strip.
The first thing to realize is that management does not set out to ruin the corporate culture. Rather, the roots of FDS lie in the human psychology of judgment
and decision-making: management overconfidence, selective perception (“I see
what I want to see.”), inability to recognize personal limitations and mistakes,
and many of the other biases we have discussed in earlier chapters. Appendix
B contains an extensive list of these biases. So, while good management practices and training may reduce the negative effect of these biases, unfortunately
we cannot completely eradicate FDS any more than we can get rid of plagues
or unwanted hair, because they are all an integral part of our existence.
Treating FDS
Even when top managers realize that their organization is infected with FDS,
treatment is extremely difficult, and the contagion cannot be removed without major organizational disruptions. Making radical changes to the corporate culture is especially difficult for the simple reason that FDS-infected
organizations usually do not support any type of initiatives, let alone ones
that would attempt to completely transform the manner in which the organization conducts its internal processes. In most cases, successful organizational changes occur when new management instigates changes to improve
company business. But remember, treatments work only if they fully involve
everybody in the organization, not just the management team.
If management wants to repair the corporate culture, major organizational
changes may be required, and very often extensive retraining is necessary.
On March 27, 1977, two Boeing 747s, Pan Am Flight 1736 and KLM flight 4805,
were preparing to take off on the only runway of Los Rodeos Airport in Tenerife, one
of the Canary Islands (Kilroy 2007). KLM Captain Jacob Veldhuyzen van Zanten
was known as a first-class pilot and was even the preferred pilot for the airline’s publicity shots, such as KLM’s magazine ads. As the KLM aircraft lined up for take-off,
97
98
Project Decisions: The Art and Science
the Pan Am flight was still taxiing on the same runway. Due to the fog, the KLM
crew was unable to see the Pan Am 747 taxiing on the runway ahead of them. As they
lined up for take-off, the KLM crew received clearance from the control tower to fly
a certain route after take-off. Captain van Zanten apparently mistook this clearance
as the permission for take-off. The KLM flight engineer expressed his concern about
the Pan Am flight not being clear of the runway. The engineer repeated his concern a
few seconds later, but he was overruled by Captain van Zanten and made no further
challenges to this decision. Shortly after taking off, KLM 4805 crashed into the Pan
Am aircraft, killing 583 people and injuring 61. The Tenerife disaster resulted in the
highest number of fatalities of any single accident in aviation history.
According to the subsequent investigation, communication problems and weather
conditions were the primary causes of the accident, but another cause for the disaster
was identified. Some experts suggested that the KLM captain, van Zanten, may have
developed a kind of governance attitude that impaired the decision-making process in
the cockpit. The flight engineer apparently hesitated to further challenge him, possibly
because van Zanten was not only senior in rank but also one of the most experienced
pilots working for the airline.
As a consequence of the Tenerife accident, the airline industry adopted changes
in cockpit procedures. The hierarchical relationship among crew members
was deemphasized, and more emphasis was placed on decision-making by
mutual agreement. This is known as crew resource management (CRM) and is
now standard training in all major airlines (McAllister 1997). CRM training
originated from a NASA workshop in 1979 that focused on improving air
safety. The NASA research found that the primary cause of the majority of
aviation accidents was human error, and that the main source of human error
is the failure of decision-making in the cockpit. CRM training encompasses
a wide range of knowledge, skills, and attitudes, including communications,
situational awareness, problem-solving, decision-making, and teamwork.
Unfortunately, the project management industry still trails aviation, fire safety,
and other industries in understanding the importance of decision-making by
all team members. Moreover, many consider the project manager, who is in
most cases an administrative manager, the ultimate decision-maker. This is a
direct path to FDS.
As you remember, training can help to improve our decision-making skills.
So training the project team to work together, to make decisions as a group,
and to share rewards together can help to battle FDS. If you have a health
problem, you consult your doctor. If your organization has FDS, contact a
project management consultant, rework your organization’s training, and try
to relieve the FDS symptoms.
Are You Allowed to Make a Decision? Or the “Frustrated Developer’s Syndrome”
But if you are not an executive and you work in an FDS-infected organization,
you are in a very unfortunate circumstance. There is not very much you can
do to treat it. Your best option is to raise awareness of the situation with your
managers; but if you pursue this route, you might also want to freshen up your
resume. At the other extreme, you can keep your head down and hope that
management recognizes the situation and starts to do something about it.
Perhaps the most sensible course of action is to concentrate on improving the
particular circumstances of your projects and, within your power, focus on
making this the best possible environment for you and your team. This strategy can actually help improve your local project environment, even if the rest
of the organization is infected with FDS.
The Second Russian Revolution
Sometime around 1988, a few hundred mostly young Russian engineers and
computer programmers met with industry experts to discuss what could be
done to improve software development for personal computers in Russia.
The first panelist argued that the primary problem was lack of hardware and
that the government should undertake the production or importation of more
computers. The second expert thought that the government should establish
R&D organizations specifically for the development of PC software. The last
expert said that while he agreed with all other panelists, he did not believe
that major government investments, establishment of state-run companies, or
any other government programs were going to help the industry. The answer,
he said, was to create conditions in which private individuals (engineers and
programmers) would be able to sit in their basements (actually apartments in
Russia), develop software, and sell it.
For anybody involved in software development, this made perfect sense,
but what the expert said was absolutely revolutionary and almost seditious.
Remember that it was 1988 in the USSR. Private enterprises in the Soviet
Union were prohibited. One might say that the whole country had FDS.
The underlying message was that the solution to the problem was to allow
individual initiative and private enterprise, which could not be done without
a regime change. When the revolution occurred a few years later, in the forefront of this so-called second Russian revolution were engineers, programmers, and anybody else who wanted to make their own decisions and earn
something as a direct result of their own risk-taking and initiative.
Please don’t get us wrong. We are not advocating revolution, rebellion, guerilla warfare, or other types of insurgency in your organization. We don’t
99
100
Project Decisions: The Art and Science
want this book to be labeled heretical and burned at the corporate bonfire.
But what we do want to point out is that any attempt to set up an advanced
decision analysis methodology will most likely fail if your organizational culture is infected with FDS. Before undertaking any new major processes, the
culture of your organization must be fundamentally sound. In many cases,
however, project teams can still benefit from improved decision analysis even
if FDS is present. A good first step is establishing a proper decision-making
process within your project team.
n
n
n
n
Frustrated Developer’s Syndrome, or FDS, is a disease that infects corporate
culture. FDS limits decision-making and does not provide sufficient incentives for project contributors.
Many executives don’t realize that their organization is infected with
FDS because the negative effects of FDS can take a long time to manifest
themselves.
In most cases, project managers should act as facilitators in the decisionmaking process, not as the primary decision-makers.
Even if your organization is infected with FDS, there are certain things you
can do to improve your working environment. In particular, your project
teams can benefit from an improved decision-making process.
Chapter 20
Adaptive Project Management
A
daptive project management is a powerful method that incorporates
constant learning and improvement. Quantitative analysis helps compare original assumptions with actual project data. Instead of making
an irreversible major decision at the start of a project, it is important to focus
on making small sequential choices. Adaptive project management can be
implemented only in a creative business environment, where potential issues
and problems can be identified and corrected at an early stage.
Adaptive Management As Part of Project Decision
Analysis
After the framing, modeling, and analysis phases of our work, we finally
come to one of the important milestones in the project—the project launch.
Why is it so monumental? Primarily because many projects never make it to
this stage. If the decision process is working correctly, the weakness in a project will be seen and the project will not be launched.
As we start to execute the project plan, we
now have the opportunity to see how the
project progresses in actuality, no longer just
in theory, and make necessary adjustments to
our original plan. This process is called adaptive management. Adaptive management is a
process of continually improving decisions
by learning from the outcomes of decisions
previously taken.
Adaptive management is
a process of continually
improving decisions by
learning from the outcomes
of previous decisions.
Because of the many risks and uncertainties
in a complex project, it is impossible to envision everything in the planning stage. We now have new inputs to our decision-making process: actual project performance.
The adaptive management concept was introduced by ecologists in the 1970s
(Holling 1978; Walters 1986) and has become an effective tool in ecological
and environmental management. Environmental and project management
250
Project Decisions: The Art and Science
have many things in common. For one thing, both deal with multiple uncertainties. We believe that project managers can affectively apply adaptive
management practices to their projects.
A key area of overlap between the two processes is the principle of continuity, which we discussed in Chapter 3 as one of the key principles of project
decision analysis (along with consistency and comprehensiveness). Continuity is also a key principle of adaptive management. Look back at Figure
3.2 in Chapter 3. The arrows from the box “Implementation, Monitoring and
Review” point to other phases of the decision analysis process. These arrows
represent the iterative process of adaptive management. By analyzing the
actual project performance, you can update the following:
n
n
n
Original assumptions made during decision framing. For example,
you may add or retire some risks. Sometimes you will have to update
project objectives, assumptions about the business environment, and
available resources.
Valuation models. You can update the schedule or reassess the probability of certain risks. Active adaptive management may involve defining multiple models for different alternatives and testing them during
the course of the project (Linkov, Satterstrom et al. 2006b).
Quantitative analysis. You can run a new analysis using event chain
methodology with an updated schedule model and risk breakdown
structure.
Here is an example. When an oil company decides to start drawing oil from one
of its reserves, it estimates the reserves in place using all available information:
seismic surveys, exploratory data, and analogous information from nearby
wells. When the well starts producing, the oil company can then use actual production data to refine its original estimates about the size of the reserve (Rose
2001). Although in some situations it is impossible to estimate precisely the volume of oil in the reserve until almost the entire field is produced, the company
can reduce uncertainties and update economic and production models based
on new information obtained during the course of the project.
Principles of Adaptive Management
Adaptive project management is based on five basic principles that help you
monitor the course of your project and refine your original decisions.
Adaptive Project Management
Principle 1: Use actual project data in combination with
original assumptions.
During the execution of a project, a manager might behave in either of two
extreme ways:
1. Disregards the original assumptions made during the planning stage
of the project.
2. Ignores the implications of the new data and adheres resolutely to the
original forecast. This occurs because of different motivational and
cognitive biases, such as optimism or overconfidence, and warning
signs about the failing project are often ignored.
Neither extreme is desirable. Assuming that the original estimates were done
using relevant historical data or expert opinion, both the original plan and the
new data should come into play together. Let’s say we have a project where
we originally estimated that it would earn net revenue of $1 million by year
end, but by April net revenue is already $0.5 million. Should we readdress
our estimate, and if so, how? If we simply multiply the current revenue by
three to account for the remaining number of months, this may not account
for expected slow summer sales. The solution is to perform an analysis and
compare it with trends for current and previous years.
A number of techniques can help us forecast the future based on actual and
historical data. One such technique is regression analysis. Generally, regression
analysis is a statistical technique for investigating and modeling the relationship between variables. If we know how a variable such as cost changes over
time, we can come up with a forecast for future cash flows. If we add actual
data to the analysis, the quality of regression analysis improves.
When we deal with probabilities, the situation is much more complex. It is easy
to ignore base-rate frequencies when trying to combine actual and historical
data, especially if they are related to probabilities. Let’s say we estimated that
the chance of a certain risk occurring was 20%, but with the project only half
completed the risk has already occurred twice. What is the chance that the
risk will occur during the reminder of the project? We previously discussed
this problem in the chapter on event chain methodology, particularly in the
section on performance tracking (see Chapter 17). One of the solutions to this
problem is to use Bayes theorem to analyze the value of imperfect information.
Using the Bayesian formula, you can combine original estimates of probabilities (prior probability or marginal probability) and data obtained as a result
of actual project measurement. The actual formula is used in various analysis
software (see Appendix A).
251
252
Project Decisions: The Art and Science
Principle 2: Minimize the cost of decision reversals.
(“Try not to kill the cow.”)
There is an old legend in which an elderly woman, having spent her last penny,
decided to sell off her only cow to be slaughtered for meat. She called the local village
butcher, who told her there were three pricing levels:
a.The total weight of the live cow
b. The total weight of the dead cow after initial processing
c. The total of weight of the processed carcass, minus by-products that could not
be sold.
The price per pound for B is greater than that for A, and for C is greater than that for
B. The problem is, the woman had to make her choice before the cow was slaughtered.
If she chose to kill the cow, she would get a higher price per unit of weight, but would
this be more or less than what she would receive for the live cow? If she decided to
kill the cow first, she would be faced with the same type of decision when choosing
between options B and C. However, she would be constrained by the fact that once
she decided to forgo option A, her options would then be limited to B and C. In other
words, the decision to kill the cow is irrevocable. We are not experts in the cow-killing
business, but we feel fairly confident in saying that trying to resurrect a cow would
not be a trivial process.
The old lady had the difficult task of estimating whether the cow would be worth more
dead or alive. Lacking any real data, she had to gamble. “Kill the cow,” she said. And
she won: The dead cow was worth more than the live one. She also went on to guess
correctly when she agreed to the further processing of the cow. As a result, she got
the maximum possible price for her cow. The legend doesn’t tell us if she used her
newfound money to buy milk.
We do not recommend that you gamble with your projects—it is a bad idea,
even though a lot of project managers routinely do it. But what if your original decision happened to be wrong? How much would it cost to go back and
salvage the project? (That is, how much would it cost to bring your dead cow
back to life?)
When you are performing a decision analysis, we recommend that you
consider the cost of decision reversal, which is the cost associated with all the
expenses related to a wrong decision. In theory, the cost of a decision reversion can be between 0 and infinity for an irrevocable decision like killing a
cow (Figure 20.1).
Cost of Decision Reversal
Adaptive Project Management
Irrevocable Decision
Fully Revocable Decision
Ability to Reverse Decision
Figure 20.1 Cost of Decision Reversal
The idea behind this concept is that when you make a decision, you should
also try to formulate an alternative that you can implement at minimum cost.
For example, if you are an opera producer, you should always have the phone
number of an easy replacement for your diva if she ends up in rehab after her
15th divorce. If you remember, in Phantom of the Opera, the producers had a
similar issue when they had to bring in the new star Christine (the object of
the Phantom’s affection) after the original star was poisoned by the phantom.
One never knows what goes on backstage.
Unfortunately, you cannot always make a U-turn in the middle of a project
because it brings up a whole new set of risks: heavy traffic and slick roads.
Principle 3: Make small, sequential decisions.
The movie Wag the Dog is a good example of a project with multiple uncertainties and sequential decisions. Just two weeks before the presidential election, the president finds himself embroiled in a scandal that is threatening
to escalate and ruin his chances at reelection. To divert attention from the
scandal, the President’s handlers and advisors decide to invent another crisis,
a war with Albania (decision #1). With the help of a famed Hollywood pro-
253
254
Project Decisions: The Art and Science
ducer, the President’s advisor has several fake war scenes produced and distributed to the media. When they find themselves being undermined by other
elements in the government, the advisors decide to add another twist to the
tale by inventing a hero left behind enemy lines (decision #2), whose televised
rescue will captivate the American audience. Unfortunately (for them), in an
unexpected turn of events, “the hero” turns out to be a violent psychotic,
and in the end he is shot. Still trying to make the best of a bad situation, the
President’s advisors decide to continue the charade by staging a state funeral
for “the hero” (decision #3).
While this example is somewhat extreme (but very amusing), it shows how
decisions can be made as a response to a constantly changing business situation. In other words, the advisors were using iterative decision-making.
In Chapter 12 we discussed use of the agile methodology in project management. We mentioned the benefits of an iterative approach, where requirements are not completely defined up front and a working (and constantly
redefined) project is delivered to the client on a regular basis.
Now we will prove to you mathematically that managing risks and uncertainties using an iterative project management process will save you time
and money. Let’s assume that we have two scenarios affected by the same
risk (Figure 20.2):
n
Scenario 1. There are three 20-day tasks, and each task has a risk
“change of requirements” with a probability of 20%. If the risk occurs,
the task will have to be restarted. The risks for each task are not correlated, so three small, separate decisions will be reviewed and, if necessary, corrected during the course of the project.
Risk
20%
Risk
20%
Scenario 1
Risk
20%
Risk
60%
Scenario 2
Figure 20.2 Quantitative Analysis of Two Project Scenarios
255
Adaptive Project Management
n
Scenario 2. There is one 60-day task with the same risk, “change of
requirements,” but with a probability of 60%. If the risk occurs, the
task will have to be restarted. This will require only one strategic decision that will be strictly followed during the course of the project.
Which scenario will be completed first? An answer to these types of questions requires quantitative analysis. In this case, we will use event chain
methodology for the analysis. The original
project schedule is shown on the event chain
diagram as white bars. The project schedule
Constraint learning
with risks has gray bars. Table 20.1 shows the
and improvements can
results of the analysis.
be implemented only
As you can see, the project scenario with the
three 20-day tasks will be completed on averin a creative business
age 17% faster than the project scenario with
environment.
one large task. Moreover, if the risk “change
of requirements” is most likely to occur at
the end of the task, the difference between
the two scenarios will be even more significant. In addition, the second scenario is also much more risky because the
range between low and high estimates of duration is much larger than that
for the first scenario.
Risk most likely occurs at the
end of the activity (triangular
distribution for moment of risk)
Risk
Scenario 1: 3 tasks,
20 days each
Scenario 2: 1 task,
60 days
Equal probability of the risk
occurrence during the course
of activity (uniform distribution
for moment of risk)
Risk
Low
estimate
(P10)
Mean
High
estimate
(P90)
Low
estimate
(P10)
Mean
High
estimate
(P90)
60 days
68 days
80 days
60 days
66 days
78 days
60 days
84 days
115 days
60 days
78 days
110 days
Table 20.1 Results of Quantitative Analysis: Duration of Project in Days
256
Project Decisions: The Art and Science
What this means is that projects with risks can be completed earlier if they
are done iteratively. The iterative approach ensures faster feedback, which
can be a result of testing, prototyping, demonstration to the client, and so
on. Through this process, we can learn from actual experience and apply this
learning to the next stage or iteration of the project.
Principle 4: Support creative business environments.
If during a project you receive new information, you should be able to use it
to steer the project in the right direction. At the same time, you do not want
to create chaos by making frequent U-turns as a response to small requests or
small changes in the business environment.
Unfortunately, many organizations are not able to strike a balance between
their ability to improve projects by using actual project information and their
change control process. Often, the change control process is so vigorous that
it suppresses any creative decision-making. For such organizations, the main
problem is that necessary corrective actions will not be taken due to organizational pressure. If this is an issue, you will not be able to resolve it without
major improvements in the organization’s culture.
Principle 5: Identify and fix problems early (avoiding
behavioral traps).
Suppose that during the project planning stage we made certain decisions
that have been proven to be wrong during the execution of the project. However, we are reluctant to make necessary changes.
The longer we continue with an incorrect course of action, the more difficult it will
be to reverse the course of action. This phenomenon has several different explanations, including technical and organizational. One of the most common
explanations is related to behavioral traps. For example, the more money we
invest in a failing project, the more money may be lost. This is the sunk-cost
effect, which we discussed in Chapter 2. The longer we continue to develop
a software application with an unfriendly user interface, the more we get
accustomed to it, and the more difficult is to create a new interface. Therefore, it is very important to identify problems as soon as possible, perform an
analysis, and try to fix them.
The PMBOK® Guide Approach to Project Executing,
Monitoring, and Controlling
The PMBOK® Guide does not explicitly use the term “adaptive management.”
However, you will find important information related to adaptive manage-
Adaptive Project Management
ment in two of the Guide’s process groups: project executing and project monitoring and controlling.
The project monitoring and controlling process group includes the following
project management processes:
1. Monitor and control project work. This includes collecting information, measuring project performance, and updating forecasts.
2. Integrated change control. This occurs when any changes to the project
scope through corrective and preventive actions need to be collected,
analyzed, documented, and approved or rejected. For example, as a
result of testing, one component of the device does not meet specifications. While this issue needs to be addressed, this change may occur in
the middle of the project and affect many other activities. This kind of
impact must be carefully analyzed.
3. Quality control. This includes measurements, corrective and preventive action, recommended defect repairs, validation of deliverables,
and other outputs. Good quality can be achieved not only by original
design but also by constant testing and monitoring during the course
of a project. It is very important to find a problem or a defect as early
as possible; otherwise, the repair can be much more costly.
4. Risk monitoring and control. This includes tracking risks, monitoring residual risks (for which risk response is implemented), identifying new risks as early as possible, recommending preventive actions,
and executing risk-response plans during the course of a project. The
PMBOK® Guide (Chapter 11) recommends regularly reassessing risks
based on actual project data. Risk audits can help to control the efficiency of risk responses. Reserve analysis helps to determine the amount
of contingency reserves remaining at any time in the project.
Other processes included as part of the project monitoring and controlling
process group include scope verification, scope control, schedule control,
project team management (tracking the performance of team members and
coordinating changes to enhance performance), performance reporting, stakeholders management, and contract administration.
One technique mentioned in the PMBOK® Guide that can be used in adaptive
management is a technical performance measurement, in which you constantly
compare technical accomplishments during the course of a project with the
project plan.
257
258
Project Decisions: The Art and Science
Adaptive project management is a process of constant learning, feedback, and
improvement to the project management process. Adaptive project management
is based on five main principles:
1. Combining original assumptions and actual project data through quantitative analysis
2. Minimizing the cost of a decision reversal
3. Using an iterative approach to decision-making
4. Having a supportive organizational culture
5. Identifying and resolving issues as early as possible.
Chapter 21
Did You Make the Right Choice?
Reviewing Project Decisions
P
ost-project reviews of project decisions are important because they
allow you to improve future decisions. However, these reviews can
be influenced by a number of psychological biases. For example, management will often believe that project failures were more readily foreseeable
than they actually were. A corporate knowledge base should provide a source
of information about previous decisions and their outcomes.
Why Do We Need Post-Project Reviews?
Now that you have completed your project, you have reached the point
where you need to review and understand any lessons learned from it. When
you perform your project reviews, there are some questions that need to be
addressed:
n
n
n
Which choices were correct and incorrect? Why?
Did you correctly identify risks and assign their probabilities and outcomes? Did you plan your risk responses properly?
How do the results of your quantitative analysis compare with the
actual data? If they are different, why?
This is one of the most important steps in the decision analysis process
because it will improve decision-making in the future. Most organizations
perform these assessments, either formally or informally.
Unfortunately, not many organizations analyze how they selected their project
plan from among the alternatives and determined the probabilities of the risk
events. Moreover, few organizations have mechanisms in place to store this
information where it can be easily retrieved. Often, the only record of this analysis is stored in the memories of the participants. Given normal staff turnover
and the vagaries of human memory, this is a high-risk strategy in itself.
Before we explain how to set up a post-project review process in your organization, let’s examine a number of psychological biases related to project
reviews.
260
Project Decisions: The Art and Science
How Could We Not Foresee It?
Well before Hurricane Katrina struck New Orleans (Figure 21.1) in August 2005,
there were many predictions of how a hurricane would wreak disaster on the city
(Wilson 2001; Fischetti 2001; Mooney 2005). In 2001 the Houston Chronicle
published a story that predicted that if a severe hurricane struck New Orleans, it
“would strand 250,000 people or more, and probably kill one of 10 left behind as the
city drowned under 20 feet of water. Thousands of refugees could land in Houston”
(Berger 2001).
Much of New Orleans sits below sea level. To prevent flooding, the city is
defended by an extensive levee system. Parts of the system are quite old, and
there were concerns about the system’s ability to withstand the stress that a
hurricane would impose upon it. Following Hurricane Katrina’s landfall in
August 2005, the levees failed in several places. Floodwater from Lake Ponchartrain inundated the city and caused many deaths and billions of dollars
in damage. In the aftermath of Katrina, investigations have demonstrated
Figure 21.1 Flooding in Northwest New Orleans and Metairie after Hurricane Katrina
Did You Make the Right Choice? Reviewing Project Decisions
that the levee failures were not caused by natural forces that exceeded the
intended design strength. The problem lay in the design of the structures, in
addition to poor maintenance practices that exacerbated the condition of the
levees. It is important to mention that the mechanism of potential levee failure was known long before Hurricane Katrina struck.
The question is, if there were so many warnings about potential problems
with the levees and the risk of hurricanes, why weren’t more resources
invested to improve the levee system? Now, after the event, these warnings
are considered not to be probabilities, but absolute certainties. Before Hurricane Katrina struck, federal, state, and municipal governments and other
organizations did not believe that major improvements to the levee system
were a main priority. This was because the probability of an event as destructive as Katrina was underestimated, even though a number of experts had
warned about the risk. Because the cost of protection against such an extreme
event must be juggled with other public priorities, only a limited amount of
work to improve the levees was done (Hardwerk 2005).
This psychological phenomenon occurs not only in major calamities but in
project failures as well. Often, as we look back at a failed project, we just cannot understand how we did not foresee a catastrophic event when we were
given so many warnings. What caused us to ignore those warnings?
In reality, we are experiencing a common psychological phenomenon that
occurs when reviewing the results of project decision analysis: After the event,
we tend to believe that project failures were more readily foreseeable than was in fact
the case.
In any project there is a chance of failure or a major risk event that can significantly affect it. However, if the probability is deemed small, the project will
proceed with risk mitigation in place. Risk mitigation does not mean that the
risk will be completely removed, just that the probability of the risk occurring
and its potential impact will be reduced. Let’s assume that an event occurred
and caused major problems. In the aftermath of this event, management will
believe that the wrong decision was made. But this is not necessarily true,
for the decision could have been correct as long as decision analysis was performed using the most comprehensive information available at the time.
Situations are much more difficult when an unpredicted risk event occurs.
Generally, these events were not foreseen because there was incomplete or
imperfect data to perform an analysis. However, once an event has occurred,
it is impossible to erase any knowledge of the event and reconstruct the mental processes that occurred prior to the event.
261
262
Project Decisions: The Art and Science
During the decision process, a lot of irrelevant information must be sorted
through (Wohlstetter 1962). Do you recall the movie Tora, Tora, Tora, which
dramatized the events leading up to and during the Japanese attack on Pearl
Harbor? At the start of the movie, several scenes describe the warnings about
an impending attack that the military and political leaders received and the
chain of events that led them to underestimate or disregard the threat. After
watching this movie, you might wonder how all of these people missed so
many obvious signs of an impending attack and how so many could get it
so wrong. In reality, there were many, many other events occurring at the
time that were not shown in the movie. Since we all have 20/20 hindsight, it
always becomes clear to us after the fact which information was relevant and
which was not. Because of this phenomenon, after a risk event occurs, management tends to believe that it should have been easy to foresee the risk and
make the correct decision.
“I Knew It All Along”
Did the decision analysis process help us make better decisions for this particular project? How much more did we learn from the analysis than we
already knew? These are very common questions raised by the management
that approved the decisions.
“I knew it all along,” referred to in psychology as the hindsight bias, is a very
common psychological bias. Management usually underestimates how much
they learned from the decision analysis process. As a result, management tends
to undervalue the process—after all, why bother with decision analysis if we
already know the answer.
At the project initialization phase, you presented a risk management plan to
your manager. One of the risks was a major delay in the delivery of a component. Based on the analysis, you believed it was a critical risk, and in response
you created a mitigation plan for it—purchase the component from another
vendor. Your manager was not so sure, but agreed to include it in the project
plan. Sure enough, this risk event occurred. Fortunately for the project, you
had lined up another vendor in advance, and the project was completed as
planned. When you have your project review, your manager (who now possesses 20/20 hindsight) notes that the fact that the component delivery risk
was critical was obvious regardless of your risk analysis. He goes further,
questioning the value of your quantitative analysis, as this was something he
says he intuitively knew. Next time the manager may not give you an opportunity to do another analysis.
Did You Make the Right Choice? Reviewing Project Decisions
Once an event occurs, many people, not just decision-makers, tend to exaggerate how much probability they had lent to the event occurring. Before
the event occurred, they might have thought the probability was 15%, but
afterward they will probably confess that they were 99% sure that the event
would occur.
Overestimating the Accuracy of Past Judgments
The two previous biases that we discussed affect managers when they try to
evaluate project decisions. But project managers or analysts who perform the
analysis are not immune from similar biases. In particular, project managers or
analysts tend to overestimate the accuracy of past judgments.
Here is a small psychological experiment you can perform in your organization. Ask a project manager to recreate from memory a risk list or risk breakdown structure he or she defined during a project initialization phase about a
year ago. Now compare it with the original risk list. You will most likely find
that in the new list the probability for risks that actually occurred are much
higher than they were in the original list.
The knowledge of outcomes affects our memory of previous analyses. When
analysts know the outcome, they will believe that they properly identified
the event and assigned the correct probability. The more time that has passed
since the original decision analysis was conducted, the greater the effect of
this bias.
The Peak-End Rule
The peak-end rule is a heuristic in which we judge our past experiences almost
entirely on how they were at their peak (whether pleasant or unpleasant) and
how they ended (Kahneman 1999). When we do this, we discard other information, including net pleasantness or unpleasantness and how long the experience
lasted. This heuristic affects project reviews because many project stakeholders
remember only certain project details. You may remember the product launch
(the first stage of the project) and some highlights during the project (like the
CEO’s visit and subsequent dinner in a good restaurant), but you probably
don’t remember why, how, and by whom certain choices were made.
The PMBOK® Guide recommends identifying lessons learned at any point in
the project. In other words, it recommends that you collect and record information about all major project decisions and events at all stages of the project.
It helps to mitigate memory errors associated with the peak-end rule.
263
264
Project Decisions: The Art and Science
The Process of Reviewing Decisions
Actual project reviews or retrospectives are usually performed as part of
other business processes. The PMBOK® Guide recommends creating an organizational corporate knowledge base, which should include a “historical
information and lessons learned knowledge base.” This information is collected during the project execution. The Closing Project process includes the
Updates of Organizational Process Assets procedure, where “historical information and lessons learned information are transferred to the lessons learned
knowledge base for use by future projects.” In practical terms, this means that
the results of project reviews should be saved in an organization’s knowledge
base so they can be referenced when planning future projects.
In software development processes, such as the Rational Unified Process
(RUP) (Kruchten 2000), reviews help to determine whether the established
goal was achieved. Such reviews or retrospectives include people, processes,
and tools and can be performed after each project iteration.
Certain steps should be taken to capture information that is necessary to evaluate project decision-making:
1. Assess input information that was created at the project planning
stage:
n
n
Project schedules
Risk-management plans, including risk breakdown structures with
assigned probabilities of certain events
n
Strategy tables and other information used to select alternatives
n
Results of quantitative analysis.
2. Compare input information with actual data:
n
Was the selected alternative correct?
n
Which events occurred, and which did not?
n
Were duration and cost estimates accurate?
3. Briefly document the conclusions and store the document in a corporate knowledge base.
Did You Make the Right Choice? Reviewing Project Decisions
Corporate Knowledge Base
An organizational knowledge base is where one can find historical information about decisions, as well as lessons learned, in previous projects. How
would a knowledge base work in reality?
In one engineering company, we met with a very interesting person. He was about
75 years old and had worked his entire life in the same organization. He probably had
been working there for 50 years, serving in many different positions. Fresh out of
college, he had a position as a junior engineer, and eventually he became head of his
department. For the last 20 years, he had worked as a full-time internal consultant
to the various divisions in the company. Primarily, he was valued as the corporate
“knowledge base.”
Although he was not able to generate new engineering ideas, this individual’s longterm memory was excellent. He analyzed each project to see if there were any historical precedents that could be applicable. He looked to see if somebody had been faced
with similar issues and what the results of their decisions were. By drawing on this
knowledge, he was able to make some fairly accurate judgments about the actual probability of certain events.
While the human knowledge base seemed to work fine for the engineering
company, human memory always has some limitations. First of all, it is hard
to find a person or a group of people who remember and understand all relevant previous projects. Second, everyone has cognitive and motivational
biases that can affect their judgment about previous decisions.
A number of computer tools are available to help establish a company’s
knowledge base. Some of them are specifically designed for organizational
knowledge bases, and many portfolio management software products have
document management functionalities.
Not all companies have corporate portfolio management software, and not
all companies would store documents related to decision analysis there, even
if they did have the software. Here is a simple and effective way to establish
a corporate knowledge base: Save all your documents on a corporate intranet
in such a way that they can be searched using search tools like Google. These
tools can be used effectively in internal sites where you can search your internal archives. Just make sure you use proper keywords for your documents so
that the search tool can return the most relevant documents.
265
266
n
n
n
n
n
Project Decisions: The Art and Science
Review of project decisions is a very important step, for it will improve
future decision-making.
After an event, management will believe that project failures were more
readily foreseeable than they were originally.
After a project is complete, management will tend to underestimate the
value of decision analysis.
Project managers or analysts who performed the decision analysis tend to
overestimate the accuracy of past judgments.
The simplest way to establish a corporate knowledge base is to save documents related to completed projects on a searchable corporate intranet.
Conclusion
Does Decision Analysis
Provide a Solution?
“It is our choices, Harry, that show what we truly are, far
more than our abilities.”
— D u m b l e d o r e to H a r r y P ot t e r i n
J . K . R o w l i n g ’ s H a r ry P o t t e r a n d t h e C h a m b e r o f S e c r e t s
D
uring the past 15 years, NASA and aerospace companies have been
involved in a number of attempts to revolutionize space launches
(Ballhaus 2005). All of these projects were canceled due to cost and
technology problems (Table Concl. 1). As Ballhaus points out, “the bottom
line—$4.4 billion was spent on these programs, with little to show for it.”
In 1996, NASA selected Lockheed Martin to design, build, and fly the X-33
Advanced Technology Demonstrator test vehicle (NASA 2001). The plan was
Program
Goal
Funds Spent
National AeroSpace • Aircraft-like
$2.4 billion
Plane (NASP)
• operations
• $100/lb to Low Earth
• Orbit (LEO)
Advanced Launch • Heavy lift for SDI
$0.7 billion
System (ALS)
• $300/lb to LEO
X-33/Venture Star
• Single stage to orbit
$1.3 billion
• launch system
• $1000/lb to LEO
Reason Canceled
• Technology
• Cost and schedule
• $16 billion project
• cost
• National priorities
• Technology
• Cost and schedule
Table Concl. 1 Post-Shuttle Attempts to Revolutionize Space Launch. Source: Adapted from
Ballhaus 2005.
268
Project Decisions: The Art and Science
to create a reusable spacecraft capable of reaching orbit without boosters or
dropping rocket engines and external fuel tanks. It was hoped that this project would lead to significant improvements in the reliability and safety of
the space program. With this approach, launching satellites into orbit would
cost one-tenth the price of using shuttles or conventional rockets. In addition, the X-33 was intended to test new technologies for a commercial singlestage-to-orbit (SSTO) launch vehicle. Among these technologies were a new
type of rocket engine called the linear aerospike engine, composite cryogenic
fuel tanks, unmanned flight control, and lifting body aerodynamics. (See Fig.
Concl. 1.) The X-33 was to be launched vertically from a specially designed
facility at Edwards Air Force Base in California and land on a runway at the
end of the mission.
In 2001 the X-33 project was canceled. At that point, the construction of the
X-33 was more than 85 percent complete, with the avionics bay, reaction control system, thruster controller, and landing gear installed. What happened?
The composite liquid hydrogen fuel tank had failed during testing in November 1999. The tank was constructed of honeycomb composite walls and internal structures to be light enough to demonstrate SSTO operations. NASA’s
investigation revealed that the composite technology was not mature enough
Figure Concl. 1 NASA Rendering of Venture Star Reusable Launch Vehicle
Does Decision Analysis Provide a Solution?
to complete the mission. In response, Lockheed Martin proposed to complete
the development of the X-33 by replacing the two composite liquid hydrogen
tanks with aluminum tanks. But NASA concluded that the benefits of testing
the X-33 in flight did not justify the cost because the X-33 would not be able
to reach space with aluminum tanks.
NASA’s investment in the X-33 program totaled $912 million, which was
within its 1996 budget projection for the program. Lockheed Martin originally committed to invest $212 million in the X-33, and during the life of the
program increased that amount to $357 million.
So the main goals of one of the most ambitious technological projects in
decades were not achieved because of technical problems. The X-33 story
illustrates a number of the misconceptions related to the decision analysis
process.
Common Misconceptions about Decision Analysis
There are three common misconceptions about decision analysis.
Misconception #1: The decision analysis process is not
beneficial because it does not ensure project success.
Failure of a project is not an indication that the decision analysis process did
not work. NASA and Lockheed Martin took a calculated risk and invested
in new, unproven technologies. Without taking any risks, the research and
development would have been impossible. To mitigate some of the risks,
NASA and Lockheed Martin built a cheaper test vehicle instead of a full-scale
spacecraft. In cases like this, decision analysis can help reduce the number of
irrational project decisions and mitigate their negative outcomes.
Misconception #2: Decision analysis adds new levels of
bureaucracy.
Absolutely anything can devolve into a bureaucratic procedure. For example,
when you go to the supermarket, you put your groceries on the belt and give
the cashier your credit card, followed by the store’s loyalty card, cards from
affiliated loyalty programs, a gift certificate, coupons from the store, and so
on. You get the picture. In return, the cashier gives you a receipt, your credit
card receipt, and some coupons. In addition, you collect 30 coupons that will
give you a 5% discount on various items on your next shopping trip. What
used to be a quick exchange of goods for cash is now a web of mind-boggling
transactions.
269
270
Project Decisions: The Art and Science
Organizations should use
a decision analysis process
provided that everyone
feels it is helpful. If the
process creates extra delay
or introduces a paperwork
burden, scrap it immediately.
Decision analysis does not necessarily imply
additional administrative overhead. It is more
a way of thinking than a documentation management process, and it should be as simple
as possible. We have stressed throughout the
book that a decision analysis process can be
tailored to meet specific organizational needs.
For example, if you do not think that quantitative analysis is going to add any benefit to your
project, no problem. Don’t use it.
Remember that the main purposes of decision
analysis are to:
n
Come up with real alternatives
n
Analyze which alternative will bring the most value
n
Select a course of action and monitor its progress.
Most organizations already do this in one way or another.
Organizations spend huge amounts of resources establishing business processes, usually for business software, training, consulting, and such. And in
most cases, it is a good investment for the right causes. Shell, for example,
spent roughly $1.5 billon implementing an SAP enterprise resource management (ERM) system (Booth 2005). Sometimes such processes do not work as
planned and do, in fact, create a bureaucracy that leads to more spending. If
this occurs, it is important to freeze the implementation and make necessary
adjustments; or if things are really dire, scrap the process altogether. It is like
an investment in the stock market: If you see a stock tumbling, don’t wait
until is hits bottom. Sell it now and limit your losses.
Misconception #3: Only organizations with mature project
management processes can benefit from decision analysis.
Any company should be able to benefit from the decision analysis process in the
same way that any person would benefit from knowing how to think rationally.
For example, if you have received a bonus, you probably have a few options:
a. Pay down your mortgage (apparently, this is not a very popular
alternative)
b. Buy ten new pairs of shoes from Oscar de la Renta
c. Gamble everything at the local casino.
Does Decision Analysis Provide a Solution?
You will select an alternative based on your preferences (your risk profile)
and on which one will give you maximum value. The point is that you do
not need to hire a consultant, create a sophisticated mathematical model, and
produce a large amount of paperwork to make this decision. The only thing
you need to do is make a logical and rational choice based on the alternatives,
perhaps using something that you have learned from this book.
If you want to establish a decision analysis process, do it step by step. For
example, start by identifying your success criteria, which should be consistent over multiple projects, and identify who will evaluate the alternatives.
If you feel that you are benefiting from these activities, you may continue
adding additional stages of the process: modeling, quantitative analysis, and
review. Once you are comfortable and happy with your process, you may
then want to invest in a software system that will help you with your project
decision analysis.
Why Do We Believe the Decision Analysis Process Is
Important?
The time of amateur tinkers working away in their garages and developing
state-of-the-art technology has passed. Technical innovations in our modern
world have become extremely expensive and take a much longer time to
develop. But marshalling all the money, engineers, and managers still does
not ensure success.
n
n
After the first satellite launch in 1957 and the first manned space flight
in 1961, people started dreaming about building cities on the Moon and
Mars. Well, we all know how far we have gotten with that effort. After
50 years, humanity has not made any more significant strides in space
exploration. This is certainly not what was prognosticated in the early
excitement of the 1960s. In reality, the design of Orion, a new generation
of launch vehicles that was supposed to replace the space shuttle, is
conceptually very similar to what we had 50 years ago (Berger 2006).
For several decades people have been trying to build a thermonuclear
reactor to produce electric power using fusion. Despite significant
progress in the research, a working fusion reactor remains a dream.
The international community, including the European Union, Japan,
China, Russia, Republic of Korea, and the United States, will invest $5
billon over next ten years in the ITER project (ITER 2006), an experiment aimed at proving that fusion can be used to generate electric
power (Figure Concl. 2). In June 2005 this group decided that a 500megawatt reactor will be built at Cadarache, in the South of France,
with the first plasma ITER reactions planned for the end of 2016.
271
272
Project Decisions: The Art and Science
Figure Concl. 2 Artist’s Rendering of the ITER Fusion Reactor
n
For many years there has been a widespread belief that electric or
hydrogen cars will soon replace our gasoline-powered cars, despite
the fact that after billions of dollars of investment we are still far away
from an affordable and practical alternative fuel vehicle.
Often when engineers are unable to solve a technical problem, they say that
the technology is not mature. What does that mean? It means that we have
not spent enough time and resources to solve the problem.
Because we are always faced with scarce resources, where can we find the
additional resources to solve these problems? Can they be found in the existing budgets of our governments or private companies? Technological innovation is not always a priority for governments, especially if it doesn’t have a
military or national security benefit. Private companies focus on profitability,
which can come from technological innovation. However, companies with
the huge resources needed for research and development often expend their
resources very inefficiently because of constraints in their corporate culture.
Conversely, companies with a good corporate culture do not necessarily have
the resources to invest. Finally, with a few exceptions, private investors are
not willing to spend a lot on long-term research and development. They want
quick returns on their investment in the form of dividends and growth in
share value.
Does Decision Analysis Provide a Solution?
Perhaps, then, the solution to scarce resources lies in the more efficient use of
the resources we do have. In particular:
n
n
Good decision analysis processes can reduce the burden of wrong decisions and allow us to spend resources more efficiently and improve
organizational performance.
Changes in corporate culture and the elimination of FDS will reduce
the inefficient allocation of resources and increase productivity.
In conclusion, while resources will always be limited, we exacerbate resource
scarcity through poor decision-making. If decision-makers in business and
government can learn and practice proper decision analysis processes,
this alone will lead to a major acceleration in technological innovation and
productivity.
273
Acquisition Management
R. Marshall Engelbeck
Vienna, Virginia
8230 Leesburg Pike, Suite 800
Vienna, Virginia 22182
Phone: (703) 790-9595
Fax: (703) 790-1371
Web: www.managementconcepts.com
© 2002 by Management Concepts, Inc.
All rights reserved. No part of this book may be reproduced or utilized in any
form or by any means, electronic or mechanical, including photocopying,
recording, or by an information storage and retrieval system, without permission
in writing from the publisher, except for brief quotations in review articles.
Printed in the United States of America
Library of Congress Cataloging-in-Publication Data
Engelbeck, R. Marshall, 1933–
Acquisition management handbook / R. Marshall Engelbeck.
p. cm.
Includes bibliographical references and index.
ISBN 1-56726-128-0 (hc.)
1. Government purchasing—United States—Handbooks, manuals, etc. 2. Public
contracts—United States—Handbooks, manuals, etc. I. Title.
JK1673.E55 2001
352.5'3'0973—dc21
2001044185
CHAPTER
1
Reform of the
Federal Acquisition System
This book is written for members of the acquisition team, especially contract managers, to show how they can meet the challenges of change
brought about by: (1) the crusade to make the federal government more
efficient and user friendly, (2) the end of the Cold War, and (3) improved
communications technology. A book on this subject is important because
the “Reinvention of Government” initiative of 1994 has kicked off the
most extensive revolution in acquisition and logistic processes since the
end of World War II. In addition, everyone involved in the buying or selling of goods and services in the federal market must understand the doctrine upon which these changes to the acquisition process are founded and
how they will affect how the federal government does business.
The Department of Defense (DoD) adopted the term acquisition in 1970
as an alternative to the term procurement. Acquisition became part of the
government-wide regulatory system in 1984 with the issuance of the Federal Acquisition Regulation (FAR).1 In The Government Contracts Reference
Book, the authors point out that the terms acquisition and procurement are
synonymous. Procurement is used in the United States Code, while acquisition is usually used in the FAR.2 Acquisition is defined in the FAR as:
. . .the acquiring by contract with appropriated funds of supplies
and services (including construction) by and for the use of the
Federal Government through purchase or lease, whether the supplies or services are already in existence or must be created, developed, demonstrated, and evaluated. Acquisition begins at the
point when agency needs are established and includes the description of requirements to satisfy agency needs, solicitation and selection of sources, award of contracts, contract financing, contract
performance, contract administration, and those technical and
2
ACQUISITION MANAGEMENT
management functions directly related to the process of fulfilling
agency needs by contract.3
A successful acquisition is built on relationships. Not only is a constructive association between the buyer and seller necessary, but real-time linking between their functional staffs and collaborative relationships within
the integrated acquisition team are vital as well. In part this is due to the
exponential growth of the Internet and its by-product the Website. These
tools are erasing the time, place, and organizational barriers that once
made acquisition a line-flow process. The hypothesis of this book is that a
proactive approach to acquisition management is a prerequisite to providing the user with a best-value product when and where it is needed. Keys to
achieving this objective are to reduce procurement cost through: (1) understanding that the key element in the development of a product or service is a strategic relationship between the contractor and its suppliers, (2)
enhancing market research techniques, (3) implementing a cross-functional integrated acquisition team approach, (4) focusing on managing the
risks and opportunities associated with the acquisition, (5) using the contract agreement as the common language by all members of an integrated
acquisition team, and (6) maximizing the use of electronic data transfer.
The objective of this first chapter is to illustrate how the federal government is responding to pressure from its constituents by being more responsive and cost-conscious. An outgrowth of this initiative has been an effort
to change how government will purchase goods and services in the post–
Cold War era. Reinvention of the acquisition system started over six years
ago when the federal government revised its primary acquisition directive,
the Federal Acquisition Regulation (FAR). Among the many changes made
to this document was, for the first time, the development and inclusion of
a statement of guiding principles and standards. These guiding principles
define the core vision of the federal acquisition system. This chapter also
addresses the performance standards that were included with the guiding
principles because the standards define the critical factors of an effective
and efficient acquisition system.
This chapter will also explain why the government’s acquisition system
needed to be reinvented by reviewing some of the most significant characteristics of the government market, and then briefly summarizing the history of government acquisition over the past 60 years or so.
CHARACTERISTICS OF THE GOVERNMENT MARKET
In procuring its needs, the federal government wears two hats. First, it
acts in a contracting capacity and is expected to exercise good business
judgment when determining requirements and purchasing a wide variety
of goods and services from every sector of the economy. Second, the gov-
Reform of the Federal Acquisition System
3
ernment also is the defender of the taxpayer’s interest and is expected to
act even-handedly while implementing social and political policies.
The dollar value and number of purchases, i.e., $183.1 billion from
487,264,000 contractual transactions in fiscal year 1999, make the federal
government by far the largest buyer of goods and services in the world.
Ten years ago approximately 50 percent of the total dollars spent by the
federal government were for supplies and equipment, with other services,
excluding R&D, A&E, and ADP services, totaling just over 25 percent. As
Table 1-1 shows, expenditures for supplies and equipment in 1999 fell to
around one-third of the total. The reduction in defense spending was a
major factor in this decrease. On the other hand, the amount spent for
services rose to 41 percent. This trend illustrates an increase in outsourcing
service-related tasks to contractors in the private sector as well as the effect
of government’s increased dependence on electronic data interchange.
In FY 1999 the Department of Defense spent $123.2 billion, or 67% of
the total federal contract dollars spent in that fiscal year. The next five top
government spenders were the Department of Energy ($15.6 billion), the
National Aeronautics and Space Administration (NASA) ($10.9 billion), the
General Services Administration (GSA) ($7.6 billion), the Department of
Health and Human Resources ($4.1 billion), and the Department of Veterans Affairs ($4.0 billion).5 What is significant is that DoD expenditures exceed the other five by $82.4 billion. DoD procurement exceeded the
amount purchased by the next four agencies by a factor of three. Consequently, its domination of government acquisition no doubt has a great
deal of influence on the policies and procedures contained in the FAR.
Dr. J. Ronald Fox, former professor of business at Harvard and Assistant
Secretary of the Army, in his book Arming of America: How the U.S. Buys
Weapons, cites the 1962 study of the defense market by Merton J. Peck and
Table 1-1 Major Categories of Federal Government Purchases4—1999
Major Category
Supplies and equipment
ADP equipment, purchases/leases
Research and development
Construction
Architect & engineering
Real property, purchase/lease/maintain
ADP services, including installation and
maintenance
Other services
Total
Dollars (Billions)
Percent of Total
$57.0
6.4
24.5
16.0
1.7
.8
32
3
13
9
1
1
11.8
64.9
6
35
$183.1
100
4
ACQUISITION MANAGEMENT
Frederic M. Scherer of the RAND Corporation. They concluded that the
defense market differs from the commercial market in that it is not determined by supply and demand. First Congress determines how much the
DoD will spend and for what. This decision is influenced by political and
economic conditions as well as international events and the interests of
the members of Congress.6 A market system does not now exist in the
weapon acquisition process . . . a market system in its entirety can never
exist for the acquisition of weapons.7
The government market as a whole is also described as being a monopsony, i.e., consisting of only one buyer. Writing in Contract Management
magazine, W. Gregor Macfarlan states, “as a monopsony, the government
inherently regulates the marketplace to its own ends through defined requirements and specified processes that satisfy those requirements. The
more influential the monopsony, the fewer the opportunities for the marketplace to express its competitive dynamics.”8
It is only when the government purchases off-the-shelf items on the
commercial market that the true forces of supply and demand apply. A
majority of goods and services in this category have traditionally been procured through the sealed bidding method. Sealed bid purchases, although
high in the number of contracting actions, historically have represented a
relatively low percentage of the total dollar value of purchases in any one
fiscal year. Negotiated procurements have traditionally led in the number
of solicitations and dollar amount. In 1990 solicitations for negotiated procurements equaled 85.4 percent of the total action and 93.1 percent of the
total dollars.9
Fair and open competition is the core philosophy of our supply-based
economic system. It is widely believed that competition generates low
prices and promotes efficiency, innovation, and quality. To realize these
benefits, federal procurement policy is founded on giving every potential
responsible supplier an equal opportunity to meet the government’s
needs. For over 100 years procurement procedures also have been directed
toward full and open competition, while government contracting officers
have aspired to protect the “integrity of the acquisition system.” Separate
studies by the RAND Corporation, the Battelle Memorial Institute, and the
Office of the Secretary of Defense concluded that a reduction in contract
price of 25 to 30 percent can be realized when genuine price competition
exists.10 The perception that potential price reductions can best be realized
from competition also is prevalent in Congress and has been a factor in the
government’s efforts to launch such policies as dual-sourcing and leaderfollower development contracts and to perform fact-finding and postaward as a replacement for competition.
When the criteria for classifying a procurement competitive were limited
to goods and services purchased via advertised bidding, less than 50 percent of all procurements were judged to be competitive.11 Then in 1984,
Reform of the Federal Acquisition System
5
Congress passed the Competition in Contracting Act (CICA), in which it
reemphasized the need for the government buyer to reap the benefits of
competition. The act also states that negotiated procurements can be considered competitive when there is more than one prospective seller. The
percentage of purchase actions classified as competitive increased from 44
percent in 1984 to 67 percent in 1990. Stanley Sherman, then Professor of
Purchasing at George Washington University, points out that this occurred
at the same time the broader private economy, especially manufacturers of
commercial products, were experiencing an unmistakable trend toward
fewer competitive purchases.12
An agreement between the buyer and seller in the commercial sector is
subject to the Uniform Commercial Code (UCC).13 On the other hand,
purchases by the federal government are governed primarily by the FAR.
Compared to the FAR, the UCC is broad and flexible. The FAR, which was
codified on April 1, 1984, is “designed to prescribe, structure, and control
the method and procedures by which is conducted in a defined segment of
our economy—government procurement.”14 Further executive orders,
regulations, rules, and procedures are frequently issued that are designed
to provide additional detailed instructions to the operation agencies
within the Executive Branch while:
• Ensuring fairness of contract award by affording all interested and responsible suppliers equal opportunity to obtain the contract
• Giving the government the right to change its mind and cancel a procurement, with reimbursement limited to cost incurred and profit limited to items delivered
• Requiring contractors to disclose their cost or pricing data in order to
ensure the price is fair and reasonable
• Giving a share of contracts to small business, small disadvantaged
business, contractors in labor surplus areas, and minority groups.15
Sherman believes the greatest distinction between the public and private
sectors is the absence of a profit-and-loss standard in the public sector. The
bottom line provides a means to measure success. The commercial firm can
purchase the stated requirement directly, without so much oversight, and
is graded on its competitive position in the market and its profitability. The
federal government does not have such a single standard for success. Instead it has multiple goals, including cost, schedule, and technical performance as well as the social and economic goals of the nation.16
THE FEDERAL ACQUISITION SYSTEM: THE PAST 50 YEARS
After more than 50 years of war and near–world war confrontations, the
American taxpayer was ready for a peace dividend in the form of lower
6
ACQUISITION MANAGEMENT
taxes and an end to deficit budgets that hindered economic growth and
their standard of living. This period in our nation’s history began in 1940
with President Franklin Roosevelt’s call to the nation to be the “great arsenal of democracy,”17 which occurred just a year prior to the United States
entering into war with Germany, Italy, and Japan. For the next five years
the nation’s industry and procurement system built and supported a twoocean navy and a military of over seven million troops fighting simultaneously in Europe and the Pacific theaters. Materiel and supplies produced
in this country also helped maintain the war efforts of our allies. After a
short respite, during which U.S. military capabilities were cut back, the
American people were again called to deter an external threat. This time it
was communism, exported by the Soviet Union. The next 40 years would
be known as the Cold War period, beginning with the European Recovery
Program (Marshall Plan) in 1947, continuing through the Korean War
(1950–1953) and Vietnam War (1964–1973) and ending with the collapse
of the Soviet Union from within in the early 1990s. During this time the
American economy not only supported significant defense and foreign aid
expenditures, but also significantly increased its social programs.
At the end of the Cold War the balance sheet showed our national
economy had been able to build and support an armed force second to
none while providing the commercial sector with countless commercial
goods and also expanding social services. A review of the Gross Domestic
Product (GDP) between 1968 and 1998 (Figure 1-1, Federal Budget Catego-
30
TOTAL OUTLAYS
20
%
ENTITLEMENTS
10
DEFENSE
DEFICIT
0
68
73
78
83
88
93
98
Figure 1-1 Federal Budget Categories as a Percentage of GDP19
Reform of the Federal Acquisition System
7
ries as a Percentage of GDP), shows that the percentage of GDP allocated to
entitlements increased 4.4 percent, while defense spending fell from 9.4 to
3.2 percent of GDP. This represents a reduction of almost one-third of the
amount spent for defense in 1968. During the same period total outlays
decreased by 0.9 percent, and the budget deficit as a percentage of GDP
decreased from 3.2 to 0.3. Note that as entitlements rose from 6.9 percent
of GDP, the deficit was decreased by 1.9 percent. The legacy of the era has
downplayed how economic expansion enabled the nation to meet commercial and defense needs simultaneously. Instead, commentary concentrated mainly on the inefficiencies of the federal government. Public opinion18 questioned the federal government’s ability to operate effectively and
efficiently. This apprehension was fueled by budget deficits, the individual
tax burden, and stories in the media of unsuccessful programs and government purchases gone wrong.
THE FEDERAL ACQUISITION SYSTEM: VIEWED FROM THE INSIDE
LOOKING OUT
Acquisition management is a well-established activity within government,
with a set of management responsibilities that are perceived to be broader in
scope than procurement.20 This is because it traditionally has focused on
large-scale purchases of major defense systems, usually under the direction of
a project or program manager. Acquisition follows an integrated systems approach with applicable technical and management disciplines collaborating to achieve the goals of the acquisition. This integrated team often includes members from logistics, production, quality assurance, finance,
contract management, and the appropriate technical disciplines.21
An acquisition of a product or service often consists of multiple procurements. The term procurement, when applied to the government environment, includes all stages of the process of acquiring property or services,
beginning with the determination of a need for the property or service and
ending with contract completion and closeout. In the private sector it is
comparable to materials management, which is a concept that integrates
the flow and control of materials and services, beginning with identifying
the need and ending after delivery to the ultimate user.22 “Both [acquisition and materials management] are interface functions that interact with
both supplier’s and customer’s organizations as well as with internal functions and activities.”23
In the federal government, Congress is the source of funds and thereby
exercises the ultimate control over government procurement. The executive branch and its associated agencies have been given the authority to
regulate the acquisition system. Over the past 200 years, both Congress
and the executive branch have relied on legislation to fulfill their constitutional responsibilities to protect the public interest and ensure fairness
8
ACQUISITION MANAGEMENT
through common treatment. As Figure 1-2 (Most Significant Procurement
Legislation, 1795–1994) illustrates, there has been a noticeable increase in
the amount of legislation regulating procurement since the end of World
War II.
Over the past few years writing directives to solve the issues has not been
left solely to Congress. Agencies within the executive branch have issued
supplements to regulations and have developed unique rules and practices in
the acquisition process. The DoD FAR supplements are a prime example. The
practice has been that whenever there is a snafu, the bureaucracy has responded by revising or writing a regulation to ensure that the problem doesn’t
recur. The result was a maze of intertwined legal and accounting rules.24
The purpose of the Truth in Negotiations Act (TINA) of 1962,25 and subsequent revisions, was to “assure that the Government is placed on an informational parity with contractors in price negotiations and avoid excessive contractor prices and profits. Failure by a contractor to disclose
current, accurate, or complete cost or pricing data may result in over pricing and government recovery of excess cost.”26 The contractor also can be
charged with fraud if the disclosure is intentionally incorrect. TINA provides the buyer information on the seller’s cost, which is unique to government acquisition. It can also be viewed as a way the government obtains
information compensating for the absence of the market forces and en-
Major Legislation
Federal Acquisition
Streamlining Act
(1994)
Acquisition
Reform
Act (1987)
Purveyor of Officials Not
Supplies Act
to Benefit
(1795)
(1808)
1800
Sealed Bids &
Public Openings
(1845)
1850
Civil
Sundry Act
(1861)
Federal Property
Administration Act
(1949)
Armed Services
Procurement Act
(1947)
WWI
WWII
Mobilization
Mobilization
(1916)
(1941)
1900
OFPP Act
(1974)
Cost Accounting
Standards Board
(1972)
Truth in
Negotiations
Act
(1962)
Acquisition
Reform
Act (1986)
Competition in
Contracting
Act (1984)
Contract
Disputes Act
(1978)
1950
Figure 1-2 Significant Procurement Legislation, 1795–1994
2000
Reform of the Federal Acquisition System
9
hances its bargaining power. The requirement to provide cost or pricing
data does not apply to sealed bids but does apply to modifications to contracts awarded under the sealed bidding process.
The requirement for consistency in a contractor’s accounting practices
was the subject of PL 91-379, which was passed as part of the Defense Production Act in 1970. This law was the result of criticism by Admiral
Rickhover, the father of the nuclear submarine, of the government’s ability
to identify properly the contractor’s cost to specific contracts.27 He also
stated, “the single most serious deficiency in government procurement
was the lack of uniform standards,” in testimony before the House Committee on Banking and Currency in 1968. This motivated the Senate Banking Committee to direct the Comptroller General to study contractor accounting practices. The end result was a law in 1972 requiring the
establishment of a Cost Accounting Standards Board, which would from
time to time review accounting practices and promulgate cost accounting
standards. As a condition of contracting with the government, other provisions of the law are: (1) defense contractors and subcontractors with more
than $10 million in contracts and subcontracts must disclose their accounting practices, and (2) there must be a contract price adjustment, with interest,
for any increased cost paid by the government because of the contractor’s
failure to follow the cost accounting standards created by the board.28
The Competition in Contracting Act (CICA) of 1984 (PL 98-369) represents another significant legislative initiative. The goal of this legislation is
to make the government operate more as a business by requiring more
competition.29 It represents a reaction by Congress to stories of inefficiencies, e.g., $400 hammers and $3,000 coffee pots. CICA was an alteration of
Congress’s “historic preference for formal advertising....; it reversed nearly
two centuries of tradition...” by “placing negotiated procurement (a World
War I innovation to gain flexibility) on the same level as formal advertising.”30 Statistics reported in his book Government Procurement Management
led Dr. Stanley N. Sherman to conclude that the upward trend in modifications to ongoing contracts between 1985 and 1990 may have offset an
apparent increase in competitive procurements.31
The “federal buying system is undoubtedly the most thoroughly examined, carefully thought-out, and fully documented procurement system in
existence.”32 There have been investigations and studies of the federal procurement process, their stated objective often being to make the government operate more like a business.
In the 1980s there were two major examinations by commissions composed of distinguished citizens from the private sector. Both had charters
to hold hearings, make site visits, and submit recommendations on ways
to “fix” the procurement system. In 1983 the Grace Commission analyzed
the procurement process and submitted recommendations on how to improve federal acquisition. Next, the president’s Blue Ribbon Commission
10
ACQUISITION MANAGEMENT
on Defense Management, headed by former Deputy Secretary of Defense
David Packard, issued a report in June 1986 titled Quest for Excellence. The
Packard Commission had a broader scope than did the Grace Commission,
addressing national security planning, military organization and command, acquisition organization and procedures, and government industry
accountability.33 Both commissions submitted recommendations that resulted in passing new or revised laws and issuing more regulations.
The net result of legislation and procedures created by Congress and executive agencies themselves was placed in perspective in a 1987 study by
the Center for Strategic and International Studies (CSIS) titled “US Defense
Acquisition: A Process in Trouble.” The study found “procurement regulations alone total more than 30,000 pages and were issued by 79 different
offices.” In addition, “defense activities were monitored by 55 subcommittees of 29 congressional committees, assisted by more than 20,000 staff
and supporting agency members.”34 Laws, regulations, check lists, and
oversight had replaced individual responsibility and accountability.
This all adds up to thousands of pages of regulations and instructions,
some of which may even have the force and effect of law because they have
been authorized by Congress.35 Under a unique concept called the “Christian doctrine,” when a federal procurement contract does not contain a
clause that is required either by statute, regulation, or executive order, then
it is automatically “incorporated by operation of law.” The roots of this
doctrine can be traced to a 1963 court case that ruled the Termination for
Convenience of the Government clause, required by regulation, that had
been excluded from a contract is to be read into a contract whether or not
it was physically included in the contract, unless a proper deviation from
the contract has been obtained.36 The Christian doctrine became a method
whereby contracting officers (COs) could argue that a required clause is
automatically incorporated into the contract by operation of the law. A
more recent case law provides clarification. For the Christian doctrine to be
applied, the clause must express or implement a deeply ingrained strand of
public procurement policy, and then only if its incorporation is not sought
by the party who is intended to benefit from the clause’s presence.37
In his book The Death of Common Sense, Phillip K. Howard reports that since
the 1950s the nation has experienced, in the name of due process, the rise in
the use of rules and regulations as a way to minimize discretionary government administrative decisions: “Our regulatory system has become an instruction manual. Detailed rule after detailed rule addressing every eventuality, or every situation the lawmakers and bureaucrats can think of.”38
Maintaining an even playing field is key to the government procurement process. All potential suppliers are to be offered an equal
opportunity to bid on a potential contract, and the CO must be
able to justify the contract award decision publicly. This is a constraint purchasers in the private sector do not enjoy. Therefore, being
Reform of the Federal Acquisition System
11
able to base the award on objective criteria, i.e., written specifications
and lowest price, has traditionally been essential to defending the
award in the event of a protest by an unsuccessful bidder. Various
critics of the process have noted that constraint-driven management
may be the enemy of goal-driven management.39
THE FEDERAL ACQUISITION SYSTEM: VIEWED FROM THE OUTSIDE
LOOKING IN
Examples of $400-hammers and $3,000-coffee pots have initiated numerous audits and investigations, editorials, and jokes on late-night talk
shows. However, this is not a recent phenomenon. The fear of profiteering
from the sale of goods and services to the government is as old as the nation itself. History cites examples at Valley Forge, during the Civil War, the
war with Spain, and World Wars I and II.40 The American public has looked
with a judicious eye at selling to the government for quite some time, especially in the defense industry, where the thought of anyone profiting from
war is especially disturbing. U.S. National Survey: Public Attitudes in Defense
Management, published in 1986 as part of the final report to the president
by the Blue Ribbon Commission on Defense Management (Packard Commission) reported, “four in five Americans think that defense contractors
should feel an obligation, when doing business with DoD, to observe ethical standards higher than those observed in their normal business practices.”41 The report concluded that “the lack of confidence in defense contractors may affect public support for important defense programs, and
thus weaken our national security.”42
Jacob Goodwin, in the Brotherhood of Arms: General Dynamics and the
Business of Defending America, relates the story of Harry Truman, then a
senator from Missouri and chairman of a Senate committee investigating
the nation’s defense program, during a visit to the Consolidated plant in
San Diego in the early 1940s. Senator Truman, getting tired of hearing
about the virtues of Consolidated’s latest aircraft, interrupted the owner,
Reuben Fleet, saying, “Dammit, I want to see your books, Fleet. I’m not
interested in your rise from rags to riches story.”43
Over the past 50 years, American industry has become divided into two
segments, i.e., contractors who specialize in government contracts and
those who do not. However, industry as a whole has become more and
more reluctant to participate in the defense market. In 1988 Dr. David V.
Lamm of the Naval Postgraduate School published the results of a study
conducted to determine why companies refuse to participate in defense
contracts. The conclusion, which was based on a response of 427 of the
1,300 firms surveyed (33 percent), was that almost 50 percent of the responding firms indicated they did not want defense contracts. The most
prevalent reasons they gave were burdensome paperwork and bidding methods, inflexible policies, and more attractive commercial opportunities.44
12
ACQUISITION MANAGEMENT
A CORE VISION FOR THE FEDERAL GOVERNMENT IN THE
21st CENTURY
In 1993 President Bill Clinton asked Vice President Al Gore to work on
making government function more efficiently and cost less. The challenge
was to regain public confidence in the federal government’s ability to solve
problems by fostering partnerships and community solutions.45 The vice
president formed a National Performance Review (NPR) team, which issued a report in September 1993. The NPR report, From Red Tape to Results:
Creating a Government That Works Better and Costs Less, called for revising
federal procurement regulations into guiding principles instead of rigid
rules, decentralizing authority to purchase computers, testing an electronic marketplace, increasing the small purchase threshold, and relying
more on off-the-shelf commercial products.46
In October 1994 the president signed into law the Federal Acquisition
Streamlining Act (FASA), which is the most significant attempt to reform
the government’s acquisition process since World War II, and is a flowdown of the core vision and guiding principles from the NPR. The act also
includes 20 recommendations on procurement from the NPR team’s report. FASA charges the executive branch with reinventing the acquisition
process by increasing personal initiative and decreasing mandatory controls. The overall goal of FASA is to streamline the contracting process
through eliminating non–value-added rules and procedures, shortening
procurement lead times, encouraging the use of automated purchasing
procedures, using electronic commerce to the maximum, encouraging the
use of commercial products to satisfy government requirements, and using
proven contractors as a way to reduce risk.47
Playing a major role in this reform effort is the Office of Federal Procurement Policy (OFPP). Created by Congress in 1974, the OFPP is located organizationally in the White House under the Office of Management and Budget. OFPP is charged with the distribution of uniform policies and
procedures and the maintenance of the Federal Acquisition Regulation System. The FAR, a part of that system, had replaced previously existing regulation systems in 1984.48 In his 1990 book, Procurement and Public Management, Steve Kelman, later to become administrator of OFPP, describes
federal procurement “as a system in trouble”49 and the government industry relationship as “a culture of distrust.”50 Mr. Kelman instructed the task
force assigned to oversee the administrative aspects of revising the FAR to
incorporate such business practices as:
• Placing greater reliance on the good sense and business judgment of
the procurement workforce
• Satisfying the customer’s needs
• Reducing unnecessary layers of review
Reform of the Federal Acquisition System
13
• Emphasizing the importance of timeliness of the procurement process
• Stressing best value judgment in making contract awards.51
Over the next year many revisions were written, reviewed, commented
on by the public, and issued as amendments to the FAR.
It is never easy to put a mechanism in place that fosters a change in the
way business has been done over many years. It can be compared to a large
ocean liner changing its course. Deputy Under Secretary of Defense for
Acquisition Reform Colleen Preston summarized the situation facing government procurement as the “most unavoidable challenge facing acquisition reform....[was] going through the needed cultural change.”52
THE IMPLEMENTING ACQUISITION VISION
To facilitate this challenge, the revised FAR incorporates a “statement of
guiding principles” early in the process. This statement includes: (1) a vision statement, or mission statement, for the Federal Acquisition System,
(2) organizational relationships, and (3) standards for performance that
apply to all acquisition participants. This “statement of guiding principles”
is an expression of the mission of the Federal Acquisition System and how
the federal government intends to acquire goods and services. For the first
time, a written statement of acquisition doctrine, clearly defining the core
objectives of the system and the performance standards of the federal acquisition system, has been articulated to participants in the process (see
Figure 1-3).
This implementing vision statement complements NPR’s core vision for
the federal government. It declares that the primary goal of the acquisition
system is “to deliver on a timely basis best value product or service to the
customer, while maintaining the public trust and fulfilling public policy
objectives.” It also concludes that participants can best achieve the primary goal by “working together as a team empowered to make decisions
within their areas of responsibility.”53
The implementing vision answers the question, “What business are we
in?” First and foremost, the goal of every acquisition is to deliver on a
timely basis the best value product or service to the customer while maintaining the public trust and fulfilling policy objectives. Further examination of the vision provides the following insight into its meaning:
• The customers are “the users and line managers acting on behalf of the
American taxpayer.”54
• The primary purpose of each acquisition is service to the customer,
not the process itself.
• The use of the term “best value product or service” means that the
government buyer can use subjective judgment to procure a product
14
ACQUISITION MANAGEMENT
THE GOVERNMENT’S CORE VISION
“A GOVERNMENT THAT WORKS FOR THE
PEOPLE IS CLEAR OF USELESS
BUREAUCRACY AND WASTE. IT IS FREE
FROM RED TAPE AND USELESS RULES.”
VISION FOR THE FEDERAL ACQUISITION SYSTEM
“TO DELIVER ON A TIMELY BASIS THE BEST VALUE PRODUCT OR SERVICE
TO THE CUSTOMER WHILE MAINTAINING THE PUBLIC’S TRUST AND
FULFILLING POLICY OBJECTIVES.”
Figure 1-3 Implementing Vision for the Federal Acquisition System
that provides the greatest overall benefit to the customer. The 1997
rewrite of FAR Part 15.101, The Best Value Continuum, rather than
using the term “best value,” used the term “tradeoff.” This was because: (1) there was no standard definition of “best value,” and (2) an
accurate reflection of what occurs during source selection, when price
is not the only determining factor for contract award, is a tradeoff
between the factors and subfactors that are mandated by statute.
These are cost or price, quality (technical merit and other measures of
the proposal’s worth), and past performance (unless the Contracting
Officer has made a written determination that it is not applicable to
the instant acquisition).55
• The required product must be available when and where the customer
needs it. The economists refer to this as “time and place utility,”
meaning that a product or service has no value unless it is at the required place at the required time.
• The participants in the acquisition process must apply high ethical
standards and maintain the public trust through openness, fairness,
and integrity.
The vision also decrees that implementation can best be achieved when
an integrated acquisition team works together and when all members are
authorized to make decisions within their areas of responsibility. The FAR
describes the integrated acquisition team as “including not only representatives of the technical, supply, and procurement communities but also
Reform of the Federal Acquisition System
15
the customers they serve and the contractors who provide the products
and services.”56 Including the contractor as an advisor to the integrated
acquisition team is a departure from the “past arm’s-length” relationship
and represents an attempt to restore a closer buyer-seller relationship. It
also recognizes that a positive buyer-seller relationship is vital to the success of any contract. In the case of small procurements or routine purchases, the integrated acquisition team can be limited to the line manager,
contracting officer, and seller’s purchasing agent.
The DoD has implemented a process management concept called Integrated Product and Process Development (IPPD), which integrates all activities from product concept through production and support, to optimizing simultaneously the product and its manufacturing and sustaining
processes to meet cost, schedule, and performance objectives. Key to the
success of this management concept is the Integrated Product Team (IPT).
The IPT is a multifunctional team that is assembled around a product or
service and is responsible for advising the project leader, program manager
(PM), or Milestone Decision Authorities (MDA) on cost, schedule, and performance of the product.57
Each integrated acquisition team member is expected to “exercise personal initiative and sound business judgment in providing the best value
product or service to meet customer needs.”58 Authority (and hence accountability) to make these decisions must be delegated to the lowest level
within the system permitted by law.59 Business judgment, based on the
core values, includes establishing objectives, developing plans, and identifying potential risk and opportunities associated with each acquisition.
Prior to contract award the team’s tasks include establishing the project’s
objectives and developing plans that consider the potential risk and opportunities associated with meeting or exceeding the objectives. After award
the integrated acquisition team focuses on the variances from the original
objectives by managing risk and opportunities.
Acquisition doctrine places a great deal of importance on the use of integrated acquisition teams. In addition, including the user and contractor as
members of the team highlights the need for synergy and timely decisions
that can only be achieved through effective communications. Acquisition
doctrine is also an admission that the traditional stovepipe-like organizational
relationships make it difficult to communicate laterally among disciplines,
especially when separate organizations are involved. The integrated acquisition team is designed to facilitate organizational and individual interaction by
creating a multifunctional critical mass so that the acquisition functions (i.e.,
product design, test and evaluation, production, purchasing, logistics support, and contracting) will “sign up” to a shared objective and thus have a
greater sense of commitment to the acquisition process.
In discussing the role of the integrated acquisition team, the FAR states
that “the contracting officer must have authority to the maximum extent
16
ACQUISITION MANAGEMENT
practicable and consistent with law, to determine the application of rules,
regulations, and policies on a specific contract.”60 Ralph C. Nash, Jr.,
founder of the Government Contracts Program at The George Washington
University, suggests that placing the contracting officer (CO) on the integrated acquisition team is very important because it ensures that the CO
will function as a member of a team and not as the person responsible for
the back end of the procurement process.61
The strongest endorsement of using individual initiative in the acquisition process is the FAR policy statement: “if it is in the best interest of the
Government and not addressed in the FAR, nor prohibited by law (statute
or case law), Executive order, or other regulation that the strategy, practice,
policy or procedure is a permissible exercise of authority.”62 This policy
ends an age-old question as to whether or not a course of action not specifically prohibited by law or policy is permitted to be implemented. To many
it represents another departure from previous practice.
PERFORMANCE STANDARDS: A GUIDE TO DECISIONS AND
EVALUATION
The FAR also includes four performance standards that provide a framework for decision making (see Figure 1-4). These standards—customer sat-
VISION FOR THE FEDERAL ACQUISITION SYSTEM
“TO DELIVER ON A TIMELY BASIS THE BEST VALUE PRODUCT OR SERVICE
TO THE CUSTOMER WHILE MAINTAINING THE PUBLIC’S TRUST AND
FULFILLING POLICY OBJECTIVES.”
SATISFY
CUSTOMER
IN
COST, QUALITY,
AND TIMELINESS
FULFILL PUBLIC
POLICY
OBJECTIVES
MINIMIZE
ADMINISTRATIVE
OPERATING
COST
CONDUCT
BUSINESS WITH
INTEGRITY,
FAIRNESS, AND
OPENNESS
Figure 1-4 Standards of Performance for the Federal Acquisition System
Reform of the Federal Acquisition System
17
isfaction, minimizing operating cost, maintaining the public trust, and fulfilling public policy objectives—provide criteria upon which participants
in the process can measure how well they performed. All acquisition officials and members of the integrated acquisition team are advised to keep
these standards in mind when performing their duties, remembering that
they come before policies, practices, and goals.
Customer Satisfaction
The first standard, customer satisfaction, is a restatement of the implementing vision that the primary objective is to satisfy “the customer in
terms of cost, quality, and timeliness of the delivered product or service.”63
It means that the product is more important than the process. This key
performance standard has seven elements (Figure 1-5, Key Elements of
Customer Satisfaction):
1. It is a recognition that the ultimate user’s needs are paramount.
2. Continuous communication with the customer is key to define, and
often refine, the performance characteristics of the product or service.
3. The potential offeror’s track record is to be taken into account when
selecting contractors to provide the product or perform the service.
BE RESPONSIVE TO
CUSTOMER’S
NEEDS
CONTINUOUS
COMMUNICATION WITH
THE CUSTOMER
SELECT CONTRACTORS
WITH PROVEN
TRACK RECORDS
CUSTOMER
SATISFACTION
MAXIMIZE THE USE OF
COMMERCIAL GOODS
AND SERVICES
PROMOTE
COMPETITION
EMPLOY PLANNING AS
INTEGRAL PART OF THE
PROCESS
SYSTEM MUST
PERFORM IN COSTEFFICIENT MANNER
Figure 1-5 Key Elements of Customer Satisfaction
18
ACQUISITION MANAGEMENT
4. The early use of market research is vital to identifying sources within
industry that have the capability to furnish the designated goods or
services.
5. Effective competition must be promoted.
6. To be successful, the acquisition system must deliver a high-quality
product when it is needed, where it is needed, and in a cost-effective
manner.
7. Advanced planning is an integral part of the overall process, but the
system must retain the capability to be flexible.
Satisfy the customer in terms of quality and timeliness of the delivered products
or service: The purpose of this principle is to remind all participants in the
acquisition process that all actions should be directed to supporting the
needs of the customer, who is the ultimate user. It is also important to
point out that the contemporary meaning of the term quality includes the
ultimate user’s performance, reliability, and maintainability needs, which
are defined during the requirements determination and refined product
design phases of the acquisition through a series of tradeoffs.
Principal customers are identified as the users and line managers acting
on behalf of the American taxpayer. How responsive the integrated acquisition team is to the needs and concerns of the customer is a critical factor
upon which the team is evaluated. Customers usually view their needs primarily in terms of performance and schedule. They want to receive exactly
what they ordered—no more, no less, no substitutes, no defects, and at the
agreed-upon delivery date. However, fiscal constraints are a reality that all
who participate in the acquisition process must recognize, and everyone
must be willing to make tradeoff decisions. Therefore, the integrated acquisition team must know how much it will cost to provide the customer the
desired level of quality and service early in the life cycle of the product. For
example, in the DoD the PM, supported by the Cost/Performance IPT
(CPIPT), is tasked to conduct all program cost and performance tradeoff
analysis. The CPIPT’s analysis may result in performance or engineering
and design changes, provided they do not violate threshold values in the
Operational Requirements Document (ORD) and Acquisition Program
Baseline (APB).64
Continuous communications: This is about the management of information—converting ideas into concepts and then into products or services
that meet the needs of the customer. Meeting this standard requires establishing a communication protocol and maintaining an effective feedback
process within the entire integrated acquisition team. Including the customer as a member of the integrated acquisition team facilitates meeting
the customer’s goals. The open communication process includes using the
intranet, extranet, video conferencing, and traditional written and verbal
means.65 After contract award the common language for communicating
Reform of the Federal Acquisition System
19
within the team must be the contract document. This document represents the contract performance baseline that was the product of the negotiated agreement and encompasses the characteristics of the product or
services to be delivered as well as the how, where, and when. Which documents should be designated for use as the performance baseline depends
on the complexity of the acquisition. Examples of appropriate documents
are: specifications, requirements-traceability matrices, statements of work,
work breakdown structures, integrated master plans, integrated master
schedules, earned value systems, system maturity matrices, and technical
performance indicators.
Select contractors with proven track records: Acquisition policy now makes it
mandatory that the past performance record of all offerors be evaluated for
all source selections for negotiated competitive acquisitions expected to
exceed $100,000, unless the contracting officer determines competition is
not an appropriate factor for the acquisition.66
This standard strongly endorses the use of a contractor’s demonstrated
past performance record, or demonstrated current superior ability to perform, to establish the contractor as a primary candidate for a government
contract. The value of this practice to the government is that there is supposedly less risk in selecting a contractor with a proven track record than
one that is relatively unknown. This belief is based on practices being
adopted by industry and Deming’s philosophy, i.e., the value of developing long-term relationships that lead to reduced cost and improved quality
by working together.67 Implementing this standard will not be easy. It requires the buying office to address questions such as: (1) What in a contractors’ past performance history is considered relevant? (2) Does a
contractor’s past performance experience have a shelf-life? (3) How will
corporation mergers and downsizing be considered? and (4) How will firms
without a history of past performance on a government contract be evaluated and compared to one with a history?
Maximize the use of commercial sources: Acquisition policy emphasizes
maximum use of commercial and commercial non-developmental68 items.
This policy was implemented because of the technology explosion, especially in electronic data interchange, and the realization that commercial
items can satisfy a large majority of government requirements. Also, by
using commercial or non-developmental sources, cost will be reduced, lead
times shortened, and the industrial base enhanced. Commercial contractors must be considered not only as prime contractors but subcontractors
as well. Whenever practical to maximize competition, innovation, and
interoperability, the DoD charges its acquisition managers to capitalize on
commercial technologies for the acquisition of products and services.69
This performance standard also charges the integrated acquisition team
to communicate with the commercial sector during the requirements determination phase to identify available capabilities that will satisfy the
20
ACQUISITION MANAGEMENT
user’s needs. This recognizes the vital role market research plays in determining requirements. Market research is defined as “the process that is
used to collect, organize, maintain, analyze, and present data for the purpose of fully understanding the technology, competitive forces, and capabilities of the marketplace to meet an organization’s needs for supplies and
services.”70 The goal of market research is to find the most suitable supplier, product, or service available to satisfy the customer’s needs. To be
successful, early participation in the market research process is required by
all members of the integrated acquisition team.
Selection of a commercial product or service can also be viewed as a way
to accelerate the acquisition process because it identifies goods or services
already available. This strategy bypasses the design and product development phases of the acquisition process. It mitigates the cost, schedule, and
performance risk inherent in the development of items unique to the
government.
For systems, the CO should now focus on developing strategic partnerships because the private sector is depending more and more on strategic
sourcing as part of supply chain management. Selecting the right partner
who will participate in joint planning early in the process is critical. As
suppliers build their businesses around their specialized knowledge and
core competencies, strategic alliances with these suppliers become increasingly important to the design and development of a system and ensure
long-term support. Consequently, supplier assessments of the potential
supply base must be more detailed and precise.71
At this point it is appropriate to point out that the laws, rules, regulations, policies, and procedures used by the federal government can easily
discourage a commercial contractor from doing business in the public sector. One of the most significant laws is TINA, which requires designated
categories of contracts and contractors to furnish the government cost or
pricing data upon which the product or services cost was based. TINA also
requires some contractors to disclose their accounting practices to the government.
Promote competition: Acquisition policy has traditionally emphasized
“full and open competition” as the way to ensure that quality goods and
services are obtained at a fair and reasonable price. This means that all
responsible sources are permitted to compete.72
In a competitive situation, both the seller and buyer will attempt to exploit the situation for their own advantage. The seller will ask as high a
price as it feels it reasonably can. The buyer will not pay more than necessary to obtain the needed item. “Which prevails will depend on relative
bargaining strength, and this will depend on the interaction of such factors
as the number of buyers and sellers of the product, the costs, the amounts
of profit, the intensity of demand, and the alternatives available to both
buyers and sellers.”73
Reform of the Federal Acquisition System
21
As discussed earlier, studies by the RAND Corporation, the Battelle Memorial Institute, and the Office of the Secretary of Defense concluded that
contract price reductions from 25 to 30 percent can be realized in an atmosphere of genuine price competition.74 Price reductions on government
contracts through competition are prevalent. Congress has made clear that
competitive procurements are mandatory, and sealed bids and negotiated
procurements fit the competitive award criteria that “full and open competition” exists.75 Inclusion of negotiated procurements, which permit award
without discussion, and the implementation of the best value and past
performance standards, means the award will no longer be left only to the
low bidder.76 Low price is not a fair way to measure competition because, as
Deming points out, “price has no meaning without a measure of the quality being purchased.”77
Early in our history, contracts were awarded primarily on price because it
was believed that lowest price represented the “best value” to the government. This policy created “the strict conformance standard”—a process in
which lowest price begets the lowest possible interpretation of requirements, i.e., no more, no less. Today, as part of acquisition streamlining,
government policy encourages greater use of performance specifications.
This, coupled with continued advances in technology, means that requirements have become more complex and that the number of variables to
consider when evaluating proposals has increased. Consequently, the 1991
DoD appropriations bill changed the law to enable the use of “best value”
criteria. Best value is consistent with Deming’s fourth point, i.e., “to end
the practice of awarding business on price tag alone.”78 The contractor’s
approach to meeting the requirement, delivery schedule, contractor’s past
performance, and life cycle (support) cost are also major factors to be considered when selecting the supplier.79
The system must perform in a cost-effective manner: This standard relates to
reducing policy and procedural constraints on the acquisition system that
cause it to be characterized as non-responsive and inefficient. The requirement for the system to perform in a timely, high-quality, and cost-effective
manner embraces one of the major initiatives of the vision, i.e., acquisition
employees must be empowered to exercise their individual initiative and
judgment. James Wilson points out that we want government to be both
fair and responsive; but the more rules we impose to ensure fairness, the
harder we make it for government to be responsive.80 Herbert Kaufman is
quoted as saying that red tape is of our own making: “Every restraint and
requirement originates in somebody’s demand for it.”81
The DoD inspector general reported that in the case of procurements
under $500,000, cost and pricing data were still requested 75 percent of the
time, even though they were not required by the regulations.82 Empowering employees to make decisions in their areas of responsibility is a message that a significant cultural change is required. FAR paragraph 1.102,
22
ACQUISITION MANAGEMENT
Statement of guiding principles for the Federal Acquisition System, states
that members of the integrated acquisition team must be empowered to
make decisions in their area of responsibility for the system to become
more responsive. The FAR vision further encourages members of the team
to exercise initiative when it is in the best interest of the government to do
so. If it is not prohibited by law or regulation, and it makes good business
sense to initiate an action, then do it.83 Members of the team can address
tasks in their areas of responsibility from the perspective that if it does not
add value, and the regulations or policies are silent on the subject, then
why do it?
Emphasis is also being placed on the government adopting best commercial practices when and where it makes good business sense to do so. In
the 1980s commercial industry began to focus on the total system cost.
This change in perspective occurred when the private sector realized that
almost 60% of the cost of goods sold went to purchase supplies and services from subcontractors and vendors. Top management realized that
they needed to change their perspective to be more competitive. The primary measures of success no longer were price, keeping the production
line moving, and the cost of operating their departments. Effective management of outside suppliers was recognized in the private sector as a competitive weapon. Purchasing and supply managers began to focus on: (1)
value-added benefits, such as the quality of purchased material and services, and (2) cutting the total cost of acquiring, converting materials to
finished goods, moving, and holding inventories. At the same time, supply
strategies were developed and integrated into marketing, production, and
financial strategies. This has led to three major developments in industry:
1. Using cross-functional commodity teams to identify sources or develop new products
2. Developing and managing the organization’s supply chain
3. Developing collaborative supplier partnerships and strategic alliances.84
An efficient acquisition system is also the outgrowth of the skills and
training of its personnel. As the government downsizes, contracting professionals are assuming an increased workload and becoming generalists
specializing in business management–type duties. Therefore, job training
and qualification requirements must be revised to meet the government
employee’s future needs.
Planning is an integral part of the acquisition system: The acquisition team
must participate in the planning and budgeting process. All members are
also charged to participate in the requirements determination and acquisition planning steps of this process. The integrated acquisition team must
be formed early so that each appropriate discipline can translate opera-
Reform of the Federal Acquisition System
23
tional and support needs into program requirements. Participation in program definition, market research, and the subsequent preparation of the
documentation describing the requirement ensures that all factors are considered. Depending on the size of the acquisition, these documents can be
multidimensional; it is therefore vital that all appropriate members of the
integrated acquisition team participate in initial planning. This performance standard also cautions members of the team to be flexible so they
can adjust to unforeseen changes to requirements as conditions dictate.
Minimizing Administrative Cost
The next performance standard is minimizing administrative operating
cost. This has always been important, but the scale of importance increases
exponentially in periods of declining funds. Some examples of ways to
minimize administrative cost are: (1) shortening procurement cycle time
through the use of electronic communications; (2) eliminating the use of
paper through the use of electronic commerce; (3) using purchase cards for
small dollar purchases; (4) taking advantage of the bulk purchasing power
of the government; (5) using blanket purchase agreements, multiple-award
indefinite quantity contracts, and single agency procurements; (6) integrating product and process; and (7) relying increasingly on commercial
products.
Avoiding excessive checking is another way to reduce administrative
cost. “There is an optimal level of ‘waste’ in any organization, public or
private. It is at that level below which further savings are worth less than
the cost producing them.”85 The benefits derived from added product testing and inspection fit the same law of diminishing returns. Acquisition
managers must determine by cost-benefit analysis if the cost of avoiding
risk entirely is worth the expenditure. Other prime candidates for costbenefit evaluations are performance requirements, process standards,
product modification, product and reliability testing, data items, and size
and structure of the integrated acquisition team itself.
Dr. Paul Kaminski, former Under Secretary of Defense for Acquisition
and Technology and one of the architects of acquisition reform, recalled
how as a program manager in the Air Force he had evaluated recommendations from the engineering support organization on required specifications
and data items. He determined their merit by using the risk-reward (costbenefit) technique.86 Following Dr. Kaminski’s lead, questions to ask when
determining the requirements to be incorporated into the specifications,
processes, and data to be delivered to the government include:
1. Is it vital to product performance and the customer’s mission?
2. Does it enhance management of the program, or is it a “just in case”
requirement?
24
ACQUISITION MANAGEMENT
3. What is the impact on the purchasing cycle time and the personnel
cost of the integrated acquisition team?
4. Can it be accomplished in a less costly way?
Maintaining the Public Trust and Managing Risk
Maintaining the public trust: When framing the Constitution, our founding fathers recognized the crucial role public opinion plays in influencing
what laws would be written, what their content would be, what funds
would be requested, and how those funds would be allocated. Alexander
Hamilton recognized in The Federalist Papers that “legislative discretion is
regulated by public opinion.”87 This performance standard highlights the
importance of maintaining the public trust, calling on each member of the
integrated acquisition team—government as well as contractor—to ensure
the integrity of the acquisition system by handling public resources wisely,
fairly, and openly. The standard states that each member of the team is
“responsible and accountable for the wise use of public resources as well as
acting in a manner which maintains the public’s trust. Fairness and openness require open communication among team members, internal and external customers, and the public.”88
As part of the government’s fiduciary responsibility to the taxpayer, government personnel have traditionally performed oversight of contractor
performance. This often includes full-time personnel assigned to review
the contractor’s performance on site or performing periodic visits to the
contractor’s plant to inspect and accept the deliverable product. Contractor progress is also monitored by reports, often covering numerous details,
submitted by the contractor via contract data requirements lists (CDRL).
This practice has sometimes led to the government approving performance
plans after contract award and creating decision points where government
permission is required prior to the contractor advancing to the next step.
Acquisition doctrine has moved government surveillance to a higher
level without sacrificing the public’s interests. Emphasis is now being
placed on increased use of performance-based contracting, which is designed to increase the contractor’s accountability for achieving the designated performance factors. In exchange for accepting this increased risk,
the contractor is given a much greater amount of flexibility in the way it
performs under the contract.89
Draft solicitations now can be sent to prospective offerors prior to issuing the solicitation. This means that a performance requirement document
fully describing tasks and performance requirements can be developed in
conjunction with the contractor prior to issuing the formal request for proposal. The integrated acquisition team can then monitor contractor performance through the use of performance indicators, e.g., metrics. Under this
concept the contractor also is able to incorporate its current processes into
Reform of the Federal Acquisition System
25
the requirements document rather than create a hybrid process, as has
been the case in the past.
Managing risk: Another way to earn the public trust is to empower officials to exercise initiative and apply sound business judgment to the management of the risks associated with each acquisition. The goal is to be
proactive by shifting the objective of decisions from “risk avoidance” to
“risk management.” This is opposed to “eliminating risk” through the
adoption of all-inclusive processes and extensive test programs.90
Managing risk increases the acquisition team’s readiness to address possible problems. Risk is defined as “the probability of unwanted consequences of an event or decision.” Every risk has a probability of occurrence, an impact, and choices that will affect outcome.91 Risk can also be
described as a potential problem dealing with the possibility of failing to
achieve a designated objective. It is not limited to any one source and can
be categorized by type, e.g., cost, schedule, technical performance, supportability, and programmatic risk. The contractor is also subject to business risk, such as a subcontractor going out of business, failure of a subcontractor to deliver on time, or a component part becoming obsolete.
A historic obstacle in managing risk is the real-life situation in which managers are more often busier correcting today’s problems than preventing or
mitigating tomorrow’s. A large part of the reason for this condition is that the
reward system recognizes those who solve current problems and rarely recognizes those with the foresight to prevent problems from occurring.
DoD Directive 5000.2 defines risk management as “an organized method
of identifying and measuring risk and developing, selecting, and managing
options for handling these risks. The types of risk include, but are not limited to, schedule, cost, technical feasibility, threat, risk of technical obsolescence, security, software management, dependencies between a new
program and other prgrams, and risk of creating a monopoly for future
procurements.”92 Risk management is a systematic approach rather than
an “art or science.”93 Identifying and managing risk is an important part of
each integrated acquisition team’s responsibilities. Policy has shifted the
team’s focus from total risk avoidance to risk management.
Members of the integrated acquisition team can manage risk by: (1) reducing the probability of the problem occurring; (2) developing a contingency plan to work around the problem, should it occur; (3) transferring
the risk to another party; and (4) eliminating the risk completely. In most
cases the cost of completely eliminating a risk is prohibitive.94
Policy initiatives are also addressing risk from the top down. One leading
example in which risk management has been implemented through policy
is the performance standard that maximizes the use of commercial products or services in the FAR.95
An additional example of risk management is the emphasis placed on
the contractor’s recent past performance in making the source selection.
26
ACQUISITION MANAGEMENT
Theoretically, there is less risk when a proven performer is awarded a contract. The FAR performance standard is: “When selecting contractors to
provide products or perform services, the Government will use contractors
who have a track record of successful past performance or who demonstrate a current superior ability to perform.”96
From the contractor’s point of view, almost every acquisition also represents a potential window of opportunity. For example, it provides the contractor the opportunity to improve its sales position and return on invested assets. It also means that the contractor can maintain a positive
record of performance that will enhance its ability to obtain subsequent
business. It could represent an opportunity to launch a new product line or
enhance the contractor’s competitive position within the industry. In addition to receiving the needed product at a fair and reasonable price, the
government also benefits from mission success, improving organizational
efficiency and effectiveness, and enhancing the industrial base.
The key point regarding these windows of opportunity is that they are
often of short duration. Therefore, management must be alert to the opportunity potential present and develop contingency plans before the window slams shut.
Fulfillment of Public Policy Objectives
Congress is the primary authority for turning public policies into law.
Not only does it establish the foundation for rules that govern the acquisition process, but it also initiates social and economic policies through legislation. However, interpreting the legislation is the function of the executive branch of government, with help from the judiciary and case law. The
magnitude of social and economic policies addressed in the FAR is immense and complex. Table 1-2 below lists the categories of social and economic programs.
This performance standard also requires the acquisition system to attain
goals adopted by Congress and the president while ensuring efficient use
of public resources.98 The social economic programs that have the greatest
affect on the acquisition process are small business, small and disadvan-
Table 1-2 Categories of Social Economic Programs97
Programs that Improve Working Conditions
Programs to Favor Selected or Disadvantaged Groups
Programs Favoring Purchase from American Companies
Programs to Protect the Environment and Quality of Life
Programs to Achieve Other Government Purposes
Reform of the Federal Acquisition System
27
taged business, equal opportunity, affirmative action programs, and wage
protection given to construction and service contract labor.
THE INFORMATION REVOLUTION
If the reasons cited above were not enough to encourage reforming the
government acquisition process, the fact that we are also entering the Information Age adds gravity to the situation. In his book Megatrends: Ten
New Directions Transforming Our Lives, Peter Naisbitt claims globalization of
the information society occurred in 1957, when white-collar workers in
technical, managerial, and clerical positions first outnumbered blue-collar
workers. For the first time in our history, more people worked with information than labored to produce goods or services.99
The federal government has had a major role to play in developing the
computer and what we refer to as electronic data interchange. The first
working computer, the ENIAC, was developed for military needs during
World War II. Early in the Cold War, the military requirement for an “early
warning system” in the Canadian Arctic enabled IBM to design and manufacture working computers in substantial numbers.100 The Internet, which
is a group of academic, commercial, and government computer networks,
was developed in 1965 under the auspices of the Advanced Research
Project Agency (ARPA) and the National Science Foundation to link scientific computers for technical research purposes.101
The capability to move data electronically means that people can exchange information without paper. Computer-to-computer exchange has
had a phenomenal influence on how business information is processed,
transmitted, and stored. It can be accomplished through a wide range of
information technologies that include electronic data interchange (EDI),
electronic funds transfer (EFT), electronic mail (e-mail), document imaging, and facsimile (fax) transmissions.
E-mail includes any technology that permits the interchange of electronic data between e-mail users. EDI is a computer-to-computer exchange
of routine business documents using transaction standards agreed on by
both contracting parties.102 Document imaging technology scans the characters from paper and then stores the electronic image on an optical or
laser disk. This technology permits storage and retrieval of thousands of
documents within seconds without the operator leaving the workstation.103 Document imaging, when combined with e-mail and EDI, is not
only making a paperless office a reality but also is revolutionizing the flow
of work within the organization and between the buyer and seller.
EDI is a powerful communication tool that carries a variety of message
formats, including technical drawings, and that can interconnect with a
variety of e-mail networks.104 E-mail fosters communication among buyers,
28
ACQUISITION MANAGEMENT
sellers, and members of an integrated development team because it is not
constrained by organizational or even national boundaries.
One of the primary benefits of EDI is a faster and concurrent flow of
information to members of the integrated acquisition team. The Internet
and sharing of common databases has greatly reduced the information
float (that is, the amount of information that cannot be accessed because it
is in the mail between sender and receiver105). Another advantage of EDI is
greater efficiency due to the elimination of data entry errors and a reduction of personnel costs by reducing handling and storing of documents.
Other revolutionary methods by which data is exchanged include:
1. Electronic funds transfer (EFT), which is the electronic transmission of
payments and remittance information. The Department of the
Treasury’s Financial Management Service (FMS) and the Department of
Defense Finance and Accounting Service (DFAS) are the agencies that
manage invoices and vouchers for the civil and defense acquisition, respectively. Both prefer paying via EFT because it reduces paper-handling
cost substantially. The benefit to the contractor is that it receives payment three to five days sooner than payment via a mailed check.106
2. Facsimile (fax) transmissions, which occur when typed characters on a
page are converted into electronic impulses that are transmitted over
telephone lines to a fax machine for conversion into readable text.
Documents can be faxed over an already existing telephone system integrated into a computer or stored in a document imaging system.107
Within the organization, EDI, E-mail, and document imaging are electronically integrating information used by such traditional business functions as product design, manufacturing, acquisition, inventory management, physical distribution, accounting, and finance. Rather than waiting
for information on the design of a new product to be sent to manufacturing, that information can now be pulled from the design database, thereby
compressing product development time. This same technology permits
the buyer and seller to do business electronically.
The use of EDI for business purposes was advanced with the passage of
the Electronic Signatures Act in June of 2000. Under this legislation electronic signatures and documents have the same legal validity as manual
signatures and hard-copy documents. Key provisions of the act are that: (1)
a signature, contract, or other record relating to a transaction in interstate
or foreign commerce may not be denied legal effect, validity, or enforcement solely because it is in electronic form; (2) a contract relating to such a
transaction may not be denied legal effect, validity, or enforceability solely
because an electronic signature or electronic record was used in its information; and (3) rules for retention of electronic records are set.108
Peter Drucker has stated that “with the advent of the computer, information became the organizing principle for work.”109 Beginning in the 1950s,
Reform of the Federal Acquisition System
29
in most commercial firms such tasks as physical distribution, manufacturing support, and purchasing were organized functionally, and management followed a vertical protocol. Since that time, as new methods to
move and share information have been introduced, organizations have
begun to refocus their orientation away from function operations and
have learned to operate interdependently, rather than independently. This
requires rethinking how work is actually going to be done as well as the
internal management structure. The information-based organization is a
group of specialists with separate bodies of knowledge that are linked in a
network but that function as independent agents. These specialists are
viewed as interacting with the suppliers as well as the ultimate customer.
This interaction occurs across internal functions on a network basis rather
than by formally reporting to a specific manager. Success comes from a
commitment to managing the overall process rather than remaining loyal
to the organizational structure.110
In an article appearing in the Acquisition Review Quarterly, the authors
state that information technology “is changing the role of the
government’s purchasing department from a transaction-oriented function to a more managerial function focused on establishing and maintaining relationships with suppliers, third parties, and internal customers, and
leveraging corporate buying power. In its new role, procurement will also
manage the technological infrastructure necessary either to automate
transactions fully or to empower end users to perform many transactions
without direct involvement of purchasing personnel.”111
It is important to point out that the term procurement as used above has a
broader meaning than the word purchasing. Procurement takes place in
many departments. It is the systematic process of deciding what, when,
and how much to purchase; the act of purchasing it; and the process of
ensuring that what is required is received on time in the quantity specified.
In other words, purchasing is a subset of procurement.112
To purchase goods and services effectively, the government acquisition
process must be able to interface effectively and efficiently with processes
used in the private sector. Management in the commercial sector, because
of its significant contribution to the bottom line, is looking to reduce the
organization’s total material cost. They are therefore reviewing their purchasing history and systems. The results will then be used to develop procurement plans and to form strategic alliances with key suppliers, creating
a synergistic relationship between purchasing, materials management, and
the product’s supply chain.
CONCLUSION
Performance by the arsenal of the United States was a major reason for
the victory in World War II and the end of the Cold War. The threat of a
world war between superpowers is lower than it has been in over 50 years.
30
ACQUISITION MANAGEMENT
In the last half of the 20th century, the American economy was able to
deliver both guns and butter. Nevertheless, there was a price to pay: a budget deficit, higher taxes, and doubts among the citizenry as to the efficiency of the federal government.
Philip Howard points out that the public’s dissatisfaction with government is not caused by the goals but by government techniques.113 The bureaucracy is subject to conflicting objectives, e.g., satisfying the customer
while at the same time protecting the integrity of the procurement process.114 Over the years procurement laws, regulations, checklists, and continuous oversight have been the way to protect the integrity of the system.
Thousands of pages of law, rules, and regulations have given the appearance that following the process was more important than delivering a
product to the ultimate user on time at a reasonable price. Rules and regulations have eclipsed common sense and individual responsibility, thereby
creating this balance.
In the early 1990s it was clear something needed to be done to make the
federal acquisition system more efficient. Public opinion, the end of the
Cold War, and the move into the Information Age and the changes it will
bring, e.g., electronic data interchange, the Internet, and strategic alliances
with suppliers, provided the motive for the nation’s leadership to seize the
opportunity to make the changes needed. As Alexis de Tocqueville observed, a democratic form of government “often unintentionally works
against itself; but its aim is more beneficial [than the aristocracy’s] . . . for
all its faults, [a democratic government] is the best suited of all to make
society prosper.” Being able to adjust past law and policies is “the great
privilege of the Americans.”115
David N. Burt’s 1984 book Proactive Procurement focuses on the importance of procurement in containing cost, improving quality, increasing
productivity, shortening concept to delivery times, and integrating materials management through the use of modern technologies. Burt, collaborating with Michael Doyle on American Keiretsu (1993), addresses the need for
strategic relationships among buyers and suppliers and the fact that the
supply chain is a competitive weapon.116 Although their ideas are directed
toward the private sector, the business practices of the commercial sector
are also models for acquisition reform.
Reinventing government and streamlining federal acquisition were the
methods selected to renovate the process. A customer-oriented goal for the
federal acquisition system has been stipulated as doctrine for all to follow.
Standards of performance have also been articulated that provide a framework to measure compliance and a set of continuous improvement targets.
However, it would be remiss to leave the reader with the impression that
government procurement will become the mirror image of the commercial
market. The fundamental objectives of the federal acquisition process also
include the need to be fair and maintain the public trust while at the same
Reform of the Federal Acquisition System
31
time fostering social and economic programs. These objectives must also
be viewed with the understanding that federal contractors must comply
with the Cost Accounting Standards as well as furnish the buyer cost or
pricing data in absence of adequate competition. Therefore, the two markets will never be totally integrated.
In a paper titled The Road Ahead, the Under Secretary of Defense J.S.
Gansler outlines a course the Department of Defense must follow to build
on the past achievements of acquisition and logistics reform. The initial
implementing action is “increased reliance on an integrated civil-military
industrial base in lieu of a defense-unique industrial base.” The paper celebrates the successes of the department’s revolution in business affairs and
the forging of a “strong partnership between the Congress, the administration, industry, labor unions, our acquisition community, and our ultimate
customer, the warfighters.” It also establishes the following implementing
actions, which are designed to build on the successes of the past, i.e., “a
more efficient and effective acquisition and logistics environment that will
deliver high-performance weapon systems and support to our warfighters
in less time, and at a lower total cost of ownership”:
• Increase reliance on an integrated civil-military industrial base in lieu
of a defense-unique industrial base
• Extend military specification and standard reform to re-procurements
through the use of performance-based acquisitions to enable logistics
reform
• Provide incentives for suppliers by using acquisition strategies that
give contractors flexibility to innovate and access commercial solutions as a way to reduce acquisition cost and cycle time
• Migrate DoD oversight and buying practices to management of suppliers, not supplies, through establishment of strategic alliance relationships among buying commands and suppliers
• Expand the use of performance-based acquisitions by streamlining
procurements for the services through use of commercial processes,
products, and practices
• Expand the use of price-based acquisition for research and development by shifting significant risk to contractors and having alternatives
available
• Adopt a new approach to systems acquisition in which price and
schedule play a key role in driving design development and systems
are reviewed by portfolio
• Develop a way to look at programs on a portfolio basis, which provides
the flexibility to meet current threats by having viable alternatives to
specific acquisition programs that have common architecture and information exchange requirements that facilitate interoperability with
other programs or legacy systems
32
ACQUISITION MANAGEMENT
• Address the cost in the Operational Requirement Document (ORD) to
determine what a system is worth compared to other capability needs
and their costs
• Implement time-phased requirements and evolutionary acquisition as
a way to reduce acquisition cycle times
• Transform its mass logistics system to a highly agile, reliable system
that delivers logistics on demand
• Implement DoD Logistics Transformation Plans, DoD Logistics Strategy goals, and objectives metrics
• Identify Section 912(c) Pilot Program production support reengineering initiatives
• Assess the feasibility of developing new Product Support Working
Capital Fund business areas to support legacy systems
• Establish logistics system architecture to coordinate integrating and
reengineering business practices and to support information technology systems so that they operate to achieve total supply chain management in a unified manner
• Reduce the DoD acquisition infrastructure and overhead functions
• Continue to implement Service RDT&E infrastructure efficiency initiatives
• Reduce DoD facilities and bases
• Provide the DoD workforce with the requisite skills to operate efficiently in its new environment and perpetuate continuous improvement
• Deliver team training courses for commercial practices and services
• Implement Phase II continuous learning to transition to a learning
organization by improving individual and organizational performance through seeking out and adopting best practices
• Adapt the key facets of the DoD Corporate University to the Defense
Acquisition University to facilitate acquisition reform further.117
With acquisition reform as the backdrop, Chapter Two explains the role
of the integrated acquisition team and relationships within it and shows
how the team can satisfy the user’s needs through increasing reliance on
business judgment in making cost-benefit tradeoffs and focusing its efforts
on the management of risk and opportunities. Subsequent chapters concentrate on the tasks of the integrated acquisition team, using the phases
of the acquisition process as the framework.
NOTES
1Sherman, Stanley N. 1991. Government Procurement Management. Wordcrafters:
Germantown, MD, 21. Stanley points out that the adoption of the word acquisition
Reform of the Federal Acquisition System
33
instead of procurement indicates a tendency in government to invent terminologies
that relate to similar or overlapping activities to reflect attitudes and approaches of
individuals, groups, or agencies.
2Nash, Ralph C., Steven L. Schooner, and Karen R. O’Brien. 1998. The Government
Contracts Reference Book: A Comprehensive Guide to the Language of Procurement. 2d ed.
Washington, D.C.: The George Washington University, 408.
3FAR 2.101.
4Federal Procurement Data System, Total Federal Snapshot Report. Actions Reported
Individually on SF279, Fiscal Year 1999 through Fourth Quarter, as of January 15, 2000.
5Federal Procurement Data System, Federal Contract Actions and Dollars by Executive Department and Agency. Actions reported individually on SF279, Fiscal Year 1999
through Fourth Quarter, as of January 15, 2000.
6Fox, J. Ronald. 1974. Arming of America: How the U.S. Buys Weapons. Boston:
Harvard University, 37.
7Fox, 26.
8Mcfarlan, Gregor. 2000. The Buyer as a Business Manager? Contract Management
(August): 28.
9“Total Federal Snapshot Report.” SF 279 and SF 281 Federal Procurement Report,
Fiscal Year 1990.
10Fox, 256.
11Sherman, 257.
12Sherman, 278.
13The Uniform Commercial Code is a U.S. model law developed to standardize commercial contracting law among the states.
14Sherman, 107.
15Alston, Frank, Franklin Johnson, Margaret Worthington, Louis Goldsmith, and
Frank DeVito. 1984. Contracting with the Federal Government. New York: John Wiley
and Sons, 9.
16Sherman, 12.
17Fireside Chat radio broadcast, December 29, 1940.
18For our purposes, public opinion is a combination of citizen beliefs, statements by
the nation’s intellectuals, and commentaries from the news media.
19Air Force Association. 1999. Air Force Magazine. (May): 58.
20Sherman, 20.
21Sherman, 21.
22Sherman, 14.
23Sherman , 8.
24Sourwine, Darrel. 1992. Contracting—Law+Accounting. Contract Management
(May): 10.
2510 U.S. Code 2304.
26Galimore, Carl R. 1982. Accounting for Contracts. Chelsea, Michigan: Bookcrafters,
272.
34
27
28
ACQUISITION MANAGEMENT
Gallimore, 280.
Gallimore, 280.
Many point out that it is unrealistic to compare a purchase by the federal government to a similar one in the private sector. This is because the executive and legislative
branches implement social and economic programs and establish accounting practices/standards through legislation and because in many cases the federal market is a
monopsony.
30Sherman, 117.
31Sherman, 361.
32Sherman, 6.
33Blue Ribbon Commission on Defense Management, Final Report to the President.
1986. A Quest for Excellence. Washington D.C. June, xv.
34The Center for Strategic and International Studies. 1983. The CSIS Acquisition
Study. U.S. Defense Acquisition: A Process in Trouble. Washington D.C.: Georgetown
University. March: 3.
35Cibinic, John Jr., and Ralph C. Nash, Jr. 1986. Administration of Government Contracts. 2d ed. Washington, D.C.: The George Washington University, 14.
36G.L. Christian and Associates v. United States, 160 Ct.Cl.1, 312,F.2d 418,160 Ct.
902.
37Wyatt, John B. III. 1993. The Christian Doctrine: Born Again But Sinfully Confusing.
Contract Management. (November): 25.
38Howard, Phillip K. 1994. The Death of Common Sense. New York: Warner Books, 11.
39Wilson, James Q. 1989. Bureaucracy: What Government Agencies Do and Why They
Do It. Basic Books, 128.
40James A. The Sinews of War: Army Logistics 17751953 Army Historical Series Office
of the Chief of History United States Army, Washington D.C.
41Blue Ribbon Commission, 77.
42Blue Ribbon Commission, 77.
43Goodwin, Jacob. 1985. Brotherhood of Arms: General Dynamics and the Business of
Defending America. New York: Times Books, 49.
44Lamm, David V. 1988. Why Firms Refuse DOD Business: An Analysis or Rationale.
National Contract Management Journal Winter, 54.
45 Gore, Albert, Jr. 1997. Introduction. Blair House Papers. Washington, D.C.
(www.whitehouse.gov/WH/html/Blair_VP.html)
46Gore, Albert, Jr. 1993. From Red Tape to Results: Creating a Government That Works
Better and Costs Less. Report of the National Performance Review, 26–31.
47Lumer, Mark and Donna Ireton. 1994. Acquisition Reform under the Federal Acquisition Streamlining Act of 1994, Vol. 2, Synopsis and Implications. NCMA, i.
48Public Law 93-400, 1976.
49Kelman, Steve. 1990. Procurement and Public Management. Washington, D.C., 1.
50 Welsh, Bill. 1997. A Look Back at Acquisition Reform with Steve Kelman. Contract
Management (November): 42.
29
Reform of the Federal Acquisition System
35
Kelman, Steve and Susan Alesi. 1995. Guiding Principles for the Federal Acquisition
System. Contract Management. (March): 28.
52Preston, Colleen A. 1997. Colleen Preston on Acquisition Reform. Program Manager
(January-February): 26.
53FAR 1.102, Statement of guiding principles for the Federal Acquisition System.
54FAR 1.102-2 (a) (1).
55Rider, Melissa, Kenneth D. Brody, David B. Dempsey, and Bernard L. Weiss. 1997.
Understanding The FAR Part 15 Rewrite. Vienna, VA: National Contract Management
Association, 19.
56FAR 1.102 (c) (1).
57DoDI 5002.2, 2001. Enclosure 2.
58FAR 1.102 (d).
59FAR 1.102-4 (b).
60FAR 1.102-4 (a).
61Nash, Ralph C., Jr. 1997. Training the Contracting Officer of the Future. Contract
Management, (March): 16.
62FAR 1.102 (e).
63FAR 1.102(d).
64DoD 5000.2R. 2001. Part 7, paragraph 7.6.4.
65The terms intranet and extranet are defined as “a private internal network that operates within a company and is usually insulated from the outside world via an electronic or hardware impedance called a firewall” and “a close relative of an intranet, the
difference being that both specified trading partners and remote company offices not
confined to the corporate location can securely access it via the Internet,” respectively.
Shaw, Jack. 1999. Surviving the Digital Jungle: What Every Executive Needs to Know about
eCommerce and eBusiness. Marietta, GA: Electronic Commerce Strategies, Inc., 104.
66FAR 15.304 b(3) (i).
67Walton, Mary. 1986. The Deming Management Method. New York: The Putnam
Publishing Group, 35.
68A commercial non-developmental item is defined as one being customarily used
for governmental needs that was: (1) developed with private funds and (b) sold on a
competitive basis (FAR 2-101).
69DoDD 5000. 2000. Paragraph 4.2.3.
70Rumbaugh, Margaret G. 1997. Conducting Market Research. National Contract
Management Association Workshop Series. Vienna, VA: National Contract Management
Association, 3.
71Duffy, Roberta. 1999. Where Are We Headed. Business Briefing: Global Purchasing
and Supply Chain Management. World Market Research Center, Proceedings of the
11th World Congress of International Federation of Purchasing and Materials Management, 17–19 November, Milton Qld, Australia, 102–107.
72FAR 6.003.
73Armed Services Pricing Manual. 1986. Chicago: Commerce Clearing House, Inc., 2–5.
51
36
74
75
ACQUISITION MANAGEMENT
Fox, 256.
Sherman, 123.
Delane, John. 1997. A Contractor’s Perspective on Procurement Reform. Contract
Management. (September): 43.
77Walton, Mary. 1986. The Deming Management Method. New York: The Putnam
Publishing Group, 62.
78Walton, 35.
79Menker, Janice M. 1992. Best Value Contracting: Debunking the Myth. Program
Manager, (September): 16.
80Wilson, James Q. 1989. Bureaucracy: What Government Agencies Do and WhyThey
Do It. New York: Harper Collins, 326.
81Wilson, 317.
82Preston, 29.
83FAR 1.102-4 (e).
84Dobler, Donald W. and David N. Burt. 1996. Purchasing and Supply Management
6th ed. New York: McGraw-Hill Companies, Inc., 11–15.
85Wilson, 324.
86Kaminski, Paul G., Under Secretary of Defense for Acquisition. Interview by Dr. J.
Ronald Fox. 1997. Program Manager, Special Edition. (January-February): 4.
87Hamilton, Alexander. 1961. The Federalist Papers, Number 84. New York: Penguin,
514.
88FAR 1.102-2 (c) (1).
89Dayton, Charlotte A., and Jean-Anne Erickson. 1999. Insights. Oversight: Can the
Government Make the Change from Task-Based to Performance-Based Contracting?
Contract Management (October): 48.
90FAR 1.102-2 (c) (2).
91Gammer, Art. 1997. Risk Management: Moving Beyond the Process. Computer
(May): 38.
92 DoDI 5000.2, Operation of the Defense Acquisition System. Paragraph
4.7.3.2.3.4.1.
93Stevens, Michael R. 1997. Addressing Risk Management in Non-Developmental
Items Acquisition Programs. Acquisition Review Quarterly (Winter): 41.
94Gammer, 38.
95FAR 1.102 (b) (1) (i).
96FAR 1.102-2 (a) (3).
97Sherman, 347.
98FAR 1.102-2 (d).
99Naisbitt, John. 1984. Megatrends: Ten New Directions Transforming Our Lives. New
York: Warner Books Inc., 2.
100Drucker, Peter F. 1990. The New Realities. New York: Harper & Row, 48.
76
Reform of the Federal Acquisition System
37
Drake, Daniel. Procurement Manager’s Guide to EC/EDI. Vienna, VA: Holbrook &
Kellogg, 2–18.
102Drake, 2–3.
103Drake, 2–15.
104Drake, 2–13.
105Naisbitt, 15.
106Drake, 2–12.
107Drake, 2–14.
108Public Law 106-229.
109Drucker, 255.
110Bowersox, Donald J., and David J. Gross. 1996. Logistics Management: The Integrated Supply Chain Process. New York: McGraw-Hill Companies, Inc., 75.
111Gebauer, Judith, Carrie Beam, and Arie Segev. 1998. Impact of the Internet on
Procurement. Acquisition Review 5(2): 167.
112Burt, David N., and Richard L. Pinkerton. 1996. A Purchasing Manager’s Guide to
Strategic Proactive Procurement. New York: American Management Association, 2.
113Howard, 173.
114Wilson, 127.
115 de Tocqueville, Alexis. 1988. Democracy in America. Translated by George
Lawrence, edited by J.P. Mayer. Harper & Row Publishers, Inc., 232.
116Burt and Pinkerton, ix.
117Gansler, J.S., Under Secretary of Defense. 2000. The Road Ahead. Washington,
D.C. June 2, 2000.
101
CHAPTER
2
Introduction to the
Federal Acquisition Process
To provide a backdrop for further discussion on the integrated acquisition team, its role, responsibilities, structure, and relationships among
team members, this chapter provides an overview of the federal acquisition
process. It concludes with a presentation on the management of risk and
opportunities (MR&O) technique, which focuses on the acquisition’s objectives and is a way by which possible variances can be managed
proactively to ensure that the risk of not achieving the objectives is mitigated and the window of opportunity to exceed expectations is not missed.
Peter Drucker suggests that we are now in transition from the traditional
command-and-control organizational relationship to one based on the
flow of information among bodies of knowledge. Drucker describes the
information-based organization as a group of specialists linked to each
other in a network but functioning as independent agents for their specialty. These specialists actively interact with customers and suppliers using the Internet and extranet in a computer-to-computer exchange of data.
Organizationally, this interaction occurs horizontally rather than vertically and crosses functional and institutional boundaries. Distance, which
once inhibited real-time communications, is almost no longer a concern.
Organizations are becoming flatter, with fewer layers of management.
Drucker also predicts that operations of large businesses will more likely
resemble those of hospitals or orchestras than of typical manufacturing
companies.1
Traditionally, contracting has been viewed as an exclusive relationship
between a buyer and a seller, each concentrating on getting what they
want from the other. This perception goes back to the era when the seller
had the expertise and was able to perform a majority of the work using its
own organic capabilities. However, as the technological content and complexity of products increased, dependence on outside specialists and sub-
40
ACQUISITION MANAGEMENT
contractors also grew because their special knowledge and capabilities were
crucial to satisfying contractual requirements. Today, at least 60% of a
product or service’s cost is in the form of purchased supplies, equipment,
material, and services. On average, 50% of a firm’s quality problems can be
traced to purchased materials.2
The postulate of acquisition doctrine is that control over cost and quality
of goods and services purchased can be achieved more effectively when
functional specialists in the buyer and seller’s organizations operate as part
of an interdependent and integrated system. The contracting officer (CO)
as a business manager plays a leading role in this relationship. No longer
can the COs act as if their primary role is to enforce the acquisition rules
and regulations and when others get involved, view them with apprehension. It has been said, “Years of dictated regulated solutions have bred a contracting culture that avoids risk, that tends not to think creatively when devising solutions, and that has gained a reputation in many quarters for being
toads in the road.”3 One of the goals of this book is to help eradicate this
reputation. The prescription is to follow the acquisition principles, eliminating the adversary relationships through team building, managing risk and
opportunities, and taking advantage of the communication capabilities afforded by technological advances in telecommunications.
THE ACQUISITION PROCESS
In this book the basic framework, or model, for obtaining supplies and
services by the federal government will be referred to as the acquisition
process. Acquisition must not be thought of as a function but rather as a
process that links customer needs to customer satisfaction.4 This process
should be viewed as a series of steps and activities for converting specific
inputs into specific outputs.5 It includes determination of requirements,
acquisition planning, preparation of the solicitation, source selection, negotiation, and contract award, performance, and closeout. The first step in
managing the acquisition process is to identify the stakeholders. Stakeholders in an acquisition include the ultimate user, program managers,
contracting officers, functional managers, engineers, manufacturers, marketing personnel, suppliers, stockholders, subcontractors, vendors, financial institutions, and taxpayers. Success in managing the stakeholder relationship can be measured using these critical success factors:
•
•
•
•
•
•
•
Client acceptance
Client consultation
Top management support
Acquisition plans and schedules
Monitoring of feedback
Communication
Troubleshooting.6
Introduction to the Federal Acquisition Process
41
The term acquisition is defined in the FAR at 2.101 as “acquiring by contract with appropriated funds of supplies or services (including construction) by or for the use of the Federal Government through purchase or
lease, whether the supplies or services are already in existence or must be
created, developed, demonstrated, and evaluated. The acquisition process
begins at the point when the agency needs are established and includes the
description of requirements to satisfy agency needs, solicitation and selection of sources, award of contract, contract financing, contract performance, contract administration, and those technical and management
functions directly related to the process of fulfilling agency needs by contract.”7 In this book the process of fulfilling an agency’s needs will be referred to as the acquisition process. DoD directives in the Defense Acquisition System, the 5000 series, also refer to the new acquisition process. In
the DoD context, the acquisition process has traditionally been an acquisition management process structured in logical phases by major decision
points called milestones, beginning with broadly stated mission needs that
cannot be satisfied by nonmaterial solutions.8
The federal acquisition process consists of a network of tasks and activities associated with a sequence of discrete events designed to produce the
timely delivery of the needed product to the customer. Figure 2-1 depicts
this process, illustrating major events associated with the procurement of
goods and services.
The requirements determination phase: All requirements begin with a determination of need. Government needs fall into one of four general categories: (1) a need to establish a new operational capability, (2) a need to improve an existing capability, (3) a need to exploit an opportunity to reduce
cost or enhance performance, and (4) a need to preserve a current capability through maintaining or replenishing inventory. Included in this phase
REQUIREMENTS
DETERMINATION
ACQUISITION
PLANNING
THE
SOLICITATION
SOURCE
SELECTION
NEGOTIATION
CONTRACT
AWARD
CONTRACT
PERFORMANCE
CONTRACT
CLOSEOUT
Figure 2-1 The Acquisition Process Model
42
ACQUISITION MANAGEMENT
are requirements forecasting, market research, development of initial acquisition strategy (external or internal source), and quantification of the
funding requirement.
Acquisition planning: During this phase the acquisition cadre is formed,
the user initiates the purchase request, market characteristics and industry
practices are determined, and perceived needs are developed into more
detailed statements of requirements. Specifications and statements of
work, identification of sources, designation of the method of procurement,
refinement of the procurement strategy, definition of evaluation criteria,
and completion of procurement plans are examples of requirement documents. Initial tradeoffs are made and steps are taken to identify the cost,
schedule, performance, and supportability risks, and assess their possible
impact.
The solicitation: The solicitation phase includes all tasks and activities
needed to refine the specifications, statement of work, and evaluation criteria into the proposal document or the request for bid, if the sealed bidding process is to be followed. Part of this task is determining the appropriate pricing arrangement; identifying government-furnished property
needs, bonding requirements, and data needs; placing the appropriate requirements documents on the Internet; and announcing the business opportunity in the Commerce Business Daily. The pre-bid/proposal conference
is held at this time, and amendments to the request for bid or proposal are
also made during this phase.
Source selection: For negotiated procurements the integrated acquisition
team evaluates potential contractors’ proposals for technical content and
cost analysis using the evaluation criteria defined in the solicitation. The
team assesses the past performance records of prospective contractors,
completes tradeoffs, and makes the competitive range decision. It then
undertakes discussions with sources within the competitive range and
makes the best value tradeoff determination. The team then finalizes the
negotiation strategy and plan. If a sealed bid is involved, the team receives
and administers the responses.
Negotiations: Negotiation is not an event but a process. There is a need to
gather data and to prepare a negotiation plan before actual face-to-face
bargaining. Therefore, negotiation planning overlaps previous steps in the
acquisition process. In this phase the bargaining segment of negotiations is
conducted. Agreement is reached, and appropriate changes are made to the
draft contract (solicitation) to ensure that it conforms to the negotiated
agreement and can be used as the contractual document.
Contract award: The parties execute the conforming contract, which represents common language for the integrated acquisition team and the
foundation for managing risks and opportunities.
Contract performance: At this point a post-award conference is held, and
the integrated acquisition team transitions to performing tasks and activities that focus on contract performance, such as risk and opportunity
Introduction to the Federal Acquisition Process
43
(MR&O) variance analysis. Consent to subcontract is approved as required.
Contracting officers implement change management procedures. Delivery
schedules are monitored and action taken in the event of a variance. Quality assurance activity begins, and deliverables are tested, inspected, and
accepted.
Contract closeout: Payments are processed and obligations discharged. In
the event the contract is terminated for default or for convenience of the
government, the tasks and activities necessary to settle all outstanding
contractual issues and obligations are performed as part of this phase of the
acquisition process.
THE INTEGRATED ACQUISITION TEAM
Today the probability of a successful acquisition is increased through the
use of an integrated acquisition team. Members of the acquisition team are
multi-organizational as well as cross-functional. This means that the ultimate user, contractors, suppliers, and the acquisition professional are organized into an acquisition team. The original skunk works, established by
Kelly Johnson at Lockheed, was so organized.
The integrated acquisition team is an information-based organization
that is composed of more specialists than in the traditional command-andcontrol organization. It is held together by the flow of information among
the specialists in government and industry, regardless of organizational
boundaries. Electronic data interchange (EDI) is greatly facilitating the exchange of project-related technical information among all members of the
integrated acquisition team, regardless of their location.
Acquisition doctrine advocates including the customer as an active
member of the integrated acquisition team. In addition, the prime contractor and major critical subcontractors contribute to the efforts of the team.
This organizational relationship ensures that both the user and the supplier participate in tradeoffs among cost, schedule, performance, and supportability decisions as they are made. The characteristics of the product
and method of procurement determine the tasks and activities performed
by the integrated acquisition team because different products and contracting methods require diverse bodies of knowledge to procure the goods
or services effectively. Therefore, tasks performed by the team vary from
acquisition to acquisition.
Figure 2-1, The Acquisition Process Model, shows the events in the process occurring sequentially. A common electronic database often makes it
possible to overlap events. Sharing a common database permits members
of the team to work concurrently from the beginning to the end of the
project, regardless of their physical location. The net result is real-time
communication among team members, a reduction of rework, and a decrease in the amount of administrative lead time.
44
ACQUISITION MANAGEMENT
This integrated approach to acquisition management is not entirely
new, having evolved from the program management9 concept used by
DoD in the 1950s. Program management developed because traditional
organizational relationships were ponderous, geared to performing repetitive routine tasks, and slow to take action because of their functional focus.
The goal of the project management concept was to achieve defined objectives by concentrating resources, e.g., specialists, funds, and equipment, in
a group established to perform non-routine tasks.
By definition, a program or project has the following attributes:
•
•
•
•
•
•
•
•
•
•
•
A boundary separating work on the product from routine work
Non-routine multifunctional tasks
A fixed beginning and scheduled completion dates
An organizational structure tailored to the characteristics of the product
Representation from all appropriate disciplines
A high degree of interdependency between tasks and functions
A need to coordinate and communicate directly and frequently with
other members of the project
A membership with the authority, responsibility, and accountability
for decisions
A commitment to mutual goals and a process for resolving differences
A management information system containing cost, schedule, and
performance data
A control process that compares current status with the planned
position.
Some integrated acquisition teams have failed to realize their potential
because they: (1) lack senior management support, (2) have poorly defined
goals, or (3) let personnel conflicts develop among functional specialists.
Specialists often try to maximize one functional approach over another
while trying to minimize their responsibility and accountability for attaining the overall objectives of the acquisition. This practice easily produces
instability within the integrated acquisition team.10 One of the most important tasks of the leaders in the integrated acquisition team is to set goals
and establish accountability so that the members of the team can maintain
an acceptable balance between areas where they have the authority to
make decisions and their responsibility to achieve the objectives of the
project.
The Program Manager/Project Manager
Although there are differences in the skills and training of a program
manager and those of a project manager, in practice the two terms are
often used interchangeably. The Government Contracts Reference Book de-
Introduction to the Federal Acquisition Process
45
scribes the program manager (PM) as an individual who manages a system
acquisition (typically a major system acquisition) program and whose tasks
include developing acquisition strategies, promoting full and open competition, and sustaining effective competition between alternative major
weapon system concepts and sources, as long as it is economically beneficial and practical to do so. In the DoD the program manager reports directly to the program executive officer on all program matters.11 The Government Contracts Reference Book also defines the position of project
manager as the official responsible for planning and controlling assigned
projects to achieve program goals. Typical duties of the program manager
that are related to the government acquisition process include establishing
program objectives; developing requirements, including purchase requests
containing specifications and statements of work; obtaining required approvals; scheduling, estimating, budgeting, and controlling projects; coordinating project planning with the contracting officer; and functioning as
the contracting officer’s representative or technical representative.12 In this
book, the term PM also refers to a project manager.
The PM’s role is not to perform the work individually but to accomplish
project objectives through specialists working in a group or, better yet, a
team situation. “As part of this process PMs must become intimate with all
project stakeholders (internal and external) in an effort to understand the
drivers behind the customer needs and the organizational challenges that
the project will help to resolve.”13 The PM needs a broad perspective on
how to lead in an event-oriented environment, i.e., balancing functional
objectives with overall project needs and milestones. To accomplish this,
the PM must develop a team structure for the project as well as a sense of
project identification. A typical duty of the PM is to translate the project’s
strategic objectives into achievable goals for the project.14 The PM is essentially a manager of information and risk.
The PM is in charge of the program. However, the PM often has been
described as having responsibility for the program but limited authority
over the multifunctional and multi-organizational resources assigned to
his or her integrated acquisition team. The imbalance between responsibility and authority means that the PM must accomplish things through negotiating with upper-level management and those functional managers
who supervise technical specialists. Integrated acquisition teams can take
on the characteristics of transient organizations because specialists become
involved in the acquisition for relatively short periods at various times during the acquisition process. This means that the PM does not have direct
authority over the personnel resources assigned to the project. It also
means that the PM and other members of the integrated acquisition team,
who have a collective responsibility to get the job done, are also vulnerable
to decisions made by managers located outside the team. In their book, The
Manager as Negotiator: Bargaining for Cooperation and Competitive Gain,
46
ACQUISITION MANAGEMENT
David A. Lax and James K. Sebenius refer to this situation as “indirect management” and state that it is faced by most PMs.15 In this situation the
project manager requires cooperation from members of the team, who,
even when working directly for the project leader, are dependent on the
function for resources, backing, and even a “good job” when the project is
completed. The authors conclude that this circumstance calls for a management approach very different from the traditional “I say, you do”
method. Consequently, a significant part of the PM’s job is to create and
maintain a series of agreements concerning the objectives and utilization
of resources on the project. With “shared authority and resources but concentrated responsibility...effective negotiation with the other shareholders
is often the key to success.”16 Figure 2-2, The PM As an Indirect Manager,
illustrates the environment in which the PM functions.
The success of every project requires collaboration of separate bodies of
knowledge, each having its own perceptions and objectives. Each profession (technical specialists) tends to regard itself as elite, with special values
that may get in the way of cross-disciplinary sharing.17 This can easily lead
to conflict, thereby breaking down the process. The PM’s task is to discipline the acquisition process and establish a climate and a communication
protocol that will ensure that the entire integrated acquisition team works
together.
Primary skills to consider when looking for a PM include good communication, negotiating, and interpersonal skills. General technical and contractual knowledge are additional requirements of the job. As noted above,
the role of the PM is to build a positive collaborative relationship among
technical specialists on the integrated acquisition team. With today’s
highly specialized work forces and the inclusion of the user and contractor
on the integrated acquisition team, people involved in the project are often separated by distance and travel time.
Communication is the process by which information of the project is
exchanged and can be formal or informal, in written or oral form. Timely
communication is vital to the success of the project. The exchange of information among members of the integrated acquisition team using EDI is
not only an effective way to communicate, but it also allows all addressees
to share their knowledge with other specialists quickly and concurrently.
When projects are complex or are not well defined, no one person, function, or organization may know what the full depth or range is or where
the key issues reside. To take advantage of the broad technical knowledge
that resides with all members of the team, an EDI protocol bringing members quickly together to focus and solve a single problem is a powerful
management tool. Figure 2-3 shows how planning information, project
status, and problem solving can be facilitated through what has been described as a “spider web” communications network.18
Introduction to the Federal Acquisition Process
47
TOP
MANAGEMENT
Strategic
Leadership
FUNCTIONAL
MANAGER
FUNCTIONAL
MANAGER
Resources
Policy
Resources
Policy
FUNCTIONAL
SPECIALIST
FUNCTIONAL
SPECIALIST
Project Direction
Technical Input
ULTIMATE
USER
Authority
Responsibility
Project Direction
Technical Input
Requirements
Performance
Standard
FUNCTIONAL
MANAGER
FUNCTIONAL
MANAGER
Resources
Policy
Resources
Policy
FUNCTIONAL
SPECIALIST
FUNCTIONAL
SPECIALIST
Project Direction
Technical Input
Project Direction
Technical Input
PROJECT
MANAGER
Figure 2-2 The PM As an Indirect Manager
To gain a sense of ownership, members of the team must also develop
project objectives. This is most often accomplished by developing “microgoals,” which are evaluated and integrated into the overall project goal.
Team participation gives members a sense of ownership and commitment
to the common purpose as well as the plan on how the teams will get there.
The members should also be evaluated on how well they participate in the
team process by cooperating and sharing their knowledge.
The Contracting Officer
The Government Contracts Reference Book describes a contracting officer
(CO) as an employee of the government with the authority to bind the
government legally by signing a contract.19 The CO is the person with the
authority to enter into, administer, and terminate contracts, and to make
determinations and findings.20 The CO’s role is to secure supplies and services from sources outside the organization. COs are also responsible for
STATEMENT OF
REQUIREMENTS
FUNDING PROFILE
TIMING & QUANTITIES
REQUEST FOR PROPOSAL
ENGINEERING
AND
TESTING
STATEMENT OF
REQUIREMENTS
ITEM DESCRIPTIONS
PROJECT
MANAGEMENT
PLAN
DESCRIPTION OF
CONFIGURATION
QUALITY STANDARDS
REQUIREMENTS
CONFIGURATION
& STANDARDS
PRODUCTION PLANS
QUALITY
AND
MANUFACTURING
Figure 2-3 Communications Protocol for the Integrated Acquisition Team
CONTRACTORS
DRAFT RFPs
DISCUSSIONS
PROJECT
MANAGEMENT
& CONTRACTING
FORECASTS
AND
FUNDING
PROFILES
FEEDBACK
AUTHORITY
RESPONSIBILITY
FUNDING PROFILES
FEEDBACK
STATEMENT
OF NEED
ULTIMATE
USER
TOP
MANAGEMENT
48
ACQUISITION MANAGEMENT
Introduction to the Federal Acquisition Process
49
ensuring performance of all necessary actions, employing effective contracting practices, complying with the terms of the contract, and safeguarding the interests of the United States in its contractual relationships.21 In accomplishing this mission, the CO must understand the
customer and its needs and maintain a good relationship with the crossfunctional integrated acquisition team and the commercial contractors.
There are four categories of CO, each having different tasks and responsibilities. The purchasing or procuring contracting officer (PCO) has authority to enter into a contract; the administrative contracting officer (ACO)
strictly administers the performance of a contract; the termination contracting officer (TCO) is responsible for contract termination; and the corporate administrative contracting officer (CACO) performs selected contract administration functions on a corporate-wide basis.22 The
relationships between the PCO and ACO, as defined in Part 42 of the FAR,
will be discussed in Chapter 7.
One of the most significant differences between the buyer-seller relationship in a government contracting environment and the buyer-seller of
commercial goods is the fact that the government is not bound by unauthorized acts of its employees. Therefore, unless the act is authorized, the
government is not obligated to comply. Consequently, it is difficult for
those outside the government to determine the exact status of government
employees they are dealing with. In this situation case law is clear: “...anyone entering into an arrangement with the Government takes the risk of
having to accurately ascertain that he who purports to act for the Government stays within the bounds of his authority.”23
The CO and CM can no longer consider themselves as independent agents
viewing the integrated acquisition team from the outside. Rather, they are
integral members of the integrated acquisition team. Dr. Ralph C. Nash, Jr.,
founder of the government contracts program at The George Washington
University, feels that the Guiding Acquisition Principles made an important
contribution by recognizing the CO as a member of the integrated acquisition
team. The principles “speak primarily in terms of the integrated acquisition
team,” thus assuming that “the CO will function in the future as a member of
a team and not as the person responsible for the back end of the procurement
process.”24 The contracting profession will require that future contracting professionals be prudent business managers because of how the profession and
the overall work force will change.25 Today the CO must “understand, accept,
and project corporate values, goals, and objectives instead of a more limited
contracting view of the world.”26
The PCO operates as an agent of the federal government whose authority and responsibilities are established by law and agency policies. Most
have the power to execute two-party agreements, within defined limitations. The FAR’s acquisition principles stipulate that the contracting member of the integrated acquisition team “must have the authority to the
50
ACQUISITION MANAGEMENT
maximum extent practicable and consistent with law to determine the applicable rules, regulations, and policies on a specific contract.”27
Acquisition doctrine encourages individual initiative and use of sound
business judgment. Some of the rules that previously constrained CO performance have been removed. Policy now permits government members
of the team to implement a specific strategy, practice, policy, or procedure
that is in the best interest of the government when it is not specifically
prohibited by the FAR, executive orders, and appropriate directives.28 This
policy statement initiative enables government personnel to be more proactive. The CO can add significant value to the overall product by bringing
timely expertise to critical issues.
Professor Ralph Nash considers critical skills for COs in the 21st century
to be: “knowledge or strategy and tactics; market knowledge and research
expertise; and total familiarity with all of the various procurement tools
available to purchase goods and services coupled with the ability to use
them to the customer’s advantage.”29
The PCO is performing in the strategic role during the requirements determination and acquisition planning phases. The PCO makes a critical
contribution during the determination of need phase of the acquisition
process. At this time the PCO provides data on products available in the
commercial market, characteristics of the market, and industry practices.
Some of these data are valuable in developing the acquisition plan and
negotiation plan and strategy. Although the users have final say in the
selection process, it is the PCO who is responsible for providing qualified
candidates. During acquisition planning the PCO is deeply involved in
procurement planning, i.e., evaluating the extent of competition that is
achievable, selecting the contracting method, determining the most appropriate contract type, and defining how risk and opportunities will be
addressed in the solicitation. The PCO’s tactical knowledge is used during
the negotiation and contract award phases. At this time the PCO assumes a
dominant role in source selection, negotiation, contract award, and the
subsequent development of the conforming contract.
With the increase in communication between functions brought on by
the use of electronic data interchange (EDI), the role of the procurement
office is changing from being oriented mainly toward transactions to managing the procurement system. This is a significant change, as the buying
offices had previously limited their role through procurement rules and
regulations.30 The CO must have a systems view. As the federal government re-engineers itself, procurement can now be easily linked with functions such as finance, inventory management, receiving, property management, and payment. It is quickly becoming an integrated system that
cannot be separated. COs must understand these interfaces and functional
relationships so that any changes to procurement procedures are compatible with the overall integrated system.31
Introduction to the Federal Acquisition Process
51
The contract document should be thought of as “common language
across the government/contractor team….” Placing the contract on the
project’s home page, where it is easily accessible to the integrated acquisition team, helps ensure that the document can easily be read and understood. Therefore, it is imperative that the entire contract document not
only record the negotiated agreement so that the intent of the parties is
clear, but it must also facilitate the administration of work, provide an incentive for the contractor to perform, allocate risk, and describe terms of
payment. The conforming contract has taken on even greater importance
than before because with today’s capabilities of EDI and the ability to have
a home page dedicated to a single project, it is now easily accessible to all.
The modern contract, with an Integrated Master Schedule (IMS) and Integrated Master Plan (IMP), provides a plan that can be referenced by the
entire integrated acquisition team. Therefore, its function as a document
that will stand up in a court of law, although still very important, is not the
only reason for its existence.
In addition to defining requirements, the conforming contract is a primary source of information that can be used to determine if there are any
variances from contract baseline.32 The PCO is responsible for managing
contract changes and, therefore, must maintain continuous communication with his or her counterpart in industry as well as other members of the
integrated acquisition team. Contract closeout or termination requires the
contracting officer to orchestrate the final disposition of property,
deliverables, data, and final payments.
An integral part of the integrated acquisition team organization during
all phases is the local area contract administration activity of in-plant government representatives. They can assume part of the administrative
workload and are a valuable conduit for information on contractor performance for the entire integrated acquisition team. To ensure their participation, the PCO must define specifically the supporting administrative functions to be performed by the ACO. The tasks to be performed at the
contractor’s plant by the ACO should be specifically delineated in a delegation agreement between the ACO and PCO. This agreement also should be
coordinated with the PM to ensure that it is consistent with the allocation
of tasks and activities of the team.
In the private sector, quality and reduced time to market have replaced
price as the key to increased market share and profit margins.33 In addition,
in the private sector approximately 70 percent of major U.S. manufacturing firms have adopted a materials management concept that coordinates
all planning, organizing, and controlling activities related to material and
inventory. This action was taken because of the interdependency of such
functions as purchasing, inventory management, production planning,
scheduling, transportation, receiving, materials handling, and warehousing. These functions, which had traditionally been located in different de-
52
ACQUISITION MANAGEMENT
partments, are in reality subsets of what is now called a materials management system. Therefore, functional policies and activities must be coordinated on a macro basis. This is done in one of two ways: (1) establishing a
set of reporting, communicating, and control procedures designed to foster
coordinated decision making; or (2) by arranging the organization to consolidate some of these individual functions in a single organization under
one manager. In many materials management organizations the purchasing process has been complemented by what has been called a procurement function. In industry the procurement function now has a strategic
focus that includes developing material and service requirements, performing market studies, performing make-or-buy analysis, formulating
suppliers’ product and quality standards, and contracting for transportation services.34
What is the future role of the CO? In November 1999 the Contract Management Institute (CMI), the National Contract Management Association
(NCMA), a not-for-profit foundation, published the results of a research
report by PricewaterhouseCoopers LLP titled “Survey of Contracting Professionals—Emerging Demands of a Changing Profession.” Respondents to
the survey were from the public and private sectors as well as professional
associations. The survey found that while many of the best practices bestvalue contracting and managing supplier relationships had not yet been
well established, “...the role of the contracting and purchasing professional
is far less clerical than it was only a short time ago, more strategic and
team-oriented in its contribution to successful outcomes, more specialized
in its requirements for effective competencies and skills, more responsible
for results, and more conscious of the needs to use time as a critical component.” Although “contracting was considered a secondary business-management function that was too process- and rules-oriented...” the respondents also “predicted that the success of contracting and purchasing
officials would be measured by business-management performance metrics
rather than volume of transactions.”35
Other Government Team Members
Acquisition doctrine calls for forming multi-disciplinary teams working
to facilitate the delivery of a specific product or service to the ultimate user.
The integrated acquisition team’s goal is to optimize the product by involving all functional bodies of knowledge through integrated decision
making. Implementing a risk management and opportunities program also
rests with the integrated acquisition team.
One of the project manager’s first duties is to assemble the integrated
acquisition team. While organizing the team, the PM must determine what
bodies of knowledge (specialists) will be required during the life cycle of
the project. Any body of knowledge that will have an effect on the perfor-
Introduction to the Federal Acquisition Process
53
mance and ownership cost of the product must be represented on the
team. Factors such as product characteristics, the probable contracting
method, and the type of contract also must be considered when determining the knowledge and skills needed. Knowledge and skills required by the
team also change as a project progresses through its life cycle. The size of
the team is also a function of what phase of the life cycle the product is in.
Figure 2-4, Bodies of Knowledge Involved in a Project, is a menu of the
bodies of knowledge the PM should consider when building the integrated
acquisition team.
The bodies of knowledge often found on an integrated acquisition team
are contracting, logistics, planning and control, engineering, quality assurance, configuration control, information systems, reliability and maintainability, testing and evaluation, manufacturing and production, property
management, subcontract management, cost estimating, financial, and legal.36 The organization’s functional staff is responsible for supporting the
integrated acquisition team, which includes human resources management aspects, such as technical competency and development. To be effective each team member must have the resources and be empowered to
achieve the project’s objective.
The availability of EDI and the Internet has enabled representatives from
other geographic locations to participate in the collective decision-making
process. An example of communications within the team was illustrated in
Figure 2-3.
Figure 2-5 illustrates three types of integrated acquisition teams and their
interrelationships. (It is based on the DoD model described in Part 7 of
DoD 5000.2R, dated January 4, 2001.) The integrated acquisition team is a
multifunctional organization assembled around the product or service being procured. Members advise the PM. The concept is to manage the acquisition by integrating all acquisition activities, from determining the requirement through its deployment to simultaneously optimizing the
product and its manufacturing and sustaining processes to meet cost,
schedule, performance, and cost-of-ownership objectives. Note that Figure
2-5 lists an Overarching Integrated Acquisition Team. This team provides
assistance, oversight, and review through the acquisition process. The
Overarching Integrated Acquisition team is led by an individual at least
one supervisory level above the PM. It is also responsible for chartering the
Intermediate Integrated Acquisition Team and the Working-Level Integrated Acquisition team. At the lowest level there is a Working-Level Integrated Acquisition Team, whose role is to help the PM plan program structure, document and resolve issues, and develop and administer the MR&O
Handling Plan. The role of the Intermediate Integrated Acquisition Team,
which is formed at the working level, is to coordinate the efforts of the
Working-Level Integrated Acquisition Team and handle issues assigned to
another team. The Intermediate Integrated Acquisition Team and the
SUBCONTRACT
MANAGEMENT
QUALITY
ASSURANCE
PROPERTY
MANAGEMENT
COST
ESTIMATING
FINANCE
RELIABILITY
&
MAINTAINABILITY
THE
ACQUISITION TEAM
CONTRACTING
LEGAL
MANUFACTURING
&
PRODUCTION
LOGISTICS
ENGINEERING
TEST
&
EVALUATION
Figure 2-4 Bodies of Knowledge Involved in a Project
MANAGEMENT
INFORMATION
SYSTEMS
CONFIGURATION
CONTROL
PROJECT
MANAGEMENT
PLANNING &
CONTROL
54
ACQUISITION MANAGEMENT
Introduction to the Federal Acquisition Process
DIRECTION
and
STATUS
REVIEW
55
OVERARCHING
INTEGRATED ACQUISITION TEAM
CUSTOMER
Design
Production
Test
INTERMEDIATE
INTEGRATED
ACQUISITION TEAM
Cost &
Schedule
Logistics
Support
Contracts
PRIME
CONTRACTOR
Test
Design
WORKING-LEVEL
INTEGRATED ACQUISITION TEAM
Production
Cost &
Schedule
EXECUTION,
COORDINATION,
and
REPORTING
Logistics
Support
Contracts
Critical
SubContractor
Critical
SubContractor
Critical
SubContractor
Figure 2-5 The Three Types of Integrated Acquisition Teams
Working-Level Integrated Acquisition Team are normally led by the PM or
representative of the PM. (Because of the size of the acquisition, only the
Working-Level Integrated Acquisition Team will be required to satisfy the
work load.) The customer may also participate in meetings of the
Overarching Integrated Acquisition Team. Industry representatives, including support contractors, provide information, advice, and recommendations to the team, although they are not formal members of a team.
Because of the sensitive nature of discussions, industry representatives do
not participate in deliberations by any integrated acquisition team.
Although the structure of an organization does not guarantee success,
effective communication and coordination are essential among the various bodies of technical knowledge not only within the government’s buying office but between the contractor and critical subcontractors as well.
The integrated team concept represents a departure from the traditional
functional orientation, which is characterized by vertical communication
via the chain of command, often described as resembling a stovepipe. An
integrated product team is built around the product, with both vertical and
horizontal communication.
56
ACQUISITION MANAGEMENT
The ability to coordinate and communicate horizontally is evident in
this organizational chart. The overarching level of the integrated acquisition team includes the PM and the leadership of the government agency as
well as senior representatives from the customer (ultimate user) and participation by the prime contractor. Their role is to provide direction, including funding, and to review the project’s status.
At the working level are the technical specialists associated with the bodies of knowledge in the government’s buying office. This is the original
integrated acquisition team cadre of technical specialists who have been
instrumental in performing market research, working with the customer in
developing the requirements, developing the acquisition plan, finalizing
and issuing the solicitation, evaluating proposals, and making the contract
award. After contract award this group is retained to manage the project
and the risks and opportunities associated with meeting the acquisition
objectives.
Participants in the contractor segment of the working level are the same as
the government’s. Critical subcontractors are also included so that information on their product, production, and product support requirements can be
shared with the integrated acquisition team on a real-time basis. The contractor and critical subcontractors are also responsible for participating in managing the risks and opportunities associated with the acquisition.
A study by RAND of risk management in the Air Force’s F-22 Engineering
and Manufacturing Development Program noted that the acquisition team
cited the lack of understanding of the requirement as one of the three basic
causes of risk.37 Participation by the customer as a member of the integrated acquisition team is one way of managing the risk of not understanding the customer’s desires. Including the customer on the integrated acquisition team from the beginning greatly facilitates communication and
coordination. An example of this can be found in the Ford Motor Company, which in 1979 consulted with customers, including a car-rental company, a women’s committee, and other consumers, when designing the
Taurus automobile. This was done rather than relying on the engineers
and manufacturers to anticipate the customers’ needs as they had done in
the past.38 The net result was a design that focused on the customer and a
car that turned around the fortunes of the Ford Motor Car Company.
The Contractor As Member of the Integrated Acquisition Team
Historically the relationship between the buyer and seller in this country
has been more adversarial than fraternal. Suppliers were played off against
each other and squeezed for lower prices.39 There has since been a growing
realization that the needs of the customer must be integrated into the
manufacturer’s design and production process as early in the acquisition as
possible. Therefore, including the contractor as a participant in meetings
Introduction to the Federal Acquisition Process
57
of the integrated acquisition team is an attempt to realize the advantages of
a positive buyer-seller relationship. Dr. Deming said: “Purchasing should
be a team effort, and one of the most important people on the team should
be the chosen supplier.”40
Industry also has recognized that to meet the competitive demands of
today, the procurement effort must be proactive rather than reactive.
Commercial firms are focusing attention on increasing productivity,
shortening delivery times, and integrating materials management into the
total operations of the organization. The heart of this concept is the crossfunctional procurement team as part of the Integrated Procurement System (IPS). This team includes representatives of design engineering, manufacturing engineering, purchasing, manufacturing, and quality control, as
well as key suppliers.41 Suppliers work as members of the team under a
strategic alliance, long-term contract, or blanket purchase order.
In large or complex programs, contractor participation as members of
the acquisition team should also involve the key suppliers. Earlier in this
chapter it was noted that, on average, contractors contract over 60 percent
of the goods and service content of a product. This percentage can go even
higher as the technical content of products increases and outsourcing is
seen as a way to cut costs and accelerate development time. Long-term
strategic alliances are being formed, and firms are becoming more interdependent. This means they are learning to share information to make product and product decisions jointly. Ravi Vankatesan is quoted as saying,
“Today manufacturing focus means learning not to make things—how not
to make the parts that divert a company from cultivating its skills—parts
its suppliers could make more efficiently.”42
DoD Implementation of the Integrated Acquisition Team Concept
“I am directing a fundamental change” were the words used by thenSecretary of Defense William Perry on May 10, 1995, when he endorsed the
implementation of integrated product and process development (IPPD)
through the use of integrated product teams (IPTs).43
IPPD is described as “a management process that integrates all activities
from product conception through production and support, using a multifunctional team, to simultaneously optimize the product and its manufacturing and sustaining process to meet cost, schedule, and performance objectives.44
Figure 2-6, The Generic IPPD Iterative Process, shows the IPPD as an
open process, i.e., it is influenced by factors outside its environment. These
factors include annual funding, changes in political priorities, oversight,
policy of regulatory agencies, suppliers, changes to the threat, and competitive products. The IPPD process recognizes the comprehensive requirement to modify and align team structures, analytical and decision tools,
58
ACQUISITION MANAGEMENT
DISCIPLINED
APPROACH
REQUIREMENTS
Tools
Teams
PRODUCT
& ASSOC.
PROCESSES
Development
Processes
CUSTOMERS
Figure 2-6 The Generic IPPD Iterative Process45
and process to achieve optimal performance as defined by the customers’
criteria.
The IPPD model represents a disciplined approach used to organize activities, scope out issues, identify and manage risk, and pursue opportunities. Requirements are initiated based on input from the ultimate customer
and are refined through market research. The iterative process enables the
integrated team to focus on several product issues simultaneously. Tools available to the team include documentation, data systems, and methodologies
that enable cross-functional experts to share and integrate information and
make decisions at the lowest level commensurate with the magnitude of the
issue involved. As noted earlier, teams are made up of the stakeholders, who
are empowered to make decisions in their areas of expertise. Output is the
product that measures the success of the integrated team.
This IPPD concept means that the IPT can optimize the cost, schedule,
performance, and supportability objective of the acquisition. The IPPD requires bodies of knowledge represented by members of the multifunctional team, who can interact simultaneously. The integrated team can
also receive input from the outside environment. The IPPD/IPT management framework remains functional for the entire life cycle of the product
or service.46
DoD guidance states that the chain of command includes the program
manager, program executive officer, Component Acquisition Executive
(CAE) reporting through the Head of the Component, and Under Secretary
of Defense for Acquisition, Technology, and Logistics (USD AT&L) or Assistant Secretary of Defense for Command, Control, Communications, and
Introduction to the Federal Acquisition Process
59
Intelligence (ASD C&I). However, to streamline the process, no more than
two levels of review are to exist between the program manager and the
Milestone Decision Authority.47
The Milestone Decision Authority shown in Figure 2-7 is an individual
designated in accordance with the criteria established by the USD AT&L of
ASD C&I to approve entry of an acquisition program into the next phase of
the acquisition process.48
DoD 5000.2-R establishes the following basic tenets for the workinglevel IPT (WIPT):
• The PM is in charge of the program
• IPTs are advisory bodies to the PM
• Direct communication between the program office and all levels in
the acquisition oversight and review process is expected as a means of
exchanging information and building trust.
MILESTONE
DECISION
AUTHORITY
OVERARCHING
INTEGRATED PRODUCT
TEAM
Oversight
& Review
INTEGRATING IPT
COST &
PERFORMANCE
IPT
CONTRACTING
IPT
WIPTs
TEST
IPT
Execution
OTHER
IPTs
AS NEEDED
PROGRAM MANAGEMENT ENVIRONMENT
Figure 2-7 The DoD Integrated Product Team Structure
for Oversight and Review
Program
IPTs
60
ACQUISITION MANAGEMENT
All WIPTs have the following roles and responsibilities:
• Assisting the PM in developing strategies and planning programs as
requested by the OM
• Establishing an IPT plan of action and milestones
• Proposing tailored documentation and milestone requirements
• Reviewing and providing early input documents
• Coordinating WIPT activities with the OIPT members
• Resolving or elevating issues in a timely manner
• Assuming responsibility for obtaining concurrence on issues, documents, or portions of documents.49
Communications Protocol
One FAR performance standard for the integrated acquisition team is to
conduct business with integrity, fairness, and openness. This requires open
communication among team members, internal and external customers,
and the public.50 In 1996 the RAND Corporation published a review of the
management of three DoD acquisition programs as a source for recommending improvements in acquisition management procedures, using lessons learned from other DoD major programs to serve as a basis of their
assessment. Communication was one of the 10 critical success factors selected by RAND. The criteria for evaluation of the effectiveness of communication include the following factors:
• Was communication completely open?
• Were unique, innovative communication techniques being followed?
• Was communication, both verbal and written, continuous?51
RAND’s study also cited the use of the contract as the “common language across the government/contractor team” by the F-22 System Program Office (SPO) as the way to ensure that the team was responding to a
common set of plans, processes, and controls. This “common language”
was found in the “specifications and a requirements-traceability matrix,
the Statement of Work, Work Breakdown Structure, integrated master
plan, integrated master schedule, Cost/Schedule Control System, system
responsibility matrix, technical performance measures, and award fee plan
(if applicable).52 Most of these documents are, or can be, included as part of
the contract. Not only do they establish the common language, but they
also define the contract baseline. All members of the team must know what
the contract says; therefore, it is a primary responsibility of both government and contractor personnel assigned to the integrated acquisition team
to see that the contract is free of ambiguous legalese and that it reflects
current requirements. It also must be accessible to all members of the team.
Introduction to the Federal Acquisition Process
61
With the Internet capabilities available today, the contract can easily be
included on the project’s home page.
MANAGING RISKS AND OPPORTUNITIES
Planning is one of the most important functions a manager performs.
Implementation of all acquisition decisions begins with a plan, which is
key to getting the project off to a successful start. By setting the objectives
of the acquisition, the plan establishes the course for the integrated acquisition team to follow. Without solid planning the buyer is forced to play
catch-up, and the integrated acquisition team becomes reactive rather
than proactive. Objectives developed during the planning process also provide the integrated acquisition team a road map and reference points that
can be used to measure variances from the desired route. Effective management control relies on measurement of the variance from the desired point
and enables the project leadership to evaluate performance and institute
corrective actions where and when required. Acquisition reform efforts
seek to change the program management environment from a risk-averse
philosophy to one of risk management.53
A proactive technique to ensure that objectives are met or exceeded is
called the “Management of Risk and Opportunities” (MR&O). The MR&O
is a structured technique that concentrates management attention where it
will benefit most. It should be thought of as an additional step in the planning process. The goal of the MR&O is to be in position to respond quickly
to potential problems or opportunities if they occur. Chapter 1 defines risk
as a potential problem and opportunity as a chance to improve on the state
of the acquisition.
The last step in acquisition planning is to answer the following four
questions:
• What potential problems (risks) might occur, and what opportunities
are possible?
• What are the likely causes of problems or opportunities?
• What is the probability of these problems or opportunities occurring?
• What is the potential impact of the problems or opportunities?54
By looking into the future at the probable risks and opportunities, the
acquisition manager can develop contingency courses of action that will
alleviate the problem or position the project to capitalize on the opportunity. Art Gemmer of Rockwell International views it as performing in a
“working smarter” mode rather than the “working harder” mode. He contends that acquisition programs that operate in the “work harder” mode
spend most of their time dealing with the consequences of their past decisions, while programs that operate in a “work smarter” mode have antici-
62
ACQUISITION MANAGEMENT
pated change and can easily adapt to their environment because they have
spent most of their time considering future options.55
Sources of Risk
Identifying the risks associated with an acquisition is a function of logic,
reason, experience, and intuition. Because one is looking for future potential problems, experience and intuition are especially useful guides. Historically, risk falls into five categories: political, financial, technical, human, and risks due to uncertainty. Figure 2-8, Sources of Risk, illustrates
these categories.
Political factors include the internal influence of the functions and the
other parties. In addition, each project is subject to labor and environmental regulations. Government contracts not only are subject to the potential
ups and downs of annual appropriations, but priority changes by the executive and legislative branches can result in revised funding profiles and
RISK
POLITICAL
FACTORS
FINANCIAL
FACTORS
TECHNICAL
FACTORS
Internal to
Team
Regulatory
Agencies
Cost
Growth
Financial
Health of
Prime
Schedule
Design
Delivery
Stretch-out
Competitors
Financial
Health of
Vendors
Economy
Quality
Performance
R and D
Investment
by Others
HUMAN
FACTORS
Funding
Lack of
Understanding
of Requirements
Haste
Language
Behavior of
the parties
UNCERTAINTY
Time
Information
Control of
Resources
Figure 2-8 Sources of Risk
Production
Introduction to the Federal Acquisition Process
63
the lengthening of delivery schedules. New or updated products by competitors also have an effect on the acquisition.
Financial factors include the financial health of the prime contractors
and subcontractors as well as interest rates and inflation. Cost growth related to contractor performance is a factor that is extremely important because it could lead to the termination of the procurement.
Technical factors include such elements as design, product performance,
quality of the item produced, and the impact of all these subfactors on the
schedule. For example, a study of 8,000 software projects in the U.S. by the
Standish Group concluded that 84 percent did not finish on time, on budget, and with all the features installed.56
Human factors contributing to risk include the shortcomings of language
and differing interpretations of the contract language and the contract itself. Rules of contract interpretation, which will be covered in Chapter 7,
are important considerations to keep in mind when developing the contract. Government contracts not only allocate risk via the contract type,
but they also contain risk allocation clauses that address deadline extensions or price adjustments should various contingencies occur or conditions not be as expected or represented. There are also risk allocation techniques, which have their roots in common law, that may serve as a basis
for interpreting the scope of contract clauses.57
Uncertainty includes two dimensions. There is uncertainty as to when
events will occur and the ability of the acquisition team to react to them.
Uncertainty as to the adequacy and accuracy of the information used to
make decisions is another important subfactor.58
Managing Risk
Acquisition doctrine emphasizes the “management of risk” rather than
“risk avoidance.” The FAR points out that attempting to avoid risk totally is
cost prohibitive.59 Dr. Saul W. Gellerman, former Dean of the Graduate
School of Management at the University of Dallas, expressed it well by
saying, “Managers are not paid to take risks, but to know what risks to
take.”60
Acquisition doctrine considers management an important part of each
procurement. DoD Directive 5000.1 defines risk management as “an
approach...that...encompasses risk identification, mitigation and continuous tracking, and control procedures that feedback through the program
assessment process to decision authorities.”61 This philosophy represents a
departure from past practices in which risk was avoided by instituting what
proved to be costly specifications and processes that were unique to government contracts.
For example, risk management in DoD is a systematic process that includes four steps: risk planning, risk assessment, risk handling, and risk
64
ACQUISITION MANAGEMENT
monitoring. Figure 2-9, Risk Management in the Acquisition Process,
shows the flow of these risk management activities during the acquisition
process, i.e., before the request for proposal, during the proposal phase,
and after contract award.62
Risk planning: Risk planning is a process that includes developing, documenting, and organizing a comprehensive interactive strategy that includes methods for identifying and tracking risk areas as well as developing
risk handling plans and performing risk assessments to determine how
risks change during the course of the acquisition. The plan also includes
determining resource requirements.63 The risk management plan should
serve the following functions:
1. It identifies possible acts that could prevent meeting a specific goal,
e.g., late delivery of parts needed for assembly, inoperative government-furnished equipment, situations in which several people or organizations share responsibility, tight deadlines, or a complex technical problem.
2. It enables management to focus attention on future issues that may
cause a variance from plan, e.g., the risk of a potential problem.
RISK PLANNING
RISK ASSESSMENT
MISSION
NEEDS
STATEMENT
RISK HANDLING
OPERATIONAL
REQUIREMENTS
DOCUMENT
INITIAL SPO PLAN
SYSTEMS
REQUIREMENTS
DOCUMENT
SPO PLAN & BUDGET
PROPOSAL
RISK ASSESSMENT
& HANDLING
RFP PREPARATION
AND RELEASE
RISK ASSESSMENT
& HANDLING
CONTRACT
AWARD
PROPOSAL
EVALUATION
POST AWARD
CONTINUED
USE AS A
MANAGEMENT
TOOL
RISK ASSESSMENT
RISK HANDLING
&
MONITORING
Figure 2-9 Risk Management in the Acquisition Process
Introduction to the Federal Acquisition Process
65
3. It serves as the basis for determining where corrective action should
be concentrated and establishes priorities among the actions needed.
4. It provides management with a tool for evaluating the status and improving the situation.
Risk assessment: The genesis of risk is usually found in the following three
sources: organizational politics, finances, and technical and product support. Potential problems often arise when the outcome of a project depends on actions taken by others who are assigned to different internal or
external organizations. A prime example is the relationship between the
prime contractor and its suppliers. Another illustration can be found in the
design and manufacture of a technically complex and multi-functional
product that depends on the effective interface of numerous components
to fulfill. In business, competitors that can change their pricing strategy or
introduce an improved product are a potential source of risk. The same can
be said about a hostile power that can introduce a new aircraft with increased capability. Potential financial problems are also present in every
project. Government projects that are dependent on annual funding by
Congress run the risk of budget cutbacks. Another example of financial risk
is the possible bankruptcy of a key supplier. Technical uncertainty is a wellknown source of risk. The design, manufacture, and testing of almost every
product have varying degrees of technical risk. A highly risky technical
project results from uncertainty associated with the various unknowns related to the requirement.64
Uncertainty about whether the job can be accomplished in the time allowed is a major cause of risk, as is uncertainty regarding the ability to react
and accomplish a repair in the time allotted. The lack of direct supervision,
i.e., total control, over the resources required to do the job is often perceived as a source of risk because of inadequate authority to establish priorities. The possibility of inadequate or inaccurate information on which
to base a decision is also present in almost every management situation.65
To assess risk accurately, the analyst should follow a structured approach
that includes: (1) identifying the risk and its characteristics, (2) estimating
the probability of occurrence, (3) identifying the timeframe and probability distribution of the risk, and (4) determining the impact on acquisition
goals and expectations.66 The latter includes determining the impact on
cost, schedule, performance, and logistics support. To describe the potential problem accurately, one needs to include additional characteristics,
such as an estimate of the probability of occurrence if the situation is allowed to continue. Knowledge of the timeframe during which corrective action must be taken to relieve the situation is an important factor. However,
the uncertainty regarding the probability of occurrence of a risk may also vary
over time. Linking of one risk to other possible risks is an additional attribute.
If the risk becomes a problem, it often triggers additional risks.67
66
ACQUISITION MANAGEMENT
Risk handling: In developing the risk-handling strategy the integrated acquisition team must consider the probability of occurrence, possible time
frame of occurrence, and possible impact. All risk-handling actions involve
a tradeoff between cost and benefits. As noted earlier, the benefits derived
from improving the reliability of the product from 97 percent to 100 percent by increasing the amount of product testing may not be worth the
cost.
The risk-handling strategies implemented during the request for proposal (RFP) and proposal evaluation phases include:
• Risk mitigation, which is the reduction of the probability that a problem will occur or of its impact.
• Risk avoidance, which is the complete elimination of the possibility of
occurrence. This may be costly or require creating other risks that
might make an acceptable impact on the acquisition.
• Risk transfer, which includes getting another party to assume the risk
or share the consequences. Examples include selection of contract
type, warranties, and insurance policies. Contract terms and conditions are other vehicles whereby risk can be shifted or shared.
• Risk acceptance is the determination that, based on its impact, an acceptable strategy would be to track the risk and take action only when
it becomes a problem.68
Changes to government acquisition policies are also being used to implement risk management. The following recent examples show how DoD
policies are attempting to reduce risk:
• Including the customer and contractor as members of the integrated
acquisition team to reduce the technical risk resulting from a lack of
understanding requirements.
• Emphasizing the selection of commercial, off-the-shelf items to minimize the technical risk associated with development of governmentunique products.
• Instituting a single-process policy in contractor manufacturing facilities to reduce exposure to the high cost of having different processes
for the same products.
• Balancing cost objectives with mission needs under the policy of cost
as an independent variable (CAIV), thereby diminishing the danger of
acquiring non-affordable systems. The CAIV-based parameters will
become part of the Acquisition Program Baseline (APB).
• Making past performance an evaluation factor in every source selection for negotiated procurements to reduce the cost, schedule, and
technical risks related to contract award to contractors with a poor
track record.
Introduction to the Federal Acquisition Process
67
Management of risk must be an integral part of the acquisition process
and is especially pertinent during acquisition planning, development of
the solicitation, contract award, and contract formation.
Managing Opportunities
In some areas there are opportunities to exceed the project’s expectations, which could result in a compensatory change to the contract. A costbenefit tradeoff must be made to determine whether the extra or added
performance is worth the added cost. This must be completed and approved contractually before any effort begins.
Figure 2-10, Cost Benefit vs. Performance Tradeoff, illustrates a relationship
between cost, performance, and time. In this example time is fixed by the
period of performance stipulated in the contract. Curve O A represents the
contract level of performance. Curve O B represents a 10 percent improvement in performance by adding additional resources (cost) to the effort.
The greater the potential performance, the greater the cost. As you move
from left to right on the cost/performance curve, the cost per increment of
increased performance slowly increases until cost becomes exponential. It
is the task of acquisition management to determine where the expected
benefit from added performance equals the added cost. Above that point it
is less than cost-effective, and the need must justify the cost.
110% Performance
B
PERFORMANCE
100% Performance
A
0
COST
Figure 2-10 Cost Benefit vs. Performance Tradeoff
68
ACQUISITION MANAGEMENT
On the contractor’s side, the primary objective of a business is to maximize the wealth of the shareholders (owners).69 The contractor is motivated to achieve long-term profits by producing quality products and
establishing a long-term relationship and repeat business. Contractors realize that the best way to achieve this goal is to meet the performance and
schedule goals of the agreement within cost. The importance placed on
past performance in source selection acknowledges this objective. Internally it is the return on assets (ROA) and return on investment (ROI) that
measure the profitability of a business organization, i.e., the effectiveness
with which capital is being utilized.70 Delivery schedules, payment
frequency, financing provisions, and other provisions of a contract can
significantly affect a contractor’s cash flow and ROA. An overall excellent
performance by the contractor provides an opportunity for repeat
business.
The FAR includes a procedure, i.e., the Value Engineering clause,71 that
can result in the sharing of any cost reduction. Under this procedure the
contractor submits a Value Engineering Change Proposal (VECP), which
can result in a reduction to the contract price without impairing the functions or characteristics of the product. In theory the VECP is intended to
provide the contract or an incentive to develop ways to be more efficient
by including a provision on how the cost avoided will be shared. Use of the
VECP clause also avoids any question of defective pricing if the contractor
changes the method of performance after its disclosure during negotiations and the certifying cost or pricing data.
The Value Engineering (VE) concept originated during World War II,
when many essential materials used in production were scarce and creative
engineers at General Electric (GE) used alternatives. Not only did the substitutes perform satisfactorily, but some turned out to be more reliable or
cheaper. After WWII a purchasing agent at GE was given the job to develop
“a systematic approach to the investigation of the function-cost aspect of
existing materials specifications.” The approach, referred to as value analysis by GE, is defined as “an organized creative approach which has for its
purpose the efficient identification of unnecessary cost.”72
As noted, to be more competitive many organizations in private sector
procurement, or material management, have been given increased responsibility for the cost of purchased material. Therefore, it is their responsibility to provide incentives for suppliers to offer cost-saving suggestions during the product design process.
Potential functions that are subject to function-cost tradeoff include:
• Material composition and manufacturing operations and processes
used in production parts and assemblies
• Acceptance and reliability testing
• Packaging specifications
Introduction to the Federal Acquisition Process
•
•
•
•
69
Design of operating systems
Administration
Transportation
Production inventory.
Figure 2-11, Management of Risk and Opportunities, summarizes the
MR&O technique and illustrates how it unfolds over the acquisition process. The x-axis represents the life of the contract. The y-axis depicts leadership by the entire integrated acquisition team to manage the risks and opportunities associated with controlling the variances from the planned
acquisition. During the pre-award phase the risks and opportunities are
incorporated into pre-award planning, solicitation, and contract award
phases. Risks and opportunities on the diagram are separated by the center
horizontal line, which represents the objectives of the acquisition.
During pre-award planning, risks and opportunities are identified and
commitments made as to the expected outcome, along with the risk associated with attaining the stated acquisition goals. Risk-handling strategies
designed to avoid, mitigate, or transfer risks will be incorporated into the
Future
Sales
Negotiation
Objective
Commitments
Profit
OPPORTUNITIES
LEADERSHIP
ROA
Reputation
Sales
IMPROVEMENTS
Establishment
of
Opportunity
Objectives
PRE-AWARD PHASE
Submission of RFP
Risk
Identification
Negotiated Agreement
Technical
AWARD
PHASE
Negotiated
Objectives
Line
Reputation
Financial
RISK
Political
POST-AWARD PHASE
Figure 2-11 Management of Risk and Opportunities
DIGRESSION
Product Performance Improvements
70
ACQUISITION MANAGEMENT
solicitation for those risks whose potential impact is judged to be unacceptable. This process includes an implied management commitment to how
risks and opportunities will be overseen. This becomes the foundation on
which the source selection is made, the contract is awarded, and the contract document itself is formulated.
After the contract is awarded and the conforming contract is issued, the
performance phase begins. Here both the government and the contractor
must be involved in tracking the risks and opportunities as the performance phase evolves. Possible variations from contract objectives are
shown on Figure 2-11; they diverge from the center line of balance as performance progresses. Opportunities for improvements, i.e., overall performance, deliveries, ROA, ROI, reputation, and future programs (contractor
sales), are shown above the objective line. Below the line are the possible
political, technical, financial, and supportability risks.
Figure 2-12, Handling Risks and Opportunities, illustrates how the management of risks and opportunities begins with defining the objectives of
the acquisition during the requirements determination process. This
method is a recurring process designed to improve acquisition planning
and then monitor the plans process so the integrated acquisition team can
mitigate risks that could potentially prevent attaining the acquisition objectives. The amount of time the integrated acquisition team spends on
this process depends on the complexity of the procurement. For highly
technical and complex projects or programs, a formal handling program is
appropriate. Techniques used in the process include answering the following questions early in the requirements determination process:
• What are the risks and potential opportunities, i.e., what could happen that would prevent attaining objectives or provide an opportunity
to exceed expectations?
• What are their likely causes, the probability of their occurrence, and
their probable impact?
• What actions can be taken to handle the risks?
• What opportunities might be discovered during performance, and
how should they be handled?
Answers to these questions are used in building a “How to Handle Plan.”
This plan has two parts. The first includes actions that can be taken to
reduce risk or likely causes of problems. The second part of the plan should
list what can be done to maximize the rewards associated with the opportunities. For each risk the plan should document: (1) a description of the
possible cause, (2) the probability of occurrence, (3) a quantification of the
impact or possible variance from the objective if the risk becomes a problem or an opportunity presents itself, and (4) a list of alternative actions,
including contract provisions that would minimize or avoid any negative
variance from the plan or steps that can be taken to improve the situation.
Introduction to the Federal Acquisition Process
71
DEFINE
EXPECTATIONS
External
Risk or
Opportunities
Identify
Potential Risks
&
Opportunities
Characterize
Risks &
Opportunities
Prioritize
Risks &
Opportunities
Implement
Risk &
Opportunity
Strategy
Compare
Performance
With
Strategy
Take No Action
Performance Is
According to Plan
Appraise
the
Situation
Positive
or
Negative
Variance
Situation Analysis
Identify Causes
and Develop
Alternatives
Complete Project
SUCCESS
Figure 2-12 Handling Risks and Opportunities
CONCLUSION
It is clear that to be effective and efficient in the 21st century, the federal
acquisition process must be structured to cope with increasing competition for scarce budget dollars, the need for flatter organizations, strategic
alliances between suppliers, and an exponential growth in the area of electronic data interchange.
72
ACQUISITION MANAGEMENT
In recent years DoD has done much to improve its acquisition practices
and policies through acquisition reform and to transform its logistics systems to integrated supply chains driven by modern information technologies and a wide range of best business practices that have been proven in
the commercial sector.73
To add value to the acquisition process, the contracting community
must become more proactive and innovative. Procurement is much
broader than the purchase of goods and services—it involves activities that
take place in many functions. “Organizations exercise the best control over
cost and quality of purchased goods and services only when appropriate
members of the various departments involved in the procurement process
operate as an interdependent, integrated system. When this happens, a
synergism takes place, with the result that the integrated efforts become
greater than the sum of the individual efforts.”74
It is clear that the capabilities of EDI are not limited to the further automation of the existing acquisition process. EDI has eliminated distance as
an inhibitor to communications, thus creating common databases that not
only will enhance communications but also will link organizations and
their processes together. Contractors with good performance track records,
along with effective supply chains and manufacturing processes, will have
an advantage over their competitors. This capability will reduce the average acquisition cycle time and lower the cost of ownership.
In Chapter 3 we will begin our focus on the acquisition process and how
acquisition doctrine extrapolates lessons of the past to the acquisition environment of the future.
NOTES
Drucker, Peter. 1987. The Coming of the New Organization. Harvard Business Review on Knowledge Management. Cambridge, MA: Harvard Business School Press, 3.
2Burt, David N., and Richard L. Pinkerton. 1996. A Purchasing Manager’s Guide To
Strategic Proactive Procurement. New York: American Management Association, xi.
3Doyle, Gregory. 1999. Developing the Next Generation of Contracting Officers
(and This Generation, Too). Contract Management (April): 43.
4The Contracting Professional as a Manager: 2000 National Education Seminar. 2000.
Vienna, VA: National Contract Management Association, 1–5.
5Rummler, Gear, and Gordon Sellers. 1997. Pitfalls in the Strategic Deployment of
Processes Improvement Management. Excellence in Practice: Innovation and Excellence
in Workflow and Imaging. Lighthouse Point, FL: Future Strategies Inc., 193.
6The Contracting Professional as a Manager: 2000 National Education Seminar. 2000.
National Contract Management Association, Vienna, VA: 3–4.
1
Introduction to the Federal Acquisition Process
73
Nash, Ralph C., Jr., Steven L. Schooner, and Karen O’Brien. 1998. The Government
Contracts Reference Book. 2d ed. Washington, D.C.: The George Washington University, 9.
8DOD Directive 5000.1 “Defense Acquisition,” March 15, 1991. DODI 5000.2. 2001
Operation of the Defense Acquisition System, January 4, paragraph 4.5 refers to the
“new acquisition process” without defining the term.
9The two terms, i.e., project and program, signify differences in the estimated value
of the acquisition. A program has more scope, is more complex, and has a higher fund
value than a project. In this book we use the term project manager for simplicity. However, the material pertains to both to a varying degree.
10Hicks, Herbert G. 1972. The Management of Organizations: A Systems and Human
Resources Approach, 2d ed. New York: McGraw-Hill, 270.
11Nash, Schooner, and O’Brien, 416.
12Nash, Schooner, and O’Brien, 418.
13The Contracting Professional as a Business Manager: 2000 National Education Seminar. 2000. National Contract Management Association, Vienna, VA, 3-2.
14Nash, Schooner, and O’Brien, 418.
15Lax, David A., and James K. Sebenius. 1996. The Manager as Negotiator: Bargaining
for Cooperation and Competitive Gain. New York: The Free Press, 12.
16Lax and Sebenius, 14.
17Quinn, James Bryan, Philip Anderson, and Sydney Finkelstein. 1998. Managing
Professional Intellect. Harvard Business Review of Knowledge Management. Cambridge,
MA: Harvard Business School Press, 193.
18Quinn, Anderson, and Finkelstein, 201.
19Nash, Schooner, and O’Brien, 127.
20FAR 2.101.
21FAR 1.602-2.
22Nash, Schooner, and O’Brien, 127.
23Cibinic, John, Jr., and Ralph C. Nash, Jr. 1985. Administration of Government Contracts Washington D.C.: The George Washington University, Government Contracts
Program, 23–24.
24Nash, Ralph C., Jr. 1997. Training the Contracting Officer of the Future. Contract
Management (March): 16.
25The Contracting Professional as a Manager: 2000 National Education Seminar. 2000.
Vienna, VA: National Contract Management Association, 1–2.
26Doyle, 42.
27FAR 1.102-4 (a).
28FAR 1.102-4 (e).
29The Contracting Professional as a Manager: 2000 National Education Seminar. 2000.
Vienna, VA: National Contract Management Association, 1–10.
30Drake, Daniel J. 1996. Procurement Manager’s Guide to EC/EDI. Vienna, VA:
Holbrook & Kellog Inc., 5–17.
7
74
ACQUISITION MANAGEMENT
Drake, 5–17.
In the case of system acquisitions, the program baseline, which is expressed in
terms of cost, schedule, performance, and supportability, and the contract baseline
should be the same.
31
32
Burt and Pinkerton, 4.
Dobler, Donald W., and David N. Burt. 1996. Purchasing and Supply Management.
6th ed. New York: McGraw-Hill, 38.
35Macfarlan, Gregor. 2000. The Buyer as a Business Manager? Contract Management
(August): 29.
36O’Brien, Dan. 1998. Briefing during 11th Annual Academic Conference for Contract Management Educators, National Contract Management Association. 29 October 1998, Monterey, CA.
37Johnson, Robert V., and John Birkler. 1996. Three Programs and Ten Criteria: Evaluating and Improving Acquisition Program Management and Oversight Processes Within the
Department of Defense. RAND, National Defense Research Institute. Prepared for the
Office of the Secretary of Defense, Santa Monica, CA, 41. The other two causes were
the lack of mature technology to satisfy the requirement and lack of a planning and
tracking system to measure progress.
38Taub, Eric. Taurus: The Making of the Car That Saved Ford. New York: Penguin, 131.
39Bowersox, Donald J., Patricia J. Daugherty, Cornelia L. Droge, Richard N. Germain,
and Dale S. Rogers. 1992. Logistics Excellence: It Is Not Business as Usual. Burlington,
MA: Digital Press, 34.
40Walton, Mary. 1986. The Deming Management Method. New York: Perigee, 64.
41Burt and Pinkerton, ix.
42Venkatesan, Ravi. 1992. Strategic Sourcing—To Make or Not to Make. Harvard
Business Review (November-December): 98.
43Hocevar, Susan P., and Walter E. Owen. 1998. Team-Based Redesign a Large-Scale
Change: Applying Theory to the Implementation of Integrated Product Teams. Acquisition Review Quarterly5(2): 147.
44DoD Regulation 5000.1. The Defense Acquisition System, Enclosure E, paragraph
E2.1.6, 23 October 2000.
45Hocevar and Owen, 150.
46DoD Regulation 5000.2-R, paragraph E2.1.6.
47DoD Regulation 5000.1, The Defense Acquisition System, paragraph 4.5.6, 23
October 2000.
48DoD Regulation 5000.1, Enclosure E, paragraph E2.1.5.
49DoD Regulation 5000.2-R. Mandatory Procedures for Major Defense Acquisition
Programs (MDAPs) and Major Automated Information System (MAIS) Acquisition Programs. Part 7, paragraph 7.6.3.
50FAR 1-102 (c).
51Johnson and Birkler, 9.
52Johnson and Birkler, 41.
33
34
Introduction to the Federal Acquisition Process
75
FAR 1-102 (c) (2).
Spitzer, Quinn, and Ron Evans. 1999. Heads You Win: How the Best Companies
Think—and How You Can Use Their Examples to Develop Critical Thinking Within Your
Organization. New York: Simon and Schuster, 98.
53
54
Gemmer, Art. 1997. Risk Management. Computer (May): 36.
Hoch, Detlev J., Cyriac R. Roeding, Gert Purkert, and Sandra K. Linder. 1999. Secret
of Software Success. Boston MA.: Harvard Business School Press, 94.
57Cibinic, John, Jr., and Ralph C. Nash, Jr. 1986. Administration of Government Contracts. 2d ed. Washington D.C.: The George Washington University, 178.
58Gemmer, Art. 1997. Risk Management. Computer (May): 38.
59FAR 1.102-2 (c) (2).
60Interview, August 17, 1998.
61DoD Directive 5000.1, Defense Acquisition, March 15, 1996, D.1.4 d.
62The Contracting Professional as a Manager: 2000 National Education Seminar, 2-5.
63Ibid.
64Gemmer, 37.
65Gemmer, 38.
66Ibid.
67Ibid.
68Ibid.
69Symonds, Curtis W. 1978. Basic Financial Management. New York: AMACOM, 4.
70Chisholm, William D. 1985. Return on Assets/Investment Considerations for Contract Managers. National Contract Management Journal (Winter): 58.
71FAR 52.248-1 and FAR 52.248-2.
72Burt and Pinkerton, 157.
73Gansler, J.S. 2000. The Under Secretary of Defense, Acquisition and Technology.
Washington, D.C., 3.
74Burt and Pinkerton, 3.
55
56
Introduction to
IT Project
Management
Cynthia Snyder
Frank Parth
8230 Leesburg Pike, Suite 800
Vienna, VA 22182
(703) 790-9595
Fax: (703) 790-1371
www.managementconcepts.com
Copyright © 2007 by Management Concepts, Inc.
All rights reserved. No part of this book may be reproduced or utilized in any form
or by any means, electronic or mechanical, including photocopying, recording, or
by an information storage and retrieval system, without permission in writing from
the publisher, except for brief quotations in review articles.
Printed in the United States of America
Library of Congress Cataloging-in-Publication Data
Synder, Cynthia, 1962–
Introduction to IT project management / Cynthia Snyder, Frank Parth.
p. cm.
Includes bibliographical references and index.
ISBN 1-56726-178-7
1. Information technology projects—Management. I. Parth, Frank, 1949– II. Title.
HD30.2S635 2007
658.4’038—dc22
2006046828
1
Projects and
Operations
After reading this chapter, you will be able to:
• Define how projects and operations are different.
• Describe how IT projects differ from non-IT projects.
• Explain the value of project management for IT projects.
• Define key terms in project management.
Welcome to the world of information technology project management. In
reading this book, you will find that managing IT projects can be highly rewarding and, often, equally frustrating. You will discover that project team
members, project customers, and other project stakeholders can be very easy
to work with and at the same time can be very challenging. It is not uncommon in project management to get a high-priority project from upper management one week and then find the next week that things have changed and
a new project is the number one priority. You will almost never have enough
resources to do the work and never have enough time to produce the best
product possible. You will be told not to spend time planning the project but
to just begin working, and you won’t have enough time to gather the user
requirements before you need to start development. Your resources will be
working on three other projects as well as normal daily operations, while
you’re trying to get them to work on your project.
However, when the project is over you will have produced something that
makes work easier for the other people in your organization, saves your organization a significant amount of money, keeps private data secure, or upgrades a legacy system into something much more effective and efficient.
When all the work of the project is over, you will have made a real contribution to the organization.
Chapter 1
What Is Project Management?
Project management is the application of skills, knowledge, and abilities to
produce a unique product, service, or result. Three components that lead to
successful projects are technical knowledge, general management abilities,
and project management skills.
The project manager must have knowledge of the technical aspects of the
project. Although some will debate this point, in IT projects particularly the
project manager needs to know enough to detect when something is amiss
and to understand the general principles of the project. He or she certainly
does not need to be a subject matter expert in every facet, but some amount
of knowledge is a necessity.
The project manager also needs some capability in the area of general management, including skills in budgeting, analysis, planning, and coordinating.
Finally, the project manager must apply project management skills, tools, and
techniques to make the project a success. This book focuses on the project
management component while referencing technical knowledge and some
general management abilities (see Figure 1-1).
Figure 1-1. Components for Successful Projects
Projects and Operations Managing IT projects is similar to managing other types of projects, such as
projects in the fields of construction and pharmaceutical development. However, IT project management has unique aspects, including:
• Technical projects require team members with specific technical skills.
• For small projects, team members are typically working on multiple projects at the same time.
• Most team members have operational responsibilities as well as project
responsibilities.
• Larger IT projects tend to form the very infrastructure of the organization,
and failure can cost millions of dollars.
• Because of the pervasiveness of information systems, a simple IT project
may become complex because of the number of other systems it touches.
• Technology is evolving so rapidly that software and hardware are almost
always out-of-date before they are deployed.
• Technology requires continual upgrading, maintenance, and improvement.
• The changing nature of technology can make it difficult to estimate accurately or to learn from previous projects.
The differences inherent in IT projects create a need for specialized approaches to manage IT projects effectively. The basic methodology of project management continually advances as we learn what works under what
conditions and what does not work. Although it is tempting to use a recipe
approach to managing IT projects, the reality is that each organization must
start with the basic principles of project management—which are presented
in this book—and develop a detailed approach that works for its organizational structure, culture, and environment.
Project management practices and methods are evolving. As organizations
change and evolve, the approaches needed to effectively manage projects also
change and evolve. The largest professional organization dedicated to project
management is the Project Management Institute (PMI®) with over 200,000
members worldwide at the time this book was written. PMI’s book A Guide to
the Project Management Body of Knowledge (PMBOK® Guide) was developed by
practicing project managers, and it is the American national standard for project management.1 This guide is continually evolving as new approaches and
new practices are integrated into project management. However, it is not the
only approach to managing IT projects. An approach called Projects in Con-
Chapter 1
trolled Environments (PRINCE2) was developed by the IT Directorate of the
British Government. PRINCE2 places a heavy emphasis on creating a strong
business case for IT projects and continually monitoring the project against
the business case. The Information Systems Audit and Control Association
(ISACA) has developed Control Objectives for Information and Related Technology (CoBIT), which emphasizes controlling and auditing IT projects.
Why Use Project Management?
Why are there so many approaches to managing IT projects? Because the failure rate of IT development work is high. The baseline study of IT project success is the CHAOS Report released by the Standish Group in 1995.2 This report
showed that 31 percent of projects were canceled before completion and 52.7
percent of projects cost over 189 percent of their original estimates.
Based on this research, the Standish Group estimated that in 1995 American
companies and government agencies spent $81 billion for canceled software
projects and had to pay an additional $59 billion for software projects that
exceeded their planned schedules. It estimated that almost 80,000 projects
were cancelled in 1995. Although large IT projects are always risky, many of
these projects were as straightforward as a drivers’ license database, a new
accounting package, or an order entry system. This book will help you understand the unique aspects of managing IT projects and how to improve the
success rate of your projects significantly.
This book is about how to manage IT projects. It is not a book on software project management and it is not a book on implementing enterprise-wide software applications. It is not a book on how to manage local area network (LAN)
design and installation. All of these are types of IT projects, but IT is a much
broader field than any one of those areas. We will use a working definition that
IT project management is about managing projects where a significant portion
of the product or result is dependent on some aspect of information technology. This book will give you a strong start towards managing those projects.
How Is Project Management Different
from Operational Management?
When most of us consider an organization, we think of a hierarchical assortment of departments that collectively produce some type of product or
Projects and Operations service. Most organizations have a marketing department, a finance department, a human resources department, some type of production or manufacturing department, and, of course, an IT department. These departments
work more or less collaboratively to create something of value that the organization provides to its customers in order to sustain the organization. In
the world of operations management, departments work towards company
objectives.
For example, in operations management the goal could be to produce and sell
the best widget for the least amount of money and to sustain those operations.
At that point, production becomes repetitive and static. However, projects are
not repetitive; projects are one-time events designed to produce specific results and then to end. The PMBOK® Guide defines a project as a temporary
endeavor undertaken to create a unique product, service, or result.3
Although departmental operations tend to focus on the objectives that each
department is working to achieve, projects focus on a client or business objective. Operations management is concerned primarily with keeping the
lights on and ensuring that the company continues and grows. Projects produce a specific deliverable and then dissolve.
The structure of management is also different. Operational departments have
managers and staff assigned full-time with well-established roles, responsibilities, and authority. Projects are temporary in nature; the project manager
and team members are brought together for a short period, complete the
work, and then disband. The project may be comprised of people at varying levels of skill, responsibility, and authority. Depending on the organization, project managers may have full authority or very little authority when
it comes to making decisions and managing people and budgets. Although
their level of authority varies, their level of responsibility does not—they are
always fully accountable for bringing the project in on time and on budget
and for satisfying all the requirements.
For projects, time, budget, and scope are constraints—limitations within
which the project manager must work. By comparison, in production environments these constraints are incorporated into the process. For example,
a production line produces 750 widgets each day, the staffing is sufficient to
manufacture the widget, and material costs are negotiated upfront with a
fixed percentage factored in for rework or failure.
Table 1-1 summarizes some of the primary differences between projects and
ongoing operations.
Chapter 1
Table 1-1. Differences between Projects and Operations
Projects
Ongoing Operations
Defined end date
Ongoing
Unique
Standardized
One time/new
Repetitive
Customer focus
Departmental focus
Drop-in project manager
Continuing manager
May lack formal authority
Defined authority
Temporary team
Permanent department
Complex communications
Everyday interactions
Scope may evolve
Well-established objectives
Scope/cost/time constraints
Constraints are factored into established processes
Generally have high risk
Most risks have been eliminated over time
Although this is a somewhat simplified version of operations, you can see that
managing an outcome in the world of project management can be much more
challenging than managing an outcome in an operations environment.
In Practice: Mergers
The merger between Hewlett-Packard and Compaq provides an example of how
failure in IT projects can impact organizations and their profits. A major difficulty
with the merger was the “bungled integration of separate HP and Compaq
implementations of SAP AG’s enterprise software.”4 Despite the fact that both
companies were using the SAP enterprise resource planning (ERP) system, the
problems with the integration cost the Americas division of HP’s Enterprise Storage
Group about $400 million in revenue and $275 million in operating profits.
Successful Project Management
Now that we have provided a summary definition of successful projects and
project management, let’s take a closer look at project management. Project management includes identifying requirements; establishing clear and
achievable objectives; balancing demands for quality, scope, time, and cost;
and adapting the specifications, plans, and approach to the needs and concerns of various stakeholders. But this is just one aspect of what it takes to call
the project a success.
Projects and Operations Projects are usually performed by a team rather
than by just one person,
• What aspects of projects make them
so a major component of
more challenging than operations?
being a successful project
• What aspect of project management do
manager is managing peoyou like the best?
ple to achieve the project
goals. Many new project
managers mistakenly think that project management is just another task to
be done on top of developing the product. As an IT project manager, you are
primarily responsible for ensuring the work is done, not for doing it yourself. This is a difficult transition for many technical people to make. You are a
manager now, not a technical person doing coding or designing a LAN.
What Do You Think?
Another common misconception is that if you have Microsoft Project or
some other project software you can manage a project. There is an old saying
in project management that having a copy of MS Project makes you a project
manager to the same extent that having a copy of MS Word makes you an author. Managing schedules and using software are pieces of project management, but certainly do not, by themselves, lead to successful projects.
One of the most challenging jobs a project manager faces is defining and
balancing the expectations of project stakeholders. If you meet the scope
of the project, on time and within budget, but the customer is not satisfied,
the project is not a success. Additionally, even if the customer is satisfied, if
the project team is burned out—or worse, feels abused—the project should
not be considered a success. One criteria of success can be whether the team
would want to work with the project manager again. If the answer is no, then
the project manager did not successfully manage the team.
So then, what is a successful project? One view says that a project is successful when all stakeholders are satisfied. For the most part that means that the
customer’s requirements were met in a timely fashion for the agreed upon
budget. However, it also means that the project is a strategic success, is consistent with the organization’s strategy (more on this in a later chapter), and
meets the needs for which it was undertaken. It also means that the team
members are satisfied. Sometimes the biggest challenge is how to meet tight
deadlines without creating team burnout. Figure 1-2 shows the project management balancing act.
Chapter 1
Figure 1-2. Project Management Balancing Act
Scope
Team
Members
Cost
Schedule
Organizational
Strategy
Programs and Portfolios
Although this book will focus on projects and project management, understanding the context of projects in the bigger picture is useful. Some organizations do projects (sometimes many projects) that too often are not organized
or prioritized in any particular manner. The entire suite of projects within a
company or department is called the project portfolio.
Earlier we defined a project as a temporary endeavor undertaken to create
a unique product or service. Some projects are so large that they have to be
subdivided into multiple
projects, each of which
contributes to the accomplishment of the larger
• What are some of the areas where
project. A project that
managing people is important to project
consists of subprojects is
success?
called a program. Each
• What do you think defines project
of the smaller projects is
success?
managed separately, but
What Do You Think?
Projects and Operations all of them have goals that support the program. An example of a program is
a large corporate initiative such as installing an enterprise resource planning
(ERP) system. Each department affected by this program may have a series
of projects related to the program, such as requirements definition, process
engineering, identifying the business rules, and so on.
A project portfolio is a collection of projects and/or programs managed as a
single group to support organizational or departmental goals. The projects
in a portfolio may be related, such as a portfolio of defense programs and
projects or a portfolio of commercial programs and projects. They may be
unrelated, such as when a portfolio is managed to ensure the proper balance
among infrastructure projects, security projects, and business development
projects. Figure 1-3 shows a possible project portfolio composed of various
projects and programs.
Figure 1-3. Projects, Programs, and Portfolios
10 Chapter 1
A Brief History of IT Project
Management
Modern project management traces its roots back to the late 1950s when the
Project Evaluation and Review Technique (PERT) and the Critical Path Method (CPM) were developed. These methods were created to handle projects
that were growing increasingly complex. PERT was developed and used in the
defense field and CPM in the construction field.
Projects from both of these fields shared common characteristics: they were
large and complex, had significant technical risk associated with them, and
had dedicated project managers and dedicated project teams. This environment existed for more than 20 years, and it worked very well. NASA’s ability to
develop large, complex, risky rockets and manned space systems under tight
schedules during the 1960s was due to its strong project management skills.
Electrical machines have been able to perform calculations since the first
large computer was wired together by hand. As mainframe computers grew,
the field of software engineering also grew, and much of the development
took place under government funding by NASA and the military. However, often these programming efforts were not managed as separate projects but as
subsets of large programs. It was not until early in the 1980s that the practice
of managing software development as a separate project began to mature
in private industry. This development occurred as commercial applications
grew in size and complexity.
For commercial applications, speed to market was the key to success and
shortcuts, especially in testing, were common. The term vaporware began
to appear as companies made promises about upcoming software to reduce
sales to competitors. Over the course of the 1980s and 1990s, software grew
increasingly large and complex, but speed to market remained the project
driver. The need to balance the scope of the project against the time to market and to do so without bankrupting the company created the perfect environment for project management.
In Practice: Evolution of IT Complexity
In August of 1984, Bill Gates started a project to create Windows for Word, version
1.0, with a completion date of September 1985. At the time, Microsoft was also
working on a version of Word for Apple computers that was released in July of
Projects and Operations 11
1985, so a project timeline of just over a year seemed reasonable. Yet WinWord
turned out to be such a complex endeavor that it was finally released in November
of 1989. Fifty-five man years of effort went into the development, a size that
previously was associated with larger, more traditional types of projects.
Since then, the industry has developed huge application packages that are used to
manage international corporations, packages that have many millions of lines of
code. Both the development of these packages and their implementation must be
managed as a project in order to have any possibility of success.
Challenges of IT Projects
Unlike the staff of traditional projects, where the team forms, develops, and
releases the product, then dissolves and never interacts with the product
again, IT people develop the product and, quite often, they maintain it after implementation (for internal IT projects) or fix problems that users identify. As a result, their time is split between daily operations and working on
projects. This almost always leads to problems in prioritizing the work and in
scheduling projects, since the availability of the resources is not known
Additionally, IT projects are usually much shorter in duration, with schedules
measured in weeks or months rather than in months or years (the keyword
is usually). IT projects have to share resources both with daily operations
and with other projects. Working on multiple projects is a fact of life in the
IT world, and being dedicated to a single project is a luxury for an IT project
manager. Because IT projects tend to be shorter in duration than other types
of projects, there is no ability to do traditional project team development.
Short timeframes and use of shared resources affect how IT projects are managed in a number of ways. Because daily operations have, or should have, priority, predicting exactly how much time each week is available for project work
is difficult. Because people are working on multiple efforts, there is measurable reduction in productivity as team members jump from one effort to another. The daily schedules of many people are often driven by whoever talked
to them last and asked when a particular project was going to be done.
Technology itself is a factor. Constantly increasing capabilities in both hardware and software pressure IT to incorporate the latest and greatest computer equipment.
12 Chapter 1
Do these problems have solutions? Yes. A strong project management culture
in the organization and a good project selection and prioritization process will
help tremendously. We will talk about these solutions in the next chapters.
Table 1-2 summarizes the differences between non-technical projects and IT
projects.
Figure 1-2. Differences between Non-Technical and IT Projects
Non-technical projects IT projects
Usually have a dedicated team.
Project team is shared with other projects and
with daily operations.
Are months and sometimes years long.
Are usually weeks long and occasionally
months long, rarely years long.
Include team development.
Do not have enough time to do team
development.
Have a well-defined priority.
Have multiple priorities that often change.
Technological risk is often constant during the course of the project.
Technological risk is different across different
projects.
Team members work on predefined tasks in one project.
Team members must multitask across
different projects as well as with daily
operations.
The Value of IT Project Management
Now that we have shown how projects are different from operations and
how IT project management is different from non-technical project management, let’s look at the value that IT project management provides to organizations. The Center for Business Practices does research and benchmarking
and provides publications on project management and business practices.
It performed a study with
senior IT project management practitioners and
found that using project
management
practices
• What is the most challenging aspect of
produced superior results
IT projects, as opposed to non-technical
compared to not using
projects?
formalized project man• What is the most exciting aspect of IT
agement practices.6 The
projects, as opposed to non-technical
results were particularly
projects?
compelling in the areas
What Do You Think?
Projects and Operations 13
of time to market, customer satisfaction, alignment to strategic goals, and
meeting time, budget, and quality objectives.
In fact, 97.7 percent of the organizations surveyed said that implementing
project management has added value to their IT organization. (Visit www.
cbponline.com for more information.)
Earlier in this chapter, we mentioned the CHAOS Report from 1995. A more
recent version shows that from 1995 to 2001, cost overruns decreased from
189 percent to 45 percent. Time overruns decreased from 222 percent to 63
percent.(For more information on the CHAOS Report, visit www.standishgroup.com.)
There are many reasons for this improvement. The most prominent are:
• Projects are smaller in scope.
• Projects are broken into discrete phases that are managed as separate projects, allowing subsequent phases to learn from previous ones.
• Better tools exist to estimate, monitor, and control project work. These allow better estimates upfront and allow project managers to detect baseline
variations while there is still time to correct them.
• Having skilled project managers and better project management processes
can significantly improve project success rates.
Chapter Summary
• Projects are one-time unique endeavors with defined starts and finishes.
They are customer focused, have project managers with varying levels of
authority, and use a temporary project team. Projects have scope, time, and
cost constraints, and scope may evolve as the work is elaborated. Projects
may be complex, involve outside stakeholders, and generally have more risk
than operations.
• Operations are ongoing, standardized, and repetitive. The focus is on the
goals of the department. Operations have a functional manager with full
authority over permanent dedicated staff. Departments have established
objectives, and constraints have been factored into the processes. Most risks
have been accommodated or eliminated over time.
14 Chapter 1
• A successful project is one that meets the triple constraints of scope, schedule, and cost. However, to be a success the project must be a strategic
success, meeting the needs it was undertaken to address. Also, the team
members should be satisfied with working on the project.
• IT projects are different from non-technical projects because the IT project
team is usually working on several projects at one time as well as maintaining operations. The time span is shorter and priorities tend to shift. In
technical projects, the technology itself is often a risk, and the risk on each
project is different. Projects are shorter in duration, and there is no time for
team development.
• Studies have shown that the use of project management increases customer
satisfaction, quality, time and cost performance, alignment with strategic
goals, and time to market. Significant improvements in project success have
been made over the past ten years due to smaller projects; improvement
in estimating, monitoring, and controlling processes; and improvement in
project management skills and processes.
Key Terms
Project
Program
Project management
Project Portfolio
Key Term Quiz
Use terms from the key terms list to complete the sentences that follow.
Don’t use the same term more than once.
1. A ____________ is a temporary endeavor undertaken to produce a
unique product, service, or result.
2. A _____________ is group of related projects managed in a coordinated
way to obtain benefits and control not available from managing them
individually.
Projects and Operations 15
3. The application of knowledge, skills, tools, and techniques to project
activities to meet the project requirements is known as ________________
____________.
4. The term for a collection of projects and/or programs and other work
grouped together to facilitate effective management of that work to
meet strategic business objectives is _____________________.
Review Questions
1. What three constraints do projects have?
2. Do project managers have full authority over the resources on their
projects?
3. List three components that make projects different from regular
operations.
4. What makes a project successful?
5. Compare projects, programs, and portfolios
6. Describe three differences between IT projects and non-technical
projects.
7. Studies have shown that using project management practices brings
about improvement in many areas. Which five areas showed the most
improvement according to the Center for Business Practices?
8. Which of the following is an example of a project?
a. Month-end closing of the books
b. Producing 1,000 widgets
c. Shutting down production for retooling
d. Researching a new product on the market
16 Chapter 1
9. An IT applications director can categorize the projects in his or her
shop as maintenance, new technology, upgrades and new releases,
and business support. There may be many separate projects in each of
these categories at any given time. However, each category is managed
collectively in order to balance resources and smooth the schedule. This
is an example of:
a. Schedule-constrained allocation
b. A portfolio of projects
c. A superorganized director
d. Project management
End notes
1. Project Management Institute (PMI®), A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 3d ed., Project Management Institute, Newtown Square, PA, 2004.
2. The Standish Group, “The CHAOS Report,” available at www. standishgroup.com, 1994.
3. Project Management Institute (PMI®), A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 3d ed., page 5, Project Management Institute, Newtown Square, PA,
2004.
4. Renee Ferguson, “HP Still Working Out Compaq Kinks,” eWeek Magazine, August 30, 2004.
5. Center for Business Practices, “Value of Project Management in IT Organizations,” available
at www.cbponline.com, 2001.
2
Organizational
Structure and the
Strategic Role of
Project Management
After reading this chapter, you will be able to:
• Explain various corporate structures.
• Describe types of project offices.
• Define strategic management and key strategic terms.
• Describe how projects originate.
In Chapter 1, we developed some working definitions of operations, projects,
and project management. We also looked at how IT project management differs from non-technical project management. In this chapter, we look at how
organizations are structured, where project management fits in an organization, different types of project offices, and how projects can help organizations meet their strategic goals and objectives.
Company Organizational Structures
The way an organization is organized and the reporting structure it adopts
significantly affect the way projects are done and the authority that a project manager has. We are going to look at three basic types of organizational
structures: functional, project driven, and matrix. We will also explore some
of the varying ways that organizations combine them and move along the
continuum of the matrix-type environment. We will look at the role of the
project manager and some of the pros and cons associated with each type of
environment.
18 Chapter 2
Functional
A functional environment is what we consider the traditional organizational
structure. In a functional environment, various departments perform functions to support the company as a whole in meeting its objectives. Figure 2-1
shows a functional organization.
Figure 2-1. Functional Organization Structure
Executive
Level
Mechanical
Engineering
Manager
Software
Engineering
Manager
Electrical
Engineering
Manager
Project
Coordination
Manufacturing
Manager
Functional
Manager X
Staff
Staff
Staff
Staff
Staff
Staff
Staff
Staff
Staff
Staff
Staff
Staff
Staff
Staff
Staff
Staff
Staff
Staff
Staff
Staff
Note:
Shaded boxes represent staff engaged in project activities.
The advantage of a functional organization structure is that people with specific skill sets sit and work together and can support each other. The manager,
whose responsibility it is to see that all work within the functional area is successfully accomplished, allocates their work. From an organizational standpoint, this is a very effective way to keep resources fully utilized.
In a true functional organization, there is often little coordination between
functions. When there is a project or a new product to develop that involves
more than one functional area, it takes longer to produce because there is
little integration. A lack of integration results in miscommunication, rework,
and not meeting the customer needs.
Here’s a common scenario: The sales manager approaches the production department and tells it about a new product the market is demanding. Production
Organizational Structure and the Strategic Role of Project Management 19
relays the information to engineering. Given enough time, engineering designs
a product that is both elegant and somewhat similar to what sales requested.
Engineering turns over the design specs to manufacturing to produce. The line
manager looks at the drawings and realizes that the production floor is not set
up to produce this type of product. Manufacturing sends the drawings back
to engineering for modifications. The drawings go back and forth for a while.
Finally, production gets something usable and produces a large quantity of the
product. Production proudly announces to sales that it has something that will
delight the customer. The sales manager takes one look and states, “That is not
at all what I asked for, and I can’t sell it.” You can see that in this type of environment no one is taking ownership of the timeliness, scope, cost, or ultimate
success of the new product. There is a lack of coordination and communication across functional areas, and ultimately the needs of the customers (both
internal and external customers) are not met.
Project Driven
On the other side of the spectrum is a project-driven organization. Virtually
all work is accomplished by projects. This structure is common in aerospace
companies, construction firms, engineering organizations, and consulting
firms. In this structure, staff members are assigned to a specific project that
they work on full-time through completion. There are some infrastructure
departments, such as the legal and finance departments, that are not assigned to specific projects, but most of the employees are project oriented. In
this situation, the project manager has full accountability for the success of
the project. Figure 2-2 shows a project-driven organization.
Typical difficulties with project-driven organizations are that highly skilled
and highly paid resources may be on a project whether needed now or not.
The usual approach for a project manager in such an environment is to bring
on the resources even if they are not utilized for several months in order to
ensure that they are available when needed. Although this makes managing
projects much simpler, it is an inefficient use of resources.
20 Chapter 2
Figure 2-2. Project-Driven Organization Structure
Higher Level
Management*
Project
Manager
Project
Manager
Project
Manager
Project
Manager
Staff
Staff
Staff
Staff
Staff
Staff
Staff
Staff
Staff
Staff
Staff
Staff
Staff
Staff
Staff
Staff
*Higher level management can be the VP of Development, the PMO, or any
senior manager who has overall responsibility for projects in the organization
Matrix
A matrix environment is a blend of both functional and project-driven approaches. This usually means that there is a function in the organization
called Project Management that manages projects using members from various functional areas. A matrix environment could also take the form of several functional areas having project managers on their staff to manage small- to
medium-size projects. Figure 2-3 shows a matrix organization.
* NOTE
Sometimes a special project office is created on a temporary basis
to manage a particularly large or strategic project, such as an ERP
implementation or an acquisition. We will look at project offices in
more detail in the next section of this chapter.
The matrix model evolved from the functional model in response to the need
for faster implementation, better coordination among departments, and the
need to satisfy customer requirements. In this model, the project manager
is responsible for the successful implementation of the project. In some organizations, the project manager has staff and/or budget management. In
some companies, the team members are temporarily moved to the project
site, and they may not see their functional manager for as long as they are
Organizational Structure and the Strategic Role of Project Management 21
Figure 2-3. Matrix Organization Structure
Executive
Level
Mechanical
Engineering
Manager
Software
Engineering
Manager
Electrical
Engineering
Manager
Manufacturing
Manager
Manager of
Project
Managers
Staff
Staff
Staff
Staff
Staff
Staff
Staff
Staff
Project Manager
Staff
Staff
Staff
Staff
Project Manager
Staff
Staff
Staff
Staff
Project Manager
on the project. In other matrix situations, staff remain physically located in
their functional areas and maintain some functional responsibilities. They
may work on one project or several projects, depending on the organization
and the size of the projects.
This organizational model presents some unique challenges. There may be
conflict over scarce resources, such as when one person is on multiple projects. In addition, team members may feel like they have two bosses: their
functional manager and their project manager. Moreover, even though team
members pick up extra work on projects, their functional responsibilities
rarely decrease significantly, which results in working longer hours.
Imagine that you’re working on three projects and also have responsibility for
supporting and maintaining a specific application. Project A has a major project review in three days and you have responsibility for a major piece of the
presentation. Senior management will be reviewing the status of the project
and making a recommendation on whether to continue or cancel it. You are
also working on project B and have a deliverable due in five days. If you don’t
get it done, the rest of the project team will be waiting on you before they can
move forward. Then your application goes awry, and you have 20 voicemails
complaining that people’s data is corrupted because of your application. Your
manager is asking you what you plan to do about the situation. This type of
conflict can occur in a matrix environment, where you have accountability to
one or more projects and still report to your normal manager.
22 Chapter 2
Sometimes matrix environments are referred to with a modifier, such as a
weak matrix, a strong matrix, a tight matrix, a balanced matrix, or a composite
matrix.
Generally, a weak matrix refers to an environment where the project manager is more of a project coordinator, with little decision-making power or
control over the resources. Most of the power resides with the functional departments.
In a balanced matrix, the project manager will have true project management responsibilities, though he or she will most likely not have full-time
staff on the projects. The project manager may have decision-making and
budgetary responsibilities for the project. In real life, there is almost never a
true balanced matrix: either the functional manager or the project manager
will have primary control, depending on the organizational culture.
A strong matrix means that the balance of power tends to lean towards the
project manager. He or she has full authority over project resources. It is more
common to see program managers and project offices in this environment.
A tight matrix refers to a project team that is collocated, meaning the team is
housed together for the duration of the project. Sometimes a strong matrix is
also a tight matrix.
Lastly, a composite matrix is when an organization may have a mixture of the various organizational structures, depending on the project or
department.
Often, whether a company has a strong matrix or a weak matrix depends on
who you ask. Senior management may state that they have a strong matrix
organization, but project managers may tell you that the reality is that the
structure is a weak matrix, with functional managers pulling resources from
projects as needed, sometimes without notifying the project managers.
Project Management Offices
In organizations that have a matrix or project-driven structure, you may
see something called a project office (PO), or a project management office
(PMO). These two terms are used interchangeably. PMOs trace their history
back to the earliest days of modern project management. When project man-
Organizational Structure and the Strategic Role of Project Management 23
agement was just used for large, complex programs, the most effective way
to manage the effort was to establish a central office to support the program
manager with schedule management, financial tracking, and other administrative functions. In the past several years, POs have reappeared and taken on
several different forms, functions, and structures. Before we look at the different types of PMOs, let’s take a look at their recent background and evolution.
Background
During the late 1990s, when companies were performing assessments on how
to update all their applications to move to the new millennium-numbering
scheme of 2000 (Y2K) and undertaking activities to mitigate risks associated
with Y2K, they discovered that establishing a central office to manage all of
these projects was a good idea.
Although the PMOs established for Y2K have disappeared, many companies
are now reestablishing PMOs to manage all of the projects they have in the
works. Unfortunately, some executives mistakenly thought that just having
a PMO would make all their projects run smoothly, so organizations spent
hundreds of thousands of dollars to create them. Consulting companies were
happy to sell a “PMO in a box”—just install their software and, voila, you had
a PMO. Companies would put in policies, mentoring programs, and centers
of excellence to do projects better, faster, and cheaper. Then, after about six
months, when they did not see an immediate and amazing impact to the bottom line, they declared the PMO a failure and went back to business as usual.
In fact, there are several types of PMOs and the variations are as many as
there are organizations that adopt PMOs. In the next section, we will look at
some of the general types of PMOs and then we will talk briefly about some
of the requirements needed to help make them successful.
Types of Project Management Offices
As mentioned earlier, the structure of a PMO is dependent on the organization that it operates within. Some offices are narrowly focused to meet one of
the objectives below, and others are a blend. There is no right structure for a
PMO; the best structure truly depends on the needs and culture of the organization. Below are five models that are common.
24 Chapter 2
In Practice: PMOs in the Real World
The July 2, 2003, edition of CIO Magazine published a survey of 303 companies
that have PMOs. Here are some of the results:
What do PMOs do?
• 43% of the respondents said their PMO is a support organization that supports
multiple projects, primarily with administrative, time tracking, reporting, and
other services.
• 12% of the respondents said the PMO is a project services organization managing
several unrelated projects.
• Another 12% said their PMO manages a set of projects that are related.
• 5% reported that their PMO is responsible for business and technical management
of a specific contract or program only.
Companies are finding that employing key practices like providing standard
methodologies and linking projects to company strategy are helping the
organization meet financial and strategic goals. 50% say that project success rates
have increased as a result of having a PMO, on average by 46%.
Overall, the benefits are:
• 62% said implementing PM standards.
• 38% said increased internal customer satisfaction.
• 29% said increased employee productivity.
• 27% said lower costs.
• 25% said increased external customer satisfaction.
Center of Excellence Project Management Office
A center of excellence PMO is used for mentoring, training, and providing
advice for project managers and other employees who find themselves managing a project. Some centers of excellence provide a project management–
training curriculum for the organization. They may have certificate programs
or provide project management basics for a wide audience.
Other centers of excellence have accomplished project managers who mentor new project managers on large and complex projects. They may help departments that don’t normally have projects and find themselves needing to
complete a project. They can provide on-the-job training, tools, or just be
available in a pinch.
Organizational Structure and the Strategic Role of Project Management 25
Another service these offices provide is giving expert advice. This may be advice on working with project software, developing a risk management plan,
developing an estimate, or managing scope creep. Again, this can be offered
at all levels of the organization. Generally, these types of offices are seen in a
matrix or project-driven environment.
Administrative Project Management Office
An administrative PMO maintains the policies, procedures, processes, and
forms that the organization uses to manage projects. This type of office may
define categories of projects. Administrative POs may develop best practices
that define the level of management required depending on the size, complexity, duration, or risk involved in the project. Frequently, this type of office serves as a repository for best practices, lessons learned, and knowledge
management surrounding projects.
The administrative PO develops, revises, and keeps all policies and procedures regarding project management up-to-date. It also defines the processes
and forms that should be used. The office will update and distribute forms as
they are developed, changed, or become obsolete. This type of office is seen
in a matrix-type environment or a project-driven environment.
Business Unit of Project Managers
Often this functional unit houses all project managers and project-related
employees. It may house professional schedulers, estimators, and program
managers as well as other project support personnel. The head of this unit
will assign projects, track their progress, give advice and coaching to project
managers, and provide administrative oversight.
This type of office collocates all project managers, which allows for mentoring among project managers, sharing of best practices, and professional
development. Generally, all the project templates, forms, and records reside
here as well. These types of PMOs are seen in a matrix environment.
Strategic Project Management Office
A strategic project management office is used to manage the organization’s
portfolio of projects. It is usually at the executive level and may be overseen
by a chief project officer or a vice president of project management. The primary function of this type of office is to define the types of categories in the
project portfolio, define the percentage of projects in each, allocate resources
26 Chapter 2
at a high level, and ensure that the portfolio is balanced per the direction of
the organization. Often this office will review the initial business case or costbenefit analysis for projects. This type of PMO is most often seen in organizations that are mature in project management. Organizations with this type of
office will most likely be project driven or have a strong matrix environment.
Project-Specific Project Management Offices
A project-specific PMO may be opened in response to a large project. Perhaps
an IT organization is looking to implement an ERP system, or an acquisition
necessitates a PMO throughout the acquisition process. In these instances,
the program manager, the project manager, and the key team members are
collocated in an office. The functions of the PMO are to support the program
manager in managing schedule and budget, managing the change control
process and the risk management process, ensuring program quality, and
performing other required functions. The PMO facilitates information sharing, decision-making, and expeditious handoffs. When the project is complete, staff return to their functional areas.
Organizational Location of Project
Management Offices
PMOs can be line organizations or support organizations. In a line organization, the PMO has direct authority over the projects. All of the project managers report into the PMO as a functional department. It is the central location
for all project activity in the business unit or the enterprise. A sample structure of a line organization is shown in Figure 2-4.
Figure 2-4. PMO in a Line Organization
VP Product Development
PMO
Project A
Project B
Project C
Organizational Structure and the Strategic Role of Project Management 27
In a support organization, the PMO does not have direct authority over projects or project managers. It is purely a support organization to the project
managers and to upper management. The project managers often report into
other departments, and the PMO is there to centralize administrative work
and perform other support functions. Figure 2-5 shows a representative organizational chart.
Figure 2-5. PMO in a Support Organization
VP Product Development
PMO
Project A
Project B
Project C
In both cases, the higher up the PMO reports, the more authority it has and
the better it will work. Many project managers will resent having a PMO if
they are not used to one. Rather than seeing the office as helpful, they often
feel like it should be labeled the project police. Unfortunately, some PMOs
behave like that, feeling that their job is to whip errant project managers back
into line. However, a truly effective PMO is supportive to both the project
managers and to the executives in the organization.
The best location for a PMO is wherever it will most effectively support the
organization. Some PMOs have started as support organizations, and as their
benefits have become clear, have become line organizations.
Criteria for Successful Project Offices
So, what is the best kind of PMO? It depends on the needs and level of project
maturity of the organization. Paramount to success is to have clearly defined
objectives for the PMO. Executive management must understand what it
wants from the PMO. These expectations need to be written down in a charter format, with clear, measurable results attached to a timeline. That being
said, the results and timeline should be reasonable and attainable.
28 Chapter 2
It is not reasonable to expect a PMO to develop
policies, procedures, and
• What type of organizational structure
processes, and to train the
would best help you perform your job:
entire organization to use
Functional? Matrix? Project driven?
them, along with men• What type of PMO would work best in
toring project managers
to produce stellar results
your organization?
on all projects, within six
• What PMO location would best help you
months or a year. The two
perform your job?
main reasons that PMOs
fail are the objectives are not clearly defined upfront, and therefore there is
no criteria or roadmap for success, and the PMO is not given enough time
to integrate into the organization’s structure. It generally takes two to three
years to start a PMO and see tangible results. The exception is the project
specific office, of course.
What Do You Think?
An organization that is new to project management principles should operate within a matrix-type environment for a few years before taking on a PMO.
It takes a certain amount of project management maturity and savvy to start
and operate a PMO successfully. A brand-new organization, with no existing
culture to have to change, should create a PMO and establish it as part of the
organization at the very beginning.
A PMO can be a very expensive in terms of personnel. It can be hard to justify the creation of one, because many of its benefits are intangible and nonquantifiable. Some examples of failed PMOs include:
• A major health insurance provider attempted to create a PMO but failed
because each project manager was used to doing things his or her own way
and resisted having to subordinate a pet project to a central office.
• The PMO at the U.S. corporate headquarters of a major Japanese car manufacturer failed because the person put in charge didn’t want to take expert
advice and wanted to do things his way.
To create a successful PMO, it would be wise to spend several months planning and discussing the scope of the PMO before plunging in. A two- to threeyear commitment also takes a significant budget. Therefore, the organization needs to be clear on its objectives and the person in charge of the office
needs to do a good job of managing expectations from day one. Otherwise,
the chance for success is significantly diminished.
Organizational Structure and the Strategic Role of Project Management 29
Overview of Strategic Management
Now that we have discussed organizational structure and how project management fits within that structure, we will look at the importance of projects
in organizations. At the highest levels of the organization, executives are concerned with strategy. To understand how projects contribute to strategy we
first need to develop a common understanding of strategic management.
The definition of strategic management found on Wikipedia states that it is
“the process of specifying an organization’s objectives, developing policies
and plans to achieve these objectives, and allocating resources so as to implement the plans.”1 Strategic management provides overall direction to the
whole enterprise. An organization’s strategy must be appropriate for its resources, circumstances, and objectives. The process involves matching the
company’s strategic advantages to the business environment the organization faces. A good corporate strategy should integrate an organization’s goals,
policies, and action sequences (tactics) into a cohesive whole, and must be
based on business realities. Strategy must connect with vision, purpose, and
likely future trends.
Key Strategic Terms
To discuss strategy, we first need to define some of the key terms used in
strategic planning. Then we will show examples from some organizations of
which you may have heard.
• Mission: The reason the organization exists. The mission describes the
products or services the organization provides, the markets it serves, and,
if relevant, the competitive advantage or the technology the company employs to provide the products and services. The mission may also address
how the company serves various stakeholders, such as investors, employees, and customers.
• Vision: Aspirations for the future; a desired future state. The vision statement answers the question, what do we want to become?
* NOTE
A vision should be inspiring. Consider Steve Jobs’ vision to build an
“insanely great” computer. Employees working on the first Macintosh computers surpassed what they thought was possible, in large
part due to their commitment to their shared vision.
30 Chapter 2
• Values: How a company treats its employees, how it treats its shareholders, how it behaves as a neighbor, and how it behaves with respect to its
environment. Values describe what is important to it as a corporate entity.
Values are used to help organizations make decisions and choices.
• Goals: Directions that the organization wants to head in to improve performance. These are generally qualitative in nature. They may address financial and nonfinancial measures.
• Objectives: Specific targets to be accomplished within a specified period.
An organization may have one-year, three-year, and five-year objectives.
• Strategy: A general program of action. Strategic plans cover three to five
years into the future. Strategies are broken down into more detailed objectives, which are then further broken down into quarterly action plans or
tactics.
In thinking about these concepts, it’s useful to imagine a pyramid, as shown
in Figure 2-6, with strategies leading all the way up to vision.
Figure 2-6. Strategic Plan Hierarchy
Mission
Va
lu
es
Goals
Objectives
Strategies
Vision
Organizational Structure and the Strategic Role of Project Management 31
In Practice: Corporate Strategy
Below are some examples from various companies. We found these on the web,
so they are only as up to date as the organization’s web site was on the date we
looked. They should give you a flavor of strategic statements.
Sample Vision Statement
Sun Microsystems
Everything with a digital, electrical or biological heartbeat will be connected
to the Network. With Auto ID-like technologies, assets of value will also be
connected. This will create profound potential and challenges for enterprises,
service providers and consumers. Technology, habits and governance will evolve
and adapt to this new connected reality.
Sample Mission Statements
IBM
At IBM, we strive to lead in the creation, development and manufacture of
the industry’s most advanced information technologies, including computer
systems, software, networking systems, storage devices and microelectronics.
We translate these advanced technologies into value for our customers through
our professional solutions and services businesses worldwide.
Microsoft
To enable people and businesses throughout the world to realize their full
potential.
Intel
Do a great job for our customers, employees and stockholders by being the
preeminent building block supplier to the worldwide Internet economy.
PepsiCo
Beat Coke.
Sample Values
PMI
Knowledge
Professionalism
Community and Volunteerism
Value of Project Management to Business
32 Chapter 2
Intel
Customer Orientation
Results Orientation
Risk Taking
Great Place to Work
Quality
Discipline
Sample Goals
Goals are generally proprietary information, and thus they are not widely available
to the public. Goals generally have to do with reducing costs or increasing
revenue.
An example of cost reduction might be increasing employee efficiency through
internal process improvement. This might translate into large projects such as an
ERP implementation, consolidating legacy systems, or automating existing manual
processes.
Examples of increasing revenue could include mergers, acquisitions, product
development, and product line expansion. Almost all mergers and acquisitions
entail large IT projects as part of the overall project.
Sample Objectives
Intel
Extend silicon leadership
Deliver architectural innovation for convergence
Pursue opportunities worldwide
Using Projects to Meet Organizational Needs
So where do projects fit with strategic management? Everywhere! First and
foremost, every IT effort should be linked to one of the organization’s goals or
objectives. Most often, projects are used as the approach that organizations
use to meet their objectives. Some organizations consider project management to be a core competency—one of the key operations that differentiate
them in the marketplace. Because project management has proven to be
such an effective approach, management by project is often used for consult-
Organizational Structure and the Strategic Role of Project Management 33
ing firms, research and development companies, and software development
companies.
In addition to supporting a company’s mission, goals, and objectives, projects should be executed consistent with organizational values. If one of the
organization’s values is high quality, the project should have sufficient testing built in and use high-grade components to create the product. Using untrained labor because it is less expensive or refurbished parts would be inconsistent with the company’s values.
* NOTE
Because projects are used to meet an organization’s strategic plan, if
a project is not tied to an organizational goal or objective, it should
not exist. Too often, we hear of projects that do not have a direct
relationship (or even indirect relationship) with the annual goals
or objectives. These projects tend to wither on the vine from lack
of resources, since other projects take priority. In fact, they should
never have been chartered at all.
Categorizing Projects
Projects come from many different sources. To provide some semblance of
order it is useful to categorize both the ways that projects originate and the
types of projects that organizations undertake.
Where Do Projects Come From?
Projects generally originate from one of the following:
• Market demands: The market may demand that new Internet connection software come with spam detection capabilities built in. Therefore,
a project is created to retrofit all existing software with spam detection, to
include spam detection in all new software, and to create a free download
that past customers can access on the company web site.
• Business needs: The organization decides that it wants to expand its product line from cell phones to units that can perform cell phone/PDA/digital camera functions. This is a new product development project based on
business needs.
34 Chapter 2
• Customer requests: A client wants a customized software solution to capture all the hours that employees spend working on projects, tabulate the
hours by project, and then total them by department. The solution should
feed into both project management software and accounting system software.
• Technological advances: An underwriting system is two versions behind
the current release, and the company that manufactures the software is
going to discontinue support in 18 months. An organization will need to
upgrade its systems to keep up-to-date with the latest advances in the software. Another impact of technological advances is that they create opportunities for new products. For example, the ability to download music from
the Internet now exists. This has led to new projects in many companies,
as they create systems to allow consumers to download music legally and
block consumers from downloading it illegally.
• Legal requirements: The Health Insurance Portability and Accountability
Act of 1996 (HIPAA) requires that organizations limit access to personal
information. Healthcare companies need to create new levels of security
for all users to make sure that personal information is secure.
• Social needs: Perhaps one of a company’s values is to contribute to the
communities where it is located. The local school needs upgraded computer equipment. The company opens a project to do a needs assessment,
gather requirements, and propose a solution, which the company will help
meet with in-kind donations.
Selecting Projects
One of the most critical aspects of successful project management is selecting the right projects.
Good ideas can come from anyone in the company. Yet, a company that starts
too many projects quickly finds that it has more projects in the pipeline than
it can reasonably accomplish. Too many projects means that many, if not
most, will not get successfully completed on time and within budget, and
that the people working on them will be burned out and frustrated. Remember the definition of project success? Scope, time, and costs are met; stakeholder objectives are met; the strategic intent of the project is realized; and
the team members are satisfied. To accomplish this, world-class companies
have fewer, more strategically oriented, projects.
Organizational Structure and the Strategic Role of Project Management 35
To select the best projects, a company should encourage ideas from anyone
in the organization and then set up a project selection process that filters out
everything but the most beneficial projects. The final list is presented to a
project selection committee, which then makes the final project selection.
Types of Projects
Three types of projects a company typically performs are:
• Mandatory projects
• Infrastructure upgrades
• Discretionary projects
Mandatory Projects
These are usually the projects that originate because of a legal or regulatory
requirement. Typically, these regulatory changes come with a specific time
limit within which the company must comply.
Any company that deals with private financial information must comply with
both federal and state laws and regulations. Utility companies are regulated
at the state level by public utility commissions. The U.S. federal government
passed the Health Insurance Privacy and Portability Act (HIPPA) stating specific requirements for healthcare-related information. All hospitals, pharmacies, and health insurance companies had to comply with those changes.
Regulatory-driven projects are often called orange jumpsuit projects, because orange is a common color for jail uniforms, and the company’s executives will go to jail if they do not comply with the regulations.
Infrastructure Upgrades
These projects are generally the result of technological improvements that
can increase the efficiency of the organization. Infrastructure projects can be
very high priority, but are not necessarily time-driven projects. An example
would be a company upgrading its Windows 98 operating system to Windows
XP. This could be a significant project if there are thousands or tens of thousands of desktop machines to be upgraded, but it does not have to be completed by a specific date.
36 Chapter 2
Discretionary Projects
Discretionary projects are the result of a market demand, customer request,
business need, some technical advances, or social needs. While they are called
discretionary, that does not mean they are taken lightly. When a key customer
wants a new product or service, it is not usually seen as a request that you will
get around to when you have time. It is considered a high priority.
Internal process improvement projects are a special type of discretionary
project. They may incorporate infrastructure upgrades. They are usually very
complex because company processes often cross organizational boundaries,
so impacts are made to several parts of the organization. These projects require a lot of analysis and coordination.
Project Selection
These days organizations find themselves with more projects than they have
resources to complete. For many organizations, choosing projects is an informal process with various projects being started, delayed, discontinued, or
killed. This has been called the “project of the week” approach. It leads to too
many projects and projects that don’t meet their objectives and come in late,
over budget, and with a burned-out team. In other words, the projects tend
not to meet the success criteria we defined earlier.
Organizations that have developed a more mature approach align their project selection process with the strategic needs of the organization. A project
selection committee at the executive level of the organization defines the
project portfolio categories, optimal weighting for each category, and a project scoring method (such as return on investment or a cost/benefit analysis).
In this way, fewer projects are initiated, but those that are contribute to the
strategic intent of the organization.
A detailed description of establishing and managing a project portfolio is
outside the scope of this text. PMI has published a standard on project portfolio management and there are several other texts in the field that present a
defined project portfolio methodology.
Organizational Structure and the Strategic Role of Project Management 37
In Practice: Categorizing Projects
A recent article in CIO Magazine suggested that discretionary projects be broken
into the following categories:
• Category A projects are mission critical and provide a market advantage to the
company.
• Category B projects are mission critical, but do not provide a market advantage.
• Category C projects are not mission critical, but provide a market advantage.
• Category D projects are neither mission critical nor provide a market
advantage.
The article suggests that organizations should select all the Category A projects
they have the resources to perform. Next in priority are the Category B and C
projects, depending on the available resources. Ignore the Category D projects.
They are not important enough to spend resources on.
Look at the categories we talked about in the previous pages. Do you see a
correlation between mandatory, infrastructure, and discretionary projects and the
categories denoted by CIO Magazine?2
In Practice: Suggesting Projects
Toyota Financial Services USA developed an automated process (utilizing Lotus
Notes) for new project suggestion and approval developing. Anyone in the company
can log on and suggest a project. The requester identifies both what the benefits of
the project are and which of Toyota’s strategic goals the project supports. Toyota
has four strategic objectives that center around the areas of Financial, Internal
Processes, Customer Relationships, and Employees & Operations.
When the original requester fills out as much as he or she knows, the form is released
and routed to different groups to complete other parts of the form. Most of the
questions on the form are devoted to identifying specifically what the relationship
is to the strategic objectives and to identifying financial impacts of the project.
At the end of the approval process, each question is scored. The scores are added
up and the project is given an overall rating. Regulatory projects are given a very
high rating automatically (with the specific number dependent on the timeframe
for the project) to ensure they rank high in the final scoring. On a monthly basis,
the rank-ordered list of new projects is presented to the Strategic Governance
Committee, which selects the specific projects it feels need to be done.
38 Chapter 2
A further refinement of this process includes identifying each project’s overall risk.
This risk score becomes part of the selection process so that the project portfolio
can be ranked with respect to risk as well as strategic benefit.
How to Choose a Project?
With all of these possible projects floating around, how do you choose the
best projects to spend your time and resources on?
All potential projects are compared with all the others. Traditional approaches
include cost/benefit analyses (CBA) or return on investment (ROI) analyses.
Whatever method a company uses to select its projects, it needs to be done
in a careful and objective manner. Research indicates that the best projects to
choose are those that most support the strategic objectives of the company.
Identifying these projects requires setting up a project selection process that
provides the final decision-maker with the best information available. This is
generally done at the portfolio management level by organization executives.
Chapter Summary
• Companies have different organizational structures. The organizational structure affects the amount of authority a project manager has on a project. The
three types of organizational structure are functional, matrix, and projectdriven. A matrix environment may be a weak matrix, balanced matrix, or
a strong matrix. A collocated team is called a tight matrix. An organization
that mixes structures based on its needs has a composite organization.
• Some organizations have POs. There is no right kind of PO. Each organization should build a PO to meet its needs. Five of the more common types
of POs are center of excellence, administrative, strategic, business unit, and
project specific. POs can be line POs or support POs. To implement a successful PO requires time to understand the requirements, gather input from
stakeholders, and manage expectations, much like managing a project.
• Organizations use strategic planning to stay competitive in today’s environment. Some of the key aspects of strategic management include vision and
mission statements, values, goals, and objectives
Organizational Structure and the Strategic Role of Project Management 39
• Projects are one of the ways that organizations turn strategic plans into reality. All projects should tie into the strategic plan.
• Projects can come from six different sources: market demand, business
needs, customer requests, technological advances, legal requirements, and
social needs.
• Because there are usually more projects than there are resources, organizations need a project selection strategy. A selection strategy can break up the
projects into three categories: mandatory projects, infrastructure projects,
and discretionary projects.
Key Terms
Matrix organization
Administrative project office
Project-driven organization
Center of excellence project office
Functional organization
Tight matrix
Strategic project office
Balanced matrix
Vision
Weak matrix
Mission
Strong matrix
Values
Composite organization
Goals Project office
Objectives
Project management office
Strategy
Key Term Quiz
Use terms from the key terms list to complete the sentences that follow.
Don’t use the same term more than once. Not all terms will be used.
1. A matrix organization that has characteristics of a functional
organization, with the project manager’s role being more of an expediter
or coordinator, is called a _________________________.
2. A project office that manages an organization’s portfolio of projects is a
__________ project office.
40 Chapter 2
3. The ________________ defines the reason an organization exists.
4. A _______________ is an organizational structure that has various
structures, depending on the needs.
5. The ________________ is a set of intentions that are broad, forward
thinking, and all inclusive. It generally refers to a desired future state.
6. A project office that maintains the policies, procedures, processes, and
forms that the organization uses to manage projects is called a(n) ______
_________________.
7. A __________________ organizational structure has project managers that
have full authority over their project, including staff, budget, decisions,
and allocation or resources.
8. Which vocabulary term describes specific targets to accomplish within a
specified timeframe?
9. A ___________________ is any organization in which the project
managers share responsibility with the functional managers for assigning
priorities and for directing the work of persons assigned to the project
10. Which type of project office has accomplished project managers that
mentor new project managers or project managers on large and
complex projects?
Review Questions
1. In which type of organizational structure would the project manager
have the most amount of authority?
a. Strong matrix
b. Tight matrix
c. Functional
d. Balanced matrix
Organizational Structure and the Strategic Role of Project Management 41
2. In which type of organizational structure would the project manager
have the least amount of authority?
a. Strong matrix
b. Tight matrix
c. Functional
d. Balanced matrix
3. In which type of organizational structure are project team members most
likely to feel they have two bosses?
a. Composite
b. Matrix
c. Project-driven
d. Functional
4. Which type of project office is used predominately for mentoring,
training, and providing advice on projects and project management?
a. Administrative
b. Strategic
c. Business unit of project managers
d. Center of excellence
5. Which type of office is used predominately to develop and manage
processes, policies, and procedures?
a. Administrative
b. Strategic
c. Business unit of project managers
d. Center of excellence
6. Which of the following is a description of a mission statement?
a. Aspirations for the future
b. The reason the organization exists
c. An enduring preference for a mode of conduct
d. Specific targets to be accomplished within a specified timeframe
42 Chapter 2
7. When planning for implementation of a PMO, what should you include?
8. What is one of the pitfalls of project-driven organizations?
9. Describe the difference between objectives and goals.
10. All projects should be tied to an organization’s ­­­­­­­­­­­­­­________________.
11. What role do an organization’s values play?
12. Projects come from many different sources. Which of the following is an
example of a project that is required to meet legal requirements?
a. A virus detection software upgrade.
b. One of your customers, a municipality, has asked your organization to
install software that can detect attempts to hack into the system.
c. Sarbanes-Oxley requirements necessitate upgraded software.
d. Giving all directors PDAs.
13. Which of the following is an example of a project that is due to a
customer request?
a. A virus detection software upgrade.
b. One of your customers, a municipality, has asked your organization to
install software that can detect attempts to hack into the system.
c. Sarbanes-Oxley requirements necessitate upgraded software.
d. Giving all directors PDAs.
14. Considering the project priorities discussed in the chapter, which of the
following is the right sequence of priority for these projects:
a. 1) Developing a new product 2) upgrading your computer operating
system 3) complying with a new state law that requires your company
to report quarterly its income sources
b. 1) Improving your own internal processes 2) developing a new
product that marketing has asked for 3) complying with a new
regulation from the SEC requiring a list of your shareholders
Organizational Structure and the Strategic Role of Project Management 43
c. 1) Complying with a new state regulation that requires your company
to upgrade your security software 2) completing an upgrade to a
financial package that your CFO needs 3) making an improvement to
an internal process
d. 1) Creating a new product that will increase your company visibility
but provide no additional income 2) completing an upgrade from MS
Office 2000 to Office 2003 3) installing a new software package that
makes it easier to do financial reports
15. Why do projects have to be prioritized?
a. Because there are limited resources to do all of them
b. Because only marketing should be able to choose which projects to do
c. Because all projects should be the Number 1 priority
d. Because the CEO said to
End note:
1. Wikipedia, The Free Encyclopedia, accessed 6-23-06.
2. Lafe Low. “First Things First.” CIO Magazine, March 15, 2004.
3
Project Processes,
Phases, and
Life Cycles
After reading this chapter, you will be able to:
• Understand what the appropriate processes are for an IT project.
• Be able to define the project phases for an IT project.
• Discuss different types of project life cycles.
When you are first given a project, it can seem a little overwhelming. There’s
an old saying in project management: “How do you eat an elephant? One bite
at a time.” In project management, we divide the project into phases and
concentrate on managing each phase. Each phase is composed of a set of
processes that guide us in starting the phase, planning it out, monitoring and
managing it, and closing it out to move onto the next phase. The full set of all
the phases on the project is called the project life cycle.
Not every project requires the same amount of project management, and
every project will have different needs for documentation, planning, and
control. It is the responsibility of the project manager to identify how to successfully complete his or her particular project in the most efficient manner
by selecting the right combination of processes, tools, and techniques. This
chapter will address project management processes and various life cycles
for IT projects.
The programmer may think, “Why should we go through all this? We know
what to do. We don’t need this bureaucracy. Let’s just start working and the
code will come out all right.” Watts Humphrey, in his seminal work Managing the Software Process, said: “The software graveyard is strewn with the carcasses of partially completed projects that were three to five times larger than
anyone dreamed. No responsible builder would contract for a house without
reviewing the plans and specs.”1
46 Chapter 3
Project Management Processes
A process is a series of activities that takes an input and brings about a result
or output. Why use processes to manage a project? Why not just jump in and
start working? Shouldn’t we just know what to do?
Processes guide us step-by-step in what we have to do during our project. But
processes don’t guide just one project. Processes ensure that all projects we
do are performed consistently, time after time. By applying the appropriate
project management processes—not too many, not too few, and appropriate
to the type of project being done—the team will have a much higher rate of
success. Jumping in and starting the work causes many projects to fail because the project manager and the team are not necessarily doing the right
things. They are just doing whatever makes sense at the moment. Project processes define the project management activities that are carried out during
the project.
According to the PMBOK® Guide, 3rd Edition, Chapter 3, there are five project management process groups used to manage a project—initiating processes, planning processes, executing processes, controlling processes, and
closing processes. They can be viewed as shown in Figure 3-1.
Figure 3-1. The Five Project Management Processes
Initiating
Monitoring &
Controlling
Replanning
Planning
Executing
Closing
Feedback
These processes are followed from the very beginning of a project until it is
closed out. But more than that, these processes are used for each phase within the project as well. The team initiates a phase, plans how to accomplish the
work, executes and controls the work, and finally closes out the phase and
moves into the next phase.
These processes are not performed in isolation. They interact with each other, as shown in Figure 3-1.
Project Processes, Phases, and Life Cycles 47
Initiating Processes
Initiating processes are used to start up the project or the phase. Initiating
the project can consist of things like developing the business case, getting approval to start, getting the team together, writing the initial documentation,
and so on.
Initiating a phase may consist of reviewing lessons learned from the last
phase so as not to repeat mistakes, initiating new team members, and having
a kickoff meeting for the phase.
Planning Processes
Planning processes are processes used to think through and plan out what has
to happen in the project or the phase. How many people are needed? What
skill sets are necessary? How long will it take? How much money will it cost?
What risks might happen? The planning process is iterative in nature and occurs throughout the project as it progresses. As information about the project
is more clearly defined through the planning process, the team will go back
and update information, which in turn can cause other information to change.
In planning, the team is essentially attempting to influence the outcome of the
project. Though even the best laid plans can’t guarantee a successful project,
lack of planning can certainly increase the chances of failure.
During the execution and control processes the team may find that it needs
to come back and replan if things don’t go according to the original plan, and
they almost never do. A guiding principle is “Plan well, but don’t get attached
to the plan. It will change.”
The start of a new phase is a good time to replan, since information gained
from the previous phase can be used to better plan the current phase. For example, more information may be known about potential project risks, or the
project manager may have learned from experience how to improve duration
estimates for some activities. On large projects, a concept called rolling wave
planning is used. That is where the near-term work is planned out in detail
and the far-term work is left at a high level. Establishing the detailed planning
at the start of a project phase is an example of rolling wave planning.
48 Chapter 3
Executing Processes
Executing processes are those where the actual work to produce the product is performed. This is where the project team involvement is heaviest.
Indeed, this is typically where most of the resources are involved and the
costs of the project are rising most rapidly. Typical project management activities include status meetings, stakeholder management, issue resolution,
and lots of communication!
Controlling Processes
Throughout the project, the project manager uses controlling processes to
monitor and manage the work. This set of processes includes collecting status
information, comparing it to plan, and making adjustments as needed. It is the
information gained in the controlling processes that may cause replanning.
Closing Processes
Finally, the closing processes are those used to complete all the documentation, deliver the product to the customer or put it into the production environment, close out contracts, conduct a lessons learned session, and so on.
Whether closing out a phase or a project, the closing processes are the same.
It is the scope of activities that is different.
* NOTE
In the PRINCE2 methodology that was designed specifically for IT
projects, the project processes look like this:
Directing a Project
Starting up
a Project
Initiating
a Project
Controlling
a Stage
Managing
Product
Delivery
Planning
Managing
Stage
Boundaries
Closing
the Project
Project Processes, Phases, and Life Cycles 49
Just as in the PMI framework, there are activities associated with the
processes shown in the figure. In PRINCE2, these activities include
the business case, change and configuration control, quality, risk
management, controlling the project, project management plans,
and project roles and responsibilities.
In Practice: CMM and CMMI
Some of the processes we use in IT project management can get very sophisticated.
A good example is the Capability Maturity Model (CMM) developed by the
Software Engineering Institute (SEI). Watts Humphrey’s book, mentioned earlier in
this chapter, was the starting point for this effort. The CMM was developed during
the early 1990s as a five-level model to measure the maturity of the software project
management approach. Each level has a specific set of processes associated with it
that will improve the ability of the company to successfully deliver projects. Research
has shown that for every level an organization moves up in the model, it has a 15%
improvement in productivity. In the past four years SEI has stopped supporting
the CMM model and has moved to the CMMI (CMM Integrated) model, which
incorporates processes beyond pure software project management.
Project Phases
The project processes we just discussed are used in each phase of the project. A phase is a segment of the project that occurs in a sequential order. At
the completion of all of the phases, the project will be complete. There are
multiple possible phases that can be used, depending on the type of project,
the industry segment, and the organization. Typical phases used in the construction industry are very different from those used by a major aerospace
contractor or by a pharmaceutical development company. In general, almost
all IT projects follow some variation of these basic phases: planning, requirements, architecture/design, development or construction, test and integration, and implementation.
For example, typical phases for a software project would be:
• Project planning
• Requirements analysis
• Architecture and preliminary design
50 Chapter 3
• Design and coding
• Test and integration
• Implementation
John J. Rakos, in his 1990 book Software Project Management for Small to Medium Sized Projects, recommends the following phases for software projects:2
• Definition
• Analysis
• Design
• Programming
• System test
• Acceptance
• Operations
Regardless of the industry, each phase requires inputs before it can be started,
each phase has a set of activities unique to that phase, and each phase produces deliverables. These deliverables are often the inputs to the following
phase. Figure 3-2 shows typical phases for an IT department’s projects.
The conclusion of each phase is marked as a milestone, i.e. the completion of
a significant event, on your schedule. At these end-of-phase milestones you
should have phase end review meetings, which are sometimes referred to as
stage gates. At these meetings you:
• Review how the work went during the previous phase.
• Assess what could have been done better and what went well.
• Make a go/no-go decision to move to the next phase.
These phase-end reviews are management control points where management decides whether the project should continue or not.
* NOTE
A milestone marks the end of something significant in the project.
You can have milestones that are not associated with the end of a
phase. For example, for a complex LAN development effort, the ap-
Project Processes, Phases, and Life Cycles 51
proval of the requirements document might be significant enough
that it can be considered a milestone. Having several milestones
within each phase of the project is not uncommon.
Remember that for each phase, we use each of the process groups. We plan
out the phase, we initiate it, we monitor and control it as it is being executed,
and finally we close out the phase and move on to the next phase.
Figure 3-2. Sample Phases and Activities
Project
Initiation
Inputs
• Project Charter
Activities
• Write the
Statement of Work
• Write the Scope
Statement
Deliverables
• SOW
Milestone
• Post Phase Review
• Approval to go
into Planning
Phase
Requirements
and Planning
Inputs
• Project Charter
• SOW
Activities
• Generate requirements
• Generate the Work
Breakdown Structure (WBS)
• Determine Roles &
Responsibilities
• Define task dependencies
• Develop the schedule
• Define critical path
• Schedule resources
• Generate project budget
• Develop management
plans
Deliverables
• Requirements spec
• WBS
• Responsibility assignment
matrix (RAM)
• Project schedule
• Project budget
• Baselined mgmt plans
Executing & Controlling
Product Development
Inputs
• WBS
• RAM
• Baselined Project schedule
and budget
• Approved management
plans
Activities
• Track/managed performance
• Develop the product
• Testing and integration
• Generate documentation
• Develop user training
Closing
Inputs
• All project reports
• Final deliverable
product
Activities
• Post-project review
• Close out contacts
Deliverables
• Lessons learned
Deliverables
• Change requests
• Status reports
• Changes to plan
• Final product
Milestone
• Post Phase Review
• Approval to go into Execute
Milestone
• Post Phase Review
• Approval to go into Execute
PM in Action!
Imagine you have contracted with a builder to create your dream home. This
evening, you’re going to sit down with the builder and define how the project
will go. List the phases you will want to use and define some key deliverables for
each phase.
52 Chapter 3
Project Life Cycles
As we have said, to manage a project effectively, a project manager divides the
project into phases and performs the phases in sequential order. The project
life cycle is the full set of those phases.
Why divide a project into smaller pieces? Because it is far easier to plan,
manage, and control small pieces than it is one giant project. Having a predefined life cycle with
well-planned-out
steps
makes the effort of managing a project much eas1. What are the phases used in your organiier. The project life cycle
zation? Are they formal or informal?
starts defining the project
2. In your organization, how do you see the
with phases.
project management processes interactWhen we talk about life
ing with the life cycle phases?
cycles, we have to be careful to clarify the context. There are actually three levels of life cycles—product
life cycle, project life cycle, and system development life cycle (commonly
abbreviated SDLC).
What Do You Think?
The product life cycle covers the product through its initial conception, the
first version, and later upgrades and variations until the product is retired and
a new product comes to take its place. This is the area that product owners
(who may be in the marketing department) care about. As shown in Figure
3-3, project management is used to develop the initial product and its upgrades, but the product life cycle begins before any project, extends through
multiple projects, and ends after the company decides to retire the product.
The initial development, each upgrade, and each new version of the product
is a project by itself.
Similarly, there is a relationship between the project life cycle and the systems development life cycle, as shown Figure 3-4.
In the May 14, 2002 edition of ComputerWorld magazine, a system development life cycle (SDLC) was defined as the overall process of developing information systems through a multistep process, from investigation of initial
requirements through analysis, design, implementation, and maintenance.
There are many different models and methodologies, but each generally consists of a series of defined steps or stages.
Project Processes, Phases, and Life Cycles 53
Figure 3-3. Product Life Cycle
Product Life Cycle
Product
Conception
Product
Version 1
Product
Version 2
Upgrade 1
Product
Close Out
Project Life Cycle—Develop Product
Project
Initiation
Project
Planning
Project
Execution
Project
Closeout
Figure 3-4. Project Life Cycle
Project Life Cycle
Project Control
Project
Initiation
System
Requirements
System
Architecture
Project
Planning
System
Design
Project
Execution
System
Development
Integration
& Test
Project
Closeout
Implementation
Systems Development Life Cycle
Many different SDLC models exist. The best one to use depends on the type
of product you’re developing. If you’re developing a product where the user
requirements are poorly defined, choose one of the approaches that puts the
product in front of the user as often as possible, such as an iterative approach.
If your project has little user interface or the user interface is well-defined,
you can choose a more classic waterfall methodology.
Common IT life cycle approaches include:
• Ad hoc/code-and-fix
• Waterfall
54 Chapter 3
• Iterative/incremental
• Spiral
• Prototyping
• Light life cycles, such as agile development
Let’s look at each of these in a bit more detail.
Ad Hoc/Code-and-Fix
Figure 3-5 shows the ad hoc/code-and-fix approach. Ad hoc/code-and-fix
is the most unstructured approach and is sometimes referred to as hack and
patch. No formal design documentation and no specifications exist. This approach works only for very small projects. The downsides are that it is very risky
and high cost (in the long term), and the products it produces often require
extensive maintenance because of the unstructured development approach.
Figure 3-5. Ad Hoc/Code-and-Fix Approach
Build first
version
Modify until
client is happy
Put into
operations
Development
Maintenance
Retire
product
One version of this approach, called extreme programming (XP), is a more
structured version of a very unstructured approach. It calls for the team to
gather minimal requirements from the user or the client, then break up into
groups of two. Each group generates what it thinks the client wants and then
shows the resulting functionality to the client. If the result is what the client
wanted, the team picks another piece of functionality and generates it the
same way. If none of the results are what the client wants, the team throws
out the code and writes new code that it thinks satisfies the requirements.
Project Processes, Phases, and Life Cycles 55
Because of the lack of planning or requirements development, and because
of the high percentage of discarded code, from a project management approach XP is generally not recommended for anything other than small software projects.
Waterfall
The waterfall approach is the most commonly used and recognized life cycle.
Figure 3-6 provides an example.
Figure 3-6. Waterfall Approach
Initiation
Planning
Analysis
Design
Construction
Testing/
Integration
Implementation
Post Implementation
Project Management
Why is it called a waterfall? When a project is behind but the end date doesn’t
move, activities are crammed onto the right side of the schedule. The schedule ends up looking like a waterfall, as shown in Figure 3-7.
The waterfall approach is a very linear approach to managing projects. Everything is planned out ahead of time and everything is documented. It emphasizes completing one phase of the development before proceeding to the
next phase.
The waterfall approach has several advantages: it’s easy to follow, the team
gets approval for the design before moving into development, and manage-
56 Chapter 3
Figure 3-7. Waterfall Approach, Version Two
Initiation
Planning
Analysis
Design
Construction
Testing/
Integration
Implementation
Post Implementation
Project Management
ment understands from the beginning what activities are going to happen
and when. The difficulties with it are that it assumes that all requirements
can be specified in advance (which usually isn’t the case); the end users are
only heavily involved during the early analysis and requirements gathering
steps, and then not again until the user acceptance test; and it requires planning and budgeting the entire project early, often before there is enough information to do a thorough job of planning and budgeting. Real life projects
are rarely as linear as the waterfall approach shows, and the project manager
ends up adjusting the schedule often to factor in changes.
Iterative/Incremental
An iterative (or incremental) approach is one which goes through the development cycle more than once, adding additional functionality to the product
each time. Figure 3-8 shows the iterative approach. The advantage to the approach is that it produces usable subparts that can be tested and delivered
earlier in the process. The iterative approach is a good choice if the product
has a heavy user interface and the customer or user is readily accessible. A
part of the product can be developed, the user can be shown the part and
provide input to the design, and then the next part can be developed.
Project Processes, Phases, and Life Cycles 57
One variation on the approach has been dubbed the Rational Unified Process
by Rational Software (now a part of IBM). Rational Unified Process is more
commonly referred to as RUP.
Figure 3-8. Iterative/Incremental Approach
Requirements
Verify
Arch. Design
Verify
For each build:
- Detailed design
- Develop
- Test & Integrate
- Deliver
Operations
Retirement
While there are advantages to using the iterative approach, there are also difficulties: the approach requires well-defined interfaces to all subparts; often,
the most difficult parts are moved to the end so that management sees progress on the simplest parts; and formal reviews and audits are more difficult to
implement on only parts of a complete system. When would you use it? David
Whitgift, in his book Methods and Tools of Software Configuration Management, says that “If it’s too risky to develop the whole system at once, then the
incremental development should be considered.”3
Spiral Approach
The spiral model created by Barry Boehm in 1985 is one example of an iterative approach to software development. Each cycle of the spiral begins by
identifying:
• The objectives of the portion of the product being elaborated
• Alternative means of implementing this portion of the product
• Constraints imposed by cost, schedule, interfaces, and so forth
58 Chapter 3
The second step is to identify alternatives relative to the objectives and
constraints, along with identifying areas of uncertainty that are sources of
project risk. If risk areas are identified, a cost-effective strategy for resolving
the sources of risk is developed. This may involve prototyping, simulation,
benchmarking, analytic modeling, or other risk reduction approaches.
Once a low-risk approach is identified, development can begin for a core
portion of the product. Both the steps above and the development effort are
managed as traditional waterfall approaches.
Typical cycles include
• Risk analysis
• Prototype
• Design and validation
• Planning
• Identification of alternatives
As each portion is developed, it is approved by the customer or user and additional functionality is added to it during the next phase. The original expectation was that each cycle would last between six months and two years—long
enough for the customer or user to work with the functionality that is developed in each phase and to develop the requirements for the next phase’s
development work.
An important feature of the model is that each cycle is completed by a stakeholder review that covers all products developed during the cycle and includes the plans for the next cycle. The goal of the review is to ensure that
all stakeholders are committed to the next phase. So at each phase of the approach, a portion of the final product is developed, shown to the users, and
used as the basis for later development.
The disadvantages of the spiral approach are that if the users are not responsible for the schedule or the budget, executive control can be difficult; the
approach requires significant risk assessment expertise to succeed; and the
project can just keep going in circles, adding “just one more feature,” or run
out of time and money. Unless the project manager manages the scope tightly, scope creep can turn into scope gallop!
Project Processes, Phases, and Life Cycles 59
Prototyping
Prototyping is the development approach that builds a less functional version of the product just to show the user and see if the prototype is what the
user wants. Because it can show the user an early version of what the user is
actually getting, prototyping is best used when the user requirements are difficult to determine. In the basic prototyping approach, called rapid prototyping or evolutionary prototyping, the main phases are:
• Gathering the requirements
• Making a quick design
• Building a prototype
• Submitting the prototype for customer evaluation
• Refining the prototype—iterate the previous two steps
• Engineering the product
As shown in Figure 3-9, there’s a lot of feedback during the prototype development. The feedback is necessary to prevent too much effort being placed
into developing something the user will not be happy with.
Figure 3-9. Prototyping
Rapid
Prototype
Verify
Receive Changes
Design
Verify
Implement
Verify
Operations
Retirement
The advantages of prototyping are that it helps define the user requirements
by producing something the user can touch and feel, provides a working version of the product, reduces downstream design activities, and simplifies the
implementation effort.
60 Chapter 3
Disadvantages to this approach are that the process is not particularly well
structured; specifications keep changing as new requirements are discovered;
it leads to premature design decisions that may turn out later to be wrong;
the prototype itself may become the final product without going through
the required QA and testing processes; and documentation tends to be poor.
Probably the most difficult part of this approach is managing it. When is it
finished? When is it right?
A variation on prototyping is called incremental prototyping or structured
prototyping. This is a combination of rapid prototyping and a waterfall life
cycle model. To use this approach, you create a prototype at each phase
(feasibility, requirements, design, and coding) and test them. The product is
developed in functional increments. Difficulties with this approach are that
no long-term planning exists and falling into a code-and-fix model is very
tempting.
Light Processes
In the field of software development, a number of light project management
approaches have recently appeared. These approaches are attempts to overcome the limitations of the traditional waterfall approach in software development. They work most effectively when the project size is not too large and not
too small. They emphasize strong client focus and involvement, strong software development team
members, and flexibility in
the project organization.
What Do You Think?
What would be the most effective system
One of the more widely
development life cycle to use on a typical
used of these newer proproject in your organization?
cesses is called agile development. The emphasis in
this methodology is to divide larger projects into smaller, shorter, and more
manageable projects and to put a heavy emphasis on continual interface
with the client or customer. Another focus for agile development is seeking to
overcome organizations’ habits of overworking their staff by setting up project management plans to develop a work pace that can be maintained for
long periods of time. Agile development is an evolving project management
approach for software development.
Project Processes, Phases, and Life Cycles 61
In Practice: How Life Cycles,
Phases, and Processes Interact
• Projects are divided into phases to help define and manage the work. The
project manager and the project team should define the appropriate phases for
the project.
• Projects have project management processes to initiate, plan, execute, control,
and close the phases and the projects.
• A system development life cycle is used to define the steps necessary to develop
the product of the project.
• The development of the product, product upgrades, and new releases are
projects that occur within the product life cycle.
Chapter Summary
• Different industries have different product life cycles. A product life cycle
includes everything from conception to final product retirement, including
development and maintenance.
• Projects are completed by using project management processes. The five
processes are initiating, planning, executing, controlling, and closing. These
processes are used throughout the life cycle of the project.
• The system development life cycle (SDLC) contains phases that include a
multistep process from investigation of initial requirements through analysis, design, implementation, and maintenance.
• There are several basic life cycle approaches. Some of the better known ones
are:
— Ad hoc/code-and-fix
— Waterfall
— Iterative/incremental
— Spiral
— Prototyping
62 Chapter 3
Key Terms
Life cycle
Phase
Process
Project management process groups
Milestone Rolling wave planning
Product life cycle
System development life cycle
Initiating processes
Planning processes
Executing processes
Controlling processes
Project life cycle
Light project management
Closing processes
Ad hoc/code-and-fix
Waterfall
Iterative/incremental
Spiral
Prototyping
Key Term Quiz
1. Process
A. Processes used to complete all the
documentation, deliver the product
to the customer or put it into the
production environment, close out
contracts, and so on
2. Phase
B. Processes used to start up the project
or the phase
3. Life cycle
C. Processes to monitor and manage
the work
4. Product life cycle
D. Processes used to do the actual work
to produce the product
5. System development life cycle E. Processes in which we think through
and plan out what has to happen in
the project or the phase
6. Initiating processes
F. A series of steps that complete the
project when done in sequence
Project Processes, Phases, and Life Cycles 63
7. Planning processes
G. A series of actions that bring about a
result or output
8. Executing processes
H. Covers the product from its initial
conception, through the first version,
later upgrades, and variations until
the product is retired and a new
product comes to take its place
9. Controlling processes
I. The overall process of developing
information systems through a
multistep process, from investigation
of initial requirements through
analysis, design, implementation,
and maintenance
10. Closing processes
J. Segment of the project that occurs in
a sequential order
Chapter Review Questions
1. Where in the project life cycle is the need for project management the
greatest?
2. A life cycle is:
a. A series of steps that will complete all parts of the project when done
in sequence
b. The set of activities we do in a project
c. What the project team does while we manage the project
d. The steps needed to start the project
3. The most common project life cycle approach is the:
a. Spiral model
b. Pilot development
c. The waterfall model
d. Iterative approach
64 Chapter 3
4. Which life cycle approach should only be used for very small projects?
a. Iterative approach
b. Waterfall approach
c. Extreme programming
d. Spiral model
5. At the end-of-phase reviews, which of these following activities would
you not typically do:
a. Review how the work went during the previous phase.
b. Tell the project sponsor that you’re over budget and need more
money.
c. Determine whether the project is ready to go onto the next phase.
d. Make a go/no-go decision to move to the next phase.
6. The most effective development life cycle to choose is one that:
a. Gets the majority of the product to the customer the fastest
b. Puts the least stress on the project team
c. Costs the least for the project
d. Makes the most effective use of resources while satisfying the product
requirements
End notes
1. Watts Humphrey, Managing the Software Process, Addison-Wesley Publishing, New York,
1990, page 58.
2. John J. Rakos, Software Project Management for Small to Medium Size Projects, PrenticeHall, New Jersey, 1990
3. David Whitgift, Methods and Tools of Software Configuration Management, John Wiley and
Sons, New York, 1991
5
Initiating
and Planning
Project Scope
After reading this chapter, you will be able to:
• Describe the elements and purpose of a project charter.
• Define the elements that go into a project scope statement.
• Gather requirements for your project.
In Chapter 2, we talked about how to select projects when the demand for
projects is high, but the resources available are low. We looked at a project selection method and noted that all projects should relate to the organization’s
strategic intent. After a project is selected, the CEO does not just find an available project manager and say, okay, here is what I want you to do, when do
you think it will be done? At least we hope that is not what happens.
Project selection begins the initiation process. The initiation process is complete when the project charter has been signed. At that point, the project
manager begins the detailed requirements gathering process.
The Project Charter
The completed project charter is often considered the official start of the
project. This document authorizes the project and allows the project manager to apply organizational resources. As such, it should be developed by
management rather than the project manager. In this context, management
may be the project sponsor, the requesting functional manager, or—in the
case of a Category A project—a member of the executive team. Generally, the
larger the project, the higher up the ladder the author of the project charter. In many organizations, upper management is often too busy to write the
86 Chapter 5
project charter. In this case, the task may be delegated to the project manager, with upper management having approval and sign-off authority. This
approach has the advantage of getting the project manager involved earlier
in the project and going through some of the upfront analysis that is necessary to plan the project.
What Goes into the Project Charter
A few things must go into the project charter. The project charter identifies
the high-level requirements necessary to satisfy customer, sponsor, or stakeholder needs. It describes the business needs that the project was undertaken to address, which provides a justification for the project. The project
charter also includes a tie to the organization’s strategic objectives. Whether
the project is a means of improving efficiency, increasing market share, reducing costs, or aiding some other aspect of an organization’s strategic plan,
the information should be spelled out in the project charter. The charter also
provides a high-level description of the project and the product.
The project charter must also prioritize the triple constraints of scope, schedule, and cost for the project. Is it more important to deliver full product functionality with cost and schedule being secondary? Is meeting the delivery
date important, even if functionality has to be sacrificed? Is the priority to
keep costs as low as possible? The primary driver should be clearly stated
in the project charter so that the project manager knows what to emphasize
during the execution phase of the project, when tradeoffs have to be made.
Knowing what is most important to the client or sponsor will allow the project manager to meet those expectations.
In some organizations, the project charter also contains additional information. This includes a high-level milestone schedule, a rough order of magnitude (ROM) budget, and the initial project organization. Sometimes the
roles and responsibilities of key project staff, including the project manager,
project sponsor, and key team positions are described. This description may
take the form of a responsibility matrix with high-level roles and responsibilities, showing who the primary stakeholders are and their roles on the project,
or it may just provide the titles and summary of responsibilities. The initial
project assumptions and constraints are frequently part of the charter, either
by being directly integrated or through the charter’s including a reference to
outside documents such as assumptions logs and risk logs.
Initiating and Planning Project Scope 87
Sometimes a business case is summarized or referenced in a project charter. An initial business case may have been developed that includes market
research, ROI or other financial models, prototype information, and legal
or regulatory information. Stakeholder influences may be listed as part of
the business case or integrated into the charter. For instance, if a regulatory
agency has input or signs off as part of the project, this stakeholder influence
is mentioned in the charter.
In summary, a project charter always addresses the following:
• High-level requirements that satisfy customer, sponsor, or stakeholder
needs
• Business needs, high-level project description, product requirements
• Project purpose or justification that ties to a strategic need
• A high-level description of the product and the project
• Prioritization of the triple constraints
And a project charter may also include the following:
• Business case justifying the project, including ROI
• Summary milestone schedule
• Summary budget
• Initial project organization
• Assumptions
• Constraints
• Known risks and issues
• Stakeholder influences
• Assigned project manager and authority level
In the case of a consulting firm or an organization that bids for business, the
information for the project charter may come from a contract or a statement
of work. If the project is internally generated, the information may come
from within the organization or from external environmental factors such as
market demand, regulatory requirements, technology advances, customer
requests, or social needs.
88 Chapter 5
Figure 5-1 shows a sample project charter.
Figure 5-1. MegaNews Project Charter
Project Name: MegaNews Infrastructure
Date
Project Sponsor: B. Ware
Project Manager
Project Description
Provide the IT component for opening up new offices in downtown Los
Angeles for 1,000 new employees, including 50 executives, 25 secretaries,
and ~925 staff. Offices will be located in three different leased office buildings in a campus type setting.
Business Alignment
•Increase advertising revenue by 20% in 3 years
•Increase the subscription base by 15% in 3 years
Project and Product
1. Backup requirements:
Requirements a.We need to do full backups, both within each facility as well as having
hot backup off site that covers all facilities.
b.Daily backup to corporate HQ is run each night for the HR and the
financial data
2. Each person gets their own desktop, except the reporters who get laptops with a docking station.
3. Basic systems need to be compatible with corporate systems. Therefore the basic desktop suite is Microsoft Office, the DB is DB2, the HR
systems will be a PeopleSoft implementation.
4. Two groups, human resources and news, need some custom software
development for programs that are unique to them. These are moderate size programs, 150 function points, which tie in-house software to
external systems such as payroll processing. They should take no longer
than 2,000 man-hours each to develop.
5. Develop and host the corporate web page for MegaNews International.
The site does not have any e-commerce capability but will have a registration DB. It must be live 3 weeks prior to the office opening to create
name recognition and it will tie into the marketing campaign.
6. In order to make maintenance operations simple after the office goes
live, a full set of design and configuration documentation will be developed, consistent with company policy.
Roles and
Project Sponsor
•
Responsibilities
•
•
•
Champion the project within the organization.
Provide business support for major project decision
and direction setting.
Approve the project plan, cost, and schedule
Support the Change Control Board meetings
Project Manager
•
•
•
•
•
Develop the project plans and schedules
Manage all aspects of project delivery in the areas
of scope, time, cost, quality, resources,
communication and risk.
Direct and coordinate the activities of the project
team.
Assure the meeting of Business Sponsor’s
objectives for the project.
Lead the Change Control Board meetings
Business Analyist
•
•
•
•
•
Gather and document business requirements.
Support gathering and documentation of functional
and technical requirements.
Support the project plan development
Design and document new business processes.
Support the Change Control Board meetings
Initiating and Planning Project Scope 89
Figure 5-1. MegaNews Project Charter (continued)
System Engineer
•
•
•
•
•
Lead the decomposition of the business
requirements into the functional and technical
requirements
Manage the requirements and assess the impact
of changes to the requirements
Identify external interfaces, ensure they are verified
Ensure the testing and integration program verifies
all requirements
Support the Change Control Board meetings
IT Lead
•
•
•
•
Lead the design effort and write the design specs
Ensure that all requirements are covered by the
design
Design external interfaces in accordance with the
specifications
Support the Change Control Board meetings
Initial Project
Betty Ware—Sponsor Overall PM
IT Project Manager
Business Analyst, System Engineer, IT Specialists
Major milestones
and deliverables
Milestone
Project Plan Baselined
Deliverables
Project management plans, project schedule,
and cost
Requirements Approved
Sponsor signoff on project requirements
document
Design Approved
Design specifications
LAN Implementation
Completed
Completion of LAN and desktop machine
installation
Approval of Custom S/W Custom software completed and approved
through User Acceptance Test
Backup Site Approved
Go Live Approval
Hot backup site completed and tested
UAT completed
Corporate is ready to turn link on
ROM Budget
N/A
Constraints
Go Live date in 6 months
Must have web site up 3 weeks prior to go live
Do not have access to server room until 1 month prior to go live
All technology must interface with existing systems
Assumptions
1. The server room will be ready for move in 1 month prior to go live.
2. MegaNews will be responsible for its own system maintenance.
3. Each facility already has a T3 link (high speed, high bandwidth link).
4. The offsite data storage will be through an outside vendor. You will have
to manage that procurement process as part of this project.
5. The Director of Corporate IT will sign off on all documentation for the
project.
Known risks
1. We don’t have a server room until 1 month prior to go live. Therefore, all
development work on custom programs and the web site must be done
off site and then transitioned to the new location once it is up.
Prioritization
Schedule, Scope, Cost
Other
90 Chapter 5
PM in Action!
Assume that you have been asked to upgrade all the computers at your company
to the newest release of your operating system. The CTO is the sponsor and she
has asked you to create a project charter for her to review tomorrow afternoon.
Making assumptions about areas you don’t have the information for, create a
project charter for this project.
Value of the Project Charter
The project charter is the link from senior management to the project and
the project manager. One of the main reasons that projects fail is lack of
senior management support. The charter is management’s visibility into
the project, its commitment of organizational resources, and its communication to the project manager and the organization of what it wants. The
charter also ensures that each project is tied to a strategic need. Therefore,
when decisions have to be made that involve trade-offs or resource allocation, management can look at the project charter, note the contribution
the project is making to the company, and use this information to make a
wise decision. The project charter also helps the project manager with authority when he or she is dealing with functional managers. The charter is
management’s statement to the organization that management supports
the project and the project manager.
The Kickoff Meeting
Usually, once the project charter is created, a kickoff meeting is called. Every
project should have a kickoff meeting. The purpose of the kickoff meeting is
to introduce the team to the project and to each other and to generate some
excitement about the project. Starting the kickoff meeting by going around
the room and doing introductions is a good idea if the team has not worked
together before. If everyone has worked together, you can launch right into
the project charter.
The purpose of the meeting is to make the objectives clear and to ask the
team members if they have any questions. At the meeting, the scope of the
project should be reviewed along with the milestones, key deliverables, and
the team organization. At the end of the meeting, everyone should under-
Initiating and Planning Project Scope 91
stand the scope of the project, their role in the project, how the project relates
to the company’s strategy, and the next steps. The project charter can be used
to facilitate all the discussions held at the kickoff meeting.
PM in Action!
Using the example of updating your operating system and the charter you
previously developed, create an agenda for a kickoff meeting.
The Project Scope Statement
The project charter is focused on how the project relates to the organization
in terms of resources, strategy, and stakeholders. It also includes high-level
information about scope, schedule, and cost. The project scope statement,
meanwhile, is focused on the scope of the project and the product. Developing the scope is an evolutionary process, just as developing the schedule and
budget are. The project scope statement helps define what is being developed and raises the questions necessary to accurately define what will and
will not be included as part of the project.
Notice that project scope is different from product scope. The product scope
defines only the end deliverable and its components. The project scope defines the work necessary to deliver the product scope. For example, part of
the requirements may call for an end-to-end testing suite where a robust user
acceptance test can be administered. This is part of the project, but it is not
part of the product. Therefore, the project manager must clearly define both
the work needed for the product and the work needed for the project.
In developing the project scope statement, the project manager will reference the project charter as well as any other additional information that is
available. Developing the scope statement generally requires a number of interviews and meetings with the client, team members, the sponsor, and other
stakeholders. Many of the decisions that affect the final product are made
in this stage. This is where the work of defining the product and the project
management approach begins.
92 Chapter 5
What Goes into the Project Scope Statement
So, what is included in the project scope statement? Like most things in project management, it depends on the product, the organization, and the external environmental factors. However, here is a list you can use as a guideline:
• Project objectives
• Product or services requirements and characteristics (including any technology requirements)
• Project requirements and deliverables
• Product acceptance criteria
• Project boundaries
• Initial WBS
• Configuration management requirements
• Updates to information from the charter, such as project milestones, budget estimates, etc.
Let’s look at these in a bit more detail, and then we will look at a sample template (see Figure 5-2).
Project objectives are the specific measurable results that the organization is
looking for the product to meet. Some possible project objectives are:
• Reduce turnaround time from 20 days to 17 days.
• Reduce waste from 3 percent to 1.5 percent.
• Save 12 percent on manufacturing costs in the next calendar year.
• Eliminate two FTE positions.
Project objectives are tied to the business justification identified in the project charter. Project objectives give the project manager and the sponsor a
way to measure the success of the project—to see if the project delivers what
was intended. The objectives will also be used as a guideline in making project decisions. When evaluating the approaches to a project, using the project
objectives is a good way to select the best approach. Objectives also keep the
project focused. Particularly with IT projects, scope tends to get out of con-
Initiating and Planning Project Scope 93
Figure 5-2. MegaNews Project Scope Statement
Project Name: MegaNews Infrastructure
Date
Project Sponsor: B. Ware
Project Manager
Project Description
Provide the IT component for opening up new offices in downtown Los
Angeles for 1,000 new employees, including 50 executives, 25 secretaries,
and ~925 staff. Offices will be located in three different leased office buildings in a campus type setting.
Business
Alignment
• Increase advertising revenue by 20% in 3 years
• Increase the subscription base by 15% in 3 years
1. Backup requirements:
a. We need to do full backups, both within each facility as well as
having a hot backup off-site that covers all facilities.
b. Daily backup to corporate HQ is run each night for the HR and the
financial data
2. Each person gets their own desktop, except the reporters who get laptops with a docking station.
3. Basic systems need to be compatible with corporate systems. Therefore the basic desktop suite is Microsoft Office, the DB is DB2, the HR
systems will be a PeopleSoft implementation.
4. Two groups, human resources and news, need some custom software
development for programs that are unique to them. These are moderate
size programs, 150 function points, which tie in-house software to external systems such as payroll processing. They should take no longer
than 2,000 man-hours each to develop.
5. We will develop and host the corporate web page for MegaNews International. The site does not have any e-commerce capability but will have
a registration DB. It must be live 3 weeks prior to the office opening to
create name recognition and it will tie into the marketing campaign.
6. In order to make maintenance operations simple after the office goes
live, a full set of design and configuration documentation will be developed, consistent with company policy.
Project Objectives
The quantifiable criteria that must be met for the project to be considered
successful. Project objectives must include at least cost, schedule, and
quality measures.
Cost Objectives (quantify)
N/A
Schedule Objectives
Entire project complete in 6 months.
Web site up 3 weeks prior to go live.
Hot backup completed and tested prior to go live.
Access to server room in 5 months.
Scope/quality
Objectives
Quality must be consistent with company standards.
Start up on Day 1 with no glitches.
Project Deliverables
A list of the summary-level sub products whose full and satisfactory delivery
marks completion of the project. Should include product and project
deliverables.
Deliverable A
Web site with registration database
Deliverable B
System design documents
Deliverable C
Network connectivity including switches, routers, circuits, and servers
Deliverable D
All hardware connected including desktops, laptops, printers, scanners, etc.
Deliverable E
HR custom software
94 Chapter 5
Figure 5-2. MegaNews Project Scope Statement
Deliverable F
News custom software
Deliverable G
Contract for off-site data backup
Deliverable H
Design and configuration documentation
Initial WBS
1.
Project Boundaries
Blackberry beta test
Anything outside IT for overall project
Any ongoing IT operations
Acceptance Criteria
All systems tested and signed off 2 weeks prior to go live
Web site operational 1 month prior to go live
All software fully functional by go live
Documentation signed off by Director of IT
Back up operations tested and functional
Configuration Management
Per company policy
Change Management
Per company policy
IT Infrastructure
1.1. Web Site
1.2. Network
1.3. Software
1.4. Back Up
1.5. Project Management
trol. A wise project manager will use the project objectives and scope statement to keep a tight reign on scope.
Product or service requirements might include compatibility with existing
systems, regulatory requirements, or certain functionalities. These requirements should be clearly documented, as they will be used to verify completion. If there are quality measurements that need to be met as part of the
product, those should be documented as well. We will discuss requirements
in more detail later in the chapter.
Project requirements and deliverables address how the product requirements will be met. This may include information on testing, alternative
approaches, life cycle or phase gates, training and documentation requirements, and any other aspect that affects the product scope but may not be
part of the end product.
Product acceptance criteria define measurements, performance, objectives,
and metrics that need to be met in order for the client to accept the product.
Information from product and project deliverables, requirements, and objectives will provide information for this section.
Initiating and Planning Project Scope 95
Project boundaries define what is in scope and what is out of scope for the
project. Project boundaries can be the project manager’s best friend when it
comes to controlling scope creep. It is a given that the customer will assume
that if something is not specifically excluded, it is included. Project managers
assume that if something is not explicitly included, it is excluded. Therefore,
be very clear on what is included in the project and what is excluded. We also
suggest that the project manager form a method for addressing conflicts and
uncertainties in project scope. This may be a project change-control board or
a project advisory committee.
For anything other than a small project, incorporating a section on what the
project will not do is critical. For example, if the project is to upgrade the operating system in the company’s computers, stating exactly what interfaces
the project will test and which ones it will not is important. This will prevent
any confusion about whether that critical piece of software on the CFO’s machine will work with the new operating system.
An initial work breakdown structure (WBS) is necessary to start to chunk
the work. Work may be chunked by phase (such as life cycle), by major component, by geography, or in any other way that makes sense. We will talk more
about WBSs shortly.
Configuration management may be included in the scope statement, as well
on certain projects. Configuration management addresses how versions, updates, materials, and changes will be incorporated into the product and the
project. It may address materials, documentation, progressive elaboration,
and iterative planning.
In addition to the above, the project scope statement may contain updates.
One of the realities of project management is what we call progressive elaboration. This means that the entire project isn’t planned in detail in one sitting. Rather, it is increasingly elaborated, planned, and made clear over time.
As product requirements are defined, the resources requirements can be refined, the schedule gets a lower level of detail, and the budget is flushed out.
This is ongoing throughout the planning and even during the executing and
control processes. Therefore, updating project documentation on an ongoing basis is important.
As part of preparing the project scope statement, the project manager may
find that he or she can update the initial milestone schedule and the initial
rough order of magnitude (ROM) budget. In starting to define the product
96 Chapter 5
and project requirements and the objectives, the project team will make certain assumptions and uncover risks. These need to be added to the various
project logs.
Value of the Project Scope Statement
In addition to poor requirements gathering, two other main reasons for project
failure are insufficient planning and lack of customer participation. The scope
statement is the planning link between the customer and the project manager. It is how the project manager knows that there is clear communication
between the customer’s needs, wants, expectations, and the end product the
project manager is helping to create. It helps the project manager organize the
project management process and creates a context for the planning process.
The list of deliverables and the top-level WBS communicate what is being
developed and how it will be developed. Getting client input into the WBS (or
at least client sign-off), assures that the client and the team are heading in the
same direction. The acknowledgment of project boundaries in the beginning
of the project can save scope creep or having to explain later why the team is
not going to add the growing list of requests for the product. The project objectives help the project manager and other stakeholders make choices about
alternatives by clearly listing what is expected from the project. The acceptance criteria assist the project manager in better defining the target and help
in the close out. Most project managers have been on a never-ending project
at one time or another. By clearly defining the acceptance criteria, the project
manager can effectively box the project and define the end point where the
product is transitioned to the customer or to operations.
All About Requirements
Requirements are the foundations of projects. They are defined at a high
level in the project charter and elaborated in the project scope statement.
In projects with an extensive set of complex requirements, the project manager usually keeps a separate requirements document that is subject to
configuration control.
Note: More projects have run into severe problems because of missing or
poorly stated requirements than any other single cause. In Effective Require-
Initiating and Planning Project Scope 97
ments Practices, Ralph Young states that studies show that up to 85 percent of
the defects in developed software begin in the requirements.1
Introduction to Requirements
What are requirements? Everyone knows what they are, but everyone’s understanding of them is different. When you tell the marketing person that you
need the requirements for the new product she’s asking for, she’ll be happy to
tell you what she wants in the product. What she gives you is virtually always
very high level and is totally concerned with the user’s experience with the
new product. When you ask the identical question of someone in engineering, he will be happy to give you an answer, but the requirements he gives you
will be so detailed that the marketing person will look at them as if they are
from another planet and say, “What does that mean?”
They are both giving you requirements, but from different levels of detail.
What, then, is a requirement? A requirement is a clear statement of a need,
sufficiently detailed so that there is no question about what is being asked.
The International Institute of Business Analysts (IIBA) defines a requirement
as a necessary attribute in a system. Requirements are statements that identify a capability, characteristic, or quality factor of a system in order for it to
have value and utility to a user.
One of the more significant challenges is to collect clear, concise, and correct
requirements. All new products or services start with someone’s needs. These
needs are translated into requirements, and the requirements form the scope
of the product. The success of your project depends on how well you deliver
what the user expects. That is, on how well you meet the requirements.
But let’s face it: gathering requirements is not much fun. To do it right can
require interviewing stakeholders, doing business process analysis, reading
the documentation you have, making some best guesses as to what is wanted, documenting it all, and then walking through it with the stakeholders to
verify that it truly is what they want. However, if you do it right, you can manage the rest of the project with full confidence that you know you understand
what the stakeholders want. Without it, you will spend the rest of the project
swallowing heartburn medicine and worrying about whether you are building the right thing.
98 Chapter 5
!
WARNING
The major indicator of a project that is headed for trouble is that
the requirements change constantly.
We said in the introduction that the success rate of IT projects is poor. Multiple surveys say that 85 percent of IT projects fail to deliver the full scope
within cost and within schedule. The two primary causes of this high failure
rate are inadequate planning and not having a good understanding of the
requirements.
How do requirements fit into our overall project? The flowchart in Figure 5-3
should give you a good indication of where they fit.
In Practice
A study conducted by Frederick T. Sheldon showed the following about the
sources of software bugs in a complex Air Force project.2
• 41% due to requirements errors
• 28% due to logic errors in design
• 6% interface errors
• 6% data errors
• 5% environment
• 5% human errors
• 2% documentation
• 6% other
Initiating and Planning Project Scope 99
Figure 5-3. Requirements Hierarchy
Problem
or
Need
Top-level
Requirements
(Business need)
Detailed
Requirements
Detailed design
specifications
Logical
Equivalent
Define tasks
to satisfy
Specifications
Aggregate tasks
into the WBS
Add task
relationships
and durations
Assign
resources
Create
network
diagram
Begin
project
Develop
solution
Verify
requirements
are satisfied
Delivery
solution
Create
test
plan
100 Chapter 5
The Business Analyst and Requirements
A good business analyst can be a project manager’s best friend. Frequently,
it is the business analyst who gathers, analyzes, manages, and tests requirements. The IIBA has developed a body of knowledge for business analysts
that focuses on requirements. The IIBA’s body of knowledge is comprised of
the knowledge areas shown in the following table.
IIBA Knowledge Areas
Description
Enterprise analysis
Defines activities and approaches
required to capture necessary business
views that support requirements and
functional design work on a given initiative
or to develop an overall enterprise or
organizational plan.
Requirements planning and managing Defines requirements, project life cycle
activities, and requirements deliverables.
Requirements gathering
Defines activities and approaches required
to capture business solution requirements
from the project stakeholders.
Requirements analysis
Defines how business, functional, and
supplemental requirements are analyzed.
Requirements communication Defines requirements documentation and
presentation practices and policies.
Requirements implementation Defines tasks necessary to validate how
the business solution meets stakeholder
objectives, ensures appropriate test
coverage, and supports requirements
management and administration.
Business analysis fundamentals Defines competencies, skills, techniques,
and knowledge needed to perform
business analysis effectively.
The project manager focuses on managing the project management processes, or initiating, planning, executing, controlling, and closing, whereas the
business analyst is focused on the technical aspects of the project scope, such
Initiating and Planning Project Scope 101
as requirements gathering, analysis, and implementation. Figure 5-4 shows
how the SDLC, the project management process, and the requirements processes work together.
For more information on the IIBA, visit www.iiba.com.
Types of Requirements
Requirements are hierarchical, starting with top-level user or business needs
that determine what this project is. A top-level need might be “E-mails from
our customers are taking much too long to get through our system. We want
them to show up at their destination within two minutes after they arrive.”
When the problem is a business need, the best people to gather these requirements are business analysts. Their job is to understand the business
processes and the business strengths and weaknesses.
We take those top-level needs and decompose them into more detailed system needs. We now start thinking about the details of the solution. We consider how the end product may be designed and developed. These are system
requirements and include functional requirements (what the product has to
do) and performance requirements (how well it has to do it).
Figure 5-4. IIBA and Project Management Process Integration
t
n
me
ge
na ups
a
t M Gro
jec
ro cess
P
I ro
PM P
Initiating
Process
Group
as
re
eA
g
led
ow
A
IIB
Kn
Requirements
Gathering
Planning
Process
Group
Analysis
Documentation
&
Communication
Executing
Process
Group
Monitoring
and
Controlling
Process
Group
Closing
Process
Group
s
cu
am
Fo
r
og
Pr
s
cu
Requirements
Implementation
e
op
Fo
Sc
Requirements Planning and Management & Fundamentals
ion
lut
So le
s
es yc
sin fe C
Bu Li
Requirements
Design Construction Test
Deliver
Pr
od
t
uc
s
cu
Fo
102 Chapter 5
The technical gurus take those system requirements and decompose them
even further, into detailed technical requirements. This is where the marketing people usually get lost; this level is too detailed for them. They cannot picture the final product from reading a stack of technical design specifications.
All of these requirements flow from the original need for the product. Unfortunately, that is not the only source of requirements. Other requirements are
imposed on us by regulatory needs, industry best practices, testing needs,
and other sources. Nevertheless, the product-derived requirements are the
core starting point.
The following are the types of product requirements that you will find on IT
projects:
Functional requirements are defined by the source of the project need.
Functional requirements are specifically what the product must do. These
are taken from the business needs or the client’s needs.
Performance requirements are also defined by the source of the project
need. This is how fast, how safely, and how securely the product must perform. When you gather requirements, you have to be careful that the performance requirements do not contradict the functionality requirements.
Interface requirements come in two types: internal interface requirements and external interface requirements. Internal interfaces are how the
different modules or pieces of the product interact with each other. External interfaces are how the product will fit into the environment for which
it is designed.
Look-and-feel requirements are defined by the user. They describe how
the user will interact with the product. This can be as simple as the graphical user interface (GUI) of a computer program or as complex as the pilot
interface in a new passenger jet. The old name for these requirements was
man/machine interface (MMI).
Operational requirements describe the operational aspects of the product when it is being used. They describe what the product will do and what
the operators will do. In a satellite system, for example, careful trade-offs
are made between what the satellites can do and what decisions need to be
made by the ground operations crew. Operational requirements are often
dictated by business rules that derive from how the company operates or
from regulations that apply to the industry.
Initiating and Planning Project Scope 103
Verification requirements describe how the system will be tested. In computer circuits, test points may be designed in to allow calibration and testing of the completed circuit. In software applications, “hooks” may be inserted into the code that a tester can access to see the result of a test at
different levels of the application.
Implementation requirements dictate how the final product will be implemented. If the product is a hardware product, implementation requirements can dictate how the hardware will be rolled out to the user. If it is a
software product, implementation requirements can dictate how it will be
installed into the final production environment.
Security, legal, and privacy requirements are a relatively new category of
requirements. These are dictated partially by regulation and partially by the
need to keep out viruses, Trojan horses, and spam from our systems. For example, in the medical field many new regulatory requirements have been
dictated by the Health Insurance Privacy and Portability Act (HIPPA).
Finally, we have the generic category of requirements called “ilities”—reliability, maintainability, upgradeability, manufacturability, and so on. Figure
5-5 shows a breakdown of the types of requirements.
In Practice: Achmed the Engineer
While the 777 jet was being designed, almost as much work was put into designing
and developing the maintenance program as was put into the jet itself. During this
project, Boeing created a fictional maintenance engineer by the name of Achmed.
Achmed was born in the Middle East, raised in China, currently lives in Africa, and
does not speak English. The design requirement was to develop a maintenance
system that Achmed could understand.
Properties of Requirements
Because the entire project depends on having a thorough understanding of
what the product will be, that is, of the requirements, you want to take requirements very seriously. Individual requirements must be clearly written
so that there is no misunderstanding of what the requirement says. The full
set of requirements must be complete and thorough. There must be no missing requirements and no contradictions among the requirements.
Requirements are like fish—they swim alone but they also form schools.
Individual requirements and sets of requirements each have criteria they
must meet.
104 Chapter 5
Figure 5-5. Requirements Breakdown
User Requirements
Functional, Performance,
Usability, Reliability, ...
System Requirements
Functional, Performance,
Usability, Reliability, ...
Data
Requirements
Hardware
Requirements
Software
Requirements
Operational
Requirements
Preliminary DB
Architecture
Preliminary
Design
Preliminary
Design
Process
Design
Detailed
Design
Detailed
Design
Detailed
Design
Process
Development
Data
Population
Machining,
Breadboarding
Coding &
Debugging
Testing &
Integration
Operations and
Maintenance
Individual Requirements
Individual requirements must satisfy the following set of criteria.
The requirement must be necessary. The stated requirement is an essential capability, physical characteristic, or quality factor of the product or
process. If it is removed or deleted, a deficiency will exist that cannot be
fulfilled by other capabilities of the product or process.
Initiating and Planning Project Scope 105
The requirement must be concisely stated. The requirement statement
includes only one requirement stating what must be done, and only what
must be done, simply and clearly. The old rule in aerospace contracting was
that you only stated one requirement per paragraph and that every paragraph was numbered. This allowed you to develop requirements tracking
systems.
The requirement must be free of any implementation bias. The requirement states what is required, not how the requirement should be met. A
requirement statement should not reflect a design or implementation nor
should it describe an operation. (The treatment of interface requirements
is generally an exception.)
The requirement must be feasible. The stated requirement can be achieved
by one or more developed system concepts at an affordable cost. Barry Boehm,
one of the software field’s leading management gurus, has been quoted as
saying a requirement must be affordable, or it is not a true requirement.3
The requirement must be complete by itself. The stated requirement is
complete and does not need further amplification.
The requirement must be consistent. The requirement neither contradicts other requirements nor is a duplicate of another requirement. The
requirement makes sense within the context of the product.
The requirement must be unambiguous. Each requirement must have
one and only one interpretation. The words used in the statement must
not leave a doubt in the reader’s mind as to what is meant.
The requirement must be verifiable. The requirement is stated in such a
way that it can be verified or tested.
In general, requirements must be relevant, affordable, implementable,
and apply specifically to the product under development. A requirement
statement should never define the solution; it simply states the need. The
solution comes from the analysis effort. If requirements are written using
the SMARTT Requirements format, they will be clear, unambiguous, and
understandable:
Specific:
No ambiguity, no fuzzy descriptions
Measurable:
Quantifiable to the extent possible
106 Chapter 5
Agreed to:
By the stakeholder
Realistic:
Achievable within constraints
Traceable:
Full up and down traceability
Testable:
Be able to prove you met it
When you write requirements, you want to avoid using words that are vague or
subject to interpretation (or argument). Words that should be avoided include:
“flexible,” “fault tolerant,” “high fidelity,” “adaptable,” “rapid” or “fast,” “ade­
quate,” “user friendly,” “support,” “maximize,” and “minimize.” (A sure sign
that someone has been trained in consultant-speak is that he or she will string
together combinations of these words to make the product sound fantastic.)
Sets of Requirements
Just as we said individual requirements had to meet criteria, the full set of
requirements taken as a whole also has criteria it must meet.
Completeness. The set of requirements is complete and does not need further requirements. The requirements address all categories and cover all
aspects of the product.
Consistency. The set of requirements does not include some requirements
that contradict other requirements.
Sources of Requirements
So, where do we get these requirements? There are a number of sources for
them. The top-level requirements often come from early project documentation, such as the project charter, the project scope statement, the statement of
work (SOW), or a request for proposal (RFP) from a client. They can also come
from business process analyses on existing processes, from the business rules,
and most importantly, from the future users and other stakeholders.
Technical requirements can be derived by decomposing the top-level requirements and by doing simulations, running scenarios, or by using specific
requirements-gathering techniques such as use cases.
Initiating and Planning Project Scope 107
PM in Action!
The Atlantic Systems Guild has developed an excellent process it calls Volere. Go to
the Volere web site, www.volere.co.uk/index.htm, and download the shareware.
Academic institutions and students are exempt from the shareware fee. Use this
template to develop a set of requirements for a PDA for yourself.
Your most important source of requirements for most projects will be the
project stakeholders. By definition, a stakeholder is any person or organization who:
• Is directly involved in the project
• Has oversight or some authority over the project
• Uses the project’s end product
• Has work affected by the project
The PMBOK® Guide defines stakeholders as individuals or organizations actively involved in the project or those whose interests may be affected (positively or negatively) by project execution or project completion.4 Stakeholders may also exert influence over the project and its results.
Most projects have more stakeholders than the project manager wants to
think about. They always seem to be getting in the way and interfering with
how the project is run. Yet, stakeholders are core to the project because it is
their requirements that we are trying to satisfy. We speak about stakeholders
as being only people, but from a system engineering perspective, stakeholders can also be an external system that interfaces with ours, an organization,
a database, standards, bodies, and anything else that might impose requirements or constraints on our project.
Stakeholders come in multiple flavors and sizes. Examples include:
• End users who will actually interact with the product on a daily basis
• Power users who need advanced features in the product
• The people who have to maintain it (e.g., the help desk and infrastructure
support)
108 Chapter 5
• The boss and his or her peers
• Team members who will design and create the product
• The client who is paying for the product
Stakeholder Categories
In order to bring some sanity to this zoo of stakeholders, we can divide stakeholders into active stakeholders and passive stakeholders. An active stakeholder is someone who will interact with the product once it is deployed and operational. Passive stakeholders include groups such as procurement personnel,
standards bodies, and everyone else who is not an active stakeholder.
We can also distinguish a product stakeholder from a project stakeholder. A
product stakeholder is someone such as an end user or client who needs,
uses, and interacts with the product the project is developing. A project
stakeholder is someone who cares about how the project is managed. This
category of stakeholders has little or no input to the requirements. We will
discuss stakeholders in more detail in Chapter 9.
Everyone’s input is important when you are gathering requirements. However, not everyone’s input has equal weight. You must clarify the importance
of stakeholders to the project and to the product while you are getting their
input on requirements. This can be managed by setting up a priority process
for categorizing requirements. Be able to identify which requirements are
critical to the final product, which are less critical, and which are just “desirements” rather than design requirements.
* NOTE
With due respect to George Orwell:
All stakeholders are equal. Some stakeholders are more equal than
others.
Once you’ve gathered your requirements, document them in a requirements
document. This document forms the basis for developing the detailed specifications and the test plans. For each requirement, you want to identify where
the requirement came from, what type of requirement it is, what test case will
test it, and be able to track any change requests against it. If you use the rule
Initiating and Planning Project Scope 109
mentioned earlier about only writing one requirement per paragraph and
then numbering your paragraphs, you will have a built-in tracking system for
your requirements.
Gathering Requirements
Asking users for requirements is like offering to give them an appendectomy.
It is easier for them to write their needs down and assume you will design
what is in their minds. Generally, they do not know how to express what they
want in terms a designer can understand.
People are our best source of requirements for many projects, and there are a
number of ways to gather the requirements—individual user interviews (you
will get great requirements, but it is very time-consuming), group sessions
(just avoid having one or two people dominate the requirements), joint application development (JAD) sessions, or e-mail surveys and questionnaires.
If your project involves business processes, then you might start by doing
business process analysis or examining the concept of operations (ConOps).
Interviews
Interviewing users, either in a group or individually, is tricky. If you ask users
“What do you need,” quite often they will not give you a requirement, but will
state a solution:
• “I need a 25-inch monitor to display all my charts.”
• “I need an Excel spreadsheet to calculate my total sales to date.”
• “I need a convertible to go to work.”
These are solutions, not requirements.
The group that will be doing the interviews should design the questions for
requirements gathering carefully. It is important to understand the psychology of how people answer when you ask them a question. Open-ended questions, where people are free to express themselves, are likely to give you more
information than closed-ended questions where you give them a limited
choice of how to answer.
110 Chapter 5
Examples of some questions are:
• What are your top needs for this product?
• What are the minimal things the product needs to do?
• If the product could provide more features, what would be most useful?
• If you use this product, how quickly should it respond to your inputs?
• How often do you think you would use this product?
• Would you like to be able to customize the product?
• Is the color of the product important to you?
When someone walks into a hardware store and says they want to buy a quarter-inch drill bit, what is the requirement? It is not to buy a quarter-inch drill
bit for the sake of buying a drill bit. The need is for a quarter-inch hole. The
drill bit is the solution. It is up to the questioner to ascertain the real need and
not to settle for a description of a solution.
Here are some interviewing hints:
• Interview every type of user.
• Take them seriously.
• Document the interviews and have the interviewees review them.
• Quickly compile the interviews into requirements, and review the requirements again with the users.
• Make the users aware that the requirements will shape the system.
• Don’t be judgmental about user requirements.
Joint Application Development Sessions (JAD)
A JAD is a facilitated meeting where all key business users participate in identifying the business requirements. At the beginning of the meeting, you will
want to have a working document that contains the high-level requirements
of the application to be developed. This is used as a guide to stimulate user
participation and discussion throughout the session. A JAD session, when
run well, can result in better discussion and synergy than individual meetings
and is far more efficient.
Initiating and Planning Project Scope 111
Other Approaches
In her paper “What a Project Manager Really Needs to Know about Requirements” Rosemary Hossenlopp defines these additional methods of gathering
requirements:5
Brainstorming: Generating ideas, approaches, issues, and gaining consensus on a reduction of ideas that are documented for further project action.
Survey: Administration of a written set of questions to the ­stakeholders to
determine information on customers, work ­ practices, and ­ attitudes. Responses are analyzed for requirements, ­supplemental requirements, and
stakeholder interests and positions. This can also include a review of customer-support user problems and product failure data.
Documentation review: Review of the existing system, business policy,
and contractual documentation. This can include a review of project lessons learned.
Interface analysis: Review of system, people, and process linkages with
the proposed business solution. System interfaces define system interactions, which systems provide input, which ones require output, and what
medium is used.
Supplemental requirements analysis (non-functional requirements):
Review of end-user business solutions quality expectations that constrain
the development of the requirements.
The key to project success is making sure you are using the appropriate requirements gathering process for your project. The more complex the project,
the more conversations the business analyst will need with your stakeholders
to ensure understanding of their needs.
In Practice: ISO Guidelines
The following is an excerpt from ISO guidelines on the development, supply, and
maintenance of software:
ISO-9000-3, Guidelines for the Application of ISO 9001 to the Development,
Supply, and Maintenance of Software, Subpart 5.3.1: “In order to proceed with
software development, the supplier should have a complete, unambiguous set of
112 Chapter 5
functional requirements. In addition, these requirements should include all aspects
necessary to satisfy the purchaser’s need. These may include, but are not limited
to, the following: performance, safety, reliability, security, and privacy. These
requirements should be stated precisely enough so as to allow validation during
product acceptance.”
Go to www.iso.org for more information.
Chapter Summary
• A project charter is the document that officially recognizes that a project
exists. It is issued by a manager outside the project. It gives the project manager the authority to apply organizational resources.
• The value of the project charter is that it is management’s statement to the organization that management supports the project and the project manager.
• Every project should have a kickoff meeting to introduce the project to the
team and the team members to each other. At the end of the meeting, the
team members should understand the scope of the project, their role in the
project, how the project relates to the company’s strategy, the planning
process, and the next steps.
• The scope statement is the planning link between the customer and the
project manager. It is how the project manager knows that there is clear
communication between the customer’s needs, wants, and expectations
and the end product that the project manager is helping to create. It helps
the project manager organize the project management process and creates
a context for the planning process.
• A requirement is a clear statement of a need, sufficiently detailed that there
is no question about what is being asked. Many different kinds of requirements exist, such as functional, technical, performance, interface, look-andfeel, operational, verification, “ilities,” implementation, security, legal, and
privacy requirements.
• Requirements come from stakeholders. It is best to meet with the stakeholders in person and interview them to help define requirements. This can be
done one-on-one or in a group meeting, such as a JAD session.
Initiating and Planning Project Scope 113
Key Terms
Stakeholder
Project charter
Project scope statement
Product scope
Project scope
Project objectives
Project boundaries
Requirement
Functional requirements Performance requirements
Technical requirements Interface requirements
Look-and-feel requirements
Operational requirements
Verification requirements
Implementation requirements
Key Term Quiz
1. ___________________ define what the product must do.
2. ___________________ define how fast, how safely, how securely, etc. the
product must operate.
3. A _____________ is defined as individuals or organizations that are
actively involved in the project, or whose interests may be positively or
negatively affected as a result of project execution or project completion.
4. The __________________ is often considered the official start of the
project. It is the document that authorizes the project and allows the
project manager to apply organizational resources.
5. ______________________ define what is in scope for the project and what
is out of scope.
6. _______________ are the specific measurable results that the organization
is looking for the product to meet.
7. The _________________ defines only the end deliverable and its
components.
114 Chapter 5
8. The _________________ defines the work necessary to deliver the product
scope.
9. The _____________________ helps define what is being developed, and
starts to raise the questions necessary to accurately define what will and
won’t be included as part of the project.
Chapter Review Questions
1. Which document is used to officially recognize that a project exists?
2. What is the purpose of the kickoff meeting?
3. At the end of the kickoff meeting, the team should have a clear
understanding of what?
4. List five items you might find in a project charter.
5. List five items you might find in a project scope statement.
6. Describe the difference between the project charter and the project
scope statement.
7. Describe the difference in product scope and project scope.
8. What is the success rate of IT projects, based on survey results?
a. 85%
b. 50%
c. 15%
d. 67%
9. You are asking a client about an IT requirement, and the client responds
by telling you that it needs 25-inch monitors to display all its charts. The
client is giving you:
a. A valid requirement that you need to document
b. Their feeling about what they need
c. A solution, not a requirement
d. The brushoff
Initiating and Planning Project Scope 115
10. You are asking a client about an IT requirement, and the client responds
by telling you that it needs 25-inch monitors to display all its charts. The
true requirement is:
a. The client wants to display all its charts
b. A 25-inch monitor
c. Unknown
d. Irrelevant, since the solution has already been determined
11. The best source of requirements for an internal process improvement
project will be:
a. The CEO
b. The project sponsor
c. The people who will be affected by the process change
d. All of the above
12. Which of the following is not part of the definition of SMARTT
requirements?
a. Specific
b. Measurable
c. Affordable
d. Realistic
e. Testable
End Notes:
1. Ralph Young, Effective Requirements Practices, Pearson Education 2001.
2. Sheldon, F. et al., “Reliability Measurement from Theory to Practice,” IEEE Software, July
1992
3. B. Boehm, W. Brown, L. Huang, D. Port, “The Schedule as Independent Variable Process for
Acquisition of Software-Intensive Systems,” INCOSE International Conference, Toulouse,
France, June 2004.
4. Project Management Institute (PMI®), A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 3d ed., page 376, Project Management Institute, Newtown Square,
PA, 2004).
5. Rosemary Hossenlopp, “What a Project Manager Really Needs to Know About Requirements,” PMI Global Congress Proceedings, Toronto, Canada, 2005.
10
Project Risk
After reading this chapter, you will be able to:
• Identify sources of project risks.
• Use tools to identify project risks.
• Analyze project risks.
• Develop responses for project risks.
Understanding Project Risk
What is project risk? Does risk entail only the things that can go wrong with
your project? Does it also include things that can go right? How do you identify all the risks lurking out there, just waiting to scuttle your project? If you
do not have enough team members, is that a schedule risk? How do you know
which risks you should respond to and which ones you should monitor? How
can you develop effective responses to risks? These are the critical questions
that risk management tries to answer.
We begin by defining specifically what we mean by a risk. According to the
PMBOK® Guide,1 a risk is an uncertain event that, if it occurs, has a positive or
negative effect on at least one project objective, such as time, cost, scope, or
quality. It is interesting to note that in this definition, a risk can have a positive outcome. Most times, we think of risk as only having negative impacts.
IT project managers barely have enough time to worry about things that can
harm our project, let alone things that can benefit it. If we look at positive
risks as opportunities, we are more likely to look for things that can make our
project more successful—the things that we call positive risks.
In the above paragraph, we said that we were concerned with the outcome if
the risk event actually happens. The risk event itself is not what we are concerned about; it is the outcome—the impact to the project—that we care
about. The impact is the result or possible result that occurs because of the
250 Chapter 10
risk event. Impacts can be felt in the project scope, schedule, budget, and
stakeholder satisfaction. How serious is the impact if the risk happens? How
badly will the schedule or budget be hurt?
In addition to seriousness of the impact, the other aspect to watch in risk
management is the probability of a risk event actually happening—the likelihood that something will occur.
Risks and issues are sometimes confused. A risk is a potential future event. An
issue is something that is occurring right now and has to be dealt with now.
For example, a risk might be a 50 percent chance that our delivery will be late,
causing a one-week delay in the schedule. This is something that could happen in the future, but since it has been identified, we can plan for it. An issue
would be if the delivery truck with critical testing equipment had an accident
on the way to the office and the equipment was destroyed. Now there is a crisis, and the team has to decide how to work around the problem.
By their nature, projects are more susceptible to risk than are normal operations. Projects are unique one-time activities and are not ongoing or repetitive. The team tries to mitigate the risk inherent in projects by developing defined and proven techniques to implement projects. One of those techniques
is methodical risk management. The process of risk management is a very
distinct one that continues throughout the project.
This chapter deals with all the steps necessary to effectively plan for risk.
The steps are most effective when done in a particular order. The first step
is identifying risks, the next is analyzing them, and the third is developing a
response. In the chapter on project monitoring and control, we will look at
how to monitor risks.
We are only discussing qualitative risk analysis in this book. There are many
quantitative techniques, such as Monte Carlo simulations, decision trees, and
statistical computations. We will leave these to the people who analyze risk
on large, complex projects. You can find many books on quantitative techniques for risk analysis if you are interested in learning more.
Sources of Project Risk
Risks occur at multiple levels of the project. Ask team members to identify
risks they see and they are most likely to identify technical risks. Ask the project sponsor and the sponsor is most likely to identify organizational risks.
Project Risk 251
The project manager is able to identify risks regarding the skill sets and experience of the project team. Everyone involved in the project has a different
view of what is risky.
One of the more challenging aspects of risk management is training the team
to address risk in a consistent manner. Another challenge is taking the time
to do risk management methodically and not jump from identifying a risk to
solving it by saying something like, “Oh, don’t worry, I will talk to so-and-so and
make sure that doesn’t happen.” It is human nature, and especially a project
manager’s nature, to try to solve a challenge or a risk once it is identified. How
many times have you heard some version of the following conversation?
Albert: “I think we are at risk for not meeting our deadline on this deliverable.”
Betty: “Oh, we will just work overtime, or we can bring in another person
to help us out.”
What Albert did was identify a risk, and rather than note it as a risk, Betty went
right into solution mode. However, the risk was never documented or analyzed.
Maybe the deliverable was not on the critical path and there was nothing to
worry about. Maybe they assumed a resource would be available when, in fact,
that resource was already overcommitted. Perhaps other team members are
out there doing the same thing, but none of this is documented so that it can be
managed in a coordinated fashion. It is important to keep the risk identification process separate from the analysis and response development process.
Where to begin identifying risks? One way is to develop risk categories. Some
of the common categories in risk management are team members, technology, project management, the organization, and external factors.
Team Members
Since team members do the projects, they can be the biggest source of risk.
Some of that risk is centered on the skills of the team members, specifically
technical skills and people skills, and some of it is centered on their availability.
Skills
On a simple, routine project that uses team members who have already done
that type of work, there is a minimal amount of risk that the team members
252 Chapter 10
will not have the appropriate technical skills for the project. However, not all
projects are simple. In fact, some are highly complex and require advanced
and specialized skills.
Suppose the project is to install a new, fully automated logistics and inventory tracking system for an organization that has over 10,000 products, 200
stores, 10 warehouses, and a fleet of trucks. Moreover, suppose that the project includes replacing all the existing hardware, moving to handheld tracking devices, developing the software for entry, stocking, transfer, and sales,
and training 200 people on the new equipment, processes, maintenance, and
use. This project needs people who are skilled in the system design and capabilities, process development, hardware setup and functionality, software
interfaces and performance, and training and documentation. These needs
provide some juicy resource risks that must be addressed. Because the company has never done this project, it is highly unlikely that all those skills are
in-house. The project manager will have to hire consultants, bring in new
employees, and train existing staff. There are risks inherent in each of those
activities.
In addition to technical skills, the project manager also needs to be aware of
a team member’s ability to work well on a team and as a team member. In
project management, this is referred to as playing well with others. In Chapter 7, we said that it would be preferable to have a team member with average
technical skills and good people skills rather than someone with outstanding
technical skills but poor people skills.
A team member who always sees the negative side of things, is demeaning,
always misses deadlines, or does not treat others with respect is a risk to the
project team. These people lower morale, influence the effectiveness of the
team, and may cause other team members to want to leave the project. By
identifying this risk early, the project manager has the opportunity to correct
the situation or at least be prepared for some of the fallout that may occur.
Availability
With the proliferation of projects in organizations and the ongoing demand
to do more with less, it is not uncommon to have a resource be pulled onto
another project or have a resource’s availability on any particular project be
reduced. In a weak matrix organization, there is a very strong risk of having a
project resource pulled off the project by a functional manager, often without
the project manager even being told that the resource is being removed.
Project Risk 253
Project managers need to pay particular attention to team members who
have skills that are unique in the organization or are in demand for numerous projects. A team member who developed a homegrown application for
the organization and is the only person who really knows how it works is always going to be in demand. Frequently this person will be a bottleneck on a
number of projects. Identifying this resource constraint and risk early in the
project will assist the project manager in planning how to respond to the risk
of the person not being available.
Technical
Technical risks are present in all projects these days. However, they are most
prevalent in IT projects, due to the rapid changes in technology and the fact
that IT touches virtually everyone else in the organization. This creates both
technical and organizational risks.
The larger and more complex the project, the more time and places it has to
fail. Many organizations have learned this lesson the hard way through failed
implementations of ERP systems, CRM systems, and supply chain management systems, and they have begun phasing large projects to limit the probability and impact of failure. After each phase, they reanalyze the needs and
the output of the project and do a lessons-learned exercise to see how to improve performance in the next phase.
There are four aspects to technical risks: technology, testing, technical requirements, and contractor/vendor relationships.
IT Technology Risks
Specific risks are common across most IT projects, regardless of the industry.
For starters, the technology itself is not simple, and when multiple types of
technology from multiple vendors are combined into one system, the end
result can require a lot of testing and integration to ensure that it works properly under all conditions.
For example, in a typical three-tier LAN (Figure 10-1), multiple client machines and peripherals connect to the middle tier, which interfaces with the
data server(s) and the outside world. Each of the different machines might
come from different vendors, creating multiple sources of potential incompatibility. Even individual areas, such as the servers, might come from
254 Chapter 10
Figure 10-1. Three Tier LAN
­ ultiple vendors, like Hewlett Packard, SUN, CISCO, and IBM. An enterprisem
wide system might include databases such as IBM’s DB2, Oracle, MySQL, MS
SQL Server, and Teradata. The network architecture itself, such as Novell or
Microsoft, interacts with virtually all parts of the system. Even more complex
are the systems common at large corporations, where mainframe systems
may be mixed in with the client/server systems.
In Practice: Technical Project Risks
Technical risks can have large impacts, as the following two examples show:
A large U.S. insurance company planned on going live with a systems update at
one of its subsidiaries on July 1. On June 30th it deactivated the old system. Seven
weeks went by before it could mail out premium notices, write commission checks,
or even issue policies. Almost 70 percent of the sales force quit during this period.
A U.S. federal government agency implemented PeopleSoft financials and did such
a poor job of it that the agency went 10 months without being able to generate
a financial report.
Project Risk 255
Requirements-Related IT Risks
The primary risks for requirements center around not identifying the correct
requirements, not identifying the complete requirements, or not making the
requirements clear and unambiguous. Recall from the Standish Company’s
CHAOS Report that the vast majority of projects fail because of problems with
the requirements.
Function and performance requirements are generally considered as risks
associated with scope; therefore, project managers normally depend on the
project sponsor or customer to give them the basic requirements of the system. However, there are technical areas where customers are unable to articulate or even fathom requirements, for example, data security, data privacy
and access, and the increasing level of spam and phishing on the Internet.
These areas are where technical experts must depend on their knowledge to
develop requirements that will go into the final product. These requirements
are often complex and difficult to manage. Because these areas are transparent to the customer (if they are done correctly) special effort must be taken
to bring them to the customer’s attention and ensure they are understood.
Security must automatically just work, despite the technical complexities of
ensuring that it does.
!
WARNING
If you are going to put in a new system that changes how people
work, you will usually have some adoption issues. Twenty percent of
the people will never support it. They do not see a reason to change,
they have always done it this way, and they have years of experience
invested in the current system. Twenty percent of the people will be
on your side because they do not like how the current system works
or they’re so new they have no investment in the current system.
The remaining 60 percent will go either way with the new system. If
you can show them how it benefits them, they will be supportive. If
they feel threatened by it, they will turn against it. Your communications effort should be devoted to capturing the hearts and minds
of that middle 60 percent.
Testing
The complexity of IT systems leads to a particular risk area in managing IT
projects—the danger of cutting testing when the schedule is running tight.
During a normal project, testing and integration are at the far right of the
project schedule. They are often the next-to-last efforts to be completed.
256 Chapter 10
When the project starts running behind schedule, the only activities left to
compress or cut are those remaining on the schedule, such as testing.
A thorough testing program, as shown earlier, is a strong risk-mitigation tool.
The more testing the team does, the more likely the team is to find problems
before implementing the system. Cutting testing, although it may save the
schedule, always increases the risk of releasing a system with undiscovered
problems.
Think about what normally happens on an IT project. During the testing and
integration phase, it is normal to find problems that could not be found earlier. The tester writes a problem report, and the piece of software goes back
to the developer for rework. However, almost nobody plans rework into the
project schedule during the initial planning phase of the project, so this perfectly normal testing activity has now created schedule risks by adding unplanned work!
If the test environment is not architecturally similar to the production environment, there may be integration problems when the product is moved
into production. If there is no time allocated to validate the testing process
and test scripts, the testing team will spend a lot of time trying to determine
if a failed test is due to a true failure of the product or if it’s a false negative
because of the testing process itself.
3 TIP
A good practice is to have a test group that is separate from your
development team. This test group should work on a test platform
that is as close to the production platform as possible. Developers will always test to their own design. The proper way to test is
against the requirements, not against the design. An independent
test group will provide additional viewpoints of the requirements
that the developers may not have considered, and ensure that the
final product will meet the requirements the user specified.
Vendor-Related IT Risks
IT projects rarely develop their basic components from scratch. They usually purchase existing vendor products and integrate them into a final system.
There are several risks associated with this. The first is giving the vendor’s mar-
Project Risk 257
keting literature or sales personnel too much credence. The vendor’s goal is to
sell the product. The project’s goal is to buy something that is cost-efficient and
that satisfies the requirements. Often these are not compatible goals. Many IT
project managers have purchased a vendor product based on assurances by
the vendor’s sales staff that the product will do everything the buyer needs,
only to discover too late that the promised features don’t work, or don’t work in
the buyer’s environment, or the feature is a planned future upgrade.
If a system is provided by multiple vendors, there are problems inherent in
upgrading. If Microsoft upgrades its Windows OS, should the organization:
a.Buy the latest upgrade and install it on each desktop immediately?
b.Wait and read the discussion forums to see problems other people are having with it?
c. Buy it and install it on a test system to check for compatibility with the
organization’s existing applications?
These are all things that the project manager needs to keep in mind. History
shows that once a decision is made to buy a particular vendor’s system, the
IT department is locked into that system for a long time and is forced to deal
with that vendor for many years, because there are significant costs associated with changing core systems.
In Practice: Vendor Risks
In 1999, Nike, the market leader in athletic shoes, began a project to integrate
its supply chain by implementing supply chain management software by i2. The
$300 million project was not, to put it kindly, a complete success and cost Nike
$100 million in lost sales. An issue of CIO magazine had an article analyzing the
project. “Nike’s supply chain project is supposed to drive the manufacturing cycle
for a sneaker down from nine months to six. Cutting out that three months would
match Nike’s manufacturing cycle to its retailers’ ordering schedule—they order 90
percent of their sneakers six months in advance of delivery. This means Nike could
begin manufacturing its sneakers to order rather than three months in advance
and then hoping they can sell them. Converting the supply chain from make-tosell to make-to-order is the dream of any company desirous of gaining competitive
advantage through its supply chain. Dell has done it, famously, with PCs; Nike
wants to do it just as famously with sneakers.
258 Chapter 10
“Wolfram [Nike’s VP of Global Operations and Technology] called the i2 problem—
a software glitch that cost Nike more than $100 million in lost sales, depressed its
stock price by 20 percent, triggered a flurry of class-action lawsuits, and caused its
chairman, president and CEO, Phil Knight, to lament famously, ‘This is what you
get for $400 million, huh?’—a ‘speed bump.’”2
Another vendor-related risk occurs when part of the project is developed
offshore in order to save on personnel costs during development. Although
cheaper programmer salaries are available by offshoring, the cost savings are
often offset by the increased amount of effort required to develop the business
and technical requirements, the more thorough testing required to ensure the
delivered product will actually work in the technical environment, and rework
due to communications problems. It is hard enough to develop clear understanding in a culture with a common language. Communications problems are
exacerbated when working cross culturally and any misunderstanding of the
requirements has the potential to increase project risk significantly.
Project Management-Related Risks
Risk related to project management has four sub-categories: scope, schedule,
cost, and project management itself.
Scope
Poor requirements gathering, unclear requirements, or changing requirements significantly increase risk and are the main reasons that projects fail.
One area where project managers often do a poor job is in identifying the
user’s performance expectations for the new system. The project team can
install the most up-to-date hardware and software available, but if users have
to wait five minutes for applications to open, they will be very unhappy. If an
SQL query to report on last week’s sales takes 24 hours to run, the sales managers are going to stop using the system. Performance expectations must be
identified as part of the requirements process so they can be designed into
the system. These performance requirements can have major impacts on the
design of the system and may lead to major redesign if the user is not happy.
Failure to educate stakeholders on how to describe their needs and wants can
lead to multiple scope risks.
Perhaps saying that change is inevitable on projects is an overstatement, but
change is certainly the norm. There are risks involved in locking down the
Project Risk 259
design too early, and there are risks involved in keeping the design open too
long. Not having a formalized change management program is a sure way
to put the scope and schedule at risk. What good is a baseline if there are no
teeth to keep it in place? Having a change management program that is just
a series of forms to complete before accepting the change is almost as bad. A
good change management program screens out unnecessary changes and allows the beneficial ones, ensuring that the scope, schedule, and budget baselines are updated in the process. Chapter 13 covers this in more detail, but for
now, suffice to say that change involves risk.
In Practice:
Requirements Risks in IT Projects
Experience shows that up to 70 percent of IT project failures result from poor
requirements gathering, analysis, and management. Even in the ‘80s, we knew
that more than 50 percent of all software defects could be traced to requirements
errors. These figures on the risks of not having strong requirements have held up
consistently in research.
Schedule
Most schedule risks are a result of overly optimistic estimates. Sometimes
the estimates come from team members who think that everything will go as
planned and assume they will not be sidetracked or need to rework anything.
Other times the estimates come from senior management defining a hard end
date or looking at a schedule and then arbitrarily reducing it by some amount
and calling it a “challenge.” Project managers should review the estimates for
each task, the critical and near critical paths, and the project as a whole to see
if the estimates are realistic or if some estimates need a reality check.
Another type of schedule risk is called merge bias. On the network diagram,
when two (or more) activities are predecessors to a later activity, a delay in
any one of the predecessors can delay the successor activity. The additional
schedule risk at this merge point is called merge bias. Let’s say that unit testing, system testing, and load testing need to be complete before integration
testing can begin. Testing is difficult to predict duration estimates for. Therefore, assume that for each of these tests there is about a 75 percent certainty
that the testing will be complete on or before the date on the schedule. Does
this mean that there’s a 75 percent chance that integration testing will start
on its estimated start date? The answer is no, because if each task has only a
75 percent likelihood of ending on its scheduled date, then the likelihood of
260 Chapter 10
the whole path having an on-time completion is .75 × .75 × .75, or .42. There is
a less than 50 percent chance integration testing will start on schedule based
on the above information. That is a significant schedule risk.
We will talk about finalizing the schedule in the next chapter. For now, we will
just touch on two ways of compressing the schedule: crashing and fast-tracking. Crashing is the process of reducing the duration of tasks on the critical
path to get the project done faster. Fast-tracking is doing tasks in parallel that
would normally be done sequentially. Both of these, although shortening the
schedule, introduce risk, because you are performing tasks in a way that is
not optimal. In addition, if you are crashing by adding people, you are adding
complexity in the communication structure and increasing the probability
that there will be a miscommunication leading to rework, a delay, or worse.
Another schedule risk can occur when team members are rushed to get a
project done quickly, either because there is another project they are expected to start working on or because they are working on multiple projects and
trying to get through them as fast as possible.
Budget
Common project budget risks include predefined budgets, poor cost estimates, and overly optimistic cost estimates. Predefined budgets are far too
common in IT. They occur when the project manager is given the project
and the budget at the same time (often with a pre-defined schedule as well).
The budget was determined by management using no analysis (it is usually
someone’s best guess at what the project should cost) and now you have to
live with it.
Poor cost estimates are those that are developed without the proper research.
We talked about different types of estimates in Chapter 6: analogous, parametric, and bottom-up. Anything other than a recently developed bottomup budget carries a risk that it may not be met. We also talked about levels
of accuracy—ROM, approximate, and budget-level estimates. A ROM and an
approximate estimate are risky because they have a good chance of being
inaccurate. Poor cost estimates often derive from poor schedule estimates.
Underestimating the duration of the project is almost guaranteed to lead to
an underestimate of the costs, as resources are kept on longer than planned.
Project Risk 261
Overly optimistic cost estimates are similar to overly optimistic schedule estimates. The risk can lie with the team members who gave the estimate, with
a project manager who believes he or she is making management happy with
a low budget number, or with management that is looking for cost to be reduced without scope being reduced.
Project Management
Project management risks include poor project manager skills and insufficient experience as well as inadequate project management infrastructure,
processes, templates, and methodologies.
An inexperienced project manager, or one who is new to the company or
the technology, is a risk. There are many opportunities for that project manager to make a wrong decision. A common problem in IT project management is promoting a strong technical person into a project management
role without proper training or guidance. The skills and knowledge required
to manage a project are very different from those required to be a good architect or programmer.
Having a solid project management methodology with well-established processes, approaches, and templates can reduce some of the variability of project management results. It can make things easier for project managers, as
they do not have to reinvent the wheel for every project. The methodology
gives them a path to follow. They know what steps to take, where to coordinate, where to find document templates, how to communicate, what the
metrics are, and so on. Much of the guesswork is taken out of managing projects. However, a methodology that is too prescriptive, that is wrong for this
type of project, or that is not adaptable to project size and complexity may
be worse than no methodology at all. Additionally, if the methodology is too
clunky or too bureaucratic, then project managers will see it as a hindrance
and not really use it. Remember, each project is unique. Established methodology should be a guideline, not a railroad track.
Organization
The organization in which the project is being performed carries with it its
own set of risks. Take, for instance, the organizational structure. If it is a func-
262 Chapter 10
tional organization, there is the risk that the project’s needs will be put on
the back burner and that the project manager will not have the influence or
authority to get the project done well. A matrix environment has risks with
conflict over resources and unclear performance or reporting priorities.
Another aspect of organizational structure to keep in mind is the different categories of team members and their various backgrounds. Some team members
may be exempt and be strictly salaried. Others may be contractors from outside the organization. In large organizations, with large projects, there may be
unionized team members who are paid hourly. In this case, there is the risk of
going over budget if the need arises to pay overtime for hourly workers; even
worse, there is the risk of losing some workers if a strike occurs.
Another set of risks revolves around the culture in the organization. Some
organizations are so risk averse they suffer from analysis paralysis. They’re
afraid of making the wrong decision, so they want to think everything through
again, and again, and again. Others have an entrepreneurial, shoot-from-thehip culture. Some organizations believe that all decisions should be made
collaboratively, and some have a very dictatorial decision-making process.
Each of these cultures presents different risks to the project.
An organizational risk that is quite common is changing priorities. Sometimes this is called project du jour, or project of the day. Sometimes it seems
that resources are moved from project to project on a monthly basis. What
was important in June is yesterday’s news in July, and the resources are pulled
from the has-been projects one-by-one, until yesterday’s projects slowly suffocate or produce a shadow of their original scope.
!
WARNING
Take care how you identify organizational risks. Some organizations recognize their weaknesses and can even laugh at them. But
in some organizations and some cultures, just mentioning risk is taboo. In these cultures, if you state that you have risk on the project,
you’re labeled a bad project manager. There is risk in every project;
you just have to be sensitive to how you phrase it. There’s an old adage: “It’s not what you say, it’s how you say it.”
Project Risk 263
External
External risks are risks that are outside the project and maybe outside the
organization; these are often out of our control. Risks external to the project
include those that have been mentioned in previous sections: competition
for resources, shifting or competing priorities, budget cuts, etc.
Risks that are external to the organization include new regulations, weather,
changes to the price of a required material or resource, changes with an external client organization, labor strikes, and so on. The project manager will
need to do some of the proverbial outside the box thinking to identify these
types of risks.
Risk Identification Tools
From reading the previous section, it should be clear that risks are, in fact,
everywhere. Right about now you may be thinking, “How can I possibly identify all the possible risks?” Well, fear not—this section has some tools that will
help you.
Project Documents
One of the easiest places to look for risks is the project plan. The project charter
will have assumptions, constraints, and any high-level risks in it. The assumption log is also a very good place to start looking for risks. Anything that is an
assumption is a risk, because the project team members don’t know for certain
it is true, but they are planning as if it were. What if this is not the case?
Also, are the assumptions consistent throughout your project documents? Let’s
say that the assumption log shows that the project has a certain resource 50
percent of the time, but the schedule shows the person allocated 100 percent of
the time. This is inconsistent, and one of the documents is inaccurate.
Identified constraints should also be reviewed. For instance, with a mandated due date, a pre-defined budget, or a level of performance, risk exists
because the constraint may not be feasible and failure to meet the constraint
could cause the project to fail. A project manager who receives the project’s
264 Chapter 10
delivery date and budget at the same time he or she learns about the project
will automatically have schedule risks and cost risks because the numbers for
schedule and cost were determined without detailed analysis.
Technical documentation is a good source for identifying technical risks. The
project manager will find requirements, details on specific technology, detailed design documents, and more in the technical documents. These documents are fertile ground for identifying aspects of the project that could cause
a negative impact.
One of the best sources for risk identification in the project scope is the WBS.
The WBS allows the project manager to see all the activities and deliverables
in the project at a glance. The project manager can see risks at the deliverable
level or at the higher levels, so the project manager gets a holistic view of the
project and can spot any systemic risks.
Performing a schedule review can help identify risks to the project’s schedule—risks to milestones and the promised delivery date. It can also help identify inaccurate duration estimates, missing dependencies, and other schedule
problems. In addition, the schedule usually shows assigned resources. The
project manager should look at the resource view of the schedule and identify
any resources that are over allocated. Any directed dates are possible risks. A
directed date is a date in the schedule that was not derived from the logic of
the schedule. Other schedule risk items are having too many activities flow
into a single successor or having one activity with too many successors. If a
critical path activity is dependent on ten direct predecessors, there is likely
a schedule risk, because the probability of that many predecessors staying
exactly on schedule is very slight.
Similarly, the project budget will help to identify cost estimates that may be
inaccurate, or times when cash flow is likely to be steeper than originally estimated. Comparing the budget to the schedule, the resource list, assumptions, and constraints may enable the project manager to find some inconsistencies that present a risk to the project.
Finally, look at any contracts for the project. There may be penalty clauses,
constraints, or other verbiage that indicates a challenge in meeting project
objectives.
Project Risk 265
Interviews
Usually the people who know the most about project risks are the people who
are working on the project—the team members. The project manager can
take time to interview them one-on-one or have a team meeting dedicated to
identifying project risks. During the interview process, the project manager
should use some of the tools described above, such as reviewing the technical documentation with the technical team lead or resource allocation with
functional managers.
3 TIP
When interviewing project stakeholders to identify risks, two of the
best questions you can ask are “What would you be worried about if
you were managing this project?” and “What should I be concerned
about that I have not yet identified?”
Risk Breakdown Structure
One of the modern risk gurus, Dr. David Hillson, has developed a tool called a
risk breakdown structure (RBS). He describes an RBS as “A source-oriented
grouping of project risks that organizes and defines the total risk exposure of
the project. Each descending level represents an increasingly detailed definition of sources of risk to the project.”3 It is similar to the tree format of a WBS
in that it is a hierarchical structure, but it is concerned with areas of potential
risk sources rather than deliverables.
A key benefit of using an RBS in the risk identification process is that it allows
the team to brainstorm project specific risks in a structured way. This facilitates a thorough and organized depiction of risk for the project.
Dr. Hillson produced a generic RBS based on a joint research project undertaken by the PMI® Risk Specific Interest Group and the International Council
on Systems Engineering (INCOSE). This RBS is presented in Figure 10-2.
Facilities/site
Local services
Contractual
Requirements
definition and
stability
Organizational
stability
Financial
Physical
environment
History/
experience/
culture
History/
experience/
culture
Natural
environment
Customer &
stakeholder
Corporate
Management
Figure 10-2. Generic Risk Breakdown Structure
Interest groups
Legal/regulatory
Political
Cultural
External
Project
Project Risk
Risk
Financial market
Labor conditions
Labor market
Economic
Complexity
Conditions of use
Scope uncertainty
Requirements
Technology limits
Technology
maturity
Performance
Technology
Physical resources
Personnel skill
sets and
experience
Organizational
experience
Application
266 Chapter 10
Project Risk 267
In Practice
Dr. Hillson created the following project RBS for defense software development.
It was first published in the June 2003 issue of Journal of Facilities Management.
More information on risk can be found in Dr. Hillson’s book Effective Opportunity
Management for Projects: Exploiting Positive Risk. There are also many interesting
articles on his web site: www.risk-doctor.com.
Project
Project Risk
Risk
Product
Engineering
Development
Environment
Program
Constraints
Requirements
Development
process
Resources
Design
Development
system
Contracts
Code and
unit test
Management
process
Program
interfaces
Integration test
Management
methods
Engineering
specialties
Work
environment
Software Development Risk Breakdown Structure
PM in Action!
Create a generic risk breakdown structure for your organization and for the types
of projects you usually work on.
Brainstorming
Brainstorming is probably the most common way to identify risks. The project manager gathers the project team, technical experts, the client, the project sponsor, and anyone else who can provide input, and the team starts generating ideas on possible project risks. The project manager or facilitator can
268 Chapter 10
use a “blue sky” approach to begin, where people blurt out any risk they can
think of without regard for how reasonable or critical it is. That evaluation is
done as a separate step. If it helps the process, the project manager can create
a RBS to use as a guide.
Once there is a comprehensive list of risks, the team starts to identify how
probable they are and what the impact might be. This process is covered in
the section on risk analysis.
3 TIP
If your organization does the same types of projects on a regular basis, it would be worthwhile to develop a risk identification checklist
or template that will guide the project manager and the risk manager in identifying the typical risks associated with IT projects in
the organization.
Documenting Project Risks
Risk statements and the risk register are used to document project risks.
The Risk Statement
Risk statements should be as specific as possible. There is no way to identify a response to a vague risk statement like “milestone XYZ may be late.”
The milestone being late is the effect; the risk statement doesn’t say anything
about the cause of the risk. Therefore, there is no viable action to take to respond to the risk. Another example of a vague risk statement is “technical
specifications may be at risk.” Now, what does that mean? What about the
technical specifications? Which ones? What are they going to do—swallow
the project whole? You get the idea. Risk statements should be phrased in
such a way that they give clear and useful information about the risk event
and the possible impact.
When writing a risk statement, start by describing the event as specifically
as possible, then explain the impact and state the cause of the risk. For example, “The shipment of monitors could be late due to a backlog at the vendor’s warehouse, causing a delay in opening the office.” At the beginning of
a project, you are looking for anything that could negatively affect the proj-
Project Risk 269
ect. As you enter the execution portion of the project, your risks may become
more detailed, which is why it is important that risk processes be conducted
throughout the project, not just once or twice at the beginning. Do not try to
include in the risk statement the possible response to the risk or any ideas
on how to mitigate it. Those are written separately. At this point, you may
not know the likelihood that the monitors will be late, and you may not know
how late they may be. This information can be elaborated as you analyze the
identified risks. For now, it is enough to identify risks to the project.
The Risk Register
The output deliverable from the risk identification process is the risk register. At this point, it is where the team lists the risks it has identified along with
their priorities, potential responses to them, and the root causes of the risks.
The risk register is usually created in an MS Excel spreadsheet or an MS Word
table and is sometimes referred to as the risk log. Some enterprising individuals create a risk database so they can slice and dice the risk information.
The first items to go into the risk register are the list of risks, their probabilities, and their potential impacts. This is where the risk register starts during
the project planning phase. As the risk management process continues, the
risk register expands to include the personnel identified to respond to that risk
if it occurs. It also expands to include the response strategies, actions, symptoms, and warning signs that tell us the risk is occurring (called trigger events),
the contingency reserves that have been set aside, the secondary and residual
risks, and other information the project manager feels is appropriate to manage the project risks. Figure 10-3 shows a sample format of a risk register.
The risk register is the tool that pulls everything together. The identified risks
are entered into the register in the beginning of the process. After the analysis
process, the probability and impact are added. During the response phase,
an action is entered and a responsible party assigned. The best person to assign to a risk is the person who has the most influence over the event.
Analyzing Project Risks
At this point, you have identified a whole pile of risks. In fact, you may have
so many risks that you’re thinking, “What are we, nuts? This project will never
turn out!” Don’t worry. Remember that these are only things that could hap-
270 Chapter 10
Figure 10-3. Project Risk Register Template
pen. The good news is that you have identified the risks. Consider this: if you
don’t manage risks, you remain at their mercy.
Now you are going to analyze and rank your risks. This is a relatively easy
process compared with trying to capture the risks. You are now going to take
each risk that you entered into your risk register and define the probability of
the risk occurring and the impact if it does occur. Before we review the steps
involved in risk analysis, let’s look at some of the finer points of assessing
probability and impact.
Assessing Probability
For our purposes, we are going to keep the analysis relatively simple and assume that the probability of something occurring is high, medium, or low.
This rough estimation works well for most IT projects (the exceptions are
when you’re doing something as complex as an ERP or SCM implementation). In order to ensure that everyone involved in the risk process ranks risk
in approximately the same manner, it is useful to create some guidelines for
Project Risk 271
the project that establish what is meant by high, medium, and low. For example, guidelines could set high probability at a 60 percent or more likelihood,
medium probability at 20 to 60 percent, and low probability at less than 20
percent. A more conservative organization may set high probability at 40 percent and set low probability at 10 percent or less.
!
WARNING
Stakeholders have different levels of risk tolerance. Your sponsor
may be a risk-taking cowboy kind of person. However, your customer may be somewhat risk averse. Your job is to figure out how to
balance these perspectives and come up with the right level of risk
tolerance. Remember, we never said this would be easy!
The probability assessment may be somewhat subjective, a gut feel of what’s
risky based on experience. This is an acceptable approach on small, noncritical projects. On larger, complex, and critical projects, the project manager
will need to take a more objective approach. He or she may interview experts
to get an opinion on the
probability. He or she may
run simulations or establish some statistical meaThink of some of the projects you have
surements to assess the
worked on and the various stakeholders’
likelihood of a risk occurattitudes towards risk. Can you identify
ring. These are all necesany situations where different risk attitudes
sary approaches for large
created conflict?
projects; however, they are
beyond the scope of this
book.
What Do You Think?
Assessing Impact
As in probability, the project manager can assess impact as being high, medium, or low. When assessing the impact of a risk, defining impact in different areas is useful to keep the risk register organized and precise. Consider
using the areas of schedule risk, scope/performance/quality (SPQ) risk, budget risk, and stakeholder satisfaction risk as impact categories in the register.
Most risks will affect many or all of these areas, but the primary impact will
be in one area.
272 Chapter 10
Schedule Risk
In most IT projects, schedule risk is created by one of three things: the schedule was dictated by management or by the client without regard to the amount
of work involved; the productivity of the resources was underestimated so the
work will progress slower than planned; or critical-path tasks were underestimated. All of these create risk to the schedule.
When assessing the severity of the impact for the schedule, consider anything that will affect the critical path as a high risk. The merging of several
paths onto the critical path, a resource that is in short supply and is assigned
to tasks that are on the critical path, or any other number of circumstances
could affect the critical path. A medium risk could be something that minimally affects a near critical path or something that would use up a significant
amount of float on a noncritical path. A low risk would be something that has
a negligible affect on a noncritical path.
Scope/Performance/Quality Risk
Scope/performance/quality (SQP) risks are associated with product requirements, scope, product performance to specifications, and deliverables. Unclear, unstable, or incomplete requirements, components that are not going
to meet the performance requirements, and untried or unstable technology
create high SPQ risk. Technology that has been proven in the market but that
your company doesn’t have a great deal of experience with creates medium
risk. Proven technology used in a new way might create low risk.
Budget Risk
Budget risks are typically created by the same factors that create schedule risk:
the budget was dictated without regard to the amount of work to be done,
the schedule was underestimated and the project will require more work and
more money than planned, or the cost of materials was underestimated.
When there is potential for budget impacts due to risks, there are two basic
approaches to plan for it. The first is to set aside a fixed dollar amount to
compensate for the risk, such as having a $50,000 contingency fund. The
second is to take some percentage of the project budget and set it aside for
risk response. For example, a high-risk project might require a contingency
fund of 50% or more of the entire project budget, whereas a lower risk project might only require 10% of the budget be set aside for risk contingency.
Project Risk 273
Stakeholder Satisfaction
Stakeholder satisfaction is concerned with the customer, end-user, sponsor,
team members, and any other significant stakeholders on the project. Remember, it is not okay to meet all of the project specifications if the client is
unhappy at the end of the project.
The real question is how to identify stakeholder satisfaction as a risk item and
identify the impact on the project. Unhappy or unmotivated team members
can cause schedule and budget problems. A difficult client who expresses
dissatisfaction with the product being developed can halt the entire project.
The end-users may not use the new application. A project sponsor who is not
happy with progress can demand additional communications and reporting,
putting more work on the project manager and on the team members. All of
these are potential risk areas for the project and can be identified during risk
analysis efforts.
In Practice:
Typical Impacts of Risks on IT Projects
Experience has shown that the most common impacts for IT projects are:
• Cost and schedule overruns
• Technical performance that does not meet expectations
• Incompatibility of the new system with the existing infrastructure
• Process changes that were not taken into account in the organization
• Users who are unable or unwilling to use the new system
• Failure to obtain all or many of the expected benefits because of implementation
problems
A Risk Analysis Process
When performing a risk analysis there are some simple guidelines to follow:
1.Keep the risks in the categories established for risk identification. Whether
an RBS or another categorization technique is used, analyzing by category
is a good idea.
2.Assess the probability of each event occurring using high, medium, and low
rankings. For a medium or large project, it may be appropriate to be more
274 Chapter 10
sophisticated and establish risk rankings of 1 to 5 or 1 to 10. In either case,
guidelines should be established that define what the ranking means.
3.Assess the impact of the event occurring. Use the following categories for
impact: schedule impact, cost impact, scope/performance impact, and
stakeholder satisfaction impact. On a medium or large project, establish
guidelines that indicate what each ranking means against these categories.
4.Sort the list by RBS (or whatever categorization scheme you have established) then by severity. Start with the high probability and high impact at
the top of each category, then medium probability and high impact, then
high probability and medium impact, and so forth until you arrive at the
bottom where there are events with low probability and impact. The result
is a prioritized set of risks against which you develop responses.
PM In Action!
Grid computing is being used more and more for high performance computing.
When using many smaller computers to do what mainframes have done in the
past, some risks are reduced and others are introduced. Go onto the Internet and
learn more about grid computing (if you need to). Assume you have a project to
move a 400-bed medical school hospital from a mainframe environment to a grid
environment. Create a risk breakdown structure to at least four levels. Identify
15–25 risks that you identified using the risk breakdown structure.
Risk Analysis Tools
A number of tools, both manual and automated, can assist you in analyzing
risks. The specific tools you can use are highly dependent on the type of project and the extent of the risks you anticipate. Three of the most commonly
used tools are a preliminary risk analysis, a probability-impact matrix, and a
project risk profile.
A Preliminary Risk Analysis
In the book Corporate Information Systems Management, Cash, McFarlan, and
McKenney determined that during the early stages of a project, such as during
the project selection process, there are three primary risk control factors: 4
• Experience with the technology
Project Risk 275
• Project size
• Project structure
Using this risk framework, a project manager can characterize IT projects according to their level or risk based on size, technology, and structure.
Low Technology
High Technology
Low Structure
High Structure
Large project
Low risk
Low risk
Small project
Very low risk
very low risk
Large project
Very high risk
Medium risk
Small project
High risk
Medium-low risk
While the specific determination of each of these terms will be dependent on
the company and on the project, Cash, McFarlan, and McKenney describe
the terms as follows:
• Low technology: The technology is familiar to the company and does not
represent a drastic change from the way things are now. It is evolutionary
technology.
• High technology: The technology of the project is unfamiliar to the company and to the project team. A substantial learning curve could exist. This
is revolutionary technology.
• Low structure: The project is poorly organized, with a high likelihood of
changes that will change the requirements or possibly the entire focus of
the project. Often the goals are not clear at the beginning of the project and
continually evolve throughout the project.
• High structure: The project is well-organized with clearly defined outputs.
Management is unlikely to request changes during the project.
Using the structure vs. technology matrix above, we can define four high-level categories of projects:
Low Structure-Low Technology
• These projects are low risk when good project management processes are
used.
276 Chapter 10
• Gaining high-level support is important.
• The project manager must periodically evaluate the project to ensure it
still satisfies the business goals.
• Continual communication is critical to ensure management is aware of
project status and issues.
• Staying within cost and schedule constraints is important.
• Because of the low structure, change requests will be common on the
project.
• Project leadership must come from the business side instead of the technical side to compensate for the low structure.
Low Structure-High Technology
• Because of the low structure, the project deliverables and goals are not
clear in the early phases.
• The combination of high technical complexity and low structure makes
this a very high risk project.
• The project manager and team leads require technical experience in the
technology and in working on high risk projects.
• Early management commitment to the requirements, design, and specifications is critical.
• Because of the low structure, the project can expect many change requests.
• Automated project management tools are of limited utility, since their usefulness depends on strong project management processes in order to be
effective.
• The project manager must evaluate the project regularly to ensure it meets
management’s expectations. If needed, the project may be broken into multiple subprojects or a phased set of upgrades to deliver full functionality.
High Structure-Low Technology
• The strong project structure makes these the easiest to manage with the
lowest risk.
Project Risk 277
• The project is likely to adhere to deadlines and schedule.
• Goals and activities are well-defined and rarely change through the project.
• The low level of technology means that there is not a steep learning curve
to becoming productive.
• The project manager does not need a high level of experience with the
technology.
High Structure-High Technology
• The strong project structure means that tasks and activities are well-defined.
• Interaction with end-users will be very important due to the new technology being introduced.
• Change occurs more often than in low-technology projects, but the
strong project structure will have a strong change management process
built into it.
• The project manager and the team leads need strong technical backgrounds in addition to experience in managing complex projects.
• Teamwork becomes critical on these projects.
Probability-Impact Matrix
A probability-impact matrix is a good way to get a visual representation of
the project risks. After identifying the risks, the project manager assesses the
probability and impact of each risk and then plots it on the matrix. Doing so
can give the project manager an overall view of the project. A probability-impact matrix is also a useful tool to use in a project team meeting when doing
a group risk analysis. (See Figure 10-4.)
Project Risk Profile Form
Figure 10-5 shows a project risk profile form for IT projects. It has categories,
scores, weights, and definitions of overall project risk. This is a good start for
both risk identification and risk analysis. Use Figure 10-5 as a template; you
can customize it for your organization and your project. This form can be
used in the project selection process as well.
278 Chapter 10
Figure 10-4. Probability-Impact Matrix
Low Impact
High Probability
Medium Impact
High Probability
High Impact
High Probability
Low Impact
Medium Probability
Medium Impact
Medium Probability
High Impact
Medium Probability
Low Impact
Low Probability
Medium Impact
Low Probability
High Impact
Low Probability
Figure 10-5. New Project Risk Profile—Technical Risk
Project Name:_ ___________________________________ Project #:__________________________
Project Manager:__________________________________ Date:_ ____________________________
Client:___________________________________________
Project Total Risk Score*:
0
Risk
Risk Area
Weight
Technology
1. Non-standard hardware required
a. None
b. Servers
c. Peripherals
5
d. Clients
e. Routers
f. Unknown
Risk
Score
0
High - 3
High - 3
High - 3
High - 3
High - 3
2. Team has little experience with the software
a. Not Applicable
b. Programming language
c. Data base
5
d. Data Communications
e. Other - specify (Unknown)
0
High - 3
High - 3
High - 3
High - 3
3. The system will use state of the art components
a. Yes
3
b. No
High - 3
Low - 1
Area
Score
Project Risk 279
Figure 10-5. New Project Risk Profile—Technical Risk (continued)
Risk
Risk Area
Weight
Technology
4. The user/client has experience in the new system
a. No experience, brand new to them
b. Some limited knowledge or experience
5
c. Familiar with the technology
Risk
Score
High - 3
Med - 2
Low - 1
5. Number of vendors that are involved in the new system
a. One
b. Two
c. Three or more
2
d. Unknown
Low - 1
Med - 2
High - 3
High - 3
Project Size
6. Total development man-hours for the System
a. 100 to 1,00
5
b. 1,000 to 5,000
c. 5,000 to 50,000
d. Over 50,000
Low - 1
Med - 2
Med - 3
High - 4
7. Total system development duration
a. 12 months or less
4
b. 13 months to 24 months
c. Over 24 months
Low - 1
Med - 2
High - 3
8. The work will be performed by:
a. Mostly by on-site personnel
2
b. Significant portions by on-site personnel
c. Mostly by off-site personnel
d. Mostly by offshore personnel
e. A combination of on-site and off-side personnel
Low - 1
Med - 2
High - 3
High - 4
High - 4
9. Number of departments (other than IT) involved with the system:
a. One
4
b. Two
c. Three or more
Low - 1
Med - 2
High - 3
10. Approximate number of end users
a. Up to 25
1
b. 25–50
c. Over 50
Low - 1
Med - 2
High - 3
11. Number of geographic locations in which the system will operate
a. One
2
b. Two or three
c. More than three
Low - 1
Med - 2
High - 3
12. Number of existing IT systems the new system will interface with
a. None
3
b. One
c. Two
d. More than two
Low - 1
Low - 1
Med - 2
High - 3
Area
Score
280 Chapter 10
Figure 10-5. New Project Risk Profile—Technical Risk (continued)
Risk Area
System
Risk
Weight
Risk
Score
13. The new system
a. Totally new system
b. Replacement of an existing manual system
1
c. Replacement of an existing automated system
High - 3
Med - 2
Low - 1
14. If a replacement system, the percent of existing functions that will be replaced on a one-to-one basis
a. 0–24
b. 25–50
5
c. 50–100
d. Unknown
High - 3
Med - 2
Low - 1
High - 3
15. The severity of process changes needed for the new system
a. Low - 1
b. Medium - 2
5
c. High - 3
d. Unknown
Low - 1
Med - 2
High - 3
High - 3
16. User organization changes needed to utilize the new system
a. None
b. Minimal
c. Somewhat
5
d. Major
e. Unknown
0
Low - 1
Med - 2
High - 3
High - 3
17. Comfort level of the users/client
a. Poor - resents the change
b. Fair - some reluctance
5
c. Good - looks forward to the change
High - 3
Med - 2
0
18. Upper-level user management commitment to the system
a. Somewhat reluctant, there are internal politices
b. Adequate
5
c. Extremely enthusiastic
High - 3
Med - 2
0
19. Client/user is actively represented on the project team
a. None
b. Part-time user representative appointed
5
c. Full-time user representative appointed
High - 3
Med - 2
Low - 1
20. The new system implementation will be
a. A phased implementation
4
b. Done all at once
Low - 1
High - 4
21. There is a backup system available (even a manual one)
a. Yes
3
b. No
Low - 1
Med - 2
22. The project team includes members with experience in the relevant business processes
a. Yes
4
b. No
Low - 1
High - 4
Area
Score
*In order to obtain the final score, multiply the Risk Weight with the Risk Score for each question. Add these totals.
High Risk is greater than 166; Medium Risk is between 140 and 166; Low Risk is less than 140.
Project Risk 281
Planning for Risk Response
Identifying and analyzing risk is only part of the process. The next step is figuring out how to respond to the risk. For positive risks (opportunities), the
possible responses are to exploit the opportunity and use it, share the opportunity with someone who can take advantage of it better than you can,
enhance the opportunity and increase the probability of it happening and
the impact if it does happen, or simply accept it.
For negative risk, the possible responses are to avoid the risk, mitigate the
risk, transfer the risk, or accept the risk.
Negative Risks
The following sections provide information on avoiding, mitigating, transferring, and accepting risk—your four choices when it comes to managing
negative risk.
Avoiding Risk
Avoiding risk involves making a change to the project or to the product that
gets rid of the risk. Let’s say that for your project you plan to use a new suite of
software test tools to help run test scenarios for a new application you are developing. Your lead tester has identified this as a risk and has written the following risk statement: “There is a risk that the testing phase will not complete
on time because the testing staff is unfamiliar with the new testing suite.”
One option you have is to test using the prior tool, which avoids the risk altogether because the testing staff is familiar with the process.
Whenever possible, you should avoid risks that have high impact and high or
medium probability.
Mitigating Risk
Mitigating a risk means reducing the probability that the risk will occur, reducing the impact that it will cause if it does occur, or both of these. If we return to
our example of the new software test suite, you can find ways to mitigate the
situation. For instance, you can send some staff to training on the new software
or you can run parallel tests with the old system and the new system. Another
option is to build in more time for the testing process. This is called adding
schedule reserve, and we will discuss it in more detail shortly.
282 Chapter 10
You should mitigate risks down to an acceptable level in your project. For
instance, if you originally decided that this risk had a medium impact and
a high probability, perhaps sending people to training and running the two
testing plans in parallel will bring this down to a low probability and a medium impact.
3 TIP
When developing risk responses, look for root causes to a series of
risks. Sometimes you can find one event that can potentially cause
a myriad of risks. If you can address one root cause and thereby
eliminate or reduce a series of risks, that is wise risk management!
Transferring Risk
By transferring risk, you are transferring the responsibility for managing the
event. For example, in the testing scenario, perhaps you can bring in a consultant who is familiar with the new software to manage the process. This
transfers, via a contract, the risk of meeting the timeline to the consultant.
However, the interesting thing about transferring risk is that you are still left
with some impact if it occurs. In other words, if the consultant delivers late,
you still have a late project. However, by transferring it, you reduce the probability of the risk happening and the impact if it does happen.
Contracts and insurance are the most common methods of transferring risk. If
you choose to transfer risk, make sure you are transferring it to someone who
has the ability to reduce the probability and, if possible, the impact. Know
that you will have secondary risks that arise out of transferring the risk.
Accepting Risk
You may decide to accept a risk if it is a low impact and a low probability risk.
Mitigating the risk may be more trouble than just dealing with it if it arises, or
you may mitigate a risk as much as you can and accept the residual risk. You will
want to track the risk so you don’t lose it or forget about it in the rush of managing the project, but it may be so small that you don’t want to deal with it.
3 TIP
Use your risk analysis worksheet, your project risk profile, or your
RBS to identify general areas that are more risk prone than others.
Focus your risk response efforts on these areas first.
Project Risk 283
Positive Risks
Lately, the concept of managing risk by managing opportunities as well as
threats has begun to make headway in the project risk management world.
The third edition of the PMBOK® Guide has an enhanced section on positive risks. The 2004 edition of the U.K. Association for Project Management’s
Project Risk Analysis & Management (PRAM) Guide defines a risk event as “an
event or set of circumstances which, should it occur, will have an effect on
achievement of one or more objectives.”5 The PRAM Guide goes on to state
that “A key principle in the definition of risk event used in this guide is the
recognition that uncertainty can affect achievement of project objectives either positively or negatively. The term risk event is therefore used to cover
both uncertainties that could hinder the project (threats) or help the project
(opportunities).” This opens up the risk management process and lets it minimize threats and maximize opportunities, thereby increasing the likelihood
of meeting project objectives.
Returning to Dr. David Hillson and his book, we find that there is a mirror
process for managing opportunities, which can be integrated with a threatfocused risk process or can be implemented separately.6
• Risk identification: Brainstorm for opportunities; conduct a SWOT analysis
to identify opportunities as well as threats. Create a combined risk register
or create a threat register and a separate opportunity register
• Risk analysis: Create a mirror format combined matrix with opportunities
on one side and threats on the other or create an opportunity matrix for
opportunity management and a risk matrix for risk management.
• Risk response: Select appropriate strategies for each opportunity, choosing
from exploit, share, enhance, or accept.
Proactively dealing with opportunities can stack the deck in your favor for
meeting or exceeding project objectives. In addition, wouldn’t it be great to go
to your sponsor with good news on how you improved project performance?
Additional Risk Items
There are still a few items we need to cover, some of which were mentioned
previously. We are going to look at contingency plans, risk triggers, secondary
and residual risks, risk reserves, and fallback plans.
284 Chapter 10
Contingency Plans
A contingency plan is a plan you put in place to deal with the risk, should it
occur. The plan may include bringing in extra resources, working overtime,
trying a different approach, or anything else that will help deal with the risk
once it becomes an issue.
Let’s assume that you are working on a project to open a new office, and one
of the risks is that the build out will not be done in time. If in fact the office
is not open on the date promised, but you still need to be open for business,
your contingency plan is to set up a secondary location temporarily until the
office can be completed.
Risk Triggers
In the above example, would you wait until the night before to realize that
you weren’t going to make the deadline? Of course not. You would set up a
deadline by which to make the call on whether to find a backup location. You
might say something like, “If the build out is not complete two weeks prior to
the live date, we will use a secondary location.” This build out date two weeks
before the live date is a risk trigger. It identifies that a risk has occurred or is
about to occur.
Secondary and Residual Risks
A secondary risk is a risk that occurs because of a selected risk response. For
example, in our software testing scenario, let’s say that you decide to transfer
the risk to an outside consultant. You now have contractual risks that you
did not have before. You may also have risks because the consultant is not
familiar with your policies, procedures, forms, personnel, etc. All these could
cause stakeholder dissatisfaction and/or schedule delays. Secondary risks
need to go through the risk planning process as well.
Residual risks are risks that are leftover after you have applied your risk response strategy. Let’s say you decide to send people to training for the new
software. There may still be some residual risk that the testing will be late.
Even though the people are trained, they still haven’t used the new software
before. However, the risk is much lower. You accept this residual risk.
Reserve
One risk management tool is reserve. You can set aside schedule reserve and
budget reserve. You would have to be naïve to think that everything is go-
Project Risk 285
ing to go according to plan. On a project, it is certain that something will go
wrong; it’s just a matter of what will go wrong, when it will go wrong, and how
bad it will be. Therefore, a wise project manager sets up reserves. Some companies have set reserve amounts. For instance, on a simple project, there may
be a 10 percent schedule and/or cost reserve. For projects that are of medium
complexity, a 25 percent reserve may be more appropriate. For highly complex projects, upwards of 50 percent is not unheard of.
How does the project manager use reserve? Cautiously. In the example of the
software testing, the project manager may want to insert two weeks of contingency into the testing process. This does not mean that the testing process
should take two weeks longer and that the team leader should not work to
meet the original date. It means that in recognizing the risk, the project manager has inserted a two-week schedule reserve to be used if the mitigation
strategies do not work as planned.
In another example, with regard to the new office build out there is no room
for schedule reserve and the scope is locked down. The project manager may
need budgetary reserves to pay for an offsite location on a temporary basis,
or he or she may use the reserve to pay overtime for the people doing the
build out.
Schedule reserve usually is at the discretion of the project manager. On small
and medium projects, budget reserve is usually held by the project sponsor.
On a larger project with an experienced project manager, there may be a certain amount of budget reserve at the project manager’s disposal. Again, this
will depend on the policies and maturity of the organization. The goal is to
not use the reserve, but the reserve is there if you need it, kind of like a savings
account.
Fallback Plans
A fallback plan is an “if all else fails” plan. If the project manager decides that
he or she is going to use the new software for the project and send people for
training, but that doesn’t work, then as a fallback plan the project manager
will test using the existing system and work overtime to catch up as much as
possible.
Fallback plans are particularly important when implementing software or a
new LAN configuration. In the case where the new system doesn’t work, the
project manager wants to be able to restore the previous capability as quickly
as possible so that the company’s daily operations are not affected. There are
286 Chapter 10
numerous horror stories in the IT literature where a software upgrade was
put into production without proper testing and it brought the entire production system down. In the cases where this has happened to financial institutions, the impacts can be measured in many millions of dollars. Always have
a backup plan if the implementation does not go as expected.
In Practice:
Continuous Risk Management
The Software Engineering Institute (SEI), along with the Project Management
Institute and many risk organizations, recommends that risks be identified and
assessed continually throughout a project. SEI has a developed a process titled
Continuous Risk Management in which the steps of identify, analyze, plan, track,
control, and communicate are performed throughout the life of the project. Each
risk nominally goes through these functions sequentially, but the activity occurs
continuously, concurrently (e.g., risks are tracked in parallel while new risks are
identified and analyzed), and iteratively (e.g., the mitigation plan for one risk may
yield another risk) throughout the project life cycle.
Function
Description
Identify
Search for and locate risks before they become problems.
Analyze
Transform risk data into decision-making information.
Evaluate impact, probability, and timeframe, classify risks,
and prioritize risks.
Plan
Translate risk information into decisions and actions (both
present and future) and implement those actions.
Track
Monitor risk indicators and mitigation actions.
Control
Correct for deviations from the risk mitigation plans.
Communicate
Provide information and feedback internal and external
to the project on the risk activities, current risks, and
emerging risks.
Chapter Summary
• A risk is an uncertain event that could have an impact on your project. The
two components of a risk are the probability that it will occur and the impact if it does occur.
• IT projects have five overall sources of risk: team members, technology, project management, the organization, and external factors. Team member risks
Project Risk 287
include skills and availability. Technical risks are comprised of technology, approach, and the technical environment. Project management risks include
scope, schedule, budget, and the project management aspects of the project.
Organizational risks are made up of the structure and culture of the organization. External risks are those risks that are outside of the control of the project
manager, including risks external to the project and the organization.
• To identify risks, the project manager should review project documentation,
conduct interviews, use checklists, and/or create a risk breakdown structure
(RBS). An RBS is a source-oriented grouping of project risks that organizes
and defines the total risk exposure of the project. It allows the team to identify risks in a structured fashion.
• To complete the process of risk identification, the project manager should
create risk statements and enter them into a risk register.
• Analyzing project risks entails estimating the probability that a risk will occur and the impact if it does occur. A matrix of high, medium, and low
probability and impact is used to analyze risks. A risk event can impact on
the scope/performance/quality, the schedule, the budget, and stakeholder
satisfaction.
• Tools for risk analysis include a preliminary risk analysis that considers the
size, technology, and project management structure; a probability-impact
matrix; and a project risk-profile form.
• Risk responses include avoiding the risk, mitigating the risk, transferring the
risk, and accepting the risk.
• Contingency plans are put in place to deal with the risk if it occurs. Risk triggers alert the project manager that a risk has occurred or is about to occur.
Secondary risks are risks that are the result of a risk response strategy. Residual
risks are those risks that are left after the risk response is developed. Sometimes schedule or budget reserve can be used to reduce risk to the project. A
fallback plan is used if the risk response does not work and the risk occurs.
Key Terms
Risk
Issue
Risk breakdown structure
Risk register
Risk log
Risk statement
Probability-impact matrix
Avoid
288 Chapter 10
Mitigate
Transfer
Accept Contingency plans
Risk triggers
Secondary risks
Residual risks
Reserve
Fallback plan
Key Term Quiz
1. Another word for a risk log is a ________________.
2. A risk has two components to it, probability and ___________.
3. A risk that remains after you have developed a risk response is _____________.
4. A ______________ is put in place to deal with a risk should it occur.
5. A ____________ indicates that a risk has occurred or is about to occur.
6. A source-oriented grouping of project risks that organizes and defines the
total risk exposure of the project is called a ______________________.
7. By assigning the risk to another entity, the project manager is _____________ the risk.
8. Finding a way to reduce the probability of a risk occurring is an example
of _____________ a risk.
9. A description of an event with an explanation of the impact is a ______________.
10. A risk that is the result of a risk response is a ________________.
Chapter Review Questions
1. What is the difference between a risk and an issue?
2. What are the three risk planning processes?
Project Risk 289
3. What are the risk categories you can use to identify risks?
4. There are four aspects of technical risk on a project. What are they?
5. When you install a new system, you can count on what percentage of
people to resist using the new technology?
6. What are the three aspects of risk involved in the actions of managing
the project?
7. What are three of the risk identification tools we talked about?
8. What is a risk register used for?
9. What are three risk analysis tools?
10. Using a preliminary risk analysis form, what type of project has very low
risk? What type of project has very high risk?
11. What are the four risk responses?
12. What is a positive outcome to a risk?
13. What are the four opportunity responses?
14. What type of risk might you want to accept?
15. What is a method of mitigating risk by putting in extra time or money?
End Notes:
1. Project Management Institute (PMI®), A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 3d ed., page 238, Project Management Institute, Newtown Square,
PA, 2004.
2. Christopher Koch, “Nike Rebounds,” CIO Magazine, June 15, 2004.
3. David Hillson, “Use a Risk Breakdown Structure (RBS) to Understand Your Risks,” PMI Annual Seminar & Symposium, October 2002, San Antonio, TX.
4. James I Cash, F. Warren McFarlan, James L. McKenney, and Lynda Applegate, Corporate Information Systems Management, 3rd ed., Irwin Professional Publications, Homewood, IL,
1992.
5. The Association for Project Management, Project Risk Analysis and Management Guide,
2nd ed., APM Publishing, UK, 2000.
6. David Hillson, Effective Opportunity Management for Projects: Exploiting Positive Risk, Taylor & Francis CRC Press, London, 2003.
12
Project Execution
After reading this chapter, you will be able to:
• Describe the steps necessary to execute the management of a project.
• Discuss the components of communication needed to manage a project.
• Define the tools and process of change management.
After all the planning and preparation, it’s finally time to start carrying out
the project activities. This phase of the project is all about accomplishing the
project objectives. Sometimes becoming stuck in planning or in the technical
aspects of the project is easy, but remember that the goal is to meet the objectives. The schedule and the technology are just a means to an end. So, what’s
involved in meeting the objectives? For starters, let’s talk about managing the
project and the project team.
Managing the Project
The project plan, with all its components, is the baseline for executing the
project. (The project plan is also known as the project management plan,
as described in Chapter 4.) Project managers will reference this tool in their
daily management activities. A number of documents comprise the project
plan. The specific components of each project plan are different because
each project is different, but in general the project plan consists of most or all
of the following:
• Project charter
• Project scope statement
• Requirements
• WBS
• Milestone dates
326 Chapter 12
• Network diagram
• Schedule baseline
• Resource requirements
• Cost estimates
• Cost baseline
• Quality plan
• Communication plan
• Risk register
• Technical architecture or designs
A significant part of managing a project involves managing the stakeholders
as well as negotiating for resources, changes, approvals, and other things to
keep the project running smoothly.
Stakeholder Management
Stakeholder management can be a very challenging part of managing a project. Hidden stakeholders can appear out of nowhere. You may have had buyin and input from everybody you could possibly imagine. However, if you
missed someone, you can bet that he will show up in the middle of your project, want to be brought up to speed on everything, second-guess all your decisions, and decide that he needs to have inputs to your project. At worst, he
can derail everything.
The main tool for managing stakeholders is communication. Much of the
communication is documented in the communication management plan
that was discussed in Chapter 9. However, a lot of the day-to-day management occurs in formal and informal face-to-face meetings with sponsors,
customers, team members, vendors, and other stakeholders. Sometimes a
phone call or e-mail is a better way to communicate, as long as the situation
at hand is not a critical issue for the project. The more critical the issue, the
more important it is to have face-to-face communication. Follow up face-toface communication with written verification of what was discussed.
Another tool is the issue log. The issue log may look similar to an assumption
log. Figure 12-1 is an example of an issue log. This is used to document and
Figure 12-1. Issue Log
Project Execution 327
328 Chapter 12
monitor the resolution of issues. Some issues are risks that have occurred
and need to be acted upon; some issues are the result of a conflict among
stakeholders, challenges that have arisen, or situations that require a formal
process for resolution.
Negotiation
Negotiation is a skill that every project manager uses constantly, yet it’s not
commonly covered in the project management literature. Negotiation is an
integral part of project management, but often the project manager does not
even realize that he or she is negotiating. Project managers negotiate for additional resources, for enough money, for keeping the resources they already
have, the project priorities, and so on. Negotiation is a key part of stakeholder
management, team management, and vendor management. A project manager who is a poor negotiator has an increased chance of having a failed project or having a project with a longer schedule or higher costs than could have
been achieved.
One key rule to remember in negotiating is that everybody has a stake in a
successful conclusion. Negotiations begin when someone wants to change
something. A negotiation where both parties get what’s important to them
but give up what is not is called a win/win situation. It is to nobody’s benefit
to win a conflict at the total expense of the other person—this type of win is
always short-term and will cause problems in the long-term.
Most of the time project managers negotiate informally as part of daily communication. However, there are times that they need to adopt a more formal
strategy.
Let’s assume you are the project lead for a consulting firm that has bid on a
large project. You have gotten to the final round of negotiations before the
winner will be selected. Here are a few pointers for winning the contract.
Develop a Negotiating Strategy
The first thing to do is clearly define the issues that are going to be negotiated.
Understand each of the areas that can be negotiated. Don’t define the needed
outcomes yet, just the issues. Next, define the strategic goals and objectives
for the negotiations. What is your overarching or strategic desire, and what
Project Execution 329
goals go along with that strategic desire? Then prioritize the goals. Define the
most important goal, the second most important goal, and so on, continuing down the line. For each of the areas that are under discussion, define the
minimum acceptable result.
Once all these items are identified, analyze strengths and weaknesses for
both sides of the negotiation. Then start brainstorming some win/win situations. It’s a good idea to identify possible win/lose and lose/win situations
in order to be prepared for them should they arise. This upfront work can be
time-consuming, but for an important negotiation it is necessary.
The Negotiation
Negotiations are more successful when they are approached looking for ways
that both parties can have their needs met. Spend time trying to understand
the goals of the other party. Both sides want to get what is important to them,
but nobody wants to be the bad guy. Understanding both sides will enable
the parties to find a win/win scenario.
During the negotiation, discuss the issues at hand, including deadlines, criteria for acceptance, payment, and any other issues. Make sure the conversation stays on track and that the strategic goals are being addressed. Watch the
body language of the people in the negotiation. A good rule of thumb is to be
hard on the issues but soft on the people. It is okay to take a strong position;
it is not a good idea to be belligerent about it. Remember that the strategic
goals are more important than the position. Another important factor is to
separate the people from the conflict. The negotiation is about a favorable
outcome, not the people involved in the negotiation.
At the close of the negotiation, document the status of open items and closed
items. Confirm acceptance by all parties. Define the next steps and when the
steps will occur.
* NOTE
During the execution phase of your project, you will be using your
conflict management skills and tools. We discussed the types of
conflicts and methods of handling conflict in Chapter 7. Much of
what we discussed in that chapter will be utilized here.
330 Chapter 12
The Project Kickoff Meeting
What should be one of the first things you do after you’ve thought through
the project? Hold a project kickoff meeting.
Project kickoff meetings are critically important. There’s an old saying among
experienced project managers that a good start is 90 percent of project success. The kickoff meeting is the first opportunity the project manager has to
formally lead the team members and other stakeholders in the right direction
to make the project successful. The kickoff meeting is where the project manager sets expectations for the project, the team members, and the culture for
the rest of the project. It is also where the project team members establish
their expectations about the project manager.
The primary goal of the kickoff meeting is to present an overview of the project: schedules, budget, performance expectations, roles and responsibilities
of the participants, and how the project manager will manage the project.
When done right, the kickoff meeting builds a sense of team and shows that
everyone is working on the project together. This is where the project manager can foster trust in the team and perform the relationship building that
will support the project in the future.
Including everyone in the kickoff meeting helps obtain buy-in to the project
goals and constraints, and everyone walks away with a full understanding of
what needs to be done and how their piece fits into the project. By the time
the kickoff meeting is over, everyone should have a clear understanding of
what will happen on the project and their role in the project. The people attending come in as part of a group. They leave the meeting as part of a team.
There is no better way to start the project.
3 TIP
For a complex IT project—one that spans multiple departments
and has multiple teams—plan on spending at least a day for the
kickoff meeting. Using a facilitator leaves the project manager free
to do team building and not get bogged down with the administrative details of running the meeting.
Project Execution 331
Managing Scope, Schedule, and Resources
At this point, the project manager has met with the customer, team members,
and the other stakeholders to define the management approach the project
manager is going to take. Now is when the project manager follows that approach. The project is out of the planning phase and into the execution phase,
so the project manager will start to manage the progress of the activities that
team members are carrying out on a daily basis according to the schedule.
The project manager will also start to track hours and costs incurred in creating the deliverables.
The project manager’s responsibilities during project execution are not just
to track and control project work, but also to ensure that project work happens successfully. This means making sure project team members have all
the resources they need. Do they have the right equipment? Are the facilities
adequate?
In today’s corporate environment, the IT project team members are most
likely working on multiple projects. Because of this, the project manager
spends part of his or her time working with functional managers or other
project managers to ensure that the team members the project manager has
planned to use are not running into other conflicts. Another project may run
late, affecting the planned use of a particular resource. A functional manager
may have started an initiative that requires a team member who the project
manager had scheduled during the same period.
Some companies manage their projects as a portfolio, with all the projects
and all the resources in a database that allows conflicts to be identified. Some
companies have regular coordination meetings among the project managers
to identify resource conflicts. However it is done, ensuring that the resources
the project manager had planned to use are available when needed is part of
the project manager’s responsibilities.
A good practice is for project managers to keep their attention on what
should be happening two reporting periods out. If status is reported every
two weeks, the project manager should be looking at what will need to happen between now and four weeks from now. What supplies, people, and tools
will be utilized between now and then? Are they ready to go? Do all the appropriate people know that you will be utilizing those resources in the coming weeks? Are there any situations that could arise that would delay the re-
332 Chapter 12
sources? Finding a potential delay a few weeks beforehand rather than the
day before gives the manager a better chance to rectify something that could
potentially throw the project off track.
The other thing he or she will be doing is a lot of walking around to check
and validate the progress on deliverables. This includes ensuring that the
deliverables are consistent with the documented plan and making sure that
progress is occurring as planned. This is not to say that the project manager
should hover over the team members and get in the way of their work being
done. Micromanagement is one of the most effective ways to slow progress.
However, the manager can informally check every couple of days. He or she
should ask team members how it’s going, if there’s anything they need, or if
anything is a concern. In the early days of Hewlett Packard, the management
style was MBWA—“management by wandering around.” The project manager can learn a lot by talking regularly to team members and showing them
that he or she cares about their work.
When the project manager does hear about a concern, he or she should act
on it as soon as possible. There are few things more frustrating for team members than telling the project manager about a problem they are having and
then not getting any help in the resolution. No one likes to deal with problems, but avoidance is not an option. To build the team member’s trust and
respect, help them get their jobs done and assist in resolving their problems.
!
WARNING
One of the easiest ways to tell a new project manager from an experienced project manager is that the new project manager spends
more time doing the technical work than managing the project. It
does not matter if you can do the job better, faster, and cheaper
than a team member, your job is to MANAGE the project, not do it!
Quality Assurance
One area that often is overlooked in the commotion of managing a project is
quality assurance (QA). Quality for the product is often integrated into the project work, but the project quality, discussed in Chapter 8, is addressed during
project execution. Is the team following the steps agreed upon in the quality
plan? Is the quality of the project management process itself adequate? Is the
project manager following methodical and structured project management
processes or running around aimlessly? Is the project being managed to the
Project Execution 333
right level of detail? Too much detail and the project manager will lose sight of
the project goals, too little detail and things will get away from him or her. Finding the right amount of project management is always a balancing act.
Risk Management
A lot of risk management takes place during project execution. It is here that
the project manager follows the risk response plan. He or she will be monitoring risks to see if they occur, if he or she needs to implement the planned
responses, if those planned responses handle the risk the way they were
intended to, or if a fallback plan is needed. The team will also identify new
risks and send them through the analysis and response processes identified
in Chapter 10. As we stated earlier, too many project managers, even if they
write a good risk management plan, tend to put it on the shelf and never look
at it once they get involved in the day-to-day management of the project.
That is not a good practice!
Part of risk management is implementing preventive and corrective actions,
which is something that occurs on a small basis every day. A team member
may mention that he or she is concerned that a piece of equipment needed
for the deliverable is not in yet and will be needed in the next few days. The
project manager should track down the equipment and ensure that it is delivered on time. That is preventive action. He or she is preventing a concern
from becoming a risk or an issue.
Taking corrective action is also part of life as a project manager. Let’s say a
deliverable is completed on time, but does not meet the specifications. Now
the team member needs to rectify the deliverable and get the schedule back
on track. That is corrective action. Chapter 10 defined the difference between
a risk, which is a possible future event, and an issue, which is a problem that
is occurring right now. Undertaking corrective and preventive action is a big
part of the project manager’s job. Some corrective and preventive actions are
formal, such as implementing a risk response, and some are informal, such
as calling a vendor to expedite shipping.
Leading the Project Team
During the execution phase of the project, you will start to add significant
staff hours and costs. Figure 12-2 shows the curve of cost and staffing levels
as the project progresses.
334 Chapter 12
Figure 12-2. Cost and Staffing Levels
Planning
Execution
Close
The project manager follows the staffing plan developed in the planning
phase of the project. This tells how to bring staff onto the project. During
the execution phase, the project manager develops the individuals and the
team as a whole, motivating them and managing them. Recall from Chapter
7 that some of the challenges and frustrations involved with leading teams
include:
• Uncommitted, uninvolved, and apathetic team members
• Conflicts, power struggles, and challenges to authority
• Inability to reach team consensus
• The team’s unwillingness to confront significant issues
• Multitasking
• Inability to influence team members
Most likely, during the planning phase the team has moved through the
forming and storming stages of team development. Now it is starting to reach
the norming and performing stages. What a relief! The project manager can
nurture this development during team meetings by starting to release some
of the control to the team itself. If the team is starting to resolve issues on its
Project Execution 335
own, team members can lead the parts of the meeting that relate to work they
are performing. The project manager can spend time at the meeting making
sure that it stays on track, that there is balanced participation, and that the
overall needs of the project and organization are being met. Of course, while
the project manager can start to share leadership, he or she does not abdicate
leadership. The project manager still organizes meetings, collects status information, resolves conflicts, and follows up on items from the meeting.
IT projects, more than many other types of projects, tend to have a lot of ambiguity in them. Even well-managed technical projects have a lot of ambiguity in them. The client’s requirements are not as well-defined as they need to
be. The technology is not static but changes as the project progresses. Even if
the team has built 10 data warehouses, the 11th one will be different because
the requirements are different, the team members have not worked together
before, the network environment is radically different, the database has had
a significant upgrade since the last implementation, and the schedule is different. The phrase “flying an airplane while learning how to fly” is often used.
Most IT people wish, once they have completed a project, that they could do
it over again because this time they would do it better.
To a technical person, ambiguity is very unsettling. Technicians tend to like
things well-defined and rational. They enjoy challenges, but they enjoy technical challenges, not people challenges or undefined requirements. Part of
the project manager’s job is to be able to manage that ambiguity and to guide
the team(s) in managing it.
Why is motivating people so important? According to an article in the February 2004 edition of Training and Development magazine, employees who
have an above average attitude toward their work have 22 percent higher productivity. This is a significant contribution towards meeting a schedule.1
This part of the project emphasizes a personal skill that has not been needed
before—leadership. No matter how good someone is at planning and identifying costs and risks, those skills alone are not enough during execution.
The primary job during the execution phase is to motivate and lead. To do
this effectively, the project manager needs to understand the team’s personal
needs, desires, and issues. The manager has to motivate the team members to
do the work even if there are problems on the project. The success of the project depends on the project manager’s abilities to ensure that it is the team,
not the project manager, who completes the project. A good project manager
will likely spend many hours every week just talking with the team members.
336 Chapter 12
Doing so is very important to team members, even if the project manager
feels it’s detracting from other work. The best project managers have strong
project leadership skills as well as strong project management skills.
PM in Action!
Create a checklist template that has all the things you might need to do on a daily
basis as part of leading and managing the project. Make it generic enough so that
it can be adapted and specialized based on the needs of individual projects.
Managing Project Communication
Recall that in the prior section we talked about how a large part of your job
is preventive and corrective action. The other big part of your job is communication. You will be communicating up and down the organization, across
departments, and internal and external to the project. You will communicate
in writing and verbally, formally and informally.
In Chapter 9, we talked about the audiences you will communicate with
and some techniques for effective communication. Here we want to look
at establishing your communication infrastructure and collecting project
information.
Communication Channel Management
Project communications go much more smoothly when the project manager
spends the time establishing communication channels early. The information that was documented in the communication plan, such as the information that will collected from team members and the information that will be
reported to the project sponsor, is carried out during the execution phase.
It is a good practice to ensure team members have a structured way to communicate with each other. It would seem evident that the system designer
would need to collaborate with the QA team lead or the testing team lead, but
it is surprising that a number of projects fall behind because no one takes the
initiative to cross those departmental boundaries and proactively establish
communication channels.
Project Execution 337
Another set of communication channels that the project manager should
keep a close eye on are those that relate to people outside the company. This
includes vendors, contractors, and external customers. For the project manager to be the liaison to external communication works well. In order to sell
more business, external consultants and vendors could “pollute” the team
with ideas that are inconsistent with the objectives of the project or the methodology that the organization follows. Few things are more frustrating than
trying to fix a solution that an outside consultant has suggested to the project
team members.
The project manager should be the only communications interface with external customers. It can be pretty ugly if the customer asks a team member
how things are going and that team member relates the daily personal challenges and frustrations encountered. Managing all client interaction is not
micromanagement; it is insuring that a consistent and accurate message
about the project is delivered to the customer.
In Practice: Project Communication
While most project communications take place within the project and from the
project manager to other stakeholders, sometimes project communication can
reach far outside the project itself. During the Year 2000 mitigation projects (often
referred to as Y2K), many companies set up formal communications efforts through
the media and through their web sites, advertising the work they were doing to
become Y2K compliant. A major utility in California, for example, put a liaison
from the company’s communications office on the Y2K corporate project team.
This person was responsible for ensuring that a consistent message regarding
the company’s Y2K efforts was being released to the public, from press releases,
television and radio advertising, filings with the Public Utilities Commission, the
monthly inserts in the utility bills, and even the telephone answering messages on
the project’s public telephone number. All communications were a joint effort of
the communications office and the company’s legal department, and the project
manager had to authorize any communications about the project.
Collecting Information
The communication plan defines the type of reporting information that will
be collected. Specifically, it addresses the necessary information on schedule
status, technical progress, budget performance, and resource utilization.
338 Chapter 12
Scope and Performance Information
Scope and performance information should reflect how the deliverables are
progressing against the plan. This information should also relate projected
progress and any performance issues and risks. Information on progress
should start with the deliverables, specifically the deliverables that have been
completed since the last report. Performance information should also include
data on what is currently in progress and what is supposed to start during the
upcoming reporting period. Additional information on technical challenges,
performance of the deliverables, and quality concerns are also a part of scope
and performance reporting.
Schedule Information
Schedule information should include any significant milestones that have
been achieved since the last reporting period. Then information on the progress that has been made towards milestones, such as percent complete on
activities in progress, should be noted. Information on activities that have
started and those that have completed should be included. For those activities that are in progress, an estimate on when they will be complete should
be included as well.
For schedule information, the project manager should get detailed information from the project team members and summarize it for management. For
example, he or she can track the progress of activities, then roll these up to
track the progress of the milestone, then roll this up to track the progress of
the project overall.
Cost and Resource Information
Sometimes tracking cost can be a challenge because you’re trying to track
costs that tie to deliverables, and frequently the costs and the deliverables are
out of sync because billing cycles and reporting cycles have their own separate timelines. One way to work within these constraints is to note what costs
have been authorized, what costs have been incurred based on the work done
during the last reporting period, and what costs have actually showed up on
the financial reports.
Cost information includes information on resources and any other items that
are charged to the project. This can include the number of people who were
working on particular tasks, equipment that was ordered and has arrived,
supplies that have been utilized, and so forth.
Project Execution 339
In Practice: Collecting Project Costs
One popular manufacturer of laptop computers has set up a project costing system
in which only contractors are charged against the project, employees are not. The
result is a strong competition, and often conflict, among the project managers to
get as many employees on their project as possible to keep their costs low. This is
certainly not an accurate way to account for costs.
One government entity installed an ERP system in its headquarters in 2003 and
2004. While it hired contractors for implementation and for testing and integration,
it also used internal employees for some of the work. It laid out a high-level project
budget, but the project manager was not required to track against the budget.
During an audit, it was discovered that the time spent by internal employees was
not charged against the project unless the employees were officially authorized to
spend more than 50% of their time on the project. The majority of the employees
working on the project were spending significant amounts of time on it, but they
were not officially authorized to spend over 50% of their time on the project and
so none of their work was charged against the project budget.
In neither of these two examples is there an accurate knowledge of the project
costs. Determining how much similar projects in the future will cost is virtually
impossible, because there is no accurate baseline from which to judge.
Other Project Information
On some projects, collecting and reporting on the risk status is important:
You might collect information on risk events that have passed, those that
have occurred, and the status of risk responses that have been implemented.
Other projects may require you to track information on contracts.
One of the more useful pieces of information that frequently does not get
collected, documented, or utilized is information on lessons learned. When
a risk occurs that the team did not identify, or if estimates were significantly
over or under, the root cause should be ferreted out and the corresponding
lesson should be documented. This should happen while the event is fresh in
the team’s mind. Don’t wait until the end, as the details and the significance
will be lost. A lessons learned log that is continually updated throughout the
project can be a very useful tool. During project closure, the project manager
can compile and categorize the information to tie it up in a report. During the
project, the log collects the information as it occurs.
340 Chapter 12
Managing Change
Imagine that you are happily managing your project, it has been well planned,
your team is performing nicely, the customer is content, and the sponsor is
staying out of your hair. You decide to take a stroll over to Seymour, your reporting team lead, to see how things are going. While blithely chatting, Seymour happens to mention that the customer called and said he would really
appreciate it if Seymour could ensure that the reports include information on
run times and tabulate that information on a monthly basis. You look at Seymour with a puzzled expression on your face as you ask him how he replied to
this request. Seymour looks back at you with a bland expression as he replies,
“Well of course I said okay, he is the customer, after all.”
You have just been the victim of scope creep. Your scope has increased without your knowledge and without an assessment of the impact of the change.
Do you suppose that Seymour assessed the impact of this change on schedule, cost, quality, testing, documentation, or team member resources? Probably not. He just assumed that since the customer asked for it, he had to do it.
Thus, we have a case for managing change.
Defining Change
Change is anything that expands or reduces project scope, product scope,
schedule, processes, plans, requirements, development approach, or resources. The first step in managing change is to define, very clearly and upfront, what constitutes a change for all of these aspects of the project. If the
project includes any internal or external contracts, define what constitutes a
change in contracts as well if this is not handled by the contracting, purchasing, or legal department.
For example, here’s a possible definition of schedule change: A schedule
change is anything that affects a milestone, a critical path, a near critical
path, or reduces float on a non-critical path to less than two weeks. A schedule change also includes any modification of the sequence or duration of activities. A revision to the schedule that modifies the duration of a task within
its float is not considered a change, unless that modification falls into the
categories mentioned above.
Project Execution 341
You can see that this example clearly defines what is considered a schedule
change and what is not. This definition is very clear and there is no wiggle room
in the definition. The same type of definition should be developed for scope,
technical approach, cost/resources, quality, requirements, approach, and processes. As a project manager, you will have requests for changes on a daily basis. Not all of them will require a formal change management approach. You
will have to decide what goes through the change management process and
what does not based on criteria you establish during the planning phase.
PM in Action!
Using the information above as a guideline, create definitions for scope change,
budget change, and requirements change.
Comparing Product and Project Scope Change
Sometimes product scope and project scope can be hard to separate. Consider that a change to the product scope usually changes the deliverable(s).
Examples include:
• Added features or functions—tighter tolerances, higher performance requirements, a new report, a new data format
• Changes to environmental requirements—tolerance to temperature, moisture, shock, and vibration
• Changes to physical characteristics—weight, size, color
Changes to project scope include a shortened schedule, exchanging a team
member, adding more testing, and reducing the budget.
Uncontrolled scope creep is one of the most frequent causes of project failure. Most often, scope creep occurs because of poorly defined objectives. Not
applying a rigorous change control process runs a close second in causes
of project failure. The impact of scope creep includes schedule delay, rising
costs, and stakeholder dissatisfaction. The cure—just say no. Many times the
project manager is afraid of annoying someone, causing a conflict, or looking
bad in front of the boss or the team. Sticking to the original baseline has a lot
of benefits, most notably the success of the project. Rather than accepting
scope creep, the project manager should use his or her negotiation and communication skills to point out the long-term impact of scope creep and then
find a polite but firm way to reject changes that are not really necessary.
342 Chapter 12
In Practice: Not Saying No
We have seen one instance where an internal project grew 3000% over its original
scope. The project sponsor was a director-level with a strong personality and the
project manager was a young contractor hired to manage this one project. She
never felt she could say no to the sponsor. The project was eventually cancelled
and she was let go. As a contractor, you may not be comfortable saying no to a
request for a change, but you can always say “Yes, and here’s the impact of the
change. Do you still want to do it?”
Sources of Change
Where do changes come from? Normally they come from five places:
• Errors in defining the product—Frequently, as the team begins to execute
the project and carry out the project plan, it encounters things for which it
did not plan. These things cause the team to expand, reduce, or modify the
product. When the project team learns more about the project they often
find a need to change the product, to make it better suit the client’s objectives.
• Errors in defining the project— The team may have done an acceptable job
in defining the product, but it may have underestimated or overestimated
the work involved in creating the product.
• Value-added change—This is a pleasant surprise. A value added change
usually comes from a team member who finds a way to do something
faster, better, or cheaper. These are good changes, but they still have to be
managed.
• A customer-directed change—These are changes that the project manager
gets from customers. The customer might call and begin with something
like, “You know I was thinking that it would be really great if. . . .”
• An external change—
These are changes outside the control of the
project team. They include changes that are
a result of the economy,
competition, politics, or
anything else outside
the organization or the
project.
What Do You Think?
Look at some of the projects you have
managed and assess where most of your
changes came from. Were they errors in
defining the product? External changes?
Customer driven?
Project Execution 343
Cost of Change
Change is almost never free. Most often, it increases the cost of the project,
although very rarely it will reduce the project’s cost or schedule. The further
along in the project, the more impact the requested change has on the project budget. Figure 12-3 is a guideline for the cost of change over time.
Figure 12-3. Cost of Change Over Time
Initiation Planning
Execution
Close
However, there is more to the cost of change than this chart shows, and that
is the cost of assessing the impact of the change. Let’s say you work for a company that has been hired to create an application to support nine call centers
around the country with the capacity to collect data from 2,200 phone lines.
Let’s say you are 8 months into this 14-month project and you are called into
the office of the director of the customer care center. She is the customer for
the project. She informs you that her organization has decided to outsource
all its West Coast customer care to an offshore location. Therefore, your project will now include three East Coast sites, two Midwest sites, and headquarters, in addition to the offshore location in Thailand. She realizes that this will
affect the scope, schedule, and cost of the project and would like to know how
bad the impact will be.
Before you even think about concocting numbers, stop. The appropriate
place to begin this type of conversation is to point out that the analysis nec-
344 Chapter 12
essary to give her an updated schedule, budget, and scope will take several
weeks and that you will get back to her within a week with an estimate on the
amount of time and cost involved in getting her that estimate. That’s right.
The effort involved in estimating that kind of change is significant. Therefore,
you will need to define the scope, schedule, and cost just to develop the impact of such a change on the project. You’re probably looking at two weeks,
at least, to determine the impact of the change, and that isn’t time that your
firm plans to donate to the customer because it decided that outsourcing
would be a nice idea. Those two weeks are also time you did not plan for in
the project schedule. Anything that takes this long, for whatever reason, will
have an impact.
In addition to the impact of the change itself, it is important to take into consideration the time and cost of assessing the impact of the change. Sometimes this additional time and cost, in and of itself, is enough to have people
reconsider their change request.
* NOTE
One of the best ways to reduce the number of frivolous change
requests is to have a rigorous change control system. People are
happy to suggest change when someone else has to do the work.
However, if they have to assess the impact of the change, document
the impact to the schedule and budget, and justify the reason for
the change, the number of change requests will drop sharply.
Change Control Infrastructure
As with all things in project management, you will set up a structure that
suits the needs of the project. For small projects, you do not need a complex change-management system. However, for a project like the call center
mentioned above, you will definitely need an infrastructure set up to manage
change. All change requires integration. A change to the product scope will
most likely affect the quality, schedule, cost, and risks on a project. A change
to project resources could affect the cost, schedule, and risks. All aspects of
the project are interconnected and need to be managed that way. When you
assess the impact of any change, don’t forget the documentation changes
needed to formalize the change to the product. Any new or changed requirement, for example, must be documented in the requirements document, the
design document, the testing document, and so on. This means re-releasing
Project Execution 345
updated documents to everyone who has a copy of the old document or is
affected by the change (so you will also need infrastructure to manage the
configuration of your project documentation).
Change management on a large project requires rigorous documentation. We
spoke earlier about configuration management. On large projects, change
management is just a part of configuration management. The PMBOK® Guide
defines configuration management as
A collection of formal documented procedures used to apply technical
and administrative direction and surveillance to: identify and document
the functional and physical characteristics of a product, result, service,
or component; control any changes to such characteristics; record and
report each change and its implementation status; and support the audit
of the products, results, or components to verify conformance to requirements. It includes the documentations, tracking systems, and defined
approval levels necessary for authorizing and controlling changes.2
Thus, managing the changes to the product, results, or components is just
one piece of a rigorous configuration management system.
In order to manage change, you begin with the baselines. For scope, this
means the scope statement and WBS. For schedule, it means the baselined
schedule. For cost, it means the budget. Finally, for requirements it means
the baseline requirements document. Any non-administrative variance to
these documents constitutes a change. The process that is followed will be
set up during the planning phase of the project and should be commensurate
with the size and complexity of the project. For a simple project of a month
or less, it is usually enough for the project manager to talk with the technical
lead, and perhaps the customer and sponsor, depending on the change. If it
is agreed that the change should be approved and implemented, the project
manager will update the project documents, advise the team, and implement
the change.
On larger, more complex projects, a more formal change control system is
needed. A change control system is comprised of the forms, policies, procedures, and processes needed to carry out change management. One such
form is a change request form. The person requesting the change fills out
the form and sends it to the designated person. There should be a change
control board (CCB) that meets periodically to review change requests. The
CCB is generally comprised of the project manager, sponsor, technical leads,
346 Chapter 12
and ad hoc members as deemed appropriate. The CCB will review all change
requests and approve or deny them or request further information before
making a decision. The CCB should understand the impacts of any requested
change on a project before making a decision. On a fast-paced project, the
CCB should meet no less frequently than weekly in order to avoid holding up
the project.
If a change is approved, the project manager updates the appropriate project documents, including configuration management documents as needed,
communicates the change, and integrates it into the management of the project. If the change is denied, the project manager or the designated person on
the CCB communicates the decision to the person requesting the change. If
further information is requested, someone on the project team is identified
to lead the effort to gather and provide the information.
Figure 12-4 shows an example of a change request form and Figure 12-5 has
an example of a change request log. These are samples that you can use as a
template to create something that will work on your project.
As in most things in project management, you should only have as much
structure as necessary to manage the project effectively. Too much is overkill,
and too little will lead to confusion.
Project Execution 347
Figure 12-4. Project Change Request Form
Figure 12-5. Project Change Request Log
348 Chapter 12
Project Execution 349
Chapter Summary
• The project plan, with all its components, is the baseline for managing the
project.
• Daily activities include: managing activities, tracking hours, costs, and resources, and checking in with team members to validate progress and to
make sure they have all they need to accomplish their work.
• Managing project stakeholders requires ongoing communication.
• Negotiation is a skill that project managers need throughout the project,
particularly when negotiating a contract. A formal negotiation necessitates
setting a negotiation strategy, selecting and preparing a negotiating team,
and holding the negotiation.
• The project manager should ensure that the product and project quality
objectives are being met and make sure that the risk management plan is
performing as expected.
• A good start is 90 percent of project success, and an effective kickoff meeting is a good start.
• The majority of the project manager’s time managing a project is spent on
corrective action, preventive action, and communication.
• During project execution there is a heavy emphasis on leadership, motivation, and conflict management skills.
• As part of project execution, the project manager will collect information on
project status in the areas of scope, performance, schedule, cost, resources,
risks, contract performance, and lessons learned.
• Change is anything that expands or reduces project scope, schedule, processes, plans, requirements, approach, or resources.
• Change can come from five sources: errors in defining the product, errors in
defining the project, value-added change, customer-directed change, and
external change.
• Change usually incurs capital expense, as does assessing the impact of requested changes. It is more costly to make a change later in the project.
• The change control system should be commensurate with the size and complexity of the project. For complex projects, you may need a CCB and a
rigorous configuration management system.
350 Chapter 12
Key Terms
Issue Log
Preventive action
Corrective action
Lessons learned
Scope creep
Change
Change control system
Change control board
Key Term Quiz
1. Documenting a risk that occurred that was not identified or determining
which estimates were significantly off is an example of collecting ________________.
2. Adding requirements or product features without adding schedule or
cost is called _____________.
3. _____________ is something that expands or reduces project scope.
4. Taking action to bring project performance into line with the project plan
is _____________.
5. _________________ is taking action to reduce the probability of the
project not performing to plan.
6. A group of people that reviews change requests to approve or deny
change requests is a _______________.
7. A set of policies, procedures, and forms to manage change is called ________________.
8. An ____________________ is used to document and monitor the
resolution of issues.
Chapter Review Questions
1. If you report progress every week, how far in the future should you be
looking?
Project Execution 351
2. During project execution, much of your job is to perform two kinds of
action. What are they?
3. By the time project execution begins, what development stage should
the team be in?
4. As team development progresses, the project manager can start to share
leadership in some of the team meetings. However, in certain areas the
project manager should not abdicate his or her responsibilities. What are
these?
5. Give two examples of managing communication channels.
6. Why is it important to collect lessons learned information throughout the
project?
7. What is the first step to managing change on a project?
8. Change can impact what aspects of the project?
9. List the five sources of change.
10. Give an example of an externally caused change.
11. Give an example of a value added change.
12. In addition to developing a cost and schedule impact for a change
request, what else should the project manager develop an estimate for?
13. On a large and complex project, change management is part of what?
14. To assess the degree of change, the project manager should measure
against what?
15. A Change Control Board will likely be comprised of who?
End Notes:
1. Training and Development Magazine, February 2005, page 62.
2. Project Management Institute (PMI®), A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 3d ed., page 238, Project Management Institute, Newtown Square,
PA, 2004.
INTEGRATED COST
AND SCHEDULE
CONTROL IN
PROJECT
MANAGEMENT
SECOND EDITION
Ursula Kuehn, PMP, EVP
8230 Leesburg Pike, Suite 800
Vienna, VA 22182
(703) 790-9595
Fax: (703) 790-1371
www.managementconcepts.com
Copyright © 2011 by Management Concepts, Inc.
All rights reserved. No part of this book may be reproduced or
utilized in any form or by any means, electronic or mechanical,
including photocopying, recording, or by an information storage and
retrieval system, without permission in writing from the publisher,
except for brief quotations in review articles.
Printed in the United States of America
Library of Congress Cataloging-in-Publication Data
Kuehn, Ursula, 1949–
Integrated cost and schedule control in project management /
Ursula Kuehn. — 2nd ed.
p. cm.
ISBN 978-1-56726-296-4
1. Engineering economy. 2. Project management. 3. Cost control.
4. Production scheduling. I. Title.
TA177.4.K864 2010
658.4’04—dc22
2010030621
1Basic Concepts
Before exploring the various tools and techniques of integrated cost and schedule control, a number of basic concepts must
be understood: What is success? What makes work a project?
What does project management mean? Who are the people involved in the project? How important is documentation to the
project?
Success
To understand how integrated cost and schedule control
techniques work, we first have to understand the psychological aspects of “success.” We all have mortgages, rent, and/or
car payments to make, which means that we all have to get up
each day and go to work to earn the money to make these payments. One of the best feelings in the world is getting ready to
go to work knowing that you’ll be spending your day working
on something that will be successful. This is such a good feeling
that it puts a spring in your step. You have a tendency to get
more done because you want to keep the good feeling going.
We all can think back on how it felt to work on a successful
project.
The flip side is that one of the worst feelings in the world is
waking up and getting ready to go to work knowing you’ll be
spending your day on something you know will not work, or
will not get done on time, or will cost too much, or no one will
really want or use, or with which the customer will be unhappy.
This is not a good feeling. Not only is there no spring in your
step, but you’re probably taking longer to get ready for work
Integrated Cost and Schedule Control
4
than normal. You have the tendency to get less done because
you don’t really care. We all can think back on a project we
worked on that had no chance of being successful and how that
felt.
A basic understanding of what makes work successful is
the most important part of what integrated cost and schedule
control is all about. Whether you are the only one working on
your project or you have a team helping you, understanding
success—even if it is the delusion of success—is what enables
the work to get done. We all need a sense of accomplishment.
Success is the goal that is tantamount to everything we do
to control the cost and schedule of the project. That means we
must define the project and everything we think might happen on the project as clearly and realistically as possible. We
must make sure that we describe the work unambiguously and
that the work is attainable. We must use all available tools and
techniques to control the project to the best of our abilities. This
does not mean that we cannot make the work challenging, but
it is self-defeating to expect something to be accomplished that
simply cannot be accomplished.
The Project
Another basic understanding required for integrated cost and
schedule control is an internalization of two basic definitions:
What is a project? and What is project management? A lot has
been written about these two basic concepts, yet misunderstandings abound.
The Project Management Institute’s (PMI) Guide to the Project Management Body of Knowledge (PMBOK® Guide)1 defines a
A Guide to the Project Management Body of Knowledge, Fourth Edition
(PMBOK® Guide) (Newtown Square, PA: Project Management Institute), 2008.
1
Basic Concepts
5
project as “a temporary endeavor undertaken to create a unique
product or service.” The PMBOK® Guide readily points out that
organizational work generally falls into one of two categories,
operational work and project work, and that projects are undertaken at all levels of the organization.
Tom Peters, in his book In Pursuit of Wow,2 defines all work
as project work in the new economy. He says that work should
always add value, and that if it adds value, it is a new, unique
endeavor.
Many organizations seem to think that larger projects should
no longer be known as projects, but should be called “programs”
instead. This view often stems from the notion that we have to
promote project managers to the higher position of “program
manager.” If the work has a beginning and an end and creates
something new and unique, it is a project—no matter how big
or small. A program, on the other hand, is usually made up of a
collection of projects, but goes beyond the completion of the individual deliverables, through the operation and support of the
deliverables, to what is often called the “end of service life” of
the deliverables. Understanding that cost and schedule control
techniques can be applied consistently to very large, complex
projects as well as to small weekend “house” projects will go far
in making the work proceed more easily and efficiently.
Project Management
Project management is not a title, nor is it a job description.
In fact, it is a process that should be learned and understood by
every level of the organization. It is amazing how many people
call themselves “project managers” but have very little understanding of the process. Worse yet are the many upper-level
managers who believe they are “above” learning the process.
These upper-level managers do not seem to grasp that the betTom Peters, In Pursuit of Wow (New York: Vintage Books), 1994.
2
6
Integrated Cost and Schedule Control
ter all the members of their organization, including themselves,
understand the project management process, the higher their
chances for overall success within their organization. Instead
many of these upper-level managers impede the opportunity
for success by not supporting the project management process.
Everyone can do and does projects. Aside from what we do
at work, we all have projects underway at home, in our neighborhoods, and at our clubs or places of worship. Planning and
managing these projects enable us to get them done. How many
times have you set out to accomplish that Saturday morning
project, just to find yourself running back to the hardware store
in the afternoon? If you had used good project management
processes, that might not have happened.
Stakeholders
Anyone who can “help” or “hurt” your project should be
viewed as a stakeholder. Your customer, the users, your management, your team, vendors and suppliers, or other departments that you will depend on, can all “hurt” your project if
their needs are not considered. For example:
• The customer who is never happy with the outcome and
constantly wants more
• The user who doesn’t use the deliverable of your project
• Your manager who doesn’t provide the support your project needs or who micromanages your project because he or
she doesn’t trust your abilities
• Other internal functional managers who refuse to support
your project or to give your project the priority it deserves
• Your team members who do not buy in to the project
Basic Concepts
7
• Support organizations, such as Purchasing or Finance, that
refuse to support the requirements of your project
• Vendors, contractors, and suppliers who do not meet their
agreements and do not deliver.
Each stakeholder has specific needs that must be determined,
considered, and possibly included in the scope of the project.
Getting the stakeholders involved and enthusiastic about the
project is crucial to the success of cost and schedule control.
The Project Team
The project team is a subset of stakeholders who can either
do major damage to your project or be your most valuable asset. The project manager’s leadership abilities will determine
which way this goes. The project manager needs to understand
and appreciate that unless he or she can do all the work of the
project, a project team will be involved.
Some of the best project managers realize that the less autonomous decision making they do during the initial and planning
stages of the project, the more leadership stature they maintain
throughout the project, because no one can accuse them of making that “bad” planning decision. They encourage involvement
of all the team members, which in turn encourages “buy-in” to
the project objectives and ultimately to a focus on the cost and
schedule control of the project.
The composition of the project team can change substantially
throughout the project. For example, the initial project team
may be a group of subject matter experts who have the customer familiarity and technical knowledge to assist in defining
the overall deliverable. This composition of the team should
change based on whether a different potential team member has
the skills or knowledge to take over the definition or decompo-
8
Integrated Cost and Schedule Control
sition of the deliverable from a certain point in the project. The
composition of the project team could go through many iterations until the entire scope—down to the true definition of the
work involved to complete the scope—is defined, at which time
the resource that can best do the work should be identified and
should become a member of the project team.
The Project Manager
The project manager is you: you, who has been asked to get
something done and to have it done by 2:00 p.m., or by Friday,
or by the end of the month; or you, who recognizes a need and
believes that you can take care of that need in time to make a difference; or you, who has taken on responsibility for delivering
that unique (be it ever so slightly unique) product or service.
It doesn’t matter how big or how small, if the product or
service is needed, is something unique, and is required to be delivered by a certain time, it falls into that definition of a project.
The words “I need it by … ” is what makes it a project. The first
step of taking on the responsibility of being a project manager is
to make sure that whoever is asking for “it” realizes that “it” is
never free. Producing anything takes time and time is money; the
management challenge is to make sure the requester can afford
“it” and that the time is efficiently planned to get “it” done.
Another aspect of project management is that “it” may be
needed to accomplish a different project. In other words, the
project that you are managing may be a subproject of the project
that whoever requested “it” is trying to manage. This makes
your “customer” another project manager.
The realization that all projects are interrelated allows for
overall efficiencies of good project management. All workers
should recognize the project aspects of their work and how the
tools and techniques of integrated cost and schedule control can
help them in accomplishing that work.
Basic Concepts
9
In today’s world we tend not to recognize an individual
worker as a “project manager” until he or she has taken on the
responsibility of a large, complex project. The assigned project
manager who has not considered him- or herself a project manager before must quickly learn project management tools and
techniques. This can be a daunting task, especially when the
individual is “thrown to the wolves” well into the lifecycle of a
project.
Too often the inexperienced project manager thinks he or she
must be “the expert” and should take on the role of defining and
planning the entire project. The enlightened project manager
knows that this is not true. Some of the best project managers
have no technical expertise in the deliverable of the project.
They know that their responsibility falls more in facilitating a
group of experts (i.e., a project team) to define what the customer deliverable should look like. The project manager doesn’t
need this expertise, because the project manager usually is not
the person doing the work; however, the project manager must
know how to use the terminology of the technical aspects of the
deliverable. In other words, the project manager does not need
to “walk the walk,” but he or she had better know how to “talk
the talk” if they are to maintain their credibility with the project
team and stakeholders.
The process of allowing other team members to participate
in identifying and decomposing the deliverable, along with the
realization that all projects are made up of many subprojects,
enables the project manager of a large, complex project to delegate portions of that project to various team members and to
assign them as project managers of their subparts.
Project Documentation
Good project managers embrace documentation. They understand that documenting everything they do, every process
they intend to use, and every decision or assumption they
10
Integrated Cost and Schedule Control
make keeps everything having to do with the project on a business level as opposed to a personal level. Aside from being a
mechanism for better communication with all the stakeholders
involved in the project, documentation is CYA—“cover your
activities” or “cover your assumptions.”
The project charter is one of the first and most important documents of the entire project management process. The PMBOK®
Guide defines a project charter as “a document provided by the
project initiator or sponsor that formally authorizes the existence of a project, and provides the project manager with the authority to apply organizational resources to project activities.”
The project charter provides so much more than that. It provides the history, or the “why” the project is being undertaken
in the first place. More importantly, the project charter provides
the “outer boundaries” of the project by providing the budget
constraint (i.e., how much the customer can afford) and the
time constraint (i.e., when the customer needs the deliverable).
If you truly believe, as I do, that every project is a subproject
of someone else’s project, there would be a number of project
charters that “pass down” or delegate authority for the parts of
the deliverable of your project to each of the team members who
are expected to deliver their parts.
The idea of identifying every team member as a project manager of their subproject, providing them with a project charter
that defines their boundaries, and teaching them each the project management process gives those team members “ownership” of providing a deliverable to the customer (which might
be you.) The team member/subproject manager quickly learns
that they need to perform a requirements analysis and define
the “best solution” to meet those requirements.
2The Integrated
Process
“Time is money,” to quote Benjamin Franklin, and that is no
more true than when trying to control the cost and schedule of
a project. This is why it is so essential to understand the processes, techniques, and tools of defining a project based on the
cost of the time it will take to produce the overall deliverable of
the project.
In this chapter we will introduce the integrated project processes, the balancing technique crucial for cost and schedule
control, the binding structure tool that will be used throughout
the integrated processes for cost and schedule control, and the
idea of having a baseline and steering the cost and schedule of
the project within a predefined tolerance threshold. We will also
take a look at the process of integrated cost and schedule control
in the U.S. federal government.
The Integrated Cost and Schedule
Control Processes
As defined in the PMBOK® Guide, the process of project management entails five subprocesses. These individual processes
are called many different names by different organizations, but
it is the understanding of what happens during each that is
important. Using PMI’s terminology, the subprocesses are the
initiating process, the planning process, the executing process,
the controlling process, and the closing process:
• The initiating process is where decisions are made about
whether something truly will take care of the need and
can be afforded in light of the customer’s budget. This
12
Integrated Cost and Schedule Control
decision authorizes the “parts” of the deliverable or service
of the project, which in turn define what is in the scope of
the project and what is not. This is where the customer’s
or stakeholder’s expectations of what they will receive are
balanced, based on the money they have in their budget.
Setting these expectations allows control over the project’s
cost and schedule. We will explore this process in depth in
Part 2, because it is the most important and most misunderstood process in project management.
• The planning process is where the best method of accomplishing the work in time for the customer to use the
deliverable (identified during the initiating process as the
agreed-to scope) is explored. Too often this process gets
started without the initiating process having been performed, and project plans that are not balanced go forward
into execution. These imbalanced plans have little or no
chance of success. Carrying out the planning process effectively requires a basic understanding of network analysis
and statistical analysis. These techniques are presented in
a straightforward fashion in Part 3.
• The executing process is where the work gets done. This
process relies less on management techniques and more on
leadership abilities. Some of the management techniques
that are involved in the other processes, such as including the team in the initiating and planning processes and
guiding the project toward a successful completion, put the
project manager in a “leadership” position with the project
team.
• The controlling process establishes a guidance system for
the performance of the work, in terms of both time and
cost, and redirects the planned work, where required, to
stay within the control area of that system to a successful
completion. This is where earned value analysis is so useful; we address how this analysis is performed in Part 4.
The Integrated Process
13
• The closing process puts accomplishments “on the shelf”
and analyzes them for lessons learned and their usefulness
in the future. We address these techniques in Part 5.
Many unenlightened project managers see these subprocesses as distinct and separate phases. They envision the
entire project plan as one big waterfall schedule through the
lifecycle of the project, as shown in Figure 2-1.
Figure 2‑1. Project Subprocesses Planned in a Waterfall Schedule
This type of schedule often becomes “very expensive wall­
paper,” because the schedule doesn’t realistically show how the
subprocesses are performed in real life. In the real performance
of any project, the subprocesses tend to overlap through the
lifecycle of the project, as shown in Figure 2-2.
Figure 2‑2. How the Subprocesses Overlap during the Project Lifecycle
14
Integrated Cost and Schedule Control
Understanding how information passes from one process to
another allows the project to be planned in an iterative process
that more closely emulates real life. Another way of saying this
is that to get to the point where we have truly defined the work
of the project, we need to have done a lot of the work of the
project.
Balancing the Triple Constraint
The key to being able to control the cost and schedule is
having a plan that balances the scope of the deliverable of the
project with the customer’s budget and has the right resources
assigned at the right time to perform all the work in time for
the customer to be able to use the deliverable. This is called the
triple constraint (see Figure 2-3).
Figure 2-3. The Triple Constraint
This triple constraint must be balanced during the initiation
and planning processes if the cost and schedule of the project are
to be controlled through the execution and closeout ­processes.
The Integrated Process
15
It is a delicate balance because some of the time and money
are expended just to get to the point where the initiation and
planning are complete. To maintain this balance throughout the
project, the project manager must always be aware of where the
project is in each process.
To maintain this balance, terms such as “quality” or “resources” come into play. The idea of quality has to do with defining the scope that fits the customer’s budget and will be able
to accomplish what the customer plans to do with the deliverable. For example, the customer may want a Cadillac but not be
able to afford one. The need that is being addressed is the fact
that the customer needs transportation and a car is a “class” of
deliverable that can fulfill that need. The quality (attributes) of
the deliverable (scope) has to be balanced with the customer’s
budget. If the customer demands the quality of a Cadillac, then
the need to have transportation cannot be met until the budget
for the Cadillac is available.
Resources take time to get work done. Two resources can usually get a job done faster than one if they have the proper skills
and the scope of the work has been unambiguously defined. If
there are not enough resources to get all the scope of the deliverable completed in time for the customer to use it, one option is
to reduce the size or the quality of the scope to something that
the resources can complete and the customer can still use.
As the project plan is time-scaled, the costs involved to complete the work can increase as a result of factors such as escalation. This is why incremental planning, with budgets defined
for each increment, is used on many projects. Incrementally
funding the project based on defined releases of the deliverable
has mitigated some of the risk involved in balancing the triple
constraint of large, multiyear projects.
This is all one big balancing act. Those projects that are not
balanced are virtually impossible to control no matter how
much earned value analysis is done.
16
Integrated Cost and Schedule Control
The Work Breakdown Structure
The one binding tool through the entire integrated process
of cost and schedule control is the deliverable-oriented work
breakdown structure (WBS). The deliverable-oriented WBS
is a tool used in every process. It is built during the initiating
process by recording the decomposition of the deliverable and
helping determine the work items required to build the deliverable that will take time and effort to accomplish.
The effort of these work items translates into money that will
help balance the scope of the work to the customer’s budget.
Like with my She Sails catalog mentioned in the Preface, my
expectations, like any customer’s, were not set until I was presented with how much each part cost and I realized that I could
not afford everything I originally wanted.
The time required to complete each work item, which is
identified using the WBS for the agreed-upon scope, will then
become part of the schedule. That schedule will then be used to
plan how each of these work items will need to be accomplished
for all of them to be done in time during the planning process.
Because these work items are “children” of the parts of the
scope, the WBS/schedule shows the progress of the project
during the execution process. The WBS also presents the information for performing the analysis that will help us control the
work items during the controlling process. This approach of
using earned value information presented in the WBS will also
help us isolate issues while they are small and can be resolved
during the controlling process.
It is important to understand that a deliverable-oriented WBS
is a tool for integrated cost and schedule control. Too often project managers use other methods of developing a WBS, such as
a time-oriented or task-oriented structure.
The Integrated Process
17
The time-oriented WBS has the tendency to set up the first
level of the WBS based on “milestones.” For example:
1.0 Project
1.1 Requirements Analysis
1.2 Design
1.2.1 Preliminary Design
1.2.2 Detailed Design
1.3 Implementation (or Build or Code and Unit Test)
1.4 Test
Each major part of this time-oriented WBS is an ambiguous
term that can neither show the customer what they are going to
get at the end of the project nor help the project team figure out
the work that will need to be planned for the project. In most
cases, when this method is used, the only opportunity to see
that the triple constraint is not balanced comes toward the end
of the project when the only recourse is to eliminate testing.
It is true that a good practice, especially when a project is
very large and will expend a lot of budget, is to break a project
down into phases of time. Each of these phases, however, must
be identified as a subproject and a deliverable that needs to be
produced. The WBS needs to focus on that deliverable and all
the subdeliverables that make up that deliverable to be produced for that phase.
Keeping in mind the first, basic understanding of success,
work to define the project and everything you think might happen on the project as clearly and realistically as possible.
18
Integrated Cost and Schedule Control
U.S. Department of Transportation
Headquarters Relocation Project
Back in 2001 I was asked by a student to look over a WBS for
a new building planned for the rehabilitation of Southeast Washington, D.C. The manager of this project showed me something
that reminded me of the many schedules I’ve seen in the past that
were filled with ambiguous terms and claimed to be work breakdown structures. He told me he had paid a consultant quite a bit
of money to help put it together (what I like to call “very expensive
wallpaper”).
He happened to have a small whiteboard hanging on the wall of
his office, which I used. “Arnold, you’re building a building,” I said
and proceeded to put a box at the top of the board that said “Building.” “If there is just one building, then you break that down into
subground, walls, floors, etc. If there is more than one building,
you break it down into west wing, east wing, guard shack, and then
proceed to break each down as though it is a separate subproject.”
I sat through many sessions with the project team creating the
WBS. It was interesting when the contractor in charge of installing
all the IT hardware presented a WBS that was based on the typical
milestones with ambiguous terms (e.g., preliminary design). We
refused to accept it and had the contractor redo it based on the
breakdown of the building. They claimed to have never constructed
a WBS in that way, but agreed that it (1) made sense and (2) would
be far easier to estimate the costs.
When I explained to all the team members how this deliverableoriented WBS would serve as a better management tool during the
actual construction of the building, I had them all converted. If
the budget for 2007 gets cut in half, for example, then the building
WBS can be prioritized to identify a possibly usable portion of the
building (say the east wing) that can be completed for the 2007 budget. The rest can be rescheduled, with all the tasks that are associated with completing the rest of the building, to the following years.
The Integrated Process
19
It takes time and effort to develop a project work breakdown
structure. The requirements have to be known before you can
complete the WBS, but the WBS serves as a tool that records the
decisions of the requirements analysis and focuses the analysis
to smaller and smaller components of the project. The customer
should see exactly what they are going to get in the WBS.
To this day, Arnold still carries that whiteboard around with
him.
The Guidance System
Using the integrated cost and schedule control tools and techniques during the subprocesses of initiating and planning the
project results in a project plan that ultimately is locked in as a
baseline. This baseline then serves as the guidance system of the
project because it points to the goal of getting the agreed-upon
scope completed within the customer’s budget and in time for
the customer to use it.
This project baseline is similar to a flight plan that the pilot
of any airplane must submit before the flight. The pilot charts
a course that points to the destination of the flight. If you ask
a pilot how often he or she is exactly on the flight plan, they
will likely tell you that they are on the plan at take-off and at
landing; in between, they might happen to fly through it. Yet,
they all seem to be able to fly to their destination with very few
problems.
If the plane is not exactly on the flight plan, the pilot can usually steer the plane back. If not, the charts are brought out to
develop a new flight plan. Hovering close to the flight plan is
what allows the plane to reach its destination.
In project management, it’s not being exactly on the baseline
of the plan that counts—it’s that you can steer the project team
back toward the baseline. Using the tools and techniques of
20
Integrated Cost and Schedule Control
integrated cost and schedule control allows the project team to
identify “control areas” around the baseline (like flight control
lanes for a pilot) both on the positive side and on the negative
side that the project status should stay in to be successful.
If a pilot finds him- or herself outside the control lane, with
no possibility to steer the plane back in, the pilot would need to
contact someone to make them aware of the situation and to be
directed out of the way of other traffic, determine a new flight
plan and submit it for approval, check the fuel to see if they will
need more than what they have (budget), and report to the passengers, “We’ll try to make up as much time as we can.”
Projects go through the same process. If the project status is
outside the threshold of the control area and, no matter what the
project team tries to do, the status is doomed to stay outside the
control threshold, the baseline of the project is no longer serving
as a guidance system. The project should be replanned and the
baseline should be changed via a change control process. Someone needs to be made aware of the situation (through a change
request) and the impact to the scope, budget, and/or schedule
must be determined. If approved, more budget or resources
should be added to the project or the due date of the project
should be adjusted, all of which will change the baseline so that
it serves as a truer guidance system for the rest of the project.
INTEGRATED COST AND SCHEDULE CONTROL IN
THE FEDERAL GOVERNMENT
When I started working with the U.S. federal government
and decided to focus on integrated cost and schedule control,
my “bible” was the Cost/Schedule Control System Criteria
(C/SCSC) first issued the U.S. Department of Defense in 1967.
This set of criteria made so much sense to me as a guide to
managing any project. The C/SCSC later evolved into ANSI/
EIA-748 (the latest version is B), available at http://webstore.ansi.org/
The Integrated Process
21
RecordDetail.aspx?sku=ANSI%2FEIA-748-B. The National Defense Industrial Association (NDIA) Intent Guide provides an
excellent (free) explanation of the 32 criteria at http://www.ndia
.org/Divisions/Divisions/Procurement/Documents/PMSCommittee/
CommitteeDocuments/ComplementsANSI/PMSC_Application_
Guide_March2007_Release.pdf. I took it upon myself to try to get
my colleagues to understand the benefit of using the criteria on
any project in any department of any size, but most directives
required that the criteria be followed only on major ($20 million
or more) Defense Department contracts.
In 1993 Congress passed the Government Performance Results Act (GPRA), http://www.whitehouse.gov/omb/mgmt-gpra_
gplaw2m/, which mandated the establishment of strategic planning and performance measurement across the entire federal
government. The purposes of GPRA were to:
• Improve the confidence of the American people in the capability of the federal government by systematically holding federal agencies accountable for achieving program
results
• Initiate program performance reform with a series of pilot
projects in setting program goals, measuring program performance against those goals, and reporting publicly on
their progress
• Improve federal program effectiveness and public accountability by promoting a new focus on results, service
quality, and customer satisfaction
• Help federal managers improve service delivery by requiring that they plan for meeting program objectives and by
providing them with information about program results
and service quality
• Improve congressional decision making by providing more
objective information on achieving statutory objectives
22
Integrated Cost and Schedule Control
and on the relative effectiveness and efficiency of federal
programs and spending
• Improve internal management within the federal government.
Those government agencies that didn’t think they had to do
it found themselves struggling to get up to speed on cost and
schedule control and earned value management.
Today more and more government agencies are getting on
the “earned value management wagon” and appreciating how
this invaluable performance measurement and predictive tool
helps the project management process.
Now that we have a basic idea of the process, the triple constraint, the WBS, the guidance system, and the emphasis in the
federal government, let’s see how these processes of integrated
cost and schedule control really work.
3Defining the
Scope
To define the scope of the project’s deliverable, decisions
must be made about whether or not a deliverable or service will
meet the customer’s need and still fit into their budget. These
decisions should be based on the answers to such questions as:
• Does the customer need it?
• Does the customer want it?
• Will it benefit the customer to have it?
• Can the customer afford it?
• Do other stakeholders need or want it?
• Will it benefit other stakeholders?
• Will it enable the project to be executed more efficiently?
The answers to these and other fundamental questions allow
the project manager to truly focus this decision-making process
regarding “what” is in the scope of the project on true objectives. Finding these answers takes time and a lot of work. The
initiation process cannot be considered complete until the entire
scope of what is to be built on the project has been designed or
at least defined and agreed to by the stakeholders.
26
Integrated Cost and Schedule Control
Customer-Focused Scope Decisions
All projects stem from a customer need. The basic steps that
start the initiating process are:
• Identifying the customer, stakeholders, and users
• Determining the difference between a need and a want
• Controlling the ever-changing need
• Clarifying the misunderstood need
• Differentiating among the needs of multiple stakeholders
or users.
Although the initiation process is the most important, it is the
most misunderstood of the five processes of project management. The initiating process usually involves a lot of time and a
lot of work. In many cases, it could take the entire allotted time
of the project, because many of these decisions are held off until
the end to “see how much money is left over.” Too often this upfront work is never accomplished, which can have detrimental
impacts on the project during the execution process.
Consider building a house. We all need shelter, and there
comes a time in almost everyone’s life that we either want to
buy a house that is built from scratch or an existing house that
needs improvement. If we have already talked to the bank, we
have an idea of just how much our budget is and what initiating types of decisions need to be made. If we don’t go through
a good process, we run the risk of never being satisfied with the
outcome of the house.
Let’s consider some bad decision scenarios:
Defining the Scope
27
Bad decision scenario #1—Not building a case for
the need for a house in the first place.
How many people do you know who just went out and
bought a house, any house, the bigger the better, to later find
that they could not keep up with the payments, ended up with
more house than they could ever use, or just weren’t happy
with the house they bought.
Making a good case for why you want the house, what the
house will provide you in the future, and whether or not you
can afford the house—and taking the time to find the right
house to fit these needs—is essential to your overall satisfaction. No one wants to be stuck with a house that is too big or too
small, that you don’t like, or that you can’t afford.
Buying a house is a project, just like any other project. Before
we enter any project, a case for the project should be developed
(sometimes referred to as a “business case”), defining exactly
why the project is required, how the deliverable of the project
will be used, and what we think we might receive in return for
taking the time, effort, and budget that we will expend to obtain
that deliverable. This business case helps focus the project team
on not trying to build more than what is needed by whoever
will use it.
Bad scenario #2—Not realizing that, even though
we have found the right size of the house we
want, we may not be able to afford it.
Just because you decide to buy a small, one bedroom, one
bath house on an inexpensive lot does not in and of itself mean
that you will be able to afford it. Whether or not the house is affordable depends on all the little parts that go into the house.
How many times have you opened that magazine or catalog
and seen those perfect marble floors that would look so good
28
Integrated Cost and Schedule Control
in your kitchen? You want those marble floors—right up to a
certain point. That point, of course, is the moment you see just
how much those marble floors cost.
Just like with the house, all projects have budgets. Making
sure we provide the best solution that the customer can afford
is tantamount to the overall success of the project.
Customer Expectations of What They Can
Get for Their Money
The goal of the initiating process is to make the decisions
about what will go into the deliverable and present to the customer exactly what they are going to get for their money. The
best technique for accomplishing this is to conduct various
reviews of the scope, using the WBS, with the customer so that
the customer gets a chance to see what the deliverable will look
like and how much the parts of the deliverable are likely to cost.
This in turn allows the customer to have a say about whether
they like or want the deliverable or any part of the deliverable,
whether they would rather not have it for this iteration or release, or whether they would rather not have it at all. Although
it may be difficult, we need to hear the customer say that they
“do not want that.” This enables the customer and the project
team to reach agreement on the scope of the project.
In most cases the customer is not exactly sure what they want,
yet they expect the project team to be able design exactly what
they want. Customers have been known to declare, “I’ll know
it when I see it.” If the project team doesn’t take the time to go
through the initiation process and never allows the customer to
“see it” on paper before they build it, “it” could end up not being exactly what the customer expected at all. The customer will
then start expressing their wants and preferences as the deliverable of the project is being built in the execution subprocess.
Defining the Scope
29
This is what causes those “creeping requirements” that so
many projects experience. A detailed description of exactly
what the customer is going to receive and how much it is going
to cost is never presented, agreed upon, and baselined; thus, the
customer thinks they can get anything they want.
Creeping requirements, also known as “creeping elegance,”
have produced more project failure than any other issue of project management. If the customer hasn’t agreed on what type of
floor should be installed and the installation of a linoleum floor
has already started, the customer could change their mind and
complain that they expected a marble floor. Then the cost of installing the linoleum up to this point must be added to the cost
of de-installing the linoleum, the cost of designing the new floor,
the cost of installing a new subfloor that can handle the weight
of the marble, the cost of acquiring the marble, the cost of the
installing the marble, and the cost of supervising and inspecting
the job. This new cost of the kitchen floor will be much higher
than the original estimate, causing a cost overrun on this part of
the project that should have been avoided in the first place.
As I mentioned in the Preface, it was after this experience
with the She Sails catalog that the pieces of the project management process began to fit together for me. I realized the importance of the initiation process and how the decomposition of
the scope of the deliverable was the most important of the subprocesses. We broke the catalog into parts, estimated the cost of
each part, and were then able to make the decision of “what”
should (or could, dictated by my budget) go into my little project. This step of scope decomposition and cost estimation, and
the subsequent analysis of what my catalog really did require,
gave the project a chance of being successful. Had we not done
that, my “customer expectations” would have remained way
too high and my relationship with the graphic artist would have
deteriorated, which ultimately would have led to the demise of
the project.
30
Integrated Cost and Schedule Control
Building and Using a DeliverableOriented WBS
The most important tool of the initiating process is the deliverable-oriented work breakdown structure (WBS) (introduced
in Chapter 2). The purpose of project is to deliver a specific,
unique product or service; the decomposition of the scope is
what forms the deliverable-oriented WBS into an architectural
breakdown of that product or service.
The central focus of a deliverable-oriented WBS is the overall
deliverable of the project. For example, if you are constructing a
building, then the top block of the WBS would be the building.
If you are developing software, then the top block would be
the major function the software will perform for the customer.
My favorite example is building a pond in my yard, where my
top block would be “Ursula’s pond.” I would have to develop
a business case of sorts to justify why I need a pond. I certainly
would have to manage the pond. I know I’ll have to design the
pond and test the pond, but the rest of my subdeliverables are
going to be the major parts of the pond.
To start my decomposition, I would need to perform a requirements analysis. This is a process in itself where the project
as a whole and each part of the project are scrutinized to make
sure that they meet the need of the customer or stakeholder and,
also, that the part fits into the budget. This analysis is like “peeling an onion.” Through the analysis, the parts of the scope are
identified. Then through a structured tool of documenting this
decomposition of the scope (the WBS), the requirements analysis can be focused down the structure to each individual part.
Let’s see how the WBS can help me plan my pond. Let’s say
that I would like to complete the entire pond in a weekend. If
I were to use a task-oriented WBS, as described in Chapter 2,
breaking down the project into the tasks of design the pond,
build the pond, and test the pond, I can almost guarantee that I
will not be able to complete the project in a weekend. It is very
Defining the Scope
31
difficult to identify all the work—that is, anything that might
take time on the project using this type of WBS. If I don’t identify all the work that might take time, I will not be able to plan
for it in my schedule and by the time it becomes obvious to me
that that additional work will need to be done, it will be too late.
By doing a requirements analysis, I can identify the major
parts of the pond, such as a hole in which to place the pond, a
liner, and water. Note that if a requirement for this project was
to not break the ground surface, then the basic major parts of
the WBS might be a plastic tub and water. The output of what
is determined by my requirements analysis is the input to my
deliverable breakdown, which in turn allows me to decide what
goes into the scope of the project and what does not.
For this example, let’s say that the basic requirements of my
pond are a hole, a liner, and water, plus some livestock and
some attractive plants. Our structure might look like the toplevel structure shown in Figure 3-1.
Figure 3‑1. High-Level Breakdown of Ursula’s Pond
There could have been several more major parts to my pond,
like a stone border, a water treatment, or external landscaping.
There also could be many logistical deliverables that relate to
the pond as a whole, such as training (possibly broken down
into operation and maintenance), equipment needed to maintain the pond, user documentation, supplies, etc. These initiation subprocess decisions are made based on the requirements
32
Integrated Cost and Schedule Control
and the budget. They then should be documented (remember
CYA) in the business case.
The requirements analysis can now be focused on each of the
individual major parts of the project. Let’s take “hole” as an example. What is required to have a hole? The basic two functions
that need to take place are to remove earth from the ground and
to dispose of the earth. We could look at each of these functions
as a subproject in itself: “earth removal” and “earth disposal.”
Performing a requirements analysis on the subproject “earth
removal” might include a requirement to study the geological
drawings of the area where the earth is to be removed. This
study would further define whether a backhoe or just shovels
will be needed, or maybe even dynamite depending on the
matter to be removed. In other words, this study is part of the
requirements analysis but might never have been identified as
work that would take time if we had not analyzed this part of
the WBS. This geological study may also identify other required
deliverables, like an environmental study.
A study to locate any utility lines, as well as many other timeconsuming activities, might need to be performed before any
earth is removed from the ground. But that is the whole point of
the WBS—it is the tool that helps identify anything that might
take time in the project, and since that time usually translates
into money, it helps determine if we really can afford to do the
project within our budget.
“Earth disposal” might be another subproject. For example,
the initiation process decision may be to use the earth taken out
of the ground to build a garden in another part of the yard. This
subproject would require its own breakdown of major parts.
Let’s take a look, in Figure 3-2, at what the WBS of the hole
might look like.
Defining the Scope
33
Hole
Earth Removal
Environmental
Study
Earth Disposal
Excavation
Shovels
Garden
Wheelbarrow
Trees
Plants
Figure 3‑2. WBS of Hole
Notice that the lines under subdeliverable “hole” and the two
subprojects extend further than what we’ve identified. That’s
because work packages—in this example, those actions that
need to be undertaken to remove the earth or dispose of the
earth—have yet to be added to our WBS. Work packages are the
lowest level of any branch of the WBS where resources will be
assigned responsibility. Let’s take a look at what types of actions
or work packages can be identified so far in our structure.
The pond, as a whole, will need to be designed. This design
of the pond will probably be a drawing of what the entire pond
should look like once it is completed. The drawing should show
each of the major parts of the pond that we decide will be part
of the scope through the initiation process. Keep in mind that
this work package can be broken down further into individual
tasks, such as conducting a site survey, developing a drawing,
and having the drawing reviewed and approved by the customer. You could almost say that this is a project in itself (which
goes along with Tom Peters’ philosophy that all work is project
work, mentioned in Chapter 1).
The pond will need to be tested. Maybe this will involve nothing more than an inspection that will take too small an amount
of time to track on the project, but it will take time nonetheless.
34
Integrated Cost and Schedule Control
In other projects, a test might be further broken down into such
work packages as developing a test plan, identifying various
test scenarios, performing the tests, writing the test reports, etc.,
each of which could be broken down even further.
Now let’s take a look at the hole for the pond. The hole will
need it own design. This design is different from the pond design because the hole needs a drawing that shows how long
it should be, how wide it should be, how deep it should be,
and where the shelves to hold those plants that need water but
do not like being at the bottom of the pond (e.g., “bog plants”
needed for filtration) should be constructed. A test will have to
be conducted to make sure the hole will hold the plants properly. This test will take time and that time needs to be included
in the project plan, especially if you want the project completed
over a limited period of time, like a weekend.
The method for removing the earth has to be determined.
An environmental assessment may need to be performed before any earth is removed. Do we need to buy a shovel, rent a
backhoe, acquire some dynamite? If we build a garden with the
removed earth, then the garden will need to be designed, and
so on.
Now let’s look at the subdeliverable “water.” Three major
functions have to take place to have water in the pond (which
are very similar to any project that must deliver an information
system, often referred to as an information technology, or IT,
project): (1) water has to get into the pond (input of information), (2) water has to circulate (processing and storage of information), and (3) at times water has to be drained from the pond
(distribution of information), as displayed in Figure 3-3.
Each of these functions can be deemed a subproject. For example, “water in” could mean an entire plumbing system that
pumps water from a water source to the pond. Often a landscape artist who specializes in ponds will contract this out to
Defining the Scope
35
Water
Water In
Water Removal
Water Circulates
Figure 3‑3. Breakdown of Water Subdeliverable
someone who specializes in plumbing systems. The details of
this plumbing system should be broken down by someone who
is familiar with all the requirements of this kind of system.
Water circulating would require a pump, which in turn requires electricity, which might be another subproject where a
certified electrician might be needed to run a new electrical line
from the power source of the house to the area of the pond for
the pump to plug or tap into. A water treatment or waterfall
that might be one of the major components of the pond would
need to interface with this pump via a hose or tubing that would
have to be purchased. This water treatment may require a more
powerful pump. Filters for the pump will be required. In other
words, the circulation of water is a project in itself.
Water draining might also require an environmental study,
depending on how and where the water is to be drained. An
actual drain might need to be buried, which would change the
requirements of the subproject for earth removal.
36
Integrated Cost and Schedule Control
Again, the work of each of these identified subprojects and
components takes effort that will cost money and will take time.
Accordingly, decisions about whether or not to include these
subprojects and components in the scope of the project need to
be made before any of this work can be planned. I’m not sure
who first said it, but you can’t plan what you don’t know. The
WBS, here in the initiation process, is the tool that helps us figure it all out—or at least as much of it as we can.
To many in the software product development world, a
­deliverable-oriented WBS is still quite foreign. This world still
wants to base its WBS on time phases, not the functionality of
the software. They have yet to understand that the WBS should
be based on the functionality that the software is supposed to
deliver to the customer, not time. If the WBS is broken down
in the same manner as the architectural breakdown of the
functionality, then all the different designs that need to occur
at each level of the functional breakdown would be defined
as individual work packages and, depending on the number
of resources that have the skills to do the individual designs,
the work can be scheduled over time in a much more efficient,
overlapped manner.
FSTAI Software Company
One of my very first consulting jobs was to help a small software
development firm. The project manager complained to me that the
project was behind in the “code and unit test phase.” I told him that
the only way I would be able to help him would be to take the team
off-site and facilitate the redevelopment of their WBS. He agreed to
bring me on to give it a try.
I brought the team to a conference room and proceeded to ask
them about “what” their software would do for the customer. Each
time they told me the functionality, I wrote it on a Post-it® note. I
would then go to each functional part and continue to decompose
it based on “what” it would do for the customer. At the end of this
Defining the Scope
37
exercise, I had the full functional architecture of their software on
the wall on Post-it® notes.
I then put a design Post-it® note and a test Post-it® note on each
function and put separate design, code, and unit test Post-it® note
on each function point at the bottom of the structure. I explained
to them that this is what the WBS should have looked like. They, of
course, told me that they had never done a WBS in this way.
I then took the design of the whole software Post-it® note and
asked if that work package was completed. They all chorused “yes,”
so I threw it away. I proceeded down the structure to each subfunction’s design Post-it® note and asked the same question. The
higher-level Post-it® notes were all thrown away, but when I got to a
fourth-level design Post-it,® the project manager said “yes,” but the
team stayed quiet. After some time, a team member volunteered that
this was one of their problems—that the design of that functionality had yet to be completed. I then put the Post-it® note back on the
wall, at which time the project manager said, “but I have a design
document approved and signed off.” It was obvious that the dozen
or so people expected to review and approve the design document
had no real idea what they were reviewing.
The flip side of this was that a number of function points had
completed their design, code, and unit test. When I asked why these
function points were not being integrated and tested as higher-level
functionality, I was told, “We can’t. We’re not in our test phase
yet.” So there was a lot of design work that had not started yet and
a lot of test work that was being artificially held off because of their
“phased” approach.
Worse yet was the feeling the team members had been getting
that the project was a “failure.” Once their success with the integration and testing at the various higher levels of functionality was
recognized, the team was able to develop a recovery plan and within
two months they had the project back on track.
38
Integrated Cost and Schedule Control
To have a complete set of work packages for the deliverableoriented WBS, each subdeliverable, or component part, of the
overall deliverable will require its own design work package
and its own test work package, plus any logistics that are specifically focused on that subdeliverable (e.g., training, equipment, manuals). Each of these subdeliverables could be deemed
sub-projects, which means that they each will need work packages addressing their specific design, test, logistics, etc. It’s the
part in the middle (the “build”) that usually involves one of six
decisions:
1. Are we (the project team, under the leadership of the project manager) going to build it? If so, we probably should
continue to break it down.
2. Have we already built it (a part on our shelf, or a reusable
software function previously coded) and can we get it “off
the shelf”?
3. Is another department in our organization or company,
over which we have no control, going to build it? If so,
should they be asked to break it down further?
4. Have they already built it and can we get it from “off their
shelf”?
5. Do we need to have an outside vendor build it, which will
require a contract that should ask them to break it down
further?
6. Has an outside vendor already built it and can it be acquired from “off their shelf”?
Often I’ve seen the expression “Buy COTS” (commercial off
the shelf) used in a project plan as one task. I often wonder how
anyone estimates how long that takes or how much that might
cost. I’m often told that the procurement department is responsible for defining what it is, how long it will take, and at what
Defining the Scope
39
cost. But “buy COTS” is a very ambiguous term that is meaningless to anyone until each item to be bought is specifically
defined. The project managers who include this in their project
plans are not delegating, but are instead abdicating responsibility for this part of the initiation process. Admittedly, the initiation process is hard to carry out, but abdicating responsibility
and using ambiguous expressions for work does not make it
easier.
Once we have defined the scope of what the customer needs
and wants, we need to develop cost estimates for each of the
parts of this scope so that the customer’s expectations can be
balanced to their budget for the project.
7Building a
Network
Schedule
It was in the late 1950s that many of the project management
philosophies used today were first recognized and the first
scheduling techniques were developed. At that time a few astute gentlemen recognized that the work tasks of a project are
dependent on each other and that a “workflow diagram” could
be developed to show this. Associating this workflow diagram
to the timeline developed by Henry Gantt during the early part
of the century allowed the work to be planned so the workers
knew when they were expected to start and finish each task.
This also gave the project manager a mechanism to oversee
the work and manage the impacts of work being accomplished
late.
These techniques matured during the early 1960s using various forms of network analysis to develop the methods of network scheduling that are used today. Two of these methods are
the arrow diagramming method (ADM) and the more mature
precedence diagramming method (PDM.)
Before we explore these two methods, there are certain “rules”
that pertain to every network schedule:
• Only the lowest level of each of the branches of the WBS,
the work package level, further decomposed activities or
tasks, or un-decomposed planning package level—should
be networked together in the schedule.
• A network can only have one start and one finish. When
more than one logically independent network schedule
94
Integrated Cost and Schedule Control
occurs in a project, each individual network needs to have
one start and one finish.
• Each work package, task, activity, or planning package
must have at least one predecessor to its start, unless it is
the one start.
• Each work package, task, activity, or planning package must
have at least one successor from its finish, unless it is the one
finish.
Many situations will fall into the category of “chicken and egg.”
For example, is the design of the hole in the pond mentioned in
Chapter 3 dependent on the design of the livestock and the
plants, or is the design of the livestock and the plants dependent
on the design of the hole? Some fish will grow dependent on their
environment. If we want large fish, then the design of the hole is
dependent on the type of fish we buy and how large we want the
fish to grow. If we do not care about the fish growing, then the
type of fish we buy is dependent on the design of the hole.
It is critical to have your entire team assembled to assist in
putting together the network schedule. You want input from the
team so that you, as the project manager, can make the final decision. This goes back to our basic concept of success. If the team
has input into the decision, they can more willingly accept the
notion of it possibly being the wrong decision and will provide
further input to help resolve the issue. If you make the decision
with no input from the team, and it turns out to be a wrong decision, the team may wonder why the decision was made in the
first place and you will lose credibility as a leader.
Network Scheduling Using the Arrow
Diagramming Method
Many students ask why we would even address arrow diagramming methods when hardly anyone uses it anymore. I
usually answer them with “That’s not true.”
Building a Network Schedule
95
Sprint Corporation
One of the best uses of arrow diagramming methods I’ve seen was
instituted at the Sprint Corporation back in the 1990s. An employee
decided that he could get the upper levels of management at Sprint
to use project management techniques to express their strategic
visions of where the company should be in 5–10 years. He used an
arrow diagram, networking what projects would be needed to get
them there. He then had the Graphics Department draw the project
diagrams in such a way that they could be displayed on the walls
throughout the company’s headquarters.
This accomplished a number of very positive things: It showed
each project team member how their project fit into the strategic vision of the company; it allowed good decision making concerning if
and when to terminate a project that no longer fit into the strategic
vision of the company; and, better yet, it provided a discipline to the
company’s upper management that they could not just change their
mind on a whim, but would have to map out any new vision and
show how the ongoing projects would fit into this new vision.
The only down side to this was that because upper management used what they refer to as “task on arrow,” all the project
managers assumed that they were to use the same network
diagramming method. ADM works best when there are only
a few work packages (in Sprint’s case, projects) that are being
networked together.
Let’s see why this is. First of all, ADM, also known as activity
on arrow (AOA) or task on arrow (TOA), was the first network
scheduling technique developed back in the late 1950s by an
employee at DuPont Industries. Before that time, the concept of
linking the completion of one project activity as a predecessor
to allow the start of another project activity in a network was
not recognized. ADM allowed for networking and display of all
project activities. This was then used to show how the work of
96
Integrated Cost and Schedule Control
the project was to be performed and how much time the project
might take to complete. Using ADM, all the information about
an activity or work package is displayed on the arrow (see Figure 7-1).
Figure 7‑1. Example Network Schedule Using ADM
This method can display workflow to a completion time, but
it has a few limiting features:
• ADM can only display the relationship between two work
packages as a finish-to-start relationship, which is limiting
and often unrealistic.
• Using the arrows in ADM to display the work package
information requires the use of a “dummy arrow” to show
some relationships.
To illustrate a network schedule using ADM, let’s look at the
six work packages of a small wallpapering project in Table 7-1.
Building a Network Schedule
97
Work PackageDuration
Buy Wallpaper 4 Hours
Buy Supplies 2 Hours
Cut Wallpaper 3 Hours
Prepare Walls 8 Hours
Hang Wallpaper
12 Hours
Clean Up 2 Hours
Table 7‑1. Work Packages for Wallpaper Hanging Example Project
If I were the only resource doing this wallpaper project, the
network schedule would be one arrow after the other, because
I can only do one thing at a time. Even though I can go to the
same store to buy the wallpaper and the supplies, I can only do
one of those work packages at any given time.
If I have help, however, the network schedule may look like
Figure 7-2.
Figure 7‑2. Example Arrow Diagram
98
Integrated Cost and Schedule Control
Because I have help, buying the wallpaper can happen at
the same time as buying the supplies. Cutting the wallpaper is
dependent on having bought the wallpaper, but also on having
bought supplies with which to cut the wallpaper. This is where
a “dummy” activity comes into play. I could place the start of
the “cut wallpaper” activity on the finish of the “buy wallpaper” activity, but there also needs to be a “dummy” arrow going
from the finish of the “buy supplies” activity to the start of the
“cut wallpaper” activity.
The “prepare walls” activity is dependent only on the “buy
supplies” activity. The “hang wallpaper” activity is dependent
on having the wallpaper cut but also on having the walls prepared. This requires another “dummy” activity going from the
finish of the “prepare walls” activity to the start of the “hang
wallpaper” activity. The “clean up” activity is dependent only
on having the wallpaper hung, and it is the last activity, so it
goes to the end.
In this example, there are two “dummy” arrows. In a large,
complex project, with many interdependencies, this method
would get very messy and would not be the best method to
use. However, for smaller projects or to strategize at the higher
levels of a large project, this method is easiest and works quite
well.
In the early 1960s the U.S. Navy began to use this arrow diagramming technique for their many projects. They discovered
that work flows in what they called “paths” from the start of
the project to the end. The longest path gave them the duration
of the project, which they could report to their superiors. This
longest path was dubbed “the critical path” because, if the work
on this path was not completed as planned, the projected completion date could be missed. The Navy also began to perform
Building a Network Schedule
99
more analysis of the critical path, using what they called the
Program Evaluation and Review Technique (PERT, introduced
in Chapter 4 and discussed further in Chapter 9), to determine
the probability of meeting the project completion date.
Today, the concept of the critical path is widely misunderstood by many who call themselves project managers. The critical path has nothing to do with the critical work of the project. As a
matter of fact, the critical path has its own inherent risk, in that
it is the path of work that could cause the scheduled end date
to be missed. It would seem that the prudent project manager
would try to keep the critical work of the project off the critical
path.
The critical path is not the only path of work that has to be
managed. As we will see with an example of our next diagramming method, if the noncritical paths of the schedule are ignored, the project could be doomed to failure.
The critical path is the longest path through the network
schedule and, therefore, determines the duration of the schedule. It is the path (and there can be more than one critical path)
of the work that must be completed as planned if the completion dates of the project are to be met. (As we will see in Chapter
8, there are techniques that can be used to change the critical
path as needed.)
Looking back at our example arrow diagram in Figure 7-2,
three paths reach from the start of the project to the end of the
project. Each of these must be analyzed to determine which one
is the longest path (i.e., the critical path.) Figures 7-3, 7-4, and
7-5 show the three paths and how long it would take to do only
the work on each.
100 Integrated Cost and Schedule Control
Figure 7‑3. First Path through Arrow Diagram
Figure 7‑4. Second Path through Arrow Diagram
Building a Network Schedule 101
Figure 7‑5. Third Path through Arrow Diagram
The third path (Figure 7-5) is the longest and therefore the
critical path, which tells us that the project will require 24 working hours to complete with the network schedule that we have
now.
To see if you can pick out the paths and determine which one
is the critical path, try Exercise 7-A.
In the arrow diagram below: How many paths are there? Which path is the longest (i.e., the critical
path)?
Exercise 7‑A
Arrow Diagramming Method
102 Integrated Cost and Schedule Control
Building a Network Schedule 103
Solution for Exercise 7-A
Arrow Diagramming
Method
There are six paths:
Start -> A -> B -> E -> H
Start -> A -> B -> E -> G -> H
Start -> A -> C -> B -> E -> H
Start -> A -> C -> B -> E -> G -> H
Start -> A -> C -> F -> G -> H
Start -> A -> D -> F -> G -> H
The longest is:
Start -> A -> B -> E -> G -> H = 27
104 Integrated Cost and Schedule Control
Network Scheduling Using the
Precedence Diagramming Method
Because the arrow diagramming method only allows finishto-start relationships and uses “dummy” activities, it became
obvious to the early developers of network scheduling techniques that this method does not work as well for large, complex projects; thus, the advent of the precedence diagramming
method (PDM). Also known as activity on node (AON), PDM
puts the information about the activity on the node of the network and, because it uses the arrows only to show relationships,
it allows all four of the task relationships to be displayed.
This method is far more conducive to team collaboration and
the use of the Post-it® notes used in building the WBS. Only the
work package Post-it® notes at the bottom of any branch of our
WBS are put in the network schedule, and the facilitator can
place each Post-it® note in the network as the team describes.
Let’s use the wallpaper example to demonstrate this method.
If we assume that there is just one resource, Figure 7-6 shows a
possible PDM network.
It can be argued whether to buy the wallpaper before the
supplies or the other way around. This is an example of the
“chicken and egg” dilemma. If a team member believes that one
way is best, he or she should be allowed to express an opinion.
If the team as a whole overrides an individual team member’s
opinion, that team member will tend to accept the team’s decision even though he or she may not agree with it.
On the other hand, if the project manager makes all the decisions without letting the team members express their opinions, the team will tend to be less productive on the project,
especially if they feel that the decision was the wrong one. The
project managers who have the most successful projects encourage their teams to express their opinions throughout both the
initiating and the planning subprocesses.
Figure 7‑6. Example Precedence Diagram
Building a Network Schedule 105
106 Integrated Cost and Schedule Control
There is a big difference between working time and calendar
time. Our full calendar day is a combination of both working
time and non-working time; we need to identify both to understand the work being done over time. Project management
software tools also must be “educated” as to what we mean by
working and non-working time if they are to accomplish the
analysis of the network schedule and be able to produce the
information we need to manage the project.
For example, let’s assume that I would like to do this wall­
paper project over a weekend, starting Saturday morning. Now,
I’m an early riser who likes to do her yoga in the dark. I try to
start any project by 8:00 a.m., and I have plans to go out to dinner with friends on Saturday night, so I want to stop working at
6:00 p.m. I’ll get up and go to an early church service on Sunday
and be able to start work by 8:00 a.m. Sunday is clear for the
rest of the day for me to continue to work as long as I need to in
order to finish the job, but I do have to go to work on Monday.
To identify the time that each work package can start and
finish, we will need to perform what is called a “forward pass”
and place the notation of this early start/finish time on the upper corners of our Post-it® note box. Performing a forward pass
enables us to identify the earliest time that each work package
can start based on the relationship it has with its predecessor(s).
(A detailed explanation of the steps of the techniques used in
this example will be presented in Chapter 8.)
Figure 7-7 displays a forward pass on our wallpapering project network schedule as we currently have it. Note that our start
time is 8:00 a.m. on Saturday.
Since the duration of our first work package, “buy wallpaper,” is four hours, the earliest it can finish is noon. Because
there is a finish-to-start relationship between “buy wallpaper”
and “buy supplies,” the earliest time that our “buy supplies”
work package can start is noon. Since the duration of “buy supplies” is two hours, the earliest we can finish this work package
Figure 7‑7. Example Precedence Diagram with Forward Pass
Building a Network Schedule 107
108 Integrated Cost and Schedule Control
is 2:00 p.m.; the earliest we can start the “prepare walls” work
package is also 2:00 p.m.
The duration of the “prepare walls” work package is longer
than the rest of the working time that is left for Saturday (remember, I want to stop at 6:00 p.m. to get ready to go out to
dinner with friends). This means that four of the eight working
hours required to prepare the walls can be done on Saturday
and the other four working hours will begin at 8:00 a.m. and
finish at noon on Sunday. The forward pass then continues
through the rest of the network until we find the earliest time
that the last work package, “clean up,” can finish.
As you see, I can get the job done in time to jump in the
shower and prepare for work, but I probably am not going to be
very productive at my job because I got very little sleep Sunday
night. Since being productive at my job is a much higher priority than having a wallpaper project completed, I must decide if
I should cancel or try to find another resource to help me get the
project completed sooner.
If I can find additional resources, I can then redo my precedence diagram and perform a new forward pass to see if I
can develop a more realistic planned schedule for my project.
Re­doing the network schedule to get the work accomplished
sooner is called “compressing the network schedule.”
Compressing Our Example Schedule
According to the PMBOK® Guide, schedule compression is
“shortening the project schedule without reducing the project
scope, to meet schedule constraints, imposed dates, or other
schedule objectives.” Two techniques used to achieve schedule
compression are “fast tracking” and “crashing.”
Fast tracking is the rescheduling of activities that would normally be planned to be completed in series, one after the other
Building a Network Schedule 109
in a finish-to-start relationship, to be accomplished in parallel.
For the full compression to be realized, if the same resource is
assigned to the activity being rescheduled in parallel, then a
new resource would need to be found who can accomplish the
work with the same productivity as the original resource.
Some think that this addition of resources will end up doubling the cost of the project, but it normally does not. Let’s add
some costs to our example to see if this is true. We will do this
as simply as we can by assuming that my unit cost is $100 per
hour. As can be seen in Figure 7-8, the total costs for the project
would be estimated as $3,100.
Let’s now see if we can get some work planned to be completed in parallel, understanding that this will require additional
resources.
As seen in our arrow diagram of the previous section and
also as shown in Figure 7-9, we can plan for one resource to buy
the wallpaper while another resource buys the supplies. This
allows both work packages to begin at the start of the project.
The cutting of the wallpaper is dependent on both the wallpaper having been bought and the supplies with which to cut it
having been bought. Preparing the walls is dependent only on
the supplies having been bought. Hanging the wallpaper is dependent on both the wallpaper having been cut and the walls
having been prepared. Once the hanging of the wallpaper is
finished, we can clean up.
The total estimated cost of the project remains at $3,100. This
is because the activities of buying and cutting the wallpaper
were taken away from the original resource (i.e., $700 worth of
work is no longer assigned to the original resource) and are now
assigned to the new resource.
Our new forward pass is shown in Figure 7-10.
Figure 7‑8. Example Precedence Diagram with Estimated Costs
110 Integrated Cost and Schedule Control
Building a Network Schedule 111
Figure 7‑9. Example Precedence Diagram Compressed
Figure 7‑10. Example Precedence Diagram Compressed with
Forward Pass
112 Integrated Cost and Schedule Control
Notice that the “cut wallpaper” work package is dependent
on both the wallpaper being bought and the supplies being
bought (i.e., it must wait until both of these work packages are
completed). Of the two, the work package that takes longer is
“buy wallpaper.” So, the earliest time that “cut wallpaper” can
start is the earliest time that “buy wallpaper” can finish, i.e.,
noon.
“Hang wallpaper” is another example of a work package that
is dependent on two predecessor work packages (cut wallpaper
and prepare walls) being completed before it can start. Since the
“prepare walls” work package takes the longest and the earliest that it can finish is 6:00 p.m., which is when I want to stop
working on Saturday. This means that the earliest the “hang
wallpaper” work package can start is 8:00 a.m. on Sunday.
Completing the forward pass on my network schedule determines that the earliest I can complete my entire project is
10:00 p.m. on Sunday. I can live with that and still get a good
night’s sleep to be productive at my job on Monday morning.
With more resources, I could probably get the project done
more quickly, but why overuse resources if the end time meets
my objectives of getting the job completed in a weekend, having dinner with my friends on Saturday, and being productive
at work Monday morning? As currently planned, my project
needs only one additional resource on Saturday from 8:00 a.m.
until 3:00 p.m.—and at no extra charge, assuming their rate is
the same as mine!
Now that I know the end time for my project, I can further
analyze the network schedule to determine how much flexibility there is related to when each work package “can” start and
when each “must” start. To do this I will perform what is called
a “backward pass” and note these late start/finish times in the
lower corners of my Post-it notes box. The backward pass
identifies the latest time that any task must start and finish.
Building a Network Schedule 113
The backward pass starts at the end time of the entire network schedule, which was determined based on the early finish
of the last work package while performing the forward pass.
The analysis for the backward pass uses a disciplined “must”
mode. An example of this disciplined thinking, when all work
packages have finish-to-start relationships, is the following:
If the last work package is to finish at a particular time, when
is the latest it must start, based on its duration? For this work
package to start at this late start time, all of its predecessors
must be finished by that time or before, so what is the latest that
each predecessor must finish? The technique continues to work
backward to try to determine when each work package must
finish, and based on its duration must subsequently start, until
all the work packages have a late finish and a late start.
The backward pass in our example (see Figure 7-11) starts
with the “clean up” work package and identifies the latest we
want that work package to finish as 10:00 p.m. Going backward,
the latest that this two-hour work package must start to meet
the 10:00 p.m. finish time is 8:00 p.m. For that to happen, all of
the predecessors of the “clean up” work package must be finished by 8:00 p.m., or sooner.
Figure 7‑11. Example Precedence Diagram Compressed with
Backward Pass
114 Integrated Cost and Schedule Control
The predecessor of the “clean up” work package is the “hang
wallpaper” work package. Before we can determine the late finish of the “hang wallpaper” work package, we must first see if
it is a predecessor to any other work package in the network. If
it is a predecessor to more than one work package, we would
need to determine the successor work package that has the earlier of the late starts and get the “hang wallpaper” work package done in time for that successor, which would subsequently
have it finished in time for the other successor work packages’
late start.
Because the “hang wallpaper” work package is not a predecessor to any other work package, the only criterion for the
“hang wallpaper” work package is to get it done in time for the
“clean up” work package’s late start (i.e., 8:00 p.m.). Therefore,
the late finish for the “hang wallpaper” work package is 8:00
p.m., which in turn means, because the duration of the “hang
wallpaper” work package is 12 hours, that the latest I must start
hanging the wallpaper is 8:00 a.m. For this 8:00 a.m. start to happen, all the predecessors of the “hang wallpaper” work package
must be finished no later than 6:00 p.m. on Saturday.
The “prepare walls” work package is a predecessor to only
the “hang wallpaper” work package, which means that it must
finish by 6:00 p.m. Saturday and, because it has a duration of
eight hours, it must start at 10:00 a.m. The “cut wallpaper” work
package is a predecessor to only the “hang wallpaper” work
package, which means that it must finish by 6:00 p.m. Saturday
and, because it has a duration of three hours, it must start at
3:00 p.m. The “buy wallpaper” work package is a predecessor
to only the “cut wallpaper” work package, which means that it
must finish by 3:00 p.m. Saturday and, because it has a duration
of four hours, it must start at 11:00 a.m.
The “buy supplies” work package, however, is the predecessor to both the “cut wallpaper” work package and the “prepare
Building a Network Schedule 115
walls” work package. This means that to determine the latest
time that the “buy supplies” work package must finish, we need
to determine which of its two successor work packages has the
earlier late start. The “cut wallpaper” work package’s late start
is 3:00 p.m. The “prepare walls” work package’s late start is
10:00 a.m., which is the earlier of the two. This means that the
“buy supplies” work package must finish no later than 10:00
a.m., which is in time for both of its successor work packages’
late starts. Because it has a duration of two hours, the “buy supplies” work package must start at 8:00 a.m.
The forward pass identified the early start and early finish for
each work package. The backward pass identified the late start
and late finish for each work package. The difference between
the late start and the early start, or the late finish and the early
finish, tell us how much time a work package can be rescheduled before the end time of the network schedule, 10:00 p.m. on
Sunday in our example, can no longer be successfully accomplished. This time is referred to as “total float” or “total slack.”
Total float is calculated for each work package individually.
If this difference in time is zero, then the work package is on a
critical path, which gives us another definition for the critical
path. If this difference is negative, than the work package is
considered “critically late” and the network schedule end time
will not be successfully accomplished unless some replanning
of the schedule is performed.
Note that total float does not refer to different amounts of float
being added together as the total float of the project. A project
does not have any total float because the duration of the project
is determined by the critical path, which has no flexibility.
Figure 7-12 displays the total float of each work package and
the critical path.
116 Integrated Cost and Schedule Control
Figure 7‑12. Example Showing Total Float and Critical Path
Too often project managers say that once they know the critical path, they have identified the only path to which they need
to pay attention. Let’s take a look at our example and one scenario that may cast doubt on this notion.
The total float for the “buy wallpaper” work package is three
hours (late start of 11:00 a.m minus the early start of 8:00 a.m.)
and the total float of the “cut wallpaper” is three hours (late
start of 3:00 p.m. minus the early start of 12:00 noon). Neither of
these work packages is on the critical path.
The “buy wallpaper” work package can start as early as
8:00 a.m., but the latest it must start is 11:00 a.m. If we assign the
“buy wallpaper” work package to someone who likes to sleep
in on Saturdays, they might not want to start that work package until the latest it must start, 11:00 a.m. The unenlightened
would think that, since there are three hours of total float in this
work package, this would not pose a problem. Well, let’s see.
Let’s say that we also have assigned the “cut wallpaper”
work package to a resource who comes from a wallpaper-
Building a Network Schedule 117
cutting department. This resource might be assigned to multiple
projects that have wallpaper-cutting work packages. Let’s say,
for example, that they are assigned to Project X to cut wallpaper
from 8:00 a.m. to 11:00 a.m. They break for lunch before they
come to our house at noon to accomplish our wallpaper-cutting
work package, after which they are assigned to Project Y to start
cutting wallpaper at 3:00 p.m. The wallpaper-cutting resource
now has a full day of work scheduled.
Under this circumstance we could have a wallpaper-cutting
resource show up at our house on time at noon, but we have no
wallpaper to cut. This not only changes our plan, but we would
need to pay this resource for the time that they are standing
around and getting absolutely nothing done. Then at 3:00 p.m.,
when the resource who was assigned to buy the wallpaper
shows up with an armful of wallpaper, a very difficult decision
has to be made (and we usually expect our resources to make
this decision): Does the wallpaper-cutting resource stay and cut
our wallpaper or does this resource go to Project Y as assigned?
The former decision would keep our project on track, but may
have a detrimental impact on Project Y. The latter decision
would cause our project to come to a dead stop.
This situation could have been avoided by using another
piece of important information that can be calculated from our
forward and backward pass data and that might have alerted
us before we made any adjustments to our schedule. This is the
calculation of how much of the total float time the work package
can slip before it impacts another work package. This is commonly referred to as “free float” or “free slack.” For a finish-tostart relationship with a successor, the free float is the difference
between the early start of the successor and the early finish of
the work package that we are analyzing.
Had we calculated the free float of the “buy wallpaper” work
package, we would have found it to be zero (early start of the
successor, “cut wallpaper” = noon, minus the early finish of
work package being analyzed = noon). This means that the buying of the wallpaper cannot be delayed at all from its early start
118 Integrated Cost and Schedule Control
without impacting the “cut wallpaper” work package. In this
case that impact could be detrimental to the entire project because we would need a resource that may no longer be available
and, worse yet, we would have been paying for this resource’s
time when absolutely nothing was accomplished.
Now let’s say that the manager of the Wallpaper-Cutting Department approaches us and asks if it would be okay for their
wallpaper-cutting resource to work on Project X in the morning, work on Project Y from noon to 2:00 p.m., and then come
to our house at 2:00 p.m. to cut our wallpaper. We would need
to look for the successor to the “cut wallpaper” work package,
which is the “hang wallpaper” work package. The early start
of the “hang wallpaper” work package is 8:00 a.m. on Sunday,
which is synonymous with 6:00 p.m. on Saturday, because we
do this calculation using working time only. We would need to
subtract the early finish of the “cut wallpaper” work package,
which is 3:00 p.m. We would find that all of the total float of the
“cut wallpaper” work package is free to us, which means that
this work package can be delayed without any impact on any
other work package in our network schedule.
If we delay the start of the “cut wallpaper” work package to
2:00 p.m., the earliest it can finish now is 5:00 p.m. Its total float
would now be one hour, and that one hour is still free to us.
Plus, we have now freed up two of the three hours of total float
of the “buy wallpaper” work package. The resource who likes
to sleep in can now delay the start of the “buy wallpaper” work
package to 10:00 a.m. with no impact on the rest of the network
schedule.
Figure 7-13 shows our wallpaper example with the free float
information added.
Building a Network Schedule 119
Figure 7‑13. Forward Pass and Backward Pass on the Wallpaper
Example with Total Float, Free Float, and Critical Path
Planning Our Example Resources
Understanding our resource needs is another very important
part of developing a network schedule. Our previous analysis
shows that we could not have planned to have the project completed by 10:00 p.m. on Sunday unless we were able to get an
additional resource to take over the two work packages “buy
wallpaper” and “cut wallpaper” on Saturday. The resource
profile of my project is displayed in Figure 7-14, which shows
that I need two resources between 8:00 a.m. and 3:00 p.m. on
Saturday.
Now looking for ways to compress the schedule even more,
we could change the relationships of the work packages to have
work done in parallel. We would start by recognizing that the
“hang wallpaper” work package does not need to wait for all
120 Integrated Cost and Schedule Control
Figure 7-14. Example Resource Histogram
the walls to be prepared and for all the wallpaper to be cut.
We could change the finish-to-start relationship between these
work packages to a start-to-start, with a lag, that allows enough
time for some walls to be prepared (let’s say two hours) and the
wallpaper to be cut (let’s say one hour) to be able to start hanging the wallpaper.
Our network diagram would change to look like the one displayed in Figure 7-15.
Building a Network Schedule 121
Figure 7‑15. Further Compressing Example Precedence Diagram
Using Fast Tracking
This allows us to finish the entire project by 5:00 p.m. on
Sunday.
Our resource histogram will look like Figure 7-16.
122 Integrated Cost and Schedule Control
Figure 7‑16. Example Resource Histogram 2
If 5:00 p.m. on Sunday is still later than we want this project to
take, we have many other solutions that will help compress the
project duration. For example, if the wallpapering is being done
in two distinctly different areas, we could cut that work package
in half, assign each half to a different resource at no additional
cost, and compress the schedule as shown in Figure 7-17.
Our resource histogram now looks like Figure 7-18.
Compressing Our Example Even More
The other schedule compression technique that we can use is
“crashing.” Crashing involves assigning additional resources to
an individual work package to get it accomplished sooner. This
has to be done realistically or it may not work. For instance, if
an additional resource were assigned to the “buy wallpaper”
work package, it might cause that work package to take longer
to be accomplished since the two resources might have ­differing
Building a Network Schedule 123
Figure 7‑17. More Compression of Example Precedence Diagram
Using Fast Tracking
Figure 7‑18. Example Resource Histogram 3
124 Integrated Cost and Schedule Control
ideas on which is the best wallpaper to buy. However, in our
example, we might choose to assign an additional resource to
each “hang wallpaper” work package. This would not necessarily cut the duration of these work packages in half, but it might
reduce the duration from six hours each to four hours each,
which would in turn add costs for each resource working an
additional hour (i.e., two resources working four hours each at
$100 an hour equals $800 per work package.) With this adjustment, our total project cost rises to $3,500 for labor.
We would also need to compress our “prepare walls” work
package, because it is now taking longer than the “hang wallpaper” work package.
We can get the “prepare walls” work package accomplished
sooner by adding a resource to that work package, and this may
cut the duration in half. We could also add a resource to the
“clean up” work package, which might reduce its duration by
half. Our final schedule would look like Figure 7-19.
Note that all of the work is scheduled to be accomplished by
6:00 p.m. on Saturday. The number of resources we need to be
able to accomplish this is shown in Figure 7-20.
Did we spend more money to compress our network schedule from an essentially three-day project to a shortened one-day
project? You bet. We now need to plan to pay $3,500 for just the
labor, versus the original estimate of $3,100, plus any additional
supply costs.
Is the added cost worth the time compression? Only the
customer, who is paying for the project, or the sponsor, whose
budget is paying for the project, can make that decision. This is
what is known as a time/cost tradeoff analysis.
Building a Network Schedule 125
Figure 7‑19. Final Compression of Example Precedence Diagram
Figure 7‑20. Resource Histogram of Final Compression
9Analyzing
Schedule Risk
If the critical path is not the only path we need to manage,
we may ask: What is the use of the critical path? The most
important use of the critical path relates to the concept of risk
management. By virtue of being the path (or paths) of work
packages that have no float, the critical path involves an inherent schedule risk. At the very least, we should check to see what
work falls on the critical path. If the critical path happens to run
through some of our riskiest work, our probability of success
is reduced. To increase our probability of success, we should
remove the risky work packages from the critical path using the
schedule compression techniques described in Chapter 8.
Analyzing the Critical Path Using PERT
The Program Evaluation and Review Technique (PERT) was
devised in 1958 by the U.S. Department of Defense’s Navy
Special Projects Office as part of the Polaris mobile submarine
launch project, which was a direct response to the Sputnik crisis.
PERT is basically a statistical summation method of ­analyzing
the work packages along the critical path to determine the probability of success of completing the project given the current
network schedule.
PERT is often criticized because it does not consider the summation of the probabilities of the noncritical paths where they
merge with the critical path. For project managers who do not
analyze their critical path at all using any method, PERT is a
great, simple-to-understand place to start.
156 Integrated Cost and Schedule Control
The basis for a PERT analysis is to have estimates for work
packages based on four pieces of information (as discussed in
Chapter 4):
• A most likely estimate for completing the work package
• An estimate for completing the work package if everything
goes perfectly (the optimistic estimate)
• Two or three things that could go wrong while completing
the work package (risk identification)
• How long it would take to complete the work package if all
these things do go wrong (the pessimistic estimate)
Once we have these four pieces of information for each work
package, the PERT formula to determine the PERT mean is:
PERT Mean =
O + 4ML+P
6
Where:
O = optimistic estimate
ML = most likely estimate
P = pessimistic estimate
Another piece of statistical information that we need to perform this PERT analysis is the standard deviation of each work
package. The formula for the PERT standard deviation is:
PERT Standard Deviation =
P–O
6
The real analysis that takes place here comes from the basics
of statistical analysis. Generally speaking, the reason we use statistics is to be able to make more precise decisions. We do this by
gathering as much data as we can, plotting the data, and hoping
that our plot will emulate a statistical distribution that has been
Analyzing Schedule Risk 157
identified and used in the past. If we can find a distribution in
the statistics books that is close to what we plotted, we can use
the two magic formulas of the mean and the standard deviation
to “normalize” our data. We can then use the normal curve and
the analytical assumptions made by Carl Friedrich Gauss, an
early 19th-century German mathematician, to determine many
things that will help us make decisions.
The way a normal distribution works is that it has the mean
as the center point and it forms a bell with curves on each side
of the center point mean, the width of which is determined by
the standard deviation. According to Gauss, 68 percent of the
data collected in the statistical analysis falls within one standard
deviation of the mean. Since our network schedule is expressed
in time, another way of stating what Gauss assumed is to say
that 68 percent of the time our completion date will be within
one standard deviation of the mean time.
An illustration will help explain this concept better. Figure 9-1
depicts a standard deviation range.
A large standard deviation will give us a wide range of time,
whereas a small standard deviation will give us a smaller range
of time. As a result, the standard deviation’s size can be used to
compare the degree of risk that one work package has to another. In other words, having a 68 percent chance of getting a work
package completed sometime within 10 days of our calculated
mean time shows us a far riskier situation than if we have a 68
percent chance of getting the work package completed within
one day of our calculated mean time. Our confidence in the
work being completed on time in the former example is much
lower than in the latter example.
The normal curve’s shape also changes depending on the size
of the standard deviation, as shown in Figure 9-2.
Gauss also determined the amount of data under the normal
curve based on multiples of the standard deviation. According to Gauss, a little more than 95 percent of the data collected
Figure 9‑1. Normal Distribution Curve with One Standard Deviation Range
158 Integrated Cost and Schedule Control
Analyzing Schedule Risk 159
Figure 9‑2. Narrower Normal Distribution Curve
would fall within the range (in our case, the range of time) encompassed by two times the standard deviation on either side
of the center point mean. A little more than 99 percent of the
data collected would fall within the range (in our case, the range
of time) encompassed by three times the standard deviation on
either side of the center point mean.
Figure 9-3 shows the second and third standard deviation
range around the mean.
The developers of the PERT analysis process determined that
using the statistical sum theory of statistics on the work packages that made up the critical path would yield a mean and a
standard deviation of the duration of the project. Then, by using the Gaussian curve, they could determine the probability of
Figure 9‑3. Normal Distribution Curve with Two and Three Standard Deviation Ranges
160 Integrated Cost and Schedule Control
Analyzing Schedule Risk 161
completing the project by a particular date. These developers of
PERT used the following formulas:
Mean project = ∑ Means
Std.Dev.
project
=
Critical Work Packages
∑ ( Std.Dev.
Critical Work Packages
)
2
Let’s try this with a simple example. Let’s assume that our
critical path has five work packages and that our data look like
the data in Table 9-1.
Table 9‑1. Sample Project Data for PERT Analysis
WPsOptimistic
Likely
Risks
Pessimistic (o+4ml+p)/6 (p-o)/6 ((p-o)/6)2
A
8.0
10.0
20.0
11.3
2.0
4.0
B
5.0
7.0
15.0
8.0
1.7
2.8
C
20.0
25.0
40.0
26.7
3.3
11.1
D
2.0
3.0
8.0
3.7
1.0
1.0
E
5.0
10.0
25.0
11.7
3.3
11.1
Project
55.0 Mean = 61.3
S((p-o)/6)2 = 30.0
SQRTS((p-o)/6)2 = 5.5
To illustrate how we calculated the data in the last three columns:
8 + 4(10) + 20
= 11.3
6
20 − 8
Task A Stand Dev =
=2
6
Task A Mean =
(Task A Stand Dev)2 = 2 * 2 = 4
For the project level:
Mean project = 11.3 + 8.0 + 26.7 + 3.7 + 11.7 = 61.3
Std.Dev.project = 4 + 2.8 + 11.1 + 1.0 + 11.1
Std.Dev.project = 30.0
Std.Dev.project = 5.5
162 Integrated Cost and Schedule Control
Our project mean is 61.3 (let’s use “days”) and our standard
deviation, which was found by taking the square root of the
sum of the squares of our five work package standard deviations, is 5.5 days. Figure 9-4 shows the normal curve using our
data (using “σ” as a symbol for standard deviation).
This does not complete our analysis because the ranges
Gauss provided can also be used to calculate the confidence, or
­probability-of-success, scale. To do this we need to recognize our
“x” axis (along the bottom) as a timescale and accept that there is
a time way to the left, say day 20, by which we pretty much have
a 0 percent chance of getting the five work packages completed,
and that there is a time to the right, say day 90, by which we have
very close to a 100 percent chance of completing the work.
The mean always has a 50 percent chance. That is, you can be
50 percent confident that the five work packages can be completed by the time of the mean or sooner. In our example, we
would have a 50 percent chance of completing our five work
packages by day 61.3 or sooner.
You may think that 50 percent is not very good, but remember
that we used the individual means of the work packages on the
critical path to calculate the project mean. They each have a 50
percent chance using their means, and 50 percent of the time
they’ll be late and 50 percent of the time they’ll be early, which
means that we should be able to hover around our baseline.
Now let’s calculate the rest of the probability scale. If, according to Gauss, 68 percent of my data is within one standard
deviation of my mean, that would be 34 percent (half) above
the mean and 34 percent below the mean. Thus, the chance of
completing my work by the day that falls one standard deviation above my mean date has an 84 percent confidence factor.
Using our example, I am 84 percent sure that I can complete
the five work packages by day 66.8 or sooner. Conversely, the
chance of completing my work by the day that falls one standard deviation below my mean date has a 16 percent confidence
Figure 9‑4. Normal Curve with Sample Data
Analyzing Schedule Risk 163
164 Integrated Cost and Schedule Control
factor. ­Using our example, I am only 16 percent sure that I can
complete the five work packages by day 55.8 or sooner.
For the second standard deviation range, remember that according to Gauss a little more than 95 percent of the data falls
in that range. Half of 95 percent would be 47.5 percent; the little
bit more takes it to 47.7 percent. Using our example, this would
give us a 97.7 percent confidence factor that we can complete the
five work packages by day 72.3 or sooner and only a 2.3 percent
confidence factor that we can complete the five work packages
by day 50.3 or sooner. Figure 9-5 shows the entire scale.
For our third standard deviation range, half of 99 percent is
49.5 percent, but the little bit more takes it to 49.8 percent. Using
our example, this gives us a 99.8 percent confidence of completing the five work packages by day 77.8 or sooner and only a 0.2
percent confidence of completing the five work packages by
day 44.8 or sooner.
The scariest part of all this analysis is that most of us use
only a single-point estimate—what we might consider the most
likely—in our project plans. If we look back at our table of data
(Table 9-1), the most likely end date of the project was day 55.
According to our probability-of-success scale, we only have a 15
percent confidence that we can complete the five work packages
by day 55 or sooner, which is not very confident, and there are
only five work packages on the critical path. What do you think
happens when you have more work packages on your critical
path? That’s right, the confidence of completing your plan,
based on single-point, most-likely estimates, declines.
Today most project managers plan their entire schedule on
one single-point estimate. These projects have a very slim
chance of completing exactly on time as displayed on their
original plan. However, there’s a famous quote in statistics that
the “probability never goes to zero” and there’s always a slim
chance. The prudent project manager would perform at least
this minimal amount (PERT) of risk analysis on the project to
Figure 9‑5. Normal Curve with Probability-of-Success Scale
Analyzing Schedule Risk 165
166 Integrated Cost and Schedule Control
challenge the team to adhere to the most likely schedule, but
would also produce a second schedule that has the contingency
built in (using the PERT mean) as the date for which the team
is really aiming. The really prudent project manager might take
the end date up one more standard deviation before giving the
customer a delivery date. This would mean that the delivery
date to the customer has an 84 percent chance of being met.
But who ever gets the chance to “give” the customer a due
date? Most customers wanted the deliverable yesterday. Keep
in mind that if the due date is sooner than the date calculated
using a statistical analysis (like PERT) as the mean date for
finishing all the work, then there is a huge risk to the overall
success of the project. That risk needs to be elevated to the appropriate decision-making authority.
Before you elevate this information, though, you might try
some of the compression techniques. If the individual work
packages each have a calculated mean duration, then the new
critical path developed after the network compressions will
calculate an end date that theoretically still has a 50 percent
chance. This, of course, usually means that additional resources
(or more efficient resources) must be assigned to the project.
Depending on the priority of the project, the decision-making
authority above you on your project can mitigate this risk by
providing the resources needed. The skill level of each additional resource needed, plus the timeframe of when they would
be needed, can be determined by identifying those resources
that are overutilized in your compressed schedule. If you can
obtain a clone of these resources during these timeframes, your
schedule has a 50 percent chance of succeeding.
If your decision-making authority does not provide the resources, then they must accept the risk. You can use the normal
curve to show the confidence factor for getting all the work completed on time without the proper amount of resources. Using
our example, let’s say your project sponsor says that the project
Analyzing Schedule Risk 167
must be completed by day 50 and that they cannot provide you
any other resources; you can show them how the probability of
completing the work by that date is 2 percent. Although this is
not 0 percent, there is clearly a high risk that the project will not
be successful. Moreover, if the project team gets wind of this,
they will likely assume defeat, thus sealing the project’s fate of
not being successful.
Try using PERT in Exercise 9-A.
8.0
14.0
3.0
12.0
3.0
20.0
6.0
4.0
15.0
A
B
C
D
E
F
G
H
I
Project
Optimistic
Tasks
10.0
16.0
5.0
15.0
4.0
25.0
8.0
5.0
17.0
Most
Likely
Mean =
20.0
28.0
10.0
25.0
8.0
40.0
20.0
10.0
25.0
Pessimistic
(o+4ml+p)/6
Square Root of S([p–o]/6)2
S([p–o]/6)2 =
(p–o)/6
=
([p–o]/6)2
Assuming that all the tasks in the chart below are scheduled serially (i.e., they make up one path
and it is the critical path of the project), determine the PERT mean, standard deviation, and ranges for
the project.
Exercise 9‑A
PERT
168 Integrated Cost and Schedule Control
Analyzing Schedule Risk 169
115.2
Mean =
105.0
Project
11.3
17.7
5.5
16.2
4.5
26.7
9.7
5.7
18.0
20.0
28.0
10.0
25.0
8.0
40.0
20.0
10.0
25.0
10.0
16.0
5.0
15.0
4.0
25.0
8.0
5.0
17.0
8.0
14.0
3.0
12.0
3.0
20.0
6.0
4.0
15.0
(o+4ml+p)/6
A
B
C
D
E
F
G
H
I
Pessimistic
Most
Likely
Optimistic
Tasks
Merge Bias
Solution for Exercise 9-A
PERT
=
6.0
36.5
S([p–o]/6)2 =
Square Root of S([p–o]/6)2
4.0
5.4
1.4
4.7
0.7
11.1
5.4
1.0
2.8
([p–o]/6)2
2.0
2.3
1.2
2.2
0.8
3.3
2.3
1.0
1.7
(p–o)/6
170 Integrated Cost and Schedule Control
Analyzing Schedule Risk 171
172 Integrated Cost and Schedule Control
Merge Bias
One of the big drawbacks of using PERT to analyze the probability of success of the project schedule is that the analysis
method can be performed only on a single path of the project.
The summation rule of statistics states that the data being analyzed must be “mutually exclusive,” which means that no other
data can have an impact on the probability of the event you
are analyzing. In the case of schedule risk analysis of just one
path, as with PERT, this would mean that no other path of work
packages can merge with the critical path that is being used in
the analysis.
The inventors of PERT ignored this clause, I assume with
the caveat that this would be “good enough for government
work …. ” They essentially isolated the longest path, gave it the
name “the critical path,” and performed the analysis as if the
work on the other paths, because of the float, could not impact
the duration.
Rarely does a well-developed project network schedule consist of only one path of work. The PERT analysis can calculate
the individual probability of any number of work package
paths; however, at any point where two or more paths merge, a
statistical sum occurs. The formula for a statistical sum is:
P (A + B ) = P (A )* P (B )
In other words, if the probability of path A being accomplished by a particular date is 50 percent and the probability
of path B being accomplished by that same date is 85 percent
(which assumes float equivalent to one standard deviation) and
these paths merge on that same expected date, then the probability of both of them reaching that expected date together is
42.5 percent (.5 * .85 = .425). If a third path merges in with a
97 percent chance of accomplishing the work by that date, the
merged probability of having all three paths of work accomplished by the date would go even lower, to 41.2 percent (.5 *
.85 * .97 = .412).
Analyzing Schedule Risk 173
Commonly known as “merge bias,” this is why so many of
the risk management experts warn that PERT analysis is not
a valid method of schedule risk analysis. However, if you are
doing nothing in the area of risk analysis on your network
schedule, and are developing your schedule using just one most
likely estimate of duration, then you are more or less “shooting
yourself in the foot” as it is. Performing a risk analysis on your
critical path is a step in the right direction toward developing a
plan that has a chance of success. A better method would be to
use a simulation.
Monte Carlo Simulation
Another, more complete, method of determining the probability of success of the project schedule is to simulate multiple
possible scenarios of the schedule. Monte Carlo simulation
was named after Monte Carlo, Monaco, where the primary attractions are casinos containing games of chance. The random
behavior in games of chance is similar to how Monte Carlo
simulation selects variable values at random to imitate a reallife situation.
This type of simulation is very useful in schedule risk analysis
by randomly selecting the duration of the individual work packages in the network schedule. To provide a range for the simulation to randomly select from, the user must provide optimistic,
most likely, and pessimistic durations, just like with the PERT
analysis, plus an expected distribution. The expected statistical
distribution of most project work packages is the “beta distribution,” which is similar to the normal curve. Instead of being
evenly distributed on either side of the mean, however, the beta
distribution is a skewed curve that has more distribution to the
right than to the left. This is more true to project tasking because
when things go well in a work package the duration will be a
bit earlier, whereas when things go wrong, the duration of the
work package tends to be impacted to a greater extent.
174 Integrated Cost and Schedule Control
A number of Monte Carlo simulation software tools are available for project management. They all accomplish the analysis
in the same or very similar ways. Once the three estimates—optimistic, most likely, and pessimistic—are entered in the simulation tool and the distribution is selected, the Monte Carlo simulation software performs a user-prescribed number of trials.
For each trial, the software tool randomly selects a duration
that falls in the range, using the distribution, for each work
package of the network schedule. The software tool then records the calculated end date of the project for each of the trials
and provides the tabulated end dates of the range of time that
the project can be accomplished with a 5 percent confidence, a
10 percent confidence, etc., stepping up every 5 percent to the
date that has a 100 percent confidence. An example of the output of this type of analysis is displayed in Figure 9-6.
Figure 9‑6. Sample Output of Monte Carlo Simulation
As can be seen in Figure 9-6, the outcome dates equate to the
confidence level that the analysis of the simulation produced. If
the dates with a fairly attainable confidence level (i.e., at least
50 percent) are beyond the expected due date of the project,
then the network schedule must be compressed, which usually
requires more resources. This must be presented to the sponsor
of the project as a major project risk. The sponsor can choose
Analyzing Schedule Risk 175
to mitigate the risk by providing the required resources, all of
which should have been identified (number, skill level, etc.) by
the project manager and team during the compression process.
If the project sponsor does not provide the resources to mitigate
at least some of the risk, then the project sponsor is choosing
to accept the risk. All this should be documented in the project
risk register.
As noted, most risk management experts prefer the Monte
Carlo method over PERT. The big advantage is that the Monte
Carlo simulation of randomly generating duration estimates is
performed on all the work packages of the schedule, not just the
critical path.
If analyzing the risk and elevating the confidence of completing the work packages of the schedule on time still has not
generated a plan that has enough success built in, one other
technique can be tried. That technique is to readdress the scope
as structured by the deliverable-oriented WBS and possibly
determine a usable amount of scope that has a higher chance
of success.
11Establishing
a Performance
Measurement
Baseline
The project is now “baselined.” This means that:
• The scope of the deliverable is locked in.
• Any new requirements will be considered a change.
• The scheduled start and finish dates of each work package
of the project plan are locked in.
• The agreed-upon cost of each work package is allocated as
a budget to that work package.
The step of allocating cost to the work package turns each
final, agreed-upon estimate of both the effort and the cost to
pay for that effort, plus any other expenses, into a budget for
that work package for analysis purposes. This budget can be expressed either as effort or as money. The analysis techniques for
identifying issues in the execution of the project can be applied
the same way on either type of data; however, since the business world is a world of dollars and cents, the common method
of performing this analysis, called earned value analysis, is in
terms of money.
The baseline is made up of all three components of the triple
constraint—scope, budget, and time—and is presented as a
graphed line of how the effort or money for the baselined scope
is planned to be spent over time.
188 Integrated Cost and Schedule Control
Figure 11-1 shows a simple schedule of work packages that
have their own budgets. Figure 11-2 shows how this information can be displayed on a graph.
Figure 11‑1. Balanced Project Schedule Ready to Be Baselined
Total Project Budget = $52,000
Delivery Date = Day 25
Figure 11‑2. Performance Measurement Baseline
Establishing a Performance Measurement Baseline 189
Budget at Completion
As can been seen in our example, the performance measurement baseline (PMB) is an accumulation of the individual budgets of each work package over time. The final data point on the
PMB chart is the cumulative sum of the budgets of all the work
packages in the project. This represents the amount of money
or effort we plan to spend at the completion of all the work
packages. This data point is called the “budget at completion”
(BAC).
The BAC should always be less than the overall budget for
the project or incremental phase. The prudent project manager recognizes that problems can occur with any of the work
packages, no matter how well risks were identified during the
estimation process. Some budget (and also some time) is usually set aside for these unknowns. This is often referred to as
“management reserve,” because the project manager can only
“tap” into this reserve with the approval and full disclosure of
the stakeholders.
Management reserve allows for a tolerance control area to be
established around the PMB. On many projects the tolerances
of this threshold are established at plus or minus 10 percent,
which means that approximately 10 percent of the overall budget of the project, or incremental phase, should be set aside as
management reserve. For a schedule management reserve, we
can use one standard deviation’s worth of time (as described
in Chapter 9). Earned value analysis provides the indicators
that let the project manager know where the project status falls
within this threshold.
Note in Figure 11-2 that the budget for the project is $52,000
and the deliverable is due on day 25. This difference of $5,000
from the BAC of $47,000, and one day between day 24 and day
25, is the management reserve.
190 Integrated Cost and Schedule Control
Displaying the Baseline on the Network
Schedule
Another very important presentation of the baseline that can
be used to help the project manager control the execution of the
project is the time-scaled network schedule, often referred to as
the Gantt view of the schedule. At the moment the baseline is
set, a snapshot of the schedule is locked in. This snapshot of the
baselined schedule can be presented to the project team so they
know what each of them needs to do on the project and when.
Each team member can have his or her own individual schedule of the work for which they are responsible. This allows the
individual team members, especially the ones who are working
on multiple projects, to plan their time effectively.
Most project management software tools will show a gray
bar representing the baselined duration of each work package.
As the project work packages are being executed, the software
tool will show either a blue bar, for a noncritical work package,
or a red bar, for a critical work package, showing the schedule
changes according to the reality of the progress of the work being accomplished.
Figure 11-3 shows how a project management software tool
(in this case MS Project) displays a time-scaled view of both the
baselined and the working schedule. Figure 11-4 shows that
same time-scaled view where the project has had a late start.
Notice how the gray bars have not changed, because they represent the schedule at the time of the baseline. As we will see in
Chapter 14, this tool will be very useful in helping the project
manager direct the work packages back to the baseline and
within control.
Establishing a Performance Measurement Baseline 191
Figure 11‑3. Schedule Showing Gray Bars for Baseline
Figure 11‑4. Schedule Showing Comparison of Working Bars to
Baselined Bars
192 Integrated Cost and Schedule Control
Changing the Baseline
One of the primary steps in controlling the cost and schedule
during execution of the project, or incremental phase, is to establish a certain discipline on the project baseline (i.e., the baseline never changes unless a formal change management process
has taken place). This does not mean that the work packages
of the baselined scope cannot be replanned and rescheduled;
however, many circumstances that cannot be controlled by any
project manager can cause the project to be out of control. If the
reality of the cost or schedule status of the project happens to
be out of the control area of the baseline, then it is not this reality that is incorrect. The original plan that is represented by the
baseline is incorrect and therefore may need to be changed.
Too often this situation of reality not being exactly as we
planned is considered a reason for reprimand of the project
manager and the project team. The project manager and the
team are made to think they did something wrong, when in
truth they just might not have been psychic enough when they
estimated the parameters of cost and time to know how productivity and availability of resources would change over time during the execution process. Just like the pilot who can continually
monitor the productivity of how the fuel of the airplane is being
consumed and the availability of the fuel in the tank, he or she
cannot always be sure that there will be enough for the flight
because circumstances (such as weather) can cause the flight
to get out of control. The baseline and the subsequent analysis
will allow the project manager to continually monitor the effort
and cost consumption of resources; however, that consumption
may be quite different from what the project manager estimated
prior to the execution process.
All estimates involve risk. While those who approved the
plan were no better at predicting the future than were the project manager and the team, by the act of approval they accepted
the risk of the estimates and should be held as accountable for
their lack of psychic powers.
Establishing a Performance Measurement Baseline 193
Both good and bad things happen on all projects. The real
technique of controlling the project is to set a threshold on both
sides of the baseline that will not only help direct future work,
but will also help determine whether or not the baseline serves
as a good guidance system. This threshold provides a “control
space” that enables the project manager and the project team
to “maneuver” in performing various corrective actions on
issues, such as performing schedule compression techniques
(discussed in Chapter 8). If the cost and schedule status falls
outside the threshold and, no matter what the project manager
and project team try to do to resolve the issues identified, it is
determined that the status will remain outside the threshold,
then the change management process should be initiated and
a change to the baseline (which is no longer guiding project
execution) should be considered.
A number of circumstances can take the project cost or schedule outside the threshold in a flash. Here are just a few:
• Change of requirements
• Loss of a key team member
• Major environmental issue (e.g., fire, flood, hurricane)
• Technological redirection.
A baseline change should not be considered a trivial matter.
When any of these situations occur, a change management process should be enacted immediately because the decisions on
how to proceed must be made at a higher level of authority than
the project manager. These situations are no longer project decisions but are corporate or organizational decisions that should
be made at the level of management that approved the project
plan when it was baselined.
The other situation that requires the change management
process occurs when the project status no longer hovers around
194 Integrated Cost and Schedule Control
the project baseline because the project manager is just not able
to control the team’s day-to-day actions. The project manager
has to make the hard decision of when to go to a higher level
of authority, such as his or her manager or project sponsor, for
help in setting priorities or providing support. This is a very
difficult thing for most project managers to do because no one
wants to be the bearer of bad news, but the longer the situation
continues, the worse it will get. I can’t tell you how often I’ve
seen project teams that really believe that “divine intervention”
will prevail and save the situation. The organization that recognizes that the timely identification of bad situations is part
of the controlling process and encourages project managers to
elevate bad news in a timely manner is the one that will enjoy
the benefits of project success.
The change management process should incorporate the following types of activities:
• An agreement by both the customer and the project team
on the level of change management control required on the
project based on size, importance, complexity, etc.
• A form documenting that the change management process
needs to be enacted (e.g., a change request form)
• A group, made up of the project manager and select team
members, to investigate the impact of the change on the
project scope, budget, and/or schedule
• A governing group of individuals that make the corporate
or organizational decisions on how to proceed with the
change based on its expected impact
• An agreed amount of budget and time to replan the rest of
the project for all approved changes
• A rebaselining of the approved replan.
Establishing a Performance Measurement Baseline 195
Without the discipline of a solid baseline—one that can be
changed only through a controlled process—controlling the
cost and schedule of any large, complex project is extremely
difficult. The baseline is the guidance system that makes the
integrated process of cost and schedule control work.
13
Collecting
Cost and
Schedule
Performance
Metrics
Regularly determining the status of the project is an integral
part of the job of managing and controlling its cost and schedule performance. The best project managers recognize that the
status report meeting not only gives each team member the
opportunity to discuss what they have accomplished or are
having difficulties with, but to share in the celebration of accomplishments and to help resolve the difficulties of the other
team members. This helps bind the individual team members
together as a team by allowing everyone to get involved with
the project as a whole.
Status should be reported using the five integrated project
management processes:
• Initiation process. If any parts of the overall deliverable were
not decomposed before this time, the status should report
whether or not sufficient information is now available to
decompose the deliverable parts to work packages or if
they should continue to be deferred as planning packages.
Any newly discovered requirements that are identified
during the decomposition of the newly identified parts
must be analyzed to decide whether or not they still fit in
the scope or should be considered out of scope.
An example of this would be my house (discussed in Chapter 2) and the fact that I did not want to design the details
of my kitchen until the frame of the kitchen area was complete. After I could go into the space of my kitchen, I was
able to visualize and break down the various possible parts
208 Integrated Cost and Schedule Control
of the kitchen. I could then decide, based on the baselined
planning package budget I had set aside for the kitchen,
what would go where and what I could do without at this
time.
• Planning process. Once any new, in-scope requirements are
decomposed and their work packages are identified, the
work must be planned using all the planning process tools
and techniques (introduced in Part 3) and incorporated
into the master plan of the project.
• Execution process. Any newly planned work packages must
be approved and individually baselined within the master
plan before work on these work packages can commence.
Data on the cost and schedule status of each work package
where the work was being executed, both those that have
started and those that have been completed, since the last
reporting period should be collected.
• Controlling process. This process involves analyzing the
cost and schedule data collected, identifying issues, and
discussing any issues with the team to determine whether
corrective action (discussed in Chapters 13 and 14) should
take place.
• Closing process. The closing process involves capturing
lessons learned and determining whether any part of the
project deliverable has been completed so that the success
of completing that part can be celebrated and properly
documented.
The outcome of all these steps should be documented in a
regular project status report, noting any action items that are
assigned to individual team members. This report should be
distributed to each team member for review and acceptance. It
can also be used as part of a more formal report to each stakeholder on the status of the project.
Collecting Cost and Schedule Performance Metrics 209
Planned Value
The baseline sets up a guidance system for the project. Just
like a flight plan serves as a guidance system for the pilot of
an airplane, the baseline aids in directing the project execution
to the ultimate goal of accomplishing all the work involved in
building the deliverable on time and within budget. Just as for
the pilot, the idea is not to be precisely on the baseline, but to be
able to hover around the baseline. To do this, we need to know
where the baseline is. The data point on the baseline serves
as one of the primary earned value analysis data points used
in analyzing the schedule status of the project or incremental
phase of the project.
The planned value (PV), also known as the budgeted cost of
work scheduled (BCWS),1 is the point on the baseline where the
line representing the date that status will be reported intersects
the baseline. This line is often referred to as a data date or status
date. The PV (BCWS) represents the portion of the budget we
expected to spend as of the status date if all work is accomplished exactly as we planned. Figure 13-1 shows how the PV
is determined for day 10 using our previous baseline example.
Task A is planned to be completed by day 10, so all of Task
A’s budget will be in the PV. Task B is planned to be 50 percent
complete by day 10, so 50 percent of Task B’s budget will be in
the PV. Task C is planned to be completed by day 10, so all of
Task C’s budget will be in the PV. Finally, Task D is planned to
have four days of its nine-day duration completed by day 10, so
4/9 of Task D’s budget will be in the PV. Table 13-1 shows the
PV for this project as of day 10.
1
This change in terms and acronyms occurred early in 2002 under
the direction of PMI’s College of Performance Management, www.
cpm-pmi.org.
210 Integrated Cost and Schedule Control
Figure 13‑1. Baseline Schedule Showing Status Date
TaskTotal Task Budget
A
B
C
D
Project
$6,000.00
$8,000.00
$4,000.00
$9,000.00
$47,000.00
Planned Value (PV)
As of Day 10
$6,000.00
$4,000.00
$4,000.00
$4,000.00
$18,000.00
Table 13‑1. Sample Calculation of Planned Value as of Day 10
The project PV can also be displayed using the PMB, as
shown in Figure 13-2.
As the project progresses over time, the PV continually increases along the PMB over time. Figure 13-3 displays day 15
on the schedule. As can be seen, Tasks A, B, C, and D are all
planned to be completed as of day 15. Task E is planned to have
one of its seven days duration completed by day 15. Table 13-2
displays the PV for this example project as of day 15 and Figure
13-4 displays the PV on the PMB.
Collecting Cost and Schedule Performance Metrics 211
Figure 13‑2. PMB with Planned Value as of Day 10 Displayed
Figure 13‑3. Baseline Schedule with Day 15 as Status Date
212 Integrated Cost and Schedule Control
TaskTotal Task Budget
A
B
C
D
E
Project
$6,000.00
$8,000.00
$4,000.00
$9,000.00
$7,000.00
$47,000.00
Planned Value (PV)
As of Day 15
$6,000.00
$8,000.00
$4,000.00
$9,000.00
$1,000.00
$28,000.00
Table 13‑2. Sample Calculation of Planned Value as of Day 15
Figure 13‑4. Planned Value Displayed Using PMB as of Day 15
Actual Cost
The only way that actual progress can be shown on the project schedule is to know whether or not each work package has
had an actual start and/or an actual finish. The project management software tools expect the project manager (or someone on
the project team) to be entering this information into the tool in
order for it to be able to display actual progress on the schedule.
Collecting Cost and Schedule Performance Metrics 213
To collect the data required to analyze the status of the project’s
budget, we need additional mechanisms that collect information on actual effort expended and the expenses of each work
package. Ideally, this mechanism will also collect estimated
remaining effort and expenses needed to complete the work
package. The best mechanisms for collecting actual information
are timesheets, expense reports, and invoices.
The use of timesheets (see Figure 13-5 for a sample) can be a
foreign concept to team members who have never been asked
to do this before. It often amazes me how many organizations
claim to have control over their projects but have never instilled
the discipline of completing timesheets.
Having the actual information of what has been spent on the
project so far is critical for cost control. A pilot needs to continually monitor the fuel consumption of the airplane. If they do not
have a gauge that provides this information, they can easily run
out of fuel while the airplane is still in the air.
The project that runs out of budget before it is complete will
have severe consequences also (although certainly not as disastrous). If the project is canceled because it has run out of funds,
all the money that has been spent on the project so far has effectively been “poured down the drain.”
Collecting actual information about what we do during our
workday has a far more positive impact than negative. Importantly, it allows the team members to show the amount of
multitasking they are expected to accomplish in an eight-hour
day. In today’s world, team members are expected to work on
a multitude of tasks (some that were in the original schedule
and others that were not) all at the same time. We tend to pride
ourselves on being able to juggle a number of “balls in the air”
at the same time.
Figure 13‑5. Sample Timesheet
214 Integrated Cost and Schedule Control
Collecting Cost and Schedule Performance Metrics 215
The biggest problem with being overwhelmed with work is
that it may erode our basic concept of success. We may begin to
think we can’t do it all, and once that notion of failure seeps into
our minds, our productivity declines, perpetuating the failure.
Some of us can pull it all together and fight the “failure” feeling,
but that fight affects our mental and physical states, which over
time will cause many stress-related ailments.
By being able to document the various tasks we perform in our
workday, we can show how much we have accomplished and we
can use the information to make sure we are not assigned more
than we can accomplish. Having a record of what we accomplish
can also add to our feeling of success on the project.
Actual cost (AC) (also known as the actual cost of work performed, or ACWP) is the second data point required to be able
to perform earned value analysis to help control the cost status
of the work packages during the execution process. AC usually
involves collecting not only the cost of doing the actual work
reported on the timesheets, but also expense reports, invoices,
etc., which provide information on the direct costs incurred on
the project.
Unfortunately, much of the information collected on the
actual costs of the project is often not shared with the project
manager. This should not be an excuse, however, for not trying
to manage the budget. The earned value data can be analyzed
using only the effort hours of the work package. The PV can be
collected in terms of effort hours planned and the AC can be
collected from the timesheets alone. This still requires that all
team members enter their time, by activity or work package, on
a timesheet.
Earned Value
The third data point for earned value analysis is the earned
value (EV) (also known as the budgeted cost of work per-
216 Integrated Cost and Schedule Control
formed, or BCWP). EV provides us data, expressed as money or
as effort hours, on what has been accomplished on each work
package. EV should not consider what was planned to be accomplished on the work package, but instead it should focus
on whatever mechanism was identified to measure the work of
the work package when the work package was first identified
on the WBS. (Remember SMART, introduced in Chapter 4?) Nor
should EV consider how much money or effort has been spent
on the work package. It is based purely on how much of the
deliverable of the work package has truly been completed. This
is the only data point that needs to be calculated.
The basic formula for calculating earned value is:
EV = % Complete work package * Budget work package
The various methods available to calculate EV are nothing more than different methods of determining the percent
complete of a work package. The following are some standard
methods:
• Actual effort expended on the work package divided by
the sum of the actual effort expended on the work package
plus the estimated remaining effort needed to complete the
work package.
• The physical percent complete of the deliverable the work
package is to produce. An example is the number of pages
of a book completed and how many more you are expecting to write, or the number of lines of software code written and how many more you estimate will be needed to
provide the functionality.
• A further breakdown of the work package into measurable
milestones (sometimes called inch-stones) with a predetermined weighting factor on each milestone.
Collecting Cost and Schedule Performance Metrics 217
• The 0/100 rule, which does not allow the work package to
earn any of the budget until it is 100 percent complete.
• The 20/80 rule, which allows the work package to earn 20
percent of the budget at the time it has an actual start and
the other 80 percent at the time it is 100 percent complete.
• The 50/50 rule, which allows the work package to earn 50
percent of the budget at the time it has an actual start and
the other 50 percent at the time it is 100 percent complete.
Each of these methods has its advantages and disadvantages;
the two that give the most realistic data of EV for a work package
are the physical percent complete and the further breakdown of
the work package to predetermined measurable milestones.
Figure 13-6 demonstrates how earned value is calculated on
our example PMB, as of day 10, using the three different “rule”
methods. Figure 13-7 shows the calculation of earned value
using either (1) a physical percent complete measurement or
(2) where the further breakdown of the work packages into milestones with measurement criteria designated to each has been
used to determine the percent complete of the work package.
Calculating Earned Value for Level of
Effort
Level of effort work packages are those in which the effort
expended does not produce a deliverable, but is needed for
general support-type services, such as project management in
general or quality audits. We would like to think that any time
we expend effort we are producing something, but there are
times, especially when working on those oversight tasks that
every project requires, that our efforts do not produce tangible
deliverables.
$16,500
No
Yes
No
Yes
Actual
Finish
$10,000
$0
$4,000
$0
$6,000
0/100%
Rule
Figure 13‑6. Calculating Earned Value Using Rule Method
$18,000
$47,000
Project
Yes
$2,000
Yes
:
$4,000
$3,800
Yes
$9,000
Work Package D
$4,000
$4,200
Yes
Actual
Start
:
$4,000
Work Package C
$4,000
$6,500
ACWP
$8,000
Work Package B
$6,000
BCWS
:
$6,000
Work Package A
Task
Budget
$13,400
$1,800
$4,000
$1,600
$6,000
20/80%
Rule
$18,500
$4,500
$4,000
$4,000
$6,000
50/50%
Rule
218 Integrated Cost and Schedule Control
$8,000
$4,000
$9,000
$47,000
Work Package B
Work Package C
Work Package D
Project
$18,000
$4,000
$4,000
$4,000
$6,000
BCWS
$16,500
$2,000
$3,800
$4,200
$6,500
ACWP
$9,000
$4,000
$8,000
$6,000
Budget
20%
100%
60%
100%
% Complete
Figure 13‑7. Calculating Earned Value Using Measurable Percent Complete
$6,000
Work Package A
Task
Budget
$16,600
$1,800
$4,000
$4,800
$6,000
BCWP
Collecting Cost and Schedule Performance Metrics 219
220 Integrated Cost and Schedule Control
The earned value of these types of work packages cannot be
calculated because there is no discrete means of measuring the
work. Therefore, the EV is set equal to the PV for these types of
work packages. The prudent project manager will plan to use
level of effort (LOE) work packages only where discrete deliverables cannot be defined.
Determining Project Status Data Using
Only Effort Hours
If you do not have information about the costs of the project,
you can still determine the PV and the AC, and then calculate
the EV. As long as you have the effort budgeted for the work
package, you have enough information to use one of the methods for calculating earned value to help control the cost and
schedule of the project.
For example, if I have budgeted 80 hours of effort for a work
package and the data date falls halfway through that work
package, then my PV is 40 hours. If I have a method of measuring the percent complete (any of the rule methods or a true
measurement), I can calculate an EV. For example, if I have
determined that the work package is 60 percent complete, then
the EV calculates to 48 hours earned. If I can determine the actual hours spent on the work package (AC), then I can perform
earned value analysis using this data. Even if I can’t get the actual hour information, performing the analysis on my schedule,
based on the PV and the EV, will yield information that will be
very useful in managing the project.
EARNED SCHEDULE
Because so many people have a difficult time accepting schedule analysis in terms of units of money, a new measurement
technique was developed to calculate earned value in terms
of time. Similar to the calculation previously introduced, the
Collecting Cost and Schedule Performance Metrics 221
earned schedule (EVt) is calculated by multiplying the percent
completed by the baselined duration of the work package.
As an example, if I have a work package that was baselined
to be completed in 20 days and my data date is at the end of
day 10, my planned schedule (PVt) in time units is 10 days. If I
determine, through whatever earned value method I am using,
that we are 60 percent complete with the work package, then I
have earned 12 days.
As you will see in the next chapter, this measurement can be
used to analyze performance on the schedule in terms of time.
This becomes very useful at the end of a project that is overrunning the schedule because it gives you another perspective for
determining how much time will elapse before the project is
completed.
14
Performing
Earned Value
Analysis
To perform earned value analysis, we need to have collected
PV, AC, and EV, plus BAC. The PV, AC, and EV data can be
collected and analyzed for both the current-period reporting
data and the cumulative data from the beginning of the project.
(Figure 14-1 shows the cumulative data graphed on the PMB.)
Earned value analysis falls into two major categories:
• Analysis that measures the performance of the project as of
a data date
• Analysis that forecasts what might happen on the project
in the future if things do not change.
Using Earned Value Analysis to Analyze
Cost and Schedule Performance
Three different types of analysis are performed to measure
performance:
• Variance
• Performance index
• Project percentage.
Figure 14‑1. Earned Value Data
224 Integrated Cost and Schedule Control
Performing Earned Value Analysis 225
Variance Analysis
Variances are simple calculations that tell us whether the
project is ahead or behind schedule by calculating the schedule
variance (SV) and whether the project is showing signs of going
over or under budget by calculating the cost variance (CV). The
formulas for these two variance indicators are:
SV = EV − PV
CV = EV − AC
In both calculations a positive or negative result equates to
the status shown in Table 14-1.
Table 14‑1. Variance Status Results
PositiveNegative
SV
CV
Ahead of schedule
Under budget
Behind schedule
Over budget
Figure 14-2 shows how the variances can be identified using
the PMB.
While variances are nice to know, they are not useful for comparing the performance of one project to another, nor can they
be used to isolate issues since they are not relative to the size of
what’s being analyzed. For example, a -$1,000 CV would have
a major impact on a $10,000 project, but only a minor impact
on a $100,000 project. To make this analysis technique more
meaningful, a further calculation for determining the SV and
CV percentages should be used. The formulas for these percentages are:
SV% =
SV PV
CV % =
CV
EV
CV
Figure 14-2. PMB Showing Earned Value Analysis Variances
SV
226 Integrated Cost and Schedule Control
Performing Earned Value Analysis 227
Each of these percentages can now be bounded with thresholds, such as plus or minus 10 percent, because they have now
made the variance data relative to the size of the project or subpart of the project.
Performance Index Analysis
To calculate a relative-to-size indicator without having to perform two steps, we can use the performance indexes.
The performance indexes calculate performance relative to
a unit, such as a dollar or an hour of effort. Here we calculate
the schedule performance index (SPI) to determine the performance for every dollar (or whatever unit of currency or effort is
being used in the analysis) scheduled to be spent according to
the baselined plan. The cost performance index (CPI) tells us the
performance for every dollar that has been spent at this time in
the project. The formula for these indexes are:
SPI =
CPI =
EV
PV
EV
AC
Let’s look at an example:
PV = $45,000
EV = $35,000
AC = $40,000
SV = –$10,000
CV = –$5,000
SPI = 0.78
CPI = 0.86
228 Integrated Cost and Schedule Control
The SV and the CV, both negative, tell us that the project is
behind schedule and over budget. The SPI tells us that for every
dollar we planned to spend on this project, we are getting 78
cents worth of performance. The CPI is telling us that for every
dollar we have spent so far on this project, we are getting 86
cents worth of performance. If our tolerance is plus or minus
10 percent, we would expect either performance indicator to be
between 0.90 and 1.10 to be in control. Since neither is within the
thresholds of our control area, we can say our project is out of
control in terms of both schedule and cost.
Let’s look at a similar example:
PV = $145,000
EV = $135,000
AC = $140,000
SV = –$10,000
CV = –$5,000
SPI = 0.93
CPI =0.96
The SV and the CV are exactly the same as in the previous
example and only tell us that the project is behind schedule and
over budget. The SPI tells us that for every dollar we planned
to spend on this project, we are getting 93 cents worth of performance. The CPI is telling us that for every dollar we have
spent so far on this project, we are getting 96 cents worth of
performance. With a tolerance of plus or minus 10 percent, both
are within the thresholds of our control area, so we can say this
project is in control in terms of both schedule and cost.
Performing Earned Value Analysis 229
Thus, the performance indicators are relative to the size of
the project and produce much more useful information than the
variances alone. Relevance-to-size indicators also lend themselves very well to being charted individually over time. Figure
14-3 shows the SPI, both current and cumulative, and Figure
14-4 shows the same for the CPI.
Figure 14‑3. SPI Chart
Figure 14‑4. CPI Chart
230 Integrated Cost and Schedule Control
Today many of us use what is sometimes called a “stoplight”
chart to show the status of the project. The color “green” is
used to show that the status of the project is excellent; the color
“yellow” is used to show that the project has some issues and
caution should be exercised; and the color “red” shows that
the project status is unsatisfactory. Too often these colors are
subjectively determined by the project manager based on only
a “gut feeling.”
The SPI and the CPI allow an objective tolerance range to be
established for these colors; for example, an indicator of ≥ .95
and ≤ 1.05 is green, ≥ .90 and < .95 or > 1.05 and ≤ 1.10 is yellow,
and < .90 or > 1.10 is red. Figures 14-5 and 14-6 show these color
bands on the SPI and CPI charts.
Figure 14‑5. SPI Chart with Stoplight Colors
In general, projects do not get “blown over by hurricanes
or tornadoes.” Instead, they get “eaten by termites.” In other
words, small issues that occur at the work package level tend
to compound if they are not identified and dealt with in time.
This is where our detailed deliverable-oriented work breakdown structure (WBS), developed during the project initiation
Performing Earned Value Analysis 231
Figure 14‑6. CPI Chart with Stoplight Colors
process, becomes so useful during the controlling process. A
WBS that is not decomposed to a level where all the real work
has been identified will not indicate that there are “termites”
until a “wall falls down.” A WBS that doesn’t have the right
­parent-child breakdown based on the deliverable can do nothing more than lump problems into what some call “rework.”
A deliverable-oriented parent-child WBS can keep all the
work involved in completing any part of the project together
with that part. It can isolate any issues to an individual part so
that the right decisions, based on the importance of the part and
the impact to the other parts of the project, can be made.
As an example, let’s use a low-level deliverable several levels down in the WBS. This can be any type of deliverable, but
for this example, let’s say it is a software function that is being
developed. The work packages are to design how this function
is to be coded, to code the function, and then to unit-test the
function. The module that this function is a child of has its own
design for how the various functional parts of the module must
work together during an integration test of the module.
232