“Project Management for Aerospace: A Practical Guide”

Project management for aerospace means running a multi-year program through a sequence of audits, tests, and approvals that cannot be argued with. A tier-one supplier discovers in month 31 that a bracket supplier changed a heat-treat subcontractor without telling anyone. The part still meets drawing. The process is no longer approved, the first article inspection is void, and eight hundred units now sit in quarantine while a design authority decides whether the change is reportable.

That is the shape of the discipline. Aerospace schedules are not hard because the work is complex, although it is. They are hard because every deliverable has a configuration, every configuration has an authority, and every authority has a document that says who approved what. A plan that ignores this produces a program that is technically on time until the first audit.

This guide covers the standards that dictate the plan, the certification gate model, configuration management as a scheduling instrument, supplier qualification, worked examples with real arithmetic, and the risk patterns that recur across civil, defense, and space programs.

What makes project management for aerospace different?

Because the acceptance criterion is not “it works” but “it is approved to work.” A prototype that flies proves the concept. It does not prove conformity, and conformity is what the customer and the regulator buy.

Three properties follow. First, verification is documented per requirement, usually in a compliance matrix that links each requirement to a test, analysis, inspection, or demonstration. Second, the design has a configuration identity: a specific drawing revision, a specific software load, a specific effectivity range by serial number. Third, the supply chain is part of the design, because a process change at a subtier supplier is a design change in everything but name.

The practical consequence is that aerospace planning has more hard predecessors per task than any other sector. A test cannot run until the test procedure is approved, the unit is conforming, the fixture is calibrated, and the facility is available. Four predecessors, four owners, four documents.

Which standards shape the plan?

Five standards do most of the work, and each one adds a specific gate to the schedule.

Two things about this table matter more than the list. AS9100 is a system standard: it audits how you plan, not what you build, which is why a program can pass the audit and still miss a gate. And AS9102 is not a one-time event. Any change to design, process, source, or inspection method triggers a delta FAI, so the FAI workload follows the change rate, and the change rate is highest exactly when the schedule is tightest.

Export control sits outside the table but inside the plan. ITAR and EAR obligations attach to technical data, and a program that shares a model with an uncleared supplier has created a compliance event with a schedule consequence measured in months. Put export classification on the gate checklist, not in a training slide.

What does the certification gate model look like?

Six gates structure most programs, and each ends with an artifact rather than a meeting.

The duration column is a planning prior, not a promise. The pattern worth internalizing is that the gates with the longest durations are the ones with the least schedule flexibility, because they contain authority review time. A team that compresses PDR to protect a CDR date has not saved time; it has moved risk into the qualification campaign, where it is more expensive.

How does configuration management protect the schedule?

By making change visible before it becomes rework. Configuration management has four functions (identification, control, status accounting, audit), and only the second is familiar to most teams. Status accounting is the one that saves programs: it answers “which units have which configuration” in minutes rather than in a week of spreadsheet archaeology.

Concretely, give every deliverable a configuration item identifier, a revision, and an effectivity statement: serial numbers, build block, or date. Then make the change board a scheduled event with a fixed quorum, because a change board that meets ad hoc becomes a queue, and a queue becomes a schedule.

The second discipline is traceability from requirement to verification. If a requirement has no verification method and no test reference, it is not in the plan; it is in a document nobody owns. Programs usually discover this at the compliance matrix review, three weeks before the customer does.

What does a change actually cost at each phase?

Far more than the engineering hours suggest, because the cost is dominated by re-verification, re-qualification, and re-documentation.

Worked example from a representative program. A wiring routing change is identified. If it is caught at PDR, the cost is design labour and a document update, roughly $40,000. If it is caught after CDR but before qualification, the same change requires a drawing revision, a delta FAI, an updated test procedure, and partial re-test, roughly $250,000. If it is caught after the type certificate, the change also triggers a certification plan amendment, authority involvement, and possibly a fleet retrofit decision, roughly $1.8 million plus schedule.

That is a 45-fold spread on the same technical change. The planning implication is not “freeze everything early,” which is impossible. It is to place the decision points where the cost curve is flat: a configuration review board at PDR and a second before the qualification build, with clear authority to say no.

How do you qualify a supplier before the first production run?

With a qualification plan that mirrors your own gate model, and with the acceptance evidence written before the first purchase order. Supplier qualification is a program task with a program owner, not a purchasing formality.

The sequence that holds up under audit: capability survey and financial check, quality system assessment against AS9100, special process verification (Nadcap accreditation with a validity date, scope, and the exact process family), first article inspection per AS9102, and then a production readiness review that confirms capacity, tooling, and inspection equipment. At the end of that chain the supplier signs a flow-down package that includes key characteristics, counterfeit part controls, change notification obligations, and record retention periods.

