Program Management Plan Template

Think Next. Now.
<PROGRAM NAME>
Program Management Plan
<Date>
CSRA, Inc.
3170 Fairview Park Drive
Falls Church VA 22042
PH: (703) 641-2000
Program Management Plan (PMP) TE 9001.01.07.12, Rev. 2
Table of Contents
INSTRUCTIONS: ....................................................................................................................... 1
1 Introduction ......................................................................................................................... 2
1.1 Program Definition (PD) ............................................................................................... 2
1.1.1 Contract / Program Details .................................................................................... 2
1.1.2 Client Business Objectives.................................................................................... 3
1.1.3 CSRA Program Objectives.................................................................................... 3
1.1.4 In-Scope Functions ............................................................................................... 4
1.1.5 Out of Scope Functions ........................................................................................ 5
1.1.6 Deliverables .......................................................................................................... 5
1.1.7 Management Approach......................................................................................... 6
1.1.8 Technical Approach .............................................................................................. 8
1.1.9 Initial Risks and Issues ......................................................................................... 8
1.1.10 Constraints ..........................................................................................................10
1.1.11 Assumptions ........................................................................................................10
1.1.12 General Equipment and Facility Needs ................................................................11
1.2 Estimates ....................................................................................................................11
1.3 Program Work Breakdown Structure (WBS) and Schedule .........................................11
1.4 Program Budget ..........................................................................................................12
1.5 Performance Measurements .......................................................................................12
Supplemental Management Plans .........................................................................................13
2 Governance Plan ...............................................................................................................13
2.1 Organization Charts ....................................................................................................13
2.2 Roles, Responsibilities and Stakeholders ...................................................................13
2.3 Face-Off Diagram .......................................................................................................14
2.4 Staffing Matrix and Profile ...........................................................................................15
2.5 Issues Escalation ........................................................................................................16
2.6 Program Communications...........................................................................................16
3 Security Plan ......................................................................................................................17
4 Continuity Plan ...................................................................................................................21
4.1 Continuity Responsibility Assignments ........................................................................22
4.2 Continuity Management Staffing Requirements ..........................................................22
4.3 Notification Tree ..........................................................................................................22
4.4 Prioritized Continuity Processes..................................................................................23
4.5 Process Details for Areas of Responsibility .................................................................24
4.6 IT Tools, Applications, Input / Output Data, and Special Instructions ..........................25
Page ii
CSRA Proprietary Information. This document shall not be disclosed, duplicated, or used, in whole or in part, outside of CSRA
without written management approval. When using this controlled tool, verify that it is the current version available in the
CSRA Process and Knowledge Center. Delete obsolete versions unless retained as a historical record.
4.7 Required Vital Records ...............................................................................................26

5 Technology Control Plan ....................................................................................................26
6 External Supplier / Subcontractor Management Plan .........................................................26
7 Program Training Plan .......................................................................................................27
8 Risk, Issues and Opportunity Management Plan ................................................................28
8.1 Risk Management .......................................................................................................28
8.1.1 Program Risk Management Strategy ...................................................................29
8.1.2 Risk Identification .................................................................................................29
8.1.3 Risk Analysis .......................................................................................................30
8.1.4 Risk Monitoring and Reporting .............................................................................34
8.1.5 Risk Status and Thresholds .................................................................................35
8.1.6 Risk Severity Levels.............................................................................................36
8.1.7 Risk Process Effectiveness Measures .................................................................38
8.1.8 Minimizing Cost and Schedule Impacts................................................................38
8.1.9 Reporting .............................................................................................................38
8.2 Issues Management....................................................................................................40
8.3 Opportunities Management .........................................................................................41
9 Contract Change Management Plan ..................................................................................42
9.1 Client-Initiated Changes ..............................................................................................42
9.2 CSRA-Initiated Changes .............................................................................................43
10 Asset, Configuration and Data Management Plan ..........................................................43
10.1 Asset Management .....................................................................................................44
10.2 Configuration and Technical Change Management.....................................................44
10.2.1 Plan the Configuration Management System .......................................................45
10.2.2 Configuration Identification...................................................................................47
10.2.3 Configuration Change Control..............................................................................47
10.2.4 Configuration Status Accounting (CSA) ...............................................................48
10.2.5 Configuration Reviews and Audits .......................................................................48
10.3 Document / Data Management ...................................................................................48
11 Measurement Plan .........................................................................................................49
12 Continuous Improvement ...............................................................................................50
12.1 Recommendations for Improvement Opportunities .....................................................52
12.2 Continuous Improvement Performance Metrics ..........................................................53
12.3 Continuous Improvement Activities to Implement ........................................................54
12.4 Cost Effectiveness ......................................................................................................55
12.5 Continual Re-Evaluation of Methods ...........................................................................56
13 Program Quality Plan .....................................................................................................57
Page iii
13.1 <Program> Quality Organization .................................................................................57

13.2 Independence .............................................................................................................58
13.3 Responsibilities ...........................................................................................................58
13.4 Schedule .....................................................................................................................59
13.5 Quality Assurance Measurements ..............................................................................59
13.6 Audits..........................................................................................................................60
13.6.1 Process Audits .....................................................................................................60
13.6.2 External Audits.....................................................................................................61
13.7 Program Product Reviews ..........................................................................................61
13.7.1 Informal Deliverable Reviews ...............................................................................62
13.7.2 Deliverable Peer Reviews ....................................................................................62
13.7.3 Peer Review Schedule .........................................................................................62
13.7.4 Peer Review Preparation .....................................................................................62
13.7.5 Conducting a Peer Review...................................................................................62
13.7.6 Peer Review Results............................................................................................62
13.7.7 Peer Review Reporting ........................................................................................62
13.7.8 Peer Review Artifacts...........................................................................................62
13.8 QA Deliverable Reviews .............................................................................................63
13.8.1 QA Deliverable Review Schedule ........................................................................63
13.8.2 QA Deliverable Review Preparation .....................................................................63
13.8.3 QA Deliverable Review Focus (Draft Version)......................................................63
13.8.4 Conducting a QA Deliverable Review (Draft Version) ..........................................63
13.8.5 QA Deliverable Review Focus (Final Version)......................................................64
13.8.6 Conducting a QA Deliverable Review (Final Version) ..........................................64
13.8.7 QA Deliverable Review Outcome .........................................................................64
13.8.8 QA Deliverable Review Artifacts ..........................................................................64
13.8.9 QA Deliverable Review Reporting ........................................................................64
13.9 Quality Management Product Reviews .......................................................................64
13.9.1 QA Product Review Schedule ..............................................................................65
13.9.2 QA Product Review Preparation ..........................................................................65
13.9.3 Conducting a QA Product Review ........................................................................65
13.9.4 QA Product Review Results .................................................................................65
13.9.5 QA Product Review Artifacts ................................................................................65
13.9.6 QA Product Review Reporting .............................................................................65
13.9.7 Quality Management Records and Reports .........................................................65
13.9.8 Quality Records ...................................................................................................66
13.9.9 Quality Reports ....................................................................................................66
Page iv
13.10 Non-compliance Remediation..................................................................................66

13.10.1 Action Items .....................................................................................................67
13.10.2 Corrective Action ..............................................................................................67
13.11 Quality Management Escalation ..............................................................................67
14 Program Verification Plan ...............................................................................................68
14.1 Verification Strategy ....................................................................................................68
14.2 Verification Process ....................................................................................................68
15 Program Validation / Acceptance Plan ...........................................................................69
15.1 Validation / Acceptance Process .................................................................................70
16 Decision Analysis and Resolution ...................................................................................70
16.1 Define the Issue to be Resolved .................................................................................72
16.2 Assign a Lead and Plan the DAR Effort ......................................................................72
16.3 Establish Evaluation Criteria .......................................................................................72
16.4 Identify Alternative Solutions .......................................................................................72
16.5 Select Methods for Evaluating Alternatives .................................................................72
16.6 Evaluate Alternatives ..................................................................................................72
16.7 Select Solution ............................................................................................................72
16.8 Capture Results and Archive ......................................................................................73
17 Program Completion Plan ..............................................................................................73
17.1 Establish Closure ........................................................................................................73
17.2 Capture Program History ............................................................................................74
17.3 Capture Lessons Learned ...........................................................................................74
17.4 Redeploy Program Staff ..............................................................................................74
17.5 Inventory, Release and Archive Program Assets ........................................................75
17.5.1 Close Down Physical Environment ......................................................................76
17.6 Close Down the Program ............................................................................................76
17.6.1 Complete Program Closedown Checkpoint ..........................................................77
Tools and Templates.................................................................................................................78
Reference Table .......................................................................................................................79
Document Approval / Change History .......................................................................................80
Appendix A ...............................................................................................................................81
Program Management Plan Completion Guide .........................................................................81
Introduction ...............................................................................................................................81
1 Program Plan .....................................................................................................................82
1.1 Program Definition (PD) ..............................................................................................82
1.1.1 Contract / Program Details ...................................................................................82
1.1.2 Client Business Objectives...................................................................................82
Page v
1.1.3 CSRA Program Objectives...................................................................................83

1.1.4 In-Scope Functions ..............................................................................................83
1.1.5 Out of Scope Functions .......................................................................................84
1.1.6 Deliverables .........................................................................................................84
1.1.7 Management Approach........................................................................................84
1.1.8 Technical Approach .............................................................................................86
1.1.9 Initial Risks and Issues ........................................................................................86
1.1.10 Constraints ..........................................................................................................87
1.1.11 Assumptions ........................................................................................................87
1.1.12 General Equipment and Facility Needs ................................................................88
1.2 Estimates ....................................................................................................................88
1.3 Program Work Breakdown Structure (WBS) and Schedule .........................................88
1.4 Program Budget ..........................................................................................................89
1.5 Performance Measurements .......................................................................................89
Supplemental Management Plans.............................................................................................90
2 Governance Plan ...............................................................................................................90
2.1 Organization Charts ....................................................................................................90
2.2 Roles, Responsibilities and Stakeholders ...................................................................90
2.3 Face-Off Diagram .......................................................................................................91
2.4 Staffing Matrix and Profile ...........................................................................................91
2.5 Issues Escalation ........................................................................................................92
2.6 Program Communications...........................................................................................92
3 Security Plan ......................................................................................................................94
4 Continuity Management Plan .............................................................................................95
4.1 Continuity Management Responsibility Assignments ..................................................95
4.2 Continuity Management Staffing Requirements ..........................................................95
4.3 Notification Tree ..........................................................................................................95
4.4 Prioritized Continuity Processes..................................................................................95
4.5 Process Details for <Program’s> Areas of Responsibility ............................................95
4.6 IT Tools, Applications, Input / Output Data, and Special Instructions ..........................96
4.7 Required Vital Records ...............................................................................................96
5 Technology Control Plan ....................................................................................................96
6 External Supplier / Subcontractor Management Plan .........................................................96
7 Program Training Plan .......................................................................................................97
8 Risk, Issues and Opportunity Management Plan ................................................................98
8.1 Risk Management .......................................................................................................98
8.2 Issues Management....................................................................................................99
Page vi
8.3 Opportunities Management .........................................................................................99

9 Contract Change Management Plan ..................................................................................99
9.1 Client-Initiated Changes ..............................................................................................99
9.2 CSRA-Initiated Changes ...........................................................................................100
10 Asset, Configuration and Data Management Plan ........................................................100
10.1 Asset Management ...................................................................................................101
10.2 Configuration and Change Management (CM) ..........................................................101
10.3 Data Management ....................................................................................................103
11 Measurement Plan .......................................................................................................104
12 Continuous Improvement .............................................................................................104
13 Program Quality Plan ...................................................................................................104
14 Program Verification Plan .............................................................................................106
15 Program Validation / Acceptance Plan .........................................................................106
16 Decision Analysis and Resolution .................................................................................107
17 Program Completion Plan ............................................................................................107
Tools and Templates...............................................................................................................109
Reference Table .....................................................................................................................110
Page vii
DELETE THESE INSTRUCTIONS IN THE ACTUAL WORK PRODUCT

INSTRUCTIONS:
Completing the Program Management Plan
This Program Management Plan template contains examples of possible ways to complete the
sections of a program PMP. Program personnel should review the examples, and tailor the
language to accurately reflect how their program operates. The PMP template is written at the
program level only; Individual projects within the program must have standalone Project
Management Plans (Refer to Project Management Plan template).
The present verbiage may contain more activities than the program plans to perform; it is
perfectly acceptable to note “Not Applicable” to entire sections. For continuity, section
headers, however, should be maintained “as-is” in accordance with the template structure and
table of contents.
The Supplemental Management Plans (i.e. sections 2 through 17) may or may not apply,
depending on the program’s scope. In addition, if applicable, they may be documented within
this PMP artifact, or written as separate plans, as appropriate.
Please note: Additional guidance for completing the PMP template is available in Creating a
Comprehensive Program Management Plan Using CSRA’s PMP Template training materials
and “Appendix A - Program Management Plan Completion Guide” contained within this
template. Please be sure to delete the Appendix (as well as these Instructions) prior to
delivering the completed template to the client.
Page 1
1 Introduction
The Program Management Plan (PMP) addresses CSRA’s approach, organization, and
reporting requirements for providing the products and services under the <> contract.
The PMP is the top-level management plan and is used for guiding the planning, management,
control, and reporting of work performed by CSRA under our contract with <>.
The PMP presents the principles, tools, and processes we use to manage the <Program>
effectively. It reflects how and when the program’s objectives are achieved by showing the
major deliverables, milestones, activities, and resources required for the program. It describes
the processes for ensuring adherence to relevant policies, standards, guidelines, and
procedures.
The PMP defines what is to be done with respect to program management, how and when it is
to be done, and by whom.
The PMP is a living document, reviewed annually, and updated as necessary.
1.1 Program Definition (PD)
The PD describes the overall scope, approach, and methodology that CSRA will undertake to
<provide description of the program>.
1.1.1 Contract / Program Details
The Contract / Program Details table below provides essential contract information:
Table 1 Contract / Program Details Table

Contract / Program Details
Contract Type:
(e.g. Cost Reimbursable, Time and
Materials and Fixed Price)
Award Date:
Period of Performance (POP):
Vehicle (Program):
Contract Number:
CSRA’s Role:
(Prime or Subcontractor)
CSRA Subcontractor(s) Name:
CSRA Job Number:

Program Type: (identify all that apply)
- Staff Augmentation (STA),
Page 2
- Services (SVC),
- Enterprise Architecture (EA),
- Systems Engineering Services
(SE),
- IT Service Management (ITSM),
- System and Software Development
and Maintenance (SSDM)
Client Organization:
Client Name:
1.1.2 Client Business Objectives
Following are the <Client Name> business objectives:
<List>
* Objective …
* Objective …
* Objective …
Examples:
- Transfer Services: Transfer of services and support from <Incumbent Name> to CSRA to be
seamless and must occur by the Services Commencement Date <date>.
- Create structure and processes: The structure and processes implemented in the Transition
program should support the on-going needs of the outsourced services solution.
- Execute Transition program: Establish the processes, procedures, actions, and timetables for
migrating support responsibilities to CSRA with minimal impact to current services.
- Reduction in operating costs year-over-year from original baseline.
- Develop a foundation on which to build for future IT sourcing in support of a <Client Name>
sourcing strategy.
- An architecture and network structure that allows flexibility for changes.
- Decreased risk of operations.
1.1.3 CSRA Program Objectives
This section defines the program team’s objectives with expected outcomes at program
completion. See Table 2 below:
Table 2 Program Objectives

Objective ID Objective Objective Measure / Outcome
1 Example: Cost and Example: Complete 100% of all tasks / projects on or before
Schedule Performance agreed to schedule.
100% on budget for tasks / projects at or below agreed to
costs.
Page 3
2 Example: Client Example: Client Satisfaction a minimum of 90% Outstanding

Satisfaction / Exceptional Ratings.
3 Example: Service Level Example: Meet or exceed all contractual SLAs (See
Agreements (SLAs) Measurement Plan).
4 Example: Process Example: Achieve CMMI Level 3, Maintain ISO-9001

registration.
5 Example: Business Example: Maintain business continuity: The most critical

Continuity objective throughout the transition of <Client Name>’s IT
services to CSRA management is business continuity and
avoidance of unscheduled disruption. CSRA will coordinate
with <Client Name> to communicate necessary planned
outages to impacted users.
6 Example: Quality Example: Deliver quality products: Compromises on quality
ultimately lead to productivity issues within the programs
and user dissatisfaction with the system.
1.1.4 In-Scope Functions

“In-Scope” functions critical to the <Program> includes the following changes in the client’s “as
is” environment to the desired “to be” environment:
<List>
* Change … “as-is” to “to-be” …
* Change … “as-is” to “to-be” ….
* Change … “as-is” to “to-be” ….
Examples:
1. Business Process - What opportunities exist to improve current processes to
enhance business performance?
2. Organization - What change in culture, capabilities, roles, and training is needed to
accomplish the necessary business change?
3. Location - What is needed in terms of geographic distribution of processes, people,
technical infrastructure, data, and applications?
4. Data - What information content and structure is necessary to meet the business
requirements?
5. Application - What application design best fulfills the requirements and how should
the application be developed, integrated, tested, and deployed?
6. Technology - What is the hardware, system software, and communication network
components needed to support the business and its systems?
The “In-Scope” critical functions also include a continuation of the client’s “as is” environment,
as follows:
<List>
* Maintain current activity …
Page 4
1.1.5 Out of Scope Functions

“Out of Scope” functions excluded from the program include:
<List>
* Function …
* Function …
* Function …
1.1.6 Deliverables
The following items are <Program> contractual deliverables, which will be provided to the
customer for acceptance:
<List>
* Deliverable …
* Deliverable…
* Deliverable …
Salesforce will be used by the program to track deliverable completion status.
1.1.6.1 Deliverable Acceptance

All of the completed deliverables identified in the <Program> deliverables list will be formally
submitted for final review and customer approval in accordance with contract requirements.
Table 3 documents the Deliverables Acceptance criteria.
For further information about Acceptance, see Project Validation / Acceptance Plan.
Table 3 Deliverables / Acceptance
Deliverable Deliverable Description Responsible Date and Acceptance Criteria /
Format Due Date
Example: Example: Monthly Status Report PM Monthly, MS Example: Monthly Status
Monthly Status (MSR) documents the program’s Word Report (MSR) must be
Report activities for the past month. delivered by the last
Includes Deliverables, Risks, Friday of the month, NLT
Issues, Staffing, Action Items. COB.
Example: White Example: Analysis of a given SME As Example: White Papers
Paper topic by a Subject Matter Expert, requested, must have been peer
as requested. MS Word reviewed and certified
prior to delivery.
Page 5
1.1.7 Management Approach
CSRA is responsible for program management and providing the necessary resources to the
program. Management objectives are focused on tightly monitoring, controlling, and reporting
the progress status of the program along with balancing the program’s three key constraints:
scope, budget, and schedule.
To be effective in achieving this primary management objective, the following will be

established:
1) An agreed-upon baseline – Developing a program Work Breakdown Structure (WBS)

and associated work packages including Earned Value methods.
The project will implement the CSRA Integrated Program Management Process (IPMP)
standard for Earned Value.
A detailed program schedule for all the work activities to be performed on the program will be
created. Every activity will have an estimate of work effort.
Once all the activities are allocated to team members, the program schedule is leveled
and loaded against the calendar. This completed schedule represents the baseline
schedule. This schedule will provide the key milestone dates to track schedule
progress.
The summation of all activity costs from the baseline program schedule will represent
the budget that the CSRA / <Client Name> management team will track.
2) A process to monitor progress – The detailed program schedule is the key vehicle for
measuring progress. The specific activities that each team member works on, and their
progress against completing those activities, are the only objective measure of where
the program stands against the schedule and budget.
This information will be recorded on a weekly time sheet and given to the appropriate
manager along with a status report that provides a brief description of work
accomplished, issues / problems, and planned work. The management team will
determine where the program stands versus the schedule and budget by analysis of this
information.
In addition, the program will be monitored by tracking the timeliness and quality of
contractual deliverables and which program is delivering each deliverable.
3) Defined processes and practices – The management processes and practices to be

used and the interrelationship between the processes will be defined.
The program’s defined processes and practices are identified on the <Program> Process
Assurance Cycle (PAC) Checklists used to document the program’s process and tailoring
decisions for adopting the CSRA organizational process baseline. The <Program> will
implement the CSRA Perform Project Tailoring Procedure.
4) A clear means of communication – A formal process is used to ensure timely and

accurate communication between CSRA and the <client>.
See Program Communications section for further details

Page 6
5) An open approach for dealing with issues – Issues are defined as:
 something that needs to be addressed immediately that could have an impact to
program schedule, budget or resources, and
 Something that is outside the scope of authority to resolve by the <Program> team.
See Issues Management section for further details.
6) An objective program change control procedure – This process is the primary vehicle for
containing scope and ensuring that management has the opportunity to make timely
trade-offs between the three key program variables of cost, time and scope.
Changes are broadly defined as work activities or work products not originally planned
for, as defined by the contract. More specifically, changes will include:
* Any scope items not listed in the program contract.
* Participation in activities not previously included in the the master schedule
* Provision or development of deliverables not included in the specific contract.
* A change in responsibilities, as defined in the contract between CSRA and <Client

Name>, including reallocation of program staffing.
* Any rework of completed activities or accepted deliverables.
* Investigative work to determine the impact of major changes.
* Impact caused by a change in the assumptions section
* Impact of any risk items.
* Delays or rework caused by items identified in the contract as <Client Name>

responsibilities or activities.
* Delays created by customer’s request to change the schedule requested or caused by

customer’s inability to meet its commitments.
* Delays caused by a change in previously agreed-upon acceptance criteria.
See Contract Change Management section for further details.
7) A process to recognize and manage risks and opportunities – An open approach for
dealing with Risks, which are defined as events that may have an unfavorable impact on
the work. A risk is something that has not yet happened but the occurrence or
nonoccurrence could negatively impact the program in terms of: scope, quality, budget,
or timeline.
See Risk Management section for further details.
Page 7
8) An approach for accepting program deliverables – All of the completed deliverables

(Section 1.1.6) will be formally submitted for final review and Client approval. The key
components to this acceptance process are:
* Client COTR is identified as the acceptor.
* Each contract deliverable and milestone has a documented acceptance criterion
* Timeframe for acceptance / rejection will be <x> Days, unless specifically agreed
otherwise.
* Deliverables will be deemed accepted if the acceptance timeframe is exceeded.
9) A definition of what constitutes program completion – Program completion is defined as

documented acceptance of all contract deliverables by the customer.
See Program Completion section for further details
1.1.8 Technical Approach

The technical approach the <Program> will employ:
Examples:
 system development life cycle (e.g. Agile SCRUM, Agile Kanban, Agile SAFe,
Waterfall, The program will implement CSRA Process PC 5050.01 Product
Engineering)),
 service life cycle (e.g., ITIL life-cycle) The program will implement CSRA Process
PC 5030.01 IT Service Management,
 architectural concept (e.g., DoDAF),
 implementation activities,
 releases,
 phases,
 sub-phases,
 major milestones, and
 acceptance points.
1.1.9 Initial Risks and Issues

Following are the initial set of risks for this program. Ongoing risk management is described in
the Risk Management section.
Page 8
Table 4 Initial Set of Program Risks

Potential Effect on Probable
Initial Risks Program Impact Risk Mitigation Strategy
[Risk Description] [If the risk comes [High, [What will be done to reduce the
to pass, what Medium, probability of the risk occurring]
effect will it have] Low]
Business changes CSRA need to Low CSRA will work with Client to amend the
before or during change Transition Transition Plan using the contractual
Transition program plans change management approach to support
the business change.
Delays related to Changes in program Medium Use change management process to
service migrations or process design or determine new dates for affected migration.
caused by business strategy Notify Client of issues as soon as they are
identified.
Lack of support from Delay in programs, Medium CSRA will work with Client to agree on
Client’s retained IT or process requirements and expectations during
incumbent service development etc. further planning activities.
provider organizations
to support Transition
activities
Delay in review or Delay in start of Low Set expectations and timeliness for Client
approval or sign-off by activities of next response.
Client phase
Site access blocked Delay in start of Medium CSRA will work with Client to agree on
activities of next requirements and expectations during
phase further planning activities.
Delay in access to Delay to start the Medium Provision of list of people needing access
Client facilities, migration or Provision of type of access needed for
systems etc. program CSRA personal working for Client
implementation
Lack of documentation Impact program and Low Baseline the available documentation
on IT environment, process Plan advance meetings and expectation of
current process, implementation time require from Client and its IT providers
applications, etc.
Unscheduled outages Impact on end-users Low Hour-by-hour plans for all activities of
due to task / activity to access program.
failures applications, data Change to be scheduled to conform to
etc. current maintenance windows.
Any major Impact on end-users High Fallback plans for all critical changes
dependencies not to access
discovered applications, data
etc.
Delays related to Changes in program Low Use change management process to
service change caused or process design or determine new dates for affected migration.
by technology, or other strategy Notify Client of issues as soon as they are
delays identified.
Page 9
1.1.10 Constraints
Constraints are listed in Table 5 below.

