Pre-Milestone A/B Checklist
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 program leaders remain engaged is important to get the capability into service quickly and cost-effectively and to begin the process of incremental improvements based 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 development program 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 major source of requirements instability during the development phase. This can be of particular importance when a system must operate in a system-of-systems environment.
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 the stakeholders. Failure to define the system’s KPPs simply and clearly at Milestone A is a first step to requirements instability and overruns later.