The previous article ended on a point worth repeating: the SE Engine does not run once. It cycles — through every phase of a project's life, at increasing fidelity. This article is about those phases: what each one is for, what it must produce, and the decision gates between them that decide whether the project continues at all.
The structure is NASA's — seven phases, Pre-Phase A through Phase F, from NPR 7120.5E as presented in the public-domain Systems Engineering Handbook — but the logic is universal: mature the definition before committing the money, and force an explicit decision at every point where the cost of continuing jumps.
The seven phases
| Phase | Name | Purpose | What it must produce |
| Pre-A | Concept Studies | Produce a broad range of ideas and alternatives; determine feasibility of the desired system | Feasible concepts — simulations, analyses, study reports, models, mockups |
| A | Concept & Technology Development | Determine feasibility and desirability of a proposed system; baseline system requirements and the mission concept | System concept definition; baseline requirements and ConOps; identified technology needs |
| B | Preliminary Design & Technology Completion | Define the project in enough detail to establish an initial baseline capable of meeting the need; preliminary design per end product | Preliminary designs, specifications and interface documents, prototypes, trade results |
| C | Final Design & Fabrication | Complete the detailed design; fabricate hardware and code software | Detailed final designs; fabricated components; developed software |
| D | System Assembly, Integration & Test, Launch | Assemble and integrate the system; build confidence it meets its requirements; transition to use | An operations-ready system, with its enabling products |
| E | Operations & Sustainment | Conduct the mission and sustain support for it | The mission, performed |
| F | Closeout | Execute the disposal plan; analyse returned data | Orderly end of life |
Two big groupings sit above the phases. Formulation (Pre-A through B) is where the definition matures while spending is still comparatively small. Implementation (C through F) is where the money goes. The boundary between them — KDP C, approval for implementation — is where the organisation formally decides the definition is mature enough to build. Readers of our opening article will recognise the cost-commitment curve underneath this structure: Formulation is where costs get committed; Implementation is where they get incurred.
Key Decision Points: the phases have doors
Phases are separated by Key Decision Points (KDP A through F, each admitting you to the phase of the same letter). A KDP is not a review of the engineering — it is the governance decision that the project has earned its next phase: definition mature enough, risk understood well enough, resources actually available. The engineering reviews feed it; they do not replace it.
That distinction — technical review versus gate decision — is one of the most exportable ideas in the whole framework. Projects that let a passed design review stand in for an honest continue/stop decision have removed the one mechanism that kills doomed projects while they are still cheap to kill.
The reviews, and what each one is asking
| Review | Sits near | The question being asked |
| MCR — Mission Concept Review | End of Pre-A | Is this mission worth studying seriously? |
| SRR — System Requirements Review | Phase A | Are the requirements complete, coherent and traceable to the need? |
| SDR / MDR — System / Mission Definition Review | End of A | Is the functional baseline sound enough to design against? |
| PDR — Preliminary Design Review | End of B | Does the preliminary design meet the requirements — and is it mature enough to commit to build? Feeds KDP C |
| CDR — Critical Design Review | In C | Is the detailed design complete enough to fabricate and code against? |
| SIR — System Integration Review | C/D boundary | Are we ready to start integrating — products, facilities, procedures? |
| ORR — Operational Readiness Review | In D | Are the system, procedures and people ready to operate? |
| FRR — Flight Readiness Review | End of D | Is everything ready to commit to launch/deployment? |
| DR — Decommissioning Review | Into F | Is it time, and is the plan in place, to end safely? |
How the engine maps onto the phases
The handbook is precise about this, and the precision is useful. The full engine — design processes and realization processes — cycles five times from Pre-Phase A through Phase D. Early passes run the whole engine conceptually: even in Pre-Phase A, concepts are "realized" as models, mockups and simulations and checked against the draft requirements — a methodical rehearsal, not the formal verification campaign. Phases C and D then split the engine between them: C finishes the left side (final requirements, final designs, fabrication begins), D runs the right (integrate, verify, validate, transition). The technical management processes cycle seven times — every phase, Pre-A through F, because risk, configuration and decisions do not stop when development does.
Reading this as a supplier
- Know which phase your customer is in. A supplier delivering detailed design answers into a customer's Phase A is answering questions nobody has earned yet — and burning trade space the customer still needs open.
- Your deliverables are review evidence. Whatever your statement of work says, your outputs will be judged by what the customer's next review needs. Ask which review your work feeds; scope to that.
- Phase boundaries are when requirements move. The KDP decisions above you reshape budgets and baselines below you. Contract accordingly — change traffic near customer gates is structural, not bad luck.
- The phase names are NASA's; the questions are everyone's. Your programme may call them gate 2 and gate 3, or PDR and CDR under an ARP4754A process. Map the vocabulary once and the whole structure transfers.
Frequently asked questions
Do all seven phases apply to every project?
The questions apply; the ceremony scales. A small project may pass through a phase in weeks with one review standing in for several. What does not scale away is the sequence — a project that starts fabrication while its requirements are still moving has skipped Formulation whether or not anything was named Phase B.
What exactly happens at a KDP?
A decision authority reviews the evidence — technical maturity, risk posture, cost and schedule realism — and decides whether the project proceeds, holds, redirects or ends. It is a governance act informed by the technical reviews, not another technical review.
Why do Phases C and D split the engine?
Management control. Finishing design and beginning fabrication (C) and integrating, proving and delivering (D) are different risk regimes, and the handbook notes the split exists to keep closer control over each half. The engine is the same; the supervision tightens.
How does this relate to PDR and CDR under ARP4754A?
Directly — civil aviation's development assurance process runs design reviews with the same intent, often the same names, anchored to the same logic of earning the next commitment. The NASA framing adds the explicit KDP layer above the reviews, which many aerospace programmes leave implicit.
Is Phase E really systems engineering?
Yes, though the work changes character: sustaining engineering, anomaly response, and managing modifications — which re-enter the appropriate earlier phase to be developed. The technical management processes run through operations precisely because the system keeps changing after delivery.
If your customer's gates keep surprising you — or your own project has reviews but no real decisions — that is a solvable structural problem, and it is our kind of work. Get in touch.