Dau acquisition program baseline

The PM will:. Risk management plans will address risk identification, analysis, mitigation planning, mitigation implementation, and tracking.

Opportunity management will identify potential opportunities to include technology development that could have a positive impact on providing better value in performance, improved mission capability, and reduced cost and schedule. The most important decisions to control risk are made early in a program life cycle. PMs and teams must understand the capabilities under development and perform a detailed analysis to identify the key risks. During the early phases, the program works with the requirements community to help shape the product concept and requirements.

Once the concept and requirements are in place, the team determines the basic program structure, the acquisition strategy, and what acquisition phase to enter based on the type and level of key risks. Risk steers planning and tailoring. If technology maturity or requirements stability risks exist, the PM should structure a program to enter the life cycle at Milestone A.

For example, if there is some doubt as to whether the program can achieve the requirements, the PM should consider a risk reduction phase with competitors building and testing prototypes in order to validate achievability of the requirements. Programs also may use prototypes to quantify the impact of technology on performance, demonstrate the ability to integrate new technologies into mature architectures, and to reduce risk and cost.

If the technologies are mature, the integration of components is at acceptable risk, and the requirements are stable and achievable, the PM can consider entering directly at Milestone B to begin Engineering and Manufacturing Development EMD. Statute requires PMs to document a comprehensive approach for managing and mitigating risk including technical, cost, and schedule risk in the Acquisition Strategy. Likewise, DoD policy requires programs to summarize the top program risks and associated risk mitigation plans in the Acquisition Strategy.

Policy also requires programs to describe their technical approach, including key technical risks, and management and execution of risk mitigation activities, in the Systems Engineering Plan SEP.

Phase specific content from the RIO guide can also be found on the phase pages. Figure Risk and Issue Management Process Overview. It is normally used in conjunction with cost plus and fixed-price incentive contracts with discrete work scope. The purpose of EVM is to ensure sound planning and resourcing of all tasks required for contract performance.

It promotes an environment where contract execution data is shared between project personnel and government oversight staff and in which emerging problems are identified, pinpointed, and acted upon as early as possible.

EVM provides a disciplined, structured, objective, and quantitative method to integrate technical work scope, cost, and schedule objectives into a single cohesive contract baseline plan called a performance measurement baseline for tracking contract performance. PMs must comply with the records management requirements of Chapter 31 of Title 44, U. DoDI Program Battle Rhythm. As for setting a battle rhythm, the key is to remember PMs are what they do—what is on the calendar.

To set a good battle rhythm, routinely review the calendar to see where time is being spent. Every PM can commit to a daily routine of reviewing their calendar and recognizing how much of their time is committed to Leadership An example battle rhythm is depicted in Table 3.

Table 6: Battle Rhythm Example. As the program leader, the PM, along with the other key leaders on the program, sets a rhythm along with a culture that empowers the PMO team. One thing the PM may want to consider is how the battle rhythm addresses or compensates for real or perceived personal or PMO challenges. As appropriate, given IPT dynamics, daily and weekly assessments help maintain an overall program execution status.

This information flows into part of the overall daily, weekly, monthly, and quarterly program reporting process cycle. Some work activity, especially management efforts such as cost, schedule, and risk management are cyclical. The event-driven and cyclical activiites are planned into a battle rhythm that aligns with the major events for management of the program as outlined in the program IMP.

It is critical that both technical and management tasks are tracked within the IMS. PMO team activities such as contracting actions and budget execution activities are tracked in the same schedule as the technical work, thus allowing for a complete picture for the program team on work that needs to be accomplished. The Acquisition Program Baseline APB may not change, but the details to reach that baseline will likely need to be adjusted as the program progresses.

Leading that effort with a realistic battle rhythm that allows for adjustments gives the team confidence to meet program execution challenges and grow in skill and ability. The PM-established and -led battle rhythm provides a higher probability of delivering a system that meets requirements within established cost and schedule. As a solid understanding of requirements, both explicit and implicit, and realistic funding profile are necessary at the initiation of an acquisition, so also is a reasonable and realistic plan and schedule of work.

Sound schedules merge with cost and technical data to influence program management decisions and actions. Robust schedules used in a disciplined manner help stakeholders make key go-ahead decisions, track and assess past performance, and predict future performance and costs. This development and integration cannot happen on its own. Leadership example and active use of the tools are required.

The IMP documents the significant criteria necessary to complete the accomplishments, and ties each to a key program event. The strategy evolves over time and should continuously reflect the current status and desired goals of the program. The strategy should address capability requirements for system performance likely to evolve during the life cycle because of evolving technology, threat, or interoperability needs or to reduce program cost or schedule and enable technology refresh.

The acquisition strategy defines the relationship between the acquisition phases and work efforts, and key program events such as decision points and reviews. Acquisition strategies are baseline plans for the execution of the program and should be prepared and submitted in time to obtain approval to support more detailed planning and the preparation of RFPs.

The acquisition strategy is an approved plan; it is not a contract. Minor changes to the plan reflected in the acquisition strategy due to changed circumstances or increased knowledge are to be expected and do not require MDA pre-approval. Major changes, such as contract type or basic program structure, do require MDA approval prior to implementation. All changes should be noted and reflected in an update at the next program decision point or milestone.

