How to write a project charter for an aerospace or defense program

Home / Aerospace and defense program execution / Front-end planning for aerospace and defense programs

You have just won a program, or you are about to start one, and everyone wants to get to design. The project charter is the step that decides whether that energy moves in one direction. On an aerospace or defense program it should settle, in writing and with signatures, what the program must deliver, what done means, what is in and out of scope, what it will cost, and who decides what. Done well, it takes one to two weeks and pays for itself the first time the customer asks for something new.

What is a project charter?

The Project Management Institute's PMBOK Guide describes the project charter as the document, issued by the sponsor, that formally authorizes a project and gives the project manager the authority to apply organizational resources to it. That definition is correct but thin. On a program that has to design, qualify and certify flight or mission hardware, the charter is also the first place the company writes down its own understanding of the contract in language every department can use.

That matters because a contract is written for lawyers and contracting officers, and a specification is written for engineers. Neither tells the purchasing lead, the test lab manager or the manufacturing engineer what the program is trying to achieve, what they are expected to own, or when they should raise their hand. The charter does. It turns the contract into a shared set of boundaries: requirements, scope, schedule, cost, authority, accountability and the definition of completion.

How is a charter different from a statement of work or a program management plan?

The three documents are often confused, and on some programs one is used to stand in for the others. They do different jobs.

A useful way to think about it: the SOW says what the customer bought, the charter says what the company has agreed to deliver and how it has organized itself to do it, and the management plan says how the work will be controlled day to day. A program can survive a thin management plan for a few weeks. It rarely survives a missing charter, because without one each department builds its own version of the scope.

What must an aerospace or defense charter settle?

Every charter is tailored to the program, the customer and the level of risk, but a charter for a highly engineered product should leave no doubt on these points:

• Requirements. The governing specifications, standards, statement of work and flowdown clauses, and which revision of each applies.
• Vision and definition of success. What the customer needs the product to do, and the specific condition that means the program is finished, such as qualification complete, customer acceptance and production deliveries started.
• Scope. What is included, and just as important, what is not.
• Schedule. The contract dates and the planned path to them.
• Major milestones and payment milestones. The events the customer measures, and the events that release cash. They are not always the same, and both need owners.
• Assumptions. Customer furnished items, facility and test rig availability, supplier lead times, staffing. Written assumptions are what let you show later that something changed.
• Risks and opportunities. The known threats to cost and schedule, and the chances to do better.
• Budget. The money available by phase, and who can commit it.
• Roles and responsibilities. Who owns each deliverable, who approves, who is consulted.
• Communication and escalation. How often the customer and leadership hear from the program, and what happens when a problem threatens the critical path.

The list looks simple. The value is in forcing each item to a specific answer. A charter that says the schedule is "per contract" or the budget is "to be determined" has not done its job.

Who should you interview before writing it?

Two groups, and most charters only talk to the first. The managers of each functional department, engineering, quality, supply chain, manufacturing, test, finance and contracts, know the constraints on their people and their budgets. The people actually performing the work, the design engineers, the test technicians, the buyers who place the long-lead orders, know how long things really take and where the last program went wrong.

Interviewing only managers produces a charter that is politically agreed and practically optimistic. Interviewing the people doing the work surfaces the details that decide the schedule: the test rig that is booked by another program, the casting supplier with an 18 week lead time, the qualification standard nobody has read in full yet. Those conversations are also where the team starts to trust the plan, because they helped write it.

Good interview questions are plain. What does done look like for your part of the program? What do you need from others before you can start? What worries you? What did the customer ask for last time that was not in the contract?

How long should it take, and who signs it?

For most programs the charter should be drafted, reviewed and signed within the first one to two weeks. Longer than that and the team starts executing without it, which defeats the purpose. The signatures matter more than the page count: the sponsor or general manager who authorizes the program, the program manager who owns it, and the functional managers who are committing their people and budgets. A functional manager who has signed a charter has agreed to its scope and resourcing in front of their peers, which changes the conversation when priorities compete later.

The charter is usually an internal document. Parts of it, such as the milestone plan, the communication rhythm and the escalation path, are often shared with the customer so both sides work from the same expectations.

Why pair the charter with an integrated schedule?

A charter states the boundaries. A schedule makes them visible. The best practice is to build the integrated Microsoft Project schedule during the same interviews, not afterwards, so that every milestone and assumption in the charter has a place in the network of tasks. The team can then see where the program is, where it is going and what has to happen next to get there.

