Business Horizons (2013) 56, 643653

Available online at www.sciencedirect.com

www.elsevier.com/locate/bushor

Lies, damned lies, and project plans: Recurring

human errors that can ruin the project planning
process
Jeffrey K. Pinto

Black School of Business, Penn Statethe Behrend College, 282 Burke Building, Erie, PA 16563, U.S.A.

KEYWORDS Abstract Project-based work has become a critical component of global industrial
Project management; activity. Among other functions, projects are used to develop new products and
New product services, improve operations flows, implement innovative information technologies,
development; and conduct primary R&D. At the same time, project management is a core skill
Planning errors requirement for numerous corporations worldwide hoping to harness a means of
improving both the efficiency and effectiveness of their operations. Unfortunately,
the track record for project development has not been strong. Data suggest that
within various industrial components, such as IT, failure rates for projects are high;
even successful examples typically run well over budget and behind schedule. This
article addresses some of the reasons why projects and project management have
failed to live up to lofty expectations, arguing that the seeds of failure are often sown
from the outset through flawed project planning. Citing the more common errors in
human judgment and drawing on numerous examples, we offer guidelines by which
project planning can begin to work as it was intended: on behalf of the project rather
than at cross-purposes with the projects goals.
# 2013 Kelley School of Business, Indiana University. Published by Elsevier Inc. All
rights reserved.

1. Project development: Whats the A bloody mess: Britains health information

problem? network.
(Chin, 2006)
A rail project shut down by court order will
NASA fights to save James Webb telescope
cost Honolulu more than $114 million.
from the axe as costs soar to $6.5 billion.
(Rail Project Shutdown, 2012)
(McKie, 2011)

It seems, as the old expression goes, that the hits

just keep coming. Project-based work has become
E-mail address: jkp4@psu.edu a critical component of global industrial activity.

0007-6813/$ see front matter # 2013 Kelley School of Business, Indiana University. Published by Elsevier Inc. All rights reserved.
http://dx.doi.org/10.1016/j.bushor.2013.05.006
644
Projects are usedamong other functionsto de-
velop new products and services, improve opera-
tions flows, implement innovative information
technologies, and conduct primary research and
development (R&D). They are touted as the cure
for business malaise, to solve unemployment prob-
lems, to bring consumers the newest and fastest
electronic gadgets, to solve infrastructure prob-
lems; in short, to exert positive changes on the
world in which we live. Accordingly, project man-
agement is a core skill requirement for numerous
corporations worldwide. With an increasing interest
in and use of project management practices and
project-based work, organizations have hoped to
harness a means of improving both the efficiency
and effectiveness of their operations. This height-
ened interest in the use of project management is
reflected in the rapid growth of professional orga-
nizations. For example, the Project Management
Institute is the largest professional project manage-
ment organization in the world, with membership
approaching 500,000. An industrial climate ripe for
exploitation, coupled with a large professional cad-
re of trained project managers, would seem to
positively indicate the use of projects toward fur-
thering organizational goals.
Unfortunately, while project management techni-
ques continue to be increasingly employed in the
private and public sectors, the track record of suc-
cessfully implementing them in organizations has not
been strong. Data suggest that within various indus-
trial components, such as information technology (IT)
and infrastructure construction, failure rates for
projects are high; even successful examples typi-
cally run well over budget and behind schedule.
Consider the following supportive evidence:
 The META Group reports that more than half of
all [information technology] projects become
runawaysovershooting their budgets and time-
tables while failing to deliver fully on their goals
(Kapur, 1998).
 Joe Harley, then-Chief Information Officer (CIO)
at the Department for Work and Pensions for the
UK government, stated that only 30% of technology-
based projects and programs are a successat a
time when taxes are funding an annual budget of
14 billion (over $22 billion) on public sector IT,
equivalent to building 7,000 new primary schools
or 75 hospitals a year (Ritter, 2007).
 The Special Inspector General for Iraq Recon-
