IT Project Planning Standards V 1.2

Information Technology Project Planning Standards – 1.2

Information Technology
Project Planning Standards
Author: Faisal Ahmed
Mission Area: Planning
Process: Standards

Version Control
Version Date Author Change Description
1.0 11/25/2011 Faisal Ahmed Initial version
1.1 01/10/2012 Faisal Ahmed Content Update
1.2 01/12/2012 Faisal Ahmed / Danielle Integrated input from Danielle Smith and
Smith / Colleen Hageman Colleen Hageman

Page 1


TABLE OF CONTENTS
1. INTRODUCTION ................................................................................................................................... 4

2. PURPOSE ............................................................................................................................................. 4

3. DESCRIPTION AND CATEGORY ........................................................................................................ 4

4. STANDARDS ........................................................................................................................................ 4

4.1 Standard Reference ................................................................................................................ 4

4.2 Standards Definition .............................................................................................................. 5

5. GENERAL GUIDANCE ......................................................................................................................... 6

5.1 Project Authorization (Charter) Documentation ............................................................... 10

5.2 Project Scope ........................................................................................................................ 11
5.2.1 Product Scope .............................................................................................................. 11
5.2.2 Project Management (PM) Scope ................................................................................. 13

5.3 Integrated Management and Control Plan ......................................................................... 13
5.3.1 Scope Management Plan ............................................................................................. 15
5.3.2 Schedule (Time) Management Plan ............................................................................. 15
5.3.3 Cost (Budget) Management Plan ................................................................................. 15
5.3.4 Quality Management Plan ............................................................................................ 16
5.3.5 Project Human Resource Management Plan ............................................................... 16
5.3.6 Project Communication Management Plan .................................................................. 17
5.3.7 Risk Management Plan ................................................................................................. 17
5.3.8 Procurement Management Plan ................................................................................... 17

5.4 Project Baselines (Schedule and Costs Estimates) ......................................................... 18
5.4.1 Schedule Estimate ........................................................................................................ 18
5.4.2 Cost (Budget) Estimate ................................................................................................. 18

5.5 Supporting Documentation ................................................................................................. 19
5.5.1 Referencing Related Documents .................................................................................. 20

6. RECOMMENDED OUTLINES FOR PLANNING DOCUMENTS ....................................................... 20

6.1 Project Authorization (Charter) ........................................................................................... 20

6.2 Scope Statement (Product and Management Scope) ....................................................... 21

6.3 Work Breakdown Structure (WBS) ..................................................................................... 21

6.4 Performance (Measures) Baseline ...................................................................................... 22

6.5 Integrated Management and Control Plan (Master Project Plan) .................................... 22

6.6 Scope Management Plan ..................................................................................................... 25

Page 2


6.7 Schedule (Management Plan) ............................................................................................. 26

6.8 Cost (Budget) Management Plan ........................................................................................ 26

6.9 Quality Management Plan .................................................................................................... 28

6.10 Staffing (HR) Management Plan .......................................................................................... 28

6.11 Communication Management Plan ..................................................................................... 29

6.12 Risk Management Plan ........................................................................................................ 30

6.13 Procurement Management Plan / Acquisition Plan .......................................................... 31

6.14 Earned Value Management Plan ......................................................................................... 33

7. SUPPORTING DOCUMENTATION .................................................................................................... 34

7.1 Alternatives Analysis ........................................................................................................... 35

7.2 Change Management Plan ................................................................................................... 35

7.3 Configuration Management Plan ........................................................................................ 36

7.4 Enterprise Architecture ........................................................................................................ 36

7.5 Solution Architecture ........................................................................................................... 37

7.6 Master Schedule ................................................................................................................... 38

7.7 Version Control Plan ............................................................................................................ 38

7.8 Test Plan ................................................................................................................................ 39

8. PREPARED BY ................................................................................................................................... 41

Page 3


1. Introduction
This Information Technology Project Planning Standards is a standards guide that establishes a
planning baseline for all the Information Technology Projects. This standards guide will be
applicable to all IT projects within the scope of the practicing organization(s).

2. Purpose
This document summarizes the major elements and artifacts of a project management plan and
how they are developed. Although its use is not intended to be 100% prescriptive, it is intended
to offer a framework for organizing the project plan’s elements and artifacts. When an artifact is
not included, there should be some rationale given for its omission. This guide is a synthesis of
project management best practices (see Standards) and the standardized practices in the
United States and other countries directives on managing IT Projects.
Through the optional independent Integrated Baseline Review (IBR) process, these standards
are used to evaluate and validate the project’s plans for quality, completeness and alignment to
the organization’s records of decisions and acquisition regulations. As per US OMB Circular A-
11, an IBR or an external program assessment is a requirement for all Major Investments to
transition from a planning phase to an execution phase.

3. Description and Category
There are two types of Information Technology (IT) investments. An investment may contain
more than one project and the project category is defined by the parent investment type.
 Major: Major IT Investment means a program requiring special management attention
because of its importance to the mission or function of the agency, a component of the
agency, or another organization; has significant program or policy implications; has high
executive visibility; has high development, operating, or maintenance costs; is funded
through other than direct appropriations; or, is defined as major by the agency’s capital
planning and investment control process.
 Non-Major: All agency investments not considered "major" are "non-major.”

4. Standards
4.1 Standard Reference
These standards are based on the Project Management Institute (PMI), Project Management
Body Of Knowledge (PMBOK), Third Edition, ANSI/PMI 99-001-2004; SEI- CMMI®; Office of
Management and Budget (OMB) and key references come from the PMBOK’s Chapter 4.1 and
Glossary.
Two leading organizations—the Software Engineering Institute (SEI) and the Project
Management Institute (PMI)—have developed guidelines and models for managing projects that
have become widely accepted in both private industry and the public sector. SEI has developed
the Capability Maturity Model Integration (CMMI®)1, which is a set of integrated reference
models that can be used to improve and appraise an organization’s ability to perform a

1
CMM, CMMI, and Capability Maturity Model are registered in the U.S. Patent and Trademark Office.

Page 4


discipline. Complementing that set of models is PMI’s Guide to the Project Management Body of
Knowledge (PMBOK®).2
The SEI’s CMMI® provides a structured view of process improvement in a specific discipline
(e.g., software engineering, systems engineering) across an organization. SEI states that a
“focus on process provides the infrastructure necessary to deal with an ever-changing world and
to maximize personnel and technology to be more effective.”3
PMI‘s PMBOK® describes proven, as well as innovative and advanced practices for project
management.4 PMI defines project management as, “the application of knowledge, skills, tools,
and techniques to project activities to meet project requirements.”5 PMBOK® defines 39 project
management processes that are mapped to five process groups (Initiating, Planning, Executing,
Controlling, and Closing).
International Organization for Standardization (ISO) 9000 is a family of standards for quality
management systems and maintained by ISO, the International Organization for
Standardization.
Six Sigma is a disciplined, data-driven approach and methodology for eliminating defects
(driving towards six standard deviations between the mean and the nearest specification limit) in
any process.
The Information Technology Infrastructure Library (ITIL) is a set of concepts and policies for
managing Information Technology (IT) infrastructure, development, and operations.
4.2 Standards Definition
The project management plan defines how the project is initiated, planned, executed, monitored
and controlled, and closed. The project plan documents the collection outputs (artifacts) from
the planning processes of the Planning Process Group. This includes:
 Project management processes selected by the project management team.
 Level of implementation of each selected process.
 Tools and techniques descriptions selected to accomplish the selected processes.
 Description of how the selected process will be used for the specific project.
 Description of how work will be executed to accomplish the project objectives.
 Description of how change will be monitored and controlled.
 Description of how configuration management will be performed.
 Description of how the performance baseline will be maintained and used.

