How to Write an Executive Summary and Project Charter

The project charter is the founding document of any project — the thing that says “this effort is officially authorized, here’s what it’s trying to achieve, and here’s who’s responsible.” In a project management course, it’s also an assignment that tests whether you understand the full scope of project initiation: not just what a project is trying to do, but how it will be measured, what it assumes, where it might fail, and what it will cost in time and resources. This guide walks through every required element — what each one means, what it needs to say, and what weak versions look like versus strong ones — with a complete worked example threaded throughout.

Choosing Your Project — What Makes a Good One for This Assignment

The assignment asks you to create a project that you’ll work through across multiple project management assignments. That’s the key phrase: you’re going to use this same project for scope management, scheduling, budgeting, risk planning, and potentially more. A project that’s too simple — “organize a birthday party” — won’t generate enough complexity to demonstrate real project management skills later. One that’s too complex — “build a national healthcare system” — generates scope so large that every subsequent assignment becomes unmanageable.

For the worked example throughout this guide, we’ll use a fictitious but realistic project: the implementation of a community mental health digital records and appointment scheduling system for a mid-sized outpatient counseling center. It has technology components, organizational change management dimensions, regulatory constraints, identifiable stakeholders, and a realistic timeline — enough to demonstrate all charter elements without requiring specialized technical knowledge.

Writing the Executive Summary

The executive summary is written for someone who won’t read the whole charter — a senior stakeholder, a sponsor, a board member who needs to understand what the project is and why it matters in three to five minutes. It’s not a table of contents and it’s not an introduction. It’s a self-contained document that answers: what are we doing, why, what will it produce, and what does success look like?

What a Project Charter Does — Before You Fill Out the Template

Understanding the charter’s function changes how you write it. The charter is not a planning document — planning happens later, in the scope statement, WBS, schedule, and budget. The charter is an authorization document. It formally defines the project, gives the project manager authority to use resources, and establishes the agreement between the project team and the sponsoring organization about what the project will and won’t do.

This means two things practically. First, every element of the charter should be specific enough that a dispute about scope, budget, or success criteria could be resolved by referring back to it. Second, the charter should be readable by people who aren’t deeply involved in the project — sponsors, executives, board members — not just by the project team.

Title, Purpose, Description, and Objective — The First Four Elements

These four elements overlap in content but serve different functions. The assignment permits you to use excerpts from your executive summary for all four — which is efficient, but doesn’t mean they should be identical. Each one has a distinct emphasis.

Success Criteria and Expected Benefits

Success criteria define what “done and done well” looks like. They’re the measurable conditions that must be met for the project to be considered successful — and they’re different from objectives. Objectives describe what you’re trying to achieve. Success criteria describe how you’ll know you’ve achieved it.

Major Deliverables

Deliverables are the tangible outputs the project produces. Not activities. Not outcomes. Outputs — the things you can point to and say “we made this.” Every project has deliverables, and a project charter that doesn’t list them clearly is a project that hasn’t been properly defined.

Common mistake: listing activities as deliverables. “Conduct staff training” is an activity. “Completed staff training program with 100% of clinical staff certified on the new EHR system” is a deliverable. “Install software” is an activity. “Fully configured EHR system live across all three clinic locations” is a deliverable. The difference is that a deliverable is a noun — something that exists when the activity is complete.

Acceptance Criteria

Acceptance criteria define the specific conditions each deliverable must meet before it’s considered complete and accepted by the sponsor or client. They’re the “done means done” definition for each deliverable. Without them, there’s no objective basis for determining whether a deliverable has been successfully produced — and scope disputes are guaranteed.

Acceptance criteria are most useful when they specify quality standards, functionality requirements, or verification methods — not just completion. “Training completed” is not an acceptance criterion. “All clinical staff (n=24) complete the EHR training module and pass the post-training competency assessment with a score of 80% or above” is.

Milestone Schedule

