A Roadmap for Reforming the DoD’s Acquisition of Information Technology


Posted: March 14, 2016 | By: John M. Gilligan

Point 5:  Employ acquisition templates

The final point of Phase 1 of the Roadmap is the recommended adoption of tailored templates that can guide program offices as they are strive to tailor DoD’s 5000 Directives to suit information technology acquisition programs.  The templates provide a point of departure for IT program offices to quickly determine how their program should be structured.  Four templates have been developed under DoD sponsorship.  These templates were summarized and endorsed in the December 2010 Report to Congress and align with the major types of IT acquisitions:

  1. Application Software Development
  2. Commercial Off the Shelf  (COTS) Capabilities
  3. Integrated COTS
  4. IT Services

As an example, the templates reflect the fact that an acquisition program that is to develop application software (on a standard platform) has different activities, risk areas, and indicators of progress when compared to the procurement of a COTS solution.  However, experience has shown that by following DoD 5000 processes, DoD program offices typically migrate from a COTS solution approach to a developed solution approach.  This should not be surprising; DoD 5000 is targeted for weapon systemdevelopment.  Templates help to avoid this mistake.

A quick review of the history of programs such as Net-Centric Enterprise Services (NCES) or the Navy- Marine Corps Internet (NMCI) shows what happens when IT programs attempt to use a DoD 5000-based approach to acquire commercial IT capabilities.  In the case of NCES, the objective of rapidly procuring COTS software products evolved into a lengthy program to acquire and then modify COTS products.  Likewise, NMCI was treated, not as an albeit large contract for commercial services, but as a developed program that required formal acquisition milestones, independent OT&E, and other acquisition processes appropriate for a developmental program.  In both instances, the envisioned acquisition of commercial products and services evolved into developmental programs significantly delaying fielding of important capabilities and dramatically increasing risk and cost.   While NMCI and NCES may be some of the most visible examples of inappropriate or failure to tailor DoD acquisition processes, there are many other examples where well intended program offices and oversight bodies have failed to recognize the unique needs of different types of IT acquisition programs.

The specific characteristics of the templates are only described generally in this paper.  The reader is recommended to review A New Model for Acquiring Government Information Technology [Ref 13] for additional insight into the recommended templates.


Figure 1: Comparison of Application Software and COTS Templates

Figure 1 contrasts a few of the top-level characteristics and processes for the Application Software Development Template and the COTS Template.  It should be noted that this abbreviated comparison does not show the iterative nature of the Development and Demonstration (in the case of Application Software Development Template) and Demonstration and Deployment (in the case of the COTS Template).  It can be seen that the tasks prior to Milestone B are significantly different, with the COTS Template focusing on assessing the commercial marketplace rather than on prototypes and the Milestone B decision being a procurement decision rather than a build decision in the case of the Application Software Development Template.

Key elements of the Application Software Development Template are as follows:

  • Participation by the end user throughout the process.
  • Recognizing the evolving nature of IT requirements, significantly streamlined predevelopment analysis, prototyping, and documentation focused on the initial increment (rather than on the full scope of requirements).
  • Close linkage of risk reduction/prototyping and incremental development such that there is no loss of continuity and no break in progress around the Milestone B decision.
    Rapid, iterative increments of software development (12-18 months) with cost, schedule and performance characteristics assigned as each increment is undertaken.
    Fielding of (agile) software iterations in weeks or months as they are approved by users during development.
  • Use of frequent in process reviews (IPRs) to monitor status and adjust development if necessary

Key elements of the COTS Template include the following:

  • Recognition that the objective is procurement of a product rather than development.
  • After procurement, the unmodified COTS product is rapidly demonstrated and then deployed to end users.
  • If the user requirements cannot be adequately satisfied with (unmodified) COTS solutions, the program is stopped rather than evolving into a development program.

The third template, Integrated COTS, addresses the fact that DoD often procures multiple COTS products that have been proven individually, but never configured as an integrated capability.  This template, therefore, addresses the need for integration of the COTS components and incremental fielding of the integrated COTS capability prior to a full fielding decision.  The fourth template,IT Services, recognizes the unique need to define service levels based on market research and customer analysis as well as the importance of focusing on ways after contract award to ensure in a continued reduction in the cost of services through employment of evolving technology and process improvement.

Individual programs and projects may also require a combination of templates.  For example, enterprise resource planning efforts (ERP) often have a procurement acquisition component for a COTS ERP package (i.e., appropriate for the COTS Template) as well as either an applications software acquisition component (i.e., employing the Application Software Development Template) or a need to integrate several software packages (i.e., using the Integrated COTS Template is appropriate).   Using the templates as a point of departure, a program or project office can quickly adapt them to suit the specific needs of an individual program or project.

Want to find out more about this topic?

Request a FREE Technical Inquiry!