What are the components of management spectrum?

3.1 THE 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 soft- ware 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.

3.1.1 The People

The cultivation of motivated, highly skilled software people has been discussed since the 1960s (e.g., [COU80], [WIT94], [DEM98]). In fact, the “people factor” is so impor- tant that the Software Engineering Institute has developed a people management capa- bility maturity model (PM-CMM), “to enhance the readiness of software organizations

“There exists to undertake increasingly complex applications by helping to attract, grow, motivate, enormous variability

deploy, and retain the talent needed to improve their software development capabil- in the ability of

different people to ity” [CUR94]. perform

The people management maturity model defines the following key practice areas programming

for software people: recruiting, selection, performance management, training, com- tasks.”

pensation, career development, organization and work design, and team/culture

Bill Curtis

development. Organizations that achieve high levels of maturity in the people man- agement area have a higher likelihood of implementing effective software engineer- ing practices.

The PM-CMM is a companion to the software capability maturity model (Chap- ter 2) that guides organizations in the creation of a mature software process. Issues

CHAPTER 3

PROJECT MANAGEMENT CONCEPTS

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

3.1.2 The Product

XRef

Before a project can be planned, product 1 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

“products” is discussed sonable (and accurate) estimates of the cost, an effective assessment of risk, a realistic

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).

58 PA R T T W O M A N A G I N G S O F T WA R E P R O J E C T S

software projects has improved somewhat, our project failure rate remains higher than it should be. 2

In order to avoid project failure, a software project manager and the software engi- neers 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 com- monsense approach for planning, monitoring and controlling the project. Each of these issues is discussed in Section 3.5 and in the chapters that follow.

What is the management spectrum?

What are the four P's of management spectrum?

What are the three P's in project management spectrum?

Which of the following is not a part of 4Ps in management spectrum?