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 separately 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, practice, 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 projects. ...