2
“PMI” and the PMI logo are service and trademarks registered in the United States and other nations; “PMP” and
the PMP logo are certification marks registered in the United States and other nations;”PMBOK”, “PM Network”
and “PMI Today” are registered in the United States and other nations.
3
Guidelines for Process Integration and Product Improvement, SEI, 2003.
4 ®
A Guide to the Project Management Body of Knowledge (PMBOK Guide), Third Edition, Project Management
Institute.
5
Ibid.

Page 5


 Stakeholder communication requirements and plan.
 Selected project life cycle for multi-phase project.
 Management reviews processes for content, extent, and timing to address open issues
and pending decisions.
The PMBOK glossary defines a project plan as a “formal, approved document that defines how
the project is executed, monitored and controlled. It may be summary or detailed and may be
composed of one or more subsidiary management plans and other planning documents.”

5. General Guidance
The project plan is used to:
 Guide project execution.
 Document project planning methodologies (rules) and assumptions.
 Document project planning decisions regarding alternatives choices.
 Facilitate communication among stakeholders.
 Defines key management reviews as to content, extent, and timing.
 Provide a baseline for progress measurements and project control.
The project plan has several key elements, including:
 Project Authorization (Charter)
 Project Scope (that includes the product scope and project management scope)
 Integrated Management Control Plan
 Project Baselines (Schedule and Cost Estimates)
 Supporting Documentation

Page 6


The project plan’s key elements are graphically represented in Illustration 1, as:

6
Illustration 1: The Project Plan’s Key Elements

The plan is a consistent and coherent document that guides the project’s execution. Threaded
throughout, the plan references outputs of the other planning processes (including strategic
planning artifacts). The project plan is the product of an iterative planning process. For
example, the initial draft may include generic resource requirements and a sequence of
activities; while the final versions of the plan will include specific resources information and
explicit activity dates.
Project Management and Governance Commentary: For an organization’s Investment Review
Board (IRB) to make an informed decision, it is expected that the project plan is mature,

6
Updated by Faisal Ahmed from Project Planning Standards – Originally by William Brimberry

Page 7


supporting realistic schedule and cost estimates. To support the “why” a project should be
allowed go from the “Development/Modernization/Enhancement (DME) Plan” phase to the
“DME Develop” phase, the IRB’s decision depends on quality planning information. The mature
plan is assessed for standards adherence and reasonableness via the Integrated Baseline
Review process. In the context of integrated life cycle (ILC) techniques, the IBR must be
completed at the end of DME Plan phase, Illustration 2.

7
Illustration 2: Interior’s Integrated Life Cycle (ILC) and Project Planning

The project planning process facilitates the development of a realistic mature project plan that is
accepted by the organization (bought into). Generally, the project management planning
process produces the product scope, management scope, and cost & schedule estimates
leading to a mature project plan to be evaluated by an IBR.
The major artifacts (PMBOK reference) that make up the plan include:
 Project Authorization Statement or Charter (Section 4.1)
 Project Management Approach or Strategy (Section 4.3)
 Scope Statement (Section 5.2.3.1)
o Activity Sequence Analysis/Network Diagram (Section 6.2)

7

Page 8


 Work Breakdown Structure, WBS (Section 5.3.3.2)
 Performance (Measures) Baseline
o Schedule Estimate (Selection 6.5.3)
o Major Milestones (Section 6.1.3.3)
o Cost Estimates (Selection 7.1.3.1)
o Cost Baseline (Selection 7.2.3.1)
o Performance Metrics
 Integrated Management Control Plan
 Scope Management Plan (Section 5.1.3.1)
 Schedule (Management Plan) (Section 6.5.3.8)
 Cost (Budget) Management Plan (Section 7.1.3.4)
 Quality Management Plan (Section 8.1.3.6)
 Staffing (HR) Management Plan (Section 9.1.3.3)
 Communication Management Plan (Section 10.1.3.1)
 Risk Management Plan (Section 11.1.3.1)
 Procurement (and Contract) Management Plan (Section 12.1.3.1)
Within the plan, special attention should be given to the Work Breakdown Structure (WBS)
and Earned Value Management System8 (EVMS). The WBS is use as a planning and control
& monitoring tool for all aspects of the project. EVMS is a set of integrated processes used for
project monitoring & control. EVMS processes include planning, organizing, authorizing,
accounting and monitoring & control.
The following sections describe and detail the key groupings of major artifacts of the project
plan:
Section 5.1: Project Authorization (Charter) Documentation;
Section 5.2: Project Scope;
Section 5.3: Integrated Management Control Plan;
Section 5.4: Project Estimates (Schedule and Cost Baselines);
Section 5.5: Supporting (Background) Documentation; and
Section 6 : Recommended outlines for various planning documents.

8
American National Standards Institute (ANSI) Government Electronic Industry Technology Association (EIA)
Earned Value Management Systems (EVMS) Standards, November 2006

Page 9


5.1 Project Authorization (Charter) Documentation
Project authorization is documentation that officially recognizes the project and its formal start.
By convention, the project authorization document is usually the Project Charter. The project
authorization document is a relatively short document. Stating directly or by summarized
reference, the document should identify:
 Business and business need(s). This may be the project’s mission statement that may
summarize and/or reference more robust documents.
 Proposed solutions (products and/or services) that address the business need. A
proposed solution may be in the form of a statement of objective. A proposed solution
may reference specific Federal or DOI standards and requirements for adherence.
 Acquisition strategy addressing the business need. The acquisition strategy may explain
how alternatives will be identified. An example of a proposed acquisition
approach/strategy is: “first, perform market research of COTS of solutions, followed by
project planning, selection, development, testing, and implementation.”
 The authorized use of organizational resources for the project.
 Project Manager (PM) and the PM’s authorities.
The project authorization document is issued by the Program (Business) Executive of the
project at a level appropriate to the project needs. It authorizes the project manager to start the
project, manage the project, and to apply organizational resources for project activities. When a
project is performed under contract, the signed contract may serve as the vendor’s project
charter.
Formatting: When possible and appropriate, the project authorization section uses the
Investment or Program Charter or text from the Investment / Program Charter. If not, the
authorization section should summarize the organizational documentation that gives the project
authority. For more formatting information reference Project Management Institute’s (PMI),
Project Management Body of Knowledge (PMBOK), Third Edition, ANSI/PMI 99-001-2004.

