2.8.5. Program Schedule
Provide a detailed graphic illustrating program milestones, phases, and events. Depicted events will vary by program, but will minimally include key acquisition decision points; principal systems engineering and logistics activities such as technical reviews and assessments; planned contracting actions such as request for proposal (RFP) release, source selection activity, and contract awards; production events and deliveries; and key test activities. (Figure 3 is a notional depiction of the expected level of detail. For example, contract details will vary with the contracting approach and the plan for competition and multiple suppliers; the use of options, re-competes, and/or new negotiated sole source; etc.)
Explain and justify any urgency if it results in needed tailoring for example if it constitutes justification for not providing for full and open competition.
Summarize the analysis justifying the proposed program schedule (list analogous programs or models used to derive schedule).
Figure 3. Notional depiction of the Integrated Schedule for Program
|
CONSIDERATIONS
- If a Technology Development Strategy, the program schedule minimally needs to identify the following:
- contract award dates for major contracts;
- whole system reviews including system requirements review (SRR), system functional review (SFR), and the preliminary design review (PDR);
- competitive prototyping activities;
- major test events such as for prototypes of key systems;
- the technology readiness assessment (TRA);
- final draft pre-Engineering & Manufacturing Development (EMD) review Acquisition Strategy (AS);
- draft RFP for EMD;
- Milestone B; and,
- Initial Operating Capability (IOC).
- If for an EMD AS, the schedule minimally needs to identify the following:
- contract events such as award dates, contract definitization, planned exercise of contract line item numbers, and Integrated Baseline Review (IBR);>
- system level Critical Design Review (CDR), software specification review (SSR), Test Readiness Review (TRR) and Production Readiness Review (PRR);
- key prototyping activities for technology maturation;
- major test events such as operational assessments and integration tests, as well as the operation test readiness review (OTRR);
- maintenance plans, depot maintenance core capabilities stand-up, Training Plan, Source of Repair Assignment Process (SORAP),
- Environment, Safety, and Occupational Health (ESOH) plans events,
- draft RFP for LRIP, final draft LRIP AS submission to MDA staff;
- Milestone C; and,
- Initial operating capability (IOC).
- If for an LRIP AS, the schedule minimally needs to identify the following:
- contract events such as award dates, contract definitization, planned exercising of contract line item numbers, and Integrated Baseline Review (IBR)
- Physical Configuration Audit (PCA), and System Verification Review (SVR);
- Operational and developmental test events including initial operational test and evaluation (IOT&E) and live fire test and evaluation (LFT&E);
- Production quantities for each year;
- maintenance plans, depot maintenance core capabilities stand-up, Training Plan, Source of Repair Assignment Process (SORAP),
- identify the activation schedule for each site in the supply chain required to support the system including the maintenance sites (including depots) and training sites
- Environment, Safety, and Occupational Health (ESOH) plans events
- draft RFP for LRIP, final draft FRP AS submission to MDA staff;
- Full-Rate Production Decision Review (FRP DR); and,
- initial operating capability (IOC) and full operational capability (FOC)
- If for an FRP AS, the schedule should minimally include:
- contract events such as award dates, contract definitization, planned exercising of contract line item numbers, and Integrated Baseline Review (IBR)
- Production quantities for each year;
- maintenance plans, depot maintenance core capabilities stand-up, Training Plan, Source of Repair Assignment Process (SORAP),
- identify the activation schedule for each site in the Production quantities for each year;
- maintenance plans, depot maintenance core capabilities stand-up, Training Plan, Source of Repair Assignment Process (SORAP),
- identify the activation schedule for each site in the supply chain required to support the system including the maintenance sites (including depots) and training sites
- planned or anticipated future increments;
- post-implementation review (PIR); and,
- initial operating capability (IOC) & full operational capability (FOC).
|
2.8.5.1. Interdependencies
Specify programmatic interdependencies with other programs. Discuss the relationship of the interdependencies with program activity on the critical path. If any memorandums of agreement are required to formalize these relationships/ interfaces, list them in the format presented in Table 2. Identify the interface (i.e., the system this product interfaces with); the agency that owns the other system; the authority (e.g., PEO, CAE, delegated PM) responsible for controlling the interface (i.e., the individual who can set the requirement; direct the solution to the interface issue; and direct who provides the funding for the solution); the required by date; and the impact if not completed.
Table 2. Notional table of Required Memoranda of Agreement
|
REQUIRED MEMORANDA OF AGREEMENT
|
|
Interface
|
Cooperating Agency
|
Interface Control Authority
|
Required By Date
|
Impact if Not Completed
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
If using an evolutionary acquisition approach with concurrent increments, state the relationship between the milestones and activities in one increment to those in the other increment(s). Include criteria for moving forward to subsequent phases of the same or other increments.
2.8.6. Risk and Risk Management
Summarize the approach used to identify, analyze, mitigate, track, and control performance/technical/manufacturing cost, schedule, sustainment, and programmatic risk throughout the life of the program.
|
NOTES
- The Program Manager (PM) should establish a risk management process consistent with Guidebook Chapter 4, and summarize the process in the Acquisition Strategy.
- For an EMD AS, if the program is so complex and technically challenging that it would not be practicable to reduce program risk to a level that would permit the use of a fixed-price type contract for EMD, the AS needs to include an explanation of the level of program risk as well as steps that have been taken, and are planned, to reduce risk. Finally a rationale for entry into EMD despite the high level of program risk should be included. This explanation of complexity, technical challenge, and risk will provide the MDA with the needed documentation if other than a fixed-price type contract is to be used for EMD.
- ESOH Risks are assessed in accordance with MIL-STD-882D and reflected here when applicable.
- Spectrum availability and supportability for applicable programs may pose for significant program risk. Spectrum analysis must be done for all applicable programs. (See DAG Chapter 7.)
- The AS is an appropriate place to discuss cost, schedule and performance implications or trades related to risks and risk mitigation, but not for detailed mitigation plans with waterfalls, etc. The Systems Engineering Plan (SEP) is the appropriate document for details on mitigation plans for the noted key technology-related acquisition risks. The SEP or the program’s Risk Management Plan is appropriate for detailed discussion of the risk management process, whereas the Acquisition Strategy should only contain a summary.
|
List and assess any program interdependency issues that could impact execution of the acquisition strategy. If the program is dependent on the outcome of other acquisition programs or must provide capabilities to other programs, the nature and degree of risk associated with those relationships should be specified. Summarize how these relationships and associated risk will be managed at the PM, PEO, and DoD Component levels.
List the key program technologies, their current technology readiness levels (TRL), the basis for including a technology (e.g., available alternative or low-risk maturation path) if it is below the TRL 6 benchmark for Milestone B, and the key engineering and integration risks. NOTE: Key technologies should include those technologies that are part of the system design and those associated with manufacturing the system.
- If conducted, summarize the results of the Technology Readiness Assessment.
- Summarize technology maturation plans and risks for each key technology, engineering risk, and integration risk identified.
- Briefly explain how the program‘s strategy is appropriate given the maturity of the system technology and design.
If the strategy is for the Technology Development Phase:
- Identify alternate technologies that could be employed if a technology chosen for the system does not achieve the maturity necessary to incorporate it into the baseline system design and define their impact on system performance and cost.
- Identify the specific prototyping activities that will be conducted during Technology Development and specify how those activities and any others planned for Engineering and Manufacturing Development will be used to reduce program cost, schedule, and/or performance risk.
Identify the principal programmatic risks (e.g., staffing, resources, infrastructure, industrial base, etc.) and summarize mitigation plans, including key risk-reduction events.
|
NOTES
The Program Manager should summarize the anticipated or existing key acquisition risks for the program and include the related Risk Reporting Matrix (risk cube). The Acquisition Strategy should describe how funding, schedule and performance are planned to be balanced and traded to manage/mitigate key risks.
|
Identify any risks that have been deferred to future increments. Explain why these risks were deferred and whether any residual risks remain in this increment.
|
CONSIDERATION
This section should include, but not be limited to, the risks associated with threats as described in section 2.8.2.
|
The acquisition strategy at the Full-Rate Production/Full Deployment Decision Review should identify principal manufacturing (if applicable), sustainment, and operational risks, and it should summarize mitigation plans, to include key risk reduction events.
DAG Tutorial 
