Achieving Effective Acquisition of Information Technology in the Department of Defense (2010) / Chapter Skim
Currently Skimming:
Summary and Recommendations
Summary and Recommendations
Pages 1-16
The Chapter Skim interface presents what we've algorithmically identified as the most significant single chunk of text within every page in the chapter.
Select key terms on the right to highlight them within pages of the chapter.
From page 1... ...
Nevertheless, today's processes for the acquisition and testing of the DOD's IT systems all too often deliver solutions that are too late to satisfy the needs of the user community. Current fielding cycles are, at best, two to three times longer than successful commercial equivalents according to presentations to the committee -- representing multiyear delays in delivering improved IT systems to warfighters and the organizations that support them.
|
From page 2... ...
This study reaches the same fundamen tal conclusion but adds another dimension in its elaboration of differing types of IT systems and offers a suggested acquisition process for each. SCOPE AND VOCABULARy FOR INFORMATION TECHNOLOGy ACQUISITION PROGRAMS Information technology is used for a wide variety of purposes in the DOD, a breadth suggested by the definition of "information enterprise" in DOD Directive (DODD)
|
From page 3... ...
. By separating programs that involve software development and/or integration from programs that entail simply adopting COTS technology, these categories facilitate the comparison of defense acquisition processes 3See, for example, DOD Directive 5002.15000 series regulations; Title 10, U.S.C., Chapters 144 ("Major Defense Acquisition" Programs)
|
From page 4... ...
4 As set forth in Title 10, U.S.C., Chapters 144 ("Major Defense Acquisition Programs") and 144A ("Major Automated Information System Programs")
|
From page 5... ...
The discrepancy between DOD fielding cycles and COTS life cycles is stark, and measured in years. • The oversight process focuses too much on shortcomings of COTS products and services and inhibits the timely delivery of meaningful (albeit imperfect)
|
From page 6... ...
This requirements-defini tion and budgeting process encourages the aggregation of requirements into larger programs. In turn, these requirements documents are used to justify program budget requests, and the approval of these requests is a condition for proceeding to successive acquisition program milestones.
|
From page 7... ...
"Small-r" requirements provide a set of more detailed requirements associated with specific user interfaces and utilities that will evolve within the broader specified architecture as articulated in the initial big-R requirements.
|
From page 8... ...
In implementing this concept, DOD officials would be responsible for setting priorities and allocating the funding to individual projects following appropriations for a portfolio of mission requirements. This approach would ensure appro priate justification of funding needs tied to mission requirements during budget submission as well as the rapid allocation of appropriated funding consistent with the pace of evolving mission requirements and technology advancements.
|
From page 9... ...
Pilot programs would provide the DOD with the means to apply new acquisition approaches and to capture valuable lessons learned and develop the necessary guidance for applying the knowledge acquired to larger and future programs. The committee believes that the establishment of 10 pilot programs for the rapid acquisition of IT systems capabilities under the alternative IT acquisition process described in this report would greatly help in moving the acquisition process forward.
|
From page 10... ...
To deliver software capability more rapidly, the commercial world has widely embraced the iterative, incremental development (IID) approach, which addresses two issues of central importance for IT systems -- (1)
|
From page 11... ...
With the existence of multiple oversight bodies and large numbers of participants in the program oversight and review process, the current system gives undue leverage to groups that often are not true stakeholders in the process. This can have negative effects, including too many detailed and ad hoc small-r requirements placed on the program, an inability to prioritize requirements effectively, and "corner case" requirements (focused on rare situations that only occur outside normal operating parameters)
|
From page 12... ...
Requirements such as the expected user interface and user paradigms and integration with other concurrently evolving systems and security practices all dictate that the initial specification be limited to broad system goals and physical operating conditions and that more detailed requirements be evolved in concert with user feedback garnered during incremental development cycles. Recommendation 2.3.
|
From page 13... ...
Where the requirement includes COTS hardware or licensed software that can be procured at volume discounts through DOD enterprise contract vehicles (such as Enterprise Software Initiative contracts) , decentralized procurement should be encouraged.
|
From page 14... ...
Without regular feedback from a user perspective on IT system development, program managers and milestone decision authorities lack critical information for managing and supporting programs, and other key stakeholders lack the knowledge that can build their confidence. This approach stands in contrast to best commercial practice, whereby user testing is performed early and often to ensure that user feedback guides all stages of system development.
|
From page 15... ...
Continuous user testing is an integral part of successful IT systems development and deployment. An acceptance team emphasizing the perspective of the end user and composed of operational end users, development testing and operational testing stakeholders, security certification and accreditation stakeholders, and interoperability stakeholders should be continuously integrated into the development process.
|
From page 16... ...
The definition of test environ ment could, over time, be significantly extended to include the use of beta testing in actual operational environments, the use of commensurate commercial data and/or operating environments, and the extension of virtual test environments to include operations monitoring as a source of continuous test feedback. The DOD should codify this approach and encourage the use of virtual environments.
|
Key Terms
This material may be derived from roughly machine-read images, and so is provided only to facilitate research.
More
information on Chapter Skim is available.