By Andrew Stellman, Jennifer Greene
Book Price: $39.95 USD
£28.50 GBP
PDF Price: $31.99

Cover | Table of Contents

Table of Contents

Chapter 1: Introduction

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Tell Everyone the Truth All the Time

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Trust Your Team

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Review Everything, Test Everything

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

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!)

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

All Software Engineers Are Created Equal

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Doing the Project Right Is Most Efficient

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

: Tools and Techniques

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

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!

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

: Using Project Management Effectively

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

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:

Chapter 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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 2: Software Project Planning

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

An urgent need can be a good motivator. Software is usually built to address an urgent need. For the stakeholders—meaning everyone who has a concern or real interest in the success of the project—the fact that the need is urgent helps to convince the organization to dedicate time and energy to addressing it. For the software engineers, an urgent need means that their work will be appreciated and used in the foreseeable future. And for the management of the organization, it means that there is a clear direction in how they need to run things.

But urgency can also be the source of a project's most difficult problems. Urgency causes people to panic, and to potentially gloss over important parts of the project. People will rush into gathering requirements (or, even worse, rush into building the code!) without thoroughly understanding the needs of the people who want the software built.

If a project manager does not really understand the context in which the software is being built, then the only thing that the project team sees is the urgency; they lose track of the needs. They can see the individual problems that they are working to solve, but they may lose track of the big picture.

Unless the team understands the needs that drive the project, they may end up with a narrow focus, causing them to waste time addressing problems that are of little importance to the stakeholders. It's easy to build great software that solves the wrong problems, but the only way to build the appropriate software is for everyone in the project to understand and agree on both why and how that software will be built before the work begins. That's the purpose of project planning.

When a stakeholder does not feel that his needs are being met, he usually puts pressure on the project manager to provide an early version of the software, so that he can personally verify that the team really understands why the software is being built. This is a big source of communication failure between the people who need the software and the team members who are building it. When the stakeholder asks for an early version or a prototype of the software, he is usually asking for evidence that his needs are understood and being addressed. When programmers hear this request, however, they interpret it to mean that the person is interested in the details of what they are doing, and that he wants to be given a tour of the solution as it is being developed.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Understand the Project Needs

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

When a stakeholder does not feel that his needs are being met, he usually puts pressure on the project manager to provide an early version of the software, so that he can personally verify that the team really understands why the software is being built. This is a big source of communication failure between the people who need the software and the team members who are building it. When the stakeholder asks for an early version or a prototype of the software, he is usually asking for evidence that his needs are understood and being addressed. When programmers hear this request, however, they interpret it to mean that the person is interested in the details of what they are doing, and that he wants to be given a tour of the solution as it is being developed.

This may sound funny to some seasoned software engineers. Such a basic lack of communication couldn't really be that widespread...right? But most software professionals have had to sit through uncomfortable meetings where a designer or programmer gives a demo or walkthrough of all of the great work he did, only to be surprised that nobody seems to care.

The reason nontechnical people seem so bored in demos and walkthroughs is because they came to see confirmation that the technology team understands their needs. Instead, they got a lecture in software design, which they did not want. This situation can be frustrating for everyone involved: the software engineers feel unappreciated and condescended to, while the stakeholders feel like their needs are not being taken seriously.

A project that starts out like this is likely to experience scope creep, delays, and even outright failure. What's worse, nobody in the organization will really even understand why the project had so many problems. All they will see is a team that built software that didn't work properly and had to be repaired or even rewritten. This is a very bad situation for a software engineering team to end up in. Even when a team is technically proficient and capable of delivering high-quality, well-written software, when faced with a problematic project, most managers will intuitively feel that the team is incapable of delivering software without major quality problems.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Create the Project Plan

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The project plan defines the work that will be done on the project and who will do it. A typical project plan consists of:

• A statement of work that describes all work products (specifications, test plans, code, defect reports, and any other product of work performed over the course of the project) that will be produced and a list of people who will perform that work
• A resource list that contains a list of all resources that will be needed for the product, and their availability
• A work breakdown structure and a set of effort estimates (described in Chapter 3)
• A project schedule (described in Chapter 4)
• A risk plan that identifies any risks that might be encountered and indicates how those risks would be handled, should they occur

The project plan is used by many people in the organization. The project manager uses it to communicate the project's status to the stakeholders and senior managers, and to plan the team's activities. The team members use it to understand the context for the work they are doing. The senior managers use it to verify that the project's cost and schedule are reasonable and under control, and that the project is being done in an efficient and cost-effective manner. The stakeholders use it to make sure that the project is on track, and that their needs are being addressed.

It is important that the organization reach consensus on the project plan. To accomplish this, the plan should be inspected by the representatives of the project team, senior management, and stakeholders. Many project plans are stored simply as a folder containing a set of word processor and spreadsheet files, or are printed and stored in a binder. It is important that the project plan is periodically reviewed, and that any deviations from the plan are tracked at the review sessions. Frequent reviews are what can keep the plan from going stale and becoming a work of fiction.

It's difficult, if not impossible, to build a project plan without a vision and scope document. Without it, the actions that a project manager would have to take in order to create a project plan are almost identical to those required to create the vision and scope document. For this reason, the project manager should begin the planning process by first writing a vision and scope document; all other planning activities depend on it, and the time required for the project manager to create it will pay for itself when the project plan is created.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Diagnosing Project Planning Problems

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

If a project is not planned well, it will veer off course fairly quickly. If the project manager does not take the lead in defining the scope immediately, the project will quickly become chaotic. Even if the scope seems to be defined well, the project manager must make sure that all stakeholders really understand and agree to it in order to avoid problems later on in the project. The team must buy into the scope as well, or else they will make decisions that are not in line with the project goals.

It's not uncommon for people to intuitively feel that all they need for a project to be successful is a group of highly talented and motivated people. But even the best people will have trouble starting a project if nobody takes the lead.

One common problem that comes from a lack of leadership is tunnel vision. Each team member knows how to do her specific tasks; however, there's no way to plan for every detail of that task. She will almost certainly encounter decision points. For example, she may see a better way to solve a particular problem that will cost time but lead to a better solution. For some projects, it may be appropriate to pursue this; for others, the delivery schedule is more important than the superior solution.

Without good leadership, the team member might be afraid to make this decision. This usually results in the team member sending emails to peers, managers, stakeholders, and anyone else she can find, requesting confirmation of absolutely every little decision that gets made. People quickly get inundated with notes about project details that they lack the context to even understand.

On the other hand, she may also simply make decisions based on her gut feelings. As the project progresses, not all of her decisions are in line with the needs of the stakeholders. For example, she may choose to pursue the superior technical solution at the expense of the deadline, despite the fact that the stakeholders' needs would have been just as easily satisfied had she chosen the faster solution. As these decisions pile up throughout the course of the project, the scope itself starts to drift away from the organization's needs.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 3: Estimation

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Many people have referred to estimation as a "black art." This makes some intuitive sense: at first glance, it might seem that estimation is a highly subjective process. One person might take a day to do a task that might only require a few hours of another's time. As a result, when several people are asked to estimate how long it might take to perform a task, they will often give widely differing answers. But when the work is actually performed, it takes a real amount of time; any estimate that did not come close to that actual time is inaccurate.

To someone who has never estimated a project in a structured way, estimation seems little more than attempting to predict the future. This view is reinforced when off-the-cuff estimates are inaccurate and projects come in late. But a good formal estimation process, one that allows the project team to reach a consensus on the estimates, can improve the accuracy of those estimates, making it much more likely that projects will come in on time. A project manager can help the team to create successful estimates for any software project by using sound techniques and understanding what makes estimates more accurate.

A sound estimate starts with a work breakdown structure (WBS). A WBS is a list of tasks that, if completed, will produce the final product. The way the work is broken down dictates how it will be done. There are many ways to decompose a project into tasks. The project can be broken down by feature, by project phase (requirements tasks, design tasks, programming tasks, QA tasks, etc.), or by some combination of the two. Ideally, the WBS should reflect the way previous projects have been developed.

