Aerospace programme risk management decides which uncertainties can change certification, supplier qualification, cost, or a customer milestone. It also decides who may accept them. A date on a chart is not that decision. Airworthiness limits, a sole qualified source, and a late test can all move one milestone. Only one of those belongs in a generic risk log. This guide shows leaders how to govern those risks without rebuilding the schedule.
Talk with a MustardSeed PMO expert about aerospace programme risk at https://www.mustardseedpmo.com/contact-our-project-management-experts-mustardseed-pmo.
Use this page when you already have a programme and need a risk system the executive gate can trust. Still building the integrated master schedule? Start with the aerospace program management IMS guide. Then come back here for the decisions that sit on top of it.
A useful register answers one question. What could stop this programme from meeting an approved outcome, and what evidence says so? In aerospace, that outcome is rarely one internal date. It is usually a customer milestone, a certification gate, a supplier commitment, and a cost baseline the sponsor has already accepted.
Four sources create most of the surprises leaders see late:
Keep ordinary task slippage on the schedule. Promote an item only when it can change one of those four outcomes. Also promote it when recovery needs a decision the team cannot make alone. That rule stops the register from becoming a second copy of the plan.
The Department of Defense separates the same ideas in its Risk, Issue, and Opportunity Management Guide for Defense Acquisition Programs. A risk is a future event that is still uncertain. An issue is a current event that already needs action. An opportunity is a future event that could improve the outcome. Mixing the three in one log buries real threats under status noise.
Not every requirement is a risk. A requirement is a constraint until evidence says the programme may miss it. The risk is the specific way you might miss it, the evidence you have now, and the decision that evidence forces.
AS9100 is the quality-management standard for aviation, space, and defense organizations. SAE AS9100D adds aerospace expectations on top of a general quality system. Those include configuration control, operational risk management, and tighter control of external providers. It does not tell a programme office which risks to accept. It does tell you that undocumented acceptance will fail an audit later.
Write a constraint risk so a reviewer who missed the meeting can still see the fork.
Example: the new bracket may not meet the fatigue requirement in the customer spec. Coupon tests are two weeks behind. The critical design review still assumes the current alloy. Only the chief engineer can accept a material change. Only the programme manager can move the review. That is a risk. "Fatigue testing is tight" is a worry.
Do not turn the register into a compliance manual. Link the risk to the clause and the evidence, then keep the procedure where quality already owns it. Leaders need the decision, not a pasted regulation.
Supplier trouble becomes programme risk when your recovery options shrink. A late weekly update is a supplier status item. A sole source, an unqualified special process, or a part that gates a certification test is different. The team cannot swap its way out, so it belongs on the programme register.
Score the dependency before you score the delay:
Bring the item onto the programme register when replaceability is low and the horizon reaches a promised gate. Leave routine commercial exposure with procurement. The programme office should see the few dependencies that can change certification, a milestone, or the cost baseline.
Flow-down gaps are a common miss. A supplier can be on time and still be unqualified for the process you need. Treat that as a constraint risk owned jointly by quality and the programme, not as a purchasing note. Ask for the qualification evidence at the same review where you ask for the date.
When you embed managers inside a prime or a supplier network, the handoff has to be explicit. MustardSeed's aerospace and defense project management work covers that embedded coordination. The rule in this guide is narrower. The programme register still records the dependency, the evidence, and the decision, even when a supplier team tracks the day-to-day recovery.
Risk governance fails in two familiar ways. Either every item waits for a monthly steering meeting, or every owner "accepts" a risk they have no budget or authority to accept. Both produce the same surprise at the gate.
Split the forums by the decision they can actually make:
| Forum | What it may decide | What it must escalate | Evidence it needs |
|---|---|---|---|
| Work-package review | Containment inside the approved baseline and slack. | Anything that moves a gate, a requirement, or a supplier qualification. | Owner, due date, and the assumption at risk. |
| Programme risk board | Priority, owner, and the response path across teams. | Accepting residual risk, extra funding, or a baseline change. | Likelihood, consequence, and options with cost and schedule effect. |
| Executive gate | Accept, fund, replan, or stop. | Nothing that is still only a status update. | The decision requested, the residual risk, and what happens if they wait. |
The programme risk board is a filter, not a court. It should leave with a shorter list than it started with. Some items need an executive decision. Some an owner can close inside the baseline. Some are really issues and need a recovery plan now. A board that reviews the whole register every month is a status meeting with a new name.
Tie each acceptance to a person, a date, and a review trigger. "Accepted by the programme" is not a decision. A real decision names the programme director, lasts until the next qualification test, and reopens if that test slips. Pair that habit with a clear model of regulated project decision making. Technical authority and programme authority should not sign each other's blanks.
NASA's Risk Management Handbook makes the same point for programmes and projects. Risk management supports decisions across safety, technical, cost, and schedule risk. It is not a side log. If your board cannot point to the decision a risk changed, the board is not governing.
The schedule stays the system of record for dates. The risk system stays the system of record for uncertainty and decisions. You connect them. You do not merge them into one file that nobody trusts.
Run this cycle. It is short on purpose.
A cross-industry method for scoring and response tracking already exists in the project delivery risk management framework. Use that for a clear statement, a consistent score, and a tracked action. Use this page for the aerospace layer. That layer is constraints, qualified suppliers, and the gate allowed to accept what remains.
Keep schedule construction out of this meeting. If the argument is about logic, calendars, or how to build the integrated master schedule, park it. Leaders lose the risk signal when the board turns into a planning workshop.
Executives do not need the register. They need the few items that still require them. A gate pack that pastes forty rows into a slide is how material risks get a thirty-second glance.
Give them one page with five blocks:
That pack should match the habit you already use for an executive project status report. Keep a small set of facts, a clear ask, and no narrative padding. If a risk does not change one of those five blocks, it stays with the owner.
Watch for proxy metrics. A green score that ignores an open qualification, or a percent-complete that ignores a failed test, will send leaders into the gate with false confidence. Earned value management is useful only when the risk note explains the variance. A cost or schedule index without the constraint behind it is a number, not a decision.
Opportunities deserve the same honesty. A second source, a test shortcut the customer has already allowed, or a clarified requirement can give time back. Record them separately. Do not use them to offset a threat you have not actually reduced.
Most late surprises are governance misses, not missing imagination. The team usually named the risk months earlier and then dropped the thread between forums.
Five patterns show up often enough to plan for them:
A short project management best practices playbook helps only if it names these rules in the open. "We manage risk" is not a control. This is a control: do not accept residual risk without an executive name and a review trigger.
When the same items return to the gate with no new evidence, stop adding process. The missing piece is usually decision rights. A broader PMO governance framework can reset who is allowed to say yes. It should not be asked to invent risks the programme has already seen.
Later, you may want to test how sensitive a milestone is to a few remaining uncertainties. Monte Carlo simulation for project decisions can support that conversation. It does not replace the acceptance decision. It should not be the first tool you reach for when the register itself is still muddy.
You do not need a new tool to start. You need a boundary, a forum, and a page the gate will actually read. Thirty days is enough to see whether the system changes decisions.
Week one: set the boundary. Write the four sources that earn a place on the programme register: constraint, supplier, integration, and decision risk. Tell every team what stays on the schedule. Freeze the template at one statement, one link, one owner, and one requested decision.
Week two: empty the shadows. Pull the engineering, quality, and supplier lists into the single register. Separate risks from issues before you score anything. Close or downgrade anything that cannot name a milestone, a requirement, or a source.
Week three: run the board for real. Hold one programme risk board with the decision split in the table above. Leave with three lists only: executive decisions, owner actions inside the baseline, and issues in recovery. If the meeting edits dates for more than a few minutes, stop and send that work back.
Week four: change the gate pack. Replace the full dump with the five-block page. Ask the sponsor to decide only on the items that request a decision. After the gate, record the acceptance, the name, and the trigger in the register the same day.
Judge the month by decisions, not by how many rows you collected. A smaller register that changed a gate is working. A longer register that changed nothing is a status archive.
Teams that want help standing this up, rather than another template, can look at how aerospace project management services are usually scoped. The scope that matters here is narrow. Facilitate the board, clean the register, and put a decision page in front of the gate. Schedule construction and a general defense-services pitch are different jobs.
If your gate pack is still a full risk dump, talk with MustardSeed about a programme risk board. The board should separate constraints, suppliers, and the decisions only executives can make.
It is how a programme office decides which uncertainties can change certification, a qualified supplier, cost, or a milestone. It also decides who may accept what remains. It is not a second copy of the schedule. It is not a flight-operations safety system.
The integrated master schedule is the system of record for dates, logic, and resources. Programme risk management records uncertainty, evidence, and decisions. You link a risk to a milestone. You do not rebuild the schedule inside the risk review.
Promote it when you cannot replace the source with a qualified alternative and the impact reaches a gate you have already committed. Routine lateness stays with procurement. An unqualified special process that blocks a test does not.
Only a named executive with the authority to live with the consequence. The programme risk board can assign owners and shape options. It should not accept residual risk on behalf of a sponsor who was not in the room.
One page per item that needs them: the decision requested, what changed, the consequence, the residual risk, and the cost of waiting. Everything else stays with the owner until the evidence changes.
