1. The Information Technology (IT) Box A Primer
The “IT Box” model calls for fewer iterations of validating documents through the JCIDS process by describing the overall IS program in the IS ICD, and delegating validation of detailed follow-on requirement and solution oversight to a flag-level organization other than the JROC or JCB.
This presentation provides background of the IT Box and summarizes the IT Box process described in the 19 Jan 2012 JCIDS Manual
Patrick Wills Associate Dean, Executive Programs,
Requirements Management, and International Acquisition Defense Systems Management College  Defense Acquisition University work: cell:
Sources:
CJCSI H, 10 Jan 2012
JCIDS Manual, 19 Jan 2012
Joint Staff, J-8, RMD

2. IT Box Topics IT Box Background Assumptions Applicability Governance
Application
Information Systems Initial Capabilities Document (IS ICD)
Follow-On Documents
IS Requirements/Acquisition Process
Examples
Lessons Learned
Conclusions

3. IT Box Background Why implement an IT box? Moore’s Law: JROCM 008-08
“The number of transistors on an integrated circuit doubles approximately every months.”
The US has been able to leverage rapidly-evolving IT for decisive military advantage.
However, the JCIDS process does not provide the required flexibility to take full advantage of evolving commercial information technology.
JROCM
The JROC wants to ensure the IT programs have the flexibility to “plan for and incorporate evolving technology” throughout the program’s lifecycle.
CJCSI H
Expands on the concepts in JROCM
JROCM 00808, 14 Jan 2008, directed changes to the JCIDS process to ensure Information Technology systems have the appropriate flexibility and oversight to plan for and incorporate evolving Technology.
The “IT Box” process to implement this JROCM first appeared in the March 2009 JCID Manual. The 19 Jan 2012 JCIDS Manual provides a major update to the IT Box process.

4. JROCM Detail
Define minimum capability levels based upon what is achievable with today’s technology. (IS ICD paragraph 4 and JROC briefing)
Describe process for approving capability enhancements. Who will have the authority to manage requirements? (JROC Briefing)
Describe the plan for delivering capability (JROC briefing):
How often will releases of new or enhanced capability be delivered?
What is the plan for assessing the application of new technologies?
What is the plan for technology refresh?
Identify the level of effort funding which will be used for the software development effort. (IS ICD paragraph 4 and JROC briefing)
The bullets are a direct lift from page 2 of the 2 page JROCM.

5. Assumptions
The acquisition and programming communities agree that IS development is different from major weapon systems
Modify their processes and documentation expectations accordingly (modifications to DODI in work)
The test and certification communities can deliver on more responsive test and certification processes to enable more rapid delivery of capabilities
Necessitates incremental/iterative development and testing
Validation authority for managing requirements can be pushed down to the lowest level to allow for rapid changes/decisions (currently within JROC authority)

6. Reasoning for Additional Change
The current JCIDS process and documents are structured to support development of major hardware weapon systems
JCIDS and documents are not supportive of the rapid pace of development necessary with IS systems/capabilities
Previous JCIDS Manual Enclosure C (IT Box process) was a good starting point to address a more agile and responsive process, but requires adjustment – Modified IT Box
In conjunction with changes in the acquisition process, the JCIDS process needs to be adapted to meet the needs of the operational user so that new capabilities can be delivered rapidly, and adapted as necessitated by changes in the operational environment
Desired Outcome - Provide agile and responsive requirements/ capability needs process to enable rapid development of IS capabilities
This describes why additional change was required for the IT Box process in the 19 Jan 2012 JCIDS Manual

7. Applicability of the IT Box JCIDS Manual, 19 Jan 2012
IT box applies to:
IS with software development only
Includes integration onto commercial off-the-shelf hardware
Program costs exceed $15 million
IT box DOES NOT apply to:
Systems with a developmental cost less than $15 million
Defense business systems
Systems which are an integral part of a weapon or weapon system which enables weapon capabilities and are considered part of the weapon system program
19 Jan 2012 JCIDS Manual expands on JROCM by implementing the “IS ICD”. Provides greater flexibility and alignment with:
Sec. 804, NDAA 2010 (Develop new approach for delivering IT capabilities)
Sec. 933, NDAA 2011 (Develop strategy for rapid acquisition of tools, applications, and other capabilities for cyber warfare)
Planned update to DoDI