struction (SIGIR) reported that the Pentagon
spent about $600 million on more than 1,200 Iraqi
reconstruction projects that were eventually
J.K. Pinto
canceled, with 42% terminated due to misman-
agement or shoddy construction (Kelley, 2008).
The question must be asked: Why, given the height-
ened awareness of value in projects and the use of
projectmanagementtechniques,doestheactual track
record continue to be so mediocre? Phrased another
way: Why is it that interest in project management is
at an all-time high, professional project managers
are being developed within numerous corporations,
and project management training and educational
opportunities abound, yet numerous projects them-
selves are still consistently failing to deliver promised
value? While it is true that any number of external
events (e.g., withdrawal of funding support, changes
in strategic priorities midstream) can derail a proj-
ects progress once it is in motion, one commonality
of many project failures is that the seeds for poor
performance are sown quite early, often during the
initial planning phase. Failure, as I define it, pertains
not just to the discontinuation or cancellation of a
project. It also includes projects that failed to deliver
on critical specifications, were completed with sig-
nificant cost and time overruns, and provided poor
return on investment (ROI). We will see that it is
precisely during the early stages of the project life
cycleconceptualization and planningthat most
projects and project teams find themselves con-
demned to an unhappy fate: trying to salvage value
and profitability from a project assignment that
seems designed to fail.
What are the causes of this disconnect between
original goals and project plans? How do project
teams, managers, and executives continually mis-
manage projects from the outset, leading to serious
complications or outright failure downstream? Here-
in, we will explore seven deadly sins of project
planning: ways in which critical project stakehold-
ers err at the outset, with seriousand often fatal
negative consequences for the project. As the arti-
cle will demonstrate, many of these errors are the
result of often willful and systematic mistakes proj-
ect team members continuously make as they pre-
pare the plan. Errors of optimism bias, artificial plan
manipulation, poor change control, and inadequate
risk management are among the blunders that
plague our ability to execute viable project plans.
Next, we will analyze these errors in turn.
2. Seven deadly sins
I would rather tell seven lies than make one
explanation.
Mark Twain
Lies, damned lies, and project plans
2.1. Optimism bias
I frequently speak to project management groups and
ask them a tongue-in-cheek question: What do you
get when you let the sales staff negotiate critical
project parameters (e.g., delivery date, functionali-
ty, cost) with the customer? The responses are
consistently negative: A doomed project! Pre-
packaged failure! A looming disaster! These com-
ments reflect an experience shared by many project
teams when they are presented with a plan over
which they had no input, one that adopts the rosiest
of expectations for specifications, delivery sched-
ules, and costs. This state is extremely discouraging
for project team members, many of whom are expe-
rienced in working on projects and who quickly rec-
ognize when project parameters are completely
unachievable in relation to these preset expecta-
tions. What we are talking about here is the damage
that optimism bias can cause to a project plan.
Optimism bias refers to an individuals or orga-
nizations belief that they are less at risk than anyone
else for experiencing a negative consequence (Shep-
perd, Carroll, Grace, & Terry, 2002). They may feel
this way due to several reasons, including: their
desired end state, their cognitive mechanisms, the
information they have about themselves versus
others, and overall mood. The net result of optimism
bias is to routinely minimize or discount negative
information and identify with the most optimistic
estimates for project performance. This term is
sometimes also referred to as delusional optimism
and the planning fallacy. The result of optimism bias
is that stakeholders make highly positive assumptions
about a projects performance, even in the face of
historical evidence to the contrary. The FBIs notori-
ous Virtual Case File (VCF) project offers an example
of optimism bias. Originally started in 2000, the VCF
project was intended to automate the FBIs paper-
based work environment. The primary contractor
delivered such a bug-riddled and off-target product
that the project was scrapped in 2005 at the cost of
$170 million. Amazingly, convinced they had learned
the hard lessons from their first attempt, the FBIs
project, renamed Sentinel, was restarted and re-
budgeted for an additional $450 million. By late
2010, the project, having fired its primary contractor,
was so far behind schedule and over budget that the
U.S. Department of Justices Office of the Inspector
General issued a scathing report on its progress to
date. An independent assessment estimated that at
its current management progress, Sentinel will come
on line at least 6 years late and $351 million over
budget.
When we explore the planning fallacy in more
detail, we find several effects that directly impact
645
the ability to manage projects on-time, on-budget,
and to-specification. Buehler, Griffin, and Ross
(1994) offer some interesting implications when
applied to project scheduling, including:
 People tend to underestimate their own, but not
others, completion times. We call this optimis-
tic prediction bias. The direct implication is that
planners commonly underestimate how long ac-
tivities on a project are likely to take, using rosy
assumptions to set a project schedule.
 People focus on plan-based scenarios rather
than on relevant past experiences when generat-
ing estimates. This effect suggests an over-
dependence on projected expectations and im-
plies that project team members are prone to
adopt the assumptions generated in a newly-
developed project plan and discount relevant
past experiences, even if they are nearly identi-
cal to the current project being considered.
 Peoples attributions diminish the relevance of