A milestone is a significant event or completion point in the project — not an activity, not a date range, but a specific, verifiable moment that marks a stage of completion. Milestones are the checkpoints against which project progress is measured. A good milestone schedule shows the project’s logical sequence and allows stakeholders to track progress without needing access to the full project schedule.

Most project charters include 5–10 milestones. More than 15 starts to look like a task list rather than a milestone schedule. Each milestone should have a clear name, a target date, and ideally a one-line description of what its achievement means.

Key Assumptions and Constraints

Assumptions are things the project plan treats as true that haven’t been confirmed and could be wrong. Every project has them. The purpose of documenting assumptions is to make them visible — so that if an assumption turns out to be false, the impact on the project can be assessed and the plan adjusted. An undocumented assumption that turns out to be false is a surprise. A documented one is a risk that was anticipated.

Constraints are limitations the project must operate within — budget caps, fixed deadlines, regulatory requirements, technology standards, staffing limitations. Constraints aren’t negotiable in the way that assumptions might be. They define the boundaries of the solution space.

Major Risks

The assignment notes that all projects have risks. The risk section of the charter is not asking for an exhaustive risk register — that comes in later planning phases. It’s asking for the major risks: the ones with high potential impact, high likelihood, or both, that the project sponsor and stakeholders should know about before authorizing the work.

A risk is not a certainty — it’s a possibility with probability and impact. Good risk documentation names the risk, gives a rough sense of its likelihood and potential impact, and briefly notes the planned response. Charter-level risks should be the ones that could threaten project success if they materialize without a response plan in place.

Resource Requirements Plan

The resource plan in a charter is high-level — it identifies what kinds of resources the project needs (people, technology, budget, facilities) without specifying the exact hours, rates, or procurement details that belong in the project plan. The purpose is to confirm that the project is resourced realistically and that the sponsor understands the commitment required.

Project Manager, Reporting Requirements, Sponsor, and Value Proposition

These four elements are often treated as administrative formalities. They’re not. The PM identification, reporting structure, and sponsor sections define the governance of the project — who’s responsible, who’s accountable, and how information flows. The value proposition is what makes the project worth doing and justifies the resource investment to stakeholders who aren’t involved in execution.

The Approval Signature Block

The signature block is the formal authorization element that converts the charter from a planning document into an official project authorization. In a real organization, the project sponsor signs here. In a course assignment, you’re typically expected to include the block with a placeholder or fictitious signature — the structure and content matter more than an actual wet signature.

A complete signature block includes: the project sponsor’s name and title, a signature line, a date, and often a statement confirming that the signatory has reviewed and approved the charter. Some charters include additional signature lines for the project manager (accepting responsibility) and key stakeholders (acknowledging awareness).

Full Worked Example Project Charter

Below is the complete project charter for the worked example — all elements assembled in the required order. This shows how the individual elements fit together into a coherent document. In a real submission, this would be formatted as a standalone document; here it’s presented as a continuous structured reference.

Frequently Asked Questions

Building From the Charter — Why Getting This Right Matters Now

The charter is the foundation everything else is built on. Your scope statement will reference the deliverables and acceptance criteria defined here. Your schedule will be built around these milestones. Your risk register will expand the major risks listed here into a full register with probability scores, impact assessments, and response plans. Your resource plan will detail the high-level resource requirements you identified in this document.

Students who rush the charter — producing vague objectives, generic risks, and unspecified deliverables — find that every subsequent assignment is harder to write because the foundation is unstable. Every time a scope question comes up, they’re guessing. Every time a risk needs a response plan, they don’t have a clear picture of what the project actually involves.

Invest the time to make the charter specific, internally consistent, and realistic. The payoff shows up in every assignment that follows.

For structured support writing project charters, executive summaries, and all subsequent project management deliverables — including scope management plans, WBS development, cost estimation, risk registers, and stakeholder communication plans — our project management services, academic writing services, and research support provide specialist guidance across all project management coursework formats.