8. Presentation Template
Applications & System Software
Development & Acquisition
Requirements Organization & Oversight
Capabilities
Required $
Hardware Refresh & System Enhancements & Integration
JROC
Approved
IS ICD
Key Points:
Describe the overall bounds of an IS program in order to reduce return trips to the JROC for approval of improved capabilities.
Provide to FCB/JCB/JROC as part of the approval process for an IS program’s ICD.
Only applies to programs that do not need to develop hardware systems (leveraging COTS/GOTS hardware).
Once ICD is approved, no need to return to the JROC with a CDD or CPD, unless the IS ICD results in a MDAP.

9. Governance Requirements Organization And Oversight: Guidance:
Determines schedule/content of capability releases based upon collaboration between users and the program manager
Guidance:
Name the flag-level body holding authority over and governance for requirements
Identify chair
Identify represented organizations, including all stakeholders. Include the acquisition community to provide advice on technical feasibility, cost and schedule.
Applications & System Software
Development & Acquisition
Requirements Organization & Oversight
Capabilities
Required $
Hardware Refresh & System Enhancements & Integration
JROC
Approved
IS ICD
In the top quadrant Identify the flag-level oversight body, the chair of that body, and
the organizations represented on the body being proposed to receive delegated
requirements oversight duties.

10. Validated Capability Requirements And Initial Minimum Levels:
Key Performance Parameters (KPP); Application & System Software Development and Acquisition
Applications & System Software
Development & Acquisition
Requirements Organization & Oversight
Capabilities
Required $
Hardware Refresh & System Enhancements & Integration
JROC
Approved
IS ICD
Validated Capability Requirements
And Initial Minimum Levels:
The initial minimum performance levels required for the entire IS program. Objective values not required nor briefed.
Application and System Software
Development and Acquisition:
Estimated development and integration costs for the lifetime of the program.
Break out costs into annual estimates.
Using identified measures of effectiveness (MOEs), initial minimums are used instead of thresholds/objectives, allowing for rapid capability development within specified funding limits.
Show estimated sustainment costs over the life cycle of the program. Break out costs into annual estimates. Estimate development and integration costs for the lifetime of the program. Break out costs into annual estimates.

11. Hardware Refresh & System Enhancements
Applications & System Software
Development & Acquisition
Requirements Organization & Oversight
Capabilities
Required $
Hardware Refresh & System Enhancements & Integration
JROC
Approved
IS ICD
Hardware Refresh and System Enhancements & Integration:
Estimated sustainment costs over the life cycle of the program.
Break out costs into annual estimates.
All hardware associated with an IS ICD is COTS/GOTS, and hardware development is restricted to that necessary for system integration, system enhancements, and hardware refresh due to obsolescence.
A cost summary table covering FYDP and total life cycle costs for development, integration and sustainment is required in the IS ICD.

12. Information System (IS) ICD
IS ICDs Implement the “Information Technology (IT) Box” Model
IS ICDs are Required When the Solution Requires Research and Development, and Acquisition of Applications with a Projected Software Development Cost of Over $15 Million
Not Used for Software Embedded as a Subset of a Capability Solution Developed IAW Other Validated JCIDS Documents
IS ICD Applies to:
Commercial off the Shelf (COTS)/Government off the Shelf (GOTS) software, and associated hardware without modification
Commercial capability solutions with integrated, DoD-specific performance standards
Additional production or modification of previously developed U.S and/or Allied or interagency systems or equipment
Development, integration, and acquisition of customized application software
“IT Box” model calls for fewer iterations of validating documents through the JCIDS process by describing the overall IS program in the IS ICD, and delegating validation of detailed follow-on requirement and solution oversight to a flag-level organization other than the JROC or JCB.