past experiences. They are quick to dismiss poor
past project track records as being the product of
external or unstable causes. Somehow, it is as-
sumed that the past does not factor into current
estimates because previous problems were
caused by others and therefore cannot be seri-
ously considered for current assignments.
Our understanding of the causes and implications
of optimism bias in projects has been immensely
helped by the work of Bent Flyvbjerg and his col-
leagues. For over a decade, Flyvbjerg has examined
the causes of failures in project planning and con-
cluded that a large number of projects suffer from
the joint and combined effects of delusion and
deception on the part of the project organization
and its principal stakeholders. That is, delusion is
often the result of adopting an inside view of the
project: focusing only on the plan itself, the ob-
stacles that have to be overcome, the scenarios to
consider, and current trends to uncover. The inside
view is a bottom-up decision making process that
discounts the wealth of historical data, past expe-
riences, and environmental factors that are likely to
affect the project (Flyvbjerg, Garbulio, & Lovallo,
2009). This delusion is best represented through the
joint effects of the planning fallacy we have dis-
cussed above and the use of artificial estimating
techniques such as anchoring and adjustment.
Anchoring and adjustment is a second effect that
confounds our ability to develop accurate plans
through the use of artificial (and harmful) scheduling
heuristics. A great deal of research has demonstrated
646
Table 1. London Olympic cost estimates
Year Estimated Cost Source
2002 1.8 billion Arup
2003 3.14 billion PwC
2004 4.21 billion Candidate File
2007 9.3 billion NAO Estimate
2012 11+ billion Official Budget Estimate
that anchoring is a powerful bias when applied to
estimates because it acts as the original stake driven
into the ground, around which all future adjustments
must be made. In other words, the first estimate for a
project becomes the anchor and subsequent modifi-
cations are made in relation to this original, often
artificially-derived number. Even if the anchor is too
high or too low, modifications of it are incremental
and always linked to that first estimate. Thus, the
starting point for an estimate becomes a critical
limiter on our ability to make proper modifications
to the plan. For example, the recently-completed
Olympics in London developed an initial cost anchor of
1.8 billion despite Beijing 2008 costing 9.8 billion.
In fairness, the original anchoring for the London
games occurred well in advance of the final bill for
the Beijing Olympics coming due; however, there
was clear data showing that Barcelonas 1992 games
cost 8.06 billion. Thus, project planners for the
London games did have viable historical data on
which to develop their estimates, but chose instead
to adopt a much smaller number. The resulting
cost increases were relentless and predictable, as
Table 1 shows.
How would the results have been different
through more accurate anchoring? First, the original
baseline would have more closely approximated a
reasonable set of cost parameters, leading to better
knowledge of the real costs of the games. Second,
adjustments would have occurred for more prag-
matic reasons; that is, if the Olympic Committee
was forced to revise the budget upward, it would
have been due to well-understood external causes
(e.g., unexpected difficulties in building venues,
higher construction material costs) that would not
have had the same negative effects on public per-
ceptions of project management. In effect, estab-
lishing a reasonable anchor is an important
demonstration of the accuracy of initial estimates
and the care with which the project organization has
begun developing its plan.
2.2. Massaging the plan
The act of massaging a project plan usually refers
to ex post adjustments being made at the specific
J.K. Pinto
request or mandate of a senior executive. For ex-
ample, a project manager may perform a good faith
effort to produce a realistic and workable project
schedule only to be told by a senior manager: Its
too long. Shorten it! In fact, there may be several
iterations of this exchange until the project man-
ager, in frustration, simply asks for specific guid-
ance: Okay, then. How long do you want it to be?
This dynamic leads to a number of pathologies.
First, it implicitly suggests that the senior execu-
tive: (1) knows more about the project than the
actual project leader; (2) does not trust the plan as
prepared by the project manager; and/or (3) as-
sumes that the plan has been heavily padded with
extra slack time to take pressure off the project
team. Any of these reasons may prompt the exec-
utives directive but they all point to a similar
problem: the carefully prepared plan is discounted
and the project manager is sent back to the drawing
board to reconstruct it.
Besides simple desire to shrink the plan, other
motives may be at work. One oft-cited reason for
low-balling initial estimates is embedded in Flyvb-
jergs (2005) strategic misrepresentation princi-
ple: Decision-makers and politicians are well aware
that full disclosure estimates will frequently doom
projects even before they are started. In short,
there are often political motives for underestimat-
ing project costs and schedules. Bostons Central
Tunnel/Artery projectknown popularly as the
Big Digwas originally estimated at $2.54 billion
and ultimately cost nearly $15 billion. The question
has to be asked: Was this the result of poor initial
estimates, or were planners simply tuned to a de-
gree key stakeholders knew would be needed to get
the project approved?
It is instructive to consider a recently proposed
and highly controversial project in light of the ef-
fects of massaging project plans. Californias High-
Speed Rail project, initially designed to build a rail
link between Los Angeles and San Francisco, is
currently in the early planning phases. Official es-
timates have steadily been climbing. The first esti-
mate placed the rail system at $34 billion, with
an estimated completion date of 2018. In 2012,
a revised official estimate projected a cost of
$98 billion and completion date of 2033. Unofficial-
ly, experts have suggested a potential cost as high
as $218 billion when all is finished. At a time when
Californias overall state budget is in considerable
arrears, it is perhaps not surprising that estimates
for the project have been adjusted and readjusted
to make them politically palatable.
There are two important implications that result
from top managements desire to massage the plan.
The first is that projects that have been honestly
Lies, damned lies, and project plans
estimated are likely to closely follow the original
schedule, regardless of how much it was com-
pressed after the fact. In other words, we see
example after example of projects coming in near
their original deadline, but now they are considered
late. The lesson here is obvious: Absent some ma-
terial help from top management, the message to
shrink the plan will not materially change final
project delivery. The second implication of massag-
ing the plan is behavioral and highly predictable.
Project teams and their leaders are quick to grasp
the difficulties that emerge from artificially-short-
ened project plans and take defensive action ac-
cordingly. Thus, when a team anticipates that its
plan is destined to take a 15% cut in duration and/or
budget once it goes to the executive committee, it
learns to pad the project with additional slack to
account for the cuts. But, a senior executive
once asked me, doesnt this just prove that we
were right to cut their project in the first place?
Actually, no. It is important to remember the order
of events here. Project teams develop this defense
mechanism because of past history of artificial
schedule compression. As a project manager once
put it to me: If they dont take our estimates
seriously, were not going to give them serious
estimates!
2.3. Creating project death marches
Coined by Yourdon (2004), the term death march
refers to projects that are typically set up to fail
under company-placed demands, leaving the expec-
tation that the project team will pull off a miracle. A
death march invokes imagery of a project team
wearily trudging along, mile after mile, with no
possibility of successful conclusion or end in sight.
Death marches are defined as projects whose
parameters exceed the norm by at least 50%. In
practical terms, that means: (1) the schedule has
been compressed to less than half the amount
determined by a rational estimating process;
(2) project team staffing has been reduced to half
the number that would normally be assigned to a
project of this size and scope; or (3) the budget and
other necessary resources are cut in half. External
pressures can lead to any of these conditions influ-
encing the project. For example, perhaps compet-
itive bidding to win the contract was so intense
that when the deal was signed, the firm had to
perform at such a cut-rate price that it could not
hire enough people or support the project team
sufficiently.
The result of these starting conditions is a virtual
guarantee that the project will fail, which begs the
question: Why are death marches so common and
647
why do they continue to occur, even within world-
class organizations that should know better? Several
possible reasons can be suggested, including:
 Nave promises made by marketing or inexperi-
