Page 29 -

Stakeholders
This is a bulleted list of the stakeholders. Each stakeholder may be referred to by name,
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 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.
Risks
This section lists any potential risks to the project. It should be generated by a project
team’s brainstorming session. It could include external factors that may impact the
project, or 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 doc-
ument 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 nontechnical assumptions should be copied into this section. (Tech-
nical 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 assump-
tions 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 accom-
plish. 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 pack-
age—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

SOFTWARE PROJECT PLANNING 21