1. 8 Tech Processes Drive Acquisition
Although the tool was developed with Department of Defense program office engineers and program managers in mind, anyone with an interest in a deeper understanding of acquisition should benefit. So, let’s get started…
This process planning tool is a click-through animated presentation designed to help you better understand and plan for the defense acquisition process using the systems engineering V model.

2. Stakeholder Requirements Definition Requirements Analysis
Realization
Decomposition
The defense acquisition process was not designed for the success of any one program. You and your program office team will need to tailor the process for the success of your program as part of your technical approach documented in your Systems Engineering Plan, your Acquisition Strategy, and the Acquisition Decision Memorandums that you draft for approval by your acquisition boss, the Milestone Decision Authority.
For example, just because a fabulous prototype was developed in somebody’s garage does not mean our industry partner is ready to produce the number of systems we require.
In a traceability analysis, we crosswalk the functions back to the requirements, ensuring that every requirement is met by at least one function and that every function meets at least one requirement.
The validated Capability Development Document guides the Development effort in the Engineering and Manufacturing Development phase.
We crosswalk the architecture back to the functions to ensure that the functions are met by at least one architecture component and that each component meets at least one function.
This model is used iteratively and recursively; over and over and with increasing detail as we move through the acquisition lifecycle. Although not always used sequentially, the technical processes in the model can give us a big picture understanding of the defense acquisition process as a whole.
At this decision point, the stakeholders come together to agree on the requirements and lock them down, to the greatest extent possible.
During the Preliminary Design Review, we accept the Allocated Baseline with the Item Performance Specifications.
These reviews focus on verification, determining whether we built the system and the configuration items to meet the specifications:
Did we build it right?
During the System Functional Review, we accept the Functional Baseline with the System Performance Specifications.
However, you should remember that users often want changes made and may break stuff during IOT&E.
Your Milestone Decision Authority will review and authorize release of your RFP at the Development Request for Proposal Release Decision.
Early Operational Assessments conducted by the user on TMRR prototypes are important for gathering user feedback.
The eight technical processes of the systems engineering V start with Stakeholder Requirements Definition.
There are a number of reviews that support the upcoming Milestone C decision.
As much as we would like to believe that they will match up perfectly, this is rarely the case. Change the documentation to match the as-built system approved in IOT&E to ensure that the Technical Data Package is accurate and complete.
The System Verification Review and the Functional Configuration Audit are often conducted together.
Stakeholder Requirements Definition
Capability Gap, Constraints, Threats, Design Considerations
Needs
System Requirements Review
Validation will also occur as Operational Assessments during EMD.
Solutions
Validation asks, “Did we build the right thing?”
Shortened cycle times help to decrease requirements and funding instability, so consider suggesting the use of incremental acquisition as the basis for the strategy outlined in the Capability Development Document. It is certainly easier to keep requirements and funding relatively stable over 4 to 5 years, than a year period. With incremental acquisition, you will plan to deliver relatively mature technology that gives the warfighter more capability than they have today in a supportable Increment 1 system, while simultaneously maturing technologies for future increments.
With valid requirements and reduced risk (thanks to our competitive prototyping effort), we develop our Request For Proposal. Down selecting from two industry partners to one for the Engineering and Manufacturing Development (EMD) phase could commit the government to a very long-term relationship with this one industry partner.
Initial Operational Capability
Transition
Crosswalk
Functions to Requirements
In defense acquisition, complex problems require comprehensive solutions. Acquisition is driven by the technological approach selected by the program office for addressing a capability gap identified by the user.
You need to clearly define the capability gap that needs to be addressed, as well as any constraints and limitations, threats, and additional design considerations.
Physical Configuration Audit
Requirements Analysis
Functional Breakdown
For example, this is a graphical representation of an Acquisition Strategy tailored for a hardware intensive acquisition. This model is one of six models you can use to start tailoring the acquisition process for your program. In this example, we have tailored the hardware intensive model appropriately to start with analysis of the materiel solutions available to address the capability gap expressed in the Initial Capabilities Document.
System Functional Review
-Functional Baseline
-System Performance Specifications
The complexities involved in running a successful program require a diverse team of acquisition professionals communicating, collaborating, and cooperating to provide the warfighter with the capabilities needed to meet their mission requirements.
we are ready to help the user refine the requirements in the updated Capability Development Document, which will guide our efforts in the Production and Deployment phase and on into Operations and Support.
Then, the system is transitioned to the next level, whether that be the system to system-of-systems or the system to the field or fleet.
Initial Operational Test & Evaluation
Your first technical review is the System Requirements Review, which aligns with the first technical process in our model: Stakeholder Requirements Definition. During this review, you want the contractor to tell you what your requirements are to ensure that you are all on the same sheet of music.
Validation
Operational Testing
The defense acquisition process, as described in Department of Defense Instruction , provides the rules of our acquisition game. You need to understand the rules to play the game well!
Once we have reduced the risk to an acceptable level and can commit to meeting the requirements, it’s time for Capability Development Document Validation, or CDD-V.
Once the user determines that a capability gap exists and that a materiel solution is the only way to address the requirement, an Initial Capabilities Document is released and guides early acquisition.
Verification asks, “Did we build it right?”
Work with users to DRAFT a program specific Capability Development Document, which defines the system’s Key Performance Parameters, Key Systems Attributes, and Additional Performance Attributes.
The acquisition process begins with the Materiel Development Decision. If the Milestone Decision Authority concurs that a materiel solution is required, a program office is established. Remember, the acquisition process was not designed for the success of any one program, so it must be tailored for the success of your program!
Once we understand the requirements, we need to do good requirements analysis to determine the functions that the system has to do to meet the requirements and then break those functions down into subfunctions.
The primary work effort in TMRR is competitive prototyping to mature the critical technologies to an acceptable level of risk, which means that we need to demonstrate the critical technologies in a relevant environment prior to Milestone B.
These requirements will not be locked down until the critical technologies are matured to an acceptable level of risk during TMRR. The Draft CDD will guide acquisition efforts early in the TMRR phase.
Tailor the competitive prototyping effort appropriately to meet the needs of your program. You are just maturing the critical technologies, so you may not need to do full-up systems prototypes.
The eight technical processes that make up the Systems Engineering V model take us from needs to solutions, which drives our technological approach.
Crosswalk
Architecture to Functions
The third technical review in TMRR is the Preliminary Design Review, which aligns with the Architecture Design process of our model in which we allocate physical architecture against the functions.
DRFPRD is considered one of the most important decision points, since the quality of the contracting effort will have a significant impact on the program outcome.
and to start transitioning our system to the field or the fleet to meet Initial Operational Capability. The Operations and Sustainment effort in the Operations and Support phase begins as soon as we have systems deployed.
So, any articles built during LRIP will likely need to be fixed. Plan to produce at least enough articles for test and Initial Operational Capability, which is also defined in the Capability Development Document.
You need Operations and Maintenance funding in your budget prior to Initial Operational Capability and throughout O&S for upgrades and modernization efforts.
You need procurement funding for whole end items and initial spares throughout production and for upgrade or modernization kits in O&S.
You would not play a game without first learning the rules, it is much the same here.
We will, therefore, award multiple cost plus type contracts for prototypes. I consider this like glasses of wine; 3 is too many and 1 is too few.
Your team needs to consider effectiveness and suitability; security and interoperability; and affordability and producibility for each of the alternatives analyzed. You need to identify the critical technologies to be matured in the next phase.
Then, we integrate components to subsystems; subsystems to system; system to system of systems.
In Validation, we determine whether we built the right thing; that our system meets the users’ requirements.
Include all stakeholders in early planning, as you consider how well the available alternatives address the complexities of requirements decomposition to solution realization.
System Verification Review
Functional Configuration Audit
The major validation effort is the Initial Operational Test and Evaluation conducted with production articles.
Now that industry partners have joined your team, let’s start walking through the Systems Engineering V Model.
We will review the alternative systems and select the recommended concept or concepts to take forward into the Technology Maturation and Risk Reduction phase. This is done in support of the upcoming Milestone A decision.
PDR is usually our downselect point for competitive prototyping going into source selection for the development contract.
You will need Research Development Test and Evaluation funds from program initiation through Initial Operational Test and Evaluation.
Once a successful Milestone A decision is reached, we proceed into the Technology Maturation and Risk Reduction phase.
The next technical review is the System Functional Review, which aligns with the Requirements Analysis process in our model.
Architecture Design Allocation of Physical Architecture
Preliminary Design Review
-Allocated Baseline
-Item Performance Specifications
Verification
Developmental Testing
We typically award a fixed price study contract or two to assist in this effort.
In requirements analysis we break the requirements down into functions and the functions into subfunctions.
A successful Milestone B decision requires that the program be fully funded, have validated user requirements, and that the critical technologies have been demonstrated in a relevant environment.
In implementation, we start detailed design and determine the components to be used: commercial or government off the shelf, new development, or reuse.
Once we’ve completed the AOA, we will conduct an Alternative Systems Review.
Work closely with your contracting officer to determine the best contract types to use throughout the lifecycle for your program.
It is a best practice to combine developmental testing and operational tests, EOAs and OAs, where possible.
Once a successful Milestone C production decision is reached, a fixed-price incentive type base contract for Low Rate Initial Production with Firm Fixed Price option years for full rate production may be awarded.
So, our first phase is Materiel Solution Analysis.
The primary work effort in Materiel Solution Analysis is the Analysis of Alternatives.
Site surveys at the production facilities to determine readiness are a best practice. An Independent Logistics Assessment is also conducted to confirm that the system is supportable.
This is typically the 90% solution, as we still need to demonstrate through developmental testing that our system is capable, affordable, supportable, interoperable, and producible.
Lastly, you can’t do anything without money. Work closely with your Financial Manager to establish and manage your budget.
Although source selection is done prior to Milestone B, the EMD contract is not awarded until after a successful Milestone B development decision.
We can then allocate physical architecture against those functions in Architecture Design.
The competitive prototyping test data reviewed at PDR supports source selection and the Milestone B decision to continue into detailed design in Engineering and Manufacturing Development as a program of record.
Just remember, you are showing the user the baby when it’s ugly! So, be sure to manage the expectations of your users at Early Operational Assessments.
In Verification, we determine whether we built the system right; whether we built it to the specifications.
Now that we have demonstrated that the system is capable, affordable, supportable, interoperable, and producible,…
Developmental testing started as soon as there was something to test.
Once we have produced and deployed all systems required in the Capability Development Document, we will have reached Full Operational Capability and the end of the Production and Deployment phase.
Critical Design Review
-Product Baseline
-Detailed Item Specifications
Please, look for other DAU tools to learn more about the Defense Acquisition Process.
Although we may conduct many subsystem Critical Design Reviews, the system-level Critical Design Review (CDR) will establish…
During TMRR, we matured the critical technologies. In EMD, we will complete detailed design…
The program office is responsible for the system until disposal of the system.
The Production Readiness Review is also conducted to ensure that the system is ready to go into production.
Your Operational Test Agency will conduct the IOT&E, testing effectiveness and suitability to ensure that our system meets the users requirements. Did we built the right thing?
and integrate components to subsystems and subsystems to system.
Once IOT&E is successfully completed, conduct the Physical Configuration Audit to compare the as-built system that the user is happy with to the product baseline documentation.
Integration
Components to subsystems, subsystems to system
the initial product baseline with the detailed item specifications.
Once you have deployed systems, you will have lots of data detailing how well the system is meeting the users’ requirements in the field. Conduct regular In Service Reviews in the Operations and Support phase to correct deficiencies and prioritize required upgrade and modernization efforts to ensure that the capabilities provided by the system continue to meet user requirements throughout the life of the system.
With a successful IOT&E, we are ready for the full rate production decision…
Implementation
Components Selection
Technology Maturation and Risk Reduction
System Requirements Review
System Functional Review
Preliminary Design Review
Competitive Prototyping
2 TMRR Contracts
Cost Plus
Capabilities Development
Document
Critical Technology Developmental Testing
Early Operational Assessment
Development Request for Proposal Release
Decision
Capabilities Development Document Validation
Milestone A
During Low Rate Initial Production, you may choose to produce up to 10% of the Full Operational Capability production numbers provided in the Capability Development Document. You need justification if you want to go above 10%.
Materiel Solution Analysis
Analysis of Alternatives
Alternative Systems Review
Study Contract
Fixed Price
Initial Capabilities Document
Draft Capabilities Development
Document
Materiel Development Decision
Engineering and Manufacturing Development
Implementation & Integration
Critical Design Review
Demonstration
Contract
Fixed Price Incentive
Capabilities Development
Document
Developmental Testing
Subsystem Level
System Level Developmental Testing
Operational Assessment
Milestone B
System Verification Review/
Production Readiness Review
Functional Configuration Audit
Production and Deployment
Operations and Support
Low Rate Initial Production
Full Rate Production
Operational
Initial
Capability
Full
Operations and Sustainment
In Service Reviews
Contract
FFP Options
FPIF Base
Initial Operational Test & Evaluation
Physical Configuration Audit
Full Rate Production Decision
Disposal
Milestone C
Research Development Test and Evaluation Funding
Procurement Funding
Operations and Maintenance Funding