enced project managers. Inexperience can result
in making rash promises that cannot be fulfilled.
 The Marine Corps mentality: real programmers
dont need sleep. This attitude emphasizes bra-
vado at the expense of evaluation. Hyper-
optimistic schedules are not an accident; they
are a manifestation of this aggressive attitude.
 The nave optimism of youth. Technical hotshots
who are feeling particularly cocky can land the
entire project team in trouble by getting in over
their heads.
 Intense pressure brought on by global competition,
new technologies, or government regulation. A
crisis mentality can shift the team, and their
project, into death march mode.
Although Yourdons (2004) work was done with IT
projects, the starting conditions found in these
circumstances can easily apply across many differ-
ent classes of projects. The end result is the same:
Massively wasted efforts are being spent on projects
that have been set up to fail by the very conditions
under which they are expected to operate.
2.4. End date-driven schedules
A common error made by many organizations entails
imposing Be done by. . . directives on their project
teams. That is, rather than create a viable time-
frame moving forward, managers actually start
scheduling by working back from some future date
considered to be a non-negotiable deadline. This
desire is understandable. Many organizations devel-
oping new products talk about launch windows, at
which time the product must be ready. For instance,
new toys must be on shelves in time for Christmas
shopping and new model-year automobiles have to
be on car lots every fall. Other projects may involve
restrictive contracts that specify large penalties in
the form of liquidated damages for late delivery. As
a result, there are many cases where the launch
window is a legitimate concern and should shape the
project delivery schedule. However, it is important
to understand how end date-driven schedules can
affect projectsparticularly when insufficient ad-
vance warning, lead time, or resources have been
contributed to actually make the target date rea-
sonable. First, these end date-driven schedules
648
serve as another form of death march mentality for
the project team. If a date is proposed without
sufficient resources supporting the team, the mes-
sages from top management are actually working at
cross-purposes with each other. On one hand, the
alarm has been sounded to complete a project by an
absolute must have date; on the other, without
actual resources to bolster this desirethat is, the
company putting its money where its mouth isthe
result can prove demotivating rather than challeng-
ing. Teams quickly draw a distinction between goals
that motivate and those that are perceived as im-
possible to attain. Too often, Be done by. . .
doesnt work. Second, end date-driven scheduling
immediately negates the value of comprehensive
planning, risk assessment, scope development, and
numerous other critical elements that are neces-
sary in putting together viable project plans. The
unspoken message in a deadline announcement is
that crisis looms; therefore, steps can be cut, plans
must be shortened, and risks waved off. Myriad
examples exist of software projects that, in a rush
to get them done by the launch window, were
introduced with so many bugs that they had to
be quicklyand expensivelywithdrawn from the ment or software tools training (Eigbe, Sauser, &
market, ultimately costing companies both money
and serious goodwill.
Savvy project organizations understand the na-
ture of dollar/day tradeoffs; there is usually a sim-
ple relationship between days saved on a project
schedule and resources committed to get it done.
The project team can speed up the development
process if senior executives show support by provid-
ing additional resources to get the job done. The
bottom line is simple: End date-driven schedules
must be shored up by a commitment, on the part of
the firms decision makers, to pay the necessary
costs. Otherwise, this practice leads to increas-
ingly cynical team decisions and dispirited team
members.
2.5. Lack of relevant project
management training
There is a wealth of data suggesting the degree to
which project management practices have been
emphasized in modern corporations. Former indus-
tries that were considered hotbeds of project-based
work (e.g., R&D, pharmaceuticals, automotive,
aerospace, construction) have now been subsumed
under a much broader canopy of diverse organiza-
tions (e.g., banking and financial, insurance, legal,
manufacturing) that are all heavily invested in using
projects as a primary means of enhancing corporate
value. Membership in professional project manage-
ment organizations, such as the Project Management
J.K. Pinto
Institute, has grown dramatically in recent decades;
today, over 500,000 million project management
professionals hold Project Management Profes-
sional (PMP) certification. As an indicator of the
emphasis corporations are placing on project
management expertise, these are positive and en-
couraging steps. Further, organizations such as
NASA, Rolls-Royce, BP, Fluor Daniel, and Boeing
are heavily invested in training and development
of project management skills for employees.
Consider NASAs Academy of Program/Project &
Engineering Leadership (APPEL) program, which is
committed to creating a second-to-none project
management workforce.
Much more needs to be done, however, to pursue
project management expertise beyond its current
levels. Even within many organizations that encour-
age project management, experience suggests pro-
cedures are far from standardized, while skill sets
are unevenly distributed across departments,
groups, and even individuals. A study of Federal
Aviation Administration (FAA) personnel, for exam-
ple, revealed that 89% of people assigned to manage
a projects schedule lacked formal project manage-
Boardman, 2010). This finding is not unique and
points to an underlying lack of systematic training
and education in project management techniques.
In short, project delivery is routinely trusted to
personnel who possess only rudimentary skills in
managing projects.
Another form of this problem becomes apparent
when we examine a phenomenon known as knowl-
edge management. Knowledge management entails
the explicit recognition that aging, successful project
managers take their expertise with them when they
retire and leave the company. As long as techniques
for successful project management remain idiosyn-
cratic and embedded within individuals rather than
becoming part of the organizations operating pro-
cedures, other employees must learn and relearn
these principles on their own, often through expen-
sive trial and error. Knowledge management seeks to
codify and retain an organizations critical skills and
expertise by capturing and passing on (Reich, 2007):
 Cultural knowledgehow the organization
