The Software Project Manager's Handbook: Principles That Work at Work / Edition 2

by Dwayne Phillips

Overview

Software project managers and their team members work individually towards a common goal. This book guides both, emphasizing basic principles that work at work. Software at work should be pleasant and productive, not just one or the other.

This book emphasizes software project management at work. The author's unique approach concentrates on the concept that success on software projects has more to do with how people think individually and in groups than with programming. He summarizes past successful projects and why others failed. Visibility and communication are more important than SQL and C. The book discusses the technical and people aspects of software and how they relate to one another.

The first part of the text discusses four themes: (1) people, process, product, (2) visibility, (3) configuration management, and (4) IEEE Standards. These themes stress thinking, organization, using what others have built, and people. The second part describes the software management principles of process, planning, and risk management. Part three discusses software engineering principles, the technical aspects of software projects. The fourth part examines software practices giving practical meaning to the individual topics covered in the preceding chapters. The final part of this book continues these practical aspects by illustrating a sample project through seven distinctive documents.

Product Details

ISBN-13:	9780471674207
Publisher:	Wiley
Publication date:	07/01/2004
Series:	Practitioners , #3
Edition description:	REV
Pages:	504
Product dimensions:	6.24(w) x 9.35(h) x 0.93(d)

About the Author

DWAYNE PHILLIPS has worked as a software and systems engineer with the U.S. government since 1980. He has a PhD in Electrical and Computer Engineering from Louisiana State University. Phillips is the coauthor, with Roy O’Bryan, of It Sounded Good When We Started (published by Wiley-IEEE Computer Society) and author of Image Processing in C as well as several dozen articles for computer magazines.

Read an Excerpt

The Software Project Manager's Handbook

---

By Dwayne Phillips

John Wiley & Sons

Copyright © 2004 IEEE Computer Society
All right reserved.
ISBN: 0-471-67420-6

---

Chapter One

What Makes a Good Software Manager?

Developing and maintaining software has become one of the most challenging and rewarding tasks a person can do. I've been privileged to attempt it in various settings for the last 15 years, and I've seen good software managers and bad ones. I've also been both at one time or another. This rather humbling experience has taught me what to value in a project manager. It has taught me that many managers approach software somewhat like the model in Figure 1.1. The project starts, everyone works hard, and software comes out some time later. If someone asks about progress, the project is always "almost finished." (If the project is headed by a more experienced project manager, it is always "93.7% finished.")

After much thought and observation, I believe this cloudy view of project management stems from a lack of three key perspectives. Of course, just having these perspectives does not guarantee a successful project, but it will go a long way toward making success possible.

1.1 PEOPLE PERSPECTIVE

Before I was a manager, I was a programmer, happily banging out solutions on the keyboard. I did well working alone. But software project management is not a loner's world. Loners who want to become software project managers must ask themselves hard questions: Do I like working closely with people? Do I want to understand what they mean when they talk to me? Do I basically like people? If the answer to these questions is a resounding "no," then you must ask another set of questions: Am I willing to change? Am I willing to study, take courses, read books, apply myself to people as diligently as I have ever applied myself to anything? If the answer is still "no," stop reading right now, and give this book to a friend. Stay in coding and have a challenging, rewarding life.

If you are still reading, you must have answered "yes" to at least one set of questions. Now take a hard look at how you feel about yourself. Gerald Weinberg (Weinberg, 1994), an excellent source of advice on people, has pointed out that we need a good sense of self-worth, self-esteem, self-confidence, and self-examination to work closely with people. If we don't have these, we will be hurt and hurt others often and deeply.

I have seen the truth of this on more than one occasion when a manager would attempt to change the way people do their jobs. Improvement, a goal for all, requires change and most people don't like to change. If I as a manager walk into a gathering of programmers and announce that the group would be better off changing the way they do things, I can almost always expect unanimous rejection. If I do not have confidence and self-esteem, I will drag my bruised ego out of the room and never implement the needed improvement. If, however, I do like myself and believe in my knowledge and abilities, I am more likely to realize that the group's negative reaction is a normal response to potential change, not a personal attack. A self-confident manager works through the fear of change person by person over time and implements the improvement.

