The project plan is used by many people in the organization. The
project manager uses it to communicate the project’s status to the
stakeholders and senior managers, and to plan the team’s activities.
The team members use it to understand the context for the work they are
doing. The senior managers use it to verify that the project’s cost and
schedule are reasonable and under control, and that the project is
being done in an efficient and costeffective manner. The stakeholders
use it to make sure that the project is on track, and that their needs
are being addressed.
Project Plan
The project plan defines the work that will be done on the project and who will do it. A typical project plan consists of:
- A statement of work
(SOW) that describes all work products (specifications, test plans,
code, defect reports and any other product of work performed over the
course of the project) that will be produced and a list of people who
will perform that work
- A resource list that
contains a list of all resources that will be needed for the product
and their availability
- A work breakdown structure (WBS) and a set of effort estimates
- A risk plan that
identifies any risks that might be encountered and indicates how those
risks would be handled should they occur
Statement of Work
The SOW is included as part of the project plan, but it should 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
features should be divided into those phases as well.
- A description of the
intermediate deliverable or work product that will be built.
- The estimated effort
involved for each work product to be delivered (possibly based on the
results of the Wideband Delphi estimation session), if known.
Resource List
The project plan should contain a list of all resources that will be
used on the project. This list should go beyond what’s covered by the
project schedule by including a description of each resource, as well
as any limits on that resource’s availability.
Most project management software packages provide a feature to maintain
a resource list. If this is not available, the resource list can either
be a spreadsheet or a word processor document containing a simple list,
with one line per resource. The list should give each resource a name,
a brief one-line description, and list the availability and cost (if
applicable) of the resource. All resources should be handled in the
same way, regardless of type.
Estimates and Project Schedule
Once the statement of work and the resource list have been created, the
project manager should build a project schedule. This is usually done
in several steps:
- A work breakdown
structure (WBS) is defined. This is a list of tasks which, if
performed, will generate all of the work products needed to build the
software.
-
estimate of the effort required for each task in the WBS is generated.
- A project schedule is
created by assigning resources and determining the calendar time
required for each task.
The project plan should include the complete revision history of the
WBS—it should contain a list of any tasks that are added, changed or
removed, and when those changes occurred. It should also include
estimates and project schedule, including any revisions that were made
during the review meetings. (Chapter 3 contains a repeatable process
for generating a WBS and estimates. Chapter 4 describes how to create a
project schedule.)
Risk Plan
A
risk plan is a list of all risks that threaten the project, along
with a plan to mitigate some or all of those risks. Some people say
that uncertainty is the enemy of planning. If there were no
uncertainty, then every project plan would be accurate and every
project would go off without a hitch. Unfortunately, real life
intervenes, usually at the most inconvenient times. The risk plan is an
insurance policy against uncertainty.
|
