Table C-1 was taken from Software Is Never Done: Refactoring the Acquisition Code for Competitive Advantage, a 2019 study by the Defense Innovation Board.
TABLE C-1 37 Years of Prior Reports on Department of Defense Software
| Date | Organization | Short Title/Summary of Contents |
|---|---|---|
| 1982 | DoD | Joint Service Task Force on Software Problems 37 pp + 192 pp Supporting Information (SI); 4 major recommendations The opportunities and problems posed by computer software embedded in DoD weapon systems were investigated by a joint Service task force. The task force members with software experience combined existing studies with the observations of DoD project managers. The task force concluded that software represents an important opportunity in regard to the military mission. Further, it was concluded that technological excellence in software is an important factor in maintaining U.S. military superiority, but that many problems facing DoD in software endangers this superiority.a |
| Date | Organization | Short Title/Summary of Contents |
|---|---|---|
| 1987 | DSB | Task Force on Military Software 41 pp + 36 pp SI; 38 recommendations The task force reviewed current DoD initiatives in software technology and methodology, including the Ada effort, the STARS program, DARPA’s Strategic Computing Initiative, the Software Engineering Institute (SEI), and a planned program in the Strategic Defense Initiative. The five initiatives were found to be uncoordinated, and the task force recommended that the Undersecretary of Defense (Acquisition) establish a formal program coordination mechanism for them. In spite of the substantial technical development needed in requirements setting, metrics and measures, tools, etc., the Task Force was convinced that the major problems with military software development were not technical problems, but management problems. The report called for no new initiatives in the development of the technology, some modest shift of focus in the technology efforts underway, but major re-examination and change of attitudes, policies, and practices concerning software acquisition.b |
| 2000 | DSB | Task Force on Defense Software 36 pp + 10 pp SI; 6 major recommendations The Task Force determined that the majority of problems associated with DoD software development programs are a result of undisciplined execution. Accordingly, the Task Force’s recommendations emphasized a back-to-the-basics approach. The Task Force also noted that numerous prior studies contain valid recommendations that could significantly and positively impact DoD software development programs. The fact that the majority of these recommendations have not been implemented should lead to efforts designed to understand the inhibitors preventing these recommendations from being enacted.c |
| 2004 | RAND | Attracting the Best: How the Military Competes for Information Technology Personnel 149 pp; no explicit recommendations Burgeoning private-sector demand for IT workers, escalating private-sector pay in IT, growing military dependence on IT, and faltering military recruiting all led to a concern that military capability was vulnerable to a large shortfall in IT personnel. This report examined the supply of IT personnel compared to the military’s projected future manpower requirements. It concluded that IT training and experience, augmented by enlistment bonuses and educational benefits as needed, seemed sufficient to ensure an adequate flow of new recruits into IT. However, sharp increases in military IT requirements had the potential to create difficulties.d |
| 2008 | NCMA | Generational Inertia: An Impediment to Innovation? 7 pp; no explicit recommendations This article cites data to the effect that approximately 50 percent of the acquisition workforce is within 5 years of retirement. Rather than being a problem, the article feels that retirement of senior contracting specialists could effectively lead to acquisition reform: “Senior contracting specialists’ resistance to change and indifference to professional development is the elephant in the room that acquisition reformers are unwilling to acknowledge.”e |
| Date | Organization | Short Title/Summary of Contents |
|---|---|---|
| 2009 | DSB | Task Force on Department of Defense Policies and Procedures for the Acquisition of Information Technology 68 pp + 2 pp dissent + 15 pp SI; 4 major recommendations with 13 subrecommendations The primary conclusion of the task force is that the conventional DoD acquisition process is too long and too cumbersome to fit the needs of the many IT systems that require continuous changes and upgrades. The task force recommended a unique acquisition system for information technology.f |
| 2010a | NRC | Achieving Effective Acquisition of Information Technology in the Department of Defense 164 pp + 16 major recommendations This study board was asked to assess the efficacy of DoD’s acquisition and test and evaluation (T&E) processes as applied to IT. The study concluded that DoD is hampered by “a culture and acquisition-related practices that favor large programs, high-level oversight, and a very deliberate, serial approach to development and testing (the waterfall model).” This was contrasted with commercial firms, which have adopted agile approaches that focus on delivering smaller increments rapidly and aggregating them over time to meet capability objectives. Other approaches that run counter to commercial, agile acquisition practices include “the DoD’s process-bound, high-level oversight [that] seems to make demands that cause developers to focus more on process than on product, and end-user participation often is too little and too late.”g |
| 2010b | NRC | Critical Code: Software Producibility for Defense 148 pp + 15 major recommendations This study was charged to examine the nature of the national investment in software research and ways to revitalize the knowledge base needed to design, produce, and employ software-intensive systems for tomorrow’s defense needs. The study notes the continued reliance by DoD on software capabilities in achieving its mission and notes that there are important areas where DoD must push the envelope beyond mainstream capability. In other areas, however, DoD benefits by adjusting its practices to conform to government and industry conventions, enabling it to exploit a broader array of more mature market offerings.h |
| 2016 | CRS | The Department of Defense Acquisition Workforce: Background, Analysis, and Questions for Congress 14 pp; no explicit recommendations The increase in the size of the acquisition workforce has not kept pace with increased acquisition spending, which has signified an increase not only in the workload but also in the complexity of contracting work. This report summarized four Congressional efforts aimed at enhancing the training, recruitment, and retention of acquisition personnel.i |
| Date | Organization | Short Title/Summary of Contents |
|---|---|---|
| 2016 | CNA | Independent Study of Implementation of Defense Acquisition Workforce Improvement Efforts 147 pp + 30 pp SI; 21 major recommendations This report examines the strategic planning of the Department of Defense regarding the acquisition workforce (AWF). The study found significant improvements in several areas that “not only reversed the decline in AWF capacity from the 1990s, but also reshaped the AWF by increasing the number of early and mid-career personnel.”j |
| 2017 | SEI | DoD’s Software Sustainment Study Phase I: DoD’s Software Sustainment Ecosystem 101 pp; 5 major recommendations Since the time in the early 1980s when software began to be recognized as important to DoD, software sustainment has been considered a maintenance function. After almost four decades, DoD is also at a tipping point where it needs to deal with the reality that software sustainment is not about maintenance, but rather it is about continuous systems and software engineering for the life cycle to evolve the software product baseline. This report recommends changing that paradigm to enable the innovation needed to address a rapidly changing technology environment, specifically through investments in human capital, better performance measurement of software sustainment, and better visibility for the software portfolio.k |
| 2017 | BPC | Building a F.A.S.T. Force: A Flexible Personnel System for a Modern Military 82 pp + 15 pp SI; 4 major themes with 39 recommendations This study describes today’s DoD personnel system as out of step with contemporary needs and issues: “the current system is typically poorly coordinated, lacks accountability, is unable to quickly obtain specialized talent, and fosters a groupthink mentality within the force.” It concludes that an effective personnel system has to build a force that is adaptable to new threats as they arise and technically proficient (among other characteristics).l |
| 2018 | DSB | Design and Acquisition of Software for Defense Systems 28 pp + 22 pp SI; 7 (high-level) recommendations + ~32 subrecommendations The Task Force assessed best practices from commercial industry as well as successes within DoD. Commercial embrace of iterative development has benefited bottom lines and cost, schedule, and testing performance, while the Department and its defense industrial base partners are hampered by bureaucratic practices and an existing government-imposed reward system. The Task Force concluded that the Department needs to change its internal practices to encourage and incentivize new practices in its contractor base. The assessment of the Task Force is that the Department can leverage best practices of iterative development even in its mission-critical software systems.m |
| Date | Organization | Short Title/Summary of Contents |
|---|---|---|
| 2018 | 2016 NDAA | Section 809 Panel - Streamlining and Codifying Acquisition 1,275 pp; 93 recommendations The Section 809 Panel was established by Congress in the FY 2016 NDAA to address issues with the way DoD buys what it needs to equip its warfighters. The panel published an Interim Report and a three-volume Final Report, containing a total of 93 recommendations aimed at changing the overall structure and operations of defense acquisition both strategically and tactically. Some changes hold potential for immediate effect, such as those that remove unnecessary layers of approval in the many steps contracting officers and program managers must take and those that remove unnecessary and redundant reporting requirements. Other changes require a large shift in how the system operates, such as buying readily available products and services in a manner similar to the private sector and managing capabilities from a portfolio, rather than program, perspective.n |
| 2019 | DIB | Software Is Never Done; Refactoring the Acquisition Code for Competitive Advantage (this document) 78 pp + 207 pp SI; 4 main lines of effort, 10 primary and 0x10 additional recommendations In this report, we focus on three overarching themes: (1) speed and cycle time are the most important metrics for managing software; (2) software is made by people and for people, so digital talent matters; and (3) software is different than hardware (and not all software is the same). We provide a set of major recommendations that focus on four main lines of effort: (A) refactoring statutes, regulations, and processes specifically for software—including acquisition, development, assurance, deployment, and maintenance—to remove hardware-centric bottlenecks while providing more insight and better oversight; (B) creating and maintaining interoperable (cross-program/cross-Service) digital infrastructure to enable continuous and rapid deployment, scaling, testing, and optimization of software as an enduring capability; (C) creating new paths for digital talent and increasing the level of understanding of modern software within the acquisition workforce; and (D) changing the practice of how software is procured and developed by adopting modern software development approaches.o |
NOTE: BPC, Bipartisan Policy Center; CNA, Center for Naval Analyses; CRS, Congressional Research Service; DIB, Defense Innovation Board; DoD, Department of Defense; DSB, Defense Science Board; NCMA, National Contract Management Association; NDAA, National Defense Authorization Act; NRC, National Research Council; SEI, Software Engineering Institute.
a DoD, 1982, Report of the DoD Joint Service Task Force on Software Problems, July 30, https://apps.dtic.mil/sti/tr/pdf/ADA123449.pdf.
b DSB, 1987, Report of the Defense Science Board Task Force on Military Software, Office of the Under Secretary of Defense for Acquisition, https://apps.dtic.mil/sti/tr/pdf/ADA188561.pdf.
c DSB, 2000, Report of the Defense Science Board Task Force on Defense Software, Office of the Under Secretary of Defense for Acquisition and Techology, https://dsb.cto.mil/wp-content/uploads/reports/2000s/ADA385923.pdf.
d J. Hosek, M.G. Mattock, C.C. Fair, J. Kavanagh, J. Sharp, and M.E. Totten, 2004, “Attracting the Best: How Military Competes for Information Technology Personnel,” RAND, https://www.rand.org/pubs/monographs/MG108.html.
e NCMA, 2008, “Generational Inertia: An Impediment to Innovation?” http://www.ncmahq.org/docs/default-source/default-document-library/articles/cm_feb08_p44.
f DSB, 2009, Report of the Defense Science Board Task Force on Department of Defense Policies and Procedures for the Acquisition of Information Technology, Office of the Under Secretary of Defense for Acquisition, Techology, and Logistics, https://dsb.cto.mil/wp-content/uploads/reports/2000s/ADA498375.pdf.
g NRC, 2010, Achieving Effective Acquisition of Information Technology in the Department of Defense, National Academies Press, https://doi.org/10.17226/12823.
h NRC, 2010, Critical Code: Software Producibility for Defense, National Academies Press, https://doi.org/10.17226/12979.
i M. Schwartz, K.A. Francis, and C.V. O’Connor, 2016, The Department of Defense Acquisition Workforce: Background, Analysis, and Questions for Congress, CRS, https://sgp.fas.org/crs/natsec/R44578.pdf.
j C.H. Porter, J.E. Thomsen, R.T. Marlow, T.M. Geraghty, and A.J. Marcus, 2016, Independent Study of Implementation of Defense Acquisition Workforce Improvement Efforts, Center for Naval Analyses, https://dair.nps.edu/bitstream/123456789/2958/1/SEC809AWF-16-0048.pdf.
k SEI, 2017, DoD’s Software Sustainment Study Phase I: DoD’s Software Sustainment Ecosystem, CMU/SEI-2016-SR-035.
l BPC, 2017, Building a F.A.S.T. Force: A Flexible Personnel System for a Modern Military, https://bipartisanpolicy.org/report/building-a-fast-force.
m DSB, 2018, Design and Acquisition of Software for Defense Systems, Office of the Under Secretary of Defense for Research and Engineering, https://apps.dtic.mil/sti/tr/pdf/AD1048883.pdf.
n NDAA, 2016, Section 809 Panel - Streamlining and Codifying Acquisition, Defense Technical Information Center, https://discover.dtic.mil/section-809-panel.
o DIB, 2019, Software Is Never Done: Refactoring the Acquisition Code for Competitive Advantage, https://innovation.defense.gov/software.
SOURCE: Defense Innovation Board, 2019, Software Is Never Done: Refactoring the Acquisition Code for Competitive Advantage, May 3, https://media.defense.gov/2019/Apr/30/2002124828/-1/-1/0/softwareisneverdone_refactoringtheacquisitioncodeforcompetitiveadvantage_final.swap.report.pdf.