Page
10


5.2 Project Scope
The project scope defines all authorized work of the project. The project scope statement is
based on detailed product scope (orange sphere) and project management scope (magenta
sphere), Illustration 3.

9
Illustration 3: Project / Program Scope
The product scope includes all technical outputs and work activities produced throughout the
development phases of the systems life cycle (SLC), Illustration 1. The project’s management
scope includes the planning, monitoring, control and quality assurance work activities produced
throughout the project management life cycle, Illustration 1. Project scope is the output of the
scope management processes.
5.2.1 Product Scope
The first body of work, product scope addressing “what is to be done,” is derived from the
architecture/systems engineering process. Often the product scope includes the solutions
architecture that should align to the enterprise architecture (EA) or system engineering analysis,
Illustration 4.

10
Illustration 4: Architecture/Systems Engineering Analysis derives Product Scope

9

Page
11


The architecture/engineering process analyzes, classifies, aligns (the respective reference
models), documenting the business performance, business functions, business information,
technical services and technical requirements. This process leads to the mature product scope
that may include the solutions architecture. In the project plan, the product scope collects this
information into one coherent document. Produced by other efforts, this information may
originate in other artifacts, including:
 EA and Segment Architecture (including the Business Process Model)
 Business Alternatives Analysis
 Information and Records Management Plan (including the Logical Data Model)
 Privacy Analysis11
 FOIA Analysis12
 508 Compliance Analysis13
 Security Plan
 Solutions Architecture (Use Cases, Component, Deployment and Operational Models)
 Service and Technical Alternatives Analysis
 Requirements (Functional and Non-Functional Business)
Functional requirements are identified, defined and validated against business processes, use
cases and the logical data model which should be in alignment; represented in Illustration 5.

14
Illustration 5: Product Scope-Requirement Alignments
(Business Process ● Use Cases ● Data Model)
10
11
Not applicable in all Countries
12
Not applicable in all Countries
13
United States of America only
14

Page
12


Non-Functional business requirements must be identified and defined, adhering to
Organizational standards and national/local regulations (e.g., legal/political requirements).
5.2.2 Project Management (PM) Scope
The second body of work, project management scope addresses “What will get done”. (See
next section: Integrated Management and Control Plan for process and activity details which
address “how it gets done”).
The PM Scope includes all of the project’s management planning, monitoring & control and
quality assurance events and deliverable. Examples of these events are scope validation
exercises, quality assessment & assurance meetings, risk evaluation events, procurement
planning meetings, team orientation meetings, status and budget reports and project status
presentations.
In summary, the project scope includes all product and management (PM) work. Adhering to
organizational policy, all funded work must be “authorized” by the organization’s governing body
or an Investment Review Board. The IRB performs the important capital planning and
investments control’s (CPIC) portfolio decision-making function.
5.3 Integrated Management and Control Plan
The Integrated Management and Control Plan addresses how the project’s management (PM)
operates and why. It details the integrative management processes of:
 Change management process and procedures,
 Formal acceptance process,
 Monitoring & controlling trigger mechanisms, and
 How EVMS standards will be applied.
This section details the management activities that contribute to the overall integrated
management plan. The management activities include:
 Scope Management
 Schedule (Time) Management
 Cost (Budget) Management
 Quality Management
 Human Resource (Team) Management
 Communication Management
 Risk Management
 Procurement (and Contract) Management

Page
13


15
Illustration 6: Integrated Management and Control Plan

The integration management processes include the 1) project plan development, 2) project plan
execution, and 3) integrated change control. Pulling together all of the management practices,
these process relationships are represented in Illustration 6.

16
Illustration 7: Integrated Management and Control Plan

The integrated management & control plan details the integration of all management activities.
All sub-processes interact with each other.

15
OLES Technology Division Project Planning Standards – By Faisal Ahmed
16

Page
14


5.3.1 Scope Management Plan
Scope management identifies the project deliverables and all related work to be accomplished.
It includes 1) product outputs and work activities and 2) all project management work activities.
This management section summarizes how they will be/were determined, including the planning
methodology, assumptions and decisions. The scope management section underpins the
verification and change control processes, including formal acceptance process. Key sub-
artifacts produced in this section are:
 Project Objectives
 Product Scope (Functional & Non-Functional Business Requirements)
 Management Scope (PM Scope)
 Milestones and High Level Deliverables
 Work Breakdown Structure (WBS)
 WBS Dictionary
 Organizational Breakdown Structure (OBS)
 Scope Verification Criteria and Verification Procedures
 Scope Management Control Plan
Management processes include: 1) scope planning, 2) scope definition, 3) create the WBS, 4)
scope verification and 5) scope change control. Note: scope verification, a part of the formal
acceptance process, is tightly coupled with integration and quality management’s acceptance
criteria.
5.3.2 Schedule (Time) Management Plan
Time management addresses the schedule issues and schedule needed complete project
objectives. It includes the project schedule. This management section summarizes how it will
be/was determined, including its planning methodology, assumptions and decisions. Key sub-
artifacts produced in this section are:
 Project Schedule (Schedule Baseline)
 Project Network Diagram
 Other time artifacts (e.g., Gantt chart and milestone chart)
 Updated WBS
 Schedule Management Control Plan
Management Processes include the 1) activity definition, 2) activity sequencing, 3) activity
resource estimating, 4) activity duration estimating, 5) schedule development, and 6) schedule
control.
5.3.3 Cost (Budget) Management Plan
Cost management addresses the cost of the resources needed to complete project activities.
Additionally, project cost management considers the effect of project’s decisions on the
product’s overall costs, often referred to as the life-cycle costing or total cost of ownership. It

Page
15


includes the project cost estimates and baseline. This management section summarizes how
they will be/were determined, including the planning methodology, assumptions and decisions.
Key sub-artifacts produced in this section are:
 Resource Requirements
 Cost Estimating Methodologies (Ground Rules)
 Assumptions17
 Cost Estimates (Cost Baseline)
 Updated WBS
 Cost Management Control Plan
Management processes are 1) cost estimating, 2) cost budgeting, and 3) cost control.
5.3.4 Quality Management Plan
Quality management assures the product characteristics meet the stakeholders’ expectation.
The plan defines how the process assures that the product characteristics will be realized to
meet the stakeholders’ expectation. It includes details of work quality. This management
section summarizes how they will be/were determined, including the planning methodology,
assumptions and decisions. Key sub-artifacts produced in this section are:
 Quality Checklists
 Quality Metrics
 Quality Baseline
 Process Improvement Plan
 Quality Management Control Plan
