Mandatory Procedures for Major Defense Acquisition Programs (MDAPS) and Major Automated Information System (MAIS) Acquisition Programs Overview of DOD 5000.2-R

DOD Regulation 5000.2-R of 1996 specifies "Mandatory Procedures for Major Defense Acquisition Programs (MDAPS) and Major Automated Information Systems (MAIS)"

Its stated purpose is "to establish a simplified and flexible management framework for translating mission needs into stable, affordable, and well-managed programs" (DOD 5000.2-R). The regulation is organized into six parts with six appendices and contains thousands of specific requirements pertaining to acquisition programs. In contrast to DOD 5000.2-R, which defines an overarching DOD acquisition management process and mandatory procedures, the FAR regulates acquisition planning and contracting.

Analysis of DOD 500.2-R in Relation to Systems Engineering

Mandatory procedures for acquiring major systems are prescribed in DOD 5000.2-R

. These requirements will influence choices in acquisition planning for product lines. Despite the comprehensive size of DOD 5000.2-R, there are only a relatively small number of requirements that directly relate to product lines

. These requirements are summarized below.

Evaluation of Requirements Based on Commercial Market Potential [2.3.1]

In developing system performance requirements, DOD Components shall evaluate how the desired performance requirements could reasonably be modified to facilitate the use of potential commercial or non-developmental items, components, specifications, open standards, processes, technology

Open Systems [3.3.1]

PMs shall specify open systems objectives and document their approach for measuring the level of openness of systems, subsystems, and components to be acquired, and devise an open systems strategy to achieve these requirements. An open systems strategy focuses on fielding superior war fighting capability more quickly and more affordably by using multiple suppliers and commercially supported practices, products, specifications, and standards, which are selected based on performance, cost, industry acceptance, long-term availability and supportability, and upgrade potential

Commercial and Non-Developmental Items [3.3.2.1]

Market research and analysis shall be conducted to determine availability and suitability of commercial and non-developmental items (NDI)

Critical Product and Technology Competition [3.3.2.4]

The acquisition strategy shall describe the approaches the PM will use (i.e., requiring an open systems architecture, investing in alternate technology or product solutions, breaking out a subsystem or component, etc.) to establish or maintain access to competitive suppliers for critical areas at the system, subsystem, and component levels

Competition [3.3.5.1]

Component breakout shall be considered on every program and shall be done when there are significant cost savings, when the technical or schedule risk of furnishing government items to the prime contractor is manageable, and when there are no other overriding Governmental interests

Best Practices [3.3.5.2]

PMs shall avoid imposing government-unique requirements that significantly increase industry compliance costs. Examples of practices designed to accomplish this direction include: open systems approach that emphasizes commercially supported practices, products, specifications, and standards; best value evaluation and award criteria; use of past performance in source selection, results of software capability evaluations; government-industry partnerships; and the use of pilot programs to explore innovative practices

Open Systems Design [4.3.4]

PMs shall address the use of open standards in the design of all systems elements (mechanical, electrical, software, etc.). This approach shall be followed to develop a standards-based architecture in designing systems

Software Engineering [4.3.5]

Software shall be managed and engineered using best processes and practices known to reduce cost, schedule, and performance risks.

It is DOD policy to design and develop software systems based on systems engineering principles, to include:

Developing software system architectures that support open system concepts; exploit COTS computer systems products; and provide for incremental improvements based on modular, reusable, extensible software; Identifying and exploiting software reuse opportunities, Government and commercial

Interoperability [4.3.9]

Compatibility, interoperability and integration are key goals that ... shall be specified and validated during the requirements generation process. The DOD JTA [Joint Technical Architecture] is mandatory for all emerging systems and systems upgrades

Work Breakdown Structure (WBS) [4.4.2]

A program WBS shall be established that ... shall define the total system to be developed or produced; display the total system as a product-oriented family tree composed of hardware, software, services, data, and facilities; and relate the elements of work to each other and to the end product

Integrated Product Teams (IPTs) [5.4, 5.4.2]

Working-Level IPTs [WIPTs] shall focus on a particular topic such as cost / performance, test, or contracting. An Integrating IPT shall coordinate WIPT efforts. The PM shall form an Integrating IPT to support development of strategies for acquisition and contracts, cost estimates, evaluation of alternatives, logistics management, cost-performance tradeoffs, etc.

