THE PROJECT

PLAN
CHAPTER 3
3.1 INTRODUCTION

The project plan (PP) is at the core of the planning function for the
project team, and is a blueprint for the work to be performed as well as the
proposal to the customer, if such a proposal is indeed required. The project
plan has seven essential elements:

 Needs, goals, objectives,  Schedule

and requirements  Organization, staffing,
 Task statements, and task responsibility
statement of work, and matrix
work breakdown structure  Budget
 Technical approach  Budget
 3.2 NEEDS, GOALS, OBJECTIVES, AND
REQUIREMENTS
This first part of a project plan can be divided into
two parts, the first consisting of needs, goals, and
objectives, and the second constituting the requirements.
Requirements are of two types, project and system, with
the latter being quite voluminous and usually a part of
the formal contract between the customer and the system
developer. Statements of needs, goals, and objectives
can be rather variable.
3.2.1 NEEDS

The Department of Defense (DoD) acquisition directive

states that three key aspects of acquisition management are:

 Translating operational needs into stable affordable

programs
 Acquiring quality products
 Organizing for efficiency and effectiveness
3.2.2 GOALS AND OBJECTIVES
Goals and objectives are usually short
declarative statements, with goals being rather
broad and objectives under each goal being
somewhat more specific, although some treat goals
and objectives in reverse order. They are often
established for programs in distinction to projects.
For this reason, they may not be a firm requirement
as part of a project plan.
 3.2.3 REQUIREMENTS
Project requirements refer to all the work to be
performed on the project. System requirements are
applicable to the ‘‘system’’ that is being addressed by
the project. To illustrate the difference, let us assume
that the project is to design, but not build, a new
‘‘subway’’ system for a city. That is, the project is
limited to design and does not include the construction
of any hardware or software for the system.
3.2.3 REQUIREMENTS
The project requirements, therefore, are limited to all the
work to be accomplished as part of the design process
only. This may include estimating the cost of the subway
system for each year during its entire life cycle.
However, the cost of the project itself, limited as it is to
the design phase, is clearly a subset of that total cost, and
is likely to be only a minor part of the life-cycle cost of
the subway system. The system requirements describe, at
increasing levels of detail, the full characteristics of the
subway system, from initial design to operations and
support.
3.3 TASK STATEMENTS, STATEMENT OF WORK
(SOW), AND WORK BREAKDOWN STRUCTURE
(WBS)
Task statements are usually part of the statement of work
(SOW) provided by the customer. Thus, these are used
interchangeably in this text. These statements are
normally accepted and reiterated by the system developer
in the program plan. Changing the customer’s SOW is
not a recommended action because it may turn into a
point of contention later in the process. Work breakdown
structures (WBSs) may or may not be part of the
customer’s definition of the work to be performed. When
it is provided by the customer, it almost always should be
accepted and used by the system developer.
 3.4 TECHNICAL APPROACH
The technical approach is a task-by-task description
of how the project team intends to execute the tasks
and subtasks in the SOW, from a technical perspective.
The technical approach is usually formulated, in detail,
in response to a request for proposal (RFP) if such an
RFP is a precursor to the project. In such a situation,
this technical approach can be abstracted and used in
this section of the project plan.
 3.5 SCHEDULE
A schedule is an expression of the tasks and activities to be
performed along a time line. Two main methods of describing a
schedule are in use today, namely, (1) a Gantt Chart and (2) a
program evaluation and review technique (PERT) Chart. Figures 3.2
and 3.3 show examples of these types of schedules. Both figures are
constructed for a hypothetical project of eight principal tasks that
involve selecting commercial-off-the-shelf (COTS) software for use
by a project team. Such software might be, for example, a project
management package or some other package (e.g., geographic
information system, executive information system) that would be
needed by a project team.
 3.6 ORGANIZATION, STAFFING, AND
TASK RESPONSIBILITY MATRIX (TRM)
The project organization can be simply the organization chart
supplemented by a short description of key roles and
responsibilities. Staffing refers to the next step of actually
assigning categories of personnel to the various project tasks. We
note that person-week totals by task and by category of personnel
are easily derived from the assignment of personnel types to the
tasks. As indicated previously, if a WBS is part of the project, and
the relationship between the tasks and the WBS has been
developed, then it is possible to also develop a profile of which
personnel are expected to execute the elements of the WBS.
3.7 BUDGET
A project budget is prepared by first
examining the direct labor costs. These costs are
incurred as a result of project personnel working
on the various tasks of the project.
3.8 RISK ANALYSIS
In order to avoid future difficulty, the project triumvirate, as a
minimum, should carry out a risk analysis, the results of which become
part of the project plan. This analysis attempts to focus on trouble spots
before the fact, developing risk-mitigation strategies prior to actual work
on project tasks.

In general, it can be said that there are four kinds of risk that the Project
Manager would be concerned with. These are

 Technical performance risk

 Schedule risk
 Cost risk
 Administrative risk
3.9 THE PROPOSAL
The Project Manager is often faced with the matter of writing a proposal in order
to have the opportunity to be awarded the project contract. In such a case, it is
recommended that the previous project plan be constructed, in rough form, as a
precursor to the actual proposal-writing process. Thus, the project plan becomes a
critical input to proposal preparation because it deals with most of the crucial
issues.

The format of the proposal is very often structured as follows:

 A technical proposal
 A cost proposal
 A management proposal