13. Information System (IS) ICD (Con’t)
CDDs & CPDs are Not Required as Successor Documents; Sponsors Have Management Flexibility for Alternate Documents
JCIDS Manual Provides Examples of Potential IS ICD Follow-On Documents (Actual Names, Content, and Approval TBD by the Delegated Validation Authority):
Requirements Definition Package (RDP) – identifies KPPs and non-materiel changes
Capability Drop (CD) – lower level document that specifies the characteristics of a “widget” or “app” for partial deployment of the solution
FCB is Briefed Every 2nd Year After Validation on Progress Toward Delivering the Solution (May Recommend JROC Oversight)
As the standard CDD and CPD documents are not typically required, an IS ICD provides Sponsors the flexibility manage IS programs with alternate documents and validation processes as necessary, as long as the program remains within the boundaries of the validated IS ICD and any additional guidance provided by the delegated validation authority.
Business IS are not normally subject to JROC Review – However, FCBs have visibility of business case documents posted to KM/DS and if FCB decides the system has “joint equities” can recommend joint oversight.

14. Requirements Definition Packages (RDPs)
RDPs are not a JCIDS document
Created to break down the requirements into deliverable increments
Responsive, nimble, focused - SPEED
Provides a more detailed definition of one or more capabilities in the ICD
Enables detailed design activity
Enables detailed costing of the requirements
Formal incorporation into JCIDS will link to the acquisition and programming processes
Approved by the delegated Requirements Management authority
FO/GO-level body that holds authority over, and provides governance for requirements
Two document types have been created in the JCIDS Manual. The Requirements Definition Package (RDP) and the Capability Drop (CD). Actual names, content and approval process are to be determined by the delegated validation authority.
The RDP is a first level decomposition of one or more capability requirements in the IS ICD, and is co-developed between the operational user (or representative) and the program office. One or more RDPs together would represent the total set of capability solutions developed to satisfy the capability requirements in the IS ICD.
The RDP identifies KPPs (including the NR-KPP), Key System Attributes (KSAs), and/or additional performance parameters as necessary to scope and cost a specific solution implementation. The RDP may also identify non-materiel changes that need to be implemented to fully realize the IS capability. The RDP would be supported by an Information Support Plan (ISP), submitted separately to DOD CIO for certification purposes. This would be equivalent to CDD as defined in the typical JCIDS process, and would be approved by the delegated validation authority identified in the IS ICD.
A draft RDP could be used before validation to support MS A decisions for IS technology/ prototyping efforts. The RDP would be submitted to the delegated validation authority for validation ahead of a MS B decision. Following validation, the RDP would be posted to the KM/DS system for information purposes and for visibility into the appropriate FCB portfolio.
The RDP can be used to initiate an IS program to develop, test, and deliver the full capability defined in the RDP. It can also be used as a basis for defining multiple drops of incremental capabilities such as “apps” or “widgets” which could be documented in something like a CD.

15. Capability Drops (CDs)
CDs Are Not a JCIDS Document
Managing delivery of capabilities through more specifically defined subsets of an RDP
The details of how to do this are left to the components and the acquisition process
The RDP is Further Broken Down into CDs to Deliver Individual “Widgets” or “Slices” of Capability
The Results of the CD Development are Released Incrementally Through Full Deployment Decisions as They Are Ready
Approved by the Delegated Requirements Management Authority and the Component PM lead
The CD could be a much lower level document to specify the detailed characteristics of a “widget” or “app” necessary for partial deployment of the capability solution. It could be developed through a rapid prototyping effort with the user to ensure it meets their needs. A CD could be developed directly from the definitions in the ICD in the event of a more urgent need for the capability. More commonly, multiple CDs would be derived from an RDP to deliver all of the capabilities defined in the RDP.
The CD should include information such as a detailed technical description of the capabilities provided by a “widget” or “app” that can be developed and fielded within a short period of time, along with specific technical performance requirements. If not already covered by the ISP approved for the RDP, the CD is supported by a separately submitted ISP for CIO certification purposes.
The approval of CDs would most likely be delegated to a lower level requirements authority as determined by the RDP authority to ensure timely decision making.
Deployment decisions are made whenever the product – whether from an RDP or a CD - is ready for deployment to the user.

