1. The deadline from nowhere

Andy Weir’s Project Hail Mary is about a scientist who wakes up with a mission he did not choose and a problem he must solve before a deadline he cannot move. Much of the book is about working backward from that deadline, deciding what matters and what can be skipped. Development phases and decision gates are the programme’s way of doing the same thing: defining what must be true before the next stage begins.

Entry 293 introduced program timeline. This entry focuses on the phases and gates that structure the work.

2. The purpose of a decision gate

A decision gate is a point where the programme stops and asks whether to proceed. It is not a bureaucratic ritual. It is a chance to cancel, redirect, or reform before more money and time are spent. A good gate has:

  • Clear entrance criteria.
  • Clear exit criteria.
  • An honest assessment of technical maturity.
  • A review of risk, cost, and schedule.
  • A named decision-maker.

Skipping gates is how programmes discover problems too late.

3. Typical phases for the desktop

For the desktop, a practical phase structure might be:

  • Phase 0: concept and feasibility. Define the objective, identify customers, assess technology readiness, estimate cost and schedule.
  • Phase A: preliminary design. Select architecture, establish interfaces, define requirements, begin regulatory engagement.
  • Phase B: critical design. Complete detailed design, release manufacturing drawings, freeze requirements, initiate long-lead procurement.
  • Phase C: manufacturing and assembly. Build the platform, procure components, conduct inspections and subassembly tests.
  • Phase D: qualification and acceptance. Environmental testing, functional testing, launch integration, final reviews.
  • Phase E: operations. Launch, commissioning, service delivery, anomaly response, end-of-life planning.

Each phase consumes more resources than the one before. The cost of a bad decision rises sharply as the programme advances.

4. Reviews that matter

Common reviews include:

  • Mission concept review: is the objective worth pursuing?
  • System requirements review: do we understand what the system must do?
  • Preliminary design review: is the chosen architecture feasible?
  • Critical design review: is the design complete enough to build?
  • Test readiness review: are we ready to test what we built?
  • Flight readiness review: are we ready to launch?
  • Operational readiness review: are we ready to operate after launch?

Each review produces a record of what was decided and what risks remain.

5. Decision criteria for the desktop

At each gate, the desktop programme should ask:

  • Does the design still meet the objective?
  • Are the risks understood and acceptable?
  • Is the budget sufficient for the next phase?
  • Is the schedule still credible?
  • Are regulatory and customer commitments aligned?
  • Can the team execute the next phase?

A gate should not be passed because of momentum or sunk cost. It should be passed because the evidence supports going forward.

6. Gates as communication

Decision gates are also a communication tool. They tell investors, customers, regulators, and team members what has been achieved and what comes next. A clear gate structure builds confidence. An opaque or skipped gate structure erodes it.

For a new programme, the ability to show evidence at each gate may be as important as the technical result.

What this changes

  • Development phases divide the programme into stages with increasing commitment.
  • Decision gates are formal points where the programme assesses whether to continue.
  • Reviews cover concept, requirements, design, test, flight, and operational readiness.
  • Gate criteria include technical maturity, risk, cost, schedule, and team capacity.
  • Gates are both a risk control and a communication tool.
  • The next entry will cover first launch and early operations.