Building the two together also catches contradictions early. If the charter promises a qualification date and the schedule, built from the durations the engineers gave, cannot reach it, the program has learned something important in week two rather than month nine. The integrated master schedule guide covers how that network should be built.

How does the charter control customer requests later?

This is where the charter earns its keep. Every program receives requests from the customer's engineers during design reviews, test witness events and routine calls. Many are reasonable. Some are changes to the scope. Without a charter, the team has nothing to test them against, so it tends to say yes and absorb the work.

With a signed charter and a scope statement, each request can be asked three questions: is it required by the contract, does it change cost or schedule, and who has authority to accept it? Requests that are in scope are simply done. Requests that are not go through a controlled path: they are logged, assessed and priced, and the customer decides whether to fund them. That discipline is the foundation of a requirements-to-work assessment when a program has already drifted, and of scope-change claims when the drift needs to be recovered commercially.

What goes wrong when programs skip the charter?

The symptoms are familiar. Each department works to its own reading of the contract. Everyone does thirty percent of everything, so nothing finishes. Customer requests are accepted in meetings and never priced. Nobody can say exactly what done means, so the program keeps moving the finish line itself. Months later, leadership asks why the program is late and over budget, and the honest answer is that it never had a boundary to stay inside. Recovering from that is possible, but it costs far more than a two week charter would have.

How Set Boundaries helps

During front-end planning, Set Boundaries runs the stakeholder interviews, drafts the charter, builds the integrated schedule alongside it and takes both to signature, typically within the first one to two weeks. The detailed charter templates and interview guides stay internal, but the outcome is simple: a signed charter, an executable plan, and a team that knows where the program is, where it is going and what has to happen next. If you have just won a program and are not sure where to start, schedule a call.

Related guides

• Building the integrated master schedule
• Preparing for the integrated baseline review
• Requirements-to-work assessment
• Scope-change claims and requests for equitable adjustment
• How we work

References

• Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide), project charter definition and the Develop Project Charter process.
• Department of Defense, MIL-HDBK-245, Handbook for Preparation of Statement of Work.
• US Government Accountability Office, Schedule Assessment Guide, GAO-16-89G.
• National Defense Industrial Association, Integrated Program Management Division, Planning and Scheduling Excellence Guide (PASEG).

Questions

Common questions

What should a project charter include for a defense program?

At minimum: the governing requirements and their revisions, the program vision and definition of success, scope and exclusions, the schedule, major and payment milestones, written assumptions, risks and opportunities, the budget and who can commit it, roles and responsibilities, and how communication and escalation will work. Each item should be settled to a specific answer. Entries such as per contract or to be determined mean the charter has not yet done its job.

Who signs a project charter?

The sponsor or general manager who authorizes the program, the program manager who owns it, and the functional managers who are committing people and budget to it, such as engineering, quality, supply chain, manufacturing and finance. Their signatures matter because they turn a planning document into an agreement. When priorities compete later, a manager who signed the charter has already committed to its scope and resourcing in front of their peers.

How long does it take to write a project charter?

For most aerospace and defense programs, the charter can be drafted, reviewed and signed within the first one to two weeks, including interviews with functional managers and the people doing the work. Taking much longer is a risk in itself, because the team starts executing without it and each department settles on its own reading of the contract. Pairing the charter with the integrated schedule keeps both moving at the same pace.

Is a project charter the same as a statement of work?

No. The statement of work is part of the contract and defines the work the customer is buying. It changes only through the contract's change process. The project charter is an internal document that authorizes the program, translates the contract into requirements, scope, schedule, budget and roles, and records the assumptions behind them. A good charter references the SOW rather than repeating it, and explains what it means for each department.

When should a project charter be updated?

When something it records genuinely changes: a funded contract change, a revised milestone, a new budget or a change in who owns a major deliverable. Updates should be deliberate and re-signed by the people affected, not quiet edits. The charter should not be rewritten to match whatever the program is currently doing, because its value comes from being the stable reference that shows when scope, schedule or cost has moved.

Does the customer see the project charter?

Usually not in full, because it contains internal budget and resourcing detail. The parts that shape the working relationship, such as the milestone plan, the definition of completion, the communication rhythm and the path for raising new requests, are often shared with the customer. Doing so early means both sides work from the same expectations, which makes later conversations about out-of-scope requests far easier and less personal.

Have a question that is not here? Ask Holly on a short call