Mandatory Procedures for Major Defense Acquisition Programs

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 them. 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 up-to-the-minute data, it can be used by the PM throughout the program (from RFP to DD-250Z) to refine these objectives and thresholds where Risk Reduction and a careful assessment of risks are important criteria.

In this way, RiskTrak integrates with any event-oriented management process by enabling an ongoing risk management process through each milestone of a program, providing for a clear view and control of risks before each decision point. RiskTrak's network connectivity, reporting capabilities and system of network notifications, provide ease of communication of those risks, and fosters a true atmosphere of teamwork.

These same features also benefit DoD oversight activities, providing ease of information sharing between all offices involved with program risk mitigation RiskTrak and DoD 5002-R Program Design RiskTrak provides the means for the PM to manage risk throughout the systems engineering process. Risks can be identified and mitigation strategies or contingency plans implemented through all life-cycle needs and system elements.

RiskTrak's risk management process allows the PM to fulfill the risk management effort in all system analysis and control activities and systems engineering process with particular emphasis on software engineering risks RiskTrak implements a system of 'Interview Experts,' electronic questionnaires that convert qualitative input into quantitative data, used to create and update projects. The Interview Experts help standardize the Program development and risk management process. RiskTrak's standard Interview Experts include an adaptation of the DoD Software Engineering Institute (SEI) Taxonomy-Based Questionnaire (TBQ).

The SEI TBQ is ideally suited to large software intensive programs. RiskTrak also includes an Interview Expert for Y2K Programs, based on the U.S. General Accounting Office Year 2000 Program Guidelines (GAO/AIMD-10.1.14). Interview Experts may be created for any DoD program plan, process, WBS or audit questionnaire.

RiskTrak and DoD 5002-R Program Assessments & Decision Reviews RiskTrak can be used in the IPT process by Overarching IPT (OIPT) leaders to prepare their integrated assessment to the DAB or MAISRC RiskTrak can be used by PMs in Integrating IPTs (IIPTs) in the development of strategies to present to Working-Level IPTs (WIPTs) particularly in the areas of cost estimates and cost-performance trade-offs RiskTrak can be used with / by the Cost Analysis Improvement Group (CAIG) in its cost risk appraisal process RiskTrak and DoD 5002-R Periodic Reporting RiskTrak enables the PM to correct program deviations and create the action plan for submission to the MDA and the correction of deviations RiskTrak can be used by the PM to generate the Major Automated.