Chapter 1. Introduction

Say a project that started out as a small, stopgap utility has turned into a raging behemoth, sucking seemingly unlimited time from your programmers. Or the president of your company announced that your project will be done this week, even though you know that it still has an enormous number of bugs. Or your team delivered the software, only to have users complain that an entire feature is missing. Or every time the team fixes a bug, they seem to uncover a dozen moreincluding ones that you know were fixed six months ago. If you are a software project manager, you may recognize these problems (or similar ones) from your own career.

Many software organizations have problems delivering quality software that is finished on time and meets the users' needs. Luckily, most software project problems have surprisingly few root causes, and these causes are well understood. Solutions to these problems have been discovered, explained, and tested in thousands of software organizations around the world. These solutions are generally straightforward and easy to implement. However, they are not always intuitive to people who do not understand project management, and that makes them difficult to introduce. The goal of this book is to teach you about these solutions and help you integrate them into your own organization.

But this book is about more than just solutions to typical project problems. Every single technique, practice, and tool also helps establish an environment of trust, openness, and honesty among the project team, the management of the organization, and the people who will use or benefit from the software. By sharing all of your project information, both your team and your managers can understand your decisions, and they can see exactly why you made them.

It's easy to forget that project management is more than just a technical engineering skill. Good project management really boils down to a few basic principles that, if you keep them in mind, will help guide you through any software project:

• Make sure all decisions are based on openly shared information.

• Don't second-guess your team members' expertise.

• Introduce software quality from the very beginning of the project.

• Don't impose an artificial hierarchy on the project team.

• Remember that the fastest way through the project is to use good engineering practices.

A project manager needs to understand every facet of software development in order to make good judgements. You don't need to be a programmer, software tester, requirements analyst, or architect in order to be a good project manager. But you do need to know what these people do, why they are on your team, the common pitfalls they succumb to, and how to fix them. You need to be able to read and understand the documents that they create and provide intelligent feedback. And by relying on objective analysis (rather than gut feelings, personal preferences, or a perceived hierarchy within your team), you can use this knowledge in order to make decisions based on the best interests of the project.