Chapter 1

The Problem

I have not seen any problem, however complicated, which,

when you looked at it in the right way, did not become
still more complicated.

Paul Anderson

Introduction
In 1976, early in my career, I became interested in effort and schedule
estimation as a result of a confrontation with a vice president at a
company for which I worked. Unknown to me, the organization had an
unstated effort and schedule in mind. I was a software project manager
while working on my MBA. There were no software estimation models
available to me at the time. I was told to prepare an estimate for a four-
terminal cluster system. Using the techniques learned through my MBA
and my knowledge and experience as a software developer and
project manager, I developed the estimate manually. It included a range
of effort accom- panied with estimates for risk and uncertainty.
When presenting the estimate to the VP, I was told, “This estimate is
too high, go cut it by a third.” When I said “I can’t,” the VP then said,
“You have assumed people would work only eight hours per day.
Go away and assume they will work twelve hours.” I said something to
the effect of, “I did assume eight hours per day. I assumed the other
four hours would cover the things that go wrong that I haven’t
thought of.”

1
 The Problem ■ 2

The VP provided several more ideas on how to cut the schedule

and effort estimates, all of which I stated were impractical. The VP was
insistent that the estimate be cut by a third. Whether I was naive or
a hero has never been determined. I stood by the estimate and the
project was cancelled. Some years later, I reestimated the project by
using a parametric cost model and determined that my original estimate
was significantly low. There simply wasn’t enough time and money
projected and, if the project had gone forward, it would have failed
miserably.1
“Far too many … software projects have become unaffordable and
unable to deliver needed quality, reliability, and capability within the
required time frame. Their outputs are not predictable. Their
processes are little more than chaotic and do not effectively utilize the
kinds of disciplines necessary to achieve success.” 2 “Unaffordable and
unable to deliver,” “not predictable,” and “chaotic.” These are words
that no one wants to have associated with his or her software project.
But the reality is that these situations are manifested in far too many
projects.
Several years ago a commercial company hired consultants to
assess a large software project that would significantly affect the
organization’s business processes. The discovery was soon made that
the project had been plagued with problems from the beginning.
Initially the organization had difficulty defining a set of requirements
on which all stakeholders could agree. In order to hold to critical
schedules, the project leaders were forced to delay functionality to
later releases. Additionally, they built significant concurrency into the
project to try to recover the schedule. Unfortunately, by developing
different aspects of the project concurrently, the project team never
seemed to have the resources to support all the activities required to
meet the schedule.
To understand the project’s dynamics, the consultants first
interviewed the project management team, who admitted that the project
was slow to begin but asserted they now had a good handle on their
problems. The project management team said they were taking steps to
address the troublesome but manageable schedule problems and they
projected that they would turn the corner sometime in the third
quarter.
Staff members were interviewed next. They presented a far different
story. An obviously overworked engineer told of having to work 12
to 16 hours a day for seven days a week for months on end under unrea-
sonable pressure. As soon as they could find jobs, he and many of his
associates were planning to leave. Obviously the consultants were inter-
ested in why this had happened and asked the engineer if he
thought the situation would change. He explained:
 The Problem ■ 3
We started on a bad foot with an initial estimate that was
unreasonable. Management knew the amount that had been
 budgeted for the system and had committed to build it
for 60 percent of that number with a 40 percent reserve. A
team of consultants brought in by management estimated the
project would cost three times what was finally presented to
the cus- tomer, based on a size projection that was two times
what had been previously estimated. In addition to the
discrepancy in the size projection, the consultants felt that the
productivity projections used by management were not based
on the his- torical performance of the organization and had
not included many tasks essential for the project to succeed.
These indepen- dent estimates were dismissed by
management as being done by an organization who were not
team players and who didn’t understand the dramatic
productivity benefits modern software engineering would
provide.

Despite the rocky start the project was funded and the
team was hired, although staffing took four months longer
than projected and project experience was minimal. As the
schedules started to erode, management took a “hands on”
role in resolv- ing the problems. Critical functions such as
risk management, inspections, trade-off studies and
independent QA were gutted or not done at all in the name of
schedule and cost reduction. The result is the situation we
are now in; too much work that is expanding at a rapid
pace due to unanticipated rework and too many defects, not
enough money or time to do even the basic things necessary
to get the project back on schedule and keep it on track.
Management’s attempts at restructuring the project by
moving tasks in parallel have compounded the prob- lem by
further compressing the schedule. It’s so bad now we seem to
lose a half day every day we work because of new tasks
we identify or defects we uncover. I can’t see this problem
getting any better soon.3

