Planning Guideline: Template
Project Development Plan
Project
Development Plan (PDP) Template
The document in this file is adapted from
the IEEE standards for Software Project Management Plans, 1058-1998, and from
the data requirements of ISO standard 12207 Software Life Cycle Processes.
This template is intended to be a guide
to begin the project development plan. The plan should be dynamic, changing
with the project changes, but keeping the overall development plan documented.
Items that are intended to stay in as
part of your document are in
bold; explanatory comments are in plain text. Italic
bold text is used where you might insert wording about your project. Simple
italic text is used for explanatory information that should be removed when the
template is used.
<organization>
<name
of program or project>
Project
Development Plan
<date>
<data
security notice>
<instructions
to reviewers, if appropriate>
Approvals Signature Block
|
Organization
Responsibility |
Signature |
Date |
|
Project
Manager |
|
|
|
User
Representative |
|
|
|
Project
Sponsor |
|
|
|
Software
Quality Assurance Leader |
|
|
|
User
Documentation Leader |
|
|
|
<etc.> |
|
|
<revision
information>
Table of
Contents
1.1 Purpose, Scope, and Objectives
1.2 Assumptions and Constraints
1.3 Project Deliverables
1.4 Schedule and Budget Summary
1.5 Evolution of the Plan
4.1 External Interfaces
4.2 Internal Structure
4.3 Roles and Responsibilities
5.1 Start-up Plan
5.2 Work Plan
5.3 Control Plan
5.4 Risk Management Plan
5.5 Closeout Plan
6.1 Process Model
6.2 Methods, Tools, and Techniques
6.3 Infrastructure Plan
6.4 Acceptance Plan
6.5 Deployment Plan
7.1 Configuration Management Plan
7.2 Product Testing and Reviews Plan
7.3 Documentation and Work Product Plan
7.4 Quality Assurance Plan
7.5 Project Reviews
7.6 Issue Management
7.7 Subcontract Management (Acquisition
Management) Plan
7.8 Process Improvement Plan
Briefly describe the scope and context of
the plan and the intended audience.
Provide an overview of the project.
Purpose, Scope, and Objectives
Describe the purpose, scope and
objectives of the project. Explain how they fit within a broader vision of any
overall program or product life cycle. Describe what is out of scope as well.
Describe the business or system needs being satisfied by the project. Provide a
reference to any requirements descriptions that drive this project.
Assumptions and Constraints
Describe assumptions on which the project
is based and any constraints being imposed in areas such as schedule, budget,
resources, products to be reused, technology to be employed, products to be
acquired, and interfaces to other products. Include system dependencies that
will affect this project. It may be useful to portray these in a table.
|
Assumptions and Constraints |
Impact to Plan if not True |
|
|
|
|
|
|
Table x.
Assumptions and Constraints
Project Deliverables
List the deliverables or services to be
provided by this project, or provide a reference to where such a list can be
found. Include delivery dates, delivery locations, and quantities, as
appropriate. It may be useful to portray these in a table.
|
Deliverables |
Date
Available |
|
|
|
|
|
|
Table x.
Key Project Deliverables
Schedule and Budget Summary
Provide a summary of the schedule and
budget, at the top level of the project work breakdown structure (or
equivalent). Include all aspects of the project, including support functions,
quality assurance, configuration management, and subcontracted work when
treating the schedule and budget.
Evolution of the Plan
Describe how this plan will be completed,
disseminated, and put under change control. Describe how both scheduled and
unscheduled updates will be handled.
Provide a list of all documents and other
sources of information referenced in the plan. Include for each the title,
report number, date, author, and publishing organization. Include a reference
for the authorizing document for this project, the Statement of Work or
Marketing Requirements or Charter or whatever that might be for the
organization.
Define(or provide references to the
definition of) all terms and acronyms required to properly interpret this plan.
|
Term |
Definition |
|
|
|
|
|
|
|
Acronym |
Meaning |
|
|
|
|
|
|
Table x.
Definitions and Acronyms
Describe the organization for the
project, using the sections that follow.
External Interfaces
Describe the administrative and
managerial interfaces between the project and the primary entities with which
it interacts. A table may be a useful way to represent this.
|
Organization |
Liaison/Interface |
|
Customer:
<name> |
<name> |
|
User
Documentation |
|
|
<etc> |
|
Table x.
Project Interfaces
Internal Structure
Describe the internal management
structure of the project, as well as how the project relates to the rest of the
organization. Include employees and contract staff that are managed as part of
this project.
It may be helpful to use charts to show
the lines of authority.
Figure x.
Organization Chart
Roles and Responsibilities
Identify and state responsibilities
assigned to each major role in the project, and identify the individuals who
are responsible for those functions and activities. A table of may be the best
way to depict these.
|
Role |
Responsibilities |
Person |
|
Project
Manager |
<definition> |
<name> |
|
Technical
Team Leader(s) |
<definition> |
<name> |
|
<etc.> |
<etc.> |
|
Table x.
Project Roles and Responsibilities
Describe the project management processes
for the project. The sections that appear here may evolve over the lifetime of
the project, and only a subset of them may be relevant; use elements
accordingly. If there are documented processes that the project team is
following, the plan may refer to the documented processes rather than reproduce
them as part of this plan.
Start-up Plan
Describe how the project effort, cost and
schedule will be estimated, including methods, tools, and techniques.
Describe how staffing will be done, along
with the expected level of staffing by phase of the project, types of skills
needed, and sources of staff (may be employees or contract personnel). Describe
how the staff will be organized and supervised here, or include it in the
section that describes the project internal structure (above).
For any resources needed in addition to
personnel, describe the plan for acquiring those resources (such as hardware,
facilities, service contracts, and software).
Describe any training that will be needed
by the project staff to conduct this project, in both technical and managerial
skills. Include a schedule for the training to be provided, number of people to
be trained, and how the training will be conducted.
Work Plan
Describe the work activities, schedule,
resources, and budget details for the project. Much of this content may be in
appendices that are maintained as living documents, supported by project
planning and tracking tools. Include at a minimum here a list of the key
elements in the project work breakdown structure and a description of those
activities. If the work breakdown is developed in elements other than
"work activities," adapt the descriptions here to conform to those
elements.
Work Activities
Specify (or refer to a location that
contains a list of) the work activities and their relationships, depicted in a
work breakdown structure. Decompose the structure to a low enough level to
facilitate sound estimating, tracking, and risk management. Work packages may
be built for some or each of the elements of the work breakdown structure,
detailing the approach, needed resources, duration, work products, acceptance
criteria, predecessors and successors.
Schedule Allocation
Specify (or refer to a location that
contains) the schedule for the project, showing sequencing and relationships
between activities, milestones, and any special constraints.
Resource Allocation
Identify (or refer to a location that
contains a description of) the resources associated with each of the major work
activities, as well as an overall summary of the resource loading for the
project.
Budget Allocation
Show (or refer to a location that
contains a description of) the budget allocated to each of the major work
activities. Use the organization’s standard cost categories
such as personnel costs, travel,
equipment, and administrative support.
Control Plan
Describe how the project will be
monitored and controlled, using the following areas.
Requirements Management
Describe the process to be used for
measuring, reporting, and controlling changes to the product requirements.
Describe the techniques to be used for configuration management of the
requirements, requirements traceabilty, impact analysis for proposed changes,
and approving changes (such as a Change Control Board).
Schedule Control
Describe how progress will be monitored
and controlled. Address how the schedule will be controlled (milestones,
progress to plan on activities, corrective action upon serious deviation from
the plan), when reporting will be done for both the project team and
management, and what tools and methods will be used.
Budget Control
Describe how performance to budget will
be monitored and controlled. Address how the actual cost will be tracked to the
budgeted cost, how corrective actions will be implemented, at what intervals
cost reporting will be done for both the project team and management, and what
tools and techniques will be used. Include all costs of the project, including
contract labor and support functions.
Quality Control
Describe the mechanisms that will be used
to measure and control the quality of the work processes and resulting work
products. Mechanisms used may include quality assurance of the processes,
verification and validation of the work products, joint reviews, audits, and
process assessments. [These may be described in detail in other plans or in the
Supporting Process Plans of this document.]
Reporting and Communication Plan
Describe the mechanisms, formats,
frequencies, and information flows to be used for communicating status of the
project work, progress of the project, and other information as needed by the
project. A table may be useful to illustrate these.
|
Information |
Frequency
Sent |
From
Whom |
To
Whom |
Medium |
|
|
|
|
|
|
|
|
|
|
|
|
|
Communication |
From |
To |
Time Period |
|
|
|
|
|
|
|
|
|
|
Table x.
Reporting and Communication Plan (alternate forms)
Measurement Plan
Describe how the project measures will be
selected (may be a project team effort, based on key issues faced by the
project; may be set by external requirements; may be organization standards).
Describe how the measures will be collected, analyzed, reported, and used.
Include any performance measures that will be used to assess the business
impact of this project, including the gathering or development of current
baseline values.
Risk Management Plan
Describe the process that will be used to
identify, analyze, build mitigation and contingency plans, and manage the risks
associated with the project. Describe mechanisms for tracking the specific
risks, the mitigation plans, and any contingency plans. Risk factors that
should be considered when identifying the specific project risks include
contractual risks, organization-related risks, technological risks, risks due
to size and complexity of the product, risks in personnel acquisition and
retention, risks in achieving customer acceptance of the product, and others
specific to the context of the project.
The specific risks for this project, the
mitigation actions, and the contingency plans are likely to be documented in
another document that is a living record of the current risk information.
Closeout Plan
Describe the plan for closing out this
project. Include descriptions of how staff will be reassigned, project
materials archived, and how post-project analysis will gather and document
lessons learned and analysis of project objectives achieved. Include an
examination of the initial cost/benefit analysis to see if objectives have been
met; examine any performance measures intended to be impacted by the project.
Include knowledge transfer plan.
If this project is to be followed by a
next release effort, operations and maintenance, or other transition plan,
describe how those efforts will be planned.
Describe the processes and approaches to
be used for developing the work products or services for the project. The
primary technical focus of the project may be one or more of the following:
- acquisition – obtaining a system, product or service
- supply – providing a system, product, or service
- development – constructing a system or product
- operation – running a system or service for regular use
- maintenance – correcting, perfecting, or adapting a
system
Process Model
Specify the life cycle model to be used
for this project or refer to an organizational standard model that will be
followed. The process model includes roles, activities, entry criteria and exit
criteria, milestones, baselines, major deliverables, and reviews for the
project. It should include phases of project initiation and project
termination. If the project is tailoring an organization’s standard life-cycle
model, that tailoring should be described here.
Methods, Tools, and Techniques
Identify the computing system(s),
development method(s), standards, policies, procedures, team structure(s),
programming language(s), and other notations, tools, techniques, and methods to
be used to develop the work products or services for the project. Include the
key elements used to specify, design, build, test, integrate, document,
deliver, modify, operate or maintain the project deliverables or services.
Infrastructure Plan
Describe the plan for establishing and
maintaining the project work environment (hardware, software, facilities), as
well as any policies, procedures, and standards needed for the project.
Acceptance Plan
Describe (or refer to a separate document
that provides) the plan for acceptance of the project deliverables by the
customer or acquirer of the product. Include the objective criteria to be used
for acceptance. Describe roles and responsibilities for reviewing the plan,
generating the acceptance tests, running the tests, and reviewing results.
Describe the final approval process for product acceptance.
Deployment Plan
Describe (or refer to a separate document
that provides) the plan for releasing and installing the project deliverables
or deploying them to the acquirer or customer site. The plan may need to
include hardware installation, telecommunications or database infrastructure
preparation, and other information, as well as describing the means of
distributing the software.
Describe (or refer to a separate document
that provides) the plan for operating and maintaining the system after
deployment.
If this project develops a product that
is packaged and shipped to customers for their installation, describe how the
product will be prepared for release and shipment.
Provide plans for the supporting
processes here, or refer to the appropriate plans and where they can be found.
In some cases, the organization’s standard processes can provide the majority
of the information and need not be reproduced in a plan.
Configuration Management Plan
Describe (or refer to the description of)
the processes, methods, and tools that will be used for configuration
management. Include these areas, where applicable: configuration
identification, change control, auditing of configurations and configuration
items, reporting of status, setting up and controlling the software libraries,
and release management. Change control processes should support reporting,
review, approval, and tracking of change requests for product requirements
changes, work product defects, and project process changes.
Product Testing and Reviews Plan
Describe (or refer to the description of)
the processes, techniques, and tools that will be used for verification and
validation of the work products and activities. Identify which work products
will receive what types of peer reviews (such as inspection, walkthroughs, and
technical reviews) and what roles will participate in such reviews. Identify
the types of testing that will be done throughout the life cycle, and which
roles will be involved in each (such as unit testing, module testing,
integration testing, system testing, and acceptance testing). For each type of
testing, describe who will plan the tests, review the plans, develop the tests,
test the product, and review the test results.
Documentation and Work Product Plan
Describe (or refer to the description of)
the processes, techniques, and tools that will be used for generating the
deliverable and non-deliverable work products for the project.
Documents often found useful to perform
the technical processes for developing software that satisfies the requirements
include the following:
- User Requirements Specification – description of the
problems to be solved, user needs to be served, in the words of the user
- Software Requirements Specification – detailed
technical descriptions of the product requirements, addressing
functionality, quality attributes, interfaces, design constraints, and
other information helpful to product design
- Design Documentation – descriptions of major components
of the product design, including architecture, process design, user
interfaces, database design, and internal interface design
- Test Documentation – test plans, test procedures, and
test cases at all relevant levels of testing (unit, module, integration,
system, acceptance, alpha, beta)
Include the product deliverables
described earlier in this plan, as well as the various supporting plans and
other documentation used by the project team to conduct the project. A table
may be useful for showing this information.
|
Work
Product |
Relevant
Template or Standard |
Prepared
By |
Reviewed
By |
Distributed
To |
|
|
|
|
|
|
|
|
|
|
|
|
Table x.
Documentation and Work Product Plan
Quality Assurance Plan
Describe (or refer to the description of)
the processes, techniques, and tools that will be used for assuring that the
project meets its commitments to plans, standards, and processes, and that it
demonstrates that the products meet the agreed-to requirements. Include in this
description any reviews and audits in support of quality assurance, as well as
what roles are performing those. Identify the processes and standards that will
be followed by the project, both internal to the organization and any industry
or regulatory standards that apply.
Project Reviews
Describe the planned schedule for
conducting project reviews, who is to be involved, and what procedures will be
used for preparing and conducting the reviews. Include reviews that are done
for the project team only, for local management, and for any external
organizations, such as an acquirer or subcontractor.
Issue Management
Describe the resources, methods, and
tools to be used for reporting, analyzing, prioritizing, and handling project
issues. Issues may include problems with staffing or managing the project, new
risks that are detected, missing information, defects in work products, and
other problems. Describe how the issues will be tracked and managed to closure.
Note: Work product defects in baselined work products should be handled by the
configuration management change control process.
Subcontract Management (Acquisition
Management) Plan
Describe (or refer to the description of)
the processes, techniques, and tools that will be used for managing any
subcontracted product for this project. Include in that description the
approaches for defining the work, selecting a subcontractor, developing and
negotiating a contract, monitoring the subcontractor, accepting the
subcontracted product, and transitioning the subcontracted product into use.
Include the life cycle support functions for monitoring supplier quality
assurance, monitoring supplier configuration management, verification and
validation, joint reviews, problem resolution, and audits.
Where work being subcontracted is under
the management and processes of the project’s organization, that work should be
described within the standard flow of the project plan. Management of contract
personnel should be described in the section on staffing in the Startup Plan
section of this plan.
Process Improvement Plan
Describe the activities that will be done
to periodically assess the project’s processes, identify areas for improvement,
and implement improvement plans. If this project carries a responsibility for
defining, testing, or using some new organization process, describe how that is
incorporated into the project’s work. If this project is responsible for
showing the impact to the business of using some new process, describe how that
is included in the project’s measurement plan.
If there are any other plans required by
this project, include them here.
Change History
|
Revision |
Release
Date |
Description
[list of changed pages and reason for change] |
|
|
|
|
|
|
|
|
Document Storage
This document was created using <>
The file is stored <file location>.
Document Owner
<> is responsible for developing
and maintaining this document.
Include any relevant appendices.