Management processes include 1) quality planning, 2) quality assurance and surveillance, and
3) quality control.
5.3.5 Project Human Resource Management Plan
Human resource (HR) management addresses what appropriate human resources (internal
staffing and external contractors) are needed and how to use them to accomplish project
objectives. It includes descriptions of the team members and (all) stakeholders. This
management section summarizes how they will be/were identified, including the planning
methodology, assumptions and decisions. Key sub-artifacts produced in this section are:
 Stakeholder Analysis
 Role & Responsibility Assignments (Responsibility Assignment Matrix)
 Project Organization Charts (and project directories)
 Staffing Management Control Plan
Management processes include 1) human resource planning, 2) acquiring project team, 3) team
development, and 4) managing project team.
17
See Section 5.4: Project Baselines (Schedule and Costs Estimates)

Page
16


5.3.6 Project Communication Management Plan
Communication management addresses how the project ensures timely and appropriate
generation, collection, dissemination, storage, and disposition of project information. It includes
stakeholder communications requirements. This management section summarizes how they
will be/were determined, including the planning methodology, assumptions and decisions.
Special attention should be given to earned value management (EVM) reporting section of this
document as an integrated practice to provide a list of key members (and the communication
channels within and outward) for project control and performance reporting on a regular basis.
Key sub-artifacts produced in this section are:
 Control Data & Reporting Requirements
 Performance Reporting Specifications
 Communications Management Control Plan
Management processes include 1) communication planning, 2) information distribution, 3)
performance reporting, and 4) managing stakeholders.
5.3.7 Risk Management Plan
Risk management addresses how risks are systematically identified, analyzed and responded to
throughout the project. It includes descriptions of the project risks. This management section
summarizes how they will be/were determined, including the planning methodology,
assumptions and decisions. Key sub-artifacts produced in this section are:
 Risk Inventory with Thresholds
 Ranked and Prioritized Probability-Impact Matrix
 Risk owner designation
 Response Plan (with workarounds and corrective action plans)
 Risk Management Control Plan
Management processes include 1) risk management planning, 2) risk identification, 3)
qualitative risk analysis, 4) quantitative risk analysis, 5) risk response planning, and 6) risk
monitoring and control.
5.3.8 Procurement Management Plan
The Procurement Management Plan addresses how goods and service are attained from
outside the performing organization. It includes descriptions of the project procurement
strategies and actions. This management section summarizes how they will be/were
determined, including the planning methodology, assumptions and decisions. Key sub-artifacts
produced in this section are:
 Acquisition strategy
 Statement of Objectives/Work (SOO/SOW) or Performance Work Statement (PWS)
 Make-or-Buy decisions
 Request for changes procedures
 Product (Performance) acceptance criteria and procedures

Page
17


 Request for Proposal (RFP) and Others (RFI and RFQ)
 Contract
 Contract change process
 Contract Closure criteria and procedures
 Procurement Management Control Plan
Management processes include 1) plan purchases and acquisitions, 2) plan contracting, 3)
request seller responses, 4) select sellers, 5) contract administration, and 6) contract closure.
5.4 Project Baselines (Schedule and Costs Estimates)
5.4.1 Schedule Estimate
This section of the project plan details the risk-adjusted schedule baseline, estimate assumptions
and estimating methodologies. The schedule estimate is primarily the product of the Schedule
(Time) Management processes.
5.4.2 Cost (Budget) Estimate
This section of the project plan details the risk-adjusted cost baseline, estimate assumptions
and estimating methodologies. The cost (budget) estimates are primarily the products of the
Cost (Budget) Management processes.

Particular attention must be given to the Government Accounting Office’s (GAO) Cost
Assessment Guide. “The objective of the technical baseline is to provide in a single document
(artifact) a common definition of the program-including a detailed technical, program, and
schedule description of the system-from which all life cycle costs estimates (LCCE) will be
derived . . .”18
Discussion19: “Developing a good cost estimate requires stable program requirements, access
to detailed documentation and historical data, well trained and experience cost analyst, a risk
and uncertainty analyst, the range of confidence levels, and adequate contingency and
management reserves. Cost estimating is nonetheless difficult in the best of circumstances. It
requires both science and judgment. And, since answers are seldom–if ever–precise, the goal
is to find a ‘reasonable’ answer. However, the cost estimator typically faces many challenges in
doing so. These challenges often lead to bad estimates, which can be characterized as
containing poorly defined assumptions, no supporting documentation, no comparisons to similar
programs, inadequate data collection, inappropriate estimating methodology, irrelevant or out-
of-date, no basis or rationale for the estimate, and no defined process for generating the
estimate.”
The WBS is the foundation of every project, because it defines in detail the work necessary to
accomplish the project objectives. A typical WBS and WBS Dictionary detail the requirements,
resources, and tasks that must be accomplished. The WBS should be defined in terms of the
product oriented elements. This is considered a best practice in cost estimating because a
product oriented WBS ensures that all cost are captured.20

18
United States GAO Cost Estimate Guide, GAO-05-1134SP, July 2007, Chapter 7
19
20

Page
18


“Cost estimates are typically based on limited information and therefore need to be bound by
the constraints that make estimating possible. These constraints are usually in the form of
[ground rules and] assumptions that bind the estimate’s scope, establishing baseline conditions
the estimate will be built from. Because of the many unknowns, cost analysts must create a
series of statements that define the conditions the estimate is to be based on. These
statements are usually in the form of ground rules and assumptions (GR&A).”Error! Bookmark
ot defined. Ground rules are the agreed upon estimating standards (methodologies) that
provide guidance and minimize conflicts in definitions. Assumptions are a set of judgments
about past, present, or future conditions postulated as true in the absence of positive proof.
These assumptions are not arbitrary and should be based on expert opinion. They should be
treated as risks.
5.5 Supporting Documentation
The supporting documentation can consist of additional plans as appropriate. Some of the
Supporting Documents are:
 Alternatives Analysis
 Change / Configuration Management Plan
 Enterprise Architecture
 Solution Architecture
 Master Schedule
 Version Control Plan
 Test Plan
In addition, the supporting documentation quotes, summarizes and/or references documentation
that gives more meaning, understanding, context, authority to the project plan. Supporting
documentation may also include:
 Mission or Strategic Plans.
 Organizational Records-of-Decisions.
 Budget and Capital Planning & Investment Control (CPIC) documentation.
 Organizational Policies and Standards.
 Legal Mandates and Legislation.
 Technical and Management Standards.
 Lessons Learned.
 Business Issues Details (resulting in a formal project).
 Project Manager’s and Team Credentials.
 Prior Business and Technical Studies.
 Business and Technical Alternative Studies.
 Issues Paper on Business or Project Assumptions and Limitations.

Page
19


5.5.1 Referencing Related Documents
If possible and appropriate, the supporting documentation should be directly quoted. If not, all
documentation should be accurately concisely summarized and authoritatively referenced. If
available, all documentation may include authoritative internet addresses. All systems of records
must be registered with the Federal Registry and a Statement of Records Notice (SORN) must
be publicly available. If the system contain or have the potential co contain any Personally
Identifiable Information (PII) data, the agency Privacy Officer must be contacted to ensure the
privacy protection requirements are either met or being addressed.

