SYSTEMS ACQUISITION MANAGEMENT
TABLE OF CONTENTS
THE DHS ACQUISITION LIFE CYCLE 2
ACQUISITION POLICY 8
SCIENCE & TECHNOLOGY 9
FUNDS MANAGEMENT 10
EARNED VALUE MANAGEMENT 21
INTEGRATED PRODUCT TEAMS 24
RISK MANAGEMENT 25
CAUSE AND EFFECT “FISHBONE” TOOL 26
SYSTEMS ENGINEERING 27
INFORMATION TECHNOLOGY 30
SOFTWARE DEVELOPMENT METHODOLOGIES 32
TEST & EVALUATION 34
LOGISTICS SUPPORT 37
MANUFACTURING AND PRODUCTION 39
THE DHS ACQUISITION LIFE CYCLE and
THE REQUIREMENTS PROCESS
The systems acquisition process exists to provide equipment, software, and services to users
so that they can keep our nation safe and secure. Requirements for capabilities arise from a
variety of sources. Within DHS, those sources include:
- Component users, who first capture capability gaps in a Preliminary Mission Needs
- The Joint Requirements Council (JRC), who look for ways to leverage the benefits
of acquisition programs across multiple DHS sponsors
- The strategic planning portion of the Planning, Programming, Budgeting and
Execution (PPBE) process, in which annual Integrated Planning Guidance (IPG)
identifies new requirements as input for the programming phase of the PPBE process
- The DHS Enterprise Architecture (EA), which can identify shortfalls in capabilities
for Information Technology (IT)
In addition to internal requirements, Congress and the President can generate requirements
to be met through the acquisition process.
As a program moves through the Acquisition Life Cycle, it flows through a series of
activities and must meet certain criteria before it can proceed to the next phase. These ‘exit
criteria’ can be general accomplishments that all programs must meet as well as specific
achievements specified by the Acquisition Decision Authority (ADA). Between each phase
of the life cycle, Acquisition Decision Events (ADEs) are conducted to ensure the program
is adequately planned, the technology is sufficiently mature, and the risks are well managed.
A typical program based on a Component-generated requirement would travel the following
Before ADE-0, users within the Component prepare a Preliminary Mission Needs
Statement (P-MNS) to identify gaps in capability. Components should consider gaps in
terms of doctrines & plans, training, material, leadership, personnel, facilities, regulations,
grants and standards (DOTMLPF+R/G/S).
At ADE-0, the Component approves the Preliminary Mission Needs Statement (P-MNS)
and sends it to the Acquisition Program Management Division (APMD) and Joint
Requirements Council (JRC) for review at DHS Headquarters. At this point, the
program has entered the Need Phase. If the program is a new start, the Component will
submit the P-MNS along with their Resource Allocation Plan (RAP) to request funds
from the Program Review Board (PRB).
The main purpose of the Need Phase is to identify a gap in capability that can be met with a
materiel solution. Three documents are prepared during the Need Phase in preparation for
The Mission Needs Statement (MNS) expands on the P-MNS to answer the
question: “What does the user need?” It summarizes in 4-8 pages the functional
capabilities that the Component must have in order to effectively accomplish their
mission and objectives. There are four steps to preparing and staffing the Mission
Needs Statement (MNS):
1. Components identify the capabilities that their users need in order to
accomplish the mission (whether or not the current capability exists).
2. Components compare their current capabilities with existing and future mission
needs to identify and prioritize any gaps.
3. Components document the results of their analysis in a MNS, expressing the
benefits of filling the gaps and the negative impact of not filling the gaps.
4. The Joint Requirements Council (JRC) and Acquisition Program Management
Division review the MNS to determine whether the need is valid.
The Joint Requirements Council (JRC) and Acquisition Program Management
Division (APMD) review the Mission Needs Statement (MNS). They look for
overlaps with other DHS initiatives and compare the MNS to the Integrated Planning
Guidance (IPG) to determine if the need is consistent with the overall strategic
direction of DHS. The MNS is approved by the Acquisition Decision Authority
(ADA) at Acquisition Decision Event 1 (ADE-1).
The Acquisition Plan (AP) indicates possible sources of goods and services
required by the user, an overview of source selection procedures, and the type of
contract(s) to be used.
The Capabilities Development Plan (CDP) is an agreement between the PM and
the Acquisition Decision Authority (ADA) about the activities, cost, schedule and
performance boundaries for the work to be done in the Analyze/Select Phase. It
identifies the possible range of alternatives to be examined and indicates whether an
Alternatives Analysis (AA) or an Analysis of Alternatives (AoA) will be used.
At ADE-1, the acquisition program can be classified into one of three levels:
Level 1 programs have life cycle costs of $1 billion or more. They are normally
overseen by the DHS Deputy Secretary or Under Secretary for Management.
Level 2 programs have life cycle costs between $300 million and $1 billion. They
are normally overseen by the Under Secretary for Management and may be
delegated to the Component Acquisition Executive (CAE).
Level 3 programs have life cycle costs under $300 million. They are normally
overseen by the Component Head.
Level 3 programs are reviewed and approved at the Component level. For Level 2 and
Level 1 programs, the MNS, Acquisition Plan, and CDP are reviewed by the Acquisition
Review Board (ARB). The ARB is supported by the Acquisition Review Team (ART),
who will review the documents, screen them for completeness, and attempt to resolve issues
before the senior ARB members conduct their review at Acquisition Decision Event 1
(ADE-1). In addition, information technology (IT) programs are reviewed by the
Enterprise Architecture Board (EAB), and vehicular and real property programs are
reviewed by the DHS Asset Review Board (DARB), before they are considered by the
ARB. The ARB is chaired by the Acquisition Decision Authority (ADA), who makes the
ultimate decision to approve the program.
The purpose of ADE-1 is to ensure that the needs are aligned with DHS strategic direction,
adequate planning has been accomplished, and sufficient resources are available for
upcoming phases. After all the reviews are complete, the Acquisition Decision Authority
(ADA) approves the MNS and signs the Acquisition Decision Memorandum (ADM),
which records his/her formal approval of the acquisition program. The ADM also
documents any program-specific exit criteria that the program must accomplish in the next
phase. When the ADA signs the ADM, the acquisition program is officially initiated and
the program moves into the Analyze/Select Phase.
The purpose of the Analyze/Select Phase is to determine the most effective and affordable
way to fill the capability gap that was identified in the MNS during the Need Phase. The
primary activity of this phase is conducting an Analysis of Alternatives (AoA) to determine
the optimal way to meet the requirement. The AoA evaluates the cost, effectiveness, and
risk of potential materiel alternatives to meet a mission requirement. For example, if
Customs and Border Protection needs a better way to maintain security and reduce
congestion at border crossings, they might consider the costs and benefits of increasing
manpower at checkpoints versus developing new vehicle screening technology.
The AoA Study Plan is prepared by the sponsor, Program Manager (PM), and the
organization who will lead the analysis. However, the AoA itself is conducted by an
independent Study Team, who identify alternatives, develop the Concept of Operations
(CONOPS) for employing the solution, conduct the analysis, and report their results.
If the user already knows the best way to meet their need, they may propose an Alternatives
Analysis (AA), instead of an AoA. For example, if the Coast Guard needs a new cutter to
patrol deep waters, the AA would look at different cutter designs rather than the full range
of sea-going vehicles. The format is similar to that of an AoA, but less extensive. The PM
proposes the use of an AA to the Acquisition Decision Authority (ADA) at ADE-1.
After the Component Acquisition Executive (CAE) approves the Study Plan, the Study
Team evaluates the operational effectiveness and life cycle cost of each alternative.
Effectiveness analysis involves assessing how well each option meets the needs described in
the Mission Needs Statement (MNS), based on a hierarchy of metrics:
Mission Tasks (MTs) are expressed as general actions to be performed by the
system. (Example: detect intruders at the border)
Measures of Effectiveness (MOEs) are objective measures of system performance.
MOEs indicate the degree to which a system performs a task under certain
conditions. (Example: number of illegal crossings). MOEs may be qualitative in
Measures of Performance (MOPs) are quantitative measures of a system
characteristic in support of a MOE. They indicate the lowest level of physical
performance or characteristic of a system. MOPs flow down to Key Performance
Parameters (KPP) in the Operational Requirements Document (ORD) and serve as
criteria for testing the system. (Example: probability of detection).
The AoA Study Team selects and applies the MOEs, MOPs, and up front them
systematically to each alternative. The team also selects and applies the appropriate cost
estimating method(s) to project the life cycle cost of each alternative. Finally, the respective
costs, benefits, and risks of each alternative are weighed to determine the optimal solution to
carry forward into the Obtain Phase. The results of the analysis and the Study Team’s
recommendation are presented to the Acquisition Decision Authority (ADA) for decision at
Acquisition Decision Event 2A (ADE-2A).
The following program documents are developed during the Analyze/Select Phase and
approved at the Component level:
Analysis of Alternatives (AoA) or Alternative Analysis (AA), discussed above.
The Concept of Operations (CONOPS) describes a proposed system from the
point of view of the individual(s) who will use, operate, and interact with it. The
CONOPS provides a framework for assessing alternatives in the context of real-
world, scenario-based, operational environments.
The Life Cycle Cost Estimate (LCCE) projects all the resources and associated
cost elements required to develop, produce, deploy, and sustain a program.
Typically, a LCCE addresses four phases: research & development, procurement &
investment, operations & support, and disposal.
The Acquisition Plan (AP) serves as a roadmap for carrying out the entire program.
across all phases of the acquisition life cycle. It documents the strategy for
managing the separate acquisitions, or contractual actions, that make up the overall
The following documents are developed during the Analyze/Select Phase and approved by
the Acquisition Decision Authority (ADA):
The Operational Requirements Document (ORD) is written by the user/sponsor to
establish minimum and desirable performance characteristics of a system. It
contains Key Performance Parameters (KPPs), identified by the user, that the
system must achieve to meet accomplish its mission. KPPs are expressed in terms of
thresholds and objectives: a threshold is the minimum acceptable level of
performance, while an objective is a goal that improves system performance, safety,
or supportability beyond the threshold value. The ORD provides a bridge between
the operational needs spelled out in the MNS and the detailed technical requirements
found in the system technical specifications.
The Acquisition Program Baseline (APB) is an agreement between the Program
Manager (PM), Component Head, and Acquisition Decision Authority (ADA) on
program cost, schedule and performance goals. Like the ORD, the APB expresses
these parameters as minimally acceptable thresholds and desired objectives.
If a program fails to meet a cost, performance or schedule threshold identified in the
APB, a condition known as a “breach” occurs. The PM cannot wait until a breach
has occurred to take action. If the PM expects that the program will not meet a
schedule or performance threshold, or if the cost threshold will be exceeded by 8%
or more, the PM must formally notify the ADA and/or DHS Headquarters of the
potential breach within 30 days, along with the cause and recommended corrective
action. Within 90 days of the breach, the program should either be back on track, be
rebaselined, or have undergone a program review. The Acquisition Decision
Authority (ADA) must assess the breach, direct corrective actions, and approve any
revisions to the APB.
The Integrated Logistics Support Plan (ILSP) lays out the PM’s plan for ensuring
the supportability and sustainability of a system. It describes the approach, schedule,
and funding requirements for integrating supportability requirements into the
systems engineering process (“designing the system for support”) and for obtaining
an integrated systems support package, such as spares, support equipment and
technical manuals (“supporting the design).”
ADE-2A marks the end of the Analyze/Select Phase, in which DHS decides which approach
will best satisfy the requirement, and the beginning of the Obtain Phase, in which the
program management team designs and develops the selected approach into an operational
The purpose of the Obtain Phase is to design, develop, test, and prepare the system for
production. Two documents are developed early in the Obtain Phase1 and approved at
Acquisition Decision Event 2B (ADE-2B):
These documents may be drafted in an earlier phase of the Acquisition Life Cycle.
The Test and Evaluation Master Plan (TEMP) formally identifies the tasks and
activities required to adequately test and evaluate the entire system. It defines test
parameters, identifies resources, and allocates responsibilities for testing the system to
ensure that it meets technical performance requirements and will be operationally
effective and suitable once it is deployed.
The Systems Engineering Life Cycle (SELC) Project Tailoring Plan documents the
development approach for the program and its projects. It describes how the proposed
development methodology aligns with the Systems Engineering Life Cycle and the
Acquisition Review Process, and it explains why that methodology is the best option
for successfully completing the project.
During the Obtain Phase, developmental testing and operational assessments/tests are
conducted in accordance with test plans, and the results are recorded in T&E Reports. In
addition, a series of technical reviews are held, such as the Preliminary Design Review
(PDR), to control technical risk as the system evolves.
Acquisition Decision Event 2B (ADE-2B) is the only acquisition event that occurs within a
phase of the Acquisition Life Cycle. At ADE-2B, the ADA will approve the TEMP and the
SELC Tailoring Plan, along with updated versions of the APB, ILSP, ORD and AP. Prior to
ADE-2B, the Acquisition Plan will be expanded to include acquisitions for all of the
projects within a program, as well as any service contracts required to support the program.
After ADE-2B, the Obtain Phase continues to support the design, development, integration,
and test of the system. Technical reviews are conducted as the system moves from one
SELC stage to the next. As the program approaches the end of the Obtain Phase, operational
tests are conducted to ensure the system is ready to enter full rate production. In addition, the
Acquisition Program Baseline (APB), Integrated Logistics Support Plan (ILSP), and Life
Cycle Cost Estimate (LCCE) are updated in preparation for Acquisition Decision Event 3
At the end of the Obtain Phase, based on successful testing and production and sustainment
reviews, ADE-3 is held. The ADA makes the production decision for the program to
advance to the Produce/Deploy/Support Phase, when the system will be produced in
quantity, deployed to the field or fleet, and then operated and maintained throughout its
The key program documents prepared and/or updated in each phase of the Acquisition Life
cycle are shown in the figure below.
Key Program Documents and the Acquisition Life Cycle
MNS ORD Update ORD Update ORD
CDP ILSP Update ILSP Update ILSP
Acq Plan Update Acq Plan Update Acq Plan
APB Update APB Update LCCE
LCCE Update LCCE
CONOPS SELC Tailoring Plan
AoA or AA TEMP
AA: Alternatives Analysis
Acq Plan: Acquisition Plan
AoA: Analysis of Alternatives
APB: Acquisition Program Baseline
CDP: Capabilities Development Plan
CONOPS: Concept of Operations
ILSP: Integrated Logistics Support Plan
LCCE: Life Cycle Cost Estimate
MNS: Mission Needs Statement
SELC Tailoring Plan: Systems Engineering Life Cycle Tailoring Plan
The systems acquisition process is guided and constrained by a variety of federal laws.
The Government Performance and Results Act (GPRA) requires federal agencies
to set strategic goals and report their progress in achieving those goals each year.
The Competition in Contracting Act (CICA) promotes full and open competition
for government business.
The Federal Acquisition Streamlining Act (FASA) makes it quicker and easier for
agencies to make small purchases of commercial products.
The Clinger-Cohen Act (CCA) requires sound management of information
technology as a capital investment.
The Federal Information Security Management Act (FISMA) imposes security
controls on information systems.
The National Environmental Policy Act (NEPA) requires PMs to evaluate the
impact of their programs on the environment.
The Anti-Deficiency Act prohibits spending or obligating funds in excess of an
appropriation or before funds have been appropriated. It also prohibits the
Government from accepting voluntary services from contractors.
The Bona Fide Needs Rule mandates that a fiscal year’s appropriations only be
obligated to meet a legitimate—or bona fide—need arising in (or sometimes before)
the fiscal year for which the appropriation was made.
The Misappropriation Act requires that funds appropriated by Congress be used
only for the programs and purposes for which the appropriation was made
Systems acquisition is also governed by Executive Branch policy:
OMB Circular A-11 requires federal agencies to submit Exhibit 300s to support
their budget requests for capital assets.
OMB Circular A-130 contains procedures for managing information systems with
an emphasis on ensuring security.
The Federal Acquisition Regulation (FAR) is the definitive guide to procurement
The primary reference for DHS acquisition policy is Acquisition Directive 102-01 and
Acquisition Instruction /Guidebook 102-01-001, which contains detailed instructions and
formats for program documents such as the MNS, AoA, CONOPs, ORD, and TEMP.
SCIENCE & TECHNOLOGY
Program Managers must determine if and when to incorporate a given technology into their
acquisition program. In general, emerging technology has the potential to provide enhanced
capability, but at greater risk than more mature and proven technology. The DHS Science
and Technology (S&T) Directorate supports acquisition programs with research,
development, and testing of new technology.
Science and technology evolve along a continuum of maturity that can be quantified along a
9-point scale of Technology Readiness Levels (TRLs):
Basic Research involves discovering new phenomena and increasing scientific
knowledge. It is often conducted at labs, universities, or research facilities where
scientific principles are observed (TRL-1), technology concepts are formulated
(TRL-2), and early experiments are conducted (TRL-3).
Applied Research analyzes basic research findings to determine the feasibility of
translating the emerging technology into a solution for broadly defined DHS
problems. Components are first built and validated in the laboratory (TRL-4) and
then validated in a relevant environment (TRL-5). Later, components are assembled
into system or subsystem prototypes that are demonstrated in a relevant environment
(TRL-6). At this point, the technology is usually considered ready for transition into
a developing acquisition program.
Advanced Technology is inserted into an acquisition program to solve a particular
problem. First a prototype of the system is demonstrated in an operational
environment, which reflects the conditions under which the system will be used in
the field (TRL-7). Then the actual system is completed and tested under realistic,
operational field conditions (TRL-8). Finally, the system is deployed in the field and
proven in actual mission operations (TRL-9). These last three TRL levels coincide
with system development.
Requirements will not be met, and technology will not be exploited, unless the necessary
resources are available. DHS uses the Planning, Programming, Budgeting, and Execution
(PPBE) process to obtain the resources needed to carry out its mission.
Cost analysis, which predicts future costs based on historical financial data, and cost
estimation, which predicts future costs based on a variety of methods, provide the
foundation for the PPBE process. Both cost analysis and cost estimation attempt to
determine the life cycle cost (LCC) of system, which is the total cost of an acquisition
program from beginning to end. A preliminary LCC estimate is developed for each
alternative considered in the Analysis of Alternatives (AoA). A complete LCC estimate is
developed in the Analyze/Select Phase to support ADE 2A, and it is updated as the program
Life Cycle Cost can be analyzed and broken out in a number of ways:
Congress appropriated funds for DHS in five major categories:
- Research and Development
- Management and Administration
- Operating Costs
- Capital Investments and Construction
- Grants and Special Funds
Within DHS, funds managers commonly break out costs into four basic categories:
- Research and Development (R&D) costs include system design, development
- Investment costs include procurement and deployment of the prime system,
along with its initial support equipment, initial spare parts, and facilities.
- Operating and Support (O&S) costs include the recurring costs of using and
maintaining a system, once it is deployed, through the entire life cycle. This is by
far the most expensive of the four categories.
- Disposal costs cover getting rid of a system after its useful life. This may entail
de-activation, detoxification, or long-term waste storage.
In addition, cost estimates can be broken into various components to facilitate comparisons
across similar systems. Some common cost components are:
Planning Cost - all costs related to obtaining the information needed to access the
costs, benefits, and risks of alternative solutions
Development Cost - the cost of all research and development activities needed to
design and test the system
Flyaway Cost (also known as rollaway or sail-away cost) - all costs related to
producing prime system equipment
System Cost – the sum of flyaway cost and the cost of associated support equipment
and services, including initial training
Procurement Cost – the sum of System Cost and the cost of initial spares
Acquisition Cost (sometimes referred to as Program Acquisition Cost) - all costs
related to the development, testing, and production of the primary system, support
items, and initial spares, as well as construction of associated facilities
In preparing a cost estimate, one of the most important decisions is which method(s) to use.
The following table summarizes four of the most commonly used methods, each with
different advantages and disadvantages. In addition, there are two methods that are often
used for estimating the cost of software development projects:
- The Top-Down Method takes a system-level view of software projects that
allocates resources to specific activities in the Work Breakdown Structure (WBS).
- The Delphi Technique uses a team of experts who exchange opinions on an
anonymous basis until they reach consensus.
Life Cycle Cost estimates are prepared in base-year dollars and later escalated to ‘then-year’
dollars to adjust for inflation.
Common Cost Estimating Methods
Analogy Parametric Engineering Actual
What 1:1 Comparison Statistical “Bottom up” Extrapolation
Single historical Analysis from actuals –
data point Same item
How Take current Cost Estimating WBS by Actual contract
system +/- Relationships component of same system
changes +/- changes
When Early ADE-1 & later ADE-2B LRIP After Full Rate
When drawings, Production
specs available Review
Advantage Fast, Easy to do Accurate Cost data exists
inexpensive, “what-if” drills Piece by piece
easy to change WBS
Disadvantage Subjective Constrained by Slow Prototype vs.
Risky data quality Labor intensive production
By holding cost as an independent variable (CAIV), cost objectives are set and held constant
while performance tradeoffs are made in the “trade space” between threshold and objective
parameters. This approach helps to ensure that a program will be accomplished within
available resources. The best time to reduce the total life cycle cost of a program is early in
the system acquisition process before development gets underway.
Cost estimates provide input to the Planning, Programming, Budgeting and Execution
System (PPBE) used to provide resources for DHS programs. The main activities and
products of the four phases of the PPBE process are as follows:
In the Planning Phase, DHS conducts strategic threat assessments to determine and
prioritize the capabilities necessary to carry out the homeland security mission. This phase
is unconstrained by resources. The ultimate product is Integrated Planning Guidance
(IPG), which is usually issued in draft form to the Components in November and signed by
the Secretary in final form in January. The IPG provides input to the Programming Phase.
In the Programming Phase, each Component prepares a Resource Allocation Plans
(RAP) to support the goals and objectives contained in the Integrated Planning Guidance
(IPG). The RAP lays out resource requirements five years into the future within projected
resource constraints. It is usually submitted in March through the Office of Program
Analysis and Evaluation (PA&E) in the Office of the Chief Financial Officer (CFO). In
May, PA&E and Budget Office analysts compare the RAPs to IPG objectives and priorities
and issue draft Resource Allocation Decisions (RAD), with their recommendations for
changes in the distribution of resources. The draft RADs are reviewed by the DHS Program
Review Board (PRB), a senior executive level panel who advise the Secretary on resource
and budget matters. The final RADs document the Secretary’s resource decisions.
Resource Decision Memoranda (RDM) promulgate those decisions, which serve as the
basis for the Budgeting Phase of the PPBE process.
In Budgeting, DHS develops detailed budget estimates to provide justification for near-
term resources to accomplish objectives. The budgeting process starts when the CFO
Budget Office issues Budget Guidance along with final RADs from the Programming
Phase. Then Components develop detailed budget estimates for the coming fiscal year to
obtain resources for the programs approved in the RADs. They also prepare Exhibit 300s to
make the business case for major capital investments and Exhibit 53s to support requests for
The CFO Budget Office and PA&E review Component budget estimates and issue draft
Program Budget Decisions (PBDs), recommending adjustments. Components can appeal the
RAD and draft PBDs before the final PBD is issued. The Program Review Board (PRB)
considers these appeals and makes recommendations to the Secretary and the Deputy
Secretary regarding funding levels to request in the President’s Budget. The DHS Secretary
signs the Program Budget Decision (PBD) to document his/her final decisions about the
budget request that will be sent to the Office of Management and Budget (OMB) as part of
the President’s Budget that is forwarded to Congress.
Key programming and budgeting decisions are recorded in a central database called the
“Future Years Homeland Security Program” (FYHSP). The FYHSP contains information
on the current year, the budget year, and up to five out-years. The database is updated four
times a year:
When the President’s Budget is submitted to Congress (January/February)
When Components submit their Resource Allocation Plans (March)
When the DHS Secretary releases the Program Budget Decision (PBD) (August)
When Congress passes the Appropriations Act (Fall)
Two funding policies influence how funds are programmed and budgeted for certain types
of programs in DHS:
The Annual Funding rule applies to appropriations that are available for obligation for
one fiscal year to cover routine expenses, such as operations, maintenance, and
personnel salaries. For these annual funds, DHS budgets only the estimated cost of
goods and services expected to be needed in a given fiscal year. An exception is
allowed for service contracts that are nonseverable or whose period of performance is
one year or less and crosses fiscal years.
The Incremental Funding rule applies to appropriations that are available for
obligation for more than one year, such as Research and Development (R&D). It
requires that the effort be budgeted in annual increments based on when costs are
expected to be incurred.
Finally, in the Execution Phase, funds are expended to carry out the mission. DHS monitors
whether funds are spent according to plan and compares actual output to planned performance.
Therefore, PMs should develop a realistic spending plan and implement it accordingly. If a
program fails to meet execution goals, or does not obligate or expend in accordance with
spending plans, the program will be in jeopardy of losing funds. Poor obligation or expenditure
performance also puts future funding at risk.
After Congress appropriates funds to DHS, and the Office of Management and Budget (OMB)
apportions the funds to DHS and its Components, and then funds are allotted to PMs for
execution within each Component. Budget execution occurs in three steps:
Commitment is an administrative reservation of funds in anticipation of a future obligation.
This internal control ensures that the proper amount of money is available for a contract
action or for transfer from one government agency to another.
Obligation is a definite commitment that creates a legal liability of the Government for the
payment of goods and services ordered. This occurs when a contract is signed by the
Contracting Officer, legally obligating the Government to pay money for products or
services to be provided.
Expenditure (or outlay) occurs when the Government disburses funds to a contractor to pay
for services or products delivered.
PMs should avoid planning new start contract awards in the first quarter of the fiscal year, since
Congress is often late passing the Appropriations Act. The second and third quarters of the fiscal
year are the best time to award new contracts.
Different categories of appropriated funds (e.g., Research & Development, Investment,
Management & Administrative) can only be used for a specified period of time, after which
those funds are considered to be expired and no longer available for new obligations.
Expired funds remain in the Treasury account (and accounting system) for five years beyond
the end of the obligation period, where they can still be used to cover expenditures and upward
adjustments of obligations properly incurred during the period of availability. Expired funds still
retain their identity, i.e., their original appropriation category, year, line-item and other
accounting information. Expired funds can only be used for payment of, or adjustments to, the
original obligations incurred during the expired period and cannot be used to incur new
The Planning, Programming, Budgeting, and Execution (PPBE) process takes place within
DHS to determine resource requirements and support requests for funding. Every year, DHS
submits a budget request to the Office of Budget and Management (OMB) to be included in
the President’s Budget. The President’s Budget is sent to Congress, when the enactment
The enactment process consists of three steps:
Concurrent Budget Resolution sets spending ceilings for the major Federal
Government functions, including Homeland Security.
Authorization establishes policy and provides permission to initiate and continue
Appropriation provides budget authority (funding) for DHS to execute its mission.
During the enactment process, House and Senate committees conduct hearings, ‘mark’ the
President’s Budget request, and meet in conference to arrive at a single version for Congress
to pass. DHS may appeal these marks prior to final Congressional action on the
Authorization and Appropriations Acts.
When Congress is unable to enact appropriations legislation by the start of the new fiscal
year), it usually passes a Continuing Resolution that enables the Government to operate but
does not allow for awarding new-start contracts.
Although Congress strictly controls the use of appropriated funds, it allows federal agencies
some flexibility through reprogramming. Reprogramming is the use of funds for purposes
other than those intended by Congress at the time originally appropriated. It applies only to
funds that have already been appropriated by Congress.
Prior approval from Congress is required to create or eliminate an acquisition program.
However, most reprogramming actions in DHS are approved at the Component level,
without the involvement of Congress, using below threshold reprogramming. Below
threshold reprogramming allows the transfer of appropriated funds among programs, within
an appropriation category, up to $5 million or ten percent of the funds, whichever is less.
Note: For more information about funds management, see MD 1330, Planning,
Programming, Budgeting and Execution.
Josephson Institute of Ethics identified six universal values or “pillars of character” that
apply to all individuals, regardless of what type of work they do:
Trustworthiness – honesty and integrity
Respect – treating people with civility and courtesy
Responsibility – competence and professionalism
Fairness – treating others consistently, without prejudice or favoritism
Caring – compassion and consideration for others
Citizenship – complying with laws and policies
If there is a conflict between ethical values, the Josephson Principled Decision Making Model
1. Consider the welfare of all stakeholders
2. Give precedence to ethical values over non-ethical values
3. Prioritize based on what will bring the most good and least harm to others
In addition, the Josephson Institute identified five ethical principles that particularly pertain
to those who work in the public service:
Public Interest – public office is not to be used for personal gain
Objective judgment – decisions should be impartial and free from conflicts of interest
Accountability – government business is to be conducted openly and equitably
Democracy – observe the spirit and the letter of the law
Respectability – avoid the appearance of impropriety
Note: For more information about ethics, see MD 0480.1, Ethics/Standards of
Systems acquisition requires close cooperation between the Program Manager (PM) and the
Contracting Officer. The PM has overall responsibility for the program and is held
accountable for delivering capability to the user, on time, and within budget. The
Contracting Officer is responsible for the business agreements needed to carry out the
program. Only the Contracting Officer has the authority to obligate the Government, enter
into a contractor, and modify a contract.
Many DHS contracts are for existing products rather than new developments. Commercial
off the shelf (COTS) products and services are customarily used for non-governmental
purposes and are offered to the general public. Non-developmental items (NDIs) are any
previously developed items that are used exclusively government purposes. Both COTS and
NDI products may be used just as they are, or they may be modified to meet unique
homeland security requirements.
The use of non-developmental items and commercial products is encouraged to reduce life
cycle costs associated with having to develop new products or systems. Use of these types
of products doesn’t completely eliminate testing and supportability issues, but it can
drastically cut development costs. The benefits of using NDI and commercial products
Quick response to operational needs
Reduced/eliminated R&D cost
Reduced technical, cost and schedule risk
Availability of product samples for source selection process
Availability of state-of-the-art technology
On the other hand, there can be drawbacks to using NDI and commercial products:
Difficulty in integrating components
Long-term logistics support problems
Lack of engineering and test data
The amount and type of testing required for an NDI or commercial item depends on how the
item will be used, whether any modifications are needed, and the availability of previous
If the item will be used in the same environment for which it was originally
designed, developmental testing is usually not necessary. However, operational
testing will be required if the item will be maintained by the Government.
If the item will be used in a different environment than that for which it was
originally designed, some developmental testing may be required to ensure the item
meets specifications or make sure the manufacturing process is effective.
Operational testing will be needed to verify effectiveness and suitability.
If the item will be integrated into a system, developmental testing will be required on
a test sample before the item is integrated into the system. Pre-production testing of
the complete system, including both hardware and software, may be conducted.
Operational testing of the complete system will also be required.
If the item will be modified, both developmental testing and operational testing will
be conducted to insure the modification meets all the requirements.
Making government unique modifications to commercial or non-developmental items may
invalidate testing and usage data. The more we modify these items, or change the way in
which they will be used, the more additional testing we will need to conduct.
The use of NDI and commercial items raises long-term supportability issues. For example,
we could face a situation where the vendor changes the product line or discontinues making
replacement parts. In addition, there may be problems with design interface and the
interoperability of parts with the overall system. Furthermore, service unique logistics
requirements may be difficult to meet with commercial and NDI products.
When deciding to use commercial or NDI items, we must determine how best to support the
system once it is fielded; i.e., whether to use organic support – using government personnel
– or to contract out logistics support. Both options have their merits and drawbacks, and
determining these can be done by taking into account the following circumstances:
How much modification is required to make the item fully operational? If
significant changes are required before the item is used by DHS, then government
(organic) logistics support might be the best approach.
How or where will the item be used? If the environment will be hostile or austere, it
could affect the contractor’s ability to support the item, and government (organic)
logistics support might be the best approach.
What is the projected service life? For short-term items, contractor logistics support
is often more appropriate.
How stable is the design or configuration? If constantly changing configurations
are inevitable, especially due to advances in technology, then contractor logistics
support is likely to be the better option.
One challenge of using COTS/NDI items is the issue of proprietary data rights. Generally, if
the Government pays for development of an item, the Government owns unlimited rights
to the associated data and can use, duplicate, or disclose that data for any purpose.
However, if a contractor developed an item entirely at their own expense, the Government is
only entitled to limited rights and cannot release the data to other parties outside the
Source selection is the process of deciding which contractor will be awarded the contract,
and it occurs every time the Government buys products or services. The Source Selection
Plan provides a road map for the source selection process, including what criteria will be
used to evaluate proposals. The Government cannot deviate from the Source Selection Plan
once the plan has been approved by the Source Selection Authority (SSA).
For a large, complex procurement, source selection team is comprised of :
- The Contracting Officer – oversees the source selection process and signs the contract
- The Source Selection Evaluation Board (SSEB) – evaluates proposals against
- The Source Selection Advisory Council (SSAC) – compares proposals against one
another and makes a recommendation to the Source Selection Authority
- The Source Selection Authority (SSA) – decides which offeror is awarded the contract
Once the contract is awarded, the contract administration phase of the contracting process
begins. The Contracting Officer conducts a post-award conference and handles the
administrative details of the contract, while the Program Management Office monitors the
contractor’s performance, usually through a Contracting Officer’s Technical Representative
Change is inevitable in an acquisition program, and contract modifications are to be
expected. There are two basic ways to modify a contract:
Supplemental Agreements are bilateral and require a signed agreement between the
Government and the contractor before the change is made. This is the preferred way to
modify a contract, since all terms and conditions are agreed to, in advance, by both
Change Orders are unilateral and do not require the contractor's concurrence. They are
used to direct the contractor to make a change within the scope of the contract when
time is of the essence. The Government Contracting Officer will definitize the change
after the work begins, and the Contractor will submit a Request for Equitable
Adjustment (REA) to the Contracting Officer if the price of the work is affected.
Sometimes the Government needs to terminate a contract before all the work has been done.
Contract terminations occur for several reasons and fall into three categories:
Termination for convenience is used unilaterally by the Government when funding
ceases or the need no longer exists.
Termination for default is used on non-commercial procurements when the contractor
fails to perform in accordance with the terms and conditions of the contract.
Termination for cause is used when a contractor fails to comply with the terms of a
contract for commercial items.
Alternative Disputes Resolution (ADR) the preferred way to resolve disputes with contractors.
It maintains the working relationship between the Government and the contractor, and it takes
less time and money to resolve differences than going to court. ADR approaches include
mediation using a third party, fact-finding using technical experts, a mini-trial using upper
management, and non-binding arbitration using a neutral third party. While ADR is generally
the preferred approach to resolve disputes, litigation is more appropriate when there is a dispute
over legal issues, fraud is suspected, or the other party is likely to present their case falsely.
EARNED VALUE MANAGEMENT
The following earned value management indicators provide insight into contractor
performance, reveal problems, and reflect trends as to whether or not a program is on track:
Schedule Variance (SV) indicates how much work has been accomplished relative to the
SV = Budgeted Cost of Work Performed minus Budgeted Cost of Work Scheduled
SV = BCWP - BCWS
Cost Variance (CV) indicates whether the work performed cost more or less than planned. CV =
Budgeted Cost of Work Performed minus Actual Cost of Work Performed
CV = BWCP - ACWP
Schedule Performance Index (SPI) is an indicator of time efficiency. It indicates how
much of the original work has been completed at any given specific point in time,
compared with what was expected to have been accomplished.
SPI = Budgeted Cost of Work Performed divided by Budgeted Cost of Work Scheduled
SPI = BCWP/BCWS
Cost Performance Index (CPI) – is an indicator of cost efficiency. It reflects how much
work is being accomplished for each dollar spent.
CPI = BCWP/ACWP
Budget at Completion (BAC) is the total authorized budget for accomplishing the
project scope of work.
BAC = Sum of all allocated budgets on a project
Percent Spent indicates how efficiently money has been spent to date
% Spent = Actual Cost of Work Performed divided by Budget at Completion
% Spent = ACWP/BAC
Percent Complete indicates percentage of the project completed to date.
% Complete = Budgeted Cost of Work Performed divided by Budget at Completion
% Complete = BCWP/BAC
These status indicators can be interpreted to tell you how well, or poorly, the program is
doing in a variety of areas, and more importantly, whether re-baselining might be necessary.
Each indicator usually has a “cut-off” value that indicates whether a program might be in
trouble, or whether it is better than expected. Here are some general conclusions that can be
drawn from these indicators:
Cost Variance (CV) – A negative value indicates that more money was spent for the
work accomplished than was planned, while a positive variance value shows efficient
use of resources.
Schedule Variance (SV) - A negative value indicated that less work was performed
than planned, while a positive variance shows that additional work was performed than
Cost Performance Index and Schedule Performance Index (CPI and SPI) – perfect
performance for a project is 1.0. Anything less than 1.0 indicates that the actual cost is
greater than the budgeted cost, or the actual schedule is behind the planned schedule. If
either index falls below 0.7, it’s serious enough that re-baselining might be necessary.
Percent Spent and Percent Complete – If the percent spent is more than the
corresponding percent completed, then the program is in trouble. Likewise, if the
percent completed is more than the percent spent, it appears the program is on the right
To Complete Performance Index [TCPI (BAC)] – This index attempts to quantify
exactly what it will take to stay within the authorized fund level for the remainder of the
project, and is correlated with the CPI to determine whether the program is on track. If
the CPI is 0.8, then that means the work must be accomplished with a TCPI (BAC) of
1.2 to make up for this inefficiency in cost. Therefore, any TCPI greater than 1.0
indicates the program is not working efficiently.
The Estimated Cost at Completion (EAC) is equal to the BAC minus the BCWP divided
by the product of the CPI and SPI. This value is then added to the ACWP to obtain the
EAC. In simpler terms:
Integrated Baseline Review (IBR)
A well-constructed Performance Measurement Baseline (PMB) is an essential first step to
effective earned value management. This time-phased budget plan is developed by the
contractor from individual control accounts to serve as the baseline against which
performance will be measured.
An Integrated Baseline Review (IBR) is conducted jointly by the Government and the
contractor to verify that the PMB covers the entire scope of work and is realistic,
measurable, and achievable. The first IBR should be held within 90 days of contract award
and must be held within 180 days after contract award. Subsequent IBRs may be held when
a major change in the program occurs.
If the established Performance Measurement Baseline (PMB) becomes unachievable, it may
become necessary to rebaseline the PMB. Typically, if both the CPI and the SPI fall at or
below 0.7, it’s a strong indication that re-baselining might be a possibility. To determine
this, an Integrated Baseline Review (IBR) needs to be held to examine the PMB to
evaluate its accuracy. Participants in an IBR typically include the government PM and
technical staff, along with the related contractor’s staff.
During an IBR, the primary factors that are evaluated include:
The technical scope of the Performance Measurement Baseline (PMB)
Program schedule requirements
Effective resource allocation to ensure that the work can be accomplished
If any one of these three requirements cannot be met, then the PMB needs to be changed to
reflect the new requirements. Changing the PMB can only be caused by any one of the
following three reasons:
- Contract changes – Only applies to contract modifications directed by the
Government, not the contractor
- Internal re-planning – Changes made by the contractor to accelerate or delay parts
of the schedule that do not affect the total cost at completion or final delivery date.
- Formal re-programming – Occurs when the remaining budget and schedule is
unrealistic, and when the PMB will exceed contract target cost.
INTEGRATED PRODUCT TEAMS
The acquisition process requires expertise and cooperation from a wide variety of business and
technical professionals. Multi-disciplinary teams known as Integrated Product Teams (IPTs) are
used to facilitate communication among developers and users, both government and contractor.
Successful IPTs invariably operate by the following tenets:
• Alignment of team with mission, vision, objectives
• Clear charter from appointing body
• Open discussions with no secrets
• Empowered, qualified team members
• Members understand their role and the process
• Dedicated, committed, and proactive participation
• Issues raised and resolved
• Leadership’s commitment and support
• Team decisions based on reaching consensus
Conversely, the following barriers make it difficult for an IPT to achieve its goals:
Lack of management commitment
Resistance to necessary cultural change
Lack of integration among functional areas
Lack of training for IPT members
Lack of communication and information sharing
Parochialism and a ‘Not Invented Here” mentality
Lack of participation by all members
Three styles of leadership are commonly used in the acquisition environment:
Supervisory leadership is characterized by directing individuals and is most appropriate
when time is of the essence.
Participative leadership involves getting input from multiple team members before the
leader makes his/her decision. This style is well suited to accomplishing a specific, well-
Team leadership strives to achieve consensus among all members of the team. This style
is best suited to complex, far-reaching efforts.
The ideal leader uses all three styles effectively, depending upon the situation.
Risk management is an essential part of planning and executing an acquisition program.
The Risk Management Model involves four steps:
Planning – the process of developing an organized and comprehensive strategy for
identifying and tracking risk areas, performing risk assessment, and delegating the proper
resources to handle that risk.
Assessment – the process used to identify and analyze circumstances and events that could
have a negative effect on program cost, schedule or performance. Assessment involves these
- Risk Identification – Processes are evaluated to document associated risk.
- Risk Analysis – Examines each area/process to further define the risk, isolate its
cause, and determine the effect.
- Risk Rating and Prioritization – Risk areas are defined in terms of likelihood of
occurrence, severity of consequence, and the relationship to other risk areas or
Handling – this phase is for identifying, evaluating, selecting, and implementing options to
minimize risk so that it doesn’t impact program parameters.
Monitoring – this final process is used to track and evaluate risk-handling measures to
ensure that the risk was properly controlled or resolved.
Potential sources of risk to homeland security programs include:
Threat – vulnerability to changing threats or countermeasures
Requirements –uncertainty of user requirements
Design – ability of the system configuration to achieve objectives
Test and Evaluation – capability of the T&E program to assess performance
Modeling and Simulation – adequacy and validity of models and simulations
Technology – maturity of current and emerging technology
Logistics – ability to affordably achieve support objectives
Production – availability and stability of manufacturing processes
Concurrency –uncertainty resulting from combining or overlapping activities
Capability of Developer – developer’s ability to design, develop and produce the system
Cost/Funding – validity of cost estimates and stability of funding sources
Management – realism and feasibility of program strategies and objectives
Schedule – can the program accomplish its goals within a reasonable time frame?
CAUSE AND EFFECT “FISHBONE” TOOL
If a risk is not effectively managed, it may eventually lead to a problem that impacts program
cost, schedule, or performance. Sometimes a problem arises for which the cause is not known.
In that case, a technique known as the cause and effect diagram or “fishbone” diagram can help
narrow down the possible causes of a problem. By identifying and analyzing all the possible
causes, the fishbone diagram focuses on determining the root cause of a problem, rather than on
alleviating symptoms or finding solutions.
The process begins with a statement of the problem in a box on the right side of the diagram--the
“head” of the fish. Then broad categories of major causes are identified and drawn to the left--
the “bones” of the fish. These major causes are broken down into all the related causal factors
that might contribute to the major causes. Finally, the causal factors are examined and narrowed
down to the most significant elements of the problem to determine the ultimate cause or causes.
Example of Fishbone Diagram
This structured brainstorming technique is used to explore all the potential causes that might
result in a single effect. Causes are arranged according to their frequency of occurrence and
level of importance, resulting in a depiction of relationships and hierarchy of events. This can
help identify areas where there may be problems and compare the relative importance of
The fishbone diagram is just the beginning of the problem-solving process. It is a tool to
structure thinking about the causes of a problem, but not to find a solution to the problem.
The Systems Engineering Life Cycle (SELC) guides the technical management of an acquisition
program through a series of nine stages. Each stage has its own entrance and exit criteria and
technical review(s) to ensure a balance of cost, schedule, and performance objectives is achieved,
and risks are managed, as the system evolves.
Stage A, Solution Engineering, supports the Analysis of Alternatives (AoA) that determines
which projects and activities will deliver the capability required in the Mission Needs Statement
(MNS). A Study Plan Review (SPR) is held to review the adequacy of the AoA Study Plan and
make sure all viable alternatives are being considered. A Solutions Engineering Review (SER)
is held at the end of the stage to review the proposed solution for effectiveness and suitability.
Stage 1, Planning Stage, validates that sufficient analysis and planning have been accomplished
to effectively carry out the program. In this stage, plans such as risk management, configuration
management, and project management are developed to guide the program through the life cycle.
A Project Planning Review (PPR) is held at the end of Stage 1 to make sure resources, activities,
and schedules are properly planned before advancing to Stage 2.
Stage 2, Requirements Definition, focuses on capturing requirements so that a system can be
designed to meet them. The Functional Requirements Document (FRD) defines performance
requirements and results in a System Specification that describes what the system should do.
The Test and Evaluation Master Plan (TEMP) is developed during this stage. At the end of
Stage 2, a System Definition Review (SDR) is conducted to approve the Functional Baseline
for the system.
Stage 3, Design, transforms the functional requirements into a design of a system that will meet
those requirements. First the Logical Design allocates performance requirements in the
Functional Baseline to hardware or software configuration items. This becomes the Allocated
Baseline, which is established at the Preliminary Design Review (PDR). Then the System
Design (or Detailed Design) expands the design down to the lowest level of detail required to
produce the solution. Requirements are allocated to configuration item components, resulting in
the Product Baseline, which is established at the Critical Design Review (CDR).
Stage 4, Development, converts the design into an actual system. Components and sub-systems
are built and tested, user documentation is prepared, and test cases are developed for the system.
A Test Readiness Review (TRR) is held to make sure all unit testing is complete and the test
environment is ready to verify the complete system.
Stage 5, Integration and Test, completes the integration of configuration items and
demonstrates, through testing, that the developed solution satisfies all defined requirements.
This stage results in a fully integrated and qualified system, to the extent that it can be verified in
a test environment that simulates the characteristics of the target operating environment. A
Production Readiness Review (PRR) is held at the end of Stage 5 to validate that the system
developed meets the requirements and it ready to move into production.
Stage 6, Implementation, transitions the system for production. In this stage, we prepare the
system, its operational environment, and end users for deployment. Training is provided, sites
are prepared, and in some cases, pilots are conducted to collect feedback on end-user
acceptability of the system. An Operational Readiness Review (ORR) is held to evaluate
whether the system, as implemented, meets the mission need and is ready to be deployed.
Stage 7, Operations and Maintenance, coincides with the Produce/Deploy/Support phase of
the Acquisition Life Cycle. The system is produced in quantity, deployed, and operated to carry
out its intended function. Usually the longest stage of the SELC, he system will continue to be
operated and maintained until disposal. A Post Implementation Review (PIR) should be
conducted within six months of deployment to assess how the new system meets requirements.
After that, an Operational Analysis should be held periodically to measure project achievement
in meeting cost, schedule, and performance goals, identify problems, and recommend ways to
improve the system.
Stage 8, Disposition, involves eliminating all or parts of a system in an orderly fashion and in
compliance with policy. A Disposition Plan is required to address all facets of archiving,
transferring, and disposing of a system and its corresponding data, including environmental and
As a system design evolves through development, integration, testing, and production, changes
can occur at any time. Configuration Management is the process that PMs and contractors use to
control change to a system. An integral part of the systems engineering process, configuration
management ensures that designs are traceable to requirements, hardware and software
components are documented, external interfaces are defined, and all changes to the system are
evaluated, approved and recorded. Configuration involves four functions:
(1) Identification describes the system in a series of technical baselines as the system is
designed and developed:
The Functional Baseline contains performance requirements for the system to be
developed. This is captured in the System Spec and Functional Requirements Document.
The Government usually maintains control of the Functional Baseline.
The Allocated Baseline assigns system functions to specific components or subsystems
of the system under development. It is captured in the Item Performance Spec and
System Requirements Document. Either the Government or the contractor can control
the Allocated Baseline.
The Product Baseline contains the as-built specifications for the system, its components
and interfaces. It’s captured in the Item Detail Spec and System Design Document. The
contractor is usually responsible for the Product Baseline.
(2) Control is exercised to ensure technical changes are properly considered, incorporated, and
documented, once a configuration baseline has been established. Contractors submit Engineering
Change Proposals (ECPs) to recommend changes to the Change Control Board (CCB), a cross-
functional group who assess the technical, cost, and schedule impacts of all proposed changes to
the system. The CCB makes recommendations to the PM on whether or not to approve each
(3) Accounting involves recording and reporting the technical information needed to manage the
configuration baseline and all changes made to it. A database is established and maintained to
track each configuration item as it evolves over time.
(4) Audits are conducted to make sure technical documents match the actual configuration of the
system. The Functional Configuration Audit (FCA) compares the prototype system to the
Functional and Allocated Baseline documents. The Physical Configuration Audit (PCA)
compares the "as built" first production representative item to the Product Baseline document.
Changes in requirements, designs, manufacturing processes, or funding can have a profound
effect on an acquisition program. External interfaces to other systems should be documented in
an Interface Control Document (ICD). For large programs, the Interface Control Working
Group (ICWG) provides a cross-functional forum for developing and managing interface
requirements. Every program should have a document manager and a data management plan
IT systems have many specific requirements that must be addressed throughout the
Systems Engineering Life Cycle (SELC). Privacy, security, and accessibility to people with
disabilities are unique concerns to IT systems that must be addressed in addition to the
general requirements for each stage.
In Stage A, Solution Engineering, the IT Portfolio Manager validates that portfolio
objectives have been captured, and the CIO ensures that all exit criteria have been met
before the program enters the Planning stage.
In Stage 1, Planning, plans are developed for data management, service reuse, and
accessibility (IAW Section 508). A Privacy Threshold Analysis is conducted to see if more
rigorous privacy protection is necessary for data to be collected by the system.
In Stage 2, Requirements Definition, a number of plans are developed to safeguard the
system and lay the foundation for obtaining security certification and accreditation. In
addition, Service Level Agreements (SLAs) are put into place to document interfaces and
enable sharing of data and other resources from one system to another.
In Stage 3, Design, the architecture is developed for the system and its data. Inter-
connection Security Agreements (ISAs) are put into place to document the exchange of data
among systems. When necessary, Technology Insertion Decision Requests are submitted
to the Enterprise Architecture Board (EAB) to ensure consistency and interoperability of
systems across DHS. Verification and validation (V&V) of the design is performed to ensure
that the design meets requirements. The Privacy Impact Assessment (PIA) and the System
of Records Notice (SORN) are prepared to safeguard the privacy of individuals on whom
records may be processed by the system.
In Stage 4, Development, a Version Description Document (VDD) is prepared to describe
the hardware and software configurations of the initial release of the system. Test cases
are developed in preparation for testing to be conducted in the subsequent stage.
In Stage 5, Integration and Test, privacy documents (PIA and SORN) are completed and
approved to ensure that all privacy compliance requirements have been met. Section 508
test results are evaluated to ensure that persons with disabilities have access to the system.
A Service Insertion Package (SIP) is submitted to the EAB to update the Homeland Security
In Stage 6, Implementation, hardware, software, and communications are deployed to
operational sites. Data from legacy systems is uploaded as necessary. The SORN is
published in the Federal Register, security testing is completed, and the Designated
Accrediting Authority (DAA) issues an Authority to Operate (ATO) letter.
In Stage 7, Operations and Maintenance, periodic reviews are held to monitor
performance and identify problems. Security and accessibility are checked on a continuing
In Stage 8, Disposition, a Disposition Plan is prepared to make arrangements for
archiving, transferring, or disposing of the system and its data.
Here is how the SELC aligns with the Acquisition Life
SOFTWARE DEVELOPMENT METHODOLOGIES
Here are three commonly used methodologies for developing software for DHS systems,
each with its own advantages and disadvantages.
Method: Waterfall Incremental Spiral
Advantages: - Cost estimates tend to be - Usable product is provided - Provides better risk
more accurate with first release; each cycle management than
- Schedule estimates tend to delivers functionality other methods
be more accurate - Can be stopped any time after - Requirements are
the first cycle to deliver a better defined
working product - System is more
- Allows for some addition or responsive to user
modification requirements needs
Disadvantages: - Working product is not - Majority of requirements - More complex and
available until late in project must be known at beginning harder to manage
- Progress & success are not - Interfaces must be well - Usually increases
observable until later stages defined at outset development costs
- Errors or deficiencies may - Formal reviews are more - Usually extends the
not be discovered until complex than for a single schedule
implementation stage development effort
- Corrections are not made - Cost and schedule overruns
until the maintenance stage may result in an unfinished
- More frequent impact to
operations with multiple
Best Applies When: - Risk is low - Risk is low to medium - Risk is high
- Requirements are well - Requirements are stable at - Requirements must
understood at the start the beginning be refined
- Requirements are not - Project funding is uncertain,
expected to change as each cycle produces a
Project Tailoring Plan
Regardless of which method is chosen, an approved Project Tailoring Plan must be prepared to
justify the choice of development methodology. This plan documents the development approach
for the program/project and is required as an entry criterion to the Planning Stage of the SELC.
The Project Tailoring Plan must describe how the proposed development methodology aligns
with the SELC and Acquisition Review Process and why it is the best option for successfully
completing the project.
A particular challenge for IT system is interoperability, which is the ability of systems to provide
services or data to, and accept services or data from, other systems. Interoperability requirements
should first be outlined in the Mission Needs Statement (MNS) and the ORD. Then all external
and internal interfaces need to be defined in system-level requirements as part of the design
process. These interfaces must be agreed upon and individually tested through the use of actual
live systems in developmental tests and operational tests.
Test and evaluation (T&E) ensures that acquired systems meet performance parameters and can
be operated and maintained effectively to accomplish the mission. Considerable planning and
resources are involved in testing the system, both before and after development. The Test and
Evaluation Master Plan (TEMP) documents the test approach, schedule of events, and resource
requirements. It supports the development decision at ADE-2B. T&E results support the
production, deployment and support decision at ADE-3.
Multiple DHS organizations and players are involved in T&E. Some of the key players are:
DHS Undersecretary for Science and Technology establishes T&E policy and
processes for DHS acquisitions via the Director, DHS Test and Evaluation Standards
Director of Operational Test and Evaluation (DOT&E) administers DHS T&E policy
and processes and provides independent reports on the T&E of acquisitions to the
Acquisition Review Board (ARB).
The Component Acquisition Executive (CAE) approves the TEMP and reviews
0perational T&E results.
The Operational Test Agent (OTA) plans, conducts, and reports independent
operational T&E of Level 1 and other selected DHS programs. Operational tests are
carried out by typical trained operators and maintainers using production-representative
articles in a representative environment. The OTA must be independent of the developer
of the system.
Modeling and Simulation
During system development, Modeling and Simulation (M&S) can be used to supplement T&E
and provide insight into system performance without physically constructing the system. M&S
can help developers better understand the relationships among subsystems and evaluate the
expected outcomes of technical decisions. This management tool can reduce program costs,
schedule slips, and technical risk by revealing weaknesses during the early stages of design.
M&S can reduce the amount of testing required, but it can never replace it entirely. Moreover,
while this tool can be used to reduce technical risk, it also introduces the risk that models do not
accurately reflect the system or portray the relevant environmental conditions. M&S requires
resources, and it takes effort to verify and validate models and refine them as the system evolves.
Types of Test and Evaluation
There are two basic types of test and evaluation: Developmental T&E and Operational T&E:
Developmental Test & Evaluation (DT&E) supports the systems development process by
verifying that the system attains the Critical Technical Parameters (CTPs) in the contract
specification and the Operational Requirements Document (ORD). It is normally conducted by
the contractor in a highly controlled environment.
Production Qualification Testing (PQT) verifies the effectiveness and efficiency of the
Production Acceptance Testing (PAT) evaluates the function of sample items as they are
Operational Test & Evaluation (OT&E) verifies that the system works in its intended
operational environment. It is conducted by users, under realistic conditions in the field, to
address Critical Operational Issues (COIs) that determine the system’s:
Operational effectiveness--the ability of a system to accomplish a mission
Operational Suitability--the degree to which a system is deployable and sustainable in
the field or at sea. This takes into account logistics support considerations such as
maintainability of equipment and training of operators.
Independent Operational Test and Evaluation is conducted on production representative articles,
typically manufactured during Low Rate Initial Production (LRIP). However, it is wise to
involve the operational testers earlier in the life cycle. Operational Assessments (OAs) are
evaluations of operational effectiveness and suitability by the Operational Test Agent prior to
production in order to get an early look at the system in development.
Combined DT&E and OT&E testing, which a single test is used to support both types of testing,
can save time and money. However, it requires extensive coordination, and it is difficult to
design one test to satisfy both DT&E and OT&E objectives.
Note: For more information about testing and evaluation, see MD 026-06, Test and Evaluation.
One of the many factors that must be considered in the design of a system is how that system
will ultimately be supported in the field. Supportability, the ability of a system to be ready and
operational at an affordable cost throughout the system’s life--is a function of system design. A
supportable system is designed for reliability, maintainability, and availability, with concern for
human factors to facilitate operation and maintenance.
Reliability indicates how long a system will work before it fails. It is measured in Mean Time
Between Failure (MTBF), the number of hours a component or sub-system will operate on the
average before a failure occurs. MTBF is calculated by dividing the total number of hours the
system is operated by the total number of failures experienced during that time.
Maintainability indicates the ability of a system to be kept in, or returned to, working condition
by skilled personnel. It is measured in Mean Time to Repair (MTTR), the average number of
hours that are required to repair a component or sub-system. MTTR is calculated by dividing
the total elapsed time for maintenance by the total number of repairs completed during that time
Availability indicates the probability that a system will be ready and able to operate when
needed. It is expressed as the ratio of system up time over the sum of system up time plus
Supportability is the foundation of mission system readiness. Reliability, Maintainability and
Supportability (RMS) goals, established early in the acquisition life cycle, should emphasize
both higher operational effectiveness and lower life cycle costs.
Performance-Based Logistics is a strategy for buying integrated system support using long-
term agreements based on achieving performance outcomes. It provides system reliability and
operability at lower life cycle costs than traditional approaches. The four primary tenets of PBL
(1) Document requirements as desired outcomes in performance-based agreements
(2) Designate a single product support integrator to be accountable for system support
(3) Use long-term contracts to foster trust between the Government and the contractor
(4) Provide incentives based on metrics to motivate the contractor and ensure that
performance objectives are met
The PM should implement PBL in four phases using a 12-step process:
Foundation Phase: The PM works with the user to integrate support requirements, form a PBL
team, and baseline the new system in terms of scope, cost and performance objectives
Planning Phase: The PBL team develops performance outcomes, selects a product support
integrator, develops a strategy to allocate workload for all the logistics support elements, and
determines a strategy for supply chain management
Execution Phase: The team develops performance-based agreements, conducts a business case
analysis, and awards contracts
Control Phase: they identify sources of long-term funding and monitor and assess
Deployment is the fielding of a system by placing it into operational use in the field or fleet.
Deployment begins with Initial Operational Capability (IOC), when the first unit receives a
system along with the capability (personnel, spare parts, supplies, etc.) to operate and maintain it.
It continues until Full Operational Capability (FOC), when all units are fully equipped. For
software, IOC occurs when the minimum capability necessary to field the application is
achieved, and FOC occurs when the application provides capability to satisfy all validated user
requirements. The details of IOC and FOC for a particular system are specified in the
Operational Requirements Document (ORD).
The success of deployment is directly related to how well the deployment was planned.
Deployment planning begins in the Analyze/Select Phase of the Acquisition Life Cycle, when
program logisticians draft logistics input for the Acquisition Plan. The Deployment Plan is
prepared early in the Obtain Phase and updated as necessary.
Sustainment is the ongoing process of providing support throughout the operational life of a
system after it has been deployed. This includes delivering all the logistics support elements
needed to keep the system operating and ensuring that a system continues to meet reliability,
availability, and maintainability (RAM) requirements.
Systems must be planned, designed, and developed with supportability and sustainability in mind.
Supportability is the inherent quality of a system that facilitates detection, isolation, and
timely repair or replacement of system anomalies. It’s a function of the system design. A
supportable system is easy to operate and access, detect, and repair or replace worn or broken
Sustainability is the ability to maintain the necessary level and duration of operation to
accomplish the mission. It’s a function of the level of personnel, materiel, and consumables
that are ready and able to support operations in the field.
The Integrated Logistics Support Plan (ILSP) describes the management approach for
obtaining a supportable system with an affordable and effective support structure. It lays out
the PM’s strategy, schedule, and funding requirements for:
Designing the system for support--integrating supportability requirements into the
systems engineering process, and
Supporting the design--developing/obtaining an integrated systems support package for
sustainability, e.g., spares, support equipment, tech manuals, etc.
The Program Manager first prepares the ILSP during the Analyze/Select Phase, soon after the
ORD and AoA are approved. The Component reviews the ILSP before it’s formally submitted
to the Acquisition Decision Authority (ADA) for approval at ADE-2A.
MANUFACTURING AND PRODUCTION
Production concerns must be considered throughout the systems acquisition process. This
involves three steps:
Step 1: Influence the Design Process deals with creating a producible design—one that will be
easy and economical to produce--by accomplishing five goals:
Design for Ease of Fabrication
Design for Ease of Assembly
Design for Multiuse
Minimize Number of Parts
Maximize Number of Common Parts
Sometimes these goals are mutually exclusive, requiring tradeoffs to achieve the optimal design.
Step 2: Prepare for Production involves five elements (5 “Ms”) of manufacturing to transform
raw materials into finished products:
Step 3: Execute Manufacturing involves carrying out and monitoring the manufacturing
process to produce uniform, defect-free products, with consistent performance, at an affordable
Lean manufacturing is a common management approach for efficient operations. It involves
two main principles that complement one another:
- Minimize waste (from inefficient layouts, defective equipment, unnecessary paperwork ,
- Respond to change (such as new requirements) by using new technology or by training
workers in a number of different skills so that they are able to work on alternate areas.
Methods for achieving consistent high quality and stable production include:
- Process proofing - verifying that the production process is optimized before production
- Reducing variability – using statistical process control (SPC) to identify, track, and
eliminate the causes of variability in key processes. SPC uses upper and lower control
limits to determine if the manufacturing process is changing or consistent and predictable
Variation can be attributed to two types of causes:
- Common cause variation is due to routine fluctuations
- Special cause variation is triggered by a unique event
For every product, there is an optimal process structure that can be used to produce it.
Manufacturing products and processes can be classified along a continuum. Products are
classified based on standardization of parts, and processes are classified on volume of production
flow. On one end are high volume, continuous flow processes that generate a large number of
standard items, like bullets produced in an assembly line. Continuous flow processes use
common materials and standard methods. At the other end of the continuum are jumbled flow
processes that produce a single, one-of-a kind item, such as a satellite. Jumbled flow processes
require specialized material and flexible production methods. The manufacturer will determine
what resources and procedures are needed to most effectively produce the end product.
Production costs tend to be a significant portion of the life cycle cost of a program. All five
elements of manufacturing (manpower, machinery, material, methods, measurement) contribute
to the cost of production.
It is not enough to combine the “5Ms” to produce a finished product; steps must be taken to
ensure that products are free of defects:
Prevention – avoiding problems in the first place through process proofing.
Appraisal – looking for errors through testing and inspection.
Failure Correction – fixing errors; rework and repair.
In general, about half of the costs of quality assurance should be directed towards prevention of
problems. About one third of the costs should focus on looking for errors. Only fifteen per cent
of quality assurance costs should be spent on correcting errors.
The learning curve can lower manufacturing costs under certain conditions. The theory states
that as production quantity doubles, the cost per unit decreases at a constant rate. Learning
theory applies when the manufacturing process is uninterrupted and manpower intensive (rather
than highly automated), the product design is complex and stable, personnel turnover is low, and
management encourages workers to make process improvements. This knowledge is useful for
projecting costs both before and after production begins.