Page 86 -

CHAPTER 3 PROJECT MANAGEMENT CONCEPTS 57

associated with people management and structure for software projects are consid-
ered later in this chapter.

3.1.2 The Product
1
XRef Before a project can be planned, product objectives and scope should be established,
A taxonomy of alternative solutions should be considered, and technical and management con-
application areas that straints should be identified. Without this information, it is impossible to define rea-
spawn software sonable (and accurate) estimates of the cost, an effective assessment of risk, a realistic
“products” is discussed
in Chapter 1. breakdown of project tasks, or a manageable project schedule that provides a mean-
ingful indication of progress.
The software developer and customer must meet to define product objectives and
scope. In many cases, this activity begins as part of the system engineering or busi-
ness process engineering (Chapter 10) and continues as the first step in software
requirements analysis (Chapter 11). Objectives identify the overall goals for the prod-
uct (from the customer’s point of view) without considering how these goals will be
achieved. Scope identifies the primary data, functions and behaviors that character-
ize the product, and more important, attempts to bound these characteristics in a
quantitative manner.
Once the product objectives and scope are understood, alternative solutions are
considered. Although very little detail is discussed, the alternatives enable managers
and practitioners to select a "best" approach, given the constraints imposed by deliv-
ery deadlines, budgetary restrictions, personnel availability, technical interfaces, and
myriad other factors.

3.1.3 The Process
A software process (Chapter 2) provides the framework from which a comprehen-
sive plan for software development can be established. A small number of frame-
work activities are applicable to all software projects, regardless of their size or
Framework activities complexity. A number of different task sets—tasks, milestones, work products, and
are populated with quality assurance points—enable the framework activities to be adapted to the char-
tasks, milestones, acteristics of the software project and the requirements of the project team. Finally,
work products, and umbrella activities—such as software quality assurance, software configuration man-
quality assurance
points. agement, and measurement—overlay the process model. Umbrella activities are inde-
pendent of any one framework activity and occur throughout the process.
3.1.4 The Project
We conduct planned and controlled software projects for one primary reason—it is
the only known way to manage complexity. And yet, we still struggle. In 1998, indus-
try data indicated that 26 percent of software projects failed outright and 46 percent
experienced cost and schedule overruns [REE99]. Although the success rate for

1 In this context, the term product is used to encompass any software that is to be built at the
request of others. It includes not only software products but also computer-based systems,
embedded software, and problem-solving software (e.g., programs for engineering/scientific prob-
lem solving).