6. Recommended Outlines for Planning Documents
The document outlines below are based on PMI, OPM, GAO and ANSI standards and
recommended for all projects. However recommendation not intended to be 100% prescriptive,
it is intended to offer a framework for organizing the project plan elements and artifacts. If an
artifact is not included, there should be some rationale given for its omission.
6.1 Project Authorization (Charter)
As mentioned previously, Office of Management and Budget (OMB) requires three different
charters for every Major Investment. However OMB does not provide directions on how to
develop all of these charters. In order to minimize workload, the following outline can be
modified to accommodate these multiple charter requirements:
1. Charter Purpose (Investment or Program or Integrated Project Team)
2. Investment / Project Purpose
2.1 Project Vision Overview
2.2 Project Goals and Objectives
3. Project Scope
4. Proposed or Anticipated Solution
5. Project Conditions
5.1 Assumptions, Conditions and Exceptions (ACE)
5.2 Constraints
5.3 Project’s Success Criteria
5.4 Risks
5.5 Issues
6. Project’s Acquisition Approach / Strategy (Contracting Officer)
7. Project Authorization for Allocation and Use of Resources (including Human Capital)
8. Project Team Organization Plans
8.1 Team Composition
8.2 Project Manager’s Responsibility, Authority and Ownership
9. Approvals / Records of Decision (RoD)

Page
20


10. Appendices (Full Project Stakeholder Roles and Responsibilities Table, Full project
Team’s Roles and Responsibilities Table, All working team’s Roles and Responsibilities
Table, Applicable Legal and Reporting Requirements, Acronyms, etc.).
6.2 Scope Statement (Product and Management Scope)
Following is the outline for the project’s Scope Statement:
1. Product Scope Statement
1.1 Project Business Need
1.2 Project Objectives
1.3 Product Overview
1.4 Product Lifecycle Deliverables
1.4.1 Design Deliverables
1.4.2 Development Deliverables
1.4.3 Test and Validation Deliverables
1.4.4 Implementation Deliverables
1.4.5 Product Scope Requirements
2. Management Scope Statement
2.1 Lifecycle Management Plan
2.1.1 Integrated Management and Control Plan
2.2 Design Management Plan
2.3 Development / Integration Management Plan
2.4 Test and Validation Management Plan
2.5 Implementation Management Plan
2.6 Management Scope Requirements
2.7 Management Scope Analysis Summary
6.3 Work Breakdown Structure (WBS)
Following is the outline for the Work Breakdown Structure and the WBS Dictionary:
1. Introduction
1.1 WBS Description
1.2 WBS Dictionary Description
2. Project WBS
2.1 WBS (Overall Summary Level)
2.2 WBS (Project Management Level)
2.3 WBS (Phase 1)
2.4 WBS (Phase 2)…………to all the phases

Page
21


3. WBS Dictionary
5. Appendix (Acronyms, reference document listings, etc.)
6.4 Performance (Measures) Baseline
Following is the outline for the Performance (Measures) Baseline:
1. Introduction
1.1 Purpose
1.2 Project Description and Background
2. Estimates
2.1 Schedule Estimates
2.2 Cost Estimates
3. Baselines
3.1 Schedule Baselines
3.2 Cost Baselines
4. Milestones
4.1 Development Phases
4.1.1 Milestones
4.1.2 Deliverables (Every 3 to 6 Months)
4.2 Integration Phases
4.2.1 Milestones
4.3 Operational Phases
4.3.1 Milestones
5. Approvals or Records of Decision (RoD)
6.5 Integrated Management and Control Plan (Master Project Plan)
Following is the outline for the Integrated Management and Control Plan (IMCP) or Master
Project Plan (MPP):
1. Introduction
1.1 Purpose
1.2 Project Description and Background
1.3 Document Organization
1.4 Project Management Planning Process
1.5 Level of Implementation of Each Selected Process

Page
22


1.6 Tools and Techniques Selected to Accomplish the Process
1.7 Description of How Selected Process will be used for Project Planning
1.8 Stakeholder Communication and the Planning Process
1.9 Project Plan’s Management Review Process for Content, Extent and Timing
2. Project Authorization
2.1 Project’s Business Needs
2.2 Project’s Objectives
2.3 Project’s Proposed Solution(s)
2.4 Project’s Acquisition Strategy
2.5 Project’s Resource Authorization
2.6 Project’s Resource Organization
2.6.1 Project Manager, Contact Information, and PM’s Authority
2.7 References to Project’s Charters
3. Project’s Scope
3.1 Work Breakdown Structure (WBS) and Organizational Breakdown Structure
(OBS)
3.2 WBS Dictionary
3.3 Product Scope Statement
3.3.1 Product Life Cycle Deliverables
3.3.2 Product Scope Requirements
3.3.3 Architecture/System Engineering Analysis Summary
3.4 Management Scope Statement
3.4.1 Development or Integration Management
3.4.2 Life Cycle Management Plan
4. Integrated Management and Control Plan (IMCP)
4.1 Integrated Control Plan
4.1.1 WBS-OBS Description
4.1.2 EVMS Description
4.2 Scope Management Plan
4.2.1 Project Objectives
4.2.2 Product Scope
4.2.3 Project Management Scope
4.2.4 Scope Verification Criteria and Verification Procedures
4.2.5 Scope Management Control Plan
4.3 Schedule Management Plan

Page
23


4.3.1 Project Schedule (Baseline)
4.3.2 Project Network Diagram
4.3.3 Other Time Artifacts (Gantt Chart etc.)
4.3.4 Schedule Management Control Plan
4.4 Cost Management Plan
4.4.1 Cost Management Plan Resource Requirements
4.4.2 Cost Management Plan Cost Estimating Methodologies
4.4.3 Cost Management Plan Cost Estimates (Cost Baseline)
4.4.4 Cost Management Control Plan
4.5 Quality Management Plan
4.5.1 Quality Baseline
4.5.2 Quality Metrics
4.5.3 Quality Checklists
4.5.4 Quality Process Improvement Plan
4.5.5 Quality Management Control Plan
4.6 Human Resource Management Plan
4.6.1 Stakeholder Analysis
4.6.2 Roles and Responsibility Assignments (Responsibility Matrix)
4.6.3 Project Organization Charts (and Project Directories)
4.6.4 Staffing Management Control Plan
4.7 Communication Management Plan
4.7.1 Control and Data Reporting Requirements
4.7.2 Performance Reporting Specifications
4.7.3 Communications Management Control Plan
4.8 Risk Management Plan
4.8.1 Risk Inventory with Thresholds
4.8.2 Ranked and Prioritized Probability-Impact Matrix
4.8.3 Response Plan (with Workarounds and Corrective Action Plans)
4.8.4 Risk Management Control Plan
4.9 Acquisition Plan
4.9.1 Acquisition Strategy
4.9.2 Alternatives Analysis (Make or Buy Decisions)
4.9.3 Request for Change Procedures
4.9.4 Evaluation Criteria
4.9.5 Request for Proposal (RFP) and Others (RFI and RFQ)

