Managing and Leading Software Projects

Richard E. Fairley

• Publisher: Wiley-IEEE Computer Society Pr
• Year: 2011
• ISBN:
  9781118210994
• Edition: 1
• Topic: Computer Science
• Subtopic: Software Development
• Index: Computer Science

• The book is organized around basic principles of software project management: planning and estimating, measuring and controlling, leading and communicating, and managing risk.
• Introduces software development methods, from traditional (hacking, requirements to code, and waterfall) to iterative (incremental build, evolutionary, agile, and spiral).
• Illustrates and emphasizes tailoring the development process to each project, with a foundation in the fundamentals that are true for all development methods.
• Topics such as the WBS, estimation, schedule networks, organizing the project team, and performance reporting are integrated, rather than being relegating to appendices.
• Each chapter in the book includes an appendix that covers the relevant topics from CMMI-DEV-v1.2, IEEE/ISO Standards 12207, IEEE Standard 1058, and the PMI® Body of Knowledge.

(PMI is a registered mark of Project Management Institute, Inc.)

1
INTRODUCTION

In many ways, managing a large computer programming project is like managing any other large undertaking—in more ways than most programmers believe. But in many other ways it is different—in more ways than most professional managers expect.¹

—Fred Brooks

1.1 INTRODUCTION TO SOFTWARE PROJECT MANAGEMENT

When you become (or perhaps already are) the manager of a software project you will find that experience to be one of the most challenging and most rewarding endeavors of your career. You, as a project manager, will be (or are) responsible for (1) delivering an acceptable product, (2) on the specified delivery date, and (3) within the constraints of the specified budget, resources, and technology. In return you will have, or should have, authority to use the resources available to you in the ways you think best to achieve the project objectives within the constraints of acceptable product, delivery date, and budget, resources, and technology.

Unfortunately, software projects have the (often deserved) reputation of costing more than estimated, taking longer than planned, and delivering less in quantity and quality of product than expected or required. Avoiding this stereotypical situation is the challenge of managing and leading software projects.

There are four fundamental activities that you must accomplish if you are to be a successful project manager:

1. planning and estimating,
2. measuring and controlling,
3. communicating, coordinating, and leading, and
4. managing risk.

These are the major themes of this text.

1.2 OBJECTIVES OF THIS CHAPTER

After reading this chapter and completing the exercises, you should understand:

• why managing and leading software projects is difficult,
• the nature of project constraints,
• a workflow model for software projects,
• the work products of software projects,
• the organizational context of software projects,
• organizing a software development team,
• maintaining the project vision and product goals, and
• the nature of process frameworks, software engineering standards, and process guidelines.

Appendix 1A to this chapter provides an introduction to elements of the following frameworks, standards, and guidelines that are concerned with managing software projects: the SEI Capability Maturity Model^® Integration CMMI-DEV-v1.2, ISO/ IEC and IEEE/EIA Standards 12207, IEEE/EIA Standard 1058, and the Project Management Body of Knowledge (PMBOK^®). Terms used in this chapter and throughout this text are defined in a glossary at the end of the text. Presentation slides for this chapter and other supporting material are available at the URL listed in the Preface.

1.3 WHY MANAGING AND LEADING SOFTWARE PROJECTS IS DIFFICULT

A project is a group of coordinated activities conducted within a specific time frame for the purpose of achieving specified objectives. Some projects are personal in nature, for example, building a dog house or painting a bedroom. Other projects are conducted by organizations. The focus of this text is on projects conducted within software organizations. In a general sense, all organizational projects are similar:

• objectives must be specified,
• a schedule of activities must be planned,
• resources allocated,
• responsibilities assigned,
• work activities coordinated,
• progress monitored,
• communication maintained,
• risk factors identified and confronted, and
• corrective actions applied as necessary.

In a specific sense, the methods, tools, and techniques used to manage a project depend on the nature of the work to be accomplished and the work products to be produced. Manufacturing projects are different from construction projects, which are different from agricultural projects, which are different from computer hardware projects, which are different from software engineering projects, and so on. Each kind of project, including software projects, adapts and tailors the general procedures of project management to accommodate the unique aspects of the development processes and the nature of the product to be developed.

Fred Brooks has famously observed that four essential properties of software differentiate it from other kinds of engineering artifacts and make software projects difficult²:

1. complexity,
2. conformity,
3. changeability, and
4. invisibility of software.

1.3.1 Software Complexity

Software is more complex, for the effort and the expense required to construct it, than most artifacts produced by human endeavor. Assuming it costs $50 (USD) per line of code to construct a one-million line program (specify, design, implement, verify, validate, and deliver it), the resulting cost will be $50,000,000. While this is a large sum of money, it is a small fraction of the cost of constructing a complex spacecraft, a skyscraper, or a naval aircraft carrier.

Brooks says, “Software entities are more complex for their size [emphasis added] than perhaps any other human construct, because no two parts are alike (at least above the statement level).”³ It is difficult to visualize the size of a software program because software has no physical attributes; however, if one were to print a one-million line program the stack of paper would be about 10 feet (roughly 3 meters) high if the program were printed 50 lines per page. The printout would occupy a volume of about 6.5 cubic feet. Biological entities such as human beings are of similar volume and they are far more complex than computer software, but there are few, if any, human-made artifacts of comparable size that are as complex as software.

The complexity of software arises from the large number of unique, interacting parts in a software system. The parts are unique because, for the most part, they are encapsulated as functions, subroutines, or objects and invoked as needed rather than being replicated. Software parts have sever...

Table of contents

• Cover
• Table of Contents
• Title
• Copyright
• PREFACE
• 1 INTRODUCTION
• 2 PROCESS MODELS FOR SOFTWARE DEVELOPMENT
• 3 ESTABLISHING PROJECT FOUNDATIONS
• 4 PLANS AND PLANNING
• 5 PROJECT PLANNING TECHNIQUES
• 6 ESTIMATION TECHNIQUES
• 7 MEASURING AND CONTROLLING WORK PRODUCTS
• 8 MEASURING AND CONTROLLING WORK PROCESSES
• 9 MANAGING PROJECT RISK
• 10 TEAMS, TEAMWORK, MOTIVATION, LEADERSHIP, AND COMMUNICATION
• 11 ORGANIZATIONAL ISSUES
• GLOSSARY OF TERMS
• GUIDELINES FOR TERM PROJECTS
• INDEX
• End User License Agreement