Point 1: Break programs into ~12-18 month projects
The primary objective of Point 1 is to reduce the risk of IT acquisition efforts by very consciously forcing rapid delivery of useful capabilities. Studies have repeatedly shown that smaller projects have a much higher chance of success [Ref 8]. Despite this knowledge, DoD continues to use acquisition processes for IT capabilities that encourage larger programs and extended development or procurement timelines. The solution is straightforward: mandate that IT projects deliver usable capabilities in 12 months or less. In addition to reducing risk, shorter timelines for providing capabilities to users permits timely user feedback that can be incorporated into successive deliveries helping to ensure capabilities are matching user needs. The Office of the Joint Chiefs of Staff has recognized this concept in their recent establishment of the “IT Box” construct for defining requirements [Ref 9]. In essence, the IT Box forces requirements to be constrained to fit within a “time-box”, a set calendar window of development time, so that they can be developed and fielded rapidly.
In order to implement short-duration projects, larger requirements must be divided so that sub portions can be developed and fielded quickly. Agile development methods ensure continuous communication between developers and users minimizing risk that user needs are not understood by the developers [Ref 10}. Use of common IT platforms (see Point 3 below) permits development efforts to address mission capabilities immediately rather than spending months or perhaps years developing a custom infrastructure platform to meet a user requirement. The recommended metric and action for this point is the following: ruthlessly cancel IT projects that do not deliver capabilities useful to the user community within 12 months (the goal is 6 months or less).
Many will assess the 12-month metric and what might be perceived as a draconian recommended action and conclude that this guideline just cannot apply to DoD. They will argue that DoD is too big and its IT solutions too complex to mandate delivery within 12 months for all IT projects. I note in particular that those involved in business enterprise resources planning (ERP) efforts appear to have grown comfortable with fielding timelines that rival those of major weapons programs, often taking a decade or more before delivery of useful capabilities (or in many cases a decision to cancel the program).
It is the case that the complex IT needs of DoD will most often require solutions that are large and complex, therefore necessitating that larger requirements be divided into multiple, perhaps many, short duration projects. DoD’s system engineers must be directed to determine how to best subdivide larger solutions into “bite-sized” pieces. The response from a program manager or engineer that it cannot be done is false and must be rejected.
In order to develop larger IT solutions through a number of short-duration, quick-delivery projects, there is a need to focus significant attention on how to ensure compatibility and interoperability among the separately-developed IT capabilities. This requires employment of formal engineering disciplines such as architectures, standards, iterative testing, and continuous integration. While these engineering disciplines are often employed in DoD IT acquisition efforts, they are most often used withina monolithic program rather than across many projects that may be developed independently. The additional consequence of the current approach is so-called “stove pipe” IT solutions that cannot be effectively integrated into the larger DoD system of systems context.
Fortunately, there are examples of DoD organizations programs that have successfully implementing complex IT efforts with short-duration projects that deliver capabilities to users very quickly. The team that compiled the Report to Congress identified a number of examples in each of the military services, including DISA, TRANSCOM and DLA. In these examples, short duration projects were effective in delivering incremental capabilities to users in less than 12 months. Success in these examples necessitated that the organizations mature the engineering disciplines necessary to ensure the effective interoperation of the separately-developed, incremental projects. Moreover, each of these projects have shown dramatically reduced risk and increased user satisfaction.
DoD’s challenge with implementing short duration, agile projects is twofold. First, DoD must overcome the current cultural comfort with IT programs taking multiple years to deliver capabilities. Unfortunately, many in DoD sincerely believe that it must take years to deliver IT capabilities! Second, and perhaps more significantly, the common practice of “thorough” implementation of DoD 5000 process steps (i.e., not taking advantage of tailoring opportunities) influences acquisition programs toward larger increments and less rapid delivery. Program managers often start with the objective of rapid fielding only to be consumed by the “mandated” documentation and well-intended oversight activities that quickly erase any hopes of rapid fielding. Moreover, it is not just the design program analysis and software development efforts that must be done more quickly to achieve the 12 month target. Contracting, testing, and project oversight decisions must align with the objective of 12 month (or less) deliveries. Contracting and test are separately addressed in Points 2 and 4.
It is useful to conclude the discussion on Point 1 with the observation made in the opening sentence—shorter duration projects are less risky and therefore can and should be done with less oversight and documentation. Rather than using surrogates such as documents to assess progress, with rapid capability delivery the end user provides direct, high-fidelity feedback by actually using the capability. Based on user feedback, successive projects can be modified, cancelled, or accelerated. A DoD mandate to field IT projects in 12 months or less with penalty of project cancellation will provide the motivation to overcome resistance to change. In addition, this mandate must force each of the critical processes supporting capability delivery (oversight, design, development, test, contracting, etc.) to operate on the same expedited timelines.