Table 5 Constraints
Constraint Constraint Type Description of Constraint
ID
1 Example: Technical Example: Client requires the use of Open Source COTS
Limitation software
2 Example: Geographic Example: Client requires that all personnel are physically
Limitation located within 30 miles of the Washington DC Metro area
3 Example: Dependencies Example other organizations to provide either work or
deliverables by a certain time
4 Example: Dependencies Example: Scheduling around Client business freeze periods
and disaster recovery window or IT changes
5 Example: Dependencies Example: Key personnel availability due to business

requirements, company holidays, vacations and/or working
hours etc. across multiple countries
6 Example: Dependencies Example: other programs to provide information that
this program is reliant on
7 Example: Dependencies Example: work being performed by a certain date so

that tasks can begin.
8 Example: Technical Limitation Example: Security-related contractual limitations,

requirements and responsibilities for approval
9 Example: Cost Client budget is limited by statute
10 Example Schedule Client has annual cycle control controlled by statute
1.1.11 Assumptions
Assumptions are listed in Table 6 below.
Table 6 Assumptions
Assumption Description of Assumption
ID
1 Example: Client requires the use of Open Source COTS software.
2 Example: Client requires that all personnel are physically located within 30 miles of the
Washington DC Metro area.
Page 10
3 Example: CSRA and Client will work with communications team to communicate to end users
regarding change in service per the program plan.
4 Example: Program assigned personnel will have access site(s)
5 Example: CSRA and Client will work with communications team to communicate to end users
regarding change in service per the program plan.
1.1.12 General Equipment and Facility Needs

The program requires a minimum of a <> clearance to work the program.
The program also requires a <unclassified or classified> secured facility in the < area(s) to
house <x> employees.
Each program employee will require a work station, telephone and a work area.
The facility will require a <certified SCIF and Server Room>.
The facility will require space for a < development and test or other defined> environment.
Government Furnished Equipment will include:
<List>
…GFE x…
…GFE y…
…GFE z…
See Table 7 below as a guide for planning for program tools.
Table 7 Sample Tool Matrix

Resource Item No. Source Availability / Need Applicable Standard
Date
CSRA RIOM Tool 1 CSRA Immediate / Jan 17 User Manuals
Peer Review Tracking 1 CSRA User Manual
System Immediate / Jan 2017
Work Stations 50 CFE Jan 2017 / Apr 2017 User Manuals
1.2 Estimates
The estimation method used to estimate the duration, cost and size of the <Program> was <>.
Examples:
Historical Data
Expert Judgement
Parametric Tool
Estimation data is maintained in <repository>.
1.3 Program Work Breakdown Structure (WBS) and Schedule

The <Program> will utilize MS Project as its primary scheduling tool. MS Project will provide a
breakdown of program activities detailing the work required to successfully complete the
Page 11
program, including all program contractual milestones and deliverables, internal scheduled
events, as well as summary tasks from the detailed schedules.
Schedules will be maintained to _ level of the WBS.
The program schedule will also identify the planned allocation of resources and budgets to
perform each activity across the program continuum, with various dependencies linked to
scheduled events.
The program will implement the CSRA Develop Project Schedule procedure. Schedules will be
monitored and controlled by the Program Control Office.
In addition to using MS Project, the program will employ Earned Value Management (EVM).
EVM will focus on managing the scope, costs and schedule to remain as close to the forecast
as possible.
The program will use <> as its EVM tool. The program will implement the Integrated Program
Management Process (IPMP).
1.4 Program Budget

The <Program> will utilize Cost Point as its primary financial reporting tool.
Budgets will be maintained to _ level of the WBS. Cost and financial performance will be
monitored and controlled by the <Program’s> Program Control Office.
The <Program> cost reporting requirements to the client are <>.
1.5 Performance Measurements

The program will implement the following performance measurement processes and techniques
to monitor performance.
 Service Level Management (SLM)
 Earned Value Management
 Schedule Management
 Quality (Defect Prevention and Detection)
 Process
 Release Data
 Agile.
See Measurement Plan for detailed measurement approach.
Page 12
Supplemental Management Plans

Supplemental program management plans are provided in the subsections below.
2 Governance Plan
The intent of the Governance Plan is to establish mutually agreed upon organization structure,
communication and escalation methods, paths and frequency, and relationship management for
all stakeholders so that issues may be resolved as quickly as possible.
The Governance Plan includes:
 the Organization Charts that document the personnel on the program,
 descriptions of the Roles, Responsibilities and Stakeholders,
 a definition of the Face-Off Diagram / Strategy between the customer and CSRA,
 a definition of the Issues Escalation process, and
 methods to be employed to manage stakeholder relationships.
 Communications plan
2.1 Organization Charts

Figure 1 is the program organization chart and a client organizational chart.
Figure 1 Program Organization Chart
2.2 Roles, Responsibilities and Stakeholders

The Client, CSRA Management and CSRA Program Team stakeholders are listed in Table 8
below.
Table 8 Sample Stakeholder Identification Matrix

Stakeholder Responsibility Information Needs
e.g., COTR Technical Execution of the Contract Program performance status,
technical issues and risks
e.g., CSRA Account Manager Establish and Maintain Client Clients Points of Contacts,
Page 13
relationships Responsibilities and Interests

e.g., Program Team Deliver Contract requirements Understanding of program approach
and processes for delivery
Etc. Etc. Etc.
Stakeholder Involvement is provided in the RACI Matrix, Table 9 below.

Table 9 Sample RACI Matrix
Activity/Role
Role …
Role n
Role 1
Role 2
Activity 1
Activity 2
Activity …
Activity n
Role Key [Fill out the table using the following role keys.]
Key Title Degree of Interaction
R Responsible This Role(s) has the responsibility for doing the work to
accomplish the activity.
A Accountable This Role(s) is answerable for the quality of the work and/or the
results of the work, i.e., the authority to approve the work.
C Consulted This Role(s) has the information or skills needed to complete the
work. Roles that are consulted may provide information or
perform aspects of the activity.
I Informed This Role(s) is notified of progress or results but is not consulted
on the performance of the work.
2.3 Face-Off Diagram

Figure 2 provides the CSRA- customer face-off strategy that identifies which roles on the
program team communicate with which roles on the client team.
Page 14
Figure 2 Sample Client Face-Off Diagram

Government Program
Manager Program
Manager
COTR
Project or Functional
Manager
PMO and
Government PMO Contracts
and Contracts
Man
Manager
Government Quality Manager
Quality Manager
Government Task Task Order

Order Manager
Manager
The program identifies many of the CSRA and Client interactions in Salesforce at <Salesforce
reference>.
2.4 Staffing Matrix and Profile

Table 10 provides the staff matrix and profile.
Table 10 Sample Staffing Matrix

Staff Position No. Source Need Date Need by Life-cycle phase
PM 1 CSRA June 2017 All
DPM 3 CSRA Dec 2017 All
Business Analysts 20 Subcontractor xyz January 2017 Requirements Dev through Test
Developers 10 CSRA April 2017 Design through Test
CM 1 CSRA April 2017 All
Page 15
2.5 Issues Escalation
Issues which have a potential negative impact of greater than _% added time, greater than _%
added cost, or will affect achievement of any prioritized business functional objectives will
immediately be reported up at least one level by the Owner, even if resolution actions remain
with the Owner.
Unresolved Issues which are more than x days past their ‘Resolve By’ date will be escalated up
one level, unless the issue analysis and problem solving effort was determined to take more
than x days.
Issues raised by the client are escalated in accordance with Policy 7015 Significant Incident
Reporting.
2.6 Program Communications

The communications flow within, to, and from the project and identifies the stakeholders and
what they need to know, including program-specific customer-required communication
requirements.
Table 11 provides the overall Communications flow for the program.
Table 11 Sample Communications Template

Communication
Distribution Document
Type of Communication How Communication is
Audience Frequency Controlled (Y /
Communication Owner Distributed
N)
Internal External
Client / CSRA CSRA Deliverable CSRA Meeting Notices, Minutes As Required

X X Y
Technical Team Members Deliverable stored in project per project
Page 16
Meetings and Client Points Owner repository

of Contact (SMEs
& PMs)
Meeting Notices, Minutes
Client Review CSRA Program when applicable stored in
Client / CSRA Weekly X X Y
Meetings Manager stored in project
repository
Through CSRA contracts
Contract CSRA Program As required
Stakeholders via formal cover letter / X X Y
Deliverables Manager by contract
email
Milestone Summary
Schedule reviewed weekly
Performance to at Client l Meeting.
Stakeholders PCO Weekly X X N
Schedule Metric Milestones for each
Deliverable is reflected in
Weekly Status Report
CSRA Program PCO distributes via
Weekly Status
Stakeholders Manager , & email; stored in project Weekly X X N
Report
PCO repository
PCO distributes notice
Program CSRA.Executive CSRA & via email; PMR stored in
Per Policy
Management Mgmt., Program Program Insight Refer to CSRA X N
9001
Review Review Authority Manager Program Management
Review procedure
There are two key vehicles for providing this communication: a <daily, weekly, or monthly>
status report and a <daily, weekly, or monthly> status meeting.
The Program Manager will report progress and status no less than the contractual frequency
and more frequently as circumstances dictate. This information, and the analysis of it, will be
summarized into a program status report for <Client Name> and CSRA Management.
This report will contain the following information:
* Progress Summary – Schedule status.

* Status Lights (Green – Yellow – Red)
* % Program completed
* Accrual % complete
* This week Accomplishments
* Planned Accomplishments
* Number of Deliverables completed (e.g. 3 out of 5 – How many on schedule and how
many late).
* Original / Revised target date for incomplete deliverables.
* Risks and Status.
* Issues and Status
* <Client Name> Resource requirements
The program status meeting will be used to review the program status and open issues
in the status report.
3 Security Plan
The <Program> security plan includes the following information:
 System Description <describe>
o Owner Information <describe>
Page 17
o System Security Categorization <describe>

o Security Responsibility Assignments <describe>
o System Inventory <describe or point to Asset Repository>
o System Boundaries <describe>
o Operational Status <describe>
o Operational Environment <describe>
o System Interconnections <describe or point to Asset Repository>
 Applicable Regulations <describe>
 Application Security Controls and their associated status <describe>.
The following are examples of security plan elements:
* Access Control – Information system access must by limited to authorized users, processes
acting on behalf of authorized users, and authorized devices.
* Awareness and Training – All employees with access to the <Program> network must
undergo initial security awareness training before being granted access to the <Program>
network.
* Audit and Accountability – Create, protect, and retain information system audit records to the
extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful,
unauthorized, or inappropriate information system activity.
* Configuration Management – Baseline configurations and inventories of <Program>

information systems must be established and maintained throughout the respective system
development life cycles.
* Identification and Authentication – Information system users, processes acting on behalf of

users, or devices must be identified.
* Incident Response – Establish and maintain an operational incident-handling capability for

<Program> information systems that includes adequate preparation, detection, analysis,
containment, recovery, and user response activities.
* Maintenance – Maintenance must be performed on all <Program> information systems to

ensure systems are protected against threat vectors.
* Media Protection – Information system media containing Controlled Unclassified Information

(CUI), both paper and digital, must be protected (i.e., physically controlled and securely stored).
* Personnel Security – A personnel security program is established and maintained that

includes background screening of new employee’s and subcontractors, employee termination
procedures, and third-party access. Individuals must be screened prior to being provided
authorization to access information systems containing CUI and / or <Program> sensitive or
proprietary data as defined in PO 4104 – Proprietary Data Security Program.
* Physical and Environmental Protection – Physical access to <Program> information Systems,

equipment, and the respective operating environments is limited to authorized individuals.
Page 18
* Risk Assessment – The risk to operations, assets, and individuals resulting from the operation
of <Program> information systems and associated processing, storage, or transmission of CUI
and <Program> sensitive or proprietary data is periodically assessed.
* Security Assessment – <Program> implements and maintains a security assessment,

authorization, and continuous monitoring program. The security controls in <Program>
information systems are periodically assessed to determine if the controls are effective in their
application.
* System and Communications Protection – <Program> communications (i.e., information

transmitted or received by <Program> information systems) at the external boundaries and key
internal boundaries of the information systems is monitored, controlled, and protected.
* System and Information Integrity – Information and information system flaws must be
identified, reported, and corrected in a timely manner. Information systems are provided
protection from malicious code. Solutions and capabilities are implemented that prevent and
protect against unauthorized modification of data, system flaws and vulnerabilities, unauthorized
software and software code, and inadequate error handling.
* Electronic Email – The <client> use their <client>-provided email accounts. Unapproved
accounts, such as private or personal (non-business) accounts (e.g., GMAIL, private-Outlook,
etc.), will not be used by CSRA employees under this contract unless specifically authorized to
do so by the Government.
* Web Sites, & Collaboration Tools – The <Program> will adhere to CSRA’s Information
Security Policy 5100 and will utilize DoD compliant PKI digital certificates to use as
authenticators for accessing all DoD web sites and/or e-rooms and collaboration tools.
When applicable, and if required for use in execution of the contract, they will utilize official DoD
remote conferencing collaboration tools, Defense Collaboration Services (DCS) for all electronic
collaborative efforts that contain DoD information. The <Program> do not host services such as
web sites, e-rooms and SharePoint sites that contain DoD CUI information.
* Common Access Cards (CAC) –The CAC issuance is solely for execution of this contract and
is to be used for official government email addresses (e.g., .mil, .gov, .edu). The Certificates
allow access to <> and <> protected sites required in the execution of this contract. CSRA will
only use the official Government email address for all contract support.
* Classified Systems – All classified information to be transmitted in support of this contract via
electronic media will use a cryptographic system authorized by the <>.
* Classified Spillages & Information Leakage – The <Program> has established

comprehensive guidelines for proper containment, sanitization and incident reporting
surrounding data spill events resulting in classified data on <Program> managed systems not
authorized for that classification level material. <Program> employees who suspect or confirm
that classified data are present on any unauthorized system must implement containment
procedures by:
* Protecting all involved data commensurate with the classification level of the material
Page 19
* Not opening, deleting, printing or further propagate the classified data
* Immediately reporting the suspected classified data spill to the Facility Security Officer
(FSO) and / or Information System Security Officer (ISSO)
* If security personnel are unavailable, immediately reporting to the Director of Security

for Information Assurance.
When a data spill occurs, security personnel perform the following steps:
* Document the event and all mitigating actions that were taken in response to the
incident
* Contain additional propagation of the classified material by removing impacted

equipment from the CSRA Network or other architecture
* Sequester and safeguard all equipment commensurate with the protection measures
applicable to the classification level suspected in the event
* Immediately notify cleared personnel involved of the exposure
* Work with cleared security personnel at other Government or industry sites to contain
the mitigate the classified data spill if data was further disseminated to industry partners
or customer locations
* Sanitize affected devices in accordance with CSRA Corporate guidelines or

procedures
* Draft incident report and provide to Information Assurance officer and Data Owner
* Review lessons learned from the classified data spill to minimized the likelihood of
repeat occurrences and improve mitigation and correction procedures.
* Specific to this program, any classified spillages either initiated or received by

<CLIENT> custodians will be reported to the Program Information System Security
Manager (PISSM) and Program Security Manager (PSM) immediately or within 24 hours
of the incident.
* Information Security Requirements for Protection of unclassified information – The

<Program> will adhere to the Information Security Policy (5100) to ensure that
necessary safeguards are implemented and maintained.
The <Program’s> safeguarding controls include:
a. All systems require login using username and password that conforms to <>
standards and must be changed every 45 days.
b. Multi-factor authentication beyond username and password in possession of only the

user and required to access systems (e.g. RSA SecurID, Text Message Code, Okta
Verify Mobile App, Google Authenticator App).
Page 20
c. Security Operations Center responsible for incident response, vulnerability scanning

and monitoring internet traffic for viruses, phishing and malware threats to <Program>
network.
d. Not processing <> information on public computers (e.g., those available for use by
the general public in kiosks or hotel business centers) or computers that do not have
access control.
e. Protecting information by no less than one physical or electronic barrier (e.g., locked
container or room, login and password) when not under direct individual control.
f. Sanitizing media (e.g., overwrite) before external release or disposal.
g. Encrypting information that has been identified as CUI when it is stored on mobile
computing devices such as laptops and personal digital assistants, or removable storage
media such as thumb drives and compact disks.
h. Limiting information transfer to subcontractors or teaming partners with a need to

know and a commitment to at least the same level of protection.
i. Transmitting voice and fax transmissions only when there is a reasonable assurance
that access is limited to authorized recipients.
j. Not posting <> information to Web sites that are publicly available.
k. Providing protection against computer network intrusions and data exfiltration:
(1) Current and regularly updated malware protection services, e.g., anti-virus, anti-
spyware.
(2) Monitoring and control of inbound and outbound network traffic as appropriate
(e.g., at the external boundary, sub-networks, individual hosts) including blocking
unauthorized ingress, egress, and exfiltration through technologies such as firewalls
and router policies, intrusion prevention or detection services, and host-based
security services.
(3) Prompt application of security-relevant software patches, service packs, and hot
fixes.
l. Comply with other Federal and DoD information protection and reporting requirements
for specified categories of information (e.g., Critical Program Information (CPI),
Personally Identifiable Information (PII), export controlled information) IAW the
requirements of the contract.
4 Continuity Plan
This Continuity Plan provides information to ensure <Program’s> ability to continue <Client>
business functions, and internal program functions under emergency conditions. The Plan
covers all required steps and coordination activities from the point that the emergency condition
Page 21
is pronounced by the program to the point that full operations are restored in the <respective
program facilities>.
4.1 Continuity Responsibility Assignments

The following persons are assigned key responsibilities for planning, approving, and
implementing Continuity requirements in <program > for the <program facility name> facility.
1. <facility name> Crisis Management <name>

Coordinator
2. <CSRA Account > VP/Director <name>
3. Applicable Service Center Coordinator(s) <Service Center

(name(s) provided by the IT DR Team) name>:
<person’s name>
4. Others as needed <name>
4.2 Continuity Management Staffing Requirements

Table 12 provides staffing counts for managers, staff, and contractors are needed for reduced
manning at the Back-up Facility under emergency conditions.
Table 12 Emergency Staffing Counts by Location

Name Days Working Hours
Staff Needed at
Backup Facility
Staff Who May

Work from Home
Staff Who are

“on call”
4.3 Notification Tree

Table 13 provides the calling tree responsibilities that apply in <program name>.
Table 13 Notification Tree Responsibilities

RESPONSIBLE TO CALL OFFICE # HOME # CELL #
PERSON
1. <name> 1. <name> ###### ###### ######
2. <name> ###### ###### ######
3. <name> ###### ###### ######
4. <name>
5. <name>
6. <name>
Page 22
RESPONSIBLE TO CALL OFFICE # HOME # CELL #

PERSON
7. <name>
8. <name>
9. <name>
2. <name> 1. <name> ###### ###### ######

2. <name> ###### ###### ######
3. <name>
4. <name>
5. <name>
6. <name>
7. <name>
8. <name>
3. <name> 1. <name> ###### ###### ######

2. <name> ###### ###### ######
3. <name>
4. etc.
4.4 Prioritized Continuity Processes

Prioritized processes that must be conducted by <Program> are identified in Table 14 below.
Table 15 explains the codes used in the Process Priorities Table that indicate if processes may
be performed manually, require automation, or have other performance modes that apply.
Table 14 Process Priorities Summary

Recovery Phase Resume Phase
(0 – 72 hrs) (72+ h – 30 d) (31 d – 90 d)
Process/ T1 T2 T3 T4 T1 T2 T3 T1 T2 T3
Function/Activity 4 8 24 48 10 20 30 40 60 90 Risk/Comment
Hrs Hrs Hrs Hrs d d d d d d
Primary Responsibility
Process Area: <name>
1. <Process name 1> A Process must be available
within 2 hrs after loss of
functionality at Washington
facility
2. <Process name 2> M A
3. <Process name 3> A Process required no later than 6
hours
4. …
5. <Process name 4> A
Page 23
6. <Process name 5> A Process can be deferred for 30

days, but then must be available
with automation
7. <Process name 6> A
8. …
9. <Process name> M A
10. <Process name> M A Manual effort will suffice until
<Group B> switches to IT for
<system x> (at W: T3)
11. <Process name> H D Personnel can work
independently from home until
access to joint resources
becomes necessary
12. …
Table 15 Keys to Matrix Entries in Process Priorities Table

MATRIX INTERPRETATION
CODE
A Indicates the point in time by which the process must be supportable in an automated
mode, usually with specialized systems applications, tools, and/or data, at the Back-up
Facility.
M Indicates the point in time at which the process must be capable of being performed at
the Back-up Facility, even if only in a manual mode.
D Automation is needed at the Back-up Facility but is typically limited to normally-configured

desktop applications (e.g., Word, Excel, PowerPoint, e-mail, etc.). Either no special
automated applications are required or their restoration may be deferred for some
specified period.
H Process may be performed by staff from their home either in standalone mode or through
VPN access to the Back-up Facility. Special accommodations and coordination ahead of
time with the IT Disaster Recovery Team (DRT) may be necessary to enable the VPN
mode of communications. Access to specialized applications may still be required (VPN
or other) even if personnel are not located at the back-up facility. These requirements
must be well-coordinated with the IT Disaster Recovery Team.
M…A Indicate progressions of requirements.

M…D or
H…D pairs
4.5 Process Details for Areas of Responsibility

Table 16 provides details of each of the processes identified in Table 13.
Table 16 Process Details: <Process Name 1>

Process Title <Process 1 name >
Process Description <Process 1 description >
Primary Contact <name>

Required Back-up Contact <name>
Page 24
Required Phase and Tier for Phase: <Phase> Tier: <tier>

Activation Only for Recovery/Critical Processes: Activation required within <number>
hrs following disaster.
Can this process be performed Yes No
manually? If yes, Manual processes are documented and stored in <location>.
What support from other Xxxxxx None <Or list, with the dependent relationship>
groups is required for this process?
What support external to Xxxxxx is None <Or list, with the dependent relationship>
required for this process?
Vital Records Required: None <Or list any that apply>
Reconciliation Approach: Describe the way that data and records for this process that were generated
during the emergency period using automated or manual means will be
synchronized with previously existing data to form the new baseline.
Comments: <Anything you need to clarify the process information>
4.6 IT Tools, Applications, Input / Output Data, and Special Instructions

Table 17 lists tools / applications, process data input requirements, process output data /
products information, and special instructions for tools or installation requirements.
Table 17 Tools, Applications, Input / Output Data Required, and Special Applications Instructions
TOOL/ PROCE RECOVERY INPUT OUTPUT DATA SPECIAL NOTES
APPLICA- SS TIME DATA/INFORMATION /INFORMATION INSTRUCTIONS
TION NAME OBJECTIVE
(RTO)
DATA
CUR- INSTALLATION
MEDIA RENCY MEDIA DESTINA- INSTRUCTIONS
(PAPER, (RPO) SOURCE (PAPER, TION (INTER-
ELEC, (HRS, (WHO, ELEC, (WHO, APPLICATION BACK-UP
VERBAL, DAYS, WHERE, VERBAL, WHERE, DEPENDENCIES, PROCE-
PHASE TIER ETC.) ETC.) HOW) ETC.) HOW) SEQUENCE, ETC. DURES
1.
2.
3.
4.
5.
6.
7.
8.
9.
This information is used to communicate <FA / Dept. / groups> IT supports requirements to the
IT Disaster Recovery Team.
This table is kept current to reflect changing needs of the group. It is imperative that any
changes must be coordinated with the IT Disaster Recovery Team Lead.
In addition, the program implements the CSRA IT Service Continuity Procedure
Page 25
4.7 Required Vital Records

Table 18 provides a list of Vital Records that need to be maintained at a backup facility.
Table 18 Details: Vital Records

PROCESS NAME VITAL NORMAL MEDIUM ALTERNATE MEDIUM NOTES
(SECTION #) RECORD TYPE
1. <Process name>  <record type 1>  <normal med 1>  < alt med 1>
 <record type 2>  <normal med 2>  < alt med 2>
 …  …
2.   
3.   
5 Technology Control Plan

The <Program> does not currently have any export requirements.
Should that change, the <Program> will follow the:
 U.S. Munitions List (USML) governed by the International Traffic in Arms

Regulations [ITAR], or
 Commerce Control List (CCL) under the Export Administration Regulations.
 CSRA Policy PO 0105A CSRA Export Control Manual
6 External Supplier / Subcontractor Management Plan

The <Program> has three types of suppliers:
1) subcontractors that are part of the integrated program team (IPT) working to CSRA
processes
2) Subcontractors that are standalone subcontractor(s) with end item deliverables (EID)
built to the subcontractor’s processes.
3) COTS suppliers / vendors
Table 19 identifies all external suppliers and their responsibilities and describes their
relationships to CSRA and the customer.
Table 19 Sample Supplier Identification Matrix

Supplier Supplier Small/ Procurement Contract Responsibility Need Date
Type Disadvantage Type Type
Contractor
(Y/N?)
Supplier 1 Vendor N/A Purchase FFP Specialty xyz xx/xx/xx
Order
Supplier 2 Vendor N/A Purchase FFP Specialty xyz xx/xx/xx

Order
Supplier 3 IPT N Subcontract FFP Building and xx/xx/xx
Delivering
HW/SW xyz
Supplier 4 EID Y Subcontract T&M Delivering xx/xx/xx
Page 26
Supplier Supplier Small/ Procurement Contract Responsibility Need Date

