Home  Software Project Planning Practices Vision and Scope Document
|
|
|
Library
|
When the project begins, the project manager has a unique role to play.
The start of the project is the time when the scope of the project is
defined; only the project manager is equipped to make sure that it’s
defined properly. Everyone else has a role to play later on: users and
stakeholders will provide expertise, requirements analysts will write
specifications, programmers will build the code, etc. Everyone involved
in the project has some input into the scope, but only the project
manager is solely dedicated to it. Defining the scope is the most
productive thing a project manager can do to get the project underway.
The Vision and Scope document is the project manager's tool for doing
that.
Vision and Scope Document
The vision and scope document is one of the most important tools that a
project manager has; it is also one of the easiest to implement. A good
vision and scope document will help a project avoid some of the
costliest problems that a project can face. By writing the document and
circulating it among everyone involved in the project, the project
manager can ensure that each of the stakeholders and engineers share a
common understanding of the needs being addressed—and that the software
must address them.
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
|
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 justified the decision to build
software to address it. This section should cover the reasons that the
problem exists, the organization’s history with this problem, any
previous projects which were undertaken to try to address it, and the
way that the decision to begin this project was reached.
Stakeholders
This is a bulleted list of the stakeholders. Each stakeholder may be
referred to by name or by title or role (“support group manager”,
“CTO”, “senior manager”). The needs of each stakeholder are described
in a few sentences.
Users
This is 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 website user”)—however, if there are many
users, it is usually inefficient to try to name each one. The needs of
each user are described.
Risks
This section lists any potential risks to the project (see Figure 2-1
for examples). It should be generated by a project team’s brainstorming
session. It could include external factors that could impact the
project, issues or problems that could potentially cause project delays
or raise issues. (The process for assessing and mitigating risk below
can be used to generate the risks for this section.)
Assumptions
This is the list of assumptions that the stakeholders, users or project
team have made. Often, these assumptions are generated during a
Wideband Delphi estimation session (see Chapter 3). If Wideband Delphi
is being used, the rest of the vision and scope document should be
ready before the Delphi meeting and used as the basis for estimation.
The assumptions generated during the estimation kickoff meeting should
then be reviewed, and any non-technical assumptions should be copied
into this section. (Technical assumptions—meaning assumptions that
affect the design and development but not the scope of the
project—should not be included in this document. The estimate results
will still contain a record of these assumptions, but they are not
useful for this particular audience.)
If Wideband Delphi is not being used to generate the assumptions, the
project manager should hold a brainstorming session with the team to
come up with a list of assumptions instead. (See Chapter 3 for more
information on assumptions.)
Vision statement
The goal of the vision statement is to describe what the project is
expected to accomplish. It should explain what the purpose of the
project is. This should be a compelling reason, a solid justification
for spending time, money and resources on the project. The best time to
write the vision statement is after talking to the stakeholders and
users and writing down their needs; by this time, a concrete
understanding of the project should be starting to jell.
List of features
This section contains a list of features. A feature is as a cohesive
area of the software that fulfills a specific need by providing a set
of services or capabilities. Any software package—in fact, any
engineered product—can be broken down into features. The project
manager can choose the number of features in the vision and scope
document by changing the level of detail or granularity of each
feature, and by combining multiple features into a single one.
Sometimes those features are small (“screw-top cap”, “holds one liter
of liquid”); sometimes they are big (“four wheel drive”, “seats seven
passengers”). It is useful to describe a product in about ten features
in the vision and scope document, because this usually yields a level
of complexity that most people reading it are comfortable with. Adding
too many features will overwhelm most readers, and each extra feature
adds time and effort to the project and makes it difficult or
unrealistic to accomplish.
Each feature should be listed in a separate paragraph or bullet point.
It should be given a name, followed by a description of the
functionality that it provides. This description does not need to be
detailed; it can simply be a few sentences that give a general
explanation of the feature. However, if there is more information that
a stakeholder or project team member feels should be included, it is
important to include that information. For example, it is sometimes
useful to include a use case in a specific feature (see Chapter 6), as
long as it is written in such a way that all of the stakeholders can
read and understand it.
Scope of phased release (Optional)
Sometimes software projects are released in phases: a version of the
software with some subset of the features is released first, and a
newer, more complete version is released later. This section describes
the plan for a phased release, if that approach is to be taken.
This is useful when there is an important deadline for the software,
but developing the entire software project by that deadline would be
unrealistic. The most common way to compromise on this release date is
to divide the features into two or more releases. In that case, this
section should identify specifically when those versions will be
released, and which features will be included in each version. It’s
reasonable to divide one feature up between two releases, as long as it
is made clear exactly how that will happen.
If a project manager needs to release a project in phases, it is
critical that the project team be consulted. Some features are much
more difficult to divide than others, and the engineers might see
dependencies between features that are not clear to the stakeholders
and project manager. After the phased release plan is written down and
agreed upon, the project team should always be asked to re-estimate the
effort and a new project plan should be generated (see below). This
will ensure that the phased release is feasible and compatible with the
company’s priorities.
Features that will not be developed
Features are often left out of a project on purpose. When a feature is
explicitly left out of the software, it should be added to this section
to tell the reader that a decision was made to exclude it. For example,
one way to handle an unrealistic deadline is by removing one or more
features from the software, in which case the removed features should
be moved into this section. The reason these features should be moved
rather than deleted from the document is that otherwise readers might
assume that they were overlooked and bring the up in a review. This is
especially important during the review of the document because it
allows everyone to agree on the exclusion of the feature (or object to
it).
|
|
|
|