A useful rule of thumb is that any project can be broken down into between 10 and 20 tasks. For large projects (for example, a space shuttle), those tasks will be very large ("Test the guidance system"); for small projects (like writing a simple calculator program), the tasks are small ("Build the arithmetic object that adds, multiplies, or divides two numbers"). The team must take care in generating the WBS—if the tasks are incorrect, they can waste time going down a wrong path.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Elements of a Successful Estimate

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

A sound estimate starts with a work breakdown structure (WBS). A WBS is a list of tasks that, if completed, will produce the final product. The way the work is broken down dictates how it will be done. There are many ways to decompose a project into tasks. The project can be broken down by feature, by project phase (requirements tasks, design tasks, programming tasks, QA tasks, etc.), or by some combination of the two. Ideally, the WBS should reflect the way previous projects have been developed.

A useful rule of thumb is that any project can be broken down into between 10 and 20 tasks. For large projects (for example, a space shuttle), those tasks will be very large ("Test the guidance system"); for small projects (like writing a simple calculator program), the tasks are small ("Build the arithmetic object that adds, multiplies, or divides two numbers"). The team must take care in generating the WBS—if the tasks are incorrect, they can waste time going down a wrong path.

Once the WBS is created, the team must create an estimate of the effort required to perform each task. The most accurate estimates are those that rely on prior experience. Team members should review previous project results and find how long similar tasks in previous projects took to complete. Sources of delays in the past should be taken into account when making current estimates. Postmortem reports (see Chapter 8) are a good source of this information.

No estimate is guaranteed to be accurate. People get sick or leave the organization; teams run into unforeseen technical problems; the needs of the organization change. The unexpected will almost certainly happen. Therefore, the goal of estimation is not to predict the future. Instead, it is to gauge an honest, well-informed opinion of the effort required to do a task from those people in the organization who have the most applicable training and knowledge.

If two people widely disagree on how long a task will take, it's likely that the source of that disagreement is that each person made different assumptions about details of the work product or the strategy for producing it. In other words, any disagreement is generally about what is required to perform the task itself, not about the effort required to complete it. For example, given the same vision and scope document for a tool that sets the computer clock, two different developers might come up with wildly different estimates. But it might turn out that one developer assumed that the implementation would have a simple command-line interface, while the other assumed that there would be a complete user interface that had to integrate tightly with the operating system's control panel. By helping the programmers discuss these assumptions and come to a temporary resolution about their differences, the project manager can help them agree on a single estimate for the task.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Wideband Delphi Estimation

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The Wideband Delphi estimation method was developed in the 1940s at the Rand Corporation as a forecasting tool. It has since been adapted across many industries to estimate many kinds of tasks, ranging from statistical data collection results to sales and marketing forecasts. It has proven to be a very effective estimation tool, and it lends itself well to software projects.

The Wideband Delphi estimation process is especially useful to a project manager because it produces several important elements of the project plan. The most important product is the set of estimates upon which the project schedule is built. In addition, the project team creates a work breakdown structure (WBS), which is a critical element of the plan. The team also generates a list of assumptions, which can be added to the vision and scope document.

The discussion among the team during both the kickoff meeting and the estimation session is another important product of the Delphi process. This discussion typically uncovers many important (but previously unrecognized) project priorities, assumptions, and tasks. The team is much more familiar with the work they are about to undertake after they complete the Wideband Delphi process.

Wideband Delphi works because it requires the entire team to correct one another in a way that helps avoid errors and poor estimation. While software estimation is certainly a skill that improves with experience, the most common problem with estimates is simply that the person making the estimate does not fully understand what it is that he is estimating. He may be an experienced software engineer, but if he has not fully explored all of the assumptions behind the estimate, the estimate will be incorrect. Delphi addresses this problem through the discussion of assumptions and the generation of consensus among the estimation team members.