Page
24


4.9.6 Contract
4.9.7 Contract Change Process
4.9.8 Formal Acceptance and Contract Closure Procedures
4.9.9 Procurement Management Control Plan
5. Project Baseline
5.1 Schedule Estimates
5.2 Cost Estimates
5.2.1 Independent Government Cost Estimate (IGCE)
5.2.2 Independent Cost Estimate (ICE)
6. Project Closure Procedures
6.1 Administrative Closure
6.2 Contract Closure
7. Supporting Documentations
8. Approvals or Records of Decision (RoD)
6.6 Scope Management Plan
Following is the recommended outline for this plan:
1. Introduction
1.1 Purpose
1.2 Background
1.3 Scope
1.4 Product and Management Scope
1.5 Product Overview
1.6 Goals and Objectives
1.7 Assumptions and Decisions
2. Roles and Responsibilities
2.1 Governance Overview
2.1.1 Governance Authorities and Responsibilities
2.2 Project Team
2.3 Organizational Breakdown Structure
3. Scope management Activities
3.1 Scope Planning
3.2 Scope Definition
3.3 Creating the WBS and WBS Dictionary
3.3.1 WBS

Page
25


3.3.2 WBS Dictionary
3.3.3 Scope Baseline
3.4 Scope Verification
3.4.1 Scope Verification Procedure
3.5 Scope Management and Control
4. Approvals / Records of Decision
6.7 Schedule (Management Plan)
1. Introduction
1.1 Purpose
1.2 Assumptions
1.3 Objectives
3. Scheduling Process
3.1 Schedule Planning
3.2 Schedule Estimation
3.3 Steps to building the Project Schedule
3.4 Estimating Activities and Resources
3.4.1 Estimating Activities (Control Account to Task levels)
3.4.2 Estimating Resources (By activities and Fiscal Years)
3.5 Schedule Baseline
3.6 Storage Process
3.7 Approval Process
3.8 Update Process
3.9 Staffing Matrix and Profile
3.10 Earned Value Management (EVM) Process
3.11 Variance Review and Analysis
3.12 Schedule Issues
3.13 Schedule References
6.8 Cost (Budget) Management Plan

Page
26


1. Introduction
1.1 Purpose
1.2 Objectives
3. Independent Government Cost Estimate
3.1 Overall Approach
3.1.1 Develop Cost Element Structure (CES)
3.1.2 Identify Cost Estimation Methodologies
3.1.3 Conduct Function Point Analysis
3.1.4 Other Cost Assumptions
3.1.5 Develop Life Cycle Cost (LCC) Model
3.2 Project General Assumptions
3.3 Life Cycle Cost Estimation Summary
3.3.1 Without Optimization / Customization / Enhancements (Base Cost)
3.3.2 Without Optimization / Customization / Enhancements (Optimal Cost)
4. Project Budget
4.1 Budget Exclusions
5. Project Accounting
5.1 Cost Variance Analysis
5.1.1 Cost Variance Response and Reporting Process
5.2 Inter-Agency Agreements
5.3 Reimbursable Services Agreements
5.4 Reporting
5.4.1 Monthly Expenditure Reporting
5.4.2 Quarterly Funding Status Reporting
5.4.3 Quarterly Cost Variance Reporting
5.4.4 Earned Value Reporting
5.5 Working Capital Fund
5.6 Cost Change Control Process
5.7 Risk Management Contract and Management Reserves
5.8 Resource (FTE and Staff Augmentation) Requirements Cost
6. Associated Documents and Forms

Page
27


6.9 Quality Management Plan
1. Introduction
1.1 Purpose
1.2 Background
1.3 Scope
1.4 Quality Goals and Objectives
1.5 Assumptions
2. Quality Management Methodology
2.1 Quality Planning
2.2 Quality Assurance
2.2.1 Process Audits
2.2.2 Product Audits
2.2.3 Audit Performance
2.3 Quality Monitoring / Quality Assurance Surveillance
2.3.1 Quality Assurance Surveillance Approach
2.3.2 Surveillance Methods
2.3.3 Documenting Surveillance
2.4 Quality Control
2.4.1 Verification
2.4.2 Validation
2.4.3 Acceptance
2.4.4 Acceptance Testing
2.4.5 Quality Control Measures
5. Appendix (Quality Checklists, QC Measures, Quality Baselines, Acronyms, reference
document listings, etc.)
6.10 Staffing (HR) Management Plan
1. Introduction
1.1 Purpose
1.2 Assumptions
2. Project Team
2.1 Project Team Composition

Page
28


