Page 15 -

contains advanced applications of these tools and techniques. The goal of this book is to
help a project manager put the basic versions of these practices in place quickly, in order
to see immediate improvement in the efficiency of a project.
Software engineers are a very practical bunch. They do not like adopting practices unless
they believe they will see a net gain from them. A practice must save more time than it
costs to implement. Every single tool, technique, and practice in this book is time-tested.
These practices (or similar ones) have been used in many successful projects around the
world and in organizations of all sizes. These practices would not have found such wide-
spread adoption if they were not efficient.

All of the effort that goes into reviews, unit testing, requirements engineering—everything
that does not directly produce code—positively affects the bottom line of your project. If it
looks like a lot of work, you should think about the effort you are saving by not having to fix
the problems later when they show up as defects in your software. What’s more, you can be
confident that we optimized the techniques that you are putting in place in order to make
them as easy to adopt as possible. But most importantly, you can be sure that your project
will go more smoothly with them in place than it would without them.
This principle is most important when a project starts to slip and a deadline looms nearer
(or when one is blown altogether). It may be tempting to start cutting out these practices
and concentrate all of the effort into pumping out code. That’s one of the most common
mistakes that project managers make. Cutting out good project management practices will
make the project take longer, not make it go faster.

Part I: Tools and Techniques

If you’re a project manager and you’re reading this book, you probably can think of
chronic problems on your projects that you need to solve. What’s more, you probably
want to do it without trying to change the entire culture of your organization. You want
to build better software; you don’t necessarily want to undertake a major process
improvement initiative, or try to change the way everyone in your organization thinks
about building software. This book is written to treat a number of common problems sep-
arately by providing self-contained tools and techniques that address them.

Most people think of a tool as a piece of software that can be used to manage a project
schedule, track defects, or automate other tasks, in order to increase productivity on a
project. While there are certainly software tools like these discussed in this book, we support
a wider definition of the term. Here, “tool” is used to mean any self-contained concept, prac-
tice, technique, or software package that can be applied independently to a software project,
in order to improve the way it is performed. Risk management, for example, is as much of a
tool as Microsoft Project or Subversion. To make this distinction clear, the term “tools and
techniques” will be used throughout the book to indicate this concept.

The idea behind these tools and techniques is to allow a project manager to pick and
choose only those practices that solve the specific problems she is having with her own

INTRODUCTION 7