The Wideband Delphi process described here depends on a vision and scope document. It is possible to estimate a project without a vision and scope document, instead relying solely on the project team's understanding of the organization's needs. However, if there is no vision and scope document for the project, most project managers will find that writing one will improve the project far more than trying to estimate without it. (Chapter 2 describes how to develop a vision and scope document as part of the software project planning activities.)

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Other Estimation Techniques

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Wideband Delphi is not the only technique that can be effective in estimating software tasks. Here are a few popular and effective alternatives.

Proxy Based Estimating (PROBE), is the estimation method introduced by Watts Humphrey (of the Software Engineering Institute at Carnegie Mellon University) as part of the Personal Software Process (a discipline that helps individual software engineers monitor, test, and improve their own work). PROBE is based on the idea that if an engineer is building a component similar to one he built previously, then it will take about the same effort as it did in the past.

In the PROBE method, individual engineers use a database to keep track of the size and effort of all of the work that they do, developing a history of the effort they have put into their past projects, broken into individual components. Each component in the database is assigned a type ("calculation," "data," "logic," etc.) and a size (from "very small" to "very large"). When a new project must be estimated, it is broken down into tasks that correspond to these types and sizes. A formula based on linear regression is used to calculate the estimate for each task. Additional information on PROBE can be found in A Discipline for Software Engineering by Watts Humphrey (Addison Wesley, 1994).

The Constructive Cost Model (COCOMO) is a software cost and schedule estimating method developed by Barry Boehm in the early 1980s. Boehm developed COCOMO empirically by running a study of 63 software development projects and statistically analyzing their results. COCOMO II was developed in the 1990s as an updated version for modern development life cycles, and it is based on a broader set of data. The COCOMO calculation incorporates 15 cost drivers, variables that must be provided as input for a model that is based on the results of those studied projects. These variables cover software, computer, personnel, and project attributes. The output of the model is a set of size and effort estimates that can be developed into a project schedule. Additional information on COCOMO can be found in

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Diagnosing Estimation Problems

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Estimation problems almost always boil down to estimates that are either too high or too low. Padded estimates, where the team intentionally overestimates in order to give themselves extra time, are a chronic source of estimates that are too high. Senior managers giving unrealistic, overly aggressive deadlines are a chronic source of estimates that are too low. In both cases, this can lead to morale problems.

There is a basic tug-of-war going on here. Engineers prefer higher estimates, giving them as much time and as little pressure as possible to do their work. Managers prefer to deliver things more quickly, in order to please stakeholders. The only way for a project manager to avoid this conflict is to work with the team to produce estimates that are as accurate as possible. By adopting a sound estimation process that allows the team and the project manager to reach a consensus on the effort involved in the work, the morale is maintained and the work is much more predictable.

In some organizations, the project team drives the entire estimation process and the project manager simply builds a schedule around their estimates. This can be comfortable for the team, but it does not always work well for the organization, and it can eventually lead to an environment where the managers don't trust the programmers.

There are many reasons why estimates are wrong that have nothing to do with the work being done. Software engineers are often overoptimistic by nature—it's easy to be very positive about a project before doing any of the work, and it's easy to ignore problems that may come up later. It's very tempting to pad estimates, since they lead to longer schedules and less pressure.

The situation is especially bad when someone with no formal training in software engineering and little experience estimating software tasks is asked by her manager to give estimates. She is forced into a difficult situation: if her estimates come up short, she will be penalized at her next review. She could pad the estimates, but that would be dishonest. Her manager will eventually catch on and start cutting down any estimate she provides. Either of these options can lead to unreliable estimates that throw off the entire project planning process. She feels like she's left hanging with little support, and if her manager sees that her estimates are off, he could end up distrusting ones she makes in the future.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 4: Project Schedules

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The project schedule is the core of the project plan. It is used by the project manager to commit people to the project and show the organization how the work will be performed. Schedules are used to communicate final deadlines and, in some cases, to determine resource needs. They are also used as a kind of checklist to make sure that every task necessary is performed. If a task is on the schedule, the team is committed to doing it. In other words, the project schedule is the means by which the project manager brings the team and the project under control.