The significant aspect of these requirements, which apply to all major system acquisitions and are a model for others, is that product lines are inherently one of the most effective ways to realize...

Product line activities recommended by the SEI's Framework for Software Product Line Practice are fully responsive to these requirements
. They include the following:

Performing a domain analysis to identify the commonality and variability across the application domain and establish requirements for the product line architecture and other components of the asset base

Conducting market research and analysis to determine the availability of suitable product line assets from commercial-off-the-shelf (COTS) products, legacy system, or NDI sources

Seeking product line opportunities (at the system, subsystem, or component level) and establishing infrastructure support to promote and encourage participation in collaborative development / acquisition efforts among organizational units

Providing specific guidance for building and communicating a business case, and developing a concept of operations for how a product line approach will work in the enterprise

Developing an acquisition strategy and implementing competitive contracting strategies, using performance-based specifications, and preparing request for proposals (RFPs) for acquiring product line assets and derivative products

Ensuring the software product line is suitably integrated with the program's systems engineering process and the PM's open systems strategy

Ensuring the software product line asset base (e.g., product line architecture, reusable software components) and derivative products are responsive to the system requirements (e.g., interoperability) that are allocated to software (at the system, subsystem, or component level)

Ensuring mainstream product line activities (domain engineering and application engineering) and their subordinate tasks are reflected in a work breakdown structure (WBS) and appropriately "rolled-up" and integrated with the PM's overarching "program WBS"

Forming IPTs to serve as a "virtual" product line organization to assist in performing tasks such as those identified above

These framework practices apply to both DOD and industry (including DOD contractors) and are representative of best practice. They are compatible with achieving conformance with DOD 5000.2-R's software-related requirements - especially those relating to component breakout, standards-based architecture, software best practices, interoperability, open-systems design, and use of integrated product teams to perform cost and schedule, performance, and risk tradeoffs

III. Assessing the Value of DOD 5000.2-R: "RiskTrak and the Critical Role of Risk Management in DoD Directive 5000.2-R"

DoD Directive 5000.2-R applies to all elements of the DoD. Its procedures are mandatory for Major Defense Acquisition Programs (MDAPs), Major Automated Information System (MAIS) Acquisition Programs and others specified in the Regulation, as well as serving as a general model for other than MDAPs and MAISs. The importance of Risk Management as stated in DoD 5000.2-R:

The acquisition management system governed by this Directive provides for a streamlined management structure and event-driven management process that emphasizes risk management and affordability and that explicitly links milestone decisions to demonstrated accomplishments.

Project Managers (PMs) and other acquisition managers shall continually assess program risks. Risks must be well understood, and risk management approaches developed, before decision authorities can authorize a program to proceed into the next phase of the acquisition process

RiskTrak and DoD 5000.2-R Program Structure

DoD Directive 5000.2-R calls for a Total System Approach to Acquisition Programs including; equipment, personnel, security procedures, system operations in intended environments as well as non-intended environments, compatibility and interoperability with other systems, operational and support infrastructure, training and training devices, required operational data and potential environmental impact and environmental compliance. As every acquisition program is different, the number of risk factors to be analyzed, reported and managed is enormous

RiskTrak, a Windows-based tool, answers the call by enabling users to identify, estimate, analyze, report, communicate and manage risk throughout the duration of the Acquisition Program. RiskTrak is network software that enables the Program Office to connect users throughout a building or around the world. RiskTrak can be used by PMs to establish their Detailed Risk Management Plan (as instructed in Section 3.3.2)

RiskTrak offers a complete package for the PM to perform this function:

Access to current data on a 24x7x365 basis

Import and export data with any ODBC-compliant database

SQL engine to search and sort project data or across multiple projects

Full range of standardized and ad-hoc reporting options

Perform real-time "What if ... " and "Go / No-Go" analysis

Attach additional files to each program risk and mitigation element

RiskTrak allows for continuous risk assessment and has the ability to generate, analyze and monitor mitigation and/or contingency plans for specific areas of risk.

RiskTrak can be used by PMs to help establish Acquisition Program Baselines (APBs) and to create their Milestone Decision Authority (MDA) proposals for objectives and thresholds for costs, schedules and performance. RiskTrak gives the PM the ability to quantify Project / Program risks in real time

. It can be used to perform tradeoff analyses prior to the finalizing their recommended acquisition strategy as well as in post-production support with its ability to create an archived historical database

As the RiskTrak project database continually presents…