Type Disadvantage Type Type
Contractor
(Y/N?)
Service xyz
Supplier 5 Vendor N/A Purchase FFP COTS HW/SW xx/xx/xx
Order
For those subcontractors working as part of the integrated program team, the PM will:
- Review resumes in advance of bringing staff on board the program to ensure they are
qualified
- Ensure candidates have necessary security clearances
- Ensure subcontractor agreements are in place for services to be rendered including
budget details and expected work week.
- Ensure subcontractor staff are fully indoctrinated into the program via Program
Orientation training or equivalent.
For standalone subcontractors delivering separable products/services or procuring COTS items

the PM will:
- Identify all long lead procurement items and planned dates for procurement
- Conduct Formal reviews (e.g. design reviews, Technical Exchange Meetings (TEMs))
(subcontractors only),
- Conduct Informal reviews (e.g. status meetings), (subcontractors only),
- Perform Acceptance testing of the supplier products,
- Evaluate supplier performance.
- Ensure receipt, acceptance and transition of subcontractor/COTS products into the
program.
The program follows the CSRA Manage Suppliers / Subcontractors procedure and the CSRA
Subcontracts and Procurement Acquisition Manual.
7 Program Training Plan

Table 20 provides the <Program’s> training / certification contractual requirements.
Table 20 Sample Training Plan
Training/Certification Role Hire/Train No. Need Date Internal/Ex Funded
Requirement ternal (Y/N)
Training
ITIL Expert Service Mgr. Hire 1 xx/xx/xx N/A N/A
ITIL Foundations Service Staff Train 25 xx/xx/xx External Y

Scrum Master Development Hire 1 xx/xx/xx N/A N/A
Lead
Client CM System CM Lead Train 1 xx/xx/xx Internal N
Etc.
The PM will monitor completion of planned training using the <Program’s> training status
spreadsheet.
Page 27
The program follows the CSRA Project Training Guide and the CSRA Learning Operations
Training Plan.
8 Risk, Issues and Opportunity Management Plan

The risk, issues and opportunities management plan describes how the program will identify
and manage program risks, issues and opportunities.
8.1 Risk Management

Risk management is a continuous process that identifies, analyzes / assesses, tracks /
monitors, mitigates, and makes visible technical, cost, and schedule risks that may endanger
achievement of critical objectives for the <Program>.
These objectives include improving customer relations, operational excellence, innovation and
technology, and financial management. A risk can potentially impact <client’s> success.
The purpose of implementing the risk management process is to control and minimize the
impact of a potential risk. CSRA approaches risk management as an integral part of daily
operations and management, not as an annual exercise.
CSRA’s risk management process is a detailed, standardized set of activities that are applicable
to the risk management of all contract types and program implementations. Figure 3 depicts the
CSRA risk management process that enables the development of effective risk mitigation
strategies and eliminates or minimizes schedule or performance impact.
Figure 2 Sample Risk Management Process
CSRA’s risk management methodology consists of the following steps:
 Establish program risk management strategy

 Identify risks
 Analyze risks
Page 28
 Plan risk mitigation

 Mitigate risks
 Monitor and report risk on a regular basis
8.1.1 Program Risk Management Strategy

Developing a Program Risk Management Strategy that lays the groundwork for the
<Program’s> risk management program is a key activity during program planning.
Developing a Strategy includes:
 Identifying the risk sources to be considered for the program, the risk categories into
which risks are grouped, and the thresholds that determine when mitigation (risk
treatment) actions are to be taken.
 Determining the methods and tools to be used in identifying, analyzing, and mitigating
risks.
 Identifying internal and external stakeholders who will be involved in risk management
 Define roles and responsibilities for risk management activities and obtain agreement
from all parties.
 Ensuring necessary training is provided to all who will be involved in risk management.
 Identifying the methods and set schedules with milestones to be used to continuously
track, update and report on risks.
 Determining how adherence to risk processes will be monitored, measured and
evaluated.
 Creating the Risk Register with program and program specific information.
8.1.2 Risk Identification

Risk identification is a systematic process of identifying specific risks that threaten the success
of the <Program>. It is a continuous process throughout the program’s life.
The PM assigns responsibility for implementation and maintenance of risk management to the
Risk Manager. The Risk Manager works closely with the <Program> staff, task leads and
stakeholders to identify risks; estimate the probability of the risk occurring, and the potential
impacts any risk may have on the program.
All CSRA program staff members have the ongoing responsibility to report and fully disclose
risks as they become visible in the day-to-day performance of their work. Risks are a standard
agenda item during program status reviews and meetings.
Identify Risks: This step is initiated before the program begins – beginning during the proposal
phase – and is repeated continuously at identified milestones throughout the program. Identical
activities are completed for program-level and maintenance change risk capture.
As risks are identified, they are captured in the Risk Register. The basic information captured at
this point includes the risk title, risk source, date identified and root cause.
Risk identification activities are triggered by the following occurrences:
 Any risk arising that jeopardizes a milestone or deliverable
 Requirements changes, contractual changes or schedule changes
Page 29
 Any changes in CSRA’s technical solution
 Occurrence of one risk that gives rise to others (e.g., vendor delivery slippage of a
critical hardware, software or communications component)
 Social, political or environmental changes
 Industry changes in technology that offer significant cost advantages or innovation

opportunities (automation, consolidation, integration) and prompt consideration of
adopting new technologies
 Changes in customer support, location or funding availability
 Results of Client Satisfaction Surveys.
 Any other risk brought forward by a stakeholder to the attention of the Risk Manager.
As risks are identified, they are documented in a Risk Register. The information entered into the
Risk Register includes:
 Brief title
 Description (cause, consequences, impact on stakeholders)
 Risk type
 Program Management and Organizational Risks
 Product Development Process (methods and tools) Risks
 Product Risks
 Combination of Risks
 Risk source (estimate)
 Risk category (estimate)
 Impact (first estimate)
 Root cause (narrative)
 Probability of occurrence (estimate)
8.1.3 Risk Analysis

Once risks are identified, each must be analyzed to determine how it is to be handled.
Risk analysis includes evaluating the risk according to the two evaluation criteria (probability
and impact); assigning risks to the risk categories; and prioritizing the risks.
Evaluation techniques include: critical path analysis, cost / schedule estimation for impact
analysis, the Delphi technique to elicit stakeholder judgment, and lessons learned from previous
programs.
The stakeholders review the results of the risk analysis to ensure that all risks are identified and
the relative impacts of the various risks are consistent. The analysis results are reviewed by
Page 30
stakeholders, and the Risk Manager determines final ratings based on stakeholder consensus.
Consensus does not necessarily mean that all stakeholders are in full agreement, but rather no
strong dissension exists amongst the stakeholders.
Analysis results are captured in the Risk Register.
Risk Evaluation. The purpose of risk evaluation is to determine the probability of occurrence
and the impact of the identified risk.
Perspectives should be sought from multiple stakeholders, such as CSRA staff and
management, <client>, subcontractors and End User Representatives.
While these determinations can be somewhat subjective, there are techniques that can improve
their accuracy:
 Critical path analysis using program management tools such as Microsoft Program to
analyze impacts of missed milestones
 Cost and schedule estimation tools to analyze impacts associated with changes to the
program’s complexity or resources
 Lessons Learned from previous programs to provide insight into the likely impact of risk
situations that may have occurred before
Risks are assigned a probability from 1 percent to 99 percent and an impact from 1 (lowest –
minor impact) to 5 (catastrophic). These probability and impact determinations are entered into
the Risk Register for the risk; the risk exposure is calculated automatically by multiplying the two
values.
Table 21 provides Impact Assessment Guidance by Risk Categories,
Table 21 Consequence / Impact Assessment Guide
Risk 1 - Minor 2 - Moderate 3 – Significant 4 - Severe 5–
Category Catastrophic
Cost Cost overrun in Cost increase Cost increase of Cost increase of Cost increase
parts of program of 1 to 5%. 6 to 20%. 21 to 50%. greater than 50%.
requires use of
management
reserve; budget
not exceeded.
Profit Profit decrease Profit decrease Profit decrease of Profit decrease No profit to CSRA.
of 1 to 10%. of 11 to 40%. 41 to 70%. of 71-100%. No Some work
work performed performed at cost
at cost to to CSRA.
CSRA.
Schedule Schedule slip in Minor slip of a Slip in one or Slip in Slip in anticipated
one or more deliverable that more tasks that anticipated delivery that will
tasks that can be does not result in deferring delivery that make the product
accommodated impact or dropping some significantly obsolete or
by adjusting customer’s of planned threatens useless to the
schedule; no mission. capability. customer’s customer,
impact on mission resulting in
delivery. performance, termination of
resulting in most or all
scope tasking.
renegotiation
and loss of
Page 31
Risk 1 - Minor 2 - Moderate 3 – Significant 4 - Severe 5–

Category Catastrophic
planned future
capability.
Performance System or System or System or service System or System or service

service will fail to service will fail will fail to fully service will fail will perform so
meet one or to fully meet meet one or more to fully meet poorly that it
more one or more performance one or more cannot support the
performance performance requirements, performance customer’s
requirements requirements, resulting in requirements, mission and
(e.g., capacity, resulting in degraded support resulting in cannot be made to
response time), degraded for customer’s severely do so within
but is usable for support for mission. There is degraded reasonable time
customer’s customer’s no resolution support for and cost, resulting
mission. The mission. The compatible with customer’s in termination of
problem can be problem can be our approach, mission. Users contract.
resolved with resolved but resulting in must rely on
minimal mission not without a continuing sub- alternatives for
impact should period of par performance. part of their
this occur (e.g., unsatisfactory mission, and
adding hardware performance. CSRA’s
or staff). contract scope
is reduced.
End User A minority of Some users do A majority of A majority of Users are unable /
Satisfaction users find the not feel that all users have a users have a unwilling to use
product of their needs need that is not significant need our product to
somewhat and fully addressed that is not perform their
difficult to use or expectations and that impacts addressed and mission, and must
do not feel that are fully met, their ability to that impacts continue working
all of their needs resulting in perform their their ability to as they do now.
and expectations change mission; it is perform their Customer elects
are fully met, but requests that correctable mission; to abandon the
no changes are are easy to without changes correction program.
deemed address. to technology or impacts cost
necessary by the cost overrun. and schedule,
customer. and may require
technology
changes.
Company Some negative Negative Negative publicity Congressional Congressional or

Image comment within articles in trade in mainstream or other highly- other highly-visible
customer press. media visible investigation
community. (newspapers, investigation not resulting in loss of
television). resulting in loss contract.
of contract.
Risks with Impact Assessments of “Significant”, “Severe” or “Catastrophic” must be

communicated immediately to Contracts and the Legal department per PO 9001
Program/Project Management.
Risk Prioritization. Risks are prioritized relative to one another in a list ordering them from
highest to lowest priority. In general, they are prioritized by exposure; however, this ordering can
be modified as appropriate to the program.
Page 32
8.1.3.1 Mitigating / Treating Risks

The objective of risk mitigation (risk treatment) is to reduce risk exposure. Since exposure is the
product of probability and impact, exposure can be reduced by either reducing the probability
that the risk will occur or by reducing the impact if it does occur.
Risk mitigation activities include developing risk mitigation plans for the most important risks,
implementing these approved plans and monitoring and reporting on risk status.
8.1.3.2 Risk Mitigation Planning
A risk mitigation plan is developed for each risk important enough to require one in accordance
with the program’s established thresholds. The program will develop a risk treatment plan as
required for high and moderate risks.
The risk mitigation plan includes, as appropriate:
- Strategies for avoiding the risk or reducing its probability
- Strategies for reducing its impact should it be realized
- A plan for monitoring the risk to determine when the avoidance strategies are to be
implemented
- A contingency plan for actions to take if the risk occurs if it cannot be mitigated or if the
risk is realized.
The Risk Manager works with stakeholders to consider risk mitigation strategies for each risk or
risk group identify the best strategy and develop a work plan for implementing it. The results of
the risk analysis and the causes, sources and components of each risk are considered when
formulating risk mitigation strategies.
The Risk Manager also considers the interactions of risks and the impact each mitigation
strategy may have on other risks or processes. Actions taken to reduce one risk may
inadvertently increase the probability of another.
CSRA works collaboratively with the <client> to reach agreement on the risk items and their
associated thresholds (probabilities of occurrence). This results in assessments of high,
moderate or low.
A risk mitigation plan will be developed for each risk that exceeds the agreed-upon threshold for
each category.
The risk mitigation plan includes, at a minimum:
8.1.3.3 Risk Mitigation Plan Implementation
When risks exceed program-defined thresholds, the risk mitigation plan is implemented.
Required resources are assigned and milestone dates are set. Impacts to other risks or ongoing
tasks are taken into account.
As with other program tasks, the risk mitigation process is assigned resources (people and
budget), schedules and resolution criteria. The process is monitored and performance metrics
are collected, analyzed and reported.
Page 33
8.1.4 Risk Monitoring and Reporting

CSRA’s risk management metrics enable CSRA and <client> to view risk trending data over
time for assessing the effectiveness of risk mitigation strategies.
Table 22 lists the metrics to be used to measure program risk and the effectiveness of the risk
management process.
Table 22 Risk Metrics
Metric Collection Method Use(s)
Change over time in number of Monthly snapshot from the  Measure overall program risk status
Risks, by high/moderate/low Risk Register  Assess effectiveness of risk
priority identification activities
 Measure program stability
Number and exposure of risks Monthly snapshot from the  Measure effectiveness of risk
avoided and issues resolved Risk Register mitigation efforts
Number of risks exceeding Monthly snapshot from the  Measure overall program risk status
thresholds Risk Register
Risk monitoring and reporting are essential elements of the risk management process. All
identified risks are monitored, without regard to their exposure or whether a mitigation plan is
being implemented. Risks are re-assessed at regular checkpoints.
Risk monitoring includes:
- Re-evaluating previously identified risks to determine if their probability or impact has
changed
- Re-prioritizing risks based on updated information
- Developing a mitigation plan if a risk that previously had not warranted one becomes
important enough to require it
- Implementing the mitigation plan if the risk crosses the program-defined threshold
- Implementing the contingency plan if the risk event occurs
- Retiring risks that can no longer impact the program
- Monitoring the progress of any ongoing mitigation / contingency actions.
CSRA uses a variety of monitoring methods. Schedule and budget risks are monitored through
earned value tracking and milestone tracking if required by <client>.
Risk management and earned value management (EVM) are tightly coupled through the EVM
variance analysis process. The variance analysis describes both the impact that the risk has on
the program if the relevant program performance continues unchanged and its CAP. If the
variance cause we have identified is significant enough such that management deems it a risk,
the item is added to the Risk Register and tracked accordingly.
Performance, technical and resource risks are monitored through engineering reviews, service-
level reviews, performance measurements, the change management process, modeling,
simulation, prototyping and other analyses, as appropriate.
Monitoring of customer satisfaction risks may include customer advocacy and survey functions.
Page 34
An important aspect to the overall risk management process will be to determine and acquire
significant metrics to assess the efficiency and effectiveness of the overall process.
While the total number of risks on the Risk Register is important, the most important data to
focus on are the number of risks that are above defined thresholds and are therefore a potential
threat to the program.
8.1.5 Risk Status and Thresholds

Risks, once identified, must be monitored for changes in state that require a change in the
course of action. When risks are entered into the Risk Register, they are given one of the
following status codes:
New: The risk event has occurred. The pre-defined contingency plan, identifying the course of
action to be taken in this case, must be enacted.
Watch: Mitigation action is not necessary at this time, but the risk is to be watched.
Mitigate: Mitigation action must be undertaken.
Transfer: The risk is outside the control of the <Program> Program. Responsibility is
transferred elsewhere. This transfer is documented on the risk page.
Retire: The risk has ceased to be a possibility. It is kept in the database as a retired risk.
The decision to assign a mitigate status rather than a watch status, or to promote a watch list
item to mitigate status, is based on category-specific thresholds, as defined in Table 23.
Table 23 Risk Thresholds
Risk Category Description
Cost Any risk of probability greater than 25% that threatens to exceed projected
costs by more than 5% requires documented and tracked mitigation action.
Any risk of probability greater than 25% that threatens to exceed projected
costs by more than 10% requires that senior management be involved.
Schedule Any risk of probability greater than 10% that threatens the ability to meet
schedule milestones critical to customer requires documented and tracked
mitigation action, as well as involvement of the customer in mitigation
activities.
Any risk of probability greater than 25% that threatens our ability to meet
schedule milestones critical to our customer requires that senior management
be involved.
Performance Any risk of probability greater than 10% that our system/service will fail to meet
performance requirements requires documented and tracked mitigation action.
(This is a low threshold because such problems can require a significant
change in our solution.)
Any risk of probability greater than 25% that our system/service will fail to meet
performance requirements requires that senior management be involved.
Customer Any risk of probability greater than 10% that our system/service will fail to
Satisfaction satisfy our customer requires documented and tracked mitigation action. (This
is a low threshold because such problems require early attention.)
Page 35
Risk Category Description
Any risk of probability greater than 25% that our system/service will fail to
satisfy our customer requires that senior management be involved.
End User Satisfaction Any risk of probability greater than 10% that our system/service will fail to
satisfy end users requires documented and tracked mitigation action, as well
as involvement of the customer in mitigation activities. (This is a low threshold
because such problems require early attention.)
Any risk of probability greater than 25% that our system/service will fail to
satisfy end users requires that senior management be involved.
Company Image Any risk of probability greater than 10% that threatens the <client> Program’s
image in this customer community requires documented and tracked mitigation
action.
Any risk of probability greater than 10% that threatens the <client> Program’s
image in the public arena (press, etc.) requires that senior management be
involved.
Identification and monitoring of risks is a continuous process. New risks are identified and
existing risks re-assessed at regular checkpoints.
8.1.6 Risk Severity Levels

When a risk is entered into the Risk Register, potential risk mitigation strategies are also
entered, and their individual effects on the probability and / or impact are assessed.
In addition, the tool produces a small graphic illustrating the level of risk at this point in time and
whether the risk is assessed as Very Low, Low, Moderate, High or Very High or High. Table 24
shows a copy of the risk matrix graphic.
Table 24 Risk Level Determination
Likelihood ( Threa t Level of
Event Occurs a nd Impact
Res ul ts i n Advers e
Very Low Low Moderate High Very High
Very High Low Moderate High Very High Very High
High Low Moderate Moderate High Very High
Moderate Very Low Low Moderate Moderate High
Low Very Low Low Low Low Moderate
Very Low Very Low Very Low Very Low Low Low
If the threshold is not attained for the specific risk category, the risk is placed into a Watch
status and no immediate actions are required.
Page 36
The risk is reviewed each month to re-validate the Probability and Impact. If the threshold is
exceeded, the risk is a candidate for active mitigation and placed into a Mitigate status.
The Risk Manager determines what mitigation actions, if any, to take to lower the probability
and/or impact of the risk. The Mitigation Plan elements are examined, and mitigation strategy is
selected to lower the overall exposure below the threshold for the specific category.
The mitigation activities selected are then entered into the Integrated Master Schedule and are
monitored as a task. The work is assigned and begins as soon as possible on the mitigation
activities.
When the mitigation activities are completed and the risk is determined to once again be below
the pre-set threshold, the mitigation activities are closed out. The status is returned to Watch if
there is some level of risk remaining and is placed under routine monitoring. If the risk is
resolved, a status of Retired is selected.
For risks, there are three primary status categories to monitor: Watch, Mitigate, and Retired.
The majority of risks are categorized as Watch. These are monitored by the responsible
individual, and their status is updated should an event change their probability or potential
impact.
When the exposure level exceeds the pre-set threshold value, the responsible person and
CSRA management are alerted to examine the risk and determine appropriate actions.
A risk in the Mitigate category is actively being mitigated to lower its exposure level to below the
threshold value. A risk in the Retired category has been remediated.
Page 37
8.1.7 Risk Process Effectiveness Measures

A number of metrics and performance measures are used to assess the effectiveness of the risk
management program. These are listed in Table 25.
Table 25 Risk Process Effectiveness Measures
Metric Collection Method Use(s)
Risk Exposure Planned Monthly snapshot from Risk Measure overall program risk
vs. Actual – by Risk Register exposure.
Category
Assess effectiveness of mitigation
efforts.
Change Over Time in Monthly snapshot from Risk Measure overall program/program risk
Number of Risks, by High Register status.
/ Moderate / Low Priority
Assess effectiveness of risk
identification activities.
Measure program stability.
Resources Expended on Monthly snapshot from Risk Measure costs associated with
Risk Management Register handling program/program risks.
Activities
Number and Exposure of Monthly snapshot from Risk Measure effectiveness of mitigation
Risks Avoided Register efforts.
Number of Risks Monthly snapshot from Risk Measure overall program/program risk
Exceeding Thresholds Register status.
8.1.8 Minimizing Cost and Schedule Impacts

Continuous risk management is one of the most effective ways to minimize the cost and
schedule impacts of potential risks.
The <Program’s> approach to identifying risks – proactively considering potential problems,
using risk checklists, involving all stakeholders, and re-evaluating at established checkpoints –
substantially minimizes the likelihood of an unforeseen risk adversely impacting program
performance.
In addition to identifying potential risks on a continuous basis, their changing status is evaluated
to determine when corrective action is warranted. Risk reporting and metrics ensures that
management is aware of potential risks and plans for mitigating them.
Once a mitigation action is initiated, it is managed like any other program task. Resources are
allocated, milestones are established and the task becomes part of the program plan.
8.1.9 Reporting
It is important to ensure all stakeholders are aware of risk status. Executive CSRA and <client>
senior management are made aware of the most significant risks as identified in the Program’s
risk management strategy so that the necessary resources (e.g., budget, staffing) can be
Page 38
applied to mitigating those risks. A risk-aware staff can provide insights and recommendations
for action and perform their tasks in a way that adds minimal risk.
8.1.9.1 Mechanisms for Reporting Potential Risks
The <Program> uses a number of methods to identify risks. These methods involve all
program stakeholders – program staff, subcontractors, other contractors, support organizations
and the government.
Because risk identification is built into the day-to-day activities of our engineering and
management processes, it becomes a natural part of everyone’s job responsibility and
encourages their participation. Some examples are:
 All issues opened at status reviews are considered as potential new risk sources. Many of
these meetings involve subcontractor, other contractor, support organization and government
personnel.
 Risk brainstorming sessions are conducted with stakeholders at program startup as well as
when a significant program change occurs – e.g., a change in requirements or adoption of a
new technology.
The Risk Manager is responsible for coordinating the risks that arise at these meetings and
checkpoints, and ensuring that they are entered into the database and maintained.
Also, because the Risk Manager has a close day-to-day working relationship with the team
leads, he / she is in a position to identify possible risks and discuss them with knowledgeable
team members to determine if they should in fact be added to the system.
The Risk Manager provides regular risk reports to the CSRA Program Manager.
8.1.9.2 Government Visibility into Risk Status
Risk management is a partnership between CSRA and <client>. Risks have the potential to
affect our success, but more important, the success of the <client>’s mission. The identification
of risks and decisions about how to handle them are joint activities. CSRA’s risk management
process fosters this critical partnership.
Our risk identification process involves all program stakeholders. Risk identification is a
continuous process throughout the program life cycle, and the government is directly involved in
the process, including:
 Participation in initial risk brainstorming and Risk Register review.

 Identification of any risks arising at program reviews, service-level reviews and informal
meetings involving our government stakeholders.
<Client> is also directly involved in risk analysis – assessing the probability and impact of risks
and prioritizing the risks, particularly for risks that may be wholly or partially under the control of
the government (e.g., evolving standards, changing user requirements, changing political /
funding environment, physical security).
Deciding on mitigation actions – identifying them, selecting among alternatives and deciding
when to carry them out – also involves the <Client>. These are important decisions affecting
program success and services to users, and the client’s voice is critical. There may also be cost
impacts requiring government approval.
The program follows the CSRA Manage Risks procedure for guidance on the risk management.
Page 39
8.2 Issues Management

It is important to ensure that issues are identified and resolved quickly by the right person. The
following steps help ensure issues are managed properly:
 Record Potential issues: Any Program Team Member may identify a potential issue.
Communicate the issue to the next level of management during regular team meeting.
Record the issue in the issue register.
Critical issues should be raised to management immediately. Issues with Impact

Assessments of “Significant”, “Severe” or “Catastrophic” will be communicated
immediately to the Contracts and the Legal department as well per policy PO 9001
Program / Project Management and Manage Issues Procedure
 Review and Analyze Potential Issue at Appropriate Level: Depending upon the level
of the issue, issues are reviewed during the regular program, program or account level
meetings. Review the issue and clarify any unclear descriptions / points.
 Approve or Reject Issue: Management rejects the issue and explains why it is not an
issue or accepts the issue as valid. If valid, ensure that the issue has been clearly
described, the source indicated, and the impact documented. Work with the relevant
level of management to prioritize against existing issues and create a required resolution
date.
 Assign Issue Owner: Management assigns an issue owner who is responsible for
defining and implementing the resolution approach. Update the Issue register with the
name of the issue owner. Ensure that the team member assigned as the owner
understands his / her responsibilities.
 Determine Resolution Approach: The issue owner defines the resolution approach
and provides a record of planned actions to the relevant program control resource to
record in the Issues register. The affected program or program manager reviews and
approves the approach and ensures that the relevant program plans are updated to
reflect any new effort, resources or tasks required to implement the issue resolution. If
the resolution results in changes to the established baseline, the issue should be
processed through the Change Management procedure
 Implement Issue Resolution: The Issue Owner implements the issue resolution plan
and reports progress. Once the issue has been resolved to management’s satisfaction,
the relevant PCO resource will mark the issue closed in the issue register.
 Close Issue: Once the issue has been resolved; the PCO Specialist records the final
resolution into the Issue register, closes the issue, and indicates the closed date. If the
issue is not resolved, but it is decided to close it because of low priority or events
overtake the planned action; indicate that the item was closed without resolution.
 Monitor Issue: Issues are monitored at all levels within the program. Program Control
will provide reports by Severity Code (Priority) within the program. These reports are
reviewed in the weekly program status meetings and critical issues are reviewed during
the Program Management Review (PMR).
 Report Progress: The PM reports progress on issue resolution as part of the normal
status reporting. To keep the issue management process effective, the PM regularly
reviews the issue reports and issues register with the key stakeholders.
 Escalate Issue as Needed: As necessary, the PM escalates critical issues to higher
levels of management, using the escalation procedures.
Figure 5 process flow illustrates the issue management process

Page 40
Identify Potential
Issue
Approve or
Reject Potential
Issue
Issue
Escalated
Pass to more
Impacted Passed
Manager Approved
Analyze and
Review Issue at
Appropriate
If critical
Level
Escalate Assign Issue

Issue As Owner
Needed
Determine
Resolution
Approach Rejected
Implement Issue
Resolution
Monitor Issue
Escalation
Required
Close Issue
Figure 3 Issue Management Process Flow
The Program uses the organizational Manage Issues procedure for guidance on establishing
rules and responsibilities for identifying, escalating, and resolving issues related to the program.
8.3 Opportunities Management

All program team members should be aware of potential opportunities during the normal course
of program execution and tracking; they should pass them along to the program manager when
they are identified.
There are two types of opportunities:
1) New work under an existing contract;
2) New work outside an existing contract.
The program will manage each opportunity type in accordance with Table 26.
Table 26 Opportunity Handling Processes
Opportunity Scope Approved Tool Example
Revenue, operating income Salesforce Gap Monitoring Tool; A program has a planned budget to
(OI), and financial changes Access the GAP Monitoring Tool acquire 100 laptops per quarter in
(such as cost reductions) User Guide through Salesforce the contract year; the customer has
within the contract Knowledge requested all 400 in Q1. The
program manager will create a gap
program to track recognition of OI
and revenue earlier than planned.
New business opportunities Salesforce New Opportunity tool; If the customer requests 100
resulting in new total Access the CSRA Sales laptops in addition to the 400
Page 41
contract value (TCV) and Opportunity User Guide through budgeted and contracted for in the
increases to the contract Salesforce Knowledge current contract year, the program
(managed in accordance manager will create a new
with the Business opportunity to track TCV and CSRA
Acquisition Process (BAP)) will receive a contract mod for the
additional equipment and related
costs.
The program uses the CSRA Opportunities Management Procedure for guidance.
9 Contract Change Management Plan