The project schedule is a calendar that links the tasks to be done with the resources that will do them. Before a project schedule can be created, the project manager must have a work breakdown structure (WBS), an effort estimate for each task, and a resource list with availability for each resource. If these are not yet available, it may be possible to create something that looks like a schedule, but it will essentially be a work of fiction. A project manager's time is better spent on working with the team to create a WBS and estimates (using a consensus-driven estimation method like Wideband Delphi—see Chapter 3) than on trying to build a project schedule without them. The reason for this is that a schedule itself is an estimate: each date in the schedule is estimated, and if those dates do not have the buy-in of the people who are going to do the work, the schedule will almost certainly be inaccurate.

There are many project scheduling software products that can do much of the tedious work of calculating the schedule automatically, and plenty of books and tutorials dedicated to teaching people how to use them. However, before a project manager can use these tools, he should understand the concepts behind the WBS, dependencies, resource allocation , critical paths, Gantt charts, and earned value. These are the real keys to planning a successful project.

The first step in building the project schedule is to identify the resources required to perform each of the tasks. A resource is any person, item, tool, or service that is needed by the project that is either scarce or has limited availability.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Building the Project Schedule

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The project schedule is a calendar that links the tasks to be done with the resources that will do them. Before a project schedule can be created, the project manager must have a work breakdown structure (WBS), an effort estimate for each task, and a resource list with availability for each resource. If these are not yet available, it may be possible to create something that looks like a schedule, but it will essentially be a work of fiction. A project manager's time is better spent on working with the team to create a WBS and estimates (using a consensus-driven estimation method like Wideband Delphi—see Chapter 3) than on trying to build a project schedule without them. The reason for this is that a schedule itself is an estimate: each date in the schedule is estimated, and if those dates do not have the buy-in of the people who are going to do the work, the schedule will almost certainly be inaccurate.

There are many project scheduling software products that can do much of the tedious work of calculating the schedule automatically, and plenty of books and tutorials dedicated to teaching people how to use them. However, before a project manager can use these tools, he should understand the concepts behind the WBS, dependencies, resource allocation , critical paths, Gantt charts, and earned value. These are the real keys to planning a successful project.

The first step in building the project schedule is to identify the resources required to perform each of the tasks. A resource is any person, item, tool, or service that is needed by the project that is either scarce or has limited availability.

Many project managers use the terms "resource" and "person" interchangeably, but people are only one kind of resource. The project could include computer resources (like shared computer room, mainframe, or server time), locations (training rooms, temporary office space), services (like time from contractors, trainers, or a support team), and special equipment that will be temporarily acquired for the project. Most project schedules only plan for human resources—the other kinds of resources are listed in the resource list, which is part of the project plan (see Chapter 2).

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Managing Multiple Projects

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Many project managers are responsible for multiple projects . If each project is planned well, managing a set of them should not be difficult. When projects don't share dependencies, managing them is straightforward—just manage each project individually, with a separate project schedule for each one.

When projects share dependencies, they are more challenging to manage. There are two ways that one project might depend on another. In the first type, two projects rely on the same resources; in the second type, a work product generated by one project is needed by the other. Getting a handle on these dependencies is the first important step in managing multiple projects.

The most common way for projects to be interdependent is through shared resources. One instance of this happening is "pipelined" projects. In many software organizations, software projects go through a set of sequential phases: requirements, design, development, programming, and testing. In each phase, most of the work is done by a small subset of the team, leaving the rest of the team available to work on other projects. To allow the team to work at full capacity, they might be working on several projects at once. Project A is in the requirements phase, while at the same time, project B is in design, project C is in development, and project D is being tested.