16. IS Requirements/Acquisition ProcessCD
RDP IS
ICD
JROC
Approved
Capabilities
Based
Assessment
MS B
O&S
Engineering Analysis/ Design
MDD
(NF)
Rapid Delivery
Fielding Decisions
Agile Development
Component
Specific implementation guidance on document content and approval process to be provided by Component
Acquire Decision

17. Requirements/Acquisition Process (con’t)
Full Deployment Decisions
MDD
MS A/B
Capabilities
Based
Assessment
ICD
(NF)
Engineering Analysis/ Design
RDP CD CD CD CD CD CD CD CD CD
Strategic Guidance
Joint Concepts
O&S
Agile Development
Rapid Delivery
IOC
This shows a very streamlined process for truly agile IS development
The ICD is developed in a new format tailored to IS capabilities
Following the MDD, one or more RDPs are developed to further refine the requirements for the needed capabilities
The RDP is further broken down into CDs to deliver individual “widgets” of capability
The results of the CD development are released incrementally through Full Deployment Decisions

18. Execution of the IT Box Process
Execution will vary depending on whether this is a new set of capabilities or whether capabilities are being added to an existing IS capability set
A new set of capabilities is initiated through a new IS ICD
Adding capabilities to an existing system may enter at any stage along the process
In many cases, an update to an existing RDP is all that is required
A major expansion of capabilities may require a new IS ICD
Modifying or enhancing existing capabilities should only require a mod or a new CD to document what is needed
There may be cases where the mod or enhancement has impact on the architectures or data and this will require a mod to the RDP to fully document the change
Managed by the requirements management authority

19. Key Performance Parameter
Net-Ready KPP Example
Attribute 1. Support to Military Operations
NR-KPP Attribute
Key Performance Parameter
Threshold
Objective
Support to military operations
Mission: Tracking and locating (Finding, Fixing, Finishing) High- Value Target (HVT)
Measure: Timely, actionable dissemination of acquisition data for HVT
Conditions: Targeting quality data to the neutralizing/ tracking entity
10 minutes
Area denial of HVT activities
Near-real-time
HVT tracked, neutralized
Mission Activities: Find HVT
Measure: Location accuracy
Conditions: Individual differentiation
100 meter circle
Identify armed/ not armed
25 meter circle
Identify individual

20. Key Performance Parameter
Net-Ready KPP Example
Attribute 2. Enter and Be Managed in the Network
NR-KPP Attribute
Key Performance Parameter
Threshold
Objective
Enter and be managed in the network
Network: SIPRNET
Measure: Time to connect to an operational network from power up
Conditions: Network connectivity
2 minutes
99.8
1 minute
99.9
Network: NIPRNET

21. Key Performance Parameter
Net-Ready KPP Example
Attribute 3. Exchange Information
NR-KPP Attribute
Key Performance Parameter
Threshold
Objective
Exchange information
Information Element: Target Data
Measure: Dissemination of HVT biographic and physical data
Measure: Receipt of HVT data
Measure: Latency of data
Measure: Strength of encryption
Conditions: Tactical/Geopolitical
10 seconds
Line of Sight (LOS)
5 seconds
NSA certified type 1
Permissive environment
Beyond LOS
2 seconds
Non-permissive environment

