**UNITED STATES DEPARTMENT OF AGRICULTURE**

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Office of the Chief Information Officer\
**

![](media/image1.png){width="2.0548611111111112in"
height="1.4166666666666667in"}

Project Management Handbook Appendices

Version 1.0

TABLE OF CONTENTS

[Project Charter Template](#project-charter-template)

[Scope Statement Template](#scope-statement-template)

[Project Management Plan Template](#project-management-plan-template)

[Cost Management Plan Template](#cost-management-plan-template)

[Earned Value Management
Definitions](#earned-value-management-definitions)

[Scope Management Plan Template](#scope-management-plan-template)

[Work Breakdown Structure Example](#work-breakdown-structure-example)

[Quality Management Plan Template](#quality-management-plan-template)

[Project Communications Plan
Template](#project-communications-plan-template)

[Change Management Plan Template](#change-management-plan-template)

[Risk Management Plan Template](#risk-management-plan-template)

[Risk Control Form Template](#risk-control-form-template)

[Risk Management Log Template](#risk-management-log-template)

[Staffing Management Plan Template](#staffing-management-plan-template)

[Procurement Management Plan
Template](#procurement-management-plan-template)

[Project Closeout Report Template](#project-closeout-report-template)

# Project Charter Template

  ---------------------------------------------------- ---------------------------------------------
  ![](media/image1.png){width="2.0548611111111112in"   **Project Charter**
  height="1.4166666666666667in"}                       

                                                       Project Name:

                                                       Date:

                                                       Point of Contact:

                                                       

                                                       
  ---------------------------------------------------- ---------------------------------------------

The following are suggested sections for the Project Charter

Approvals

The signatures of the people below relay an understanding in the purpose
and content of this document by those signing it. By signing this
document you agree to this as the formal Charter statement sanctioning
work to begin on the project described within.

  ---------------- ---------------------- --------------- ------------------
  Position/Title   Name                   Date            Phone Number

                                                          

                                                          

                                                          
  ---------------- ---------------------- --------------- ------------------

Purpose

Describe the purpose of the Project charter using the following
guidelines. Do not merely describe the content of the plan, but explain
why a Charter is necessary for the project

The purpose of the (XYZ) project charter is to communicate the
authorization for the project and the management approach to project
participants and external entities. The project charter lays the
groundwork for informed decisions and planning regarding projection
direction, outcomes and delivery.

Project Objective

Define the objectives of the project as they relate to the goals and
objectives of the organization along the following guidelines

The \[Project\] will support the following \[Organization\] strategic
goals. For each goal, \[Project\] objectives are identified. The project
plan developed as a result of this project charter will:

-   Develop a project performance measurement plan to measure
    performance against these objectives.

-   Provide a project performance report to report the results.

The \[external oversight committee\] must approve the project
performance measurement plan.

  ----------------------------------- -----------------------------------
  Organization Strategic Goals        Project Objectives

                                      

                                      

                                      

                                      

                                      
  ----------------------------------- -----------------------------------

Summary Scope Statement

The level of detail in this section must be sufficient to allow for
detailed scope development in the Project Plan. The Project Manager will
develop a more detailed description of the project scope.

Project Authority

Describe the authority of the individual or organization initiating the
project, limitations or initial checkpoint of the authorization,
management oversight over the project, and the authority of the Project
Manager. Also, ensure that the project initiator has the authority to
commit the appropriate resources within the organization.

Project Manager

Explicitly name the Project Manager and define his/her role and
responsibility over the project. Also list the Project Manager's skill
sets, and justify their selection for this project. Depending on the
project complexities, this section may describe how the Project Manager
will control matrixed organizations and employees.

Project Oversight

Describe department management control over the project. Within the
project, internal control should be established to control the
day-to-day activities of the project. The Project Manager should manage
internal control. External oversight should be established to ensure
that the organization's resources are applied to meet the project and
organization's objectives. Describe or reference a process by which
internal and external controls interact. Diagrams should be used where
appropriate.

Roles and Responsibilities

Discuss the overall structure of the project organization and its roles
and responsibilities throughout the project phases. Include the roles of
identified project stakeholders

Project Constraints

List and describe any identified project constraints. Typically,
constraints will impact timing, cost, resources and/or quality.

Project Assumptions

List and describe any identified assumptions. Assumptions pose a risk to
the project and will need further evaluation and validation during
subsequent project process phases.

Preliminary Schedule and Cost Estimates

Provide a rough estimate of dates to accomplish key project tasks.
Consider any constraints and assumptions prepared above when considering
the preliminary timing. Describe key management checkpoints established
by the initiating authority. Similarly, provide a rough order of
magnitude estimate of project costs.

  --------------------------- -------------------------------------------
  Management Checkpoint       Evaluation Criteria

                              

                              
  --------------------------- -------------------------------------------

RECORD OF AMENDMENTS

  --------- ------------------ --------- -----------------------------------
  Version   Author             Date      Comments

  1.0                          7/25/05   Draft 1. Based on template created
                                         for project charter

                                         

                                         

                                         

                                         

                                         

                                         
  --------- ------------------ --------- -----------------------------------

# Scope Statement Template

  ---------------------------------------------------- ---------------------------------------------
  ![](media/image1.png){width="2.0548611111111112in"   **Scope Statement**
  height="1.4166666666666667in"}                       

                                                       Project Name:

                                                       Date: DD Mmmm 20yy

                                                       Project Manager:

                                                       Approver: signature

                                                       Approver Name and Title
  ---------------------------------------------------- ---------------------------------------------

Purpose of Scope Statement

Describe the purpose of the scope statement using the following
guidelines:

The Scope Statement is distributed to all the project stakeholders for
their approval. It documents a description of the project, including the
objectives, planned deliverables, and requirements. It becomes the
baseline document that can only be changed through the process outlined
in the Scope Management Plan.

The Scope Statement documents a description of the project, including
the objectives, planned deliverables, and requirements. It becomes the
baseline document that can only be changed through the process outlined
in the Scope Management Plan.

Project Business Need

Provide the justification in terms of the problems the project will
address and/or the improvements it will implement. The business need
impacts the ability to assess project alternatives.

Project History

Provide a short narrative of the events that lead up to project
approval. This helps to put the project description into context and
supports the rest of the document.

Project Description/ Objectives

Describe the project in terms of strategy, timing, objectives and
deliverables.

Project Product Requirements

Provide a description of the project's product or service, its use,
technical parameters, requirements, etc.

Project Deliverables

Provide the stakeholders a list of the project deliverables.

Project Assumptions and Constraints

Assumptions describe details that are considered to be true or certain
that impact the success of the project. Examples would be available
critical personnel or funding. Constraints describe factors the impact
the project such as: budget limitations, organizational policies,
statutes or regulations.

Assumptions

-   

Constraints

-   

Quality Assurance Manager Activities

Generally describe the activities of the QA manager as they relate to
specific deliverables. What will the QA manager do to supplement the
testing and acceptance process?

Signature Page

The Scope Statement is distributed to all the project stakeholders for
their approval. Signature blocks should be provided for the project
sponsor, the project manager and the primary resource managers from
organizations such as project users, system owner, procurement, human
resources, finance, enterprise architecture and others as appropriate.

RECORD OF AMENDMENTS

  --------- -- ------------------ ---------- --------- ----------------------------------
  Version      Author                        Date      Comments

  1.0                             07/25/05             Draft 1 -- Based on template
                                                       created for VA IT scope statements

                                                       

                                                       

                                                       

                                                       

                                                       

                                                       
  --------- -- ------------------ ---------- --------- ----------------------------------

# Project Management Plan Template

  ---------------------------------------------------- ---------------------------------------------
  ![](media/image1.png){width="2.0548611111111112in"   **Project Management Plan**
  height="1.4166666666666667in"}                       

                                                       Project Name:

                                                       Date: DD Mmmm 20xx

                                                       Project Manager:

                                                       Approver: signature

                                                       Approver name and title
  ---------------------------------------------------- ---------------------------------------------

The following sections constitute the core areas of the Project
Management Plan.

Introduction

Describe the purpose of the Project Management Plan using the following
guidelines.

This document contains the plan for executing the xx project. It forms
the basis for all work activities and management efforts associated with
the project. The plan explains the project's rationale, team structure,
scope and objectives.

The information associated within the plan evolves as the project moves
through its various stages and will be updated as new information
develops about the project. The Plan is a dynamic document and is
expected to go through updates during the life of the project. The
updates will be recorded and maintained as part of the project change
management process, which is a contributory portion of the overall
project management plan.

Several subsidiary plans are also contained under the umbrella of the
project management plan. These describe the management practices for
specific project disciplines (i.e. scope management, schedule
management, risk management). The subsidiary plans are maintained in
separate documents that are also updated throughout the life of the
project. A summary description of each subsidiary plan is provided
within this project management plan.

General Project Information

[Project Governance Documents:]{.underline}

The project charter establishes the project and ...

The project scope statement documents a description of the project,
including the objectives, planned deliverables, and requirements.

[Team Membership]{.underline}

The Team consists of:

Project Manager ....

The Team structure is contained in the Organizational Breakdown
Structure, which is discussed elsewhere in this document. The Team
reports to xxx .

[Points of Contact]{.underline}

A contact list of team members and other stakeholders is maintained at
xxx. The list contains names, telephone numbers, fax numbers, e-mail
addresses and project roles. The file is updated as contacts are added
or removed from the project.

Executive Summary

[Approach:]{.underline}

Provide an executive level overview of the project management plan:
identify the business need or problem, identify the project goals and
objectives, and define the management strategy used to implement the
project.

[Business Need/Problem:]{.underline}

State the business problem/issue the project will solve.

[Project Objectives:]{.underline}

Provide a brief, concise list of what the project will accomplish.

Project Requirements and Scope Statement

See Project Scope Statement Template.

Work Breakdown Structure (WBS)

The project Work Breakdown Structure (WBS) organizes the project by
major functions (project management, software design, quality control,
etc.), continuous processes (status reporting, financial reporting,
etc.), and primary deliverables. It decomposes the work to the level
where the actual work is done and labor costs are tracked. These work
packages are further decomposed in the schedule.

The WBS is the primary tool for managing the scope of the project. This
simply means that if the work is included within the WBS, it is
considered within scope. If work is not contained within the WBS, it is
considered "out of scope" and should not be included in the project's
end product. The WBS is used to create a time-phased project budget
where actual data is collected to generate project performance
measurement.

The format can be a tree diagram that resembles an organization chart or
an outline format that can be accomplished in a spreadsheet format. It
is extremely important to have a consistent numbering system that can
tie the WBS to the budget and schedule. A typical numbering format
envisions the 1.1.1.1 style, where each number represents a new level of
indenture. (see sample in \[WBS section\])

Organizational Breakdown Structure

Provides a work package based organization chart that defines the
communications channels, responsibilities, and the authority of each
participating person/unit.

Create a blank 'tree' type diagram that looks similar to a Work
Breakdown Structure, in order to prepare to assign responsibility for
work packages. A spreadsheet type with all the elements of the Work
Breakdown Structure listed, including work definitions, is a suggested
format. (see sample in \[OBS section\])

The Organizational Breakdown Structure (OBS) is a diagram showing the
hierarchical structure of the organization's existing departments, units
and teams. The OBS is analyzed against the WBS to determine assignments
for the work to be done. This analysis results in a Resource Assignment
Matrix (RAM), which is used to illustrate the connections between the
work that needs to be done and the project team members. Figure 2
conceptually describes how the Resource Assignment Matrix is derived
from the WBS and OBS.

![](media/image2.jpeg){width="6.0in" height="4.5in"}

Project Schedule

Following the definition of project activities, the activities are
associated with time to create a project schedule. The Project Schedule
provides a graphical representation of predicted tasks, milestones,
dependencies, resource requirements, task duration, and deadlines. The
Project Schedule should be detailed enough to show each Work Breakdown
Structure task to be performed, the name of the person responsible for
completing the task, the start and end date of each task, and the
expected duration of the task. The Work Breakdown Structure lowest level
work packages can be further decomposed into schedule tasks.(see
\[Project Schedule section\])

A project schedule is created based on the work breakdown structure to
encompass the activities associated with developing project deliverables
and executing project work. The Project Schedule contains predicted
activities, milestones, dependencies, resource requirements, activity
durations, and deadlines. The Project Schedule shows each activity to be
performed, the name of the person responsible for completing the
activity, the start and end date of each activity, and the expected
duration of the activity.

Cost Estimating

Using the OBS, WBS and the project schedule, cost estimates are
developed for the lowest level of the WBS where costs are tracked (this
can called the work package level or cost account level -- it has also
been defined as the level where the OBS intersects with the WBS, thereby
identifying responsibility for a portion of the project work). The cost
estimates are used during project justification briefings and become the
time-phased budget used to measure cost performance (see Cost Management
Plan). Additional inputs to cost estimating include resource estimates
and risk assessments. Cost estimates should also incorporate a coding
structure that can be applied to the organization financial tracking
system.

Cost estimating is the process of calculating the cost of required
resources for completing the project activities. Cost estimating derives
costs for all resources required including personnel, materials,
services or equipment. Identified risks should also be evaluated and
contingencies included in the cost estimating as appropriate.

This process results in a project cost estimate, which is defined as "a
quantitative assessment of the likely costs of the resources required to
complete project activities" (PMBOK, 2002). An analysis of the cost
estimate provides a determination as to whether the project objectives
can be achieved within the project cost constraints.

The estimating process is iterative in nature and may require several
iterations to arrive at a final estimate. Changes in the cost estimates
may have impact on the scope, schedule or resource planning of the
project. Likewise, any changes in scope, schedule, quality or resource
planning may impact the cost estimate.

Project Management Plan Subsidiary Documents

The following documents are developed when needed during the project
life cycle and managed as subsidiary parts of the Project Management
Plan. Separate templates are provided to aid development of the
subsidiary documents:

The following documents are managed as subsidiary parts of the Project
Management Plan.

-   Staffing Management Plan

The Staffing Management Plan defines the project organization, resource
planning (people) and process for managing project staffing. It
describes when and how human resources will be brought onto and taken
off of the project. The Staffing Management Plan provides for orderly
and efficient management of human resources within the context of the
overall Project Management Plan.

-   Risk Management Plan

The Risk Management Plan describes how risks are identified, tracked,
assessed and responded to. The plan identifies the tools used to capture
identified risks, risk categories, assigned owners, calculated
probabilities, identified thresholds or triggers for instigating
mitigating action and contingency plans.

-   Procurement Management Plan

The Procurement Management Plan discusses the scope of procurements that
will exist for the EVM project, which include consultants, additional
software and licenses, and employee training. It describes the types of
contracts appropriate for the procurement, the solicitation and
evaluation processes, and team/stakeholder responsibilities relative to
the development of procurement documents. It discusses the timing of
procurements, describing the dependencies between solicitation
preparation, contract award and lead times with other aspects of the
project, such as design development or deployment. The procurement plan
describes the steps required by the USDA IT acquisition approval process
to initiate procurement.

-   Quality Management Plan

The Quality Management Plan describes the processes the project will use
to accomplish project quality assurance and quality control. The scope
of Quality Management for the EVM project includes project reporting,
training, contract language and EVM deliverables. It contains the
criteria used to determine acceptable products and the processes used to
control quality during the development, deployment and operational phase
of the project.

-   Communications Management Plan

The Communications Management Plan describes how project information is
distributed, reviewed, updated and filed. The plan describes the
information product, how it is produced, who produces it, when it is
produced and to whom it is distributed.

The plan also describes the communications forums (meetings) used to
disseminate information and to escalate issues. Meeting time, purpose,
attendees, sample agenda and information product(s) are all captured.

-   Change Control Plan

The Change Control Plan describes the processes, tools and
responsibilities for controlling the necessary changes to project scope,
cost and schedule. The plan discusses change identification, submission,
authorization and implementation. The plan identifies the tools used to
track, document and communicate project changes.

-   Cost Management Plan

The Cost Management Plan describes the process for implementing change
control over cost estimates and the project time-phased cost baseline.
This covers budget preparation and maintenance. It details the process
for authorizing and expending project funds. The plan includes the steps
taken when the performance measurement system identifies major or minor
cost vs. budget variances. The plan also covers the timing and
distribution of cost and performance reports.

-   Schedule Management Plan

The Schedule Management Plan describes who owns and manages the project
schedule, processes that control schedule change, reporting, updating
and analysis and the process for establishing a baseline schedule.

-   Scope Management Plan

The Scope Management Plan discusses the development, baseline and
control of the WBS, the primary scope management tool. The Scope
Management Plan also describes how scope changes will be managed and
integrated into other project areas, such as cost and schedule.

RECORD OF AMENDMENTS

  --------- -- ------------------ --------- --------- ----------------------------------
  Version      Author                       Date      Comments

  1.0                             7/25/05             Draft 1 -- Based on template
                                                      created for VA IT projects

                                                      

                                                      

                                                      

                                                      

                                                      

                                                      
  --------- -- ------------------ --------- --------- ----------------------------------

# Cost Management Plan Template 

  ---------------------------------------------------- ---------------------------------------------
  ![](media/image1.png){width="2.0548611111111112in"   **Cost Management Plan**
  height="1.4166666666666667in"}                       

                                                       Project Name:

                                                       Date: DD Mmmm 20yy

                                                       Project Manager

                                                       Approver: signature

                                                       Approver Name and Title
  ---------------------------------------------------- ---------------------------------------------

The following are suggested sections for the Cost Management Plan:

Purpose of Cost Management Plan

Describe the purpose of the cost management plan using the following
guidelines. Do not merely describe the content of the plan, but why Cost
Management is necessary for the project:

The objective of the cost management plan is to make certain that
project costs are monitored and controlled and that the project is
delivered within budget.

Cost changes, especially for complex projects, are common as project
activities are completed and more information and detail become
available. Cost changes can be caused by several factors such as the
unavailability of critical resources, material delivery, or cost of new
technology. The objective of the cost management plan is to make certain
that project costs are monitored and controlled and that the project is
delivered within budget.

Roles and Responsibilities

Describe how the following project participants, at a minimum, perform
in the planning and execution of project cost management

-   Project Sponsor

-   Project Manager

-   Project Team

-   Project Stakeholders

Project Budget

Describe the iterative process of preparing high-level conceptual budget
estimates during the project initiation phase and evolving to a
detailed, time-phased, WBS based budget during the planning phase of the
project. Describe the process for baselining the budget to enable
performance measurement. Describe how the budget will be maintained and
the process that will be followed if budget changes are required.
Describe periodic budget reviews and how project stakeholders will be
kept informed of their impact on the budget.

For OMB Exhibit 300 projects that involve "reimbursement" funds, be sure
to describe the amounts and source of the funds, method and frequency of
reporting progress towards agreed upon goals (for which the funding is
intended to help achieve), mutually agreed upon ways to change the
reimbursement (up or down), and mutually agreed upon decision making
about disposition of year-end remainders. A senior officer(s) from the
organization(s) providing the reimbursement funds should sign this plan,
signifying their concurrence and approval of the portion of the plan
that deals with the reimbursement funds.

Cost Performance Measures

Describe how performance reporting will be accomplished (i.e.,
deliverables, activity, contract, departmentally, etc.) and what
performance characteristics will be reported. The reporting measures
should also include a project overview of total performance to date with
project completion projections. The description should include the
development of financial, budget and schedule data required for the OMB
Exhibit 300 process Earned Value Management System.

Cost Reports

Include a brief overview of the reporting content and format. Various
reports may be used dependent upon the recipients (i.e., management
reports, project team reports, contractor performance reports, etc.). At
a minimum reports should include cost variances (CV), estimated at
completion (EAC) and the cost performance index (CPI). Describe
reporting cost data for the OMB Exhibit 300 process.

Cost Change Review and Approval Process

Describe the organization and process for evaluating and assessing
project budget/cost changes. Define the authority for accepting and
approving changes in cost. Include the evaluation process to assess the
impact of cost changes on project scope, schedule, risk and quality.
Note: the cost change review and approval process should be contained
within the Integrated Change Control Management Process. Reference to
that process should be included within this statement.

The integrated change management process must be followed to initiate
any changes or revisions to the cost estimate. Other aspects of the
project, including scope, risks, requirements, acquisition plan etc, may
impact budget changes.

Approved cost changes may or may not require re-baselining. In other
words, a change in cost may not necessarily change the budget and
therefore would not require re-baselining. In determining whether to
make a cost change, consideration is given to impacts on scope,
schedule, risk, quality and staffing. The integrated change management
plan should contain further explanation of the re-baselining process.
The status of all change requests is communicated to appropriate project
stakeholders in accordance with the project's communications plan.

RECORD OF AMENDMENTS

  --------- ------------------ --------- -----------------------------------
  Version   Author             Date      Comments

  1.0                          7/25/05   Draft 1. Based on template created
                                         for VA IT project cost management

                                         

                                         

                                         

                                         

                                         

                                         
  --------- ------------------ --------- -----------------------------------

# Earned Value Management Definitions 

# Scope Management Plan Template

  ---------------------------------------------------- ---------------------------------------------
  ![](media/image1.png){width="2.0548611111111112in"   **Scope Management Plan**
  height="1.4166666666666667in"}                       

                                                       Project Name:

                                                       Date: DD Mmmm-20yy

                                                       Project Manager:

                                                       Approver: signature

                                                       Approver Name and Title:
  ---------------------------------------------------- ---------------------------------------------

The following are suggested sections for the Scope Management Plan

Purpose of Scope Management Plan

Describe the purpose of the Scope Management Plan using the following
guidelines. Do not merely describe the content of the plan, but explain
why Scope Management is necessary for the project.

Scope changes are common in projects, especially complex projects, as
more information and detail become available during project planning and
execution. Some changes are necessities in that the end product may not
meet the project objectives if the changes are not incorporated. Some
changes are "nice to have" features that really are not essential to
meeting the project end product objectives but would enhance the
product. Some changes are simply included due to a difference in
approach, style or priority but are not essential at all to meeting
project objectives.

A management process must to be established that will allow the
evaluation and impact assessment of proposed scope changes. Any change
in scope will have some impact on cost, time or quality of the project's
end product. Before decisions can be made regarding the proposed change
the impact of that change must be known. Therefore a scope management
process must be a part of the Project Plan. The objective of the scope
management plan is to make sure the scope is delivered -- no more and no
less.

The scope of a project should be captured in the Work Breakdown
Structure (WBS). The WBS organizes the project by major functions
(project planning, standards documentation, training etc.), continuous
processes (status reporting, financial reporting, etc.), and primary
deliverables. The WBS is the primary tool for managing the scope of the
project. This simply means that if the work is included within the WBS,
it is considered within scope. If work is not contained within the WBS,
it is considered "out of scope" and should not be included in the
project's end product. The Work Breakdown Structure is the fundamental
planning tool for project management.

Roles and Responsibilities

Describe how the following project participants, at a minimum, perform
in the planning and execution of project communications

-   Project Sponsor

-   Project Manager

-   Project Team

-   Project Stakeholders

Work Breakdown Structure (WBS) Development

The plan should discuss the process the project will follow to develop
the WBS (an outline or graphical depiction of the project scope). The
development process involves deciding on an approach (usually top-down),
involving team members who will accomplish the work (tasking them for
inputs, meetings), creating a numbering system, including financial
system codes and budgetary information, and deciding where to capture
costs (work package level). A thorough understanding and buy-in of the
WBS from the project team and supporting organizations is essential.

Scope Baselining

Describe the process for establishing the scope baseline (essentially
freezing WBS development). The formal process to insure the project team
and stakeholders understand the WBS and are supportive of its layout.
The baselined WBS can then become the backbone for establishing a
detailed project schedule and cost accounting system. The integrated
change control process must be followed to initiate further changes or
revision to the WBS (schedule, budget, risk database, requirements,
acquisition plan, etc.) if rebaselining occurs. Discuss the possible use
of a Change Control Board (CCB).

Scope Change Management Process

Describe the scope (WBS) change control process as it pertains to
project integrated change control. Discuss the likelihood that WBS
changes will be necessary. As an example, progressive elaboration of the
project product can lead to changes to the WBS. Discuss the frequency of
anticipated changes. Describe how scope changes will be identified
classified and assessed (major cost and schedule impact, minor impact,
no impact, etc). Do scope changes require changes to the scope
statement, WBS, or schedule? Include a process for tracking scope
changes, continuously evaluating the overall impact of changes, and
reporting changes to sponsors, senior management, stakeholders, project
team members (immediately, at status reviews, etc.). Discuss the
triggers for rebaselining the WBS and process for revising project
documents (schedule, budget, risk database, requirements, acquisition
plan, etc.) if rebaselining occurs. Discuss the possible use of a Change
Control Board (CCB).The integrated change management process must be
followed to initiate any changes or revisions to the WBS. Scope changes
can be impacted by any aspect of the project, including schedule,
budget, risks, requirements, acquisition plan etc. The integrated change
management plan is described in the document titled EVM Change
Management.doc.

[Change Thresholds]{.underline}

Submittal of a change request to the \[sponsor\] for approval is
required if one of the two following statements is true:

1.  The change is estimated to reduce the cost or duration of an
    individual activity by x% or more, or increase the cost or duration
    of an individual activity by x% or more

2.  The change is estimated to reduce the cost or duration of the
    overall schedule by x% or more, or increase the cost or duration of
    the overall schedule by x% or more

Change requests that do not meet these threshold levels are to be
submitted to the \[Project Manager\] for approval.

Approved scope changes may or may not require re-baselining. In other
words, a change in scope may not necessarily change the schedule or cost
and therefore would not require re-baselining. In determining whether to
make a scope change, consideration will be given to impacts on schedule,
cost, risk, quality and staffing. The integrated change management plan
contains further explanation of the re-baselining process. The status of
all change requests is communicated to appropriate project stakeholders
in accordance with the project's communications plan.

All change requests are documented using a change request form. The
change request form is included in the integrated change management plan
document along with instructions on how to complete it.

The project Scope Statement must be reviewed for any impacts as part of
a change request submission. Any scope changes also affecting the scope
statement must be noted on the request form. The change request is then
processed through the approval process with knowledge that the scope
statement also requires revision.

RECORD OF AMENDMENTS

  --------- -- ------------------ --------- --------- ----------------------------------
  Version      Author                       Date      Comments

  1.0                             7/25/05             Draft 1. Based on template created
                                                      for VA IT Scope Management

                                                      

                                                      

                                                      

                                                      

                                                      

                                                      
  --------- -- ------------------ --------- --------- ----------------------------------

# Work Breakdown Structure Example

![](media/image3.png){width="9.1875in" height="4.895833333333333in"}

# Quality Management Plan Template

  ---------------------------------------------------- ---------------------------------------------
  ![](media/image1.png){width="2.0548611111111112in"   **Quality Management Plan**
  height="1.4166666666666667in"}                       

                                                       Project Name:

                                                       Date: DD Mmmm 20yy

                                                       Project Manager:

                                                       Approver: signature

                                                       Approver Name and Title
  ---------------------------------------------------- ---------------------------------------------

The following are suggested sections for the Quality Management Plan

Purpose of the Quality Management Plan

Describe the purpose of the Quality Management Plan using the following
guidelines. Do not merely describe the content of the plan, but why
Quality Management is necessary for the project.

Quality doesn't simply happen. It must be planned into the project.
There must be some method of ensuring that the end result will meet the
needs of the organization and the "customer" (either internal or
external), as well as meeting the project objectives. A method is needed
for validating these measures. Quality Planning, Quality Assurance and
Quality Control processes developed within the Quality Management Plan
are used to achieve quality goals.

Roles and Responsibilities

Describe how the following project participants, at a minimum, perform
in the planning and execution of project communications

-   Project Sponsor

-   Project Manager

-   Project Team

-   Project Stakeholders

Quality Policy

Describe the organization's quality policy or the policy adopted for the
project. Quality policy might involve document preparation standards,
status reporting standards, levels of communication standards for
project events, contracting standards, development and testing
standards, etc.

Quality Management Approach

Describe how the project team will implement the quality policy and
achieve the project quality standard. Include the quality criteria
identified during the quality planning process.

Quality Assurance

Describe the project quality assurance process which include the test
and acceptance processes, documentation and operational support
transitions, milestone checklist, the requirement verification process,
schedule and communication activities, and continuous improvement
processes. (see example of a Quality Management Process Model in the
Quality Management Plan section)

Quality assurance is intended to "design quality into" the product.
Quality assurance is an ongoing activity that occurs in a planned and
systematic way, not as a "post facto" event. Quality assurance is
focused on the quality processes that:

-   Organize

-   Design processes

-   Set objectives

-   Provide resources

-   Develop procedures

Quality Control

Define in-process control processes that address quality assurance
activity areas. Describe how control information will be collected and
how the information will be used to control processes and deliverables.
Describe the periodic quality audits and reviews and how variances from
acceptable criteria will be reported and resolved.

The Quality control process measures whether the project deliverables
are meeting the criteria, policies, procedures and other planning steps
as the project moves into the execution phase. Quality control also
analyzes the validity of the quality criteria and other outputs of the
quality planning process. Quality control is focused on quality by:

-   Estimating

-   Analyzing

-   Monitoring conformance

-   Providing quality reports

Quality Change Review and Approval Process

Describe the organization and process for evaluating and assessing
proposed quality changes. Define the authority for accepting and
approving changes in quality, which may include the customer. Note: the
change review and approval process should be contained within the
Project Integrated Change Control Process and referred to in this
section.

RECORD OF AMENDMENTS

  --------- -- ------------------ --------- --------- ----------------------------------
  Version      Author                       Date      Comments

  1.0                             7/25/05             Draft 1 -- Based on Quality
                                                      Management Template created for VA
                                                      IT projects

                                                      

                                                      

                                                      

                                                      

                                                      

                                                      
  --------- -- ------------------ --------- --------- ----------------------------------

##  

# Project Communications Plan Template

  ---------------------------------------------------- ---------------------------------------------
  ![](media/image1.png){width="2.0548611111111112in"   **Communications Management Plan**
  height="1.4166666666666667in"}                       

                                                       Project Name:

                                                       Date: DD Mmmm 20yy

                                                       Project Manager:

                                                       Approver: signature

                                                       Approver Name and Title
  ---------------------------------------------------- ---------------------------------------------

The following are suggested sections for the Communications Management
Plan

Purpose of Communications Management Plan

Describe the purpose of the Communications Management Plan using the
following guidelines. Do not merely describe the content of the plan,
but explain why Communications Management is necessary for the project:

The success of any project is heavily reliant upon the project team
members and stakeholders being thoroughly informed in a timely manner.
Information such as scope, time, cost or quality changes, current
project schedule status, current and projected cost data, and project
decisions or issues all need to be disseminated to project members and
stakeholders. This Communications Plan establishes the project's
processes and requirements for the collection and distribution of
project data.

Document accessibility and security are also key factors. Not every
project participant requires access to every project document, but some
information should be available to all. Methods need to be in place to
identify security and accessibility to project information.

Roles and Responsibilities

Describe how the following project participants, at a minimum, perform
in the planning and execution of project communications

-   Project Sponsor

-   Project Manager

-   Project Team

-   Project Stakeholders

Stakeholder Identification

Using the WBS and OBS identify the project stakeholders, when they will
be active on the project and all the pertinent information necessary to
communicate with them (organization, title, address, phone numbers,
email, etc.). Further identify alternates and subordinates that will be
assigned to the project and act on behalf of a stakeholder. Provide the
stakeholders responsibility to the project including review and approval
authority for project documentation.

Project Reports

Describe the reports to be generated in support of the project. Define
the data to be collected, the frequency of collection, the responsible
party for collection, compilation and analysis, the report media and
format, and the distribution of the report. Some examples of reports
include:

  --------------------------------- -------------------------------------
  Project Status                    Open Issues/Action Items

  Financial Data                    Quality Assurance

  Cost Variance                     Resource Utilization/Projections

  Schedule Status and Variance      Change Control

  Updated Project Schedules         
  --------------------------------- -------------------------------------

The following other subsidiary project management plans also should
contain information on reports:

-   Cost Management Plan

-   Schedule Management Plan

-   Risk Management Plan

Ad-hoc or specialized report requests may arise during the project. The
plan should describe how specialized reports are accepted within the
project, who approves them and how reporting changes will be
communicated.

Project Meetings

Describe the meetings held on the project, their purpose, frequency,
attendees and reporting requirements. This information might be held is
a separate document for easier maintenance.

Project Information Accessibility

Access to project information should be planned. Centralized project
files and data may not be advantageous to large projects with varied
geographic locations. This section will define the project team
requirements, media and locations for project information, including any
document management system employed. Also consider document scanning and
storage policies within the project office. The plan should also cover
document security, the requirement for locked storage, passwording, etc.

RECORD OF AMENDMENTS

  --------- -- ------------------ --------- --------- ----------------------------------
  Version      Author                       Date      Comments

  1.0                             7/25/05             Draft 1 -- Based on template
                                                      developed for VA IT project
                                                      communications management

                                                      

                                                      

                                                      

                                                      

                                                      

                                                      
  --------- -- ------------------ --------- --------- ----------------------------------

Project Name:

  --------- ----------- ------ ---------- -------- ------------ --------------- -----------
  Meeting   Frequency   Time   Location   Leader   Attendees    Purpose         Report(s)
  Name                                                                          Used

                                                                                

                                                                                

                                                                                

                                                                                

                                                                                
  --------- ----------- ------ ---------- -------- ------------ --------------- -----------

Project Name:

  ------ ------------- ------------- ------------- ------------- ------------
         Monday        Tuesday       Wednesday     Thursday      Friday

  Week 1                                                         

  Week 2                                                         

  Week 3                                                         

  Week 4                                                         
  ------ ------------- ------------- ------------- ------------- ------------

# Change Management Plan Template

  ---------------------------------------------------- ---------------------------------------------
  ![](media/image1.png){width="2.0548611111111112in"   **Integrated Change Management Plan**
  height="1.4166666666666667in"}                       

                                                       Project Name:

                                                       Date: DD Mmmm 20yy

                                                       Project Manager:

                                                       Approver: signature

                                                       Approver Name and Title
  ---------------------------------------------------- ---------------------------------------------

The following are suggested sections for the Integrated Change Control
Plan.

Purpose of Integrated Change Management Plan

Describe the purpose of the Integrated Change Management Plan using the
following guidelines. Do not merely describe the content of the plan,
but explain why Integrated Change Management is necessary for the
project.

Projects are dynamic efforts and as such change is inevitable. One of
the greatest challenges to a project's success is controlling the impact
of change or managing changes to the benefit of the project objectives.
By accepting the fact that change will occur and planning for the
management of change, the probability of project success is increased
and enhanced.

The purpose of the Integrated Change Control Plan is to define all
processes, practices, tools, review bodies, and authority necessary to
monitor and control project performance, identified change and the
potential impact of change on project objectives.

Roles and Responsibilities

Describe how the following project participants, at a minimum, perform
in the planning and execution of project change management.

-   Project Sponsor

-   Project Manager

-   Project Team

-   Other Stakeholders

Review and Approval Process

Describe the process to identify change in the project scope, cost and
budget. Describe the change approval authorities and review boards that
will process project change control documents. An example may be a
change control board made up of leaders in various project disciplines
such as project management, cost, scheduling, configuration management,
technical design, and test. Sponsors, system owners and users should
also be considered. A process flow chart is appropriate for this
section. (See the notional flow chart in the Change Control section of
the Project Handbook Appendices)

The following text and chart comes from the VA project plan for EVM.
Provided as reference only

Following are the steps involved in the change control process. A
process flow diagram at the end of this section graphically displays the
steps.

I.  A potential change is identified by any team member or project
    stakeholder.

II. The change request form is completed (see appendix of this document)
    with the assistance of the Project Manager or designee.

III. The Project Team evaluates the request to make sure impacts are
     thoroughly discussed and identified on the form. Decision-makers
     should be able to clearly see the impact of change on the project
     (time cost, scope, quality and risks).

IV. If the impact of the change the thresholds outlined in this plan
    then the change is presented to the \[*Approval Body*\] for review.
    The \[*Approval Body*\] chair has ultimate approval or denial of the
    change. Any changes under the threshold for \[*Approval Body*\]
    approval are sent to Project Manager for approval.

V.  If the change is denied the reason is documented and the requestor
    is notified. No other action is taken.

VI. If the change is approved then it is documented and implemented. The
    change will be reflected in all the appropriate Project Management
    documents. (e.g. schedule, budget, WBS, Risk management plan etc.)
    Re-baselining may be appropriate (see section on re-baselining
    below).

VII. If a change request is deferred, then one of two actions is taken.
     In the case where a "trigger event" which would necessitate the
     change is known, the Project Team will monitor the occurrence of
     the event. The change request will be re-visited when the event
     occurs. Otherwise, the Project Team will schedule a date to
     re-evaluate the request.

> The Review and Approval Process Flow Chart is presented here

Change Thresholds

Describe the limits that trigger the change control process for scope
(WBS), cost, schedule and possibly resources. An example may be critical
WBS elements where costs exceed 10% of budget, or perhaps a schedule
element that is falling behind and will require additional resources to
meet a critical deliverable.

Change Identification, Documentation, Implementation and Reporting

Describe the initiation of a change control form and the documentation
required to track a request. Describe automated tool used to manage and
track changes and identify the process for entering and reporting
changes. Also, if the project has a change control board, describe the
process for preparing the agenda and communicating results to the
stakeholders. Describe the process for updating the WBS, schedules and
budget/cost documents with approved changes. If the baseline for these
documents changes, describe the means for capturing the baseline change
in the OMB Exhibit 300 process.

Re-baselining

Describe the reasons and procedures for re-baselining such as in the
statement below:

The project WBS, schedule and costs are all baselined early in the
project. Any of these artifacts may experience enough change throughout
the project to require re-baselining. The original baseline is never
over-written. Change requests submitted after re-baselining will be
assessed for impacts against the revised baseline, not the original
baseline.

General guidance for re-baselining includes:

-   General cost overruns and schedule slippages due to performance or
    poor estimation are NOT sufficient reasons to re-baseline.

-   As long as there is no change in scope, a project manager is able to
    further decompose activities that were previously recorded at a
    higher level. This DOES NOT constitute a re-baselining but is
    considered an update.

-   Requested changes to cost and/or schedule to achieve the original
    scope. This DOES constitute a re-baselining.

-   Reductions in funding ARE an acceptable reason to re-baseline. This
    should be accompanied by an explanation of how the funding cuts
    impact the original scope of the project.

Appendix A. -- Change Request Form

The attached form is to be used for all change requests in the project
affecting scope, schedule, cost and risk.

Revisions to the template should be noted in the Record of Amendments at
the end of this document.

**RECORD OF AMENDMENTS**

  --------- -- ------------------ --------- --------- ----------------------------------
  Version      Author                       Date      Comments

  1.0                             7/21/05             Draft 1. Based on template created
                                                      for VA IT change management

                                                      

                                                      

                                                      

                                                      

                                                      

                                                      
  --------- -- ------------------ --------- --------- ----------------------------------

##  

  ---------------------------------------------------- ---------------------------------------------
  ![](media/image1.png){width="2.0548611111111112in"   **Change Request Form**
  height="1.4166666666666667in"}                       

                                                       Project Name:      

                                                       

                                                       

                                                       
  ---------------------------------------------------- ---------------------------------------------

Refer to the last page for a diagram of the change approval process

+----------------------------------------+-----------------------------+
| **1. Change Request Information -- To  |                             |
| be Completed by Requestor**            |                             |
+----------------------------------------+-----------------------------+
| Requestor                              | Request Date                |
+----------------------------------------+-----------------------------+
| Proposed Change Description and        |                             |
| References                             |                             |
|                                        |                             |
|                                        |                             |
+----------------------------------------+-----------------------------+
| Justification/Reason for Change        |                             |
|                                        |                             |
|                                        |                             |
+----------------------------------------+-----------------------------+
| Impact of Not Implementing Proposed    |                             |
| Change                                 |                             |
|                                        |                             |
|                                        |                             |
+----------------------------------------+-----------------------------+
| Alternatives                           |                             |
|                                        |                             |
|                                        |                             |
+----------------------------------------+-----------------------------+
| Baseline(s) Affected: Scope (WBS)      |                             |
| Schedule Cost                          |                             |
+----------------------------------------+-----------------------------+
| Impact on Scope                        |                             |
+----------------------------------------+-----------------------------+
| Impact on Schedule                     |                             |
+----------------------------------------+-----------------------------+
| Impact on Cost                         |                             |
+----------------------------------------+-----------------------------+
| Risk Analysis                          |                             |
+----------------------------------------+-----------------------------+
| Reference Risk Number                  |                             |
|                                        |                             |
| Risk Description                       |                             |
|                                        |                             |
| Change in Risk Impact From To          |                             |
|                                        |                             |
| Change in Risk Probability From To     |                             |
|                                        |                             |
| Change Impact Analysis on Risk         |                             |
+----------------------------------------+-----------------------------+

+-----------------------------------------------------------------------+
| **2. Impact Analysis -- To Be Completed by Earned Value Team**        |
+-----------------------------------------------------------------------+
| Review Date                                                           |
|                                                                       |
| Change Control Number                                                 |
|                                                                       |
| Comments                                                              |
|                                                                       |
| Classification                                                        |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| **3. Project Manager Review Results -- To Be Completed by Project     |
| Manager**                                                             |
+-----------------------------------------------------------------------+
| Review Date                                                           |
|                                                                       |
| Comments                                                              |
|                                                                       |
| Approved                                                              |
|                                                                       |
| Forward to EPMC                                                       |
|                                                                       |
| Rejected                                                              |
|                                                                       |
| Defer Until (trigger event or future date)                            |
+-----------------------------------------------------------------------+
| Reason for Rejection/Deferral                                         |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| **4. \[Approval Body\] Review Results -- To Be Completed by           |
| \[Approval Body\]**                                                   |
+-----------------------------------------------------------------------+
| Review Date                                                           |
|                                                                       |
| Comments                                                              |
|                                                                       |
| Approved                                                              |
|                                                                       |
| Rejected                                                              |
|                                                                       |
| Defer Until (trigger event or future date)                            |
+-----------------------------------------------------------------------+
| Reason for Rejection/Deferral                                         |
+-----------------------------------------------------------------------+
| Name       Position                                                   |
|                                                                       |
| Signature:\_\_\_\_\_\_\_\_\_\_\_\_\_\_­\_\_\_\_\_\_\_\_\_\_\_\_        |
|                                                                       |
| Name       Position                                                   |
|                                                                       |
| Signature:\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_        |
|                                                                       |
| Name       Position                                                   |
| Signature:\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_        |
|                                                                       |
| Name       Position                                                   |
|                                                                       |
| Signature:\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_        |
+-----------------------------------------------------------------------+

Change Request Process Flow Diagram

# Risk Management Plan Template

  ---------------------------------------------------- ---------------------------------------------
  ![](media/image1.png){width="2.0548611111111112in"   **Risk Management Plan**
  height="1.4166666666666667in"}                       

                                                       Project Name:

                                                       Date: DD Mmmm 20yy

                                                       Project Manager:

                                                       Approver: signature

                                                       Approver Name and Title
  ---------------------------------------------------- ---------------------------------------------

The following are suggested sections for the Risk Management Plan

Purpose of Risk Management Plan

Describe the purpose of the Risk Management Plan using the following
guidelines. Do not merely describe the content of the plan, but why Cost
Management is necessary for the project.

Risk is an indicator of uncertainty about the future. The greater the
investment in a project, the more one has to lose should any problems
delay or derail the project. Risks on any project must be identified and
analyzed so that project teams can prepare for their potential
occurrence and lessen or eliminate their chance of occurring.

The Risk Management Plan provides a systematic method of identifying and
analyzing the effects of uncertainties in the project and to plan for
minimizing or containing the consequences of any undesired event that
may impact the success of the project.

Roles and Responsibilities

Describe how the following project participants, at a minimum, perform
in the planning and execution of project communications

-   Project Sponsor

-   Project Manager

-   Project Team

-   Project Stakeholders

-   Risk Manager

Risk Identification

During risk identification, the perception of a potential problem is
documented in sufficient detail to enable effective assessment of the
risk to support subsequent management decisions. Once the risk has been
identified and reviewed, the risk is recorded into the risk database.

See Risk Inventory and Assessment at form end.

The project team systematically reviews the project deliverables and
activities for possible risk information. Typically, risk information is
derived from:

-   Analysis of high-level deliverables

-   Analysis of the work Breakdown Structure(WBS) and Network diagram

-   Analysis of change requests

-   Project team input (experience, lessons learned etc.)

-   Stakeholder input (assumptions, organizational requirements etc.)

Risk Triggers

Risk triggers are events or performance characteristics that warn of the
occurrence of risk events. An example of a risk trigger would be a
supplier missing deliverable dates and delaying related activities and
adding cost to project.

Risk triggers are determined during the risk identification process and
are captured on the Risk Control Form.

Risk Analysis

The goal of risk analysis is to ensure that the risks are examined in a
structured and systematic manner. The risk owner may work with the risk
coordinator to formulate the initial risk assessment. Two methods of
risk analysis are employed in this process -- qualitative and
quantitative analysis.

A qualitative risk assessment qualifies the expected impact,
probability, and timeframe of a risk. The results of the risk analysis
are recorded on a risk identification form. The results are used to
determine Risk Management priorities.

A quantitative risk analysis is also accomplished where the impact of a
risk is ranked against other risk events or in the case or performance,
the risk is assessed as a percentage of reduction in performance.

Risk Severity

The results of qualitative analysis and quantitative analysis are
captured on an impact/probability chart, called the Risk Severity Grid.
The grid is used to determine the priority that is assigned each risk
and the need to develop containment strategies.

Risk Response Planning

Risk response planning involves identifying the strategy for minimizing
the effects of the risk to a level where the risk can be controlled and
managed to ensure the project objectives are achieved. Risk reduction
strategies include research, watch, mitigate, accept or transfer.

Each risk containment strategy will uniquely address the situation.
However, strategies generally involve one of the following techniques:

  ------------------ --------------------------------------------------------
  **Avoidance**      To avoid a risk event, the project plan may be altered.
                     Better clarification of scope or product description may
                     avoid the risk. The additions of resources, time, and/or
                     the development of a different approach are also risk
                     avoidance techniques.

  **Transference**   Transferring responsibility for management of a risk may
                     mitigate the risk. This technique is typically used when
                     strategizing financial exposure but does not eliminate
                     the probability of the risk event.

  **Sharing**        It is at times possible to share the impact of a risk
                     event with a customer, third party vendor, etc. This
                     could result in an overall lessening of the risk impact
                     and position all parties to better control, avoid or
                     mitigate the risk event.

  **Mitigation**     Mitigation attempts to reduce the probability or
                     consequence of the risk event to an acceptable level.
                     This could involve an early action plan to address the
                     issue before it becomes problematic by adopting less
                     complex processes or adding more resources or time.

  **Acceptance**     Acceptance of a risk by a project team indicates that
                     the risk is within acceptable limits or that contingency
                     plans are sufficient to ensure project success even if
                     the risk event occurs. Accepted risks typically require
                     the development of a contingency plan (an alternative
                     course of action should the risk event occur). This may
                     include the allocation of a contingency allowance or
                     reserve in terms of finances, time or resources.
  ------------------ --------------------------------------------------------

Risk Documentation and Reporting

Create a central repository for risk information and mitigation
strategies. This is typically an automated system where risk information
is available to appropriate project team members and risk owners.
Typical tools include the risk register (the complete risk database) and
a monthly risk status report that is part of the OMB Exhibit 300
process.

Risk Control

Define the risk control process that addresses risks on a periodic
basis. Describe how risks are regularly reassessed and the risk database
is updated. Describe how the risk triggers are regularly assessed and
validated. Insure, on a periodic basis that new risks are being
identified, assessed and captured in the database.

In order to successfully address the OMB risk categories for submission
and scoring of the OMB Exhibit 300, the following Risk categories must
be addressed to discuss plans, milestones and completion dates, and
whether to eliminate, mitigate, or manage the risk.

  ------------ ------------------ ------------- ------------- ------------ -----------
  Date         Area of Risk       Description   Probability   Strategy for Current
  Identified                                    of Occurrence Mitigation   Status

               Schedule                                                    

               Initial Cost                                                

               Life Cycle Cost                                             

               Reliability of                                              
               Systems                                                     

               Capability of                                               
               agency to manage                                            
               project                                                     

               Overall risk of                                             
               project failure                                             

               Technical                                                   
               Obsolescence                                                

               Feasibility                                                 

               Dependencies and                                            
               Interoperability                                            

               Risk of creating                                            
               "lock-in" -- a                                              
               monopoly for                                                
               future                                                      
               procurements                                                

               Organization and                                            
               Change Management                                           

               Business                                                    

               Data/Info                                                   

               Technology                                                  

               Strategic                                                   

               Security                                                    

               Privacy                                                     

               Project Resources                                           

               Management                                                  
               Complexity                                                  

               Departmental                                                
               Reorganization                                              
  ------------ ------------------ ------------- ------------- ------------ -----------

Appendix A. - RISK IMPACT CATEGORIES

+--------------+----------+----------+--------------------------------+
| Risk Event   | Schedule | Cost     | Performance                    |
| Impact       | Slippage | Increase |                                |
|              |          |          | (Scope and/or Quality)         |
+--------------+----------+----------+--------------------------------+
| 5 -- Very    | \> 20%   | \> 20%   | End product fails to meet      |
| High         |          |          | customer needs                 |
+--------------+----------+----------+--------------------------------+
| 4 -- High    | 10 --    | 10 --    | Reduction in functionality or  |
|              | 20%      | 20%      | usability unacceptable to      |
|              |          |          | customer                       |
+--------------+----------+----------+--------------------------------+
| 3 --Moderate | 5 -- 10% | 5 -- 10% | Major impact in functionality  |
|              |          |          | or usability requiring         |
|              |          |          | customer approval              |
+--------------+----------+----------+--------------------------------+
| 2 -- Low     | \< 5%    | \< 5%    | Relatively minor impact in     |
|              |          |          | functionality or usability     |
+--------------+----------+----------+--------------------------------+
| 1 -- Very    | \~ 0     | \~ 0     | Very minor impact in           |
| Low          |          |          | functionality or usability     |
+--------------+----------+----------+--------------------------------+

Assess the impact of each identified risk event.

Appendix B. - RISK PROBABILITY CATEGORIES

+----------------+------------------+----------------------------------+
| Risk Event     | Likelihood of    | Response Strategy Difficulty     |
| Probability    |                  |                                  |
|                | Risk Event       |                                  |
+----------------+------------------+----------------------------------+
| 5 -- Very High | \> 80% -- Risk   | No strategy available to         |
|                | event expected   | counteract the risk event        |
|                | to occur         | occurring.                       |
+----------------+------------------+----------------------------------+
| 4 -- High      | 60-80% -- Risk   | Limited resources or strategies  |
|                | event more       | are available that will          |
|                | likely to occur  | influence the occurrence of or   |
|                |                  | contain the risk event. A high   |
|                |                  | level of management attention is |
|                |                  | necessary.                       |
+----------------+------------------+----------------------------------+
| 3 -- Probable  | 40-60% -- Risk   | A higher level of management     |
|                | event may or may | attention is required to develop |
|                | not to occur     | strategies that will produce an  |
|                |                  | acceptable outcome.              |
+----------------+------------------+----------------------------------+
| 2 -- Low       | 20-40% -- Risk   | With attention, normal           |
|                | event less       | management strategies should     |
|                | likely to occur  | produce an acceptable outcome    |
+----------------+------------------+----------------------------------+
| 1 -- Very Low  | \< 20% -- Risk   | Normal management strategies     |
|                | event not        | should produce an acceptable     |
|                | expected         | outcome.                         |
+----------------+------------------+----------------------------------+

Assess the probability of occurrence for each identified risk event.

## 

Appendix C. - RISK SEVERITY GRID

+----+-----------+-----------+-------+---------+---------+-----------+
| Im | 5         |           |       |         |         |           |
| pa |           |           |       |         |         |           |
| ct | Very High |           |       |         |         |           |
+----+-----------+-----------+-------+---------+---------+-----------+
|    | 4         |           |       |         |         |           |
|    |           |           |       |         |         |           |
|    | High      |           |       |         |         |           |
+----+-----------+-----------+-------+---------+---------+-----------+
|    | 3         |           |       |         |         |           |
|    |           |           |       |         |         |           |
|    | Moderate  |           |       |         |         |           |
+----+-----------+-----------+-------+---------+---------+-----------+
|    | 2         |           |       |         |         |           |
|    |           |           |       |         |         |           |
|    | Low       |           |       |         |         |           |
+----+-----------+-----------+-------+---------+---------+-----------+
|    | 1         |           |       |         |         |           |
|    |           |           |       |         |         |           |
|    | Very Low  |           |       |         |         |           |
+----+-----------+-----------+-------+---------+---------+-----------+
|    |           | 1         | 2     | 3       | 4       | 5         |
|    |           |           |       |         |         |           |
|    |           | Very Low  | Low   | P       | High    | Very High |
|    |           |           |       | robable |         |           |
+----+-----------+-----------+-------+---------+---------+-----------+
|    |           | Pr        |       |         |         |           |
|    |           | obability |       |         |         |           |
+----+-----------+-----------+-------+---------+---------+-----------+

After probability and impact assessment, identify the risk severity from
the chart above. Risks are then prioritized based upon the severity of
event.

(Red shaded areas represent the greatest risk severity with significant
potential impact to the project.)

## 

Appendix D. - RISK CONTROL FORM

Form to be used for submitting project risks and formulating risk
responses.

Appendix E. - RISK MANAGEMENT LOG

Form to be used for maintaining status of project risks.

RECORD OF AMENDMENTS

  --------- -- ------------------ --------- --------- ----------------------------------
  Version      Author                       Date      Comments

  1.0                             7/25/05             Draft 1 -- Based on template
                                                      created for VA IT risk management

                                                      

                                                      

                                                      

                                                      

                                                      

                                                      
  --------- -- ------------------ --------- --------- ----------------------------------

##  

# Risk Control Form Template

  ---------------------------------------------------- ---------------------------------------------
  ![](media/image1.png){width="2.0548611111111112in"   **Risk Control Form**
  height="1.4166666666666667in"}                       

                                                       Project Name:      

                                                       Date:      

                                                       Project Manager:      

                                                       
  ---------------------------------------------------- ---------------------------------------------

+----------------+-----------------+----------------+----------------+
| Risk Log       | Submittal Date  | Submitted By   | Assigned Owner |
| Number         |                 |                |                |
|                |                 |                |                |
|                |                 |                |                |
+----------------+-----------------+----------------+----------------+
| Brief          |                 |                |                |
| Description of |                 |                |                |
| Risk Event     |                 |                |                |
|                |                 |                |                |
+----------------+-----------------+----------------+----------------+
| Status         |                 | Priority Level |                |
+----------------+-----------------+----------------+----------------+
| Probability    |                 | Impact         |                |
+----------------+-----------------+----------------+----------------+
| Qualitative    |                 |                |                |
| Analysis (Risk |                 |                |                |
| Severity)      |                 |                |                |
|                |                 |                |                |
+----------------+-----------------+----------------+----------------+
| Quantitative   |                 |                |                |
| Analysis       |                 |                |                |
+----------------+-----------------+----------------+----------------+
| Activity       | Best Case       | Most Likely    | Worst Case     |
| Number (WBS)   |                 | Case           |                |
+----------------+-----------------+----------------+----------------+
|                |                 |                |                |
+----------------+-----------------+----------------+----------------+
|                |                 |                |                |
+----------------+-----------------+----------------+----------------+
|                |                 |                |                |
+----------------+-----------------+----------------+----------------+
|                |                 |                |                |
+----------------+-----------------+----------------+----------------+
| Evaluation     |                 |                |                |
|                |                 |                |                |
+----------------+-----------------+----------------+----------------+
| Containment    |                 |                |                |
| Strategy       |                 |                |                |
+----------------+-----------------+----------------+----------------+

RECORD OF AMENDMENTS

  --------- -- ------------------ ---------- --------- ----------------------------------
  Version      Author                        Date      Comments

  1.0                             07/25/05             Draft 1 -- Based on template
                                                       created for VA IT risk control

                                                       

                                                       

                                                       

                                                       

                                                       

                                                       
  --------- -- ------------------ ---------- --------- ----------------------------------

# Risk Management Log Template

Project Name:

  -------- ----------------- ------------- -------- --------------- ----------- -------------
  Risk ID  Threat Event      Probability   Impact   Strategy        Follow-up   Responsible
  Number                                                            Date        Team Member
                                                                                or
                                                                                Responsible
                                                                                Manager

                                                                                     

                                                                                     

                                                                                     

                                                                                     

                                                                                     
  -------- ----------------- ------------- -------- --------------- ----------- -------------

# Staffing Management Plan Template

  ---------------------------------------------------- ---------------------------------------------
  ![](media/image1.png){width="2.0548611111111112in"   **Staffing Management Plan**
  height="1.4166666666666667in"}                       

                                                       Project Name:

                                                       Date: DD Mmmm 20yy

                                                       Project Manager:

                                                       Approver: signature

                                                       Approver Name and Title
  ---------------------------------------------------- ---------------------------------------------

The following are suggested sections for the Staffing Management Plan

Purpose of the Staffing Management Plan

Describe the purpose of the Staffing Management Plan using the following
guidelines. Do not merely describe the content of the plan, but explain
why Staffing Management is necessary for the project.

It takes people to run a project. The Project Manager needs a team to
produce the deliverables and maintain control over the project. Project
Team members need certain skills to become truly productive. The Project
Manager needs to ascertain when new people will be required on the
project or when existing team members will be able to leave. This
Staffing Management plan provides the Project Manager with a framework
to identify and justify human resource needs and provide an effective
work force to accomplish the project work.

Roles and Responsibilities

Describe how the following project participants, at a minimum, perform
in the planning and execution of project communications

-   Project Sponsor

-   Project Manager

-   Project Team

-   Project Stakeholders

Project Organization

Describe the project organization including the project team and
stakeholders. Include the roles and responsibilities of the team members
and stakeholders. An OBS may be developed indicating the responsible
personnel, the department or functional area, the specific activities of
responsibility and may include the associated budget allocation.

An understanding of the organization and stakeholders is also important
in communications planning. This knowledge helps identify the reporting
needs and communications flow within the project. Refer to the
communications plan for a "map" of the communications channels on the
project.

Resource Requirements

An outline of the resource requirements needed to execute the project.
In many cases it is possible to define this based on areas of
responsibility or technical capability. Identified areas such as
engineering, software development, system engineering, etc. should be
listed as well as the necessary skill sets and expertise required within
each area

Project Managers responsible for OMB Exhibit 300 projects are required
to have an extensive knowledge of project management, including all the
discipline areas described in the Project Management Plan, e.g. schedule
management, risk management, change management etc.

Understanding of the project background and requirements is also very
important. This includes the OMB Exhibit 300 requirements, ANSI/EIA 748
A Standards documentation and Circular A-11. These documents can be
found at xx.

All project participants are expected to have knowledge of the USDA
culture, organization, policies and procedures. Communication skills,
both verbal and written, are important in any project environment. Other
soft skills, such as team dynamics, negotiation and facilitation are
assets that are beneficial for any employee.

It is understood that resources may not meet all the knowledge
requirements presented here. As such, employee training has also been
captured as part of this plan, and is also included in the project scope
(WBS) and project schedule. Employees are offered training as their
skill levels and availability permit.

Resource Staffing Plan

Describe what resources are required and when they are required. This
should be graphical in nature and indicate the time phased resource
loading. This is the basis for managing resources and serves to assure
that the project is resource loaded properly.

Resource Constraints

Document any known constraints regarding resources. Constraints may be
project based, defining specific requirements and limitations within the
project objectives, or organizationally based, defining limitations or
requirements of the organization to adequately staff the project and
meet project requirements and needs.

Staffing Reports

Define the reporting frequency and requirements during execution of the
project. Indicate on a time phased basis what resources are required and
when.

Staffing Contingency Plans

Describe the process for developing contingency plans, providing
alternatives should critical resources not be available when required.

Staffing changes are common to all projects. Some of these changes can
be anticipated and some cannot. Contingencies are therefore important to
ensure that project deliverables can still be met when staffing changes
occur. Contingencies should answer questions such as: What happens if
the Project Manager leaves? What if budgets are curtailed?

Training Requirements

Specialized training may be identified and required for project team
members or staffing. These requirements should be defined and planned
into the project.

RECORD OF AMENDMENTS

  --------- -- ------------------ --------- --------- ----------------------------------
  Version      Author                       Date      Comments

  1.0                             7/25/05             Draft 1 -- Based on template
                                                      created for VA IT Staffing
                                                      Management

                                                      

                                                      

                                                      

                                                      

                                                      

                                                      
  --------- -- ------------------ --------- --------- ----------------------------------

# Procurement Management Plan Template

  ---------------------------------------------------- ---------------------------------------------
  ![](media/image1.png){width="2.0548611111111112in"   **Procurement Management Plan**
  height="1.4166666666666667in"}                       

                                                       Project Name:

                                                       Date: DD Mmmm 20yy

                                                       Project Manager:

                                                       Approver: signature

                                                       Approver Name and Title
  ---------------------------------------------------- ---------------------------------------------

The following are suggested sections for the Procurement Management Plan

Purpose of the Procurement Management Plan

Describe the purpose of the Procurement Management Plan using the
following guidelines. Do not merely describe the content of the plan,
but why Procurement Management is necessary for the project:

The organization is unable to create or supply all the products and
services necessary to complete the project and therefore needs to use
external sources that have the expertise in certain areas to assist in
completing all required project deliverables. Procurement planning gives
the project team knowledge and confidence to obtain quality products and
services from qualified vendors in a timely manner.

Roles and Responsibilities

Describe how the following project participants, at a minimum, perform
in the planning and execution of project procurement

-   Project Sponsor

-   Project Manager

-   Project Team

-   Project Stakeholders

-   Contract Office Technical Representative (COTR)

Required Project Procurements and Timing

Discuss the necessity for planned procurements, including the results of
alternative analyses and make or buy analyses. Discuss the best times to
initiate the procurement processes to meet the detailed project
schedule.

Description of Items/ Services to be acquired

Briefly describe the overall scope of the project. What are the specific
items/services/major contract deliverables that will be acquired?

IT Acquisition Process

Discuss initiating a project using the USDA IT Acquisition process.
Describe the required acquisition approvals. Include the use of any
tracking systems and the requirement for supporting documentation.
Examples of the supporting information include: a requirements analysis,
a business case justification, a cost/benefits analysis and a Statement
of Work (SOW).

Solicitation Planning

Describe the responsibilities of the project team and stakeholders in
developing acquisition requests, SOWs, a solicitation strategy, an
evaluation strategy and evaluation criteria.

Period of Performance

Indicate the period of performance in months or years from time of award
with options separately indicated. For example: "Three year base period
with two one-year options."

Applicable Conditions

Indicate any significant conditions, constraints, or assumptions
affecting the acquisition such as the need for:

-   Compatibility with the enterprise architecture, existing or future
    systems or programs

-   Compliance with Section 508, privacy, security, IT investment
    management, and technical review and change control board
    requirements

-   Compliance with known cost, schedule or performance constraints.
    Also include any trade-offs that may need to be made among the
    various cost, schedule, and performance goals

If this is a system acquisition, describe any considerations given to
build-vs.-buy decision, testing and evaluation, implementation,
training, and operation and maintenance.

Background/Recent history of the procurement

If this is the first attempt to acquire the item or service, indicate
"Not applicable." Otherwise, briefly describe the last procurement of
the item or service and the results obtained. How have lessons learned
from that procurement shaped the strategy for this one?

Estimated obligations required

Include the estimated funds required for each fiscal year and total.
Describe the cost model/methodology that was used in developing the
estimates.

Proposed contracting vehicle

Describe the contract vehicle(s) that will be used and the different
items/services to which they will be applied.

Proposed contract type

Describe the contract types that will be used and the different
items/services to which they will be applied.

Performance-based contracting

FAR 7.105 states that "Acquisition plans for service contracts must
describe the strategies for implementing performance-based contracting
methods or must provide a rationale for not using those methods (see
Subpart 37.6)."

Modular contracting techniques

Section 5202 of The Clinger-Cohen Act as implemented in FAR 39.103
addresses the use of modular contract techniques (i.e. the use of one
more contracts to acquire information technology systems in successive,
interoperable increments). If this project is a major system acquisition
and such techniques will not be used, a justification should be
provided. If this project is not a major system acquisition and modular
techniques were not used, indicate "Not a major systems acquisition."

Potential sources

Indicate the prospective sources for the items or services. Describe how
competition will be sought, promoted, and sustained throughout the
course of the acquisition. Include consideration of small business,
veteran-owned small business, HUBZone small business, small
disadvantaged business, and women-owned small businesses. Describe the
results of any market research that was conducted as well as any efforts
to encourage industry participation such as draft solicitations or
pre-solicitation conferences.

Source selection procedures

Describe the source selection procedures for the acquisition, to include
the timing for the submission and evaluation of proposals. Identify the
major evaluation criteria and why they are needed to identify the
proposals that offer the best chances for project success. Describe how
technical, past performance, and cost factors will be ranked to
determine "best value." For example, will technical and past performance
outweigh cost? Describe whether single or multiple awards will be made.

Contract Administration

Describe who will administer the contract. Describe how the contract
will be administered, including roles and responsibilities for
inspection, acceptance, validation and verification of performance.
Describe how invoices will be paid. Describe the process for changing
the contract and controlling the changes. Describe the process for
accepting contract deliverables. Describe the interaction between the
project team and stakeholders with data systems used to maintain
contract data.

Contract Closeout

Describe the formal acceptance of contracts and closure. Describe the
alternative means for closing the contract without formal acceptance.
Describe the archiving of contract documentation. Describe the use of
procurement audits to identify successes and lessons learned.

RECORD OF AMENDMENTS

  --------- -- ------------------ --------- --------- ----------------------------------
  Version      Author                       Date      Comments

  1.0                             7/25/05             Draft 1. Based on template created
                                                      for VA IT Project Procurement
                                                      Management

                                                      

                                                      

                                                      

                                                      

                                                      

                                                      
  --------- -- ------------------ --------- --------- ----------------------------------

# Project Closeout Report Template

  ---------------------------------------------------- ---------------------------------------------
  ![](media/image1.png){width="2.0548611111111112in"   **Project Closeout Report**
  height="1.4166666666666667in"}                       

                                                       Project Name:

                                                       Date: DD Mmmm 20yy

                                                       Project Manager:

                                                       Approver: signature

                                                       Approver Name & Title
  ---------------------------------------------------- ---------------------------------------------

The following are suggested sections for the Project Closeout Report:

Purpose of Closeout Report

Describe the purpose of the Closeout Report using the following
guidelines:

The closeout report insures that personnel, contract, administrative,
and financial issues are resolved, that documents are archived, and
lessons learned are captured.

Administrative Closure

Were the objectives of the project met?

Review the project objectives and indicate if the objectives were met.
If there were deviations from the baseline objectives and the final
product, describe those here.

Archiving Project Artifacts

Describe how project documents will be collected and archived for future
reference. Documentation to consider:

-   Financial records

-   Cost and schedule performance reports and records

-   Quality data

-   Correspondence

-   Meeting Notes

-   Status Reports

-   Issue and Action Log

-   Risk Log

-   Contract Files

-   Change Requests

-   Technical documents

-   Acceptance records

Lessons Learned

Conduct a lessons learned session to discuss and capture the performance
(e.g., what worked well, what didn't work well) from start to finish on
the project. Capturing and incorporating lessons learned on future
projects are among the most important ways in which an organization
gathers information to institutionalize repeatable processes and avoid
repeated mistakes.

Plans for Post Implementation Review (PIR)

Describe the plan to conduct the Post Implementation Review (PIR).

Final Customer Acceptance

Describe the achievement of final customer acceptance. Describe the
final meeting with customer, who attended and what disciplines were
represented (finance, contracts, quality, etc.) Discuss the documents
signed. If open issues remain discuss the plan for their resolution.

Financial Records

Discuss the review of invoices, purchase orders, and final cost
reporting. Describe where the final cost records are archived.

Final Project Performance Report

Summarize the project's scope management, schedule performance, cost
performance, quality achievements and a review of the risk containment
performance. Discuss the reasons for cost or schedule variances.

Contract Closure

Resolution of Contract Open Issues

Describe any open contract issues and the plans to obtain closure to the
issues.

Collection and Audit of Contract Documents

Contract closure is essentially a collection and audit of the contract
documentation. Documentation to be collected includes but is not limited
to:

-   Original contracts

-   Contract changes

-   Schedules

-   Performance reports

Describe the plan and actions for closing any contracts and associated
tasks.

RECORD OF AMENDMENTS

  --------- -- ------------------ --------- --------- ----------------------------------
  Version      Author                       Date      Comments

  1.0                             7/25/05             Draft 1. Based on template created
                                                      for VA IT Project Closure

                                                      

                                                      

                                                      

                                                      

                                                      

                                                      
  --------- -- ------------------ --------- --------- ----------------------------------

##