The trouble with this system is that no two projects take exactly the same time, and the phases don't always require the same percentage of the total effort. For example, programming is typically 30% to 40% of the total effort of a project. But during that time, a lead tester might be working on a test plan, while programmers might have to stop work for half a day to review the requirements or design documents on another project. When there are more than two or three projects being worked on simultaneously, things can get very chaotic.

Usually, a programmer is fully allocated to a programming task. This means that the programmer is spending all of his time on that task (minus lunch, bathroom breaks, etc.) But in other cases, a resource will be only partially allocated to a task. For example, a conference room may be a scarce resource; it might be reserved only in the morning, but free in the afternoon. Or a designer might work on two projects at once, meeting with stakeholders for one project in the morning while analyzing usability lab data for another in the afternoon.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Use the Schedule to Manage Commitments

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

A project schedule represents a commitment by the team to perform a set of tasks. When the project manager adds a task to the schedule and it's agreed upon by the team, the person who is assigned to that task now has a commitment to complete it by the task's due date. Senior managers feel that they can depend on the schedule as an accurate forecast of how the project is going to go—when the schedule slips, it's treated as an exception, and an explanation is required. For this reason, the schedule is a powerful tool for commitment management .

One common complaint among project managers attempting to improve the way their organizations build software is that the changes they make don't take root. Typically, the project manager will call a meeting to announce a new tool or technique—he may ask the team to start performing code reviews, for example—only to find that the team does not actually perform the reviews when building the software. Things that seem like a good idea in a meeting often fail to "stick" in practice.

This is where the schedule is a very valuable tool. By adding tasks to the schedule that represent the actual improvements that need to be made—for example, by scheduling all of the review meetings—the project manager has a much better chance of gaining a real commitment from the team.

If the team does not feel comfortable making a commitment to the new practice, the disagreement will come up during the schedule review. Typically, when a project team member disagrees with implementing a new tool or technique, he does not bring it up during the meeting where it's introduced. Instead, he will simply fail to use it, and build the software as he has on past projects. This is usually justified with an explanation that there isn't enough time, and that implementing the change will make the task late.

By explicitly adding a task to the schedule, the project manager ensures that enough time is built in to account for the change. This cements the change into the project plan, and makes it clear up front that the team is expected to adopt the practice. More importantly, it is a good consensus-building tool because it allows team members to bring up the new practice when they review the project plan. By putting the change out in the open, the project manager encourages real discussion of it, and is given a chance to explain the reason for the practice during the review meetings. If the practice makes it past the review, then the project manager ends up with a real commitment from the team to adopt the new practice.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Diagnosing Scheduling Problems

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

When a project manager doesn't create a schedule, the organization is given an unrealistic view of how the project will progress. When schedules are not correct, the project manager usually has to resort to drastic measures in order to try to bring the project in line with the organization's expectations, and those measures often don't work. Even when they do, they hurt the morale of the team, and they frequently hurt the quality of the software produced as well.

