MANAGEMENT SPECTRUM

Effective software project management focuses on the four P’s: people, product,
process, and project. The order is not arbitrary. The manager who forgets that software
engineering work is an intensely human endeavor will never have success in
project management. A manager who fails to encourage comprehensive customer
communication early in the evolution of a project risks building an elegant solution
for the wrong problem. The manager who pays little attention to the process runs the
risk of inserting competent technical methods and tools into a vacuum. The manager
who embarks without a solid project plan jeopardizes the success of the product.
 The People
The cultivation of motivated, highly skilled software people has been discussed since
the 1960s. In fact, the “people factor” is so important
that the Software Engineering Institute has developed a people management capability
maturity model (PM-CMM), “to enhance the readiness of software organizations
to undertake increasingly complex applications by helping to attract, grow, motivate,
deploy, and retain the talent needed to improve their software development capability”
The people management maturity model defines the following key practice areas
for software people: recruiting, selection, performance management, training, compensation,
career development, organization and work design, and team/culture
development. Organizations that achieve high levels of maturity in the people management
area have a higher likelihood of implementing effective software engineering
practices.
The PM-CMM is a companion to the software capability maturity model  that guides organizations in the creation of a mature software process. Issues associated with people management and structure for software projects are considered
later in this chapter.
The Product
Before a project can be planned, product1 objectives and scope should be established,
alternative solutions should be considered, and technical and management constraints
should be identified. Without this information, it is impossible to define reasonable
(and accurate) estimates of the cost, an effective assessment of risk, a realistic
breakdown of project tasks, or a manageable project schedule that provides a meaningful
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 business
process engineering and continues as the first step in software
requirements analysis. Objectives identify the overall goals for the product
(from the customer’s point of view) without considering how these goals will be
achieved. Scope identifies the primary data, functions and behaviors that characterize
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 delivery
deadlines, budgetary restrictions, personnel availability, technical interfaces, and
myriad other factors.
The Process
A software process provides the framework from which a comprehensive
plan for software development can be established. A small number of framework
activities are applicable to all software projects, regardless of their size or
complexity. A number of different task sets—tasks, milestones, work products, and
quality assurance points—enable the framework activities to be adapted to the characteristics
of the software project and the requirements of the project team. Finally,
umbrella activities—such as software quality assurance, software configuration management,
and measurement—overlay the process model. Umbrella activities are independent
of any one framework activity and occur throughout the process.
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, industry
data indicated that 26 percent of software projects failed outright and 46 percent
experienced cost and schedule overruns. Although the success rate for software projects has improved somewhat, our project failure rate remains higher
than it should be.
In order to avoid project failure, a software project manager and the software engineers
who build the product must avoid a set of common warning signs, understand
the critical success factors that lead to good project management, and develop a commonsense
approach for planning, monitoring and controlling the project