I was able to move a group of programmers from coding cowboys to SEI CMM level 2. (Chapter 6 describes the Software Engineering Institute's Capability Maturity Model in more detail.) It was neither easy nor quick, but it happened. Patience, knowledge, and self-esteem are required, and most people with a little determination can do the same.

Unfortunately, most of us are operating with a distinct handicap. We weren't taught people or management skills. When we were in school, the instructor described the problem, and students individually coded a solution. Problems at work, however, require interaction with people, which can be fraught with difficulties. As Weinberg says, "the three causes of [software project] failure are people, people, and people." (Weinberg, 1994) The lack of a people perspective has helped litter the software industry with failed projects. Rob Thomsett (Thomsett, 1995) states that "most projects fail because of people and project management concerns rather than technical issues." I agree. I've seen new managers tell a group of talented programmers exactly how to solve a problem. The resulting revolt is quick, decisive, and puzzling. As a new manager, I asked myself countless times, "How could these people not embrace my carefully thought-through technical solution and management plan?" Besides, wasn't I the manager (translation, "the boss")? Weren't they supposed to do what I said? And wasn't I appointed manager because I was the smartest person in the group? If they didn't agree with me soon, we would all fail.

As long as attitudes like these continue, people skills will be in demand. Over the years, through much trial and error, I have identified some core people skills and personal qualities anyone who attempts to manage will need. The list below is by no means inclusive.

Be flexible. Let your people perform. The same people will react differently to a new project with a new product. Managers cannot manage each project just like the last one. The basic repeatable principles remain the same; only the particulars change (Constantine, 1995).

Have compassion. You must also learn how to deal compassionately with difficult people. In Chapter 4 on managing a project day to day, I call for removing toxic people from projects. Some people habitually hurt others; some lie and steal. However, removing them does not always mean firing them. Some of the people who act this way can be helped. An organization should never condone theft, dishonesty, or hatred, but it should also strive to act with kindness, patience, and compassion in helping to correct such actions. Try to help reform problem employees and help good employees when they need help. Be careful, however, about attempting to perform miracles. Rescuing can become a destructive addiction. Do what you can, recognize your limitations, and call in professional help when needed. Know when to lead and when to manage. Lead people; manage the process and product. Leading means that others are following, so set an example. If you act honestly and courteously all the time, people are apt to do the same. Examples also extend to behavior with other groups. You can be sure that your people will be watching as you talk to upper management, so tell the truth. Accept the role of meetings. You will perpetually be in meetings (Maguire, 1994; Gause and Weinberg, 1989). They will be held in halls, offices, parking lots, and even in rooms. These meetings are not just bureaucracy; they are communication. If they are bureaucracy, it is your fault and you should empower yourself to correct it. Chapter 5 gives you some techniques for doing this.

Perhaps the best advice comes from the sports and recreation world (Hawkins, 1994). Choose the best people, keep the team small, minimize distractions, train them, meet together as a team regularly, know them, and set an example. This is common sense, but all too uncommon in practice. As managers, we know what we should do and we have the means to do it. The last step is to get in the habit of doing it regularly.

1.2 BUSINESS PERSPECTIVE

The software industry is plagued with problems. Projects fall behind schedule, have cost overruns, or fail outright. And the failures are sometimes spectacular (who can forget the Denver International Airport baggage handling system or the Federal Aviation Administration's traffic control system?).

I'm convinced that a good part of the reason for these failures is a lack of business perspective. Most of us were introduced to software through programming. The problems were easy enough and we were smart enough to sit down and code the solutions without much thought. The problems we face now are more difficult, and we can't solve them alone. This requires different techniques and delving into what seems like mindless bureaucracy. Tasks like writing requirements, selecting a design alternative, and having others review our work are some techniques that can make us smart enough to solve these larger, more complex problems.

But these tasks encompass more than an immediate perspective. They require some idea of the big picture. They mean that we must look hard at management problems in the context of business requirements.

A well-known study by the Standish Group (Glass, 2002) paints an embarrassing picture. In the survey, 23% of the projects were canceled before completion (projects couldn't be saved); 49% of the projects were finished, but were over budget, late, and did not have the required functionality. Only 28% were on budget with all the desired functions. These numbers were improved from 1995 (Johnson, 1995), but still have much room for improvement.

I suspect that projects fail to deliver as frequently as they do because practitioners don't see the needs of the business enterprise. Building software at work is done for the benefit of the business. This means asking questions like "Who will use the software? Who wants it and who doesn't? What will the software do for the user and our business? Where will people use it? When do the users need (not want) it? Why do the users want it? Why does our business need it? Why are we developing it? What can we do differently that will bring greater benefit to our business and consequently to us as employees?

I agree with Howard Rubin (Rubin, 1996), who said "a world-class (software) organization's primary distinguishing aspect is a common understanding of how its technical performance is transferred into value for the enterprise."

One of the best pieces of advice a software project manager can heed is to build only the software people want (Szmyt, 1994). This seems obvious, but it is ignored all too frequently. Programmers build software; they don't look for reasons not to. When programmers learn a new technique, they quickly create a new solution (whether or not anyone else wants it) and invent a problem for it.

Unfortunately, if people don't want the software, they won't use it. All the money spent building it and trying to have people use it is wasted. Companies that waste money go out of business, and people lose paying jobs. Build interesting new software at home; at work, build software that people want and the business needs.

The key is to add value to the customer's endeavors. I close with a comment from Jerry Weinberg's SHAPE forum (Weinberg, 1997). "We all think we add value, but it's not value if the customer doesn't see it that way. If what you value is not what the customer values, it doesn't mean either one of you is "bad." It just means there is not a very good fit." One simple way to determine if I am adding value to the customers is to ask them. In my experience, they answer honestly. I place these comments here because they span the concepts of the people and business perspectives. Business, as most things, comes down to people. If the people aren't satisfied, the business isn't either.

1.3 PROCESS PERSPECTIVE

Software project managers must do the right things in software projects. This is known as using the right process or applying best practices. Table 1.1 takes a look at current level of practice and what is recommended for a successful project. The left column shows that the build phase or coding always occurs (McConnell, 1993). If there is no code, there is no software. The second column shows the tasks some projects may complete, although often unintentionally. Software managers should state the problem clearly (define requirements), decide among alternative solutions (design), bring together the elements of software into a product, and test the result systematically. The third column (when combined with the first two) shows what should be done. If you are a software manager who does not do each one of these on every project, this book is for you.

1.3.1 Successful Process Techniques

A major influence in the process movement has been the Capability Maturity Model of the Software Engineering Institute (Humphrey, 1989; CMU/SEI, 1995). The CMM is a progression of levels, each of which contains key processes. An organization starts at the Initial level (see Chapter 6) and step by step adopts processes that lead to a greater ability to produce software. The SEI produced several more capability maturity models (e.g., one for software acquisition, one for people management, one for system engineering, etc.). They consolidated and replaced these with the Capability Maturity Model Integrated (CMMI). The CMMI contains proven engineering and management basics. Some people have maligned these CMMs as being too bureaucratic (government and defense oriented) and instead pushed best practices and, more recently, agile methods. If you look closely at the two, however, most best practices lists contain the same items as the CMMI.

I believe the CMMI works, and I've seen it work. I prefer not to debate whether it can be improved. A couple dozen experts in the United States are qualified to argue the finer points of the CMMI; the rest of us would be much better off if we simply followed it.

Humphrey created a CMM for the individual called the Personal Software Process (PSP) (Humphrey, 1995). The PSP (see Chapter 6) guides an individual programmer through a similar progression of processes. I worked through Humphrey's method and found that it also works at work. The exercise proved, much to my annoyance, that I was not smart enough to sit down and code off the top of my head. The PSP makes you write out a design, review it, write code, print the code, and review the code before compiling it the first time. My own metrics proved that with this mindful bureaucracy, I could produce more error-free software in less time.

These techniques (the CMMI, PSP, and others like them) apply basic engineering and management principles to software. Over the years, we software practitioners convinced ourselves that software was different. The basics did not apply to us; we needed to break the mold. We were wrong. Software is different in some ways, but it has more in common with other fields than we want to admit. We must use what others have proven works at work.

Some people feel they cannot do the right thing in their current job. I've heard it all: "Our management won't let us write requirements and hold a requirements inspection." "Our programmers would revolt if we asked them to let others inspect their code."

To these objections, I respond with two statements, which are easier said than done, but are not impossible to either say or do. You can probably fill in the blanks better than I can.

Life is too short to ______ ("work for indecisive management," "chase out-of-control projects," "argue about proven practices," "fix errors late instead of early").

We have never done ______ here ("code inspections," "configuration management," "planning," "quality assurance," "metrics").

On my 35th birthday, I woke up and realized I was halfway to my biblical three score and ten years. Being on my second half, I decided that I would no longer run out-of-control projects. I would do the things I knew would work. If other people did not like that, I decided life is too short to put up with people who will not do the things proven to work at work.

1.3.2 Best Practices

The idea behind best practices (Glass, 1995) is to examine organizations that succeed consistently to discover what they do. If enough of these best-performing organizations practice similar tasks, these become a best practice for the industry. This is similar to, but not the same as, the emphasis on process. The best practices also include elements of people and product.

Below is a best practices list compiled from the best practices lists of many well-known authors: (Bach, 1995; Comaford, 1995; Jones, 1996a; Jones, 1996b; Johnson, 1995; Parnas, 1996; Racko, 1995; Reid, 1995; Sharp, 1995; Wirth, 1995). Note that the newest of these sources dates from 1996. Although I have read several dozen papers and texts since then that discuss best practices, none of them offer anything beyond this list. All the latest best practices come from one form or another of those listed here. I will repeat this list and discuss it again in Chapter 6.

(Continues...)

---

Excerpted from The Software Project Manager's Handbook by Dwayne Phillips Copyright © 2004 by IEEE Computer Society. Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

---

Table of Contents

Preface.

Part 1.

1 What Makes a Good Software Manager?

1.1 People Perspective.

1.2 Business Perspective.

1.3 Process Perspective.

1.4 Key Thoughts in This Chapter.

References.

2 Four Basics That Work.

2.1 People, Process, and Product.

2.2 Visibility.

2.3 Configuration Management.

2.4 Standards.

2.5 Key Thoughts in This Chapter.

References.

3 What Doesn’t Work and Why.

3.1 When the 3Ps Are Out of Balance.

3.2 When There’s Not Enough Visibility.

3.3 When Configuration Management is Missing or Abused.

3.4 When Standards are Dismissed.

3.5 Key Thoughts in This Chapter.

Reference.

4 Managing a Project Day by Day.

4.1 Balancing the 3Ps to Create a Good Environment.

4.2 Visibility: Project Control in a Simple Equation.

4.3 CM: Managing Baselines with Milestones.

4.4 Looking to Standards for Help.

4.5 Key Thoughts in This Chapter.

References.

Part 2.

5 Requirements.

5.1 Balancing the 3Ps: Requirements Analysis, Documentation, and Management.

5.2 Visibility: Making Requirements Known.

5.3 Using CM.

5.4 Using Standards.

5.5 Key Thoughts in this Chapter.

References.

6 Planning.

6.1 Elements of a Good Plan.

6.2 Balancing the 3Ps: Selecting the Process.

6.3 Making the Project Visible: Planning Techniques.

6.4 Making the Project Visible: Estimating Techniques.

6.5 Configuration Management.

6.6 Standards.

6.7 Key Thoughts in this Chapter.

References.

7 Risk Management.

7.1 A Task Overview.

7.2 Balancing The 3Ps: Uncertainty and Choice.

7.3 Making Risk Visible.

7.4 Other Ways to Manage Risk.

7.5 Configuration Management.

7.6 Using Standards.

7.7 Key Thoughts in this Chapter.

References.

Part 3.

8 Design.

8.1 The Challenge of the 3Ps.

8.2 Visibility—Expressing the Design.

8.3 Design in the Code.

8.4 Design and Process.

8.5 Designing with COTS.

8.6 Configuration Management.

8.7 Standards: Writing the SDD.

8.8 Key Thoughts in this Chapter.

References.

9 Integration and Testing.

9.1 Some I&T Myths.

9.2 Managing the 3Ps: People.

9.3 Managing the 3Ps: Process.

9.4 Visibility: Testing Techniques and Details.

9.5 Configuration Management.

9.6 Standards: Documenting the Test Plan.

9.7 Key Thoughts in this Chapter.

References.

10 Software Maintenance.

10.1 What is Maintenance.

10.2 Balancing the 3Ps: Managing the Maintainers.

10.3 Balancing the 3Ps: Managing the Process.

10.4 Balancing the 3Ps: Making the Most of the Product.

10.5 Visibility: Understanding the Maintenance Stages.

10.6 Configuration Management.

10.7 Using Standards.

10.8 Key Thoughts in this Chapter.

References.

Part 4.

11 Cookbook.

11.1 Essentials.

11.2 Opt: A Waterfall Project.

11.3 System Upgrade: An Evolutionary Project.

11.4 CTRAN: A Spiral Project.

11.5 Other Software Projects.

11.6 Key Thoughts in this Chapter.

References.

Appendix A Documents for the OPT Project.

A.1 OPT Executive Sponsor Memorandum.

A.2 OPT Project Context Document.

A.3 OPT Configuration Management Plan.

A.4 OPT Concept of Operations.

A.5 OPT Software Requirements Specification.

A.6 OPT Software Project Management Plan.

A.7 OPT Software Design Description.

Appendix B Configuration Management.

B.1 Will The Real CM Please Stand Up?

B.2 The Main Ingredients.

B.3 Baselines.

B.4 CM Activities.

B.5 CM People.

B.6 CM Plan.

B.7 A CM Sketch.

B.8 Summary.

References.

Appendix C Structured Analysis and Design.

C.1 Structured Analysis.

C.2 Structured Design.

References.

Appendix D Annotated Bibliography.

D.1 Process.

D.2 Visibility.

D.3 People.

D.4 Journals.

Index.

About the Author.

Editorial Reviews

"…clearly explains what it takes to be a good software project manager...a first-rate information source for novice project managers." (IEEE Software Magazine, November/December 2005)

"...a useful book for the classroom or the workplace...I advise purchasing this book and applying the author's ideas." (Software Quality Professional, September 2005)

"...a good reference for individuals just starting off as IT project managers...For those preparing for the CSQE exam, this book can be a good reference..." (Software Quality Professional, June-August 2005)

"…helps guide software project managers and their team members in working towards common goals." (IEEE Computer Magazine, October 2004)

From the Publisher

Project visibility and communication, proper configuration management, the use of standards, and a balance of people, process, and product are key in this approach to effective software management. The author describes the stages of the software development cycle--from requirements gathering and analysis, planning, and risk management to design, integration and testing, and maintenance. The final chapter presents case studies using waterfall, evolutionary, and spiral process models. Annotation c. by Book News, Inc., Portland, Or.

Booknews