This engineer had a far more realistic view of what goes on in real-
world projects than many managers or experts in the field. He
understood that estimates are only as good as the size projections that
they are based on. He also understood that projections of productivity
must consider all the costs and tasks associated with a project — not
only those related to production.
As Tom DeMarco4 pointed out, “Are overruns and busted budgets
happening too frequently? When performance doesn’t meet the
estimate, there are two possible causes: poor performance or poor
estimates. In the software world, we have ample evidence that our
estimates stink, but
virtually no evidence that people in general don’t work hard enough or
intelligently enough.”
In the situation noted above, the management team lost sight of the
fundamental elements of successful project management: that
estimates for project cost and schedule should be based on reality, and
there is a minimum time required for any software development.
Successful project management also requires an estimate that
corresponds to and is driven by (a) how the process is to be managed,
monitored, and controlled, and
(b) how risks are to be identified, managed, and mitigated.

Managers and project staff often recognize the potential for

impending productivity shortfalls but assume that things will
work out even though the available evidence points to the
contrary. Managers often flock to unproven or unrealistic
“silver bullets” rather than addressing the true nature of a
problem. “If we can only get the tool installed by Friday we’ll
be OK.” “If Joe doesn’t quit….” “If we can squeeze 86 hours
from the staff next week….” “Changing our method will
give us the productivity we need.” “They probably won’t
catch that defect.” These are typical comments in projects
falling into this behavior.5

Focus of the Book

The focus of this book is how to make software projects more successful
by properly estimating and planning costs, schedules, risks, and
resources. The examples cited of unreasonable software project
estimation expose some of the fundamental problems: not planning up
front; failure to use viable estimates as the basis of an achievable
project plan, not updating the plan and estimates when a project
changes, and failing to consider the uncertainties inherent in
estimates. Most estimates are prepared early on in the life cycle of a
project, when there are typically a large number of undefined areas
related to the project. The steps presented in this book provide a method
for developing realistic estimates and plans, as well as managing the
risk associated with estimates.

Why Software Projects Fail

A recent search of the World Wide Web identified over 2100 sites that
describe over 5000 reasons that software projects fail, ranging from the
poor use of technology to lack of communication to management
inatten- tion. While certainly these factors can contribute to the failure
of a project,
the most pertinent reasons include (1) a lack of understanding of the
requirements of a project, (2) insufficient time or discipline to plan the
project properly from the first day, and (3) a loss of focus when the
project is under way.
In his book Winning with Software, 6 Watts Humphrey identifies
several causes for software project failure, including unrealistic
schedules, inap- propriate staffing, changing requirements, poor quality
work, and believing in magic. It is interesting to note that in both
references cited, technology issues are not factors and that Humphrey
lists management and sociolog- ical issues as primary causes of
dysfunctional projects. Many software managers focus on the
“technology of the software process” and fail to acknowledge or even
recognize the sociological factors that make projects work.7 These
factors include the need to:

1. Adequately project the resources and time required to deliver a

quality product that meets the commitments of the project and
the expectations of the users.
2. Be sensitive and responsive to the needs, frustrations, and
concerns of the staff and foster a project environment based on
the project team.
3. Adequately and effectively plan and provide sufficient time and
resources to accomplish the project and recognize that
technology- based “silver bullets” cannot substitute for
adequate planning.
4. Understand that risk is an inherent part of any worthwhile
endeavor; that risk can be identified and managed before the
project is affected; and that addressing risk is a responsible man-
agement function and does not reflect badly on the state of the
project or its potential for success.
5. Deny additional customer requests to prevent disruptions to the
project’s process or unspecified changes to the product.
6. Treat product quality and project commitments as absolute com-
mitments.
7. Collect meaningful, objective status data concerning progress,
qual- ity, productivity, and risk.
8. Define the expectations and true requirements of the user.
9. Address issues that threaten the project with effective and timely
solutions.

“A maxim of project management is that projects don’t fail in imple-

mentation; they fail in the planning stage.” 8 If this is true, why then do
competent managers agree to budgets, schedules, and technical commit-
ments that they have no idea how to meet? Why do seasoned, rational
executives pursue irrational solutions to project issues when the
engineers
offer no evidence that the solutions can meet those commitments? As
Humphrey notes, “Where software is concerned, many otherwise hard-
headed executives willingly accept vague promises and incomplete
plans. Management’s undisciplined approach to schedule commitments
contrib- utes to every one of the … most common causes of project
failure.”9
Almost all software-intensive projects start with the potential for
some degree of failure. The first risk of any software project is rooted in
the initial estimate used to forecast needed resources. The basic
equation traditionally used to estimate the project effort is:

Effort  (Size
Complexity)
Productivity

