Acquisition Program Baseline
A. Purpose
The Acquisition Program Baseline (APB) formally documents the program’s critical cost,
schedule, and performance parameters, expressed in measurable, quantitative terms
that must be met in order to accomplish the program’s goals. By tracking and
measuring actual program performance against this formal baseline, the program’s
management is alerted to potential problems, such as cost growth or requirements
creep, and has the ability to take early corrective action.
The APB documents the fundamental agreement on critical program cost, schedule,
and performance objectives between the Program Manager (PM), the Component Head
and the DHS Acquisition Decision Authority (ADA). The scope of the APB
encompasses the entire planned execution of the program. Its parameters trace back to
the mission gaps expressed in the Mission Need Statement (MNS), and the
requirements established in the Operational Requirements Document (ORD). The
program’s OMB Exhibit 300 and the APB should align and be consistent.
The APB guidance as outlined and described in this document cancels and supersedes
all previous DHS guidance for APBs.
B. Overview of the APB Process
The PM is responsible for developing and maintaining the APB and, most importantly,
for executing the program to achieve this baseline. The program’s APB is formally
submitted at Acquisition Decision Event (ADE) 2A. Acquisition Decision Authority
(ADA) approval of the APB at ADE-2A establishes the formal program/project baseline
for cost, schedule, and performance. The APB is revalidated by the ADA at ADE-3
(Produce, Deploy and Support)
Once approved by the ADA, any change to the APB, from whatever cause, requires
subsequent approval by the ADA. However, the PM has the authority to make “tradeoffs” within the trade spaces defined between each APB parameter’s threshold and
objective value, as long as the established program baseline is not exceeded. To
document proposed changes to the APB, the PM shall prepare a revision to the APB
describing the rationale for the revision in the Revision Summary section. This
guidance provides specific instructions for documenting changes to APB parameters
proposed for change.
An APB breach of performance or schedule is defined as failure to meet the threshold
value of the specific parameter. An APB cost breach is defined as cumulative program
cost increases greater than or equal to 8% from the approved cost baseline. Breaches
to the APB can be driven by multiple causes, many of which are fact-of life changes in
requirements, resources, or schedule that are beyond the PMs / Component’s control.
If a program breaches an approved APB parameter threshold (or the PM determines
that the program will so breach in the near future), the PM must promptly notify the
DHS Acquisition Instruction/Guidebook #102-01-001: Appendix K
Interim Version 1.9 November 7 2008
K-1
Component leadership and ADA via a formal memo. The PM must submit (1) a
remediation plan both explaining circumstances of the breach and proposing corrective
action within 30 days of breach notification and (2) if required, a revised APB for ADA
approval within 90 days of breach notification. A copy of the standard DHS remediation
plan template is provided later in this appendix.
In many cases, DHS programs are aggregations of multiple discrete projects, and
deliver capability in the form of discrete products (e.g. platforms, software applications,
or enterprise services), or products integrated into a “system of systems.” APBs that
combine multiple projects into single, program-level cost and schedule parameters are
of limited usefulness in practical acquisition management where the work actually
occurs – at the project level.
As defined in the sample template and guidance to this document, a program may
consist of multiple constituent projects. As the complexity, duration, and cost of projects
vary widely, it is not feasible nor practical to mandate a “one size fits all” guidance for
determining whether to break out projects separately into individual APBs or to
encompass them within an overarching program-level APB with discrete projects.
Either way, the desired intent is for the PM to cite specific performance, schedule, and
cost parameters for each discrete project within their program. This project-specific APB
information can be described as a separate section within the program-level APB under
the Discrete Useful Segment/Project section of the APB (see APB Template), or it may
be documented in a separate APB just for that project. Note: Although a discrete
useful segment and a project are defined differently (see template and guidance in this
appendix), their corresponding baseline information can be documented similarly under
the Discrete Useful Segment/Project section of the APB.
Determining when a project should be documented in a separate APB depends upon
many different factors and will vary from project to project. Some questions/factors to
consider as to when a project should have a separate APB include but are not limited to
the following:
K-2
•
Is the project overly complex? Will management and oversight benefit from a
separate APB?
•
Des the project provide a product, application, or enterprise service with a unique
mission capability (e.g., unmanned air vehicle system) which is distinct from the
overall program mission capability?
•
Does the project provide a system platform with a large degree of performance
independence from other platforms (e.g., aircraft platform versus a ship platform)?
•
Does the project develop and implement a system driven by a stand alone set of
operational requirements (e.g., individual or unique ORD)?
•
Is the project at a significantly different development stage from other projects within
the program?
DHS Acquisition Instruction/Guidebook #102-01-001: Appendix K
Interim Version 1.9 November 7 2008
Note: The above questions/factors are provided as examples only and do not represent all
the considerations that may play a part in determining when a project should have a
separate APB. The PM and Component leadership should determine the approach best
fitted to the circumstances of the specific program/projects. Prior to preparing their APB,
the PM should reach agreement with their Component Head/CAE and the DHS ADA on
the appropriate APB documentation approach for any discrete projects within their
program.
DHS Acquisition Instruction/Guidebook #102-01-001: Appendix K
Interim Version 1.9 November 7 2008
K-3
Sample Template and Guidance
APB Format
The APB shall include the following information and comply with the following format.
Cover/Signature Page
Table of Contents
Section A. Revision Summary
Section B. Program Overview
1. Strategic Goals
2. Mission Need
3. Program Description
4. References
Section C. Top-Level Program Baseline
1. Program Performance
2. Program Schedule
3. Program Cost
Section D. Discrete Useful Segment/Project 1 Baseline (if applicable)
1. Discrete Useful Segment/Project 1 Performance
2. Discrete Useful Segment/Project 1 Schedule
3. Discrete Useful Segment/Project 1 Cost
Section E and beyond. Additional Discrete Useful Segment/
Project 2 Baselines (if applicable)
1. Discrete Useful Segment/Project 2 Performance
2. Discrete Useful Segment/Project 2 Schedule
3. Discrete Useful Segment/Project 2 Cost
K-4
DHS Acquisition Instruction/Guidebook #102-01-001: Appendix K
Interim Version 1.9 November 7 2008
Sample Template and Guidance
APB Guidance
Cover/Signature Page:
• See APB template
•
The APB cover page shall, at a minimum, be signed and dated by: the PM, the Component Head or CAE,
and the DHS ADA (dependent upon program level).
Table of Contents: See APB template
Section A. Revision Summary: Provide a summary of the revisions made to the document, including the
date of the revision. If this APB is the first submission, indicate so in this section.
Section B. Program Overview (1 to 2 pages in length)
• Strategic Goals – This section describes the DHS strategic goals supported by the program.
• Mission Need – This section summarizes the business/mission need as described in the MNS and
describes the high-level program requirements, as contained in the ORD.
• Program Description – This section provides a summary of the program approach and acquisition
strategy. If applicable, describe the relationship of projects within the program, such as how they
interface, interact, or integrate. Also, describe significant assumptions or dependencies with external
programs which the program may be reliant upon to be successful, if applicable.
• References – This section identifies the relevant source documents used to establish the program
baseline in the APB. Typical APB source documents include: MNS, ORD, Acquisition Strategy and LCCE
(see template and guidance at the end of this document). If any referenced document is not yet approved,
it shall be noted as “Draft.” If a separate document is used to identify (e.g., title, version, date approved,
etc.) the relevant source documents, then that document may be referenced instead.
Section C. Top-Level Program Baseline: This section of the APB contains the program's baseline
parameters and their associated threshold and objective values. The baseline parameters must be stated in
measurable, quantitative terms. The number of parameters will be the minimum number needed to
characterize the program’s operational performance, technical performance, schedule, and cost. Definitions
for the terms "objective" and "threshold" are listed below.
•
Threshold. The threshold value is the minimum acceptable value that, in the user's judgment, is
necessary to satisfy the need. If threshold values are not achieved, program performance is seriously
degraded, the program may be too costly, or the program may no longer be timely.
•
Objective. The objective value is that value desired by the user for which the PM is contracting or
otherwise attempting to obtain. The objective value could represent an operationally meaningful, timecritical, and cost-effective increment above the threshold for each program parameter. If no objective is
otherwise indicated, the objective is subsumed in the threshold.
For documenting changes to APB parameters, the PM shall create a new column or table, as appropriate,
entitled “Revision #” and enter only the values for the parameters that are proposed to be changed or deleted.
If the ADA approves the change, that column will remain in the table with only the changed values indicated.
Previously approved APB parameters shall not be removed and are to be retained in the APB to capture the
overall historical record of change to the program’s baseline.
Program Performance: The performance baseline should be based upon the Key Performance Parameters
(KPPs) specified in the ORD. In this document, a KPP is defined as those attributes or characteristics of a
system that are considered critical or essential to the development of an effective capability or system
required to successfully meet the mission of DHS (see definition in guidance). The values of each KPP
represent the program as it is expected to be produced and deployed. Failure to achieve a KPP (threshold is
not met) would require rebaselining or termination of the program based upon the decision by the ADA.
DHS Acquisition Instruction/Guidebook #102-01-001: Appendix K
Interim Version 1.9 November 7 2008
K-5
Sample Template and Guidance
Each KPP included in the APB must have both an objective and a threshold value. These objective and
threshold values shall be consistent with those contained in the ORD. If the objective values are not
specified, the objective value for performance shall be the same as the threshold value. Performance
thresholds and objectives must be verifiable by testing. The performance baseline may include operational,
technical, and supportability parameters. Other system-specific requirements, such as a cost KPP, may be
specified as applicable. The Component head/ADA may mandate additional Component-wide/Departmentwide performance parameters (for example interoperability, enterprise architecture, economic benefit or return
on investment) as they deem necessary.
The PM shall describe the program/project KPPs with thresholds and objectives in accordance with the format
noted in the table below. Project specific KPPs may be documented at the project level (see Section D) and
do not have to be duplicated in this section. Note: If a KPP has changed (revised or new), explain the reason
for it.
KEY PERFORMANCE
PARAMETER (KPP)
BASELINE
THRESHOLD
OBJECTIVE
REVISION #1
THRESHOLD
OBJECTIVE
KPP #1
KPP #2
KPP #3
KPP #4
KPP #5
KPP #X
Program Schedule: The PM should enter the planned completion dates for major program events. Examples
of typical major program events are listed in the table that follows. Additional program/project events, such as
those in the optional list below, may be specified as well. Project specific schedule events may be documented
at the project level (see Section D) and do not have to be duplicated in this section. Schedule dates shall be
specified as MONTH YR or QUARTER YR. Objective and threshold dates for each event must also be
specified. For Level 1 major acquisition programs, the threshold value should not typically exceed the objective
value by six months for programs lasting more than three years. For short programs lasting less than three
years, the threshold value should not typically exceed the objective value by three months.
MAJOR PROGRAM
EVENT
SYSTEM
REQUIREMENTS
REVIEW (SRR)
ADE 2 DECISION
PRELIMINARY DESIGN
REVIEW (PDR)
CRITICAL DESIGN
REVIEW (CDR)
PRODUCTION
READINESS REVIEW
(PRR)
ADE 3 DECISION
K-6
SCHEDULE BASELINE
THRESHOLD
OBJECTIVE
SCHEDULE REVISION #1
THRESHOLD
OBJECTIVE
DHS Acquisition Instruction/Guidebook #102-01-001: Appendix K
Interim Version 1.9 November 7 2008
Sample Template and Guidance
MAJOR PROGRAM
EVENT
INITIAL OPERATIONAL
TEST & EVALUATION
(IOT&E)
INITIAL OPERATIONAL
CAPABILITY (IOC)
FOLLOW-ON
OPERATIONAL TEST &
EVALUATION (FOT&E)
(when applicable)
FULL OPERATIONAL
CAPABILITY (FOC)
OTHER KEY EVENTS
(AS APPLICABLE)
SCHEDULE BASELINE
THRESHOLD
OBJECTIVE
SCHEDULE REVISION #1
THRESHOLD
OBJECTIVE
Examples of other key events the PM/Component Head could consider for APB use include, but are not
limited to:
• Functional Requirements
Review
• Application Test Readiness
Review
• Asset Deliveries
• Production contract award
• Project Decision
• Developmental Test &
Evaluation (DT&E)
(start/complete)
• Implementation Readiness
Review
• Preliminary design review
• Operational Test Readiness
Review
• Low Rate Initial Production
(LRIP) contract award
• First article/prototype
delivered
• Capability Development &
Demonstration contract
award
• Major contract award or
recompete date
• Final delivery
• Alternative Selection
• Concept & Technology
Development contract
• Operational support date
• Program termination
Note: For IT systems, the DHS Systems Life Cycle (SLC) process may require alternate or additional
schedule events (SLC expected events not listed). Enterprise services programs/projects should provide
applicable major program events as laid out in their program/project documentation.
Program Cost: The PM shall enter program/project total cost by Then Year dollars (also known as current
dollars). Cost data reflected in the baseline should reflect life cycle cost estimates or independent cost
estimates and be fully documented and defendable. Program cost data totals should reflect cost parameters
of corresponding projects documented in Section D, if applicable.
APB costs must represent total program funding requirements, not just the amount funded in the budget and
programmed through the Future Years Homeland Security Program (FYHSP) (i.e., baseline costs must
include unfunded requirements if those unfunded requirements are a part of the approved program).
However, the APB should not include costs that are not part of the program/project approved by the ADA.
The APB should contain cost parameters (objectives and thresholds) for major elements of the program life
cycle costs. The cost elements include:
DHS Acquisition Instruction/Guidebook #102-01-001: Appendix K
Interim Version 1.9 November 7 2008
K-7
Sample Template and Guidance
•
Acquisition Cost – All costs related to the acquisition (see definition of acquisition in template and
guidance of this document).
•
Operation and Maintenance (O&M) Cost – Includes all costs incurred for using and supporting the system
or capability, such as personnel, maintenance (unit and depot), spares, and training.
•
Total Life Cycle Cost – Costs of the entire life cycle of the program or project, including operations and
maintenance/support.
•
If applicable, total system quantity (to include both low rate initial production (LRIP) and production units)
•
Any other cost objective established by the milestone decision authority.
As the program/project progresses through later acquisition phases, acquisition costs shall be refined based
on actual costs from activities conducted during the Concept and Technology Development and Capability
Development and Demonstration phases.
The cost elements at ADE-2 will be provided in the initial cost baseline submission. Future columns will be added
at subsequent ADEs or ADA approved changes. Future columns will be reflected in every section. If a new cost
parameter is added, state "N/S" or “Not Specified” in the previous columns for that parameter. Previous columns
will not be revised to reflect actual results or changes in events or characteristic titles. If old parameters no longer
apply, state "deleted" in future columns. Do not change titles and values of old or previous parameters.
Program Cost Baseline in Then Year Dollars
Program Cost Estimate in Then Year Dollars (Millions)
Cost Categories
Baseline
Baseline
Revision #1
Threshold
Objective
Threshold
Revision #1
Objective
Acquisition
O&M
Life Cycle Cost
Note: Annotate via a footnote for the reason and milestone for a cost revision; a breach occurs at greater
than or equal to cumulative 8%.
Sections D, E, and beyond. Discrete Useful Segment/Project Baselines: These sections of the APB shall
contain the baseline parameters for discrete useful segments or projects and their associated threshold and
objective values. As in the top-level program baseline, the discrete useful segment/project baseline
parameters must be stated in measurable, quantitative terms. The number of parameters will be the
minimum number needed to characterize the operational performance, technical performance, schedule, and
cost of the discrete useful segment or discrete project.
Sample Template and Guidance
APB Terms and Definitions
APB Document Template
DHS Remediation Plan Template
DHS APB Review Checklist
APB Relationship to Other Key Program Documents
K-8
DHS Acquisition Instruction/Guidebook #102-01-001: Appendix K
Interim Version 1.9 November 7 2008
Sample Template and Guidance
APB Terms and Definitions
Acquisition: For the purposes of this guidance, “acquisition” includes the conceptualization, initiation,
planning, design, development, test, contracting, production, deployment, logistics support (i.e., spares),
modification of systems, supplies, or services (including construction) to satisfy DHS needs, intended for use
in or support of homeland security missions.
Acquisition Cost: All costs related to the acquisition (see definition of acquisition above).
Acquisition Decision Authority (ADA): With respect to a major DHS acquisition program, means the
individual within the Department of Homeland Security designated with overall responsibility (including
acquisition decision-making) for the program.
Acquisition Decision Event (ADE): A predetermined point within the acquisition phases at which the
investment will undergo a review prior to commencement of the next phase. Formerly known as a Key
Decision Point (KDP).
Acquisition Planning: Acquisition planning means the process by which the efforts of all personnel
responsible for an acquisition are coordinated and integrated through a comprehensive plan for fulfilling the
agency need in a timely manner and at a reasonable cost. It includes developing the overall strategy for
managing the acquisition.
Component Acquisition Executive (CAE): The CAE is the senior acquisition official in the Component. The
CAE is the individual responsible for the direct management for all acquisition functions and programs in that
Component.
Discrete Useful Segment: A unit of capability, defined by the Component, that is part of a larger effort (e.g.,
a release of a system, etc.) and can be measured for its outcome against pre-defined objectives or goals.
Full Operating Capability (FOC): The time at which investment becomes fully operational, with all functions
deployed to the designated user(s), as defined by the Program Manager.
Initial Operating Capability (IOC): The projected point in a program that indicates that there is major new
capability with measurable program benefit available to the designated user(s). Initial Operating Capability
may indicate the success of a set of releases or a pilot or may test a capability prior to modification and final
deployment. This point is set by the PM during planning according to the needs of the program, not by a
specific time reference (e.g., half finished or a particular Milestone Decision Point), and should reflect the
interdependencies revealed during planning. Initial Operating Capability is tracked at both the program level
and at the discrete useful segment level.
Key Performance Parameter (KPP): Those attributes or characteristics of a system/program/project that
are considered critical or essential parts of an effective system/program/project capability.
Life Cycle Cost: The total cost to the Federal Government of acquiring, operating, supporting, and, if
applicable, disposing of the items being acquired [FAR 7.101]; the sum of all costs over the useful life of a
building, system, or product; the sum total of the direct, indirect, recurring, nonrecurring, and other related
costs incurred or estimated to be incurred in the design, development, production, operation, maintenance,
support, and final disposition of a major system over its anticipated useful life span and salvage (resale)
value, if any [FAR 52.248-2(b)]. Where system or project planning anticipates the use of existing sites or
facilities, restoration and refurbishment costs should be included [OMB Circular A-94, App A].
Objective: The objective value of a parameter is that value desired by the user, within the resources
provided, for which the PM is contracting or otherwise attempting to obtain.
DHS Acquisition Instruction/Guidebook #102-01-001: Appendix K
Interim Version 1.9 November 7 2008
K-9
Sample Template and Guidance
Operation & Maintenance (O&M) Cost: Includes all costs incurred for using and supporting the system or
capability, such as personnel, maintenance (unit and depot), and training.
Program: The totality of activities directed to accomplish specific goals and objectives, which may provide new or
improved capabilities in response to approved requirements and/or sustain existing capabilities. Programs may
have multiple projects within the program authority set up to achieve overall programmatic capability. Programs
can achieve directed capabilities via a variety of paths, to include (but not be limited to): capital assets (e.g.
platforms/systems); IT applications/systems; and provision of enterprise services.
Program Manager (PM): The responsible agency customer, who, with significant discretional authority, is
uniquely empowered to make final scope-of-work, capital-investment, and performance acceptability decisions and
is responsible for accomplishing program objectives or production requirements through the acquisition of any mix
of in-house, contract, or reimbursable support resources. The PM is responsible for management and oversight of
the Integrated Product Team, and may have one or more PMs (see below) working for him/her.
Project: A planned undertaking with a definite beginning, objective, and ending. A project involves the definition,
acquisition, and fielding of a unique product/capability, service or result in accordance with specified resources and
requirements. A project may be the whole or a part of a program, and is funded by those investments related to
the program. All investment elements with a start and end date and producing a defined capability are considered
projects
Project Manager (PM): A project manager is the official assigned responsibility for accomplishing a specifically
designated unit of work effort or group of closely related efforts, established to achieve stated or designated
objectives, defined tasks, or other units of related effort on a schedule and in support of the program mission. The
PM is responsible for the planning, controlling, and reporting of the project, and for the management of a specific
function or functions, performance of the schedule, formulation of the budget, and execution of the approved
budget.
Remediation Plan: A discussion of an APB threshold breach, including current projected impact to cost,
schedule, and performance; root-cause analysis that explains the cause for the shortfall or breach; identification of
corrective actions with the date they will begin and the date they will be completed.
Strategic Goal or Strategic Objective: A statement of aim or purpose included in a strategic plan (e.g.,
DHS/Component).
Then Year Dollars: Dollars values in terms of prices at the time of purchase. Then Year Dollars account for
inflation, etc., to arrive at the cost of money in outlying years.
Threshold: The threshold value is the minimum acceptable value of an APB parameter that, in the user's
judgment, is necessary to satisfy the need.
Top-level Program Baseline: This reflects the top level cost, schedule and performance parameters for the
overall program, and should be used when the program is providing capability via a single product (e.g. capital
investment, IT application, enterprise service). Programs made up of multiple, stand-alone projects with multiple
products, etc should lay out their baseline in a “project-by-project” basis
Total Life Cycle Cost Estimate (LCCE): An estimate of the entire life cycle of the program or project, including
operations and maintenance/support.
K-10
DHS Acquisition Instruction/Guidebook #102-01-001: Appendix K
Interim Version 1.9 November 7 2008
Sample Template and Guidance
APB Document Template
Acquisition Program Baseline (APB)
for
(PROGRAM TITLE)
___________________________________
Program Manager
_______________
Date
Endorsed by:
____________________________________
Component Review Authority
_______________
Date
Approved by:
____________________________________
DHS Acquisition Decision Authority
_______________
Date
Submitted by:
DHS Acquisition Instruction/Guidebook #102-01-001: Appendix K
Interim Version 1.9 November 7 2008
K-11
Sample Template and Guidance
Table of Contents
Section A. Revision Summary ...........................................................................................................................
Section B. Program Overview ......................................................................................................................................
B.1. Strategic Goals..........................................................................................................................................................
B.2. Mission Need ............................................................................................................................................................
B.3 Program Description .................................................................................................................................................
B.4. References................................................................................................................................................................
Section C. Top-Level Program Baseline .....................................................................................................................
C.1. Program Performance ..............................................................................................................................................
C.2. Program Schedule....................................................................................................................................................
C.3. Program Cost............................................................................................................................................................
Section D. Discrete Useful Segment/Project 1 Baseline (if applicable)..................................................................
D.1. Discrete Useful Segment/Project 1 Performance..........................................................................................
D.2. Discrete Useful Segment/Project 1 Schedule ...............................................................................................
D.3. Discrete Useful Segment/Project 1 Cost .......................................................................................................
Section E and beyond. Additional Discrete Project Baselines (if applicable) ..............................................
E.1. Discrete Useful Segment//Project 2 Performance.........................................................................................
E.2. Discrete Useful Segment/Project 2 Schedule ...............................................................................................
E.3. Discrete Useful Segment/Project 2 Cost .......................................................................................................
K-12
DHS Acquisition Instruction/Guidebook #102-01-001: Appendix K
Interim Version 1.9 November 7 2008
Sample Template and Guidance
A.
Revision Summary
B.
Program Overview
B.1 Strategic Goals
B.2 Mission Need
B.3 Program Description
B.4 References
C.
Program Overview
C.1 Top-Level Program Performance
KEY PERFORMANCE
PARAMETER (KPP)
BASELINE
THRESHOLD
OBJECTIVE
REVISION #1
THRESHOLD
OBJECTIVE
KPP #1
KPP #2
KPP #3
KPP #X
C.2
Program Schedule
MAJOR PROGRAM
EVENT
SYSTEM
REQUIREMENTS
REVIEW (SRR)
ADE 2 DECISION
PRELIMINARY DESIGN
REVIEW (PDR)
CRITICAL DESIGN
REVIEW (CDR)
PRODUCTION
READINESS REVIEW
(PRR)
INITIAL OPERATIONAL
TEST & EVALUATION
(IOT&E)
ADE 3 DECISION
INITIAL OPERATIONAL
CAPABILITY (IOC)
FOLLOW-ON
OPERATIONAL TEST &
EVALUATION (FOT&E)
(when applicable)
FULL OPERATIONAL
CAPABILITY (FOC)
OTHER KEY EVENTS
(AS APPLICABLE)
SCHEDULE BASELINE
THRESHOLD
OBJECTIVE
SCHEDULE REVISION #1
THRESHOLD
OBJECTIVE
DHS Acquisition Instruction/Guidebook #102-01-001: Appendix K
Interim Version 1.9 November 7 2008
K-13
Sample Template and Guidance
Note: For IT systems, the DHS Systems Life Cycle (SLC) process may require alternate or additional
schedule events (SLC expected events not listed).
C.3 Program Cost
Program Cost Baseline in Then Year Dollars
Program Cost Estimate in Then Year Dollars (Millions)
Cost Categories
Baseline
Baseline
Revision #1
Threshold
Objective
Threshold
Revision #1
Objective
Acquisition
O&M
Life Cycle Cost
Note: Annotate the reason for a revision; a breach occurs at greater than or equal to cumulative 8%.
D through X. Discrete Useful Segments/Projects
Note: Attach individual Sections D through X for each discrete useful segment or project, separated by
segment or project name, using the charts illustrated above in Sections C for performance, cost, and
schedule. For example, the discrete useful segment or project may be documented as follows:
D.1
Discrete Project 1 Performance
KEY PERFORMANCE
PARAMETER (KPP)
BASELINE
THRESHOLD
OBJECTIVE
REVISION #1
THRESHOLD
OBJECTIVE
KPP #1
KPP #2
KPP #3
KPP #4
KPP #5
KPP #X
K-14
DHS Acquisition Instruction/Guidebook #102-01-001: Appendix K
Interim Version 1.9 November 7 2008
Sample Template and Guidance
D.2 Discrete Project 1 Schedule
MAJOR PROJECT
EVENT
SYSTEM
REQUIREMENTS
REVIEW (SRR)
ADE 2 DECISION
PRELIMINARY DESIGN
REVIEW (PDR)
CRITICAL DESIGN
REVIEW (CDR)
PRODUCTION
READINESS REVIEW
(PRR)
INITIAL OPERATIONAL
TEST & EVALUATION
(IOT&E)
ADE 3 DECISION
INITIAL OPERATIONAL
CAPABILITY (IOC)
FOLLOW-ON
OPERATIONAL TEST &
EVALUATION (FOT&E)
(when applicable)
FULL OPERATIONAL
CAPABILITY (FOC)
OTHER KEY EVENTS
(AS APPLICABLE)
SCHEDULE BASELINE
THRESHOLD
OBJECTIVE
SCHEDULE REVISION #1
THRESHOLD
OBJECTIVE
Note: For IT systems, the DHS Systems Life Cycle (SLC) process may require alternate or additional
schedule events (SLC expected events not listed).
D.3
Discrete Project 1 Cost
Project Cost Baseline in Then Year Dollars
Project Cost Estimate in Then Year Dollars (Millions)
Cost Categories
Baseline
Baseline
Revision #1
Threshold
Objective
Threshold
Revision #1
Objective
Acquisition
O&M
Life Cycle Cost
DHS Acquisition Instruction/Guidebook #102-01-001: Appendix K
Interim Version 1.9 November 7 2008
K-15
Sample Template and Guidance
DHS Remediation Plan Template
INVESTMENT PROGRAM:
FY:
QTR:
PURPOSE: This Plan should establish a sound approach/methodology to resolving the given problem.
Emphasis should be placed on assessing the “Impact” to the overall investment and determine a “way ahead”
for resolving the issue.
PROBLEM STATEMENT: Briefly summarize the given situation.
CAUSE OF BREACH: State the most fundamental reason for the breach. (Root cause)
Comments:
Potential causes of unfavorable outcome (Select those that apply):
Causes of unfavorable cost:
Causes of unfavorable schedule:
C1
S1
S2
S3
C2
C3
C4
C5
C6
C7
C8
K-16
Work is more complex
than anticipated
Design review comments
more extensive than
planned
Rework
Unfavorable market
fluctuations (labor or
material cost)
Poor planning
Unclear requirements
Scope Creep
Other
Explain
Manpower shortage
Revised Execution Plan
Supporting organizations
are behind schedule
S4
Late vendor delivery
S5
Delayed customer
feedback/direction
S6
Rework
S7
Work more complex than
anticipated
S8
Unclear requirements
S9
Scope Creep
S10
Other
Explain
Causes of unfavorable
performance:
P1
P2
P3
P4
P5
P6
Lower than anticipated
participation
Work more complex than
anticipated
Unclear requirements
Scope Creep
Defects in deliverable
Other
Explain
DHS Acquisition Instruction/Guidebook #102-01-001: Appendix K
Interim Version 1.9 November 7 2008
Sample Template and Guidance
PROGRAM IMPACT: Indicate the impact(s) of the breach on affected APB parameters (technical, cost,
schedule). Include both the effect of the actions on program interdependencies and any resulting issues or
risks; how progress will be measured/monitored in addition to Earned Value Management System; and an
updated Integrated Master Schedule and revised APB, as necessary.
Cause
Deliverable/Milestone
Impact(s)
Short and/or long term impact to deliverable and/or other segments
(i.e. functionality expansion )
Short and/or long term impact to overall investment
PM Comments:
CORRECTIVE ACTION: Indicate the actions taken to successfully remedy the breach.
Target
Corrective Action
Completion
Outcome
Date
COMMENTS/Recommendations: This section is to be used by Component /DHS HQ
Component/DHS HQ Comments/Recommendations
DHS Acquisition Instruction/Guidebook #102-01-001: Appendix K
Interim Version 1.9 November 7 2008
K-17
Sample Template and Guidance
DHS APB Review Checklist
GENERAL
1. Is the APB compliant with the format and content of the DHS guidance?
2. For programs with multiple projects, are there performance, cost, and schedule baseline data identified
for each project?
3. Is the APB structured properly to address incremental or spiral development (if applicable)?
4. Are all changes to the baseline parameters described in the revisions summary (if applicable)?
5. Are there threshold and objective values for the performance, schedule and cost parameters? (a
parameter may have a threshold value only).
6. Does the APB adequately address the whole program?
PERFORMANCE
1. Are the Key Performance Parameters (KPP) in the APB traceable to other requirements documents as
applicable (e.g., Operational Requirements Document, Mission Needs Statement, Test & Evaluation
Master Plan, etc.)?
2. Do the KPPs adequately characterize the key operational performance of the system or capability being
developed?
3. Do the KPPs sufficiently address operational, technical, and supportability requirements?
4. Are the KPPs quantifiable and measurable?
5. Do the KPPs capture the desired “critical mass” of parameters required to monitor the program/project
(too many and/or too few)?
SCHEDULE
1. Do the APB schedule parameters include the typical schedule events identified in this APB guidance?
2. Are the APB schedule parameters supported by an integrated master schedule, if applicable?
3. Are the APB schedule parameters consistent and traceable to the program’s Earned Value Management
System schedule, if applicable?
4. Are the APB schedule parameters consistent with other appropriate program documentation (Program
Management Plan, Test & Evaluation Master Plan, etc.)?
COST
1. Are costs presented in Then Year and Base Year dollars?
2. Are the APB cost parameters supported by an Independent Cost Estimate (ICE) or a Life Cycle Cost
Estimate (LCCE)?
3. Do the APB cost parameters align and consistent to the OMB 300 and FYSHP Resource Allocation Plan?
4. Are the APB cost parameters consistent and traceable with other appropriate documents (Cost Benefit
Analysis, Acquisition Plan, Program Management Plan, etc.)? If not, are the discrepancies explained?
K-18
DHS Acquisition Instruction/Guidebook #102-01-001: Appendix K
Interim Version 1.9 November 7 2008
Sample Template and Guidance
APB Relationship to Other Program Documentation
The Acquisition Program Baseline (APB) formally documents the program’s critical cost, schedule, and
performance parameters, expressed in measurable, quantitative terms, which must be met in order to
accomplish the program’s goals. The APB baseline parameters are derived and traceable to other program
documentation. This section provides information on the relationship of the APB baseline parameters to other
key documents, as available.
PERFORMANCE PARAMETERS
1.
2.
3.
4.
Mission Need Statement
Operation Requirements Document
Systems Engineering Master Plan
Test & Evaluation Master Plan
Schedule Parameters
1.
2.
3.
4.
5.
6.
Integrated Master Schedule
Earned Value Management System Schedule
Program Management Plan
Acquisition Plan
Work Breakdown Schedule
Test & Evaluation Master Plan
Cost Parameters
1.
2.
3.
4.
5.
6.
Life Cycle Cost Estimate
Independent Cost Estimate
Analysis of Alternatives
Cost Benefit Analysis
OMB 300 Submission
FYSHP Resource Allocation Plan Submission
DHS Acquisition Instruction/Guidebook #102-01-001: Appendix K
Interim Version 1.9 November 7 2008
K-19