. "Summary." Pre-Milestone A and Early-Phase Systems Engineering: A Retrospective Review and Benefits for Future Air Force Acquisition. Washington, DC: The National Academies Press, 2008.
The following HTML text is provided to enhance online
readability. Many aspects of typography translate only awkwardly to HTML.
Please use the page image
as the authoritative form to ensure accuracy.
Pre-Milestone A and Early-Phase Systems Engineering: A Retrospective Review and Benefits for Future Air Force Systems Acquisition
BOX S-1
Pre-Milestone A/B Checklist
Concept Development
Have at least two alternative concepts to meet the need been evaluated?
The purpose of alternatives is to stimulate thinking to find the simplest, fastest, and cheapest solution.
Can an initial capability be achieved within the time that the key program leaders are expected to remain engaged in their current jobs (normally less than 5 years or so after Milestone B)? If this is not possible for a complex major development program, can critical subsystems, or at least a key subset of them, be demonstrated within that time frame?
Achieving capabilities or demonstrating critical subsystems while key programleaders remain engaged is important to get the capability into service quicklyand cost-effectively and to begin the process of incremental improvementsbased on operational experience.
Will risky new technology have been matured before Milestone B? If not, is there an adequate risk mitigation plan?
The development of risky new technology in parallel with a major developmentprogram can be costly in terms of both time and money.
Have external interface complexities (including dependencies on other programs) been identified and minimized? Is there a plan to mitigate their risks?
Complex, ill-defined, external requirements and interfaces can be a majorsource of requirements instability during the development phase. This can beof particular importance when a system must operate in a system-of-systemsenvironment.
Key Performance Parameters and CONOPS
At Milestone A, have the KPPs been identified in clear, comprehensive, concise terms that are understandable to the users of the system?
It is important that KPPs be expressed in terms understandable to all of thestakeholders. Failure to define the system’s KPPs simply and clearly at Milestone A is a first step to requirements instability and overruns later.