views the world, operates, and emphasizes key
attitudes;
 Domain knowledgeinformation about the indus-
try, technology, or processes the organization uses
to develop projects;
 Institutional knowledgeintellectual capital a
project team member has about the organization,
Lies, damned lies, and project plans
including reporting structure and rules and pro-
cedures; and
 Process knowledgefacts about the project
plans, goals, and processes for development.
2.6. Poor change control
Change control is often labeled configuration man-
agement and refers to a tool that defines the prod-
uct, then controls changes to that definition (Kidd &
Burgess, 2004). It is the careful management of
necessary changes made to the project as it is being
developed. This occurs in response to environmental
shifts that necessitate major product modifications
sometimes due to faulty technology that must be
modified and corrected; sometimes as a result of
initial customer response to prototypes that demand
alteration. In short, change control recognizes the
simple fact that few projects survive, intact, their
first contact with the customer. Recent examples of
failed configuration management, along with the
resulting impacts, are evidenced by the Eurofighter
and Airbus A-380 projects. These programs experi-
enced huge mid-stream changes that were not effec-
tively accounted for or managed through change
control, resulting in billions of dollars in cost over-
runs.
Another common result of poor change control is
rework. Rework is a dirty word in most project
circles, as it implies that the project team failed to
adequately account for all technical, commercial, or
developmental issues. This necessitates that the
project be recycled back to some earlier stage in
its development, in order to get things right through
repeating iterations. In some industries (e.g., IT,
software development) rework is so prevalent that
it is the number one cause of late or cancelled
projects, and contributes approximately 60% to the
final project cost (Twentyman, 2005). Further, and
perhaps more depressing, a Computerworld survey
of 160 IT professionals revealed that 80% of the
respondents reported requirements creep always
or frequently, leading to the need for extensive
rework in projects. Worse, when asked by Peat
Marwick about failure rates of 65% for their software
or hardware development projects, over half the
managers surveyed indicated that these results
were normal (Pinto, 2013).
In some organizations, there exists the belief that
it is possible to eliminate all rework. Based on my
experience, I have found this to be a dangerous and
flawed view. For a number of reasons, confirmed
time and again through research studies of projects
across myriad industries, it is virtually impossible to
649
eliminate all the causes of rework. Rework may occur
because of:
 Changing requirementsbetter to get the spec-
ifications right before the project is completed;
 Engineering gold plating,the desire to contin-
uously add features outside of the initial scope in
order to give the project a bigger wow factor; or
 Poor initial planning and scopingwhen engaging
in bad planning, critical steps or activities are
neglected, which always come back to haunt the
project.
It is important to remember that sometimes rework
is desirable, as teams use the results of iterative
development cycles to debug systems or software.
Nevertheless, to help us understand the over-
whelming rework problem, it is helpful to apply
Coopers (1994) distinction between known and
undiscovered rework. Known rework results from
testing or top management demands that changes
be made to the current project configuration.
For instance, when Boeing originally redesigned
the cockpits of its 767 aircraft from 3-person to
2-person configurations, those changes required a
massive amount of rework to alter the way the
cockpit and all controls were positioned. The ad-
vantage of known rework is that it can be factored
into the estimated costs for rescoping a project.
Undiscovered rework, on the other hand, plays a
much more insidious role in projects. Because it is
still waiting to be identified, usually through down-
stream testing, it may be months or even years
before the discovery is made. During this time,
dependent work will have incorporated errors or
technical distortions. Thus, the more dependent
elements, deliverables, or activities there are in
a project, the greater the potential not just for
costly rework to occur, but for undiscovered rework
to have corrupted other parallel or supporting
activities during the projects development. Changes
at this stage are very costly.
2.7. Superficial risk management
Risk management is becoming more widely prac-
ticed in many project organizations, but there is
typically no agreed-upon methodology that is rou-
tinely adopted. Although we often think of project
risks, the manner in which risks are carefully con-
sidered, threats evaluated and classified, and miti-
gation strategies prepared is highly idiosyncratic;
this varies from firm to firm, and often from project
to project even in the same organization. Regarding
650
projects, risk is usually defined as an uncertain
event or condition thatif it occurshas a negative the process from project to project over time.
impact on the project. Conceptually, we can think of
most project risks as the product of two dimensions:
likelihood and consequence. As such, project risks
must first be identified and classified in terms of the
likelihood of their occurring. Receiving requests for
project specification changes from the customer in
mid-stream is a likely event; the project manager
being hit by a bus is, happily, not as common.
Coupled with this dimension is the assessment of
consequence. Some risks are judged to have low
consequence if they are to occur. These can usually
be ignored or entail relatively simple mitigation
strategies. Others are more severe and require
the project team to thoroughly analyze the poten-
tial impact of the event and develop appropriate
response strategies.
A useful way to view risk and response can be
found in Figure 1. This portrays a timeline of uncer-
tainty during the projects development, particular-
ly as it relates to risks (Winch, 2010). Note that
uncertainty offers the project team opportunities to
be both proactive and reactive in the face of events.
What is critical and often missed in our understand-
ing of project risks are the feedback/learning loops
shown in Figure 1. Most project risk management
focuses on the learning loops on the right side of the
figure; in other words, teams learn whether their
responses to actual events were useful and con-
structive. However, the problem with this form of
risk management is that it is inherently reactive.
Events have occurred that necessitate remedial
response. While this form of organizational risk
management may help teams limit the damage from
Figure 1. Timeline of uncertainty
J.K. Pinto
threatening events, they do little toward improving
Effective, proactive risk management recognizes
that learning can occur both in terms of response to
actual events and using these events to better
anticipate future states. Most organizations do
not adequately plan, through learning loops, for
what might happen in the future; that is, using risk
management as a critical component of overall
project planning. Getting risk management half
right is not an acceptable response.
3. Whats to be done?
Thus far, I have made the case that project planning
is laden with systematic and recurring errors that
often render it a nearly useless process. Clearly, not
every organization suffers from all these pathologies
when it comes to project planning; this is a cumula-
tive list based on my own research and consulting
experiences with a number of both national and
international corporations. However, it is evident
that when we examine these different planning
errors, they point to some underlying causes and
implications, including the following:
 Errors in judgment are often systematic and pre-