Figure 6 provides the <Program> Contract Change Management Process. This process has
been established to identify, record, assess, and approve contractual changes to the Program.
CSRA and <Client Name> will follow this process to classify, prioritize, approve, or reject
changes. CSRA will always need prior authorization and approval of expenditures by <Client
Name> before starting work on changes.
Recognize
Change
Document
and Analyze
Change
Review
and Approve
Change
If approved
Modify Implement
Contract Change
Figure 4 Contract Change Management Process
The standard <Program> contract change control form will be produced for each change
request by the CSRA program manager. A unique record number will be assigned to each
change request and will be and will be documented in the change control log.
The program will also utilize the organizational Manage Program Change Procedure where
needed.
9.1 Client-Initiated Changes

Proposed client-initiated requirements changes will be managed closely by CSRA to avoid
“scope creep”. The PM and technical leads will ensure program staff are fully educated on the
Page 42
approved <Program> requirements baseline and when to recognize requests are “out of scope”
of that baseline.
Client requests to add / change requirements or propose derived requirements may occur
formally (review of a deliverable) or informally (e.g., during a technical interchange meeting).
Steps for managing proposed <client> initiated requirement changes are:
 Informal Requirements Change Requests - Requirement change requests

raised informally by clients (e.g., via technical meetings) that appear to be “out of
scope” should be recorded by the CSRA Subject Matter Expert (SME) as
program issues (Refer to Issues Management). The issue is then subsequently
tracked to closure; if the requirements change request is approved for
implementation the change should be incorporated into baseline requirements
documentation which is then reviewed and approved by the program
Configuration Control Board (CCB).
 Formal Change Requests - Requirement change requests raised formally by
clients via a deliverable review should be reviewed and approved by the program
CCB before accepting.
 Out-of-Scope Requirements Handling - Client-initiated requirement Change
Requests that are deemed “out of scope” by the CCB, should result in a
notification back to the client.
o If initially received as a formal client requirement change request (e.g., via
a deliverable review), communication to the client will be via CSRA
contracts
o If initially received as an informal client requirement change request (e.g.,
via a technical meeting), the CSRA Subject Matter Expert (SME) will
contact the client informally (technical meeting, email).
o Negotiate change with the client. If approved, issue contract
modification. If not approved, determine follow-on action with Executive
Management and Contracts Administrator.
9.2 CSRA-Initiated Changes

Steps for managing proposed CSRA-initiated requirement changes are:
 Change Requests - Requirement change requests raised internally by
Program Management should be reviewed and approved by program CCB
before accepting.
 Program Management socializes the Change Request with the Client.
 Program Management coordinates with the Contracts Administrator by
formally submitting the Change Request to the client for approval.
10 Asset, Configuration and Data Management Plan

Asset, Configuration/Change Management and Data Management are closely linked processes.
The <Program Asset Repository tool)> will be used to identify and track assets, CIs and
changes to CIs and associated documentation. The <Program repository tool> will be used as
the primary repository for storing assets and Configuration Items (CIs).
The Configuration and Data Manager (CDM) will be responsible for managing these three
functions on the program.
Page 43
10.1 Asset Management
This section describes the control of assets from the point of acquisition to the point of disposal
including:
 Receiving – Assets will be received at the <facility>. The <role> acknowledges

the assets received conform to the requirements of the purchase order.
 Inspecting – Assets will be examined by <role> to ensure that the products
delivered meet the purchase specification.
 Acceptance – <Role> will acknowledge receipt and acceptance of the asset so
the vendor can be paid. Upon acceptance, the packing slip with copy of
purchase order will be sent to accounts payable.
 Installation – <Role> will install product in appropriate location.
 Periodic Inventories – <Role> will set up a regular schedule for partial and
complete physical inventories of product and resolve any discrepancies identified
during inventory.
 Disposal – <Role> will dispose of assets, when asset reaches end of life or is
replaced. Disposal will be in accordance with appropriate CSRA policies and
regulations.
Assets will be identified and tracked via the project <Asset Repository> tool. Table 27 provides
a sample of the minimum information to be collected for each Asset received. Assets
determined to be Configuration Items (CIs) will be identified and managed through the
Configuration and Change Management process.
Table 27 Sample Asset Item List

Asset Name Type Attribute Is this a CI? (Y/N) Vendor/Contractor
<name: application Software Version #, where Y Vendor XYZ

program xyz> used/location
<name: system Hardware Serial #, where N Vendor XYZ

component xyz> used/location
<name: document Document Version #, Y CSRA
xyz>
For overall asset management, the program will implement the CSRA Property Control Manual.
10.2 Configuration and Technical Change Management

The Configuration and Change Management section defines how software, hardware and
documentation items will be stored, how their integrity will be established, maintained and
verified, and what information will be provided for monitoring configuration management activity.
Assets that are deemed to be CIs are listed in a Configuration Item List. Items listed as CIs are
added to the Asset Repository. CIs listed in the Asset Repository are under change
control. The status of the CI is updated from point of acquisition to decommission or end of life.
The program will use CSRA Service Asset and Configuration Management and Change
Management procedures for guidance.
Page 44
Configuration
Item/ Asset
Information
Figure 7 provides the process flow for Configuration and Change Management (CM)
4.1
Plan the Service
Asset and
Configuration
Management System
4.2
Identify Assets and
Configuration
Items, Create the
CMDB, and
Establish Baselines
4.3
Control
Asset and Change Management
Configuration
Management
4.4
Verify and Audit
Assets and
Configuration
Items
Figure 5 Configuration Management Process

Configuration
Management
10.2.1 Plan the Configuration Management System Record
The <Program’s> Configuration Management System (CMS) consists of staff, processes and
tools. The CMS includes collecting, storing, managing updating and analyzing and presenting
data about configuration items and their relationships
10.2.1.1 CM Roles and Responsibilities

CM roles and responsibilities are as follows:
Page 45
Table 28 CM Stakeholder Roles and Responsibilities
Role CM Responsibilities
Technical / Development Department  Ensure development department personnel receive required training to
Management perform CM-assigned roles effectively.
 Assign resources to support development department CM and training
activities.
 Ensure that a process is defined for the identification, control, and
storage of local development department desktop procedures.
 Provide process recommendations to improve management and
control of work products and life-cycle throughput.
Change/Configuration Control  Coordinate the development, documentation, training, and
Board: maintenance of the <Program> Process Baseline with CM, including
Program Manager (Chair), process-related policies, procedures, standards, and plans.
Program Directors,  Review and approve changes to internal software, engineering, and
process work products as necessary.
QMO Director
 Develop Management Procedures and ensure that they are
configuration-managed within the framework of CM process
improvement goals.
 Coordinate the administration of Change Requests with CM.
 Review and approve changes to the Procedures and Work Instructions.
 Evaluate and promote best CM practices from program groups to
Program level.
 Encourage personnel to identify CM opportunities relative to process
improvement.
QMO Personnel  Monitor and evaluate CM processes, activities, and compliance with
contract requirements and this plan.
Configuration/Data Management  Develop and maintain instructions and procedures that define and
(CDM) Lead and staff document CM activities, including data management, and disseminate
to stakeholders.
 Perform CM and DM on work products.
 Provide CM policy/procedure set.
 Train CM personnel and development personnel, who perform CM
tasks, in CM procedures and methodologies.
 Support process change methodologies.
 Recommend improvements to CM processes.
 Provide for the identification and status of the CIs from acquisition to
decommission and end of life
 Manage the program CM tool, library/database.
 Control the build and release process
 Prepare release packages.
 Represent the program CM Group at customer meetings to coordinate
delivery requirements and milestones.
10.2.1.2 CM Tools
The <Program> will utilize the following Configuration Management <tool(s)>:
Page 46
<List>
*Tool 1…
*Tool 2…
10.2.1.3 CM Processes
The <Program> will utilize the following Configuration Management <processes>:
<List>:
*Procedure a…
*Procedure b…
*Procedure c…
10.2.2 Configuration Identification

Configuration Identification encompasses identifying both contract-defined deliverable work
products and internal work products that are subject to CM and the unique naming, numbering,
and marking of those work products.
Configuration items, their type and attributes will be identified and tracked via the project Asset
Repository <> tool. As a minimum, the information contained in the Asset Repository will
include the information contained in Table 28 below:
Table 28 Sample Configuration Item List

Configuration Type Attribute Vendor/Contractor
Item
<name: application Software Version #, where used/location Vendor XYZ
program xyz>
<name: system Hardware Serial #, where used/location Vendor XYZ
component xyz>
<name: document Document Version #, CSRA
xyz>
Unique titling and numbering are applied to each configuration item as detailed in <name of CM
Procedure>.
10.2.3 Configuration Change Control

Configuration Change Control deals with the functions that establish an initial configuration or
baseline. In addition, it supports the systematic evaluation, coordination, approval or
disapproval, and implementation of changes to that configuration or baseline in such a manner
that accountability and change traceability is maintained at all times.
CI changes are identified, controlled, and tracked using the Change Request (CR) process. CM
staff ensures that only CCB-approved and <Client> Program Management Organization
(PMO)-directed CRs are incorporated in Cis directed for delivery.
CM ensures:
Page 47
 Evaluation, coordination, and implementation of all changes to program

hardware, software and documentation to include function and responsibility of
configuration control process including Configuration Control Boards (CCBs), and
classification and processing of engineering change proposals.
 Description of automated CM tools and developmental and formal library controls
including check-in / checkout procedures.
 Description of the release process for documentation, data, software and
hardware.
10.2.4 Configuration Status Accounting (CSA)

Configuration status accounting and reporting encompasses the functions and activities
associated with the recording and reporting of the status of all proposed changes to formally
controlled <Program’s> CIs and their associated documentation. It also identifies how many
systems by type are in build status, test status, cutover status and decommissioned
Status information is maintained on the initiation, change status, and incorporation and closure
of all changes, such that visibility into the evolving development effort is available to
management at any point in the development life cycle. All CI status accounting data is
maintained in the <> tracking data base. CM verifies the content of baselines using status
accounting data from the tracking database.
10.2.5 Configuration Reviews and Audits
Configuration auditing examines CI records of inventory, the change of approval status, and the
change of incorporation history to ensure that the integrity and accuracy of the configuration
baseline is maintained at all times. CM audits all release packages.
10.3 Document / Data Management

The Document / Data Management section describes how deliverable and non-deliverable data
on the program will be managed, and documents the Quality Records List (QRL) and the Master
Document List (MDL) for the program.
The <Program> CDM Lead (a.k.a. Document Control Official (DCO)) is responsible for Data
Management. The CDM Lead ensures compliance with CSRA Policy 0212 Records and
Information Management and PO 0212A Records Retention Schedule.
The CDM Lead:

- Creates the architecture for the program repository
- Populates the program repository
- Maintains a Quality Records List
- Maintains a Master Document List
- Establishes Data Requirements,
- Establishes Privacy requirements,
- Establishes Security requirements and procedures for data.
Table 29 below depicts the information required for a Master Document List (MDL).
Page 48
Table 29 Sample Master Document List

Docum Document Document Issue Date Owner / POC Approval Location Archive Date
ent Type Number / ID Authority Location Range
Descri
ption /
Title
Title of Refer to PO Assigned Date the Organization’s Element description of Archive Provide
docume 0212, document document Manager or responsible software Location of the date
nt. Records number or has been staff assigned for approving application/da Record once range
Retention document ID. approved for the document tabase they become (start to
Schedule (May use use. (May responsibility issuance/ containing historical finish
“Current use “Current for issuing, revision master records dates)
version on- version on- revising, and version of for the
line” for line” for maintaining the document archived
documents documents document record
stored and stored and
controlled in controlled in
electronic electronic
form) form)
Table 30 provides a format for the Quality Records List.
Table 30 Sample Quality Records List

Record Docu Record Media Storage Access Retentio Archive Date Final Protect
Descripti ment Owner Location ible By n Period Locatio Range Dispositio ion
on / ID Type n n
Descriptio Refer Organizatio Form of Location Individu Calendar Archive Provid Disposition Descript
n of each to PO n’s record: of record als or or time Locatio e the of records ion of
quality 0212, manager Paper while in group(s period for n of date following backup
record Recor who “owns” or use by ) who which Record range retention or
stored/mai ds process Electron program / can records once (start period restricte
ntained/co Retent which ic group access are they to (proprietary d
ntrolled by ion generates record retained become finish trash, access
the Sched record and / in above historic dates) electronic for
program ule or has store al for the deletion). security
responsibilit records archiv or
y for ed safety
maintaining/ record
storing and
controlling
access to
record
11 Measurement Plan
The <Program> measurement plan describes what measures will be collected; where they will
be stored; and how measurement data and indicators for analysis will be used and reported.
The plan also describes how schedule, budget, completeness, and quality of products and
services are to be measured, monitored, reported, and controlled, and who has which
responsibilities. This plan elaborates on the performance measures identified in Section 1.5,
Measurements.
Table 31 below provides a sample measurement definition matrix for inclusion in the plan.
Page 49
Table 31 Sample Measurement Definition Matrix

Measurement Measure Storing / Collecting Analysis / Reporting
Objective
Monitor the Total number Collection Activity: Requirements team Analysis: Trend analysis
scope of of approved will record the number of approved Analysis by: Requirements
functional requirements requirements in the baseline. Manager
capabilities Provided by: Requirements Manager
allocated to the Threshold: none
Requirements Made Available to: Requirements
(example) release Reported to: Program
Manager Manager
Frequency: Monthly Frequency: Quarterly
Stored In: Requirements Repository
Library
Monitor the Number of Collection Activity: Requirements team Analysis: Threshold/Trend
stability of the approved will record the number of approved analysis
functional requirements changes to the baseline. Analysis by: Requirements
capabilities changes: Provided by: Requirements database Manager
allocated to the count of the manager
release added, Threshold: Volume of
Requirements
modified, Made Available To: Requirements changes = 20% of total
Volatility Manager requirement count in one
deleted
(example) requirements; Frequency: Monthly reporting period
whether origin Stored In: Requirements Repository Reported to: Program
of change is Library Manager
internal or Frequency: Quarterly
external
Monitor Budget Analysis:

vs Actuals Analysis by:
Cost Threshold:
Reported to:
Frequency:
Monitor the Analysis:
planned vs Analysis by:
actuals
Schedule Threshold:
Reported to:
Frequency:
Monitor the Analysis:
SLAs/TPMs Analysis by:
Quality Threshold:
Reported to:
Frequency:
12 Continuous Improvement
The program will provide comprehensive and aggressive Continuous Improvement.
The objectives of Continuous Improvement are:
 Improve cost effectiveness
 Meet changing business needs
 Provide quality management
As part of the program’s Continuous Improvement approach, the Deming Cycle, with its four
stages—Plan-Do-Check-Act—will underpin continuous improvement.
Page 50
Activities will be monitored, measured, analyzed and reviewed and then improvement initiatives
will be implemented. The program follows the CSRA Continual Improvement Policy and
Continual Service Improvement Procedure
The program will also use the <Client> SLAs, along with other performance metrics, to support
the measurement framework. The measurement framework will rely on monitoring and
measuring of metrics.
The program will use objective data to validate recommendations, align activities in order to
meet targets and justify and prioritize necessary courses of action to implement changes and
corrective actions.
The <Program> process for Continuous Improvement is the 7-Step Improvement Process
Plan-Do-Check-Act (see Figure 9).
Figure 6 The CSI 7-Step Improvement Process
Vital coordination between the <CLIENT> and the program, and control and prioritization of
Continuous Improvement initiatives, are accomplished through the Continuous Improvement
Register.
The <client> specification has identified the most important concerns for Continuous
Improvement, which are reflected below:
1. Recommendations for improvement opportunities
2. Performance metrics
3. Activities to implement
Page 51
4. Cost effectiveness
5. Continual re-evaluation of methods
6. Optimization and consolidation
The program will implement comprehensive and rigorous Continuous Improvement, fully
coordinated with <Client> management, by developing and following the Continuous
Improvement Plan as outlined above.
Each of the six components of the Continuous Improvement Plan is detailed in the following
sections. Each section also discusses that component’s Continuous Improvement Objectives
and Concepts as shown above, and how the Continuous Improvement Plan will implement
Continuous Improvement for the <Client>.
12.1 Recommendations for Improvement Opportunities

As part of the Continuous Improvement process, the program will work closely with process
owners and service owners on developing recommendations for improvement, and tracking
them to closure. This will determine which improvement activities to focus time and effort on, for
maximum improvement value.
The program will follow the Continuous Improvement 7-Step Improvement Process needed to
identify, define, gather, process, analyze, present and implement improvements. The goal of
the 7-Step Improvement Process is to increase the efficiency, effectiveness and cost-
effectiveness of program processes.
In addition to meeting with process owners and service owners, the program will review the
following sources of information for improvement opportunities:
 Client Satisfaction Surveys
 Client feedback from Service-level reviews, Daily Service Reviews and other
meetings
 End-User customer input
 Missed SLAs
 Performance metrics trending negative (yellow)
 Results of Internal and External Audits
 Candidates for automation, and user self-help
 New Industry trends, Vendor Road Maps and innovations
 New or pending federal and state laws and regulations with respect to security,
privacy, etc.
 Root Cause Analysis of problems and failed changes (Requests for Change).