At the beginning of any project the three variables in the equation are
unknown. A baseline set of validated requirements is lacking so what
needs to be built cannot be accurately defined; the trade-off analyses and
architecture are not complete, so complexity is still unknown; and
the team has not been formed or, if it has, the team members have not
yet gone through the “forming, storming, norming, and performing” 10
steps that are essential for team success. All these unknown factors
mean productivity projections are little better than educated guesses.
The question then arising is where does that leave the project
manager? Is the project doomed to success or failure based on the
whims of fate or the clairvoyance of an estimator? No. Over the years,
estimation methods and tools that significantly lower the initial
estimation risks have been developed. However, failure to realize the
potential imprecise natures of initial estimates and effectively manage
and control the risks associated with them certainly is a major
contributor to downstr eam problems, including project failure.
Although software development organizations range from the com-
pletely ad hoc to the fully process-driven, most of them use some
manner of software estimates at the beginning of a project. Ad hoc
organizations may use off-the-cuff, back-of-the-napkin methods, while
others may pro- ceed in a very well thought out fashion, defining the
risks and uncertainties up front. Sometimes the customer for a project is
an internal organization, while other projects must be bid and awarded;
alternatively they may be outsourced to organizations that respond to
formal requests for proposals (RFPs). This book addresses projects for
both internal and external cus- tomers. Some of the case studies and
examples cited come fr om the outside contractor’s world and others
are based on in-house projects.
Why Software Projects Fail: Problems with Estimation
Accurately projecting and tracking software costs is difficult, and
cost overruns often occur. It is very important, therefore, to understand
software estimating processes and methods. According to the
Parametric Estimating Handbook of the International Society of
Parametric Analysis (ISPA), 11 software estimating problems often
occur because of the:
■ Inability to accurately size a software project
■ Inability to accurately specify an appropriate software
development and support environment
■ Improper assessment of staffing levels and skills
■ Lack of well-defined requirements for the software activity
estimated

Problems resulting from poor software estimation are some of the

most difficult problems a software development team will face. Many
people think that it is impossible to accurately project the time required
to develop or update a product, the size of an application, or
productivity, and that the best that can be done is to establish targets.
Some experts feel that software estimation is not precise enough to ever
satisfy business expec- tations.12 Often, engineers who are not software
specialists will prepare estimates while attempting to satisfy ulterior
agendas that are unconcerned with determining the true cost of
development. Estimates are frequently overly optimistic, attempting to
achieve a number that will satisfy a budget constraint. Sometimes they
are unrealistic in an effort to “take the heat off” a manager who must
defend them, or they may be trimmed to provide stretch goals to help
motivate staff. In the words of Capers Jones, “Most software projects
still tend to run late because of arbitrary estimate over- ruling by
customers and senior executives, creeping requirements, and inadequate
early quality control.”13
If used properly, estimates can provide basic constraints that
potentially limit the options available when planning a project. The
estimates also identify the resource limitations that must be considered
when scheduling a project, which in turn may dictate the selection of
methods and tools. Budget and resource constraints affect a project’s
schedule, the phasing of activities, the logical relationships of the work
activities, and the structuring and packaging of the products. In addition,
the estimate determines the options available to increase the quality of
the products, either precluding or enabling the use of practices such as
structur ed inspections or enhanced testing.
Software estimation methods have been applied with varying
degrees of success, to small and large projects. Table 1.1 summarizes
popular estimation methods.
Table 1.1 Estimation Methods14
Estimation
Method Objective Advantages Limitations
Analogy Compare project Estimates are Truly similar
with past similar based on projects must exist
projects actual
experience
Expert Consult with one Little or no Experts tend to be
judgment or more experts historical data is biased; knowledge
needed; good for level is sometimes
new or unique questionable; may
projects not be consistent
Top-down A hierarchical Provides an Need valid
estimation decomposition estimate linked requirements;
of the system to requirements difficult to track
into and allows architecture;
progressively common engineering bias
smaller libraries to size may lead to
components is lower-level underestimation
used to components
estimate the
size of a
software
component
Bottom-up Individuals Accurate Methods are time-
estimation assess each estimates are consuming;
component; possible because detailed data may
estimates are of detailed basis not be available,
summed to of estimate especially early in a
calculate the (BOE); promotes program;
total estimate individual integration costs
responsibility are sometimes
disregarded;
engineering bias
often leads to
underestimation
Design to Uses expert Easy to get Need reasonable
cost judgment to under customer assessment of cost
determine how number of defined
much functionality; may
functionality can have little
be provided for engineering basis
given budget
Table 1.1 (continued) Estimation Methods14
Estimation
Method Objective Advantages Limitations
Parametric Perform overall Models are Models can be
models estimate using usually fast and inaccurate if not
design easy to use, and properly applied;
parameters and useful early in a underestimation of
mathematical program; they size will
algorithms are also objective underestimate
and repeatable scope; excessive
optimism in
parameters may
lead to
underestimation