dictable, not random. We know much about the
ways in which people arrive at estimates. Opti-
mism bias, anchoring and adjustment, and other
errors of the planning fallacy are deep-rooted in
both organizational cultures and personal psyches
(Flyvbjerg et al., 2009). In fact, in many orga-
nizations, individuals are motivated to provide
Lies, damned lies, and project plans
misleading data (the idea of strategic misrepre-
sentation) knowing full well that being honest
about project challenges, real schedules, and
quality expectations will lead to an unwillingness
by top management to fund the project. The old
chestnut, It is easier to beg forgiveness than ask
permission, could be seen in this instance as an
example of the predictable nature of judgment
errors.
 Experts are just as prone to these problems as
everyone else. It is often assumed that well-
trained project personnel are capable of operat-
ing without bias or other planning errors. In fact,
research and practical experience usually dem-
onstrate that this is not the case. In his landmark
book, The Black Swan, Nassim Taleb (2010) used
the 1990s financial markets meltdown as an ex-
ample to demolish the perception that experts
are somehow operating with different informa-
tion, disinterested motives, and keener insight. In
fact, Taleb and Bent Flyvbjerg (2011) have re-
peatedly shown that these experts operate with a
set of biases every bit as pronounced as the rest
of us.
With these points in mind, I would like to offer some
suggestions as starting points for correcting blatant
project planning errors. While readers of the previ-
ously listed seven deadly sins can draw appropriate
conclusions from simply noting and resolving to
avoid these pitfalls, additional options exist that
project organizations may call upon as they begin
fixing systematic planning errors.
3.1. Suggestions to start fixing the
problems
3.1.1. Reference class forecasting
Reference class forecasting represents an attempt
to bypass human bias. In his analysis of systematic
bias in project planning, Flyvbjerg (2007) compiled
data from a number of years in relation to certain
classes of infrastructure projects. His findings are
shown in Table 2. Flyvbjerg coined the term refer-
ence class forecasting to acknowledge the nature
Table 2. Estimation errors by project class
Type of Project Average Inaccuracy
Rail 44.7%
Bridge and Tunnel 33.8%
Road 20.4%
All 27.0%
Source: Flyvbjerg (2007)
651
of systematic project overruns within classes of
projects, and further, to use it as a means of remov-
ing the subjective and predictably over-optimistic
human element from the estimation problem. Ref-
erence class forecasting relies on historical data
from past projects of a similar type to make more
reasonable predictions of budget and schedule
parameters for new projects. Using our earlier ex-
ample of the London Olympic Games, reference
class forecasting could have immediately raised
red flags in the face of preliminary cost projections
of a mere 1.8 billion.
As Table 2 demonstrates, overruns in certain
classes of projects are not only severe, but also
have been shown to be remarkably consistent. By
relying on reference class forecasting as an alterna-
tive to current approaches that, as we have seen,
are subject to delusional optimism and strategic
misrepresentation, the project organization and
stakeholders are working to normalize project esti-
mates. Thus, for example, in the case of an IT
operating system upgrade, the organization first
pulls all relevant historical information on schedule
estimates, actual completion dates, projected and
concrete budgetary numbers, and so forth. All
estimates should begin with these numbers as a
point of reference. While it is true that the human
element can never be taken out of project estimat-
ing, using reference class forecasting places the
burden of proof back on the project organization
to justify their numbers and identify any obvious
over-optimistic projections in the face of actual
historical information.
3.1.2. Factoring in necessary rework cycles
The notion of acknowledging and allowing necessary
rework is controversial, to say the least. When
rework is defined as correcting errors arising from
unanticipated events, the question can be asked:
How do we anticipate rework when, by definition,
its occurrence is unanticipated? Most organizations
have enough historic data, usually across types of
projects undertaken, to observe that rework is typi-
cally not the result of poor development, but a
function of the projects themselves (Cooper,
1994). That is to say, rework in certain classes of
projects occurs frequently and naturally (Love,
2002; Love & Li, 2000). As an example, initial spec-
ifications for many IT projects may suggest a certain
development cycle length; however, it is not until
actual end-users are permitted to navigate the
system that corrections can be most effectively
made. Rework here is necessary to hone the func-
tionality of the system, ensuring that the scope is
what the users expect. Thus, in many cases, rework
can be seen not as an unfortunate byproduct of poor
652
planning, but rather a necessary element in success-
ful project implementation.
3.1.3. Authenticity
Authenticity is deceptively obvious in concept, but
frustratingly difficult in practice. It refers to the
need for all stakeholders in the projectparticular-
ly within the organizationto modify a number of
self-preservation behaviors in the interest of im-
proving overall performance. In his book, Critical
Chain, Eli Goldratt (1997) observed that efforts
to fix project delivery were usually hamstrung by
self-interest. That is, it was in the self-interest of
project team members to protect themselves from
aggressive bosses by padding project estimates; it
was in the self-interest of managers to protect
themselves from anticipated top management cuts
by further padding duration estimates; and so forth.
As noted previously, one of the seven deadly sins of
project planning consists of precisely this sort of ex
post adjustment to protect against behaviors by top
management. Thus, self-interest continues to drive
project estimates.
Authenticity is a conscious decision made by proj-
ect team members and their managers to stop playing
the game of self-protection. Goldratts (1997) solu-
tion was to suggest that, prior to the schedule being
finalized, all project duration estimates be reas-
sessed as 50/50 probabilities. His research suggested
that padding increased reasonable estimates by near-
ly 200% in most cases, leading to seriously flawed
project plans. Giving the project manager control of
project safety while withholding punishment when
activities overrunafter all, they were based on 50%
likelihoodis the key to accomplishing two things:
improving the actual project delivery process
and positively altering the previously adversarial
relationship between managers and their teams.
Self-protection gives way to collective behaviors.
Although a simple option, authenticity requires cul-
tural changes, new ways of viewing the project and
team members, and support from top management.
World-class organizations such as BEA Systems and
Eli Lilly Pharmaceuticals have adopted Goldratts
authenticity principles embedded in the critical
chain methodology and experienced considerable
success in faster time to market and much improved
project development processes.
Authenticity serves as one of the best tools to
defend against the rival camps mentality that is so
prevalent in many of the errors we have discussed.
Rival camps imply systematic differences, coupled
with mistrust of motives, among critical project
stakeholders. Top management does not trust the
team to give honest estimates; the customer does
not trust the organization to be truthful about
J.K. Pinto
specifications; the project team does not trust
the project manager to create accurate schedules
and budgets; and so forth. Employing authenticity in
the process avoids the conflict-laden dynamic that
so often claims as its victim the project itself.
Authenticity also plays a critical role in managing
contractor-client relationships. A common dynamic
that arises between the project developer and the
client (for external projects) is to promise much, bid
low, and then renegotiate. In other words, in many
contracted relationships with clients, the project
organization deliberately low-balls initial bids and
then tries to find creative ways of extending profit
margins through add-ons and change orders. Cus-
tomers expect this behavior and the atmosphere is
often poisoned early via mutual distrust. When
customers are given a reason to alter the relational
dynamic, it is often surprising how well the recre-
ated relationship can work. For example, during the
building of Heathrows Terminal Five (T5), all project
stakeholdersincluding the customersentered
into relational contracts that specified cooperation
over conflict, mandating steps to resolve disputes
in an integrative win-win manner (Gil, Pinto, &
Smyth, 2012). While the results were not perfect,
relational contracting represented an important
step in moving toward an atmosphere of authen-
ticity, even between project organizations and
their customers.
3.1.4. Planning in segments, not just wholes
Large projects can be incredibly complex, involving
sizeable and highly complicated plans, comprehen-
sive schedules, and numerous interdependencies. In
light of these complexities, new methodologies
(e.g., cascade scheduling, agile methodology) are
being developed and successfully used in a number
of industries. While it is beyond the scope of this
article to go into great detail regarding these new
planning methods, they emphasize incrementalism,
constant client contact, iterative development
cycles, working in sprints, and so forth. Their main
efforts are predicated on breaking projects down
into smaller segments and addressing these incre-
ments one at a time. Planning projects in an itera-
tive, segmented manner reduces the complexity of
an enormous challenge into the relative simplicity
of viable stages. As the plan gets less complicated,
the negative effects of deadly planning sins also
become less intrusive.
4. Summary
Project management is a difficult, complex, time-
consuming undertaking. Project managers jobs
Lies, damned lies, and project plans
have been characterized by role overload, frenetic
activity, and superficiality (Slevin & Pinto, 1987, p.
33), and the environment in which project-based
organizations operate remains fast-paced and highly
competitive. Within the context of the myriad chal-
lenges project managers and their teams face, it is
ironic that professionals have often worked against
their own best interests through employing a variety
of planning processes that seem designed to actually
make successful project delivery increasingly diffi-
cult. This article has identified a number of planning
pathologies (the seven deadly sins) to highlight their
role in project failure, and encourage project man-
agers and team members to take a hard look at how
they are running their projects. When mistake fol-
lows mistake, is it any wonder that project after
project comes in late, over budget, or suffering
from poor quality? Successful project delivery is
challenging under the best of circumstances. Isnt
it time that people stop making their lives more
difficult than necessary?
References
Buehler, R., Griffin, D., & Ross, M. (1994). Exploring the planning
fallacy: Why people underestimate their task completion
times. Journal of Personality and Social Psychology, 67(3),
366381.
Chin, T. (2006, April 10). A bloody mess: Britains health network.
Amednews.com. Retrieved from http://www.ama-assn.org/
amednews/2006/04/10/bisa0410.htm
Cooper, K. (1994). The $2,000 hour: How managers influence
project performance through the rework cycle. Project Man-
agement Journal, 25(1), 1223.
Eigbe, A. P., Sauser, B. J., & Boardman, J. (2010). Soft systems
analysis of the unification of test and evaluation and program
management: A study of a Federal Aviation Administrations
strategy. Systems Engineering, 13(2), 298310.
Flyvbjerg, B. (2005). Design by deception: The politics of mega-
project approval. Harvard Design Magazine, 22(Spring-
Summer), 5059.
Flyvbjerg, B. (2007). Cost overruns and demand shortfalls in
urban rail and other infrastructure. Transportation Planning
and Technology, 30(1), 930.
Flyvbjerg, B. (2011). Over budget, over time, over and over again:
Managing major projects. In P. W. G. Morris, J. K. Pinto, & J.
Soderlund (Eds.), The Oxford handbook of project manage-
ment (pp. 321344). Oxford, UK: Oxford University Press.
Flyvbjerg, B., Garbulio, M., & Lovallo, D. (2009). Delusion and
deception in large infrastructure projects: Two models for
explaining and preventing executive disaster. California
Management Review, 51(2), 170193.
653
Gil, N., Pinto, J. K., & Smyth, H. (2012). Trust in relational
contracting and as a critical organizational attribute. In
P. W. G. Morris, J. K. Pinto, & J. Soderlund (Eds.), The Oxford
handbook of project management (pp. 438460). Oxford, UK:
Oxford University Press.
Goldratt, E. (1997). Critical chain. Great Barrington, MA: North
River Press.
Kapur, G. K. (1998, May). Dont look back to create the future.
Address given at the Frontiers of Project Management Annual
Conference, Boston, MA.
Kelley, M. (2008, November 18). $600 million spent on canceled
projects. USA Today, p. 1.
Kidd, C., & Burgess, T. F. (2004). Managing configurations and
data for effective project management. In P. W. G. Morris
& J. K. Pinto (Eds.), The Wiley guide to managing projects
(pp. 498513). Hoboken, NJ: John Wiley & Sons.
Love, P. E. D. (2002). Influence of project type and procurement
method on rework costs in building construction projects.
Journal of Construction Engineering and Management,
128(1), 1829.
Love, P. E. D., & Li, H. (2000). Quantifying the causes and costs of
rework in construction projects. Construction Management
and Economics, 18(4), 479490.
McKie, R. (2011, July 9). NASA fights to save the James Webb
telescope from the axe. The Guardian. Retrieved from http://
www.guardian.co.uk/science/2011/jul/09/nasa-james-webb-
space-telescope
Pinto, J. K. (2013). Project management: Achieving competitive
advantage (3rd ed.). Upper Saddle River, NJ: Prentice-Hall.
Rail project shutdown will cost Honolulu millions. (2012,
October 12). BusinessWeek. Retrieved from http://www.
businessweek.com/ap/2012-10-12/rail-project-shutdown-will-
costs-honolulu-millions
Reich, B. H. (2007). Managing knowledge and learning in IT
projects: A conceptual framework and guidelines for practice.
Project Management Journal, 38(2), 517.
Ritter, T. (2007, May 17). Public sector IT projects have only 30%
success rate. Computer Weekly. Retrieved from http://
www.computerweekly.com/blogs/public-sector/2007/05/
public-sector-it-projects-have.html
Shepperd, J. A., Carroll, P., Grace, J., & Terry, M. (2002).
Exploring the causes of comparative optimism. Psychologica
Belgica, 4, 6598.
Slevin, D. P., & Pinto, J. K. (1987). Balancing strategy and tactics
in project implementation. Sloan Management Review, 29(1),
3341.
Taleb, N. N. (2010). The black swan: The impact of the highly
improbable (2nd ed.). New York: Random House.
Twentyman, J. (2005, June 15). The crippling costs of project
rework. Inside Knowledge. Retrieved from http://www.
ikmagazine.com/xq/asp/txtSearch.Measuring/exactphrase.1/
sid.0/articleid.7A69C140-4A6A-451D-90A8-AABBFA2C4EA5/qx/
display.htm
Winch, G. M. (2010). Managing construction projects: An infor-
mation processing approach (2nd ed.). Chichester, UK: Black-
well.
Yourdon, E. (2004). Death march (2nd ed.). Upper Saddle River,
NJ: Prentice-Hall.