The arithmetic that changes behavior is lead time against qualification time. Qualifying a new special process supplier commonly takes 16 to 26 weeks, so a supplier added to the plan eight weeks before a build has already failed. Model qualification as a predecessor with a duration, and run a monthly expiry report for every accreditation and approval in the chain. The purpose is not paperwork: it is to make the invisible dependency visible on the same Gantt chart as the design work.

How do you measure program health with earned value?

Earned value is the only schedule metric that survives a customer review, because it compares planned value, earned value, and actual cost on the same axis.

Worked example. A program has a budget at completion of $24 million over 30 months. At month 14, planned value is $11.2 million, earned value is $9.5 million, and actual cost is $10.4 million. Schedule performance index is 9.5 ÷ 11.2 = 0.85, and cost performance index is 9.5 ÷ 10.4 = 0.91. At that CPI, the estimate at completion is 24 ÷ 0.91 = $26.4 million, a $2.4 million overrun that no amount of status reporting will remove.

The schedule number to watch is not SPI alone. It is the critical path float, measured in working days, and its trend. A program with SPI 0.85 and 40 days of float is in a different position from a program with SPI 0.95 and zero float. Report both, weekly, or the review becomes a conversation about definitions.

How do you plan a qualification test campaign?

Backwards, from the certification date, with facility and article lead times as the binding constraints.

Worked example. First flight is fixed by a customer commitment. A 22-week environmental test campaign must finish 6 weeks before flight to allow data review and conformity sign-off. The test article requires 14 weeks to build after drawing release, and the fixture requires 10 weeks after fixture design release, with 4 weeks of integration and calibration before test start. Working backwards: test start must be 28 weeks before flight. Article build must start 42 weeks before flight, and fixture design must be released 46 weeks before flight. If fixture design currently sits at 60% with a 9-week remaining effort, the program is already late by 3 weeks, and the honest response is to re-sequence rather than to add overtime to the test team.

What are the sector-specific risks that actually bite?

Two risks on that table deserve more attention than they usually get. Special process lapse is the most common self-inflicted stoppage in the industry, and it is entirely preventable with a calendar. Certification findings are the most expensive, because they arrive after the design is frozen and the tooling is cut.

What trade-offs does aerospace planning force?

Make versus buy is the first. Vertical integration buys control of schedule and sells capital and flexibility. The test that works: integrate where the process is a key characteristic or a certification-relevant special process, and buy elsewhere.

Parallel versus serial qualification is the second. Running qualification in parallel across two configurations saves months and doubles the cost of a failure that invalidates both.

Margins are the third, and the most political. Weight, power, thermal, and schedule margins are budgets. Spending them early feels efficient and is usually the reason a program has no room when the authority asks a question.

What mistakes show up most often?

• Treating the compliance matrix as a document instead of a plan. Every unverified requirement is an unscheduled task.
• Letting supplier qualification run on the supplier’s schedule. Qualification is a program task with a program owner.
• Planning to the customer’s requested date rather than the authority’s process. The authority has no incentive to accelerate.
• Skipping delta FAI after a “minor” process change. Minor to engineering, major to conformity.
• Reporting percent complete by hours spent. Hours spent measures effort, not earned value, and it hides the 15% that is 60% done forever.

Where does Doitify fit in an aerospace program?

Doitify is our product, so this is disclosure, not an independent review. It provides the planning layer: a program structure with gates as milestones, workstreams, dependencies, Gantt and roadmap views, resource workload, risk and issue registers, and reporting that rolls up from task to program.

The pattern that works in aerospace is to model gates as milestones with entry criteria as linked tasks, then keep the authoritative records where they belong: the PLM system for configuration and effectivity, the QMS for FAI and nonconformance, the requirement tool for traceability. Doitify does not replace any of those, and it is not a certified configuration management system. What it does well is the coordination layer above them: one view where engineering, supply chain, quality, and certification see the same gate dates and the same open evidence.

Conclusion

Aerospace project management is the craft of planning around proof. The schedule is a chain of approvals, the design has a configuration identity that must be controlled from the first drawing, and the supply chain is part of the certified product whether the plan says so or not.

If you take one action from this guide, make it a gate calendar with named evidence for each gate, then audit it monthly for two things: supplier special process validity and unverified requirements. Those two lists predict most of the delays that will otherwise be reported as bad luck.

If this post on project management for aerospace was helpful, you might also enjoy Design Project Management Template: Sections, Example, and How to Use It and Why Project Management Spreadsheets Stop Working as Teams Grow.