One of the most common problems that affects a project is that the deadline, which seemed perfectly reasonable when the project started, begins to seem completely unrealistic as the date starts getting closer. This is often caused by a project manager facing a deadline that cannot be changed. Usually, the date comes from marketing or customer relations needs. Instead of being based on estimates of actual effort from the team, expectations are based on agreements between project managers, senior managers, and stakeholders. (For example, a consulting company may take on an overly aggressive deadline in order to satisfy a client seen as important for the company's growth.)

When faced with a non-negotiable deadline for a project, many project managers will work backward from the deadline to determine what work needs to be performed. One misguided way of doing this is to divide the project into phases and assign each phase a certain percent of the schedule. The project manager may decide, for example, that programming should take 60% of the time, testing should take 25%, etc. These numbers don't come from any specific knowledge of the work required; rather, they come from the need to fit that work into a predetermined tomfooleries.

What results is deadline-driven work. If milestones look like they will be missed, key activities like reviews, inspections, and even testing are often abandoned in order to meet unrealistic expectations. The people working on the project are treated unfairly because they are asked to perform an impossible task. They may be told to work overtime or spend weekends in the office to make up for poor planning.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 5: Reviews

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

A review is any activity in which a work product is distributed to reviewers who examine it and give feedback. Different work products will go through different kinds of reviews: the team may do a very thorough, technical review of a software requirements specification, while the vision and scope document will be passed around via email and have higher-level walkthroughs. (This book was reviewed by a wide range of experts including seasoned project managers, university faculty, and business executives.) This chapter covers several kinds of reviews, each of which may be appropriate for different work products and at various points during the software project.

Reviews are useful not only for finding and eliminating defects, but also for gaining consensus among the project team, securing approval from stakeholders, and aiding in professional development for team members. In all cases, the work product coming out of the review has fewer defects than it had when it was submitted—even though the author thought it was "complete" before the review. Every defect that is found during a review is a defect that someone did not have to spend time tracking down later in the project.

There are many ways that a work product can be reviewed. Each kind of review is appropriate for different audiences or kinds of work product. The purpose of all reviews is to ensure that each reviewer is satisfied that the work product is correct, and that his or her perspective is represented.

The goal of every review is to save the project team time and effort. It's much easier to fix the problems on paper, before they cause software to be built incorrectly. An effective way to make sure defects are caught early is to schedule many reviews over the course of the project to catch the defects before they become deeply embedded in the software. By reviewing each work product before it is approved, a project manager sets those checkpoints and ensures that defects are caught early, before they are repeated in later work products.

An inspection is one of the most common sorts of review found in software projects. The goal of the inspection is for all of the inspectors to reach consensus on a work product and approve it for use in the project. Commonly inspected work products include software requirements specifications (see Chapter 6) and test plans (see Chapter 8). In an inspection, a work product is selected for review and a team is gathered for an inspection meeting to review the work product. A moderator is chosen to moderate the meeting. Each inspector prepares for the meeting by reading the work product and noting each defect. In an inspection, a defect is any part of the work product that will keep an inspector from approving it. For example, if the team is inspecting a software requirements specification, each defect will be text in the document that an inspector disagrees with. The goal of the inspection is to repair all of the defects so that everyone on the inspection team can approve the work product.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Inspections

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

An inspection is one of the most common sorts of review found in software projects. The goal of the inspection is for all of the inspectors to reach consensus on a work product and approve it for use in the project. Commonly inspected work products include software requirements specifications (see Chapter 6) and test plans (see Chapter 8). In an inspection, a work product is selected for review and a team is gathered for an inspection meeting to review the work product. A moderator is chosen to moderate the meeting. Each inspector prepares for the meeting by reading the work product and noting each defect. In an inspection, a defect is any part of the work product that will keep an inspector from approving it. For example, if the team is inspecting a software requirements specification, each defect will be text in the document that an inspector disagrees with. The goal of the inspection is to repair all of the defects so that everyone on the inspection team can approve the work product.

Most project managers have seen their projects get delayed because of scope creep and unnecessary work caused by changes that, had they been caught earlier, would have required much less work to fix. One of the most common complaints from project team members is that they would have built the software differently had they been given a better understanding of what was needed from the beginning. One important root cause of these problems is defects in work products that are not caught until long after those work products have been used as the basis for later project activities.

The most important reason to inspect documents is to prevent defects. If the team starts building software based on a vision and scope document that has a serious defect, eventually the entire project will have to stop and reverse course. This can be very expensive in both effort and morale, because the team will need to backtrack and revise the requirements, design, code, test plans, and other work products that they have already put a lot of effort into implementing. The same goes for defects that were caught in other work products—defects missed in a design specification, for example, will have to be corrected later after they have been coded. The longer a defect goes uncorrected, the more entrenched it is in other work products; the more entrenched it is, the more time and effort it will take to fix.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Deskchecks

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

A deskcheck is a simple review in which the author of a work product distributes it to one or more reviewers. In a deskcheck, the author sends a copy of the work product to selected project team members. The team members read it, and then write up defects and comments to send back to the author. Work products that are commonly reviewed using a deskcheck include vision and scope documents (see C