Weapon Systems Intelligence Integration (WSII) Handbook; June 1999

Previous Section

ISP Outline

Title Page

Executive Summary (2 pages maximum)

This summary must be able to stand-alone and should capture the major issues and shortfalls brought out in the document.

Table of Contents and List of Figures and Illustrations.

Since the ISP process is a new concept, this section should emphasize the purpose of the Intelligence Support Plan including intelligence infrastructure support to the acquisition process. This section will mostly be "boiler-plate" and not vary much from plan to plan. A suggested structure for Chapter 1 is as follows:

Section 1: Weapon System Description -- This section will describe the overall mission area, the type of system proposed, and the anticipated operational and support concepts in sufficient detail for intelligence support planning.

- Operational Baseline

-- Employment Options -- Describe all of the different options of how the system is to be employed. An employment option is one level down from a role or mission.

-- Concept of Operations -- Present the CONOPS in the clearest way possible. If graphical representations are helpful, then use them. If the CONOPS for different employment options are best described separately, then do so.

-- Operating Environment -- this may be included under the CONOPS section

Section 2: Acquisition Strategy Description -- Briefly describe the acquisition strategy. This is the business and technical management approach designed to achieve program objectives within the resource constraints imposed. It is the framework for planning, directing, and managing the program. Also include a master schedule for research, development, test, production, fielding and other activities essential for program success. Here is a proposed format:

- Overview/Acquisition Strategy
- Program Schedule
- Weapon System Technologies
- Development and Operational Testing
- Training

-- Program Peculiarities (e.g. Joint, Foreign Military Sales, Off-the-Shelf, Advanced Concept Technology Demonstrators)

The Strategy-to-Task derivations used to arrive at the intelligence requirements from the operational baseline should be shown here. Strategy-to-Task is a methodology for requirements analysis leading to operational system procurement. It is a tool that enables analysts to derive and trace linkages from high-level military objectives down through individual tasks and the systems and resources that support them. The various STT-based methodologies and models are useful throughout the acquisition and intelligence support cycle. See Chapter 8 of the WSII Handbook for more guidance.

Acquisition-Related Intelligence Needs. Certain programs may have needs to be filled by the intelligence community during its acquisition process. For example, during Phase I, Demonstration and Validation, a contractor designing a countermeasure may need information on the capabilities of an adversary’s missiles; or, during Phase II, Engineering and Manufacturing Development, there may be requirements for specific intelligence information or infrastructure in place for certain tests. If a Strategy-to-Task analysis is the best way to arrive at these requirements, then show this derivation. If not, then explain in the clearest way possible where it was derived from, i.e. why it is needed. The acquisition strategy or peculiarities in the program may involve other functions and organizations such as Modeling & Simulation, AFOTEC or Foreign Military Sales; these needs should also be addressed.

Unclassified

Unclassified

XX-X#-####*

3.# (U) Title.

3.#.1 (U) Functional Description. A concise statement of the intelligence requirement. This statement should include the reason the information is required and what operational/acquisition function it supports.

3.#.2 (U) Reference/Justification. reference to the specific section in Chapter 2 from which this requirement is derived. Provides traceability back to the operational/acquisition requirement.

3.#.3 (U) Satisfaction Criteria. The specific details that fully describe the requirement. The data to populate the second column of this matrix is generated using the functional area checklists in Chapter 8 of the ICO Handbook. Examples of satisfaction criteria would be: format, accuracy, timeliness, volume, classification, etc. The column "REQUIREMENT" is optional and could be used to aid in tracking the discrete criteria of your overall requirement. The element of satisfaction needs to be clear and easily measurable so it is easy to identify when the ISR has been satisfied.

Classification

(U) Table 3.# -- (ISR Title) Satisfaction Criteria

3.#.4 (U) Support Plan/Solution. The solution (i.e., product description and dissemination architecture [organization, hardware]) to the requirement is detailed here. A graphical representation of the infrastructure elements that support this solution can also be presented. "Potential" solutions may also be listed if the solution concept is scenario dependent.

3.#.5 (U) Dissemination Infrastructure. (As required) The method or system in which data or information is disseminated to the end-user.

3.#.6 (U) Action Items. A description of the items required to ensure satisfaction of the intelligence support requirement. The OPR and operational need date also are provided. Some flexibility should be used here depending on the system and where it is in its life cycle; for example, if it’s in early EMD, there may be many requirements identified that are needed at different times and it may be appropriate to identify operational need date as "Due by PDR," "Due by DT&E," "Due by IOC," etc. In the status column, one of the following descriptors should be used to facilitate cross-ISP checks: Active, Future Action, Needs Reviewed, Unknown, Completed, Overcome By Events (OBE). Further detailed status descriptions may also be added. For example:

Unclassified

3.#.7 (U) Comments. (Optional)

*Notes on Numbering Scheme: (XX-X#-####)

XX = Two-letter designator of the category of the intelligence requirement. This will provide a convenient, consistent method of identifying the category of requirement.

X# = Two-character descriptor to indicate which ISP this requirement comes from. This will provide an ISP-unique descriptor to distinguish which ISP a given requirement supports (provides relational information when requirements are put into a cross-ISP database).

xxxx = Four-digit sequence number for the unique requirement. The numbers will be consistent from ISP to ISP. This will provide a simple mechanism for managing requirements from ISP to ISP.

The purpose of Chapter 4 is to provide a documented assessment of the estimated intelligence infrastructure costs to implement and sustain the solutions for intelligence support requirements (ISR) examined in Chapter 3.

To the maximum extent possible, the following cost areas should be addressed: equipment/systems (including hardware and software and maintenance), manpower, training, and facilities. Address each intelligence requirement individually. Due to the complexity of cost information, we recommend each WSIIO use the following format to create their Chapter 4:

4.1 (U) Overview. The purpose of Chapter 4 is to provide a documented assessment of the estimated intelligence infrastructure costs to implement and sustain the preferred solutions for each ISP name intelligence support requirement (ISR) examined in Chapter 3. Some cost estimates remain tentative in this draft and are so identified where appropriate. Only cost estimates are shown in this chapter; refer to Chapter 3 for explanations of each requirement, impacts of not meeting a requirement, and action items.

4.1.1 (U) Baseline Assumptions for Cost Estimates. Many infrastructure costs are shared among weapons systems. The ISP is intended to identify and assess only the additive, ISP name-unique impacts on the intelligence infrastructure, not the absolute total burden. This ISP does not attempt to cost currently funded collection, processing and distribution of data. Also, detailed Joint infrastructure assessments are outside the charter of an Air Force ISP. All cost estimates are given in base year 19XX dollars and do not reflect any escalation due to the anticipated effects of inflation. Note: use the following if applicable: Man-hours were converted to manpower billets in accordance with AFI 38-201, Table A.2.1. The billets were converted to dollars in accordance with AFI 65-503. Key facts and assumptions are listed with each cost assessment.

4.1.2 (U) National Organizations. Use this if applicable. The principal national level agencies involved with weapon-specific intelligence support are NIMA, producer of the DPPDB and provider of intelligence imagery, and the Defense Intelligence Agency (DIA), involved with Joint target production policy issues and standardization matters. NIMA already is funding several areas crucial to ISP name support, such as DPPDB production and wholesale intelligence imagery access, and DIA is not expected to introduce any new funding requirements. That is not to say there are no shortfalls in these areas; only that impacts are so widespread that it is neither possible nor productive to attempt to segregate and put a price tag on "ISP name-unique" shortfalls within those organizations.

4.1.3 (U) Cost Assessment Models. By necessity, cost models vary among the ISRs assessed. However, these guidelines were applied in performing the assessments.

4.2 (U) Cost Drivers. Just as the ISRs in Chapter 3 are derived from the strategy-to-task methodology in Chapter 2, the cost drivers here depend on the support plan/solution for each ISR in Chapter 3. These drivers may or may not incur actual new costs, depending on the extent to which name of the contractor developing your weapon system (for example Boeing) will be able to meet the ORD requirement using existing (i.e., standard) intelligence products and services. Potential ISP name cost drivers for the intelligence community include the equipment/systems, manpower, training, and facilities required. A short summary by major category of cost driver follows.

4.2.1 (U) Equipment/systems. Use this or something similar. Equipment is involved with nearly every phase of ISP name intelligence support, including.

4.2.2 (U) Manpower. Use this or something similar. The key issue concerns the type of personnel, numbers involved, and the skill levels needed to support.

4.2.3 (U) Training. Use this or something similar. Additional TBMCS training costs, over and above what is covered in the technical intelligence training programs, fall into several areas, such as using DPPDB-equipped TBMCS workstations. Some probably will be provided by the contractors, at least initially, for hardware/software/procedural upgrades. Afterwards, some sort of mobile or refresher training capability should satisfy most requirements. It will have to be reoccurring (e.g., bi-annual) to account for personnel turnover, system enhancements, and changing mission requirements.

4.2.4 (U) Facilities. Use this or something similar. Intelligence support activities for ISP name are not expected to incur major facility costs, with the exception of base operating support "surcharges" applied when adding manpower to an installation such as an air force base. Floor space for any additional workstations at the AOC and unit levels is expected to be available within existing facilities. (Note: Although not driven by any intelligence support requirement, there is a potentially large facility impact at the unit level resulting from the apparent operational need to use special access required [SAR] data for ISP name route planning.)

4.3 (U) An overall ISP name infrastructure cost summary. The following two tables provide a quick reference of the cost to the ISP name program. While the first table shows the cost to the SPO, the second table lists non-SPO requirements and provides cost when available.

4.3.1 (U) Estimated cost to the SPO to implement ISRs.

Unclassified

4.3.2 (U) Estimated non-SPO cost to implement ISRs.

Unclassified

4.4 (U) Cost Estimates for ISP name Intelligence Support Requirements. A brief assessment of each of the (state the number) ## ISRs from Chapter 3 follows, summarizing direct and indirect costs to satisfy each requirement. When there is no funding issue or the existing or planned infrastructure satisfies the requirement, in whole or in part, it is so noted.

4.4.1 (U) AQ-XX-0100 – GI&S/Targeting: Target Data

4.4.1.1 (U) Support Plan/Solution.

4.4.1.1.1. (U) SPO cost. The Modernized Integrated Data Base (MIDB) Version 2.0 interface cost for TBMCS (Rapid Application of Air Power [RAAP]) sought $180K in the FY99 timeframe. For the later MIDB Version 3.0 interface cost required in FY01 timeframe, the $200K needed is unfunded.

Unclassified

4.4.1.1.2. (U) Non-SPO cost. Still to be determined are associated costs for correcting distribution hosts and mobile/deployable theater communication deficiencies. Also, there will be substantial cost associated with procurement of additional Combat Intelligence System (TBMCS) workstations (see Appendix C).

Unclassified

Note to the WSIIO: some ISRs only deal with solutions which will be satisfied by the SPO. If that is the case then there will be no need for the above table. Nonetheless, to ensure clarity, maintain paragraph 4.4.1.1.2. where you should say: "N/A." On the other hand, some ISRs could require greater level of detail. In that case you should use matrix similar to the "cost to the SPO" matrix provided in paragraph 4.4.1.1.1.

4.4.1.2 (U) Assumptions. For example: NIMA products and services are provided at no charge to the US Department of Defense (DoD) user.

4.4.1.3 (U) Cost Model and Analysis. For example: Manpower, training and communications needs are addressed in ISRs OP-P5-0401, TN-P5-0401, and MP-P5-0300 respectively. The cost model for the equipment and facility cost drivers addressed here is a combination of (1) comparative analysis with building target materials (both pre-planned and contingency) which have characteristics similar to TAMs, and (2) rudimentary time trials conducted by 480th IG using an early version of PTM software (with an UltraSparc1 Model 170E workstation) in November 1997. The 480th IG experience with warfighter target materials support is an essential supplement to TAM time trials, since actual construction time is a minor fraction of the overall data-gathering, production, dissemination and maintenance process. The analyses which derived parameters for these and other key factors are shown below.

Note to the WSIIO: some IRSs may require more detailed information on the cost drivers. You may want to individually address: equipment/systems, manpower, training, and facilities.

4.4.1.4 (U) Summary. For example: For equipment/systems, the target data will be extracted from MIDB via TBMCS. There is a lack of multi-level security system between the collateral distribution host and the system high theater integrated data base (IDB) host, a lack of mobile/deployable theater communications, and a need to build a TBMCS (RAA) MIDB 2.0 interface. Also, the noted Air Force wide shortfall in TBMCS workstations available to the Wings and Squadrons will impact several intelligence support requirements. Under manpower and training, training for TBMCS-AFMSS target data interface functionality for technical courses and field units, if insufficient, should by covered by the CIS Training Planning Team (TPT) through requirement submissions to the Air Education and Training Command (AETC).

Appendices

Annexes

3 blank 12 pt lines

1. (U) Role of the Intelligence Support Plan (ISP):

1.1 (U) Overview: Use/Save As MicroSoft Word 6.0. Page classification markings are 16 pt Arial Bold. Chapter number and title is 14 pt Times New Roman Bold. Main body text is 12 pt Times New Roman with ½" hanging indent, fully justified paragraphs. Paragraph numbers, paragraph classification markings, and paragraph headings are bold type. Use the Air Force standard numbering system for all paragraphs and subparagraphs.

Unclassified

1.1.2 (U) Figures: Use/Save As only MicroSoft PowerPoint 4.0, do not use any drawing programs. If possible, put a box around the figure. Classification markings and caption specifications are the same as for tables.

Unclassified

Figure 1.1 -- Figure Caption (U)

Next Section