(Note: After potential improvement opportunities have been captured, the remediation schedule
will be determined by client and CSRA prioritization).
Once a Continuous Improvement activity has been agreed upon by the program and <Client>, it
will be entered into the official Continuous Improvement Register. The Continuous Improvement
Register records and manages improvement opportunities throughout their lifecycle and
becomes part of the Knowledge Management System.
A Continuous Improvement Register records the following information for improvement
opportunities:
Page 52
 Name of improvement opportunity

 Assigned action item number
 Date Opened
 Category and sub-category
 Approximate timeframe to resolve
 Priority
 Associated Metric, RFC#, Incident#, Problem#, CAR# (as applicable)
 Justification for completing the improvement program (includes expected cost
savings, cost estimate, expected benefits (greater accuracy, less rework, higher
availability, etc.)
 Approval from Senior Management
 Name of person assigned to complete (if multiple tasks, multiple people will be listed)
 Implementation Schedule (if the Continuous Improvement initiative is complex)
 Deadline
 Actual Date Completed.
12.2 Continuous Improvement Performance Metrics

The program will analyze performance metrics for Continuous Improvement opportunities (refer
to the Measurement Plan section for candidate measures). The program will review
performance metrics with process and service owners to get their feedback and input.
For each of the metrics, the program will develop a method to collect, report, monitor, and
improve them.
There are several components to this:
 Tracking performance trends to identify areas for improvement (generally yellow or
red)
 Identifying potential problems before they occur, correcting them and following up on
corrective actions to ensure they were completed (proactive)
 Correcting incidents after they occur and then following up on corrective actions to
ensure they were completed (reactive)
 Performing root cause analysis (or Component Failure Impact Analysis, or other
method) to determine actual source of problems or inefficiencies. This knowledge
may be used to take preventive actions to avert future incidents
 Assessing present performance and striving toward future desired performance by
using centralized, standardized performance management metrics
 Implementing enterprise-wide processes, data collection and tools whenever
possible to provide visibility, alignment, collaboration and consistency across the
<Client> Program
 Ensuring the Change Management process is followed, so changes are approved,
tested prior to deployment, and implemented.
 Analyze missed milestones for improvement opportunities.
 Ensure metrics are communicated and understood by relevant stakeholders
 Individual work activities that affect performance need to be understood and mapped
out.
Page 53
12.3 Continuous Improvement Activities to Implement

After all potential improvement opportunities have been captured, the <Client> and CSRA will
prioritize and select which improvement opportunities to remediate first. This is critical for the
efficient use of resources.
The <Client> and CSRA will be able to rely on the wealth of timely data provided by CSRA-
supported tools and methods to expeditiously evaluate of the cost and benefits of each potential
improvement opportunity.
Higher priority Continuous Improvement initiatives will be completed first.
Examples of High Priority Continuous Improvement initiatives are:
 Negative feedback on Client Satisfaction Surveys
 Missed SLAs or deliverables
 <Client> enterprise-wide deadlines, initiatives or directives
 Continuous Improvement initiatives that will yield large cost savings.
The Priority levels of High, Medium and Low are based on impact in terms of the number of
people / end users, locations or systems affected.
For example, High Priority Continuous Improvement initiatives affect many people / end
users, or involve multiple locations or multiple systems/tools. Low Priority Continuous
Improvement initiatives affect one or two end users, or involve one location or parts of a
system or tool.
Table 32 illustrates the types of Continuous Improvement activities that the program will perform
to support the <Program>.
Table 32 Continuous Improvement Example Tasks
<CLIENT> Tasks Examples of Continuous Improvement Activities
Enterprise Management Services  Confirm that Root Cause Analysis (RCA)s conducted for
(EMS) missed service levels are successfully identifying and
remediating root causes
 Confirm Configuration and Asset Management processes are
being adhered to by personnel
 Review Student Evaluation Forms for Training provided to
<CLIENT> personnel and implement improvement activities
Enabling Technology Services  Confirm that any issues identified in annual Business Continuity
(ETS) testing have been resolved
 Examine device configurations for compliance
 Review any Lessons Learned from <Program> Closure
Support for Continuous initiatives
Client Support Services (CSS)  Confirm procedures are in place and are being followed to
support troubleshooting and incident resolution Services
 Confirm procedures and workflows are written for the Help
Desk Support activities
Protection Assurance Services  Confirm newly developed security procedures comply with ITIL,
(PAS) FISMA and COBIT frameworks
 Review firewall port change requests to ensure compliance
with the change management process
 Review CSIRT procedures for remediating firewalls, anti-
malware systems, HIDS/ NIDS, host anti-virus and application
whitelisting for completeness/accuracy
Engineering and On-Demand  Confirm Test Plans for proper execution of images on different
Page 54
Services (EODS) devices have been written and contain the necessary elements
 Confirm network-accessible data repository for patches, service
packs and upgrades functions properly
Development, Quality  Audit procedures developed for the acceptance, installation
Assurance/Testing Support and support of software and hardware into the <client> Lab to
confirm they are being followed
 Confirm Operational Level Agreements between teams have
been documented and are up-to-date
Asset Acquisition Services (AAS)  Validate Procurement Rosters (Technical Refresh, Strategic,
Recurring & Procurement)
 Confirm Quarterly Process Review Report contains all required
elements
The program will ensure Continuous Improvement initiatives are tracked to completion and
correctly and fully resolved by:
 Using the Continuous Improvement Register to document and track improvement
opportunities
 Providing Continuous Improvement status reports to <Client> and CSRA
management
 Following up on a regular basis with personnel assigned to remediate Continuous
Improvement initiatives
 Escalate to management if a Continuous Improvement initiative is going to miss its
deadline to provide visibility (following documented Continuous Improvement
escalation procedure)
 Collecting evidence to confirm that the Continuous Improvement initiative has been
completed (ex. new metrics, observation, new document written such as Operational
Level Agreement, meeting minutes, new device configurations, settings, additional
memory or new model or software version, training records, etc.).
12.4 Cost Effectiveness

The program develops documented cost estimates for Continuous Improvement initiatives,
either as a Rough Order of Magnitude (ROM) or a more formal business case for opportunities
to reduce cost, reduce rework, improve accuracy and improve cost-effectiveness.
Using methods such as the Total Cost of Ownership (TCO), the program will calculate the total
lifecycle cost of services and compare from year to year to measure potential cost reduction.
The program will:
 Forecast the costs of the improvement recommendation while incorporating people,
partners (subcontractors, suppliers, third parties), processes and technologies.
 Analyze various alternatives and tradeoffs to ensure that the best improvement
recommendations to reduce costs and improve service delivery are chosen.
 Present the cost data supporting the chosen recommendation for the Continuous
Improvement initiative and its alternates in an easy-to-read format so stakeholders
can challenge or ask probing questions to have a voice in the decision.
 Work with the Financial Manager to establish a cost basis for specific activities (for
ex., cost per change) to serve as a cost baseline, enable trending and lifecycle cost
analysis and measure cost-effectiveness.
Page 55
 Develop a Decision Analysis and Resolution for different categories of Continuous

Improvement initiatives that enables cost-effectiveness awareness such as Rent vs.
buy, basis for software license charges, basis for maintenance contract charges, etc.
 Regularly review IT operations for cost reduction in such areas as:
o Eliminate rework,
o automation opportunities,
o changes and standardized processes,
o reducing complexity,
o integrated tool sets, and
o retiring End-of-Life and obsolete equipment.
12.5 Continual Re-Evaluation of Methods

Continuous Improvement is built into CSRA programs, and all employees and subcontractors
are encouraged to identify and bring forward opportunities for improvement. The program will
ensure that applicable quality management methods are used to support continual improvement
activities.
The program will conduct performance Gap Assessments to compare the actual operational
process environment to the performance standards in effect. Improvements in process
capability or potential shortcomings are noted and will be addressed. These assessments will
be conducted throughout the lifecycle of the contract.
Upon program initiation, the program will assess the <Program> processes. The program will
determine whether process implementation or improvement objectives are being met, and
whether the expected benefits have materialized from the investment made.
The program will use the iterative Continuous Improvement Approach as shown in Table 33.
Table 33 Iterative Continuous Improvement Approach
Continuous Improvement Approach Definition Data to review
What is the Vision? Understand high-level business objectives. <CLIENT> Vision, mission, goals, values and
The vision should align the business and IT objectives
strategies
Where are we now? Assess the current situation to obtain Baseline Assessments
accurate, unbiased snapshot of where the
organization is right now
Where do we want to be? Provide specific goals and a Measureable Targets
manageable timeframe
How do we get there? Continuous Improvement Plan to achieve Service and process improvement
higher quality service by implementing or
improving processes
Did we get there? Verify that measurements & metrics are in Measurements & Metrics
place, process compliance is high and
business objectives were met by the service
levels.
How do we keep the momentum going? Ensure momentum for quality improvement is Follow the steps again
maintained by assuring that changes become
embedded in organization
The program uses a number of techniques to measure the efficiency and effectiveness of
services and processes:
Page 56
 Benchmarking—CSRA will identify gaps in terms of people, process and technology,

and to see where CSRA is rated and ranked against our competitors. The program
will conduct a baseline assessment upon contract startup so improvement can be
measured from the baseline via metrics.
 Total Cost of Ownership (TCO)— The program will calculate the total lifecycle cost of
services, and compare year-to-year metrics to assess potential cost reduction. TCO
calculations typically include initial purchase price or monthly charges, installation
and maintenance charges, cost of software licenses, costs of training over a multi-
year period.
13 Program Quality Plan

The quality plan describes the goals, objectives, constituent elements, staffing, and operation of
a quality system for the <Program>. The <Program> follows the CSRA procedure Manage
Program Quality for developing a Program Quality Plan.
Figure 8 provides the organizational Quality process flow that the program adheres to:
Create
Quality Plan
INITIATION
Review and
Communicate
Quality Plan
Conduct Project
Perform Audit Work Health
Peer Review and Products and Assessments
Testing Activities Processes and Delivery
Reviews EXECUTION
Perform Quality
Close-Down
Activities
COMPLETION
Figure 7 Organizational Quality Process Flow
13.1 <Program> Quality Organization

The <Program> Quality Assurance Manager (QAM) will be a senior member of the program
who performs and/or coordinates process and product quality management activities on a full-
Page 57
time basis. Assignment to this role is made in coordination with the CSRA E2O Quality
Management Office (QMO).
Other program personnel may be designated by the <Program> QAM to perform quality
management activities as needed to accomplish the requirements described by this QMP.
13.2 Independence
Independence in the performance of program quality management activities is achieved by
ensuring that personnel assigned to quality activity tasks do not evaluate products for which
they have had any development responsibilities. Independence is also achieved from a
matrixed reporting of QA staff through the QMO.
The <Program> QAM reports directly to the E2O QMO. The <Program> staff members report
to the QAM in order to ensure independence of all personnel working on quality assurance and
quality control activities.
The E2O QMO provides quality assurance management and oversight of the <Program> QMO
to include the review and audit of all <Program> QMO processes. The <Program> QAM is
authorized to escalate any quality issue(s) that have not been resolved at the program level,
directly to E2O Senior Manager of Quality.
13.3 Responsibilities
The QAM is responsible for ensuring that all contractual quality requirements are fulfilled. To
accomplish this, the QAM has the authority to allocate resources to the performance of quality
management and related support activities.
The <Program> QMO staff, under the direction of the <Program> QAM, supports fulfillment of
program quality requirements. Specific responsibilities delegated to the <Program> QMO may
include the following based on specific program needs.
 Ensure that the expectations of the <Program> QMO activities are identified and
understood by the <Program> team members.
 Assist in tailoring the process baseline as directed by the PM.
 Review <Program> products and deliverables, including <Program> Program
Management Plans, for compliance with applicable objectives or accepted
standards, requirements, review comments; and to determine consistency,
completeness and traceability.
 Develope and implement <Program> Quality Plans, Quality Control Plans, Quality
Assurance Surveillance Plans etc.
 Audit <Program> Processes to identify opportunities for problem prevention as well
as improvements to <Program> processes.
 Manage the documentation of process non-compliances and product defects and
track them through correction and closure.
 Consult with Team Leads and review proposed preventive and corrective actions to
address non-compliances, defects, or issues identified in reviews and audits.
 Monitor Peer Review processes, documentation of findings and provide oversight to
review artifacts to measure correction and/or justification of findings.
Page 58
 Escalate overdue or insufficient non-compliance resolutions to the AM and other

appropriate resources.
 Identifiy and facilitate Lessons Learned opportunities and track process
improvements through implementation.
 Collect and analyze quality measurement data and report quality metrics and trends.
This measurement and metrics data is generated as a result of categorizing defect
data in deliverables based on DHMH reviews.
 Develop, maintain and coordinate a Quality Records List (QRL) and coordinate
collection, archival and maintenance of such records.
 Participate in <Program> Change Control Review Board (CCB) meetings and related
activities.
 Provide oversight for process and procedure development and guidelines.
 Interface with organizational auditors and external auditors.
 Coordinate and oversee day-to-day quality management activities.
 Support testing by developing and completing audits on test processes.
13.4 Schedule
All Deliverable reviews are conducted in accordance with the <Program> Schedule of
Deliverables and is scheduled within the IMS. In addition to the IMS schedule, QMO audit
activities are scheduled and included in the <Program> repository.
13.5 Quality Assurance Measurements

Quality measurement data are collected regularly and reported to program management and
the QMO as requested. These data provide a quantitative assessment of the quality aspects of
the work processes and products.
Data included within the <Program> are used in the generation of the base quality
measurement data and action item statistics which are listed below.
The following base quality measurement data are collected monthly.
 Number of Peer Reviews, Deliverable Reviews, Product Reviews, and Process
Audits conducted (providing a six month rolling trend).
 Number of Process Audits Planned versus Completed.
 Number of Review / Audit non-compliances opened/closed.
 Number of days that Review / Audit non-compliances are past due.
The QMO also provides <Program> Quality Management Program Metrics. These statistics
include the following:
 Defect Density – Number of defects found divided by number of units of work (e.g.,
#defects / #pages).
 Weighted Defect Density – Number of defects per unit of work, weighted by the
severity of defects.
 Defect Removal Efficiency – Number of defects removed prior to implementation
as a percent of total defects.
Page 59
 Service Level Agreement (SLA) performance as required by contract.
13.6 Audits
Through audits, opportunities for problem prevention as well as improvements to processes are
identified. Observed deficiencies and adverse findings are tracked through closure in the non-
compliance repository, located on the <Program> QMO site or corporate Quality Information
System (QIS). Audits are conducted in accordance with <Program> defined schedules and
procedures, which are summarized in this section.
13.6.1 Process Audits

A process is a program-specific procedure for creating, modifying, or meeting program work
functions. Audits can be conducted on any <Program> process to assess compliance with
planned procedures, specifications, and standards; organizational and contractual
requirements; and other applicable criteria as stated in the <Program> procedure <>.
13.6.1.1 Process Audit Schedule
The process audit schedule will be created to minimize impact on the <Program> work
activities/resources. Process audits will be scheduled according to process availability and may
depend on the following factors:
 Is process applicability limited to specific program phases of <Program>?

 Does the <Program> IMS show that the process is only applicable during a specific
time period (e.g. available during certain months)?
 Is the identified process part of future activities and/or has not yet been implemented
within <Program>?
 Are there are specific days that the process occurs?
 Are Subject Matter Experts (SME), if required, available?
Table 34 provides a list of the processes that the QMO are planning to audit over the next 12
months (in no specific order).
Table 34 Planned Process Audits
Program Planning –
Program Planning – Program Planning -
Risk Management
Scope Management and WBS Communication Management
(Risk, Issue, & Opportunity)
Program Planning - Schedule
Program Planning – Program Planning – Management, Program
Change Management Process and Product Schedule, and WBS [Monitoring
(Estimation and Overall Process) Quality Assurance and Control (Program Tracking &
Oversight)]
Program Planning – Configuration Management Measurement and Analysis
Staffing Management (Process and Planning) (Schedule Measurement)
Development Requirements Management
Testing (Process and Planning)
(Process and Planning) (Process and Planning)
Reviews & Reporting Decision Analysis and Resolution Data and Records Control
Procurement (including Supplier Continuous Business

Process Management
Agreement Management) Process Improvement
Page 60
Material Control Measurement and Analysis

<Program> Training
(Asset Management) (Software Measurement)
Deliverable Management
Program Environment
(Overall Process and Planning)
As process audits are scheduled, a Quality Evaluation Record (QER) will be created in the
<Program> QMO site, reflecting general information about the audit.
13.6.1.2 Process Audit Preparation
In preparation of audit, the QMO will review the <Program> defined procedure and create a
tailored checklist, which will contain elements to be validated. The audit checklist, as well as
audit scope and an overview of the QMO audit methods, will be reviewed with the process
owner prior to audit. Any questions or issues will be addressed prior to audit. The QMO will
also secure a SME for the audit if required.
13.6.1.3 Conducting a Process Audit
To perform the audit, process activities may be observed firsthand, interviews may be
performed with personnel performing the process, and any pertinent information and data may
be reviewed. Any applicable documents, records, data, products, and other artifacts related to
the process elements may be utilized to validate process compliance. Every process element
on the checklist is audited and any findings are documented onto the audit checklist.
13.6.1.4 Process Audit Results
If the QMO finds process elements that are non-compliant, the QMO will determine if there is a
potential for impact to <Program> cost, schedule, scope, and / or other contractual
requirements and/or if there is an impact to the outcome of the process activity. The potential
impact of the non-compliance determines the type of remediation that will be used.
13.6.1.5 Process Audit Artifacts
All artifacts related to the process audit will be loaded into the <Program> QMO site.
13.6.1.6 Process Audit Reporting
Upon completion of the audit process, findings will be reported to the process owner informally
in a Draft Audit Report, which will allow the process owner an opportunity to comment on the
findings, ask questions, or provide additional evidence prior to audit closure. Final audit reports,
summarizing the audit, will be created in two (2) pieces, an Audit Detail Report, which will be
distributed to the process owner(s), and an Audit Summary Report, which will be distributed to
the management team for oversight purposes. The <Program> QAM will distribute these
reports once all non-compliances have been remediated. The audit reports, as well as
statistical results, will also be uploaded to/created in and available in the <Program> QMO site.
13.6.2 External Audits

QMO will interface with external auditors in the event of an external audit. If non-compliances
and/or deficiencies are identified by auditors external to Team CSRA, the <Program> QAM or
other designated <Program> QMO staff will document and follow to remediation.
13.7 Program Product Reviews

Reviews are conducted on all deliverables and on select products, to ensure that they meet the
requirements and program objectives. Reviews are conducted in accordance with <Program>
defined procedures, which are summarized in this section.
Page 61
13.7.1 Informal Deliverable Reviews

Deliverables will be reviewed by one or more program members independent of the author(s)
prior to their finalization. Program members are selected based on expertise and availability.
The Informal Reviewers review the deliverable and provide comments and feedback directly to
the author. This process helps ensure that the deliverable is understandable.
13.7.2 Deliverable Peer Reviews

Peer Reviews are reviews of contractual deliverables by a cross-functional team. Review teams
use their own expertise/area of specialty, as well as general criteria from the Format and
Content of Deliverables (FCD), to evaluate the quality of a deliverable, and may be made of
different team members depending on the deliverable being reviewed. A representative of the
QMO, a technical SME, PMO, and Management participates in and facilitates the peer review.
The program will utilize the CSRA Peer Review Procedure with details being documented in
<Program> procedure <>.
13.7.3 Peer Review Schedule

It is the goal of the QMO to conduct peer reviews at least five (5) days prior to the release of a
deliverable. Scheduling peer reviews in advance of release allows time for
corrections/addressing of comments prior to the submission deadline to the client.
13.7.4 Peer Review Preparation

A QMO staff member will create a checklist that is specific to the deliverable being reviewed.
Upon receipt from the author, the QMO will distribute the deliverable to the peer review team,
with review instructions and timeframes.
13.7.5 Conducting a Peer Review

Each peer review team member reviews the deliverable and records comments and concerns
about potential quality infractions. Team comments are documented onto QMO forms /
checklists and provided to the author.
13.7.6 Peer Review Results

Results from the peer review are reviewed by the author and necessary changes are addressed
in the product. After the deliverable is updated, one or more of the reviewers confirms the
adequacy of the changes and the product is placed under formal configuration control.
The QMO reviews the deliverable to ensure all comments have been addressed and a Peer
Review checklist is finalized and a data report is created within the <Program> repository. A
deliverable will not progress to the QA Deliverable Review until the QMO accepts all changes
made.
13.7.7 Peer Review Reporting

Peer review results are recorded onto the <Program> QMO site. Statistical results are
compiled and reported monthly by the <Program> QAM.
13.7.8 Peer Review Artifacts

Peer review checklists and any other artifacts related to the peer review will be loaded into the
<Program> QMO site and forwarded to the CSRA Measurement Repository.
Page 62
13.8 QA Deliverable Reviews

All deliverable documents and supporting documentation related to performance, planning,
system / subsystem design and implementation, product / process verification and validation,
use or maintenance of software / system products, and system performance or analysis are
subject to deliverable reviews.
Assortments of methods are employed to determine the deliverables’ adherence to required
format, compliance with applicable contractual requirements, and consistency,
comprehensibility, and technical adequacy.
All detailed procedures are documented in the <Program> procedure <>.
13.8.1 QA Deliverable Review Schedule

Deliverables are reviewed by the QMO prior to the submission of the deliverable to the
<Program> PM for signature, and subsequently submission to <client>.
The dates of QMO deliverable reviews are outlined in the IMS. A Quality Evaluation Record
(QER) will be created in the <Program> QMO site, reflecting when a review is scheduled and
other general information about the review.
13.8.2 QA Deliverable Review Preparation

A QMO representative will create a checklist that is specific to the deliverable being reviewed,
ensuring that any specifics related to the acceptance criteria of the deliverable are addressed.
Additionally, QMO will ensure that a peer review of the document has been conducted and that
the author(s) have finalized their deliverable.
13.8.3 QA Deliverable Review Focus (Draft Version)

The QMO will conduct a QA Deliverable Review with a primary focus on the following elements:
 The document adheres to its required format.
 The document follows the content description outlined in the Format and Content of
Deliverables document.
 The document complies with applicable contractual requirements.
 The document is consistent with the <Program> documentation standards.
 The document is technically correct.
 The document is complete and sufficiently addresses the overall ‘intent’ of the subject.
 The document meets the expectations and guidelines set forth in the contract.
13.8.4 Conducting a QA Deliverable Review (Draft Version)

A deliverable acceptance review will be conducted as follows.
 QMO staff will review all formal deliverables prior to submission to the PM for
signature and submission to the client for a <x> business day review.
 QMO staff will complete a QA Deliverable Review checklist for each review.
Page 63
13.8.5 QA Deliverable Review Focus (Final Version)

The QMO will conduct a QA Deliverable Review with a primary focus on the following elements.
 The document adheres to its required format.
 The document is consistent with the <Program> documentation standards.
 The document is technically correct.
 The document is complete and sufficiently addresses the overall ‘intent’ of the subject.
 The document contains all the required signatures.

 The Document Revision History has been updated and changes made have been
summarized.
 All review comments been addressed either in the deliverable or with the original
comment in the Comments document.
 The Footer has been annotated to indicate changes.
13.8.6 Conducting a QA Deliverable Review (Final Version)

A deliverable acceptance review will be conducted as follows.
 Upon receipt of the revised deliverable, the QMO will conduct a final deliverable
review prior to submitting to the PM for signature and submission to <client> for a
<x> business day review and acceptance sign-off.
 QMO staff will complete a QA Deliverable Review checklist for each review.
13.8.7 QA Deliverable Review Outcome

If the deliverable has a minor deficiency in consistency, clarity, grammar / spelling (or other
editorial defect), or minor formatting issue(s), the QMO will make the minor changes.
If the deliverable has a major or critical deficiency in completeness, accuracy, security, or
format, then the deliverable is sent back to the author for corrections.
If the deliverable meets all criteria in the QA Deliverable Review Checklist, the deliverable is
submitted to the PM for signature and submission to the client.
13.8.8 QA Deliverable Review Artifacts

All QA review results are documented in a QA Deliverable Review Checklist.
13.8.9 QA Deliverable Review Reporting

Statistical results from all QA Deliverable Reviews are compiled and reported monthly by the
<Program> QAM to CSRA Management. All completed QA Deliverable Review dates are
reported to the CSRA PMO IMS Status meeting on a weekly basis.
13.9 Quality Management Product Reviews

A <Program> product is an artifact produced as a result, or by-product, of the development
process, both deliverable and non-deliverable (e.g., specifications, reports, and source code).
Quality Management Product Reviews will be conducted on products, through independent
examination, assessing compliance with specifications, and standards; organizational and
contractual requirements; and other applicable criteria.
Page 64
13.9.1 QA Product Review Schedule

Product reviews may be conducted on a planned basis, with some scheduled periodically and
others performed as a function of defined milestones. Reviews may also be conducted on an
ad-hoc basis as warranted by conditions experienced or approved requests from CSRA
management and the client. As product reviews are identified, a QER will be created in the
<Program> QMO site, reflecting general information about the review.
13.9.2 QA Product Review Preparation

The <Program> QAM or designee will develop a review checklist specific to the work product
being reviewed. The QMO will also secure a SME for the audit if required.
13.9.3 Conducting a QA Product Review

A QMO staff member will review the product, focusing on the following aspects.
 The product adheres to its required format.
 The product complies with applicable contractual requirements.
 The product is consistent with the <Program> documentation standards.
 The product is technically correct.
 The product is complete and sufficiently addresses the overall ‘intent’ of the subject.
 The product meets the expectations and guidelines set forth in the contract.
13.9.4 QA Product Review Results

If the product has a deficiency in formatting or grammar / spelling, the QMO staff member will
make the minor changes.
If the product has a deficiency in consistency, completeness, accuracy, security, or clarity, then
the deliverable is sent back to the author for corrections.
If the product meets all criteria in the QA Product Review Checklist, the product is submitted to
the PMO for further processing.
13.9.5 QA Product Review Artifacts

All QA review results are documented in a QA Product Review Checklist.
13.9.6 QA Product Review Reporting

Statistical results from all QA Product Reviews are compiled and reported monthly by the
<Program> QAM to CSRA Management. If the QA Product Review is listed in the IMS,
completion dates are reported to the <Program> Status meeting on a weekly basis (i.e.
<Program> Monthly Status Report).
13.9.7 Quality Management Records and Reports

This section describes the reports of <Program> QMO activities that are prepared and the
types of quality records maintained by the program.
Page 65
13.9.8 Quality Records

The <Program> QAM ensures that records of each quality management activity performed are
prepared and maintained under configuration control. Such records are identified in a Quality
Records List (QRL) developed and promulgated to personnel by the <Program> QAM. The
QRL is located in the <Program> repository. Refer to Table 22 for details of the QRL format.
Completed product review forms;
13.9.9 Quality Reports

The QMO prepares various reports in support of the Program. These reports provide a status of
quality management activities, the results of audit activities, and non-compliances identified
during audit activities. The following subsections identify the various reports prepared by the
QMO in support of the program.
13.9.9.1 Monthly Reports
The <Program> QAM or designee prepares a Monthly QA Status report of quality management
activities performed on the program. The report identifies key activities performed, monthly
accomplishments, and a trend of QMO activities (reviews and audits performed) over a six
month trend period.
Included in the report are basic quality measurements defined by the QMO such as the
numbers of process audits and product reviews completed along with the number of corrective
action requests and defects identified during audits and reviews.
13.9.9.2 Reviews and Audit Reports
Following the completion of reviews and audits, the <Program> QAM, or designee prepares
and coordinates the completion of a report of the observations and findings.
As appropriate, recommended approaches to resolve noted deficiencies and suggested
improvement areas are also provided in the reports. As above, copies of the audit reports are
provided to the PM and a copy is archived in <Program> Portal.
A basic set of review and audit procedures and templates reside in the <Program> repository.
As specific reviews and audits are planned and conducted, these process assets will be tailored
to meet the specific requirements of each review and audit.
13.9.9.3 Ad Hoc Reports
Reports are prepared and submitted to the CSRA PM by the <Program> QAM or designee, as
requested, to respond to unscheduled or non-recurring support requests received. The
completed report is archived in the <Program> repository.
13.10 Non-compliance Remediation

Observed deficiencies and adverse findings will be documented and remediation will be tracked
through resolution and closure.
Most non-compliances are identified in audits and reviews, reflecting deficiencies in performing
in accordance with procedural requirements, complying with contractual requirements, or
following product standards.
Noncompliance remediation is conducted in accordance with <Program> defined procedures,
which are summarized in this section. Non-compliances can be positive (e.g.: finishing ahead of
schedule and/or below budget) or negative (e.g.: finishing behind schedule and/or over budget).
Page 66
It is the potential impact of the non-compliance that determines the type of remediation that will
be used. This section describes the two (2) types of noncompliance remediation’s that are used
on <Program>.
13.10.1 Action Items

For non-compliances where documented processes were not followed, and there is not a
potential impact to <Program> cost, schedule, scope, other contractual requirements, and / or
the outcome of the process activity, an action item will be utilized to track remediation.
Action Items will be created on the <Program> repository, documenting the deficiency, and
assigned to the appropriate team or functional area, and team member(s) responsible for
performing the remediation.
Upon notice of resolution, the <Program> QAM or designee validates that the
noncompliance has been resolved.
If the noncompliance is not resolved or if the action item resolution is assessed as deficient,
the <Program> QAM or designee reviews the outstanding issue with the appropriate
manager.
If an acceptable resolution is not agreed upon, the <Program> QAM escalates the matter to
the PM.
13.10.2 Corrective Action

For non-compliances where documented processes were not followed, and there is a potential
impact to <Program> cost, schedule, scope and / or other contractual requirements and / or a
potential negative impact to the outcome of the audit / review activity, a Corrective Action
Request (CAR) will be utilized to track remediation. CARs associated with this QMP refer to
those generated as a result of a process audit.
To log, track, report, and maintain each corrective action identified, an entry into the <Program>
CAR repository will be created in the <Program> Portal QMO site.
The CAR will be routed to the appropriate <Program> staff throughout each phase of the
corrective action lifecycle. A plan to resolve the non-compliance will be submitted to the QMO
in the form of a Corrective Action Plan (CAP).
It is the goal of Team CSRA to resolve the non-compliance and for the QMO to validate
corrective action items within 48 days of CAR creation. If the non-compliance is not resolved or
if the corrective action taken is assessed as deficient, the <Program> QAM or designee reviews
the non-compliance and its status with the appropriate manager and if an acceptable resolution
is not agreed upon, the <Program> QAM escalates the matter to the PM as defined in section
12.11.
13.11 Quality Management Escalation

Quality Management escalation occurs within the non-compliance remediation lifecycle if an
acceptable action is not taken, documented and / or agreed upon within the designated
timeframes for each workflow milestone. It is the responsibility of the QMO staff member who
identified the non-compliance to escalate to the <Program> QAM.
The <Program> QAM is responsible for communicating any escalations to the appropriate
manager or to the PM if necessary. Escalations are documented into the appropriate Action
Item or CAR in the <Program> repository.
Page 67
14 Program Verification Plan

Product evaluations are performed primarily through peer reviews, verification and validation
processes, and testing. Independence of reviews is critical to ensure that each product
undergoes one or more objective reviews to verify compliance with its specified requirements.
To ensure that independent evaluations are carried out, the following activities will be utilized:
o Product reviews are performed by individuals who are not directly associated
with development of the product under review.
o Software components are tested by the test team before release.
o QMO will provide oversight of Peer Review and subsequent tracking of corrective
action, if applicable.
The following sections describe the strategy and process for verification of products prepared on
this program.
14.1 Verification Strategy

Verification planning must be an integral part of the planning process for the work products.
Provisions for verifying products and product components must be embedded into the product
requirements, product design, product implementation, and the maintenance, enhancement,
operation, and training support for the system after its operational deployment.
Table 35, Verification Strategies for Program Work Products, identifies a set of verification
methods and related procedures and support aids for use in verifying items or products.
Table 35 Verification Strategies for Program Work Products and Services
Item to be Verified Verification Method Verification Procedures and Aids
Peer Review Peer Review Checklist
Deliverable Documents
QA Deliverable Review QA Deliverable Review Checklist
QA Requirements Review Checklist
QA Requirements Review
Requirements QA Use Case Review Checklist
QA Use Case Review
Requirements Tool
Design
QA Design Review QA Design Review Checklist
Test Case Specifications
QA Test Plan Review QA Test Plan Checklist
Service Level Management
Services SLA Reviews
Procedure
14.2 Verification Process

The verification process includes the approach to establishing and maintaining a suitable,
controlled work environment, together with a description of how the work products and services
to be verified are selected and the verification methods to be used.
Page 68
When peer reviews are conducted for requirements specifications, each requirement is
examined for testability and traced to its applicable test procedures. Verification methods are
categorized.
Code segments, hardware and / or software configuration items, or threads are integrated and
tested in a controlled test environment. This is done using controlled inputs and comparing
results with expected output, based on a written test procedure, so that detailed test results are
recorded and any noted problems can be repeated.
In a controlled test environment, specialized tests can be performed using various test tools or
simulators to examine the quality of the products under test.
Prior to performing any tests, all test plans and procedures are verified to ensure that they are
adequate, conform to applicable standards, and have been reviewed by technical personnel.
This approach enhances the probability that all test planning of the system is complete and that
test results can be certified as to completeness and accuracy.
Defects found during verification activities are recorded in appropriate tools, after which they are
analyzed and appropriate product changes are developed to resolve the defects.
15 Program Validation / Acceptance Plan

The purpose of acceptance is to demonstrate that a product or product component or service
fulfills its intended use when placed in an operational environment. Validation / Acceptance
planning is also an integral part of the planning process for all work products.
Validation / Acceptance activities can be applied to all aspects of a product or service in any of
its intended environments, such as operations, training, maintenance, and support services.
Table 36, Validation / Acceptance Strategies for Program Work Products and Services,
identifies a set of candidate validation methods and related procedures and support aids for use
in validating items or products typically included in a development or maintenance solution.
Table 36 Validation / Acceptance Strategies for Program Work Products and Services
Validation Procedures / Aids /
Item to be Validated Validation Method
Acceptance Criteria
Requirements Validation Checklist;
Requirements and Use
Joint Application Design Customer Acceptance of System
Cases
Requirements Document
Design Validation Checklist, Customer
Design Joint Application Design Acceptance Of Software Design
Document
Test Cases, Test Test Case Validation Checklist,
Review
Procedures Customer Acceptance of Test Plan
Customer Acceptance of Test Readiness
Product(s) Validation Test
Results
User Manuals Inspection Maintenance Documentation Checklist
Services SLA Reviews Service Level Management Procedure
Page 69
Deliverable Acceptance provides the initial “acceptance criteria” for Deliverables. This section
provides additional detail. Salesforce will be used by the program to track deliverable
completion status.
15.1 Validation / Acceptance Process

The validation / acceptance process includes the program approach to establishing and
maintaining a suitable, controlled work environment. In addition it includes a description of how
the work products to be accepted are selected and the acceptance methods to be used.
The <Program> QAM supports the program Technical Lead in identifying the specific products
or services to be accepted and the method(s) and criteria to be used for each. The planned
acceptance method must address the relevant test procedures and acceptance criteria, based
on the levels of the product components that have been selected. The acceptance environment
may be the same or different than that used to support the verification process.
Validation / Acceptance methods are selected based on their ability to demonstrate that
selected items are accepted (see Table 36). They are identified early in the
development/service life-cycle so that they are clearly understood and agreed to by the relevant
stakeholders. The validation environment and test process are carefully controlled to provide for
replication, analysis of test results and re-examination of problem areas.
System integration and testing activities may be monitored throughout system-level testing.
During testing, selected tests may be witnessed to ensure that approved procedures are
followed. Also verified are the use of test data consistent with the data described in the test
plan and conformance of test results with the outputs described in the test procedure.
Additionally, test reports are reviewed to ensure that output anomalies or deviations resulting
from execution of the test procedures are included and that problems identified during testing
are formally recorded for subsequent review and resolution.
16 Decision Analysis and Resolution

The Decision Analysis and Resolution (DAR) process is designed to help the program make
decisions objectively and wisely. It can be used to resolve many complex business and
technical decisions. While the primary application of the DAR procedure is for technical
decisions, it will also be applied to many non-technical issues.
The DAR process is conducted by the program whenever it is determined that a decision falls
within the program guidelines that define which decisions should be subjected to an objective,
structured evaluation requiring analysis across alternatives.
Examples of decision guidelines that require the use of the DAR Process are shown in the table
37 below.
Table 29 DAR Decision Guidelines

Category of Decision Condition
Technical  Hardware and software COTS selection decisions greater than $50,000
(does not include client directed solutions)
 Evaluating design alternatives for new development, major

enhancements (new functionality), or a single SCR maintenance
change requiring effort of greater than 6 staff months (not including
Page 70
client directed solutions)
 Customer-directed DARs
 High Probability and / or high impact risk mitigation actions at discretion

of Program Manager
Programmatic  Un-billable investments of greater than $25,000
 Overhead commitments greater than $35,000
 Capital investments of greater than $50,000
 Competitive decisions involving new subcontractor selection with

estimated annual value greater than $2,000,000
 Decisions that result in requesting an increase to a program’s ceiling

above $50,000 (should include such factors as staffing (CSRA and
subcontracting), technical scope and complexity, duration, etc.)
 Customer-directed DARs
 Facility moves for greater than 25 people
 Decisions that can result in injury of the loss of life
Business Development  Decisions that can result in loss of business

(including organic growth)
 Bid / no bid decisions for opportunities previously identified in the
pipeline
 Selection of alternative contract vehicle decisions
Contractual  Decisions requesting changes to contract terms and conditions

resulting in an increase or decrease to program cost plus / minus
$50,000
 Risk authorization decisions with less than 75% probability of cost

recovery and greater than $25,000
The <Program> follows the CSRA DAR process, PC 9001.02 Decision Analysis and Resolution
Process for its DAR activities.
The DAR process consists of 8 steps:
 Define the Issue to be Resolved

 Assign a Lead and Plan the DAR Effort
 Establish Evaluation Criteria
 Identify Alternative Solutions
 Select Methods for Evaluating Alternatives
 Evaluate Alternatives
 Select Solution
 Capture Results and Archive.
Page 71
16.1 Define the Issue to be Resolved

The PM / Program team will:
 Specify the Issue
 Capture Key Data
 Capture Constraints.
16.2 Assign a Lead and Plan the DAR Effort

 Identify a Trained Lead
 Review the Issue
 Build the Initial Plan.
16.3 Establish Evaluation Criteria

 Develop the Evaluation Criteria
 Define Ranking Scale
 Rank Criteria
 Document Criteria.
16.4 Identify Alternative Solutions

 Capture Alternative Solutions
 Identify Additional Alternatives
 Solicit Stakeholders
 Document Alternatives.
16.5 Select Methods for Evaluating Alternatives

 Identify Evaluation Methods
 Document Selected Evaluation Methods(s).
16.6 Evaluate Alternatives

 Perform the Evaluation
 Consider New Alternatives
 Document Evaluation Results.
16.7 Select Solution

 Assess Risks of Solutions
 Select High Score / Low Score Solution
Page 72
 Obtain Approval
 Document Results.
16.8 Capture Results and Archive

 Consolidate Documents
 Archive.
17 Program Completion Plan

The program completion plan specifies the program completion activities that will be undertaken
throughout the life of the program. It identifies the conditions that the client must acknowledge
that CSRA has completed the program.
The <Program> follows the organizational Perform Project Completion Procedure for guidance
on Closeout execution.
Figure 11 provides the <Program> process flow for Program Closeout.
Establish
Closure
Capture Project
History
Conduct Project
Lessons
Learned
Work Session
Redploy Project Release Project

Staff Assets
Close Down
Project
Figure 8 Program Closeout Process
17.1 Establish Closure

The <Program> will close down when the client authorizes a contract close-down or <x> days
before the contract end date. In either case, the <Program> PM will document the decision to
close-down the program and the supporting rationale.
If the program does not end in the planned manner, the PM will describe the reasons that
brought about the completion and what remains to be accomplished.
Page 73
The PM will:
 Provide input for negotiations concerning the timing of the close-down so that the
remaining work can be completed and the program can shut down in an orderly fashion.
 Update the completion plan portion of the Program Management Plan (PMP) that was
established during the planning stage, showing the remaining activities necessary to
support the client and an orderly close-down; include the essential resources (budget
and personnel) needed to perform the close-down.
17.2 Capture Program History

The PM will:
 Ensure relevant program experience records are updated so that there is a history and
lessons for other programs to leverage for bidding future work and providing resource
estimates.
 Prepare a final program metrics and status report.
 Work with the CSRA E2O client satisfaction group in preparing the final client
satisfaction survey(s) and passes it to the Customer for completion. If necessary, the
PM escalates to the next level of management to ensure that the survey is completed
and returned in a timely manner.
These documents, once reviewed, are archived in the program document repository.
17.3 Capture Lessons Learned

Throughout the life of a program, the program will capture lessons learned. Capturing lessons
learned will occur at the end of phases or at major milestones.
The PM will:
 Hold meetings and include all stakeholders as participants. Given varying levels of
stakeholder knowledge, it may be necessary to conduct multiple sessions to arrive at
final lessons.
 Document lessons learned including both successes and difficulties, addressing all
aspects of the program – financial, management, technical performance. Identify
accomplishments, what went well, how to improve on future programs, as well as things
that should have or could have gone better.
 Determine if the program delivered business benefits and, if they were not as expected,
investigate what caused the benefits to differ from expectations.
17.4 Redeploy Program Staff

The PM will:
 Engage CSRA Talent Acquisition’s Internal Mobility and their assigned HR Business
Partner with 90+ days’ notice of contract end.
 Brief program staff on any completion activities that require their involvement before
leaving program.
 Provide final communication to program staff remaining on final contract date.
 Release program staff based upon an agreed schedule.
 Engage with Internal Mobility to ensure employee redeployments are accurately
captured in the appropriate HR systems..
 Work with those program staff remaining on off-boarding activities.
Page 74
 Determine a transition schedule for the employees based on the program completion
schedule.
 Work with team member’s HR Business Partner and Internal Mobility Specialist to
determine specific dates for individuals to begin their new assignments and to ensure
their transfer documentation is completed on schedule and the redeployment
(placement) is tracked in the appropriate HR system of record.
 Ensure that Workday is kept current reflecting the true program position and that the
redeployment (placement) has been accurately tracked in the HR system of record.
 Create a Personnel Transition Plan to account for how resources will be scaled back
over time; plan on keeping essential personnel for as long as possible in order to meet
contractual obligations.
 Notify CSRA HR Business Partner and Internal Mobility Specialist of the availability of
those team members affected by the completion, if they cannot be absorbed within an
existing program.
 Address Staff Career Goals.
 Have team members update their Workday Career Profile with enhanced knowledge,
skills, and abilities.
 Keep staff informed as to what is being done to communicate job opportunities, all the
while encouraging needed staff to remain.
 Redeploy Program Staff in accordance with CSRA Project Personnel Resource Planning
and Management Work Instruction and CSRA Involuntary Offboarding Process.
 Work with Human Resources’ Internal Mobility Specialists to identify possible
redeployments. Communicate any re-deployments to the Internal Mobility Specialist to
ensure all redeployments (placements) are accurately tracked in the HR system of
record.
 Assist in the placement of program personnel.
 Negotiate staff transition schedules and agreements.
 Follow formal separation policies and procedures for employees leaving CSRA by
effectively listing the end of assignment date in Workday and notifying HR Shared
Services and the HR Business Partner who can engage in off-boarding notifications and
activities.
17.5 Inventory, Release and Archive Program Assets
The CDM Lead will:
 Inventory any remaining assets used by the program.

 Update the program document repository with final data and characteristics of this
program, (e.g., program size, team size, technology, etc.) and ensure that the complete
program documentation set is archived to the program document repository with the
appropriate configuration management controls.
 Determine the final disposition of each asset.
 Archive Program Assets in accordance with the Master Document List and Quality
Records List and CSRA Policy PO 0212 Records and Information Management.
 Identify any leased inventory used for the program.
Page 75
 Transfer Knowledge Assets.

 Retrieve and assemble knowledge assets (processes, procedures, training materials,
tools, guidebooks, etc.) for release to parent business unit and / or CSRA for use as
future best practice examples.
 Disseminate various assets to libraries, curricula, methodologies, and shared data
bases.
17.5.1 Close Down Physical Environment

The PM will:
 Ensure the transition of any remaining physical assets to support and maintenance or
return them to their original owner.
 Retire systems using the CSRA procedure System Retirement Disposition Procedure as
a guide.
17.6 Close Down the Program

The PM will:
 Ensure program work is completed
 Review and assure that all contract terms and conditions have been satisfied
 Resolve ownership and licensing issues
 Sign invoices, etc., and
 Complete the transition of the Customer relationship.
Program closedown signifies the completion of all work on a program. A large quantity of
information generated during the program will have been stored with varying degrees of
formality by the members of the program team.
 Ensure all program records are available for future use.
 Update the program document repository and create a summary report of important
financial records and reports.
 Transfer responsibility for unresolved issues or remaining work to Executive
Management.
 Ensures that all deliverables (e.g., reports, studies, software, and documentation) are
complete, have received Quality Assurance (QA) certification where required, are
released by Configuration Management (CM), and are turned over to the customer as
appropriate.
 Ensures that CSRA property, Government Furnished Equipment (GFE) and Contractor
Acquired Property (CAP) are reassigned or returned as required, including subcontractor
property.
 Evaluate subcontractor performance for the purpose of maintaining quality
subcontractors for future use. The project will use the Subcontracts and Procurement
Acquisition Manual for implementing this activity.
 Verify suppliers have fulfilled their obligations. Ensure receipt and acceptance of all
deliverables.
 Make sure supplier has returned all equipment, materials, and property that were
furnished by the Customer or CSRA.
The PM works closely with the CSRA Contracts Administrator as these activities are performed:
 Account for Deliverables.
Page 76
o Confirm that all past deliverables have been submitted and accepted.
o Confirm that future deliverables are on schedule for submission.
 Confirm that all services have been successfully completed.
 Account for Milestones.
o Confirm that all major milestones have been met or are about to be met prior to
contract expiration.
 Award / Incentive Fee Evaluation.
o Document successes in preparation for a final award fee evaluation for award or
incentive fee type contracts.
 Ensure contract terms and conditions have been met.
o Resolve all outstanding contract and performance issues bringing them to
resolution prior to contract expiration.
o Identify any risks going forward.
 Close out the Work Order Authorization and charge codes.
 Determine the status of program finances, including those related to vendors and
subcontractors.
 Complete financial arrangements, making use of the organization’s finance and
accounting organizations.
 Update and finalize the program financials tracking tool.
 Verifies that all invoices have been submitted in accordance with the invoicing plan.
Particular attention should be paid to any outstanding Other Direct Costs (ODCs) that
need to be paid after the closeout, and to any outstanding fees that will not be collected
until after the program completion. (See Cash Operations- Contracts Closeout
Procedures Manual (financials)).
 Transfers responsibility for unresolved issues or remaining work to the account team
(see Manage Program Financials).
 Arranges for the close out of all charge codes associated with the program, including
special codes set up for subcontractors or supporting business units through
intercompany work orders (e.g., low cost center support).
o Closing out all charge numbers is extremely important as it will prevent staff from
inadvertently charging effort to the program.
o It is also important to notify all personnel well in advance that was billing labor to
the program that the program has concluded, and that the program's charge
numbers are no longer activated.
17.6.1 Complete Program Closedown Checkpoint
The program’s QAM will:
 Complete a Program Completion Quality Checkpoint.

 Results of the checkpoint are shared with the PM, including any deficiencies.
Page 77
Tools and Templates

The following is a list of tools and templates for this plan
Template/Tool Name Link (if applicable)

TE 9001.01.07.01 Project Management Plan Project Management Plan Template
Template
Creating a Comprehensive Program Process Training
Management Plan Using CSRA’s PMP Template
Page 78
Reference Table
Procedure Reference Type
PO 0212 Records and Information Management Policy
0212A Records Retention Schedule Policy Attachment
PO 5100 Information Security Policy
Policy 7015 Significant Incident Reporting Policy
PO 9001 Program / Project Management Policy
PO 9005 Continual Improvement Policy
0105A CSRA Export Control Manual Policy Attachment
2500B Contracts Closeout Procedures Manual Policy Attachment
4000A Property Management and Control Manual Policy Attachment
7100A CSRA Subcontracts and Procurement Acquisition Manual Policy Attachment
PC 5050.01 Product Engineering and Development Process Process
PC 9001.02 Decision Analysis and Resolution Process
ST 9001.01 Integrated Program Management Process (IPMP) Standard
PR 5030.01.16 IT Service Continuity Procedure Procedure
PR 5030.01.31 Change Management Procedure Procedure
PR 5030.01.36 Asset and Configuration Management Procedure
PR 5030.01.81 Continual Service Improvement Procedure Procedure
PR 5050.01.90 System Retirement Disposition Procedure Procedure
PR 9001.01.05 Develop Project Schedule Procedure
PR 9001.01.10 Manage Project Financials Procedure
PR 9001.01.14 Manage Risks Procedure
PR 9001.01.15 Manage Issues Procedure
PR 9001.01.16 Manage Opportunities Procedure
PR 9001.01.17 Manage Project Change Procedure
PR 9001.01.18 Manage Suppliers/Subcontractors Procedure
PR 9001.01.19 Manage Project Quality Procedure
PR 9001.01.23 Perform Project Completion Procedure

WI 9001.01.01.02 Project Personnel Resource Planning and
Work Instruction
Management
WI 9001.01.13.01 Program Management Review Work Instruction
PL 1106.01 Learning Operations Training Plan Plan
GU 9001.01.07.01 Project Environment and Data Control Guide Guide
GU 9001.01.07.10 CSRA Project Training Guide Guide
TD 9001.01.23.04 Involuntary Offboarding Process Technical Document
Page 79
Document Approval / Change History

Date Revision Approval Change/Description
08/01/2017 Initial Release CCB CR 0158 PMP template that provides more of
a "fill in the blanks" structure for completing
rather than a template with just subject areas
to be completed. Created separate Program
and Project Management Plan Templates
09/25/2017 1 Editorial Change only CR 0192 Fix numbering from section 17.3 down
10/26/2017 2 CCB CR 0198 Add PPMF training references
Page 80
TEMPLATE Program Management Plan (PMP) Template TE 9001.01.07.12, Rev. 2
Appendix A
Program Management Plan Completion Guide
Introduction
This Program Management Plan Completion Appendix is designed to assist the Program
Manager (PM) in the creation of a Program Management Plan, through the use of best
practices, examples and suggestions. The PM, while responsible for the PMP, should actively
seek contributions from the Solution Architect(s), Technical Lead(s) and Subject Matter Experts
(SMEs) engaged in the program planning process.
Please note that Section 1 – Program Plan is intended to describe what the program team will
do, when the program will be complete, what it will cost and how it will be tracked.
The Supplemental Management Plans (sections 2-17), describe how the program management
team will ensure that the Program Plan contained in section 1 will be managed to successful
completion.
Note: These supplemental plans should be completed to the appropriate level of detail based
on the program size, type and risk level of the program (Refer to Perform Project Tailoring).
When completing supplemental plans, if the program maintains a separate Engineering
Management Plan or Software Development Plan, identify any overlaps between those plans
and the PMP and determine the appropriate content for each.
Page 81
1 Program Plan
This section briefly describes the customer's business and some of the key events, activities, or
decisions that led up to this program. It serves as an introduction to the Program Management
Plan (PMP) and benefits those who are not familiar with the program. It may also contain
historical background on the program.
This section should also describe the relationship of the program planning documents (e.g.,
hierarchy of plans).
Lastly, this section should also describe the process for updating the PMP, including
authorizations, timing, revision control, etc.
1.1 Program Definition (PD)

Prepare a description of the program. The definition identifies and explains the objectives,
scope, and approach the program intends to achieve.
In the course of definition development, the program team will:
 explore the relationships between the formal and informal activities, events,
durations, costs, and constraints involved in executing the program,
 identify areas of vagueness or uncertainty and potential conflict,
 propose alternative solutions to obtain a satisfactory balance between
customer / stakeholder expectations and program cost and schedule
requirements,
 document the understanding of the work required to achieve the objective
and complete the program,
 Describe the depth and breadth of the work to be performed.
Note
The creation, review and approval activities of the Program Definition section of the PMP are detailed in Develop
Project Definition.
See also Example Project Definitions from past programs for guidance.
Note
If the activities related to Program Definition are begun as early as possible in the program lifecycle, i.e., prior to or
during the proposal process, then much of the information in the table below may not be available at that time.
The PM should update the table on an ongoing basis, as the information becomes available.
1.1.1 Contract / Program Details
The Contract / Program Details provide essential contract information.
1.1.2 Client Business Objectives

This section briefly describes the Client’s objectives (business objectives that are driving the
program), with expected outcomes at program completion.
Page 82
This section should describe:

 the Client’s vision for the program,
 defined and measurable quality goals, and
 Technical and schedule goals.
The appropriate objectives can be listed, or consider using the CSRA Project Scope and
Requirements tool to document the objectives via the objectives tab within the tool.
1.1.3 CSRA Program Objectives

This section briefly defines the program team’s objectives, with expected outcomes at program
completion.
It is important to distinguish between two sets of objectives:
 Customer Business Objectives (business objectives that are driving the
program), and
 Program Objectives (objectives related to the specific program).
This section should describe:

 the vision for the program, including CSRA’s internal objectives (development
and service management, as appropriate),
 defined and measurable quality goals,
 technical and schedule goals, and
 goals related to enhancement of CSRA’s technical capability and competitive
market position.
The appropriate objectives can be listed in a table, or consider using the CSRA Project Scope
and Requirements tool to document the objectives via the objectives tab within the tool.
1.1.4 In-Scope Functions

Scope definition can be thought of as the change we are bringing to the customer’s
environment. Through the execution of the program, document the changes we are
implementing to convert the state of the client’s “as is” environment to the desired “to be”
environment. In-Scope functions define “What” we will do in the program.
This section specifies “In Scope” critical functions the program should achieve, and the
quantifiable criteria that the program must meet to succeed.
It identifies which aspects of the business are to be included, such as:
 customers,
 products,
 processes,
 organizations,
 locations,
 applications,
 data, or
 Technology.
In addition, it determines what other external influences, impacts, and dependencies are to be
addressed, such as:
Page 83
 third-party vendors,
 customer needs, and
 regulatory requirements.
Parts of this section can be copied from the Request for Proposal (RFP) or contract
documentation.
Consider using the CSRA Project Scope and Requirements tool to document the boundaries via
the boundaries tab within the tool.
Note
This section is extremely important - it is one of the key areas to establish a baseline for the program that the
customer should find easy to understand, since it addresses aspects of their business.
1.1.5 Out of Scope Functions

This section describes what is “Out of Scope” i.e., those aspects and functions that are to be
excluded from the program as they are not contractually required. When there is concern and a
high probability that scope creep is a potential risk, this section can be used to identify specific
limits.
In some circumstances, it can be appropriate to simply state that whatever is not in scope
should be considered out of scope.
1.1.6 Deliverables
This section provides a list of the <Program> tangible items that will be presented to the
customer for acceptance. This list should include:
 a title for the deliverable
 a brief description of the deliverable (the description can contain several work
products that comprise the deliverable; do not describe the work products
here but list them instead)
 a notation of what group or party is responsible for the deliverable
 data and format description
 Acceptance criteria for the deliverable, including due dates.
Parts of this section can be copied from the contract documentation and the proposal.
Program-level deliverables should be included in Program Management Plans if applicable.
1.1.6.1 Deliverable Acceptance

All of the completed deliverables identified in the deliverables list will be formally submitted for
final review and customer approval in accordance with contract requirements.
Parts of this section can be copied from the contract documentation and the proposal.
For further information about Acceptance, see Program Acceptance Plan.
1.1.7 Management Approach
The approach definition describes “How” the team will perform the management and technical
work required to accomplish the scope, satisfy the technical requirements, and complete the
program. It defines the work by:
Page 84

laying out a broad picture of releases and phases,

identifying the specific activities that people on the team will perform, and

Describing the tangible work products and deliverables that result from these
activities.
The team should determine their top-level approach for:
 discovery,
 design,
 development,
 deployment processes,
 procedures,
 support systems,
 facilities,
 management, and
 Specific customer responsibilities for elements of the solution.
In addition, the team should determine requirements mandated by the customer or by legal
considerations that are included in the Contract. The team should get approval from
management for exceptions to business unit policies, procedures, and standards.
This section describes the top-level program management approach that will be employed on
the contract.
Note
Additional processes for managing the program are detailed in the Supplemental Plans
section (e.g., risk, issues management, communications, measurement plans, etc.).
Please see Section 2 - Supplemental Management Plans for insight into these processes.
The management approach identifies how the execution of the technical approach will be
monitored, controlled, and directed.
It describes the methods used on the program to communicate, coordinate and track program
activities and commitments on the program including:
 Developing a program Work Breakdown Structure (WBS) and associated
work packages including Earned Value methods, if required. (See Integrated
Program Management Process (IPMP) if an Earned Value approach is
selected).
 Defining development and service management processes and practices to
be used and interrelationship between the processes.
 Coordinating and tracking the work performed.
 Documenting critical dependencies.
 Determining when formal decision making will be applied (i.e., see Decision
Analysis and Resolution Process). See also, Example Decision Analysis and
Resolution Plans and Assets from previous programs.
 Capturing Lessons Learned (i.e., when lessons learned will be captured; how
they will be recorded; and who records and reviews them).
The result of the approach definition is a methodology and a summary of solution work
Page 85
products, both technical and managerial, to be produced; in some cases, parts of this section
can be copied from the proposal.
Note
The Management Approach should also point to the appropriate Process Assurance Cycle
(PAC) Checklists used to document process tailoring on the program.
1.1.8 Technical Approach

This section describes the technical approach that will be employed on the program. The
technical approach identifies how the required product, service, or result will be provided.
It includes the technical methodology and / or processes that will be employed, such as the:
 system development life cycle (e.g. IEEE development paths, (Refer to PC
5030.01 Product Engineering and Service Management Plan Template),
 architectural concept,
 implementation activities,
 releases,
 phases,
 sub-phases,
 major milestones, and
 acceptance points.
1.1.9 Initial Risks and Issues

This section contains the initial identification of program’s risks and issues and may refer to an
ongoing Risks / Issues / Opportunities Management (RIOM) Tool that is maintained and
evaluated throughout the course of the program. The program should evaluate the extent to
which it wants to implement Risk Management. This initial set of risks should be used for
evaluating the validity of the management and technical approaches.
If the initial list of risks is extensive, consideration should be given to creating a risk
management supplemental plan and implementing a tracking tool.
Risk/ Description Mitigation Plan Date Mitigation

Issue Required
Risk GFE might not be provided in Procure GFE and pass costs July 2017
time to begin development. back to the Government.
Issue To meet schedule, work has to Obtain Risk Authorization June 2016
begin prior to contract award Funding.
Note
Not all risks can be mitigated, and may have a potential impact on the program’s schedule, budget, and
/ or ability to deliver in-scope items.
Not all issues can be resolved and may have a potential impact on the program’s schedule, budget, and
/ or ability to deliver in-scope items.
Page 86
Parts of this section can be copied from the CSRA proposal.
1.1.10 Constraints
This section should reflect the items that limit the choice in design, approach, scheduling,
execution, etc.
Constraints could include dependencies on:
 other organizations to provide either work or deliverables by a certain time,
 other programs to provide information that this program is reliant on,
 work being performed by a certain date so that tasks can begin.
Include customer directives that have been accepted by the program team as constraints. Parts
of this section can be copied from the CSRA proposal.
Constraints can be listed in a table, or consider using the CSRA Project Scope and
Requirements tool to document the constraints via the constraints tab within the tool.
Constraints
Constraint Constraint Type Description of Constraint
ID
1 Example: Technical Limitation Example: Client requires the use of Open Source COTS software
2 Example: Geographic Example: Client requires that all personnel are physically located
Limitation within 30 miles of the Washington DC Metro area
1.1.11 Assumptions
This section identifies program assumptions. Assumptions are those expectations and decisions
upon which the program “path forward” is based and which, if proven incorrect, result in a
significant program issue that could invalidate the program budget estimates, schedules and
approach.
Assumptions must be based on a likely reality - do not assume away reality.
Parts of this section can be copied from the CSRA proposal.
Assumptions can be listed in a table, or consider using the CSRA Project Scope and
Requirements tool to document the assumptions via the assumptions tab within the tool.
Assumptions
Assumption Description of Assumption
ID
1 Example: Client requires the use of Open Source COTS software.
2 Example: Client requires that all personnel are physically located within 30 miles of the Washington
DC Metro area.
Page 87
1.1.12 General Equipment and Facility Needs

This section specifies the program-specific equipment and facility needs. These are the needs
for supporting the program’s activities (e.g., team working area, testing environment, system
and software engineering, and inter-facility communication).
The environment and resources section should describe the requirements for the work facility
(including secured facilities), computer equipment / tools, repositories, etc. for the program such
as:
 Information services hardware (e.g., desktop computers and network),
 Information services software (application software and operating systems),
 Program databases,
 Program repositories (refer to the See Project Environment and Data Control Guide,
for guidance),
 Program and service management tools (e.g., SharePoint, MS Program, Earned
Value tools),
 Capital equipment,
 Calibration equipment,
 Customer Supplied Equipment, Automated tools and support (e.g., requirements
management, configuration management, test),
 Security-related contractual limitations, requirements and responsibilities for
approval,
 Secure facility requirements, security clearance requirements and data / information
security requirements,
 Applicable CSRA Safety Requirements and standards (refer to Health and Safety
Program Manual for guidance.
1.2 Estimates
The estimates definition process should describe the estimation technique(s) used to derive
size, cost, effort and the schedule for the program (e.g., historical data, analogy, expert
judgment, parametric tool).
This section also includes discussion of measurements and estimates related to the budget (see
Section 1.4 Program Budget and Section 1.5 Measurements below as well as Develop Project
Estimate for details of estimating techniques).
1.3 Program Work Breakdown Structure (WBS) and Schedule

Prepare a program Work Breakdown Structure and master schedule to serve as the baseline.
Refer to the E2O Earned Value and Scheduling Group for assistance.
The Program schedule consists of a breakdown of Program activities detailing the work
required to successfully complete the Program, including all program contractual milestones and
deliverables, internal scheduled events, as well as summary tasks from the detailed schedules.
The program schedule will also identify the planned allocation of resources and budgets to
perform each activity across the program continuum, with various dependencies linked to
scheduled events.
Page 88
Note
The implementation of Earned Value Management (EVM) and various development

approaches (Waterfall, Agile, SAFe, and Hybrid) will impose a varying level of detail and
complexity on the program schedule.
EVM will focus on managing the scope, costs and schedule to remain as close to the forecast
as possible, with a decreasing tolerance to accept change without invoking a formal change
process.
Agile and related development approaches are more focused on prioritizing work based on
maximizing business value of the product and decreasing risk to the customer. Agile also
attempts to accommodate the inevitable changes through each iteration and in most cases,
uses negotiation to foster change without having to invoke a formal change process.
The creation of the program schedule is detailed in Develop Project Schedule.

For Agile programs, refer also to Agile Supplement to PPMF.
For programs with an EVM requirement, refer to the Integrated Program Management Process
(IPMP).
1.4 Program Budget

The budget is the total amount of authorized financial resources, reflected in the bid model, that
are allocated for expenditure in support of specific activities of the program at specified
intervals. The program budget serves as the primary financial document for executing the
program activities and producing the deliverables.
The Budget should specify the financial management methods for the program. It should state
how and by whom the program cost and financial performance will be monitored and controlled.
Where reporting is required by the contract, it should specify the cost reporting requirements,
responsibilities, reviews and submission requirements.
Include sample formats / templates for each financial report and the schedule for each
submission.
Note
A time-phased budget baseline serves as the basis for measuring and managing cost
performance on the program. It is developed by totaling the budgeted costs by period and by
top-level Work Breakdown Structure (WBS) component. It shows the total budget for the
program and the distribution of the budget to the components identified in the top-level WBS.
The program budget is created during Estimation (see Develop Project Estimate) and monitored
and managed by the Manage Project Financials procedure.
1.5 Performance Measurements
This section describes the performance measurement processes and techniques to be
employed on the program to monitor performance.
Page 89
 Identify the responsibility for the overall measurement program, the support
infrastructure (measurement repository and tools), and the measurement training
requirements.
 Describe how schedule, budget, completeness, and quality of products and services
are to be measured, monitored, reported, and controlled. (Refer to the IPMP for
programs required to use EVM).
 Specify the program, product, service, and process measurements to be collected,
analyzed and reported. (Refer to Develop Measurement Approach procedure for
guidance on measurement activities).
 Document the measurement objectives and definitions and the procedures for data
collection, storage, and analysis.
 Identify the responsibilities for measurement and the stakeholders.
 Document the measurement reporting venues and the frequencies for measurement
cycles.
 Document the activities that ensure program release data will be prepared and
submitted to the Delivery Assurance Organization (Program Release Data Collection
and Submission Procedure).
Supplemental Management Plans

Supplemental plans may be included in the PMP or written as separate documents and referred
to in the PMP, depending on the size of the plan.
Please be sure to report positively for each section, whether or not a section is applicable to the
program. Provide an indication to the location of external plans, as necessary.
2 Governance Plan
This section describes how the Program is to be governed (Refer to CSRA policy PO 9001
Program Management for CSRA Program governance requirements).
The intent of the Governance Plan is to establish mutually agreed upon communication and
escalation paths with the client so that issues may be resolved as quickly as possible.
The Governance Plan should include:
 the Organization Charts that document the personnel on the program,
 descriptions of the Roles, Responsibilities and Stakeholders,
 a definition of the Face-Off Diagram / Strategy between the customer and CSRA,
 a definition of the Issues Escalation process.
For Agile programs, refer also to Agile Scrum Product Development Guide.
2.1 Organization Charts

Provide a program organization chart and a client organizational chart.
2.2 Roles, Responsibilities and Stakeholders

This section focuses on stakeholder roles and associated responsibilities on the program.
Describe:
 CSRA program team roles including:
o Oversight roles above the PM
Page 90
o Management and lead roles below the PM

 Customer roles, such as:
o customer user or technical roles
o customer contractor/vendor roles
o customer direction/management roles
 CSRA subcontractor / vendor roles;
 Groups not under the control of the program but that have an impact on the
program’s ability to deliver the program successfully (e.g., associate contractors).
 CSRA organizations outside the program with whom the program must interface.
This information may be summarized per the Stakeholder Identification Matrix provided as an
example below.
Identify the key program stakeholders including their responsibilities and the key information
each needs to perform their job.
Stakeholders can be listed in a table, or consider using the CSRA Project Scope and
Requirements tool to document the stakeholders via the stakeholders tab within the tool.
Also refer to the RACI Chart work aid and see example Responsibility Assignment Matrices
from previous programs.
Tip
Be sure to:
 identify roles rather than names in this section
 clearly define the responsibilities assigned to each role
 describe product or specialized teams expected on the program, if any
 identify coverage for key roles when an absence occurs
2.3 Face-Off Diagram

Describe the Face-Off Strategy between CSRA and the customer.
Provide a diagram showing the customer face-off strategy to identify which roles on the program
team communicate with which roles on the customer team.
Address face-offs between the client senior leadership and CSRA Executive Management
levels where they exist.
If the program have subcontractors, include a face-off diagram for the subcontractor and CSRA.
2.4 Staffing Matrix and Profile
Staffing Matrices and Profiles are useful tools in tracking staff needs.
The Staffing Matrix is derived from the information within the estimate and program schedule;
the Staffing Profile may be used as input to an appropriate resource management tool.
The staffing matrix / profile shows the number and types of personnel needed for the program,
decomposed by role and by time period. It describes program staffing levels by functional area,
life-cycle phase, and staffing source.
See Staffing Plans and Profiles from previous programs for staffing profile content examples.
Page 91
2.5 Issues Escalation

This section contains the program’s issues escalation process.
Not all issues can be resolved by the program. Issues that have a potential impact on the
program’s schedule, budget, and / or ability to deliver in-scope items may be candidates for
escalation to CSRA Executive Management.
Describe the process for how, and to whom, issues that require escalation above the program
level are processed.
2.6 Program Communications

The communications management section describes how the program’s needs for giving and
receiving information can be met.
It describes how information should flow within, to, and from the program and should identify the
stakeholders and what they need to know, including program-specific customer-required
communication requirements.
Communications Management should also describe the meetings and other vehicles used for
program communication.
It should include:
 types of communication,
 purpose,
 general content,
 audience,
 rules for access / distribution, and
 Frequency of updates.
Tip
When creating the Communications Management Plan, consider factors such as:
 Environment (open door policy, freedom to participate and speak mind, normal and
exceptional lines of communication, free and open flow of information),
 The types of information stakeholders need (progress, risks, issues, etc.),
 Methods (e-mail, meetings, teleconference),
 Program newsletters,
 Bulletin boards (electronic or wall-mounted),
 Program web-sites,
 Tools (SharePoint, telephone),
 Communication Products (Agendas, Minutes, Issues, Actions and Decision capture,
Correspondence),
 Ensuring that the work proceeds smoothly, that all participants meet expectations,
transitions are efficient and resources come together at the right time and place,
 The creation and maintenance of a Program Calendar (a key program tool) which
Page 92
shows all program communication events (e.g., regular meetings, reviews, reports,
etc.). The program calendar should be maintained and stored in an application that the
entire program team can access.
As part of the PMP, the Communication Management Plan should also:
 describe how to keep stakeholders informed during the program,
 discuss how to communicate with related programs.
The PM uses the program's Organizational Chart, Stakeholder matrix, and Client Face-off
diagram (contained in the Governance Plan) to produce the Communications Plan.
In addition, the contract may contain program-specific customer-required communications
requirements that the plan should accommodate.
The plan should:
 Identify communications mechanisms between the CSRA and stakeholders.
 Describe how information is exchanged both formally and informally with the
client, including any guidelines concerning this communication.
 Identify all meetings, including their purpose, attendees, meeting documentation
and schedule.
 Specify the reporting requirements listed in the contract (e.g., management
reviews, progress reports).
 Describe the external document reporting frequency.
 Provide similar information for independent subcontracting or vendor
organizations as appropriate.
 Describe how meetings will be used to exchange information with clients.
 Identify all scheduled external meetings, formal reviews, informal reviews, and
other communications mechanisms.
Program Management Reviews:

Describe the process that will be followed for review of the program by Executive Management,
including, the materials, content, participants and frequency of these reviews.
Indicate any standard presentation or reporting templates that may be required. Refer to CSRA
Program Management Review procedure and template for more information.
Specify the various written reports that will be produced by the program, such as:
 contractual deliverables
 general correspondence.
Describe at the appropriate level of detail, the:
 content and format of each type of report,
 who is responsible for producing, approving, and reviewing each report,
 the production frequency or schedule for the report, and distribution.
The Communication Management Plan should align with CSRA procedure Report Project
Status.
Refer also to the Communications Plan template.
See the Communications / Stakeholder Plans from prior programs for content examples.
For Agile programs, refer also to Agile Scrum Product Engineering Guide.
Page 93
3 Security Plan
The goal of the System Security Plan (SSP) is to document the security controls of the system
and its operating environment. The security plan also describes the system environment,
personnel responsibilities and the expected behavior of those accessing the system – both data
and back-end (i.e. administrative) functions. The SSP is a key component of the system’s
Information Assurance and Assessment and Authorization (A&A) process.
All Executive branch departments and agencies are required to use National Institute of
Standards and Technology (NIST) Special Publication (SP) 800-18, “Guide for Developing
Security Plans for Federal Information Systems” to develop their SSP. NIST SP 800-18
provides detailed guidance on developing an SSP and includes an SSP template. CSRA has
also posted useful SSP templates on FUSE, which can be found at the link below. It is
important to note that some federal agencies have tailored their SSP and it is recommended to
confirm the template used with the customer before completing the SSP.
The Application Security Controls and their associated status should be included. The security
controls section of the SSP will constitute a large portion of the document. This section identifies
the system’s applicable security controls - including those in the 18 control categories from NIST
SP 800-53, “Security and Privacy Controls for Federal Information Systems and Organizations”
as well as any controls specifically tailored or required by the customer. Before this section can
be completed, the security controls applicable to the system must be identified and agreed to by
the customer.
The security controls section of the SSP will constitute a large portion of the document. This
section identifies the system’s applicable security controls - including those in the 18 control
categories from NIST SP 800-53, “Security and Privacy Controls for Federal Information
Systems and Organizations” as well as any controls specifically tailored or required by the
customer. Before this section can be completed, the security controls applicable to the system
must be identified and agreed to by the customer.
o AC - Access Control
o AU - Audit and Accountability
o AT - Awareness and Training
o CM - Configuration Management
o CP - Contingency Planning
o IA - Identification and Authentication
o IR - Incident Response
o MA - Maintenance
o MP - Media Protection
o PS - Personnel Security
o PE - Physical and Environmental Protection
o PL - Planning
o PM - Program Management
o RA - Risk Assessment
o CA - Security Assessment and Authorization
o SC - System and Communications Protection
o SI - System and Information Integrity
o SA - System and Services Acquisition
Describe the IT requirements for the program (Refer to the contract and CSRA IT Standards)
Page 94
See example Security Management Plans from prior programs for content examples.
4 Continuity Management Plan

The purpose of Continuity Management is to ensure the program’s ability to protect personnel
and facilities during a time of disaster and to carry on critical functions that are absolutely
necessary for the program to ensure delivery of essential services to clients.
Critical functions have extremely strict prescriptions for the time frame when such functions
must be restored, and typically carry extensive requirements for data and applications support
enabled by automated systems.
Over time, Continuity also requires the program to resume the remainder of other important
Business functions in a gradual manner consistent with the availability of personnel, facilities,
and systems to reactivate and support these remaining Business processes.
The program’s Continuity Program defines the highest level responsibilities and courses of
action to be followed in order to avoid or diminish the adverse effects of major emergencies
upon the company. Adverse effects to be avoided include, first and foremost, harm to
personnel. Other adverse effects include significant harm to a firm's tangible assets.
4.1 Continuity Management Responsibility Assignments

Identify a program Crisis Management Coordinator who will manage the implementation of the
Continuity Plan.
Identify CSRA Account / Program management who will be the decision-makers when crisis
occurs.
4.2 Continuity Management Staffing Requirements

Identify staff critical to maintaining on-site continuity and those that can work from home or are
on call.
4.3 Notification Tree

Create a Notification Tree for key staff that is used in case of an emergency when someone
can’t be contacted in a timely manner.
4.4 Prioritized Continuity Processes

Identify and prioritize the key Processes that must be maintained in time of crisis. Identify the
required recovery and resume times for each of the processes should they fail.
4.5 Process Details for <Program’s> Areas of Responsibility

Provide a detailed description of each of the key processes that must be maintained, who owns
the process, and what dependencies there might be for the process.
Page 95
4.6 IT Tools, Applications, Input / Output Data, and Special Instructions

List the tools / applications, process data input requirements, process output data/products
information, and recovery time for each
4.7 Required Vital Records
List the vital records that need to be preserved in case of a disaster.
5 Technology Control Plan

The technology control plan describes the program controls that CSRA employees,
subcontractors, and visitors must follow, if:
 the data used by the program falls under U.S. Munitions List (USML) governed
by the International Traffic in Arms Regulations [ITAR], or
 exports are expected for products covered under the Commerce Control List
(CCL) under the Export Administration Regulations.
See the PO 0105A CSRA Export Control Manual and Technology Control Plans from prior
programs for content examples.
Technology Control Plan Tip
The Program Manager must work with the Contract Administrator, with support from CSRA's Legal
department, to understand CSRA's Technology Control requirements and determine if any portions
need tailoring for the program.
6 External Supplier / Subcontractor Management Plan

The external supplier / subcontractor management plan describes how external suppliers,
vendors and subcontractors will be managed by the program. The plan identifies external
suppliers and their responsibilities and describes their relationships to CSRA and the customer.
The plan includes the same elements as the program contractual baseline, modified or scaled
down appropriately to fit the nature and scope of the external suppliers’ / subcontractors roles in
the program.
The plan should:

 Identify the acquisition types to be implemented on the program (e.g., subcontractors,
COTS procurements, Customer furnished equipment (CFE)).
 Identify all major equipment, software, and services that must be acquired by CSRA and
the acquisition type for each, or reference the program Bill of Materials (BOM).
 Describe the process for receipt, acceptance and transition of COTS products into the
program. (Refer to CSRA Property Management and Control Manual).
 Describe the method for obtaining and controlling CFE product, (refer to PO 4000
Attachment A, CSRA Property Management and Control Manual).
 Identify all long lead procurement items and planned dates for procurement.
Page 96
For each supplier with subcontracted custom development or integration efforts, if not contained
in the supplier agreement, describe:
 Subcontract coordination and reviews,
 Formal reviews (e.g. design reviews, Technical Exchange Meetings (TEMs)),
 Informal reviews (e.g. status meetings),
 Critical processes requiring CSRA monitoring and oversight,
 Critical products requiring CSRA evaluation,
 Acceptance testing of the supplier products,
 Evaluation methods of supplier performance.
For more details on supplier management, refer to Manage Suppliers / Subcontractors and
Supplier Management Plan template and the CSRA Subcontracts and Procurement Acquisition
Manual.
The plan includes the same elements as the program contractual baseline, modified or scaled
down appropriately to fit the nature and scope of the external suppliers’ roles in the program.
See also Supplier Agreement Management Plans from prior programs for content examples.
External Supplier Plan Tip
An External Supplier Management Plan is only required if the program involves external
suppliers, i.e., vendors and or subcontractors), whose activities need to be managed as part of
the program.
If the program does not involve external suppliers, indicate as such in the program’s tailoring
documentation and omit this plan.
7 Program Training Plan

Training is required when there are major gaps between the skills and knowledge of the
program team and the chosen technical or management approaches unique to the program.
The training plan guides team development so that the team has the skills necessary for their
program roles. The plan states why training is needed, what training is needed, and when
training should be carried out.
The PM should initiate a Program Training Plan, identifying the skills required as well as the
appropriate sources for training, as soon as possible; however it is recognized that the PM may
not be able to complete the training plan until all the Program resources have been identified.
Refer to the Training Plan Template and the CSRA Project Training Guide and the Learning
Operations Training Plan.
See also Training Plan examples from prior Programs for content examples.
Training Plan Contents
The plan consists of:

 Skills Assessment - Comparison of each team member’s competence with the major
competencies required to succeed in the assigned roles and assessment of the number
Page 97
Training Plan Contents

of staff who need to develop each competency.
 Interventions - Defined training interventions to address skills shortfalls.
 Budget - Define the training budget.
 Schedule - Define the training schedule and identify potential participants.
 Roles and Responsibilities - Specify roles and responsibilities for executing the Training
Plan.
 Related Policies, Processes, Standards, Procedures, Templates, and Tools - Specify
policies, processes, standards, procedures, templates, and tools related to executing
the Training Plan.
 Assessment Processes and Measures - Specify processes and measures to assess
the effectiveness of interventions and the plan.
Training Plan Tip
If the Program requires a training plan, i.e., the Customer is paying for the training or you wish
the Customer to have visibility of the training, indicate as such in the Program’s tailoring
documentation and develop the plan.
Ensure that training activities are reflected in the Program estimate (see PR 9001.04 Develop Program
Estimate) and program schedule (see PR 9001.05 Develop Program Schedule).
Note that Customer end-user training is not part of this training plan.
Note
It is highly recommended that the Decision Analysis and Resolution (DAR) activity be applied
for determining the skills required, training needed, and the sources of training.
Application of the DAR activity ensures usage of a formal evaluation activity of the identified
alternatives against established criteria.
The DAR activity can be applied for medium and large application programs, and for programs
with a high degree of risk.
More information on the DAR process is available in Decision Analysis and Resolution.
8 Risk, Issues and Opportunity Management Plan

8.1 Risk Management
The risk management section describes how the program will identify and manage program
risks. In addition, it summarizes the process to be followed to identify and manage program
risks, including technical, schedule and cost risks. It should also identify the management tool
used to record and track risks.
See Manage Risks for guidance on the risk management.
Refer also to the Risk Management Plan template.
Page 98
See also Risk Management Plans from prior programs for content examples.
For programs with an EVM requirement, also refer to the IPMP for risk management
requirements.
8.2 Issues Management

The issues management section describes the approach for identifying, responding to, tracking,
and resolving program issues or Customer issues / complaints (e.g., periodic program reviews,
PMRs). It should It also establishes the rules and responsibilities for issue resolution.
See Manage Issues for guidance on establishing the rules and responsibilities for identifying,
escalating, and resolving issues related to the program.
See also Issues Management Plans from prior programs for content examples.
8.3 Opportunities Management

The opportunities management section describes how the program will identify and manage
program opportunities. In addition, it summarizes the process to be followed to identify and
manage program opportunities, including technical, schedule and cost opportunities. It should
also identify the management tool used to record and track opportunities.
See Manage Opportunities for guidance on opportunities management.
9 Contract Change Management Plan

The contract change management plan describes how the program manages contractual
changes (e.g. Contract Modifications, changes in Scope).
Change Management Plan Tips

The program’s approach to change should be in line with Manage Project Change; if the program
is following this procedure, a separate Change Management Plan is not required.
If a separate change management plan becomes necessary, see Change Management Plans
from prior programs for content examples.
9.1 Client-Initiated Changes

The requirements management plan describes how requirements will be managed and
controlled on the program. See Requirements Management Plan Work Instruction.
The Requirements Summary should summarize the technical and service requirements of the
contract. It should:
 specify the contract deliverable line items and acceptance criteria,
 include references to the program’s Engineering Management Development or
Service Management Plan if applicable,
 describe how technical requirements will be satisfied,
 include policy, standards, statutory, and regulatory requirements, as appropriate
and as specified in the contract.
Page 99
The initial set of requirements is considered the requirement baseline and is included as an
appendix of the PMP. This appendix lists all of the requirements and characteristics of
requirements that affect the outcome of the product or service. Those requirements that are to
be fulfilled by subcontractors are also identified.
The requirements list should be managed separate from the PMP, as it evolves throughout the
program life and changes to the list are tracked and managed.
The Requirements List portion of the CSRA Project Scope and Requirements List tool can be
used to identify all contractual requirements to satisfy the terms of the program and the
characteristics of the requirements. Contract requirements are traced to the program objectives,
deliverables, and Work Breakdown Structure (WBS).
See Requirements Management Plans from prior programs for content examples.
9.2 CSRA-Initiated Changes
Steps for managing proposed CSRA-initiated requirement changes are:
 Change Requests - Requirement change requests raised internally by
Program Management should be reviewed and approved by program CCB
before accepting.
 Program Management socializes the Change Request with the Client.
 Program Management coordinates with the Contracts Administrator by
formally submitting the Change Request to the client for approval. Refer to
the CSRA Manage Project Change Procedure.
10 Asset, Configuration and Data Management Plan

The Asset, Configuration and Data Management Plan is intended to describe how program
assets are managed.
Assets enter the program from various sources and need to be identified and tracked in an
Asset Repository. Complex and critical assets may be designated “Configuration Items” and
managed through the project Configuration/Change Control Board. Less complex and bulk
assets (e.g., keyboards, mice) are managed as assets only and are simply tracked in the project
Asset Repository.
Documentation assets need to be managed as well using the Quality Records List (QRL) and
Master Document List (MDL). The QRL lists “one-time” assets that do not require change
control (e.g., Incident Reports). The MDL lists documents that do require change control (e.g.,
plans).
 The Configuration/Change Management Plan defines how software, hardware
and documentation items will be stored, how their integrity will be established,
maintained and verified, and what information will be provided for monitoring
configuration management activity.
 The Data Management Plan describes how deliverable and non-deliverable data
on the program will be managed, and documents the Quality Records List (QRL)
and the Master Document List (MDL) for the program.
Page 100
10.1 Asset Management

If the organization has to manage the vendor asset it may be recorded as a CI and populated in
the Asset Repository. If the asset is not managed but there is a relationship between this asset
and a managed CI that relationship is documented. If there is a change to the is a
relationship between the vendor assets and one they are managing will impact services it
may benefit both parties to place under change control since they are working together to
deliver the service. The CI that s a vendor asset will be noted as such in the Asset Repository.
The Asset Management Plan describes the governance of assets from the point of acquisition to
the point of disposal, including the receiving, inspection and acceptance of assets.
For additional guidance on Asset Management, reference the CSRA Property Control Manual.>
10.2 Configuration and Change Management (CM)

The CM requirements are based on the number and type of product components and their
complexity. These requirements are determined by analyzing the program’s contractual
documentation, including:
 contract,
 SOW,
 proposal,
 Contract Data Requirements List (CDRL), and
 Specified standards.
The CM requirements determine the scope of the configuration management task. By
determining the scope, the PM identifies the issues the Configuration Management Plan (CMP)
will and will not address, the items to be managed, and the deliverable Configuration Items (Cis)
to be released.
The CMP addresses hardware and software configuration items, support software, development
tools, CM tools, build requirements, implementation methods, maintenance requirements and
service requirements.
The configuration management section should describe the methodology and overall approach
to configuration management with respect to:
Configuration Identification – Software Items, Hardware Items and Documentation selected
for CM control, including sub-contractor and vendor software that establishes program
baselines.
Assets that are deemed to be CIs are listed in the Configuration Management Plan. Items listed
as CIs in the CM Plan are added to the Asset Repository. CIs listed in the Asset Repository are
under change control. The status of the CI is updated from point of acquisition to decommission
or end of life.
If CIs are vendor assets they may be recorded as a CI and populated in the Asset Repository If
the asset is not managed but there is a relationship between this asset and a managed CI, that
relationship is documented. If there is a change to a relationship between the a vendor asset
and one CSRA is managing that will impact services it may benefit both parties to identify the
asset as a CI and place the asset under change control since they are working together to
deliver a service. The CI that is a vendor asset will be noted as such in the Asset Repository.
Configuration management practices must also be followed for Program Management work-
products (e.g., documentation), not just program deliverables.
Page 101
For further guidance, refer to the CM Plan template.

See also Configuration Management Plans from prior programs for content examples.
Configuration Control:
 Evaluation, coordination, and implementation of all changes to program
hardware, software and documentation to include function and responsibility of
configuration control process including Configuration Control Boards (CCBs), and
classification and processing of engineering change proposals.
 Description of automated CM tools and developmental and formal library controls
including check-in / checkout procedures.
 Description of the release process for documentation, data, software and
hardware.
Configuration Status Accounting:
 Method for collecting, recording, processing, and maintaining data for status
accounting information using report and / or database access.
Configuration Reviews and Audits:
 Support of Program/Engineering Reviews and baseline CM audits, as well as
QMS audits.
Configuration Management Plan Contents
The CM Plan includes:

 The criteria for elements to be configuration-managed, the resulting selection of
configuration items (major system components) including their constituent
components and configuration units, and their associated documentation
(specifications, and so forth).
 How programs will store configurations, including naming conventions and data
management (repository design, creation, loading, updating, backup, and
recovery).
 How programs will construct builds and releases.
 The contents, timing, and interrelationships of program baselines.
 How programs will manage changes to configuration elements (proposing,
approving or rejecting, incorporating, and tracking).
 What kinds of data will be collected, what metrics will be derived, and what
reports will be used to provide visibility to configuration status and to
configuration-related activities and trends.
 What tools will be reused, acquired, modified, or developed to support
configuration management.
 The timing and scope of audits and other activities to monitor and assure
configuration integrity.
 CM role descriptions, including responsibilities, skill and training requirements,
authorities, and reporting hierarchies.
 CM staffing.
 References to standards and procedures being used by programs in support of
configuration management activities.
Page 102
10.3 Data Management

The data management section should describe the plan for management of program data to
include various forms of documentation required to support a program in all of its areas (e.g.,
administration, engineering, configuration, financial, logistics, quality, safety, manufacturing,
service management, and procurement). The plan should identify a Document Control Official
(DCO) who is responsible for maintaining control of documents subject to Policy 0202 Records
and Information Management and for monitoring the program’s adherence to the PO 0212A
Records Retention Schedule.
This includes all deliverable and non-deliverable data. Establish a plan for the definition,
collection, and analysis of program data. (See Project Environment and Data Control Guide,
which provides additional guidance for program repository planning).
Include descriptions for:

 Data Requirements,
 Privacy requirements,
 Security requirements and procedures for data,
 Identification of program contributions to organizational process repositories
(e.g., lessons learned, program history, measurement data).
Data Management Identification and Tools

Describe the method for how plans will be kept in sync when changes occur. Refer to CM
Secure Library Procedure for additional guidance. The table below depicts the information
required for a Master Document List (MDL). Current versions of a document are depicted on
the MDL. Once they are revised, the previous versions are archived for historical purposes and
become part of the Quality Records List (QRL) and the requirements for the QRL are listed
below. For an Excel version of the MDL / QRL, reference the MDL / QRL Excel template.
The QRL is to include format and location that will be maintained by the program in accordance
with CSRA Records Retention Policy and Records Retention Schedule procedure.
The MDL identifies by category all data items that are important enough to be retained over the
life of the program and archived according to Program Completion activities in the Program
Closeout process.
Data items are the documentation and artifacts that support a program in all areas, including:
 program management,
 engineering,
 configuration management,
 financial,
 quality,
 logistics, and
 procurement
See Data Management Plans from prior programs for content examples.>
Data Management Plan Tips
If the MDL does not address privacy requirements or data storage and retrieval mechanisms, they should be
addressed in the program PMP, if appropriate for the program.
Page 103
11 Measurement Plan
<The performance measurement plan helps the program team plan how they will collect and
store measurement data and produce indicators for analysis and reporting program
performance.
It also helps program managers define and initialize the measures and indicators that the
Program Management Team will use to control the program.
The plan describes how schedule, budget, completeness, and quality of products and services
are to be measured, monitored, reported, and controlled, and who has which responsibilities.
Refer also to Section 1.5, Measurements.
The development, review and approval of the metrics applicable to the program are detailed in
Develop Measurement Approach and CSRA Performance Measurement Guide
See Measurement and Analysis Plan from prior programs for content examples.
For programs with EVM requirements, see also the IPMP.
For Agile programs, refer to Agile Supplement to PPMF and Agile Scrum Product Development
Guide .
Performance Measurement Plan Tips
For programs that will be quantitatively managed, a separate Quantitative Performance Measurement Plan is
required to document how the program’s performance will be measured (see Perform Quantitative Program
Management).
12 Continuous Improvement
<Continuous Improvement provides the mechanism to identify and implement improvement to
program processes. All programs should have a continuous improvement program. Refer to
CSRA Policy PO 9005, Continuous Improvement.
For IT Services Programs, this process is commonly known as Continual Service Improvement
(CSI). Refer to the CSRA Continuous Service Improvement (CSI) procedure.
13 Program Quality Plan

<The quality plan describes the goals, objectives, constituent elements, staffing, and operation
of a quality system for the program.
There are 2 components to a quality system, each of which may have its own plan or may be
described as part of the Program Quality Plan:
1) Quality Assurance (QA) – QA ensures a program is performing their activities in
accordance with their defined, repeatable processes (“Doing things right”).
2) Quality Control (QC) – QC ensures that the program’s products are correct (“Doing
the right thing”). The extent of QC activities vary, based on contract requirements
from the customer, and may range from basic verification activities such as peer
reviews or testing to full statistical quality control. Programs create a formal QC Plan
only when required by a contract.
Page 104
Review and document the program-specific quality requirements, such as non-conforming

material, packing and shipping requirements, problem reporting, and Process Assurance Cycle
(PAC) Forms.
Describe the following:
 Roles and Responsibilities of personnel ensuring program quality.
 Quality Resources: Staff and tools required to perform the quality functions.
 Organizational structure: Describe how organizational structure is conducive to
independent reporting by Quality personnel.
 Processes to be audited (e.g., program-specific processes, CMMI / ISO-9001,
ITIL / ISO 20K, processes), person(s) responsible, frequency of evaluations,
evaluation criteria, and method for tracking, reporting, closing and escalating
process-related non-compliances.
 Specific products to be audited, person(s) responsible, frequency of evaluations,
evaluation criteria (refer to specific checklists, tools, etc. for each product),
method for tracking, reporting, closing and escalating product-related non-
compliances.
 Product evaluations should include in-progress or incremental evaluations of
work products and services.
 Pointer to a schedule describing timing of Quality activities. Also, description of
procedure for updating schedule and frequency of updates to schedule.
 QA-related Measurements (or pointer to Measurement Plan): Auditing
measurements, defect-related measurements, etc., associated responsibilities
and method for analyzing and trending measurements data.
 Method for reporting status of Quality activities and non-compliances to
Executive Management, both program line management and Delivery Assurance
(Program Reviews, QA Monthly Reports, etc.). Method for ensuring the
resolution of noncompliance issues with the staff and managers.
 Describe tools used for tracking status.
 Methods for interfacing with, and reporting to, customer QA personnel, if
required.
 Specific descriptions of Quality records: Types of reports, checklists to be used,
audit templates, etc., and the configuration management of these records. If
described elsewhere in planning documentation, provide a pointer.
 Stakeholders of the Quality process, including all program personnel and
customer as appropriate. This topic may be addressed in a Communications
Plan; if so, provide a pointer.
 Typical activities to be addressed include:
o Establishing criteria for the objective evaluations of process and work
products,
o Evaluating processes and work products,
o Resolving noncompliance issues,
o Tracking noncompliance issues to closure. (Refer also to Manage
Corrective Actions).
 Descriptions of training provided to Quality personnel including minimum
requirements for their training, and how program personnel are oriented to the
role of QA.
 Descriptions of how Quality contributes to program and organizational process
improvement efforts: Analysis of QA lessons learned, contribution of
measurements to measurement tool repository, contribution of plans, audits to
the CSRA Process and Knowledge Center (PKC), etc.
Page 105
 Describe the program’s Peer Review Process. See Peer Review Procedure for
guidance.
The creation of the Program Quality Plan is detailed in Manage Project Quality.
Refer also to the Program Quality Plan template and Quality Guide.
See the Program Quality Plans from prior programs for content examples.>
14 Program Verification Plan

<The program verification plan specifies the work products to be verified and the methods for
verification (e.g. peer review, testing, etc.).
Describe the program’s peer review process if not provided in Section 13, Quality Assurance.
See Peer Review Procedure for guidance.
15 Program Validation / Acceptance Plan
<The acceptance plan defines the requirements for program acceptance, including criteria for
deliverable acceptance, acceptance criteria, and the necessary procedures for program
completion.
Refer also to Section 1.1.3.1 Deliverable Acceptance.
Program Acceptance Plan Tips
The Program Acceptance Plan includes:

 Program Completion Criteria that include items that must be satisfied before a program
is considered complete.
 Acceptance Criteria that define the agreed-on rules for determining whether the
program’s deliverables have been successfully completed. Good acceptance criteria
minimize subjectivity in deciding whether the work has been done and provide a
starting point for test planning.
 Technical performance measures that deliverables must meet.
 Acceptance rules and responsibilities for approving program deliverables.
The creation of the Program Acceptance Plan is detailed in Manage Acceptance.

Refer also to Acceptance Plan template.
For Agile programs, refer also to Agile Scrum Product Development Guide.>
Page 106
16 Decision Analysis and Resolution

The Decision Analysis and Resolution (DAR) process is designed to help the program make
decisions objectively and wisely. It can be used to resolve many complex business and
technical decisions. While the primary application of the DAR procedure is for technical
decisions, it will also be applied to many non-technical issues.
The DAR process is conducted by the program whenever it is determined that a decision falls
within the program guidelines that define which decisions should be subjected to an objective,
structured evaluation requiring analysis across alternatives.
The PM must first document decision guidelines that require the use of the DAR Process. Once
a DAR is determined to be required, the program should follow the DAR Process Steps as
outlined in the CSRA DAR process, PC 9001.02 Decision Analysis and Resolution Process
The DAR process consists of 8 steps, describing the DAR activities to be followed when the
program completes a DAR:
 Define the Issue to be Resolved

 Assign a Lead and Plan the DAR Effort
 Establish Evaluation Criteria
 Identify Alternative Solutions
 Select Methods for Evaluating Alternatives
 Evaluate Alternatives
 Select Solution
 Capture Results and Archive.
Additional information for DAR may be found in the DAR Work Instruction and DAR Training.
See also, Example Decision Analysis and Resolution Plans and Assets from previous programs.
17 Program Completion Plan

<The completion plan specifies the program completion activities that should be undertaken
throughout the life of the program. It identifies the conditions that the customer must
acknowledge that CSRA has completed the program. (Parts of this section can be copied from
the contract documentation and CSRA proposal).
The completion plan describes the completion activities to be followed when the program or a
program completes. It should consider:
 asset disposal,
 facility transition,
 knowledge management (what happens to intellectual capital),
 staff and support service transitions,
 contract and subcontracts wrap-up,
 final payments,
 support of the client relationship,
 record archival,
Page 107
 capturing lessons learned and metrics, and

 the completion celebration.
It should identify the supporting roles from the CSRA support organizations that will assist in
completing these activities.
Program Managers ensure that proper controls are established for tracking items that will be
required at contract closeout, including:
 government furnished property / equipment,
 patents / trademarks,
 security documentation (including clearances, document handling, and facilities), and
 labor categorization documentation, where applicable.
Tracking includes subcontractor items that meet the above criteria.
The completion plan specifies the program completion activities that should be undertaken
throughout the life of the program.
The program will follow the Perform Project Completion Procedure for execution.
Page 108
Tools and Templates

The following is a list of tools and templates for this template.
Template/Tool Name Link (if applicable)

TE 5030.01 Service Management Plan Template Service Management Plan Template
TE 9001.01.07.02 Communication Management Communication Management Plan
Plan Template
TE 9001.01.07.03 Training Plan Template Training Plan Template
TE 9001.01.07.04 Requirements Management Requirements Management Plan Template
Plan Template
TE 9001.01.07.05 Configuration Management Configuration Management Plan Template
Plan Template
TE 900101.07.06 Stakeholder Model Template Stakeholder Model Template
TE 9001.01.07.07 RACI Chart RACI Chart
TE 9001.01.07.09 MDL / QRL Excel MDL / QRL Excel
TE 9001.01.14.01 Risk Management Plan Risk Management Plan Template
Template
TE 9001.01.18.01 Supplier Management Plan Supplier Management Plan Template
TE 9001.01.19.01 Program Quality Plan Program Quality Plan template
template
TE 9001.01.22.01 Acceptance Plan Template Acceptance Plan Template
TM 9001.02.05 DAR Training DAR Training
Program Management Review Template Program Management Review Template
TO 9001.01.02.01 CSRA Program Scope and CSRA Program Scope and Requirements List
Requirements List
CSRA RIOM Tool Requires a Risk Account. Email
rskmAdmin@csra.com to obtain an account
FO 9001.01.03.01Process Assurance Cycle PAC PAC Part A
A
FO 9001.01.03.02Process Assurance Cycle PAC PAC Part B
B
FO 9001.01.03.03Process Assurance Cycle PAC PAC Part C
C
Page 109
Reference Table
Procedure Reference Type
PO 0212 Records and Information Management Policy
0212A Records Retention Schedule Policy Attachment
PO 2301 Financial Risk Authorization Policy
PO 9001 Program Management Policy
0105A CSRA Export Control Manual Policy Attachment
4000A Property Management and Control Manual Policy Attachment
4000C Health and Safety Program Manual Policy Attachment
7100A CSRA Subcontracts & Procurement Acquisition Manual Policy Attachment
PC 5050.01 Product Engineering and Development Process Process
PC 9001.02 Decision Analysis and Resolution Process
ST 9001.01 Integrated Program Management Process (IPMP) Standard
PR 5030.01.36 Asset and Configuration Management Procedure
PR 9001.01.02 Develop Program Definition Procedure
PR 9001.01.03 Perform Program Tailoring Procedure
PR 9001.01.04 Develop Program Estimate Procedure
PR 9001.01.05 Develop Program Schedule Procedure
PR 9001.01.06 Develop Measurement Approach Procedure
PR 9001.01.09 Manage Program Schedule Procedure
PR 9001.01.10 Manage Program Financials Procedure
PR 9001.01.12 Report Program Status Procedure
PR 9001.01.14 Manage Risks Procedure
PR 9001.01.15 Manage Issues Procedure
PR 9001.01.16 Manage Opportunities Procedure
PR 9001.01.17 Manage Program Change Procedure
PR 9001.01.18 Manage Suppliers/Subcontractors Procedure
PR 9001.01.19 Manage Program Quality Procedure
PR 9001.01.20 Manage Corrective Actions Procedure
PR 9001.01.21 Perform Quantitative Program Management Procedure
PR 9001.01.22 Manage Acceptance Procedure
PR 9001.01.23 Perform Program Completion Procedure
WI 9001.01.22.01 Peer Review Work Instruction
WI 9001.01.13.01 Program Management Review Work Instruction
WI 9001.01.06.01 Program Release Data Collection and Work Instruction
Page 110
Submission
WI 5050.01.02.01 Engineering Management Plan Work Instruction
WI 5050.01.02.02 Software Development Plan Work Instruction
WI 9001.02.04 Decision Analysis and Resolution Work Instruction
GU 5050.01.01.02 Agile Scrum Product Engineering Guide
GU 9001.02 Agile Supplement to PPMF Guide
GU 9001.01.07.01 Program Environment and Data Control Guide Guide
GU 9001.01.07.10 CSRA Program Training Guide Guide
PL 1106.01 Learning Operations Training Plan Plan
Communication Plans Examples
Configuration / Data Management Plans Examples
DAR Examples
Issues Management Plans Examples
Measurement and Analysis Plans Examples
Quality Plans Examples
Responsibility Assignment Matrices Examples

Requirements Management Plans Examples
Risk Management Plans Examples
Security Management Plans Examples
Staffing Plans and Profiles Examples
Technology Management Plans Examples
Page 111

Program Management Plan Template

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Program Management Plan Template

Caricato da

Copyright:

Formati disponibili

Think Next. Now.

4.7 Required Vital Records ...............................................................................................26

13.1 <Program> Quality Organization .................................................................................57

13.10 Non-compliance Remediation..................................................................................66

1.1.3 CSRA Program Objectives...................................................................................83

8.3 Opportunities Management .........................................................................................99

DELETE THESE INSTRUCTIONS IN THE ACTUAL WORK PRODUCT

Completing the Program Management Plan

The PMP is a living document, reviewed annually, and updated as necessary.

1.1 Program Definition (PD)

1.1.1 Contract / Program Details

Table 1 Contract / Program Details Table

Period of Performance (POP):

CSRA Subcontractor(s) Name:

CSRA Job Number:

1.1.2 Client Business Objectives

Following are the <Client Name> business objectives:

Table 2 Program Objectives

2 Example: Client Example: Client Satisfaction a minimum of 90% Outstanding

4 Example: Process Example: Achieve CMMI Level 3, Maintain ISO-9001

5 Example: Business Example: Maintain business continuity: The most critical

1.1.4 In-Scope Functions

* Change … “as-is” to “to-be” …

* Change … “as-is” to “to-be” ….

* Change … “as-is” to “to-be” ….

* Maintain current activity …

* Maintain current activity …

* Maintain current activity …

1.1.5 Out of Scope Functions

Salesforce will be used by the program to track deliverable completion status.

1.1.6.1 Deliverable Acceptance

1.1.7 Management Approach

To be effective in achieving this primary management objective, the following will be

1) An agreed-upon baseline – Developing a program Work Breakdown Structure (WBS)