22. Example: Integrated Strategic Planning & Analysis (ISPAN)
Organization & Oversight
Flag-level oversight through ISPAN Requirements Governing Council (IRGC)
Chair: GS/CD
Members: ESC SPM, USSTRATCOM CIO
GS COS, J2, J3, J5, J6
HQ J63, J82, J83
Key Performance Parameters
KPP #1 - 4: define mission planning capabilities required
services and critical user access devices: 0.99
KPP # 5, 7, and 8 – define material availability/quality of service performance
KPP #6 Net-Ready requirement
“Boundaries”
JROC-Approved
ISPAN
Oversight – ASD(NII)
Execute – AF/PEO ESC
Hardware Refresh & System
Enhancements & Integration
Per year (FY04-20) = $22.8M (TY)
Lifecycle cost = $387.3M (TY)
Per FY = $355.8M average/yr
ISPAN consists of a system-of-systems approach that spans multiple security enclaves for strategic and operational level planning and leadership decision making. The system is composed of two elements: (1) a Collaborative Information Environment (CIE) managing strategy-to-execution planning across all United States Strategic Command (USSTRATCOM) Mission areas; and (2) a Mission Planning and Analysis System (MPAS) that support the development of Joint Staff Level I through Level IV nuclear and conventional plans supporting National and Theater requirements. Both elements of the ISPAN program establish a framework to support the USSTRATCOM's effects-based planning and analysis activities.
Category: ACAT IAM
Sponsor: Air Force
Milestone Decision Authority: USD(AT&L)
Application and Systems
Software Development
Per year (FY04-20 = $54.7M (TY)
Lifecycle cost = $929.9M (TY)

23. IT Box Cost Driver Quad Chart
Performance (KPPS & Select KSAs)
KPP 1 | | |
KPP 2 | | |
KPP 3 | | |
KSA 4 | | |
KSA 5 | | |
N IM O
Top Cost Drivers
A, % of program cost
B, % of program cost
C, % of program cost
D, % of program cost
E, % of program cost Y G G G R
N = No capability IM = Initial Minimum O = Objective
Acquisition Program Baseline (APB)
Technology Readiness Assessment
Baseline
Cost | | |
- Life-cycle cost
- Current Est | | |
(DAES Report)
Schedule
- IOC or FOC | | |
- Next Major Event | |
Critical Technologies
Critical Assessment
Next Milestone
Technology A
TRL #
Technology B
Technology C
Technology D
Technology E
Technology F G G
+15% +25% G Y
+6 mo +1 yr
MS B Date: M/Yr
MS C Date: M/YR
(Note: Aligns with MAIS reporting
Tripwires in Ch 144A, FY07 NDAA)

24. Example JROCM – Consolidated Afloat Networks & Enterprise Services (CANES)
Delegates change authority for non-key performance parameters to the Navy
Program oversight for CANES delegated to the Navy led Information Technology Management Council (ITMS)
ITMC may approve spiral developments as long a all initial KPPs and funding constraints are not exceeded
The CANES program recapitalizes the Navy's afloat network infrastructure (see note below) by consolidation of diverse physical networks into a secure, modular and scalable Common Computing Environment (CCE) and software environments augmented with state of the shelf Cross Domain Solutions (CDS). CANES is the intended hardware and software environment upon and within which applications, services and systems will reside in the Navy tactical domain. CANES provides all security domains from Unclassified through Top Secret/Sensitive Compartmented Information (SCI) for a wide variety of Navy surface combatants, submarines, Maritime Operations Centers and aircraft. CANES enables efficient data visibility and flow within the Ship, Ship-to-Ship and Ship-to-Shore to support operational nodes on the Global Information Grid (GIG) using an open architecture.
Category: ACAT IAM
Sponsor: Navy
Milestone Decision Authority: USD(AT&L

25. Lessons Learned/ Working Issues
KPPs in IT program CDDs should be briefed with “Initial Minimums” only vice traditional Thresholds/Objectives.
PAUC/APUC don’t apply to IT acquisition; use different metric.
For incremental acquisition, ensure IT box describes entire IT program and not just a single increment (if possible).
Working Issues:
Tie-in IT box (requirements piece) with on-gong DOD IT acquisition reform efforts (directed by FY 2010 NDAA)

26. Conclusion The IT box is the right thing to do for IT programs
Provides required flexibility for IT program success
Allows more effective support to the Warfighter
High-level guidance and agreement
VCJCS, JROC, DOD CIO
Supports FY 2010 NDAA:
“The Secretary of Defense shall develop and implement a new acquisition process for IT systems …. Based on recommendations for the DSB Task Force on Acquisition of IT.”
Must continue close coordination to successfully implement IT box