A rapid, iterative approach to capability development reduces cost, avoids technological obsolescence, and reduces acquisition risk.

Consistent with that intent, acquisitions will rely on mature, proven technologies and early tester involvement. Planning will capitalize on commercial solutions and non-traditional suppliers, and expand the role of warfighters and security, counterintelligence, and intelligence analysis throughout the acquisition process.

Acquisition programs will be designed to facilitate capability enhancements by using open systems architectures and common, open, and consensus-based standards.

An open system design supports sustainment and rapid integration of new or updated subsystems into the platform. To facilitate a flexible and rapid acquisition process, MDAs, program managers PMs , and other relevant authorities will implement certain processes described in [Flexible Implementation].

MDAs will structure program strategies and oversight, phase content, the timing and scope of decision reviews, and decision levels based on the specifics of the product being acquired, including complexity, risk, security, and urgency to satisfy validated capability requirements.

Technologies successfully demonstrated in an operational environment via the Rapid Prototyping procedures in the Middle Tier Acquisition pathway, or other prototyping authorities, may be transitioned to major capability acquisition programs at decision points proposed by the PM and approved by the MDA.

The technologies may provide the technical foundation for a formal acquisition program, incrementally improve a program capability in support of approved requirements, or support the development and insertion of more efficient program components. Similarly, products and technologies that have been successfully demonstrated via the Rapid Fielding procedures under the Middle Tier Acquisition pathway may provide the basis for a program developed in accordance with the procedures in this issuance.

PMs for Middle Tier programs will identify and develop the statutory and regulatory information needed to facilitate an efficient pathway transition.

DoDI The DAG is intended to inform thoughtful program planning and facilitate effective program management. The PM uses PS analyses e. The acquisition strategy and the PSS should include the transition plan from interim contractor support to organic, contractor logistics support, or a combination of both. The business approach detailed in the acquisition strategy should be designed to manage the risks associated with the product being acquired.

It should fairly allocate risk between industry and the government. The approach will be based on a thorough understanding of the risks associated with the product being acquired including security, FOCI, supply chain risks to acquisition, and industrial base concerns and the steps that should be taken to reduce and manage that risk.

The business approach should be based on market analysis that considers market capabilities and limitations. The incentives in any contract strategy should be significant enough to clearly promote desired contractor behavior and outcomes that the government values, while also being realistically attainable.

It focuses technical efforts on requirements analysis. The System Requirements Review SRR is a multi-disciplined technical review to ensure that the developer understands the system requirements and is ready to proceed with the initial system design. This review assesses whether the system requirements are captured in the system performance specification sometimes referred to as the System Requirements Document SRD. The System Functional Review SFR is held to evaluate whether the functional baseline satisfies the end-user requirements and capability needs and whether functional requirements and verification methods support achievement of performance requirements.

At completion of the SFR, the functional baseline is normally taken under configuration control by the government. The PDR ensures the preliminary design and basic system architecture are complete, that there is technical confidence the capability need can be satisfied within cost and schedule goals and that risks have been identified and mitigation plans established.

The PDR establishes the allocated baseline. The Critical Design Review CDR confirms the system design is stable and is expected to meet system performance requirements, and confirms the system is on track to achieve affordability and should-cost goals as evidenced by the detailed design documentation.

The CDR establishes the initial product baseline. The System Verification Review SVR is the technical assessment point at which the actual system performance is verified to meet the requirements in the system performance specification and is documented in the functional baseline. The Functional Configuration Audit FCA is the technical audit during which the actual performance of a system element is verified and documented to meet the requirements in the system element performance specification in the allocated baseline.

Production readiness increases over time with incremental assessments accomplished at various points in the life cycle of a program. The Physical Configuration Audit PCA is a formal examination of the "as-built" configuration of the system or a configuration item against its technical documentation to establish or verify its product baseline. A successful PCA provides the Milestone Decision Authority MDA with evidence that the product design is stable, the capability meets end-user needs and production risks are acceptably low.

At the conclusion of the PCA, the final product baseline is established and all subsequent changes are processed by formal engineering change action. It typically involves a review of earlier or lower-level test products and test results from completed tests and a look forward to verify the test resources, test cases, test scenarios, test scripts, environment and test data have been prepared for the next test activity.

A TRR provides the formal approval authority with a review showing that the system is ready to enter the test and that the funding and execution of a test executes the test and gathers the required information. TRRs assess test objectives, test methods and procedures, test scope, safety, and whether test resources have been properly identified and coordinated.

TRRs are also intended to determine if any changes are required in planning, resources, training, equipment, or timing to successfully proceed with the test. If any of these items are not ready, senior leadership may decide to proceed with the test and accept the risk, or mitigate the risk in some manner. DoDI Technical Reviews and Audits Purpose of Technical Reviews and Audits For DoD weapon systems development, a properly tailored series of technical reviews and audits provide key points throughout the life cycle to evaluate significant achievements and assess technical maturity and risk.

Technical Baselines and Technical Reviews The technical baseline including the functional, allocated and product baselines established at the conclusion of certain technical reviews inform all other program activity.

The technical baseline provides an accurate and controlled basis for: Managing change. Program technical plans and schedules, which also inform the APB.