3) Defined processes and practices – The management processes and practices to be

4) A clear means of communication – A formal process is used to ensure timely and

See Program Communications section for further details

See Issues Management section for further details.

* Any scope items not listed in the program contract.

* Participation in activities not previously included in the the master schedule

* Provision or development of deliverables not included in the specific contract.

* A change in responsibilities, as defined in the contract between CSRA and <Client

* Any rework of completed activities or accepted deliverables.

* Investigative work to determine the impact of major changes.

* Impact caused by a change in the assumptions section

* Impact of any risk items.

* Delays or rework caused by items identified in the contract as <Client Name>

* Delays created by customer’s request to change the schedule requested or caused by

* Delays caused by a change in previously agreed-upon acceptance criteria.

See Contract Change Management section for further details.

See Risk Management section for further details.

8) An approach for accepting program deliverables – All of the completed deliverables

* Client COTR is identified as the acceptor.

* Each contract deliverable and milestone has a documented acceptance criterion

* Deliverables will be deemed accepted if the acceptance timeframe is exceeded.

9) A definition of what constitutes program completion – Program completion is defined as

See Program Completion section for further details

1.1.8 Technical Approach

1.1.9 Initial Risks and Issues

Table 4 Initial Set of Program Risks

Constraints are listed in Table 5 below.

5 Example: Dependencies Example: Key personnel availability due to business

7 Example: Dependencies Example: work being performed by a certain date so

8 Example: Technical Limitation Example: Security-related contractual limitations,