2.2 Acquiring the Project Team
2.3 Project Groups formed for Project Activities
2.4 Organizational Breakdown Structure
2.5 Required Skill Sets
2.6 Project Skills Matrix
3. Stakeholder Identification and Analysis
3.1 Project Team Member Identification Process
3.2 Stakeholder Identification Process
3.3 Stakeholder Analysis and Political Mapping
4. Project Human Capital Management Control
4.1 Stakeholder Expectation Management
4.2 Resource Management
4.2.1 Managing the Project Team
4.2.1.1 Roles and Responsibilities
4.2.2 Managing Contracted Resources
5. Non-Labor Resources
6. Resource Risk and Mitigation
7. Associated Documents
9. Appendix (Skills Matrix, Staffing Forecast, Staffing Sources, Acronyms, reference
6.11 Communication Management Plan
1. Introduction
1.1 Purpose
1.2 Approach
1.3 Assumptions
1.4 Constraints
2. Project Communication Framework and Documents
3. Project team Structures and Assignments
3.1 Team Goals
3.2 Team Communications
3.3 Team Roles and responsibilities
3.4 Team Roles – Appointing New Members
4. Project Stakeholders

Page
29


4.1 Stakeholder Analysis
4.1.1 Needs Assessment
4.1.2 Requirements Gathering
4.1.3 Requirements Consolidation
5. Risks and Issues Management
5.1 Escalation Process
5.2 Communication Pathways
6. Change Management Process
6.1 Communication Pathways
7. Performance Measurement Process
7.1 Performance reporting
7.2 Earned Value Management (EVM) Reporting
8. Communication Process Improvement
8.1 Gathering Feedback
8.2 Communicators / Channels
8.3 Recording Feedback
8.4 Evaluating Feedback
8.5 Responding to Feedback
8.6 Process Improvement
10. Appendix (Team Listing, Team Member listing with phone/e-mail etc., Roles and
responsibilities matrix, Stakeholder Listing, Performance Measurement Table,
Communication templates – briefing papers, memos, etc., Acronyms, reference
6.12 Risk Management Plan
1. Introduction
1.1 Purpose
1.2 Assumptions
3. Risk Management Methodology
3.1 Risk Identification
3.2 Risk Assessment
3.3 Risk Quantification / Scoring
3.4 Risk Response Planning

Page
30


3.4.1 Risk Ownership Assignment
3.4.2 Risk Mitigation and Contingency Planning
3.4.3 Risk Trigger
3.4.4 Risk Threshold
3.5 Risk Management
3.5.1 Risk Management Process and Activities
3.5.2 System Security Risk Management
3.5.3 Risk Management Budget and Schedule
3.5.4 Risk List and Issue List Management
4. Risk Closure
4.1 Avoidance
4.2 Acceptance
4.3 Mitigation
4.4 Closure process and reporting
6. Appendix (Risk List template, Risk Management Reporting table, Risk Management
Audit log, Acronyms, reference document listings, etc.)
Note: A Risks and Issues List must always accompany the plan and the should be reviewed and
updated monthly
6.13 Procurement Management Plan / Acquisition Plan
This plan is also known as the Acquisition Plan and usually is developed by the Contracting
Officer. There may be different documentation requirements for different agencies. However,
following is the recommended outline for this plan:
1. Introduction
1.1 Purpose
1.2 Background
2. Acquisition Objectives
3. Investment / Program Description
3.1 Authority and Identification
3.2 Statement of Need
3.3 Acquisition Alternatives
3.4 Records of Decision
3.5 Approvals for Operational Use
3.6 Milestone Chart Depicting the Objectives of the Acquisition
3.7 Milestones for Updating the Acquisition Plan
4. Applicable Conditions

Page
31


4.1 FAR
4.2 Vehicles
4.3 Agency
4.4 Other
5. Cost
5.1 Lifecycle Cost
5.2 Design-To-Cost
5.3 Application of Should Cost
6. Capability of Performance
6.1 Delivery of Performance Period Requirements
6.2 Tradeoffs
6.3 Risks
6.4 Acquisition Streamlining
7. Plan of Action
7.1 Sources
7.2 Competition
7.2.1 Component Breakout
7.2.2 Spares and Repair / Recode
7.2.3 Subcontractors
7.2.4 Multiple Sourcing
7.3 Source Selection Procedure
7.4 Acquisition Considerations
7.4.1 Acquisition Type
7.4.2 Warranties/Rework Guarantee
7.4.3 Contract Administration/Management
7.5 Budgeting and Funding
7.5.1 Program Funding
7.5.2 Contract Funding
8. Product Descriptions
9. Priorities, Allocations and Allotments
10. Contractor vs. Government Performance
11. Inherently Governmental Functions
12. Management Information Requirements
13. Make or Buy
14. Test and Evaluation

Page
32


15. Logistics Considerations
15.1 Assumptions
15.2 Quality Assurance, Reliability, Maintainability, Warranties
15.3 Requirements for Contractor Data
15.4 Standardization Concepts
15.5 Continuous Acquisition and Life cycle Support (CALS)
16. Government Furnished Elements
16.1 Property
16.2 Information
16.3 Intellectual Property
17. Considerations
17.1 Environmental Considerations
17.2 Security Considerations
17.3 Other Considerations
17.3.1 COTR / COR / Inspector Assignment Process
17.4 Identification of Participants in Acquisition Plan Preparation
18. Sub-Artifact References
18.1 Acquisition Strategy
18.2 Statement of Objectives / Statement of Work (SOO/SOW)
18.3 Alternatives Analysis
18.4 Request For Change (RFC) Procedures
18.5 Evaluation Criteria
18.6 Contract
18.7 Contract Change Process
18.8 Formal Acceptance and Contract Closure Procedures
18.9 Procurement Management and Control
20. Appendix (Contractual templates and forms, COTR/COR Assignment memo,
Acronyms, reference document listings, etc.)
6.14 Earned Value Management Plan
1. Introduction
1.1 Purpose
1.2 Background
2. Assigned Roles

Page
33


3. EVM Implementation Activities
3.1 Project Baseline
3.1.1 Work Breakdown Structure (WBS)
3.1.2 WBS Dictionary
3.1.3 Organizational Breakdown Structure (OBS)
3.1.4 Responsibility Assignment Matrix (RAM)
3.1.5 Control Account (CA)
3.1.6 Work Package (WP)
3.1.7 Planning Package (PP)
3.1.8 Control Account Plans (CAP)
3.1.9 Integrated Master Schedule (IMS)
3.1.10 Cost and Budget
3.1.11 Reporting Thresholds
3.1.12 Work Authorization Document (WAD)
3.2 Earned Value (EV) Status
3.3 Reporting of Actual Cost and Schedule
3.4 Statistical Forecast
3.5 Performance Analysis Reporting
3.5.1 Monthly Contract Performance Report (CPR) Analysis
3.5.2 Integrated Master Schedule (IMS) Review
3.5.3 Formal Reporting of Cost and Schedule Performance
3.6 Statement of Work (SOW)
4. Change Control
4.1 Change Process Schematic Diagram
6. Appendix (Earned Value Techniques, EV Calculation Formulas, Acronyms, reference
7. Supporting Documentation
Supporting documents are not mandatory documents by OMB or by DOI. However, some of the
supporting documentation (Alternatives Analysis, Enterprise Architecture and Draft Solution
Architecture framework) are considered pre-planning documents and provide the information,
analysis, verification and validation needed to develop a robust Business Case for the
investment/project, as well as provide the initiation point for the Exhibit-300 for the Major
Investment. The other supporting documents provide the credibility and efficient progress of the
project while minimizing risks and rework.

Page
34


7.1 Alternatives Analysis
1. Introduction
1.1 Purpose
1.2 Objectives
2. Executive Summary
3. Recommendation
4. Overview
4.1 Mission
4.2 Architecture
4.3 Expected Useful Life / Sunset
4.4 Objective Based Performance Measures
5. Cost Benefit Analysis (CBA)
5.1 Identification of Viable Alternatives
5.2 Option 0: Status Quo
5.3 Option 1:
5.4 Option 2:
5.5 Option 3:
5.6 Alternative to Options 0-3: (e.g. Government Service Provider)
6. Results
6.1 Cost Estimate Comparison of Alternatives (in millions of dollars)
6.2 Mission driven Functional Comparison of Alternatives
6.3 Benefit Comparison of Alternatives
6.4 Conclusion
8. Appendix (References, Source Documents list, Bibliography, etc.)
7.2 Change Management Plan
1. Introduction
1.1 Purpose
1.2 Objectives
2. Definitions
2.1 Definition of Change
2.2 Scope Relationships

Page
35


3. Change Management Process
3.1 General Rules
3.2 Change Process Explanation
3.3 Roles and Responsibilities
3.4 Change Request Cycle
3.5 Approval Guidelines
5. Appendix (Change Process Diagram, Change Process Walk-Through, Change
Request Form Template, Change Log Template, etc.)
7.3 Configuration Management Plan
The Configuration Management plan is an extension of the Change Management Plan. Thus a
separate Configuration Management Plan is not often needed for single project based
investments. However, if an investment contains more than a single project or the project within
the investment is of integration or multiple component assimilation type project, an investment
level Configuration Management Plan is highly useful. Following is the recommended outline for
this plan:
1. Introduction
1.1 Purpose
1.2 Objectives
2. Definitions
2.1 Definition of Configuration related to the investment
2.2 Scope Relationships
3. Configuration Management Process
3.1 General Rules
3.2 Roles and Responsibilities
3.3 Configuration Governance and Oversight (if multiple component)
3.4 Request and Escalation Cycle
3.5 Approval Guidelines
3.6 Document Management
3.7 Configuration Records Library and Archives
5. Appendix (Process Diagram, Process Walk-Through, etc.)
6. Configuration Tracking (reviewed and updated monthly recommended)
7.4 Enterprise Architecture
1. Introduction

Page
36


1.1 Purpose
1.2 Objectives
2. Modernization Blueprint
2.1 Segment Architectural Transition
2.2 As-Is Conceptual Solution Architecture
2.3 Intermediate Target Conceptual Solution Architecture
2.4 Target Conceptual Solution Architecture
2.4.1 Specific Architectural Considerations
2.5 Segment Sequencing Plan
3. Segment mappings
4. Service Component reference Model (SRM)
5. Technical reference Model (TRM)
6. High Level Requirements and Alignment to Strategic Goals
6.1 Mission Goals Alignment
6.1.1 Mission Goal 1
6.1.2 Mission Goal 2
6.1.3 Mission Goal 3………
7. EA Authority and Governance
9. Appendix (Architectural Diagrams, Strategic Plan Mapping Table, Mapping of
Program Requirement to Mission Goals table, etc.)
7.5 Solution Architecture
1. Introduction
1.1 Purpose
1.2 Overview
1.3 Relationship to Enterprise Architecture (EA)
2. Solution Objective and Scope
2.1 Business Drivers
2.2 Information Technology Drivers
3. High Level Business Descriptors
3.1 Conceptual Elements
3.1.1 Access and Delivery
3.1.2 Business Services
3.1.3 Resources

Page
37


4. Solution Overview
4.1 Patterns for Enterprise Architecture Assimilation
4.1.1 Status Quo
4.1.2 Intermediate
4.1.3 Target
5. Use Case Model
5.1 System Components
5.1.1 Interfaces
5.2 Architectural Components
5.3 Security Components
5.3.1 Access Control
5.3.1.1 Role Based
5.3.1.2 Domain
5.3.1.3 Discretionary
6. Deployment / Operational Model
6.1 Deployment Unit Mapping
6.2 Walkthrough
6.2.1 Example Walkthrough
7. Architectural Decisions
7.1 Segment Governance Framework
9. Appendix (Capacity Characteristics, Use Case template, Deployment mapping to
Logical Node Table, Deployment mapping to Physical Node Table, etc.)
7.6 Master Schedule
There is no specific guidance to the Master Schedule format. All project schedules must be
subsumed into the Master Schedule. The Master Schedule must have dependencies
(predecessor, successor, parallel) identified for all sub schedules. A critical chain management
method is highly recommended. Various software (e.g. Microsoft Project ™, Primavera ™, etc.)
can be used to facilitate this.
7.7 Version Control Plan
The Version Control Plan is usually very specific to the software being developed and the
methodology used. It is also highly dependent on the Master Schedule. Following is a generic
recommended outline for this plan:
1. Introduction
1.1 Purpose
1.2 Objectives
2. Scope

Page
38


2.1 Assumptions
2.2 References
3. Methodology
4. Tools and Techniques
4.1 Versioning Process
4.2 Version Outlines
5. Evolving Conclusion
7. Appendix (Version Specific Installation Documents table, Version Records table,
etc.)
7.8 Test Plan
The Test Plan is also applicable to a software development project. This plan is generally used
in tandem with the Version Control Plan. Following is the recommended outline for this plan:
1. Introduction
1.1 Purpose
1.2 Background
1.3 Objectives
2. Relationship to Version Control Process
3.1 Integrated project Team (IPT)
3.1.1 Technical Team(s)
3.1.2 Business Team(s)
3.2 Bureau Level Team(s)
3.3 External Team(s)
3.4 Evaluation Team(s)
3.5 Governance
4. Test Environment
4.1 Test Locations and Equipment
4.2 Testers
4.3 Test Data
4.4 Prerequisites and Assumptions
4.4.1 Prerequisites
4.4.2 Assumptions
4.5 Support Services / Help Desk
4.6 Test Status Meetings

Page
39


4.7 Test Metrics
5. Test Methodology
5.1 Survey Format
5.2 Scenario Format
5.3 Test Script Format
5.4 Discrepancy Reporting (DR)
5.5 Support Service / Help Desk Procedures
5.6 Governance Discussion Items
6. Test Completion Report
8. Appendix (Test Scripts example, Test Survey example, Test Scenario example, DR
Form, DR Log, Test Communication Process Walk-Through, etc.)

Page
40


8. Prepared by

__________________________________
Faisal Ahmed
Assistant Director - Technology
DOI – Office of Law Enforcement and Security
http://www.doi.gov/pmb/oles/technology.cfm
faisal_ahmed@ios.doi.gov / faisal_b_ahmed@hotmail.com

Faisal Ahmed serves as the Assistant Director for the
Office of Law Enforcement and Security leading the
Technology Division. He presently provides oversight and
guidance for the Office of Law Enforcement and Security
(OLES) Technology Programs with primary responsibility of
managing the OLES cornerstone program, the Incident
Management, Analysis, and Reporting System (IMARS).
Mr. Ahmed holds a Bachelor of Science degree in Information Technology from
University of Wisconsin, a Master of Science Degree in Technology Management
from University of Central Florida. He is a graduate of the Harvard University,
JFK School of Government - Senior Executive Fellows (SEF) program in Public
Policy and the Office of Personnel Management (OPM) - Leadership Education
and Development (LEAD) program at a Senior Executive level. He also holds
multiple technical and program management certifications including a Masters
Certificate in Project Management from Regis University, Paralegal Diploma in
Intellectual Property Law from Ashworth University, Senior Expert level FAC
P/PM from the Federal Acquisition Institute (FAI), Project Management
Professional (PMP), Program Management Professional (PgMP) and various
core technical certificates relating to CMMi, ITIL, Microsoft, Citrix, etc.

Assistant Director Ahmed has over 16 years of technology management
experience. He began his career as a Systems Analyst with the Fairfax County
Government, VA, USA and spent his career life in mixed Government,
International Organizations and private industries. Some of his highlight career
contributions were with the US Census Bureau, Department of Commerce, the
World Bank, Assurenet Limited and Apogen Technologies before joining the
Department of the Interior in 2007.

Page
41

IT Project Planning Standards V 1.2

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to IT Project Planning Standards V 1.2

Similar to IT Project Planning Standards V 1.2 (20)

IT Project Planning Standards V 1.2