2.8. Technology Development Strategy/Acquisition Strategy (TDS/AS) Outline
This guideline is intended as just that, a guideline. While it attempts to shed light on all relevant strategic business aspects of a program, it may fail to solicit information a Program Manager (PM) feels is vital to their chain-of-command. Therefore, PMs are empowered to add where necessary. Adherence to the spirit in which this guideline was crafted should yield a document that provides insight into the PM’s thoughts and thought processes.
As directed in the April 20, 2011 Principal Deputy Under Secretary of Defense (Acquisition, Technology, and Logistics) memorandum “Document Streamlining — Program Strategies and Systems Engineering Plan,” the structure for the body of a Program Strategy document follows. Each program strategy should also include a title page, signature/approval page, and a table of contents. The primary sections included in the body of the outline are:
- Purpose
- Capability Need
- Acquisition Approach
- Tailoring
- Program Schedule
- Risk and Risk Management
- Business Strategy
- Resources
- International Involvement
- Industrial Capability & Manufacturing Readiness
- Life-cycle Signature Support
- Military Equipment Valuation
Detail on expected content for each of these topics is described in the following sections.
2.8.1. Purpose
State the reason the program strategy (i.e., the Technology Development Strategy or the Acquisition Strategy) is being prepared or updated (e.g., milestone review, full rate production decision, change in strategy, etc.).
2.8.2. Capability Need
Summarize the requirement. Indicate the key operational and sustainment requirements for this system (i.e., the time-phased capability requirements as described in the Initial Capabilities Document, Capability Development Document, Capability Production Document, Requirements Definition Package, and/or Capability Drop). Highlight system characteristics driven by interoperability and/or joint integrated architectures, capability areas, and family- or system-of-systems.
Summarize the expected operational mission of this program. Identify the user and summarize the user‘s Concept of Operations (CONOPS). Indicate how the program fits into current and future integrated architectures.
Summarize the threat assessment in relation to the capabilities or operational concepts the system will support (see the applicable System Threat Assessment document for details). Specify which elements of the threat (if any) are not yet fully defined, and which elements of the threat (if any) will not currently be countered by the system capabilities or CONOPS. Include a projected plan/schedule to define and counter the remaining threat elements.
If TDS, also summarize the Net-Centric Data Strategy. [Starting with Milestone B, the Net-Centric Data Strategy is included in the Information Support Plan.]
|
CONSIDERATIONS
When summarizing the threat, consider the following:
- Summarize the threat concisely while addressing it from the perspective of the capability areas and gaps in the validated capability document, including CONOPS considerations.
- Threat elements that are not yet fully defined should be specified referencing scenario, timeframe and foreign systems. The timeline for defining these threats needs to be provided by the Service’s Intelligence Production Center in concert with the Defense Intelligence Agency.
- Threat elements which will not currently be countered or that should be watched for foreign capability increases need to be identified as Critical Intelligence Parameters (CIPs) in the System Threat Assessment document, an should be highlighted here in the AS/TDS.
- The projected plan/schedule to counter remaining threats needs to be addressed in terms of evolutionary acquisition increments, if applicable for the specific program—and should also be discussed in the Program Strategies Section 6.6 concerning risks deferred.
|
|
NOTES
- In most cases, this section of the Technology Development Strategy (TDS) or (Acquisition Strategy (AS) should be classified and presented as a separate annex to the unclassified document. The classified annex should be emailed via the SIPRnet to the Milestone Decision Authority (MDA)’s office of primary responsibility (OPR) for TDS/AS documents.
- a. OUSD(AT&L/ARA/AM) is the OPR recipient for programs in which the DAE is the MDA and will distribute this section to OUSD(I), the OIPT leader organization, OSD Systems Engineering, OSD Developmental Test & Evaluation, Office of Operational Test & Evaluation, the Joint Staff J8 and any other OSD parties requesting and appropriately cleared with need to know.
- b. A classified repository capability is anticipated to be set up by the end of FY 2012 that can replace this SIPRNET email process. If this section cannot be written at a level of SECRET (or below) then alternative means will have to be negotiated with the TDS/AS OPR.
- The Program Management Office should work closely with their intelligence community colleagues in the Service Production Center(s) and Component staff intelligence organizations in order to complete this section of the TDS/AS template.
- In this context, the term “threat” refers to the foreign systems and capabilities of a potential adversary in the context of military conflict; it does not include the foreign collection threat that needs to be addressed via the program protection planning process. This threat section is also not relevant to intelligence mission data or signatures data that is needed from the intelligence community for signature dependent systems – this information is to be addressed in the Life-cycle Signature Support Plan and in summary later in this TDS/AS Outline.
|
Include an Operational View (OV)-1 Illustration. (See example in Figure 1, below.)
Figure 1. Example OV-1 Illustration
|
NOTES
- The purpose of the OV-1 is to provide a quick, high-level description of what the architecture is supposed to do, and how it is supposed to do it.
- In general the OV-1 describes the business activities or missions, high-level operations, organizations, and geographical distribution of assets. The model frames the operational concept (what happens, who does what, in what order, to accomplish what goal) and highlight interactions to the environment and other external systems.
- A textual description accompanying the graphic is crucial. Graphics alone are not sufficient for capturing the necessary architectural data.
|
For Milestone B, provide a reference design concept for the product showing major subsystems and features (one or more drawings as needed to describe or illustrate the expected features of the product; see the example in Figure 2).
Figure 2. Sample Drawing of the Reference Design Concept
2.8.3. Acquisition Approach
Indicate whether the program strategy will be evolutionary or single step to full capability and rationale for selection. Note: If this program employs an evolutionary acquisition approach, this strategy will primarily apply to the current increment, while occasionally addressing some topics in the context of the overall program.
If this program employs an evolutionary acquisition approach, summarize the cost, schedule, and performance drivers for the increment under consideration, and the plan to transition from the initial increment to later increments.
|
NOTES
The cost, schedule and performance drivers summarized here should align with the cost, schedule and performance parameters in the acquisition program baseline.
An evolutionary approach delivers capability in increments, recognizing, up front, the need for future capability improvements. If this program strategy is for an evolutionary approach, each increment must be a militarily useful and supportable operational capability that can be developed, produced, deployed, and sustained.
Each increment must be traceable back to an approved requirements document and have its own set of threshold and objective values. Each program or increment shall have an Acquisition Program Baseline establishing program goals.
Department of Defense Instruction 5000.02 requires each increment or subprogram to have its own program strategy document (TDS or AS), or minimally, have a distinctly separate annex from the ‘core’ program strategy document. When appropriate, an annex for an increment can leverage the core program information.
|
Specify any unique program circumstances, such as transitioning from a technology project, selection as a special interest program, etc.
Indicate whether this program will replace an existing system, is a modification to an existing system, or is a new capability.
Indicate whether this is a New Start program. Verify that the appropriate Congressional notifications have been completed for a New Start. (Reference DoD 7000.14-R, DOD Financial Management Regulation, Volume 3, Chapter 6 for guidance on new start determinations.)
|
NOTES
- A new start is considered to be reprogramming actions which require prior approval of the congressional committees (DD 1415-1).
- A new start program for RDT&E is a new program element or project, or a major component thereof, as determined by specific supporting information provided in the R-2 and R2A (RDT&E Budget Item/Project Justification) exhibits not previously justified by the Department and funded by the Congress through the normal budget process.
- A new start program for Procurement is a new procurement line item or major component thereof, as determined by specific supporting information provided in the P-5 (Cost Analyst) or P40A (Budget Items Just for Aggregated Items) exhibits not previously justified. Congressional committees discourage the use of the reprogramming process to initiate programs. Except for extraordinary situations, consideration will not be given new start reprogramming requests for which the follow-on funding is not budgeted or programmed. Funding for new starts may not be obligated without prior approval or written notification.
|
Indicate whether this is a joint program. If so, specify the joint nature and characteristics of the program. Identify the Service(s) or DoD Components involved, state the key Service-specific technical and operational differences in the end item deliverables, and provide the principal roles and responsibilities of each DoD Component in the management, execution, and funding of the program.
If this is a Technology Development Strategy, identify the feasible technical approaches for developing the approved materiel solution, the impact of prior acquisitions on those approaches, and any related preceding effort.
If this strategy supports the Milestone B or C decision, in a table showing quantity per year, indicate the total planned production quantity and provide the LRIP quantity. Summarize the Low-Rate Initial Production (LRIP) plan. If the planned LRIP quantity exceeds ten percent of the total planned production quantity, provide the justification. (Not applicable to software-intensive programs without production components.)
2.8.4. Tailoring
Consistent with statutory and federal regulatory requirements, the Program Manager (PM) and Milestone Decision Authority (MDA) may tailor the phases and decision points to meet the specific needs of the program. If tailoring is planned, state what is being proposed and why.
List all requests for either regulatory policy waivers or waivers permitted by statute. Include a table similar to notional Table 1.
|
NOTE
The Table should contain proposed tailoring initiatives for MDA approval, as well as already approved (e.g., via Acquisition Decision Memorandum) tailored items, and the rationale should state why the policies, regulations or directives being proposed to be tailored are not relevant or applicable.
|
Table 1. Notional Table of Program Waiver Requests
|
WAIVER REQUESTS
|
|
Requirement to Be Waived
|
Type (Regulatory or Statutory)
|
Granting Authority
|
Rationale
|
Required by
(date or event)
|
Status
|
| |
|
|
|
|
|
| |
|
|
|
|
|
| |
|
|
|
|
|
DAG Tutorial 
