Page 32 -

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 man-
agement, 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.
Statement of Work

The first component of the project plan is a statement of work (SOW). This is a detailed
description of all of the work products that will be created over the course of the project,
including who is responsible for creating each work product. The description of each work
product should contain a reference to any tasks in the project schedule (see Chapter 4) in
which it is involved. The vision and scope document is a useful starting point for the SOW.
But the SOW serves a different purpose—while the vision and scope document talks about
the rationale for the project (the needs that must be met, the list of users and stakeholders
who need it built, etc.) the SOW simply contains a detailed list of the work that must be
done and all of the work products that will be produced.

The SOW is included as part of the project plan, but it should be a separate document that
can stand on its own. It should contain each of the following:
• The list of features being developed. If the software is being released in phases, the fea-

tures should be divided into those phases as well.
• A description of the intermediate deliverable or work product that will be built. This is a
list that covers (but is not limited to): software requirements specifications, design and
architecture specifications, class or UML diagrams, code or software packages (divided
into separate libraries or modules, if necessary), test plans and test cases, user accep-
tance plans, and any other document, source code or other work product that will be
created. A brief description—no more than a paragraph—is usually sufficient for each
one. The SOW also should list any standards or templates that will be used to create the
work product.
• The estimated effort involved for each work product to be delivered (possibly based on
the results of the Wideband Delphi estimation session), if known.

24 CHAPTER TWO