Book Excerpt: Applied Project Management

We recently had a chance to take a look at one of the new offerings from O'Reilly: "Applied Project Management." The book offered some interesting insights and a few updated ways of looking at old ideas -- Read on for a short excerpt.

Chapter 1: Introduction

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 more including 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 judgments. 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.

Section 1.1: Tell Everyone the Truth All the Time

The most important principle in this book is transparency . A project manager constantly makes decisions about the project. If those decisions are based on real information that's gathered by the team and trusted by management, that's the most likely way to make sure the project succeeds. Creating a transparent environment means making all of that information public and explaining the rationale behind your decisions. No software project goes exactly as planned; the only way to deal with obstacles is by sharing the true nature of each problem with everyone involved in the project and by allowing the best solution to come from the most qualified people. But while anyone would agree with this in principle, it's much harder to keep yourself and your project honest in practice. Say you're a project manager, and your project is running late. What do you do if your boss much to your surprise announces to the world that your project will be done on time? Unfortunately, when faced with this situation, most project managers try to change reality rather than deal with the truth. It's not hard to see why that approach is appealing. Most people in software engineering are very positive, and it's not hard to convince them that an unrealistic deadline is just another technical challenge to be met. But the passage of time is not a technical challenge, and if the expectations are unrealistic, then even the most talented team will fail to meet them. The only real solution to this problem is to be open and honest about the real status of the project and that's going make your boss unhappy. And so, instead of telling the truth, many project managers faced with a deadline that's clearly unrealistic will put pressure on their team to work late and make up the time. They silently trim the scope, gut quality tasks, start eliminating reviews, inspections, and pretty much any documentation, and just stop updating the schedule entirely. And, above all, they wait until the very last minute to tell everyone that the project is late.., hoping against hope that luck, long hours, and a whole lot of coffee will correct the situation. And sometimes it works... sort of, until the users have to work around bugs or missing features, until programmers have to start patching the software, and until managers have to go on a charm offensive in order to smooth over rough relations among everyone involved. Even if the deadline was met, the software was clearly not really ready for release. (And that's assuming the team even managed to squeeze it out on time!) That's why the most important part of building better software is establishing transparency. It's about making sure that, from the very beginning of the project, everyone agrees on what needs to be built, how long it will take to build it, what steps will be taken in order to complete the project, and how they will know that it's been done properly. Every tool, technique, and practice in this book is based on the principles of freely sharing information and keeping the entire project team "in the loop" on every important decision.

Section 1.2: Trust Your Team

If you are a project manager, it's your job to be responsible for the project. That means that you have to do whatever it takes to get the project out the door. But it does not necessarily mean that you know more about the project than everyone else on the team. Yet many project managers act in exactly this way. They arbitrarily cut down or inflate any estimates that they don't understand, or that give them a bad gut feeling. They base their schedules on numbers that they simply made up. And, most importantly, they make every project decision based on how it will affect the schedule, instead of considering how it will affect the software. Managing a project is all about forming a team and making sure that it is productive. The best way to do that is to rely on the expertise of the team members. Any project manager who tries to micromanage his team will immediately get overwhelmed, and the project will come screeching to a halt. Every single role in a software project requires expertise, skill, training, and experience. There is no way that one person can fill all of those different roles she would need several lifetimes just to gain enough knowledge of each discipline! Luckily, nobody has to do it alone: that's why you have a team full of qualified people. It's up to them to recommend the best course of action at each stage of the project; it's up to you to make informed decisions based on their recommendations. If you don't have a good reason to veto an idea, don't do it. Usually, the people on your team know best what it takes to do their job. The most important thing that you can do to support them is to trust them and listen to them. However, you cannot blindly trust your team. You need to evaluate their ideas in relation to solid engineering principles. This is why the first part of this book goes beyond "traditional" project management (creating project plans, developing estimates, building schedules, etc.) to cover all parts of a software project. Every project manager needs to understand at least the basic principles of software requirements engineering, design and architecture, programming, and software testing in order to guide a software project through all of the phases of development.

Section 1.3: Review Everything, Test Everything

Reviews get a bad rap. Many people see them as frivolous. "In a perfect world," many project managers say, "we would review all of our documents. But we live in the real world, and we just don't have time." Others feel that the only reason for a review is to force various people to sign off on a document as if a signature on a page somehow guarantees that they agree with everything that it's stapled to. The purpose of a review is not to make a perfect document or to generate a page of signatures. Rather, a review does two things: it prevents defects in the software and it helps the project manager gain a real, informed commitment from the team. What's more, it's important to recognize that no review is perfect and that's just fine. It may not be possible to catch 100% of the defects before coding has started, but a good review will catch enough defects to more than pay for the time it took to hold the review. It is always faster and cheaper to hold a review meeting than it is to skip it, simply because it's much easier to fix something on paper than it is to build it first and fix it later. When a review turns up an error that takes a few minutes to fix in a document, it saves the team the hours, days, or weeks that it would take to fix the error once it has been built into the software. But even more importantly, reviews frequently uncover errors in documents whose resolution requires a lot of discussion and decision-making. Errors like this can completely destroy a software project if they make it all the way into the code. Many project managers try to schedule reviews, only to meet with an enormous amount of resistance from everyone around them. Peers, project team members, and senior managers all seem to resist the idea of "yet another meeting." Oddly, the same project managers who are unable to scrape together an hour and a half to review a scope document at the beginning of the project generally have no difficulty whatsoever scheduling lengthy, tedious weekly status meetings with no agenda, goal, or purpose. (Of course, not all project status meetings have to be run that way!) The truth is that there is no such thing as wasted time in a review. On average, every hour spent reviewing and repairing documents saves well over an hour later in the project. This is true because it catches costly errors early on in the project, when they are cheap to fix. But reviews have other valuable benefits as well. By bringing team members into a room to evaluate each others' work, reviews foster respect among the team members for everyone's contributions. And, most importantly, a review results in a real commitment to the work that is produced by the team, not just a signature. Testing whether it is unit testing, functional testing, performance testing or regression testing is just as important, and just as likely to be dismissed as unaffordable or "idealistic." Yet software testing activities are just as cost-effective as reviews. The team can't "test in" quality at the end of a project just by tacking on some testing tasks. Testing must be planned from the beginning and then supported throughout the entire project. To come up with a quality product, the entire team needs to actively look for defects at every stage, in every document, and in the software. It's the project manager's responsibility to make sure that this happens.

Section 1.4: All Software Engineers Are Created Equal

A software project requires much more than just writing code. There are all sorts of work products that are produced along the way: documents, schedules, plans, source code, bug reports, and builds are all created by many different team members. No single work product is more important than any other; if any one of them has a serious error, that error will have an impact on the end product. That means each team member responsible for any of these work products plays an important role in the project, and all of those people can make or break the final build that is delivered to the users. There are many project managers who, when faced with a disagreement between a programmer and a tester, will always trust the programmer. This same project manager might always trust a requirements analyst or a business analyst over a programmer, if and when they disagree. Many people have some sort of a hierarchy in their heads in which certain engineering team members are more valuable or more skilled than others. This is a dangerous idea, and it is one that has no place on an effective project team. One key to building better software is treating each idea objectively, no matter who suggests it or whether or not it's immediately intuitive to you. That's another reason the practices, techniques, and tools in this book cover all areas of the software project. Every one of these practices is based on an objective evaluation of all of the important activities in software development. Every discipline is equally important, and everyone on the team contributes equally to the project. A software requirements specification (SRS), for example, is no more important than the code: the code could not be created without the SRS, and the SRS would have no purpose if it weren't the basis of the software. It is in the best interest of everyone on the team to make sure that both of them have as few defects as possible, and that the authors of both work products have equal say in project decisions. The project manager must respect all team members, and should not second-guess their expertise. This is an important principle because it is the basis of real commitments. It's easy for a senior manager to simply issue an edict that everyone must build software without defects and do a good job; however, this rarely works well in practice. The best way to make sure that the software is built well is to make sure that everyone on the team feels respected and valued, and to gain a true commitment from each person to make the software the best it can be.

Section 1.5: Doing the Project Right Is Most Efficient

The first part of this book is a presentation of techniques, tools, and practices for every phase of a software project. They are designed to be implemented one at a time and in any order (with a few restrictions). This means that you have a lot of freedom to choose the approach that is best for your project. But no matter which one you choose to implement first, you can be sure that your project will be better off with the practice than it would be without it. This is because building the software correctly the first time is always preferable to doing it wrong and having to go back and fix it. Every practice in this book is designed to help you build software efficiently and accurately. What's more, there are many ways to implement every single one of these practices. We put a great deal of effort into developing the most efficient version of each tool, technique, or practice we present in this book. We did this by stripping out as many of the "bells and whistles" as possible from each practice without compromising its basic integrity. There are more complex and involved ways to implement every single idea in this book. Wherever possible, there are references that will point you to more in-depth reading that 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 widespread 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.

Section 1.6: 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. When a software project is in trouble, a disproportionate amount of the trouble is usually caused by a small number of problems. The tools and techniques in this book are meant to address those specific problems. An organization that implements all of these tools and techniques will see an enormous gain in both productivity and user satisfaction for minimal cost. A project manager who targets the specific problems that he has found in his organization can address only his most pressing problems and still see a very noticeable gain and at a much lower cost than trying to tackle every possible project problem! Because the tools and techniques can be applied independently, one useful way to use this book is to take a "toolbox" approach to building better software. Consider the tools, techniques, practices, software packages, and other ideas in this book as individual tools in a toolbox. You can select the right tool depending on the specific problems and challenges that you face in your projects. While these tools have been developed to be used by project teams, most of them can be implemented by a single person, either working alone or in a team environment. Using this book, even a single team member working alone can have a significant effect on both the quality of the software being produced and the effectiveness of the organization to which he belongs. Each chapter in Part I of this book is based on a specific phase or area of a software project. It contains specific tools and techniques a project manager can use to help address problems, as well as information that most project managers should know about what goes on during that phase of the project. Part I covers the following tools and techniques, divided into different areas of project management:

Chapter 2, Software Project Planning

Vision and Scope Document Software Project Plan

Chapter 3, Estimation

Wideband Delphi Estimation Process

Chapter 4, Project Schedules

Project Schedules Earned Value Metrics Project Scheduling Software (such as Microsoft Project and Open Workbench)

Chapter 5, Reviews

Inspections Desk checks Walkthroughs Code Reviews Pair Programming

Chapter 6, Software Requirements

Use Cases Functional and Nonfunctional Requirements Software Requirements Specifications Change Control

Chapter 7, Design and Programming

Configuration Management Subversion Refactoring Unit Tests Project Automation Software

Chapter 8, Software Testing

Test Plans Test Cases Test Automation Defect Tracking System Postmortem Meetings Metrics

Most of these tools and techniques can be applied independently of one another. However, there are a few that rely on tools in other parts of the book. (For example, it is very difficult to build a test plan and test cases without a software requirements specification.) When this is the case, it is always because the software project will be better off with the other tool in place first, and the project will see a greater gain by implementing the other tool instead. Many of the practices in this book are described using a process script that contains step-by-step instructions to help guide the team through the practice. "Script" should bring to mind a script read by an actor, rather than a script run by a computer. All scripts follow the same format (which is based on the template used for use cases, defined in Chapter 6) that contains:

• A name, one-line description of the purpose, and a brief summary.
• A list of work products that are used in the script. Work products are labeled as "input" if they already exist and are used in the script; they are labeled as "output" if they are generated or updated by the script.
• Entry criteria that must be satisfied before the script can begin.
• A basic course of events, which consists of step-by-step instructions to lead the team through the script activities.
• Alternate paths that the team members may follow to deviate from the basic course of events.
• Exit criteria that should be satisfied when the script ends.

There's an old saying: "There's only one way to be right, but a million ways to be wrong." This is not necessarily the case with software projects! In practice, the vast majority of projects go wrong in one of a small number of ways. At the end of each chapter in Part I, there is a section aimed at helping you diagnose the symptoms in your organization in order to determine if that chapter's tools, techniques, and practices will help fix the specific problems. This section contains several scenarios that should describe the way this problem typically looks from the outside. The "Diagnosing" scenarios in the chapters in Part I describe these problems in a way that should seem very familiar to project managers suffering from them. If one of these scenarios seems eerily familiar to you, there is a good chance that the tools in its chapter will help.

Section 1.7: Part II: Using Project Management Effectively

It's not enough for a project manager to understand practices that are used by all of the team members. A good project manager also needs to know how to lead the team. The second part of this book is focused on learning how to use the five basic principles listed above in order to work with people, teams, and organizations. Each chapter in Part II takes on specific areas of project management:

Chpter 9, Understanding Change

Introducing practices, tools, and techniques to your organization's culture Avoiding the most common pitfalls in selling your ideas Planning for your changes and making them succeed

Chapter 10, Management and Leadership

Understanding responsibility, authority, and accountability Creating a culture of transparency in your organization Working with your organization and your team

Chapter 11, Managing an Outsourced Project

Preventing the most common sources of failure in outsourced projects Forming a relationship with the team and management at an outsourcing vendor Reviewing and collaborating between organizations

Chapter 12, Process Improvement

Understanding when process improvement is useful (and when it isn't) Utilizing process improvement models and certifications Working with third-party processes and methodologies

Our goal in writing this book is to help you build better software. If you implement all, some, or even one of these practices, we think you will see a noticeable improvement in the efficiency of your projects and that it will make your job easier. We have tried to make it clear throughout this book exactly why we think these things are important. We use them every day in our own work, and we hope you find them as helpful and satisfying as we do.