Quick-Kill Project Management

Vision and Scope Document: Up To 6 Hours

If a team doesn't really understand the context in which the software is being built, they're more likely to make bad decisions over the course of the project. These bad decisions cost the team valuable time to correct—or, if left uncorrected, cost the team goodwill with users when the project doesn't meet their needs. Without a good understanding of the real scope of the project, the only thing that the team sees is the urgency, and they lose track of the needs they're trying to fill. Programmers can see the individual problems that they are working to solve, but lose track of the big picture. And this is the single biggest source of delays and project failure.

Luckily, there is a straightforward and easy-to-implement practice that can help the team avoid these problems. Writing a vision and scope document takes less than a day, and helps the team avoid weeks of rework and false starts.

The first step in writing a vision and scope document is to talk to project stakeholders. Unfortunately, it's not always immediately obvious who those stakeholders are. The lead should find the people who will be most impacted by the project, either because he plans on using it or because he is somehow responsible for it being developed. In other words, the lead needs to find the people who will be in trouble if the software is not developed. Stakeholders are generally happy to talk about what they need. This is exactly what the lead developer—and other team members, if possible—should do with them. Gathering those needs should take less than an hour per stakeholder.

The vision and scope document (see Table 1) should be brief, no more than a couple of pages. All of the information the team gathers by talking to the stakeholders should be added to the Problem Statement section.

The Project Background section is a summary of the problem that the project solves. It should provide a brief history of the problem and an explanation of how the organization justified the decision to build software to address it. This section should cover the reasons why the problem exists, the organization's history with this problem, any previous projects that were undertaken to try to address it, and the way that the decision to begin this project was reached.

The Stakeholders section is a bulleted list of the stakeholders. Each stakeholder may be referred to by name, title, or role ("support group manager," "SCTO," "senior manager"). The needs of each stakeholder are described in a few sentences. The Users section is similar, containing a bulleted list of the users. As with the stakeholders, each user can either be referred to by name or role ("support rep," "call quality auditor," "home web site user"); however, if there are many users, it is usually inefficient to try to name each one. The needs of each user are described.

The needs of the users and stakeholders are the most important part of this document. 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.

The "vision" part of the vision and scope document refers to a description of the goal of the software. All software is built to fulfill needs of certain users and stakeholders. The team must identify those needs and write down a Vision Statement (a general statement describing how those needs will be filled). The goal of the Vision Statement section is to describe what the project is expected to accomplish. It should explain the purpose of the projects. This should be a compelling reason, a solid justification for spending time, money, and resources on the project.

The List of Features and Features That Will Not Be Developed sections contain a concise list of exactly what will and won't be built. Before writing these sections, the team should write the rest of the document and have an open discussion of the needs that they are trying to fill. Every single feature in each list should be built to address a specific need listed in the Problem Statement section. Often the team comes up with a feature that seems obvious, but that turns out not to really address a need. Features like this should be described in the Features That Will Not Be Developed section.