Page 28 -

good idea to go back to the stakeholders and build a new vision and scope document. This
is the project manager’s best chance at catching scope problems as early as possible. If the
project has started to go off track, the best way to repair the damage is to assess the current
needs of the stakeholders, and then to create a plan to change the software in order to
meet those needs.

Table 2-1 shows a typical outline for a vision and scope document. When talking to each
stakeholder, the project manager should direct the conversation so that all of the topics in
the vision and scope document are discussed. Typically, stakeholders will be happy to talk
about all of this. They know their own needs very well, they understand who will be using
the software, and they generally have many opinions about what features should go into
it. The project manager should take lots of notes during this conversation—enough so that
writing the vision and scope document is mostly a matter of transcribing those notes.
(Stakeholders will often appreciate lots of note-taking, because it shows that the project
manager is listening to them and taking what they say seriously.)

TABLE 2-1. Vision and scope document outline
1. Problem Statement
a. Project background
b. Stakeholders
c. Users
d. Risks
e. Assumptions
2. Vision of the Solution
a. Vision statement
b. List of features
c. Scope of phased release (optional)
d. Features that will not be developed
The outline itself provides a good guide for the discussion with each stakeholder. It can be
used as an agenda for the meetings that the project manager uses to gather the information
about stakeholder needs. It’s a common mistake for a project manager to approach the writ-
ing of a vision and scope document as little more than a bureaucratic exercise. The project

manager’s goal should be to learn what each user, stakeholder, and project team member
thinks about the software in order to develop a single, unified vision and ensure that every-
one shares that vision. He should treat the document as a tool to build consensus among the
stakeholders and project team members. In other words, the important part is the discussion
of the vision and scope; the document is simply a record of that discussion.

Project background
This section contains a summary of the problem that the project will solve. It should
provide a brief history of the problem and an explanation of how the organization justi-
fied 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.

20 CHAPTER TWO