A project charter is a short document that formally authorizes a project. It names the project manager and their authority, and it records the business case, objectives, scope boundaries, constraints, and high-level risks your sponsor agreed to at the start. Below you’ll find a real project charter example from an IT project I managed, section by section, and a practical way to write your own.
Key takeaways
- Keep it short. Your sponsor should read the charter in a few minutes. I keep mine under five pages.
- Make the objectives measurable. “Reduce customer attrition to 3%” tells you when you’re done. “Improve the site” never does.
- Write down what’s out of scope. One sentence like “Deployment is not part of this project” saves you weeks of arguments later.
- Use it to filter changes. Check every change request against the business case in the charter. If a change doesn’t serve the business case, you reject it.
A project charter is arguably the most critical document on a project.
However, many project managers skip it…
…and that’s how projects fail.
They start building before anyone agrees on what the project should achieve. Three months later, every stakeholder has a different picture of “done,” and you’re managing chaos, not projects.
If you skipped the charter on your last project, you’re in good company. In IT, projects often roll straight out of pre-sales, and nobody stops to write down why the project exists.
Here’s the textbook definition first.
A project charter is a document issued by the project initiator or sponsor that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities.
But this definition is theory. In practice, here’s what a project charter does for you:
A project charter acts as a soft agreement between you and the project owners not to change the project timeline, scope, and budget without proper consideration and impact analysis.
It gives you a stable vision to plan against at the start of the project. After that, you use the charter to keep the project on its scope and objectives.
Let’s look at how it works on a real project.
Table of Contents:
- Project Charter Example From a Real IT Project
- What This Project Charter Example Gets Right
- How to Write a Project Charter in 13 Steps
- What Project Charter Template Should I Use?
- What Is Included in a Project Charter?
- Real-World Application of a Project Charter
- Project Charter FAQ
Video Walkthrough of the Project Charter
You can read through the project charter example below, or I can walk you through all the details in this video.
Project Charter Example From a Real IT Project
This is the charter from a real website redesign project I managed. You can also download this project charter example as a PDF for your reference.
Project Title
Image Library Service Site Update (codename: project “redesign”)
Description
The last update of the Image Library Service Site was done three years ago. It is outdated in terms of appearance, performance, and user experience.
An investigation was conducted to develop performance requirements and a new vision of the UI.
The purpose of this project is to develop a new design and implement a brand-new site.
The new site deployment is not a part of this project. Due to its complexity, it will be done as a separate project.
Any updates or improvements to the database should not be performed unless needed.
Project Manager and Authority Level
Dmytro Nizhebetskyi is assigned as the project manager. He has the authority to select the required project team and determine the final budget.
Business Case
All closest competitors have up-to-date, responsive, and fast websites. Customer satisfaction with our service has dropped to a level of severe attrition.
This project is called to update the Image Library Services site.
- The new site should have good search and filtering capabilities.
- UI should be clutter-free and focused on finding and previewing images in the library.
- The site should be fast, responsive, and support key accessibility features.
We expect to regain our first position as an image content provider within a year after the new site is online.
Resources Preassigned
Patricia Smith from the design team is already assigned to the project on a full-time basis. The Project Manager will identify and request any other internal resources.
Stakeholders
Andrew Peterson represents the design team. Ray Jackson is from the customer support team. Lora James is from marketing.
They are available to support the project as needed.
Stakeholder Requirements as Known
There are requirements for the new site’s performance and a description of a general vision of its design as attachments to this document.
In no way should the new website reduce existing functionality for users.
Requirements Gathering Example (Real Software Project)
Product Description/Deliverable
- Full design of the new site as a storyboard
- Work breakdown structure
- Human resources plan
- List of project-related risks
- The new version of the site that is tested on lower environments and ready for deployment
Assumptions
- No new hardware is required.
- No changes to the database are required.
- Internal resources are capable of finishing the project.
Constraints
The new site should be ready for deployment by October 20.
The work breakdown structure should be provided by July 10.
A list of risks should be provided by July 25.
The final design should be ready and approved no later than August 20.
Measurable Project Objectives
The objective of this project is to develop a site with the speed performance level stated in the requirements.
Attrition should be reduced to 3%.
Budget limits and deadlines are the next priority.
Release date: Due no later than October 20, 2016.
Summary budget: $100,000
Project Approval Requirements
The head of the Design Department should approve the final UI designs.
Sponsors should approve the work breakdown structure.
PMO Manager should review and approve the list of risks.
High-Level Project Risks
We have little experience in improving and measuring customer satisfaction. It is possible that the new site will not meet end-users’ expectations. Therefore, our goals may not be reached.
Due to customer attrition, project delays may cause serious customer losses.
Project Sponsors Authorizing This Project:
______________________ John Snow, Vice President
What This Project Charter Example Gets Right
Most project charter examples online show you empty headings. The headings are the easy part. What matters is the handful of sentences inside them that protect you later.
Here’s why each key line in this charter is there.
| Section | Line in the example | What it does for you |
|---|---|---|
| Description | “The new site deployment is not a part of this project.” | Draws a scope boundary. When someone asks “Why isn’t it live yet?”, you point to this line. |
| Description | “Any updates or improvements to the database should not be performed unless needed.” | Stops the team from turning a redesign into a database rewrite. |
| Project Manager and Authority Level | “Authority to select the required project team and determine the final budget.” | You know which decisions you make yourself and which ones you escalate. |
| Business Case | Competitors have faster sites, and customers are leaving. | Gives you the filter for every change request. A feature that doesn’t win customers back can wait. |
| Assumptions | “No new hardware is required.” “No changes to the database are required.” | If one of these proves false, you have grounds to reopen the budget and timeline. |
| Constraints | WBS by July 10, risks by July 25, design approved by August 20. | Your sponsor commits to the planning milestones, not only the final deadline. |
| Measurable Project Objectives | “Attrition should be reduced to 3%.” “Budget limits and deadlines are the next priority.” | Success has a number, and you know what to trade first when something has to give. |
| Project Approval Requirements | Design head approves the UI, sponsors approve the WBS, the PMO approves the risks. | No surprise approvers at the end of the project. |
| High-Level Project Risks | “We have little experience in improving and measuring customer satisfaction.” | Your sponsor sees and accepts the biggest risk before the project starts. |
Notice what’s missing: long paragraphs, a methodology section, a RACI matrix. You can read this whole charter in five minutes. That’s just enough process to keep the project under control, light enough that your sponsor actually reads it.
Want a first draft like this for your own project, so you know which questions to ask before the sign-off meeting? Prompt 6 in my free AI Prompt Pack writes a project charter with almost the same sections as this example. You attach your kickoff meeting transcript and a Project Context File. Wherever information is missing, AI marks the gap with a 🔴 and gives you the questions to ask your stakeholders.
How to Write a Project Charter in 13 Steps
Step #1: Check who is responsible for creating the project charter. Is it mandatory?
Step #2: Check if your organization has a project charter template. Ask your manager and your peers. If there’s no template, create one.
Step #3: Talk to the project sponsor, client, customer, and key stakeholders. Collect information about the business case, high-level requirements, constraints, assumptions, project success criteria, and risks.
In this video, I prepare for my first meeting with a project sponsor and show the questions I ask to get what I need for the charter.
Step #4: Understand the project objective and how it aligns with the business case.
Step #5: Try to identify the real expectations behind the project.
Step #6: Write a project charter draft.
Step #7: Consult with subject matter experts, review historical data, and look for similar projects.
Step #8: Update the draft with risks and assumptions from other projects if needed.
Step #9: Meet with preassigned project team members and get their input.
Step #10: Update the draft if needed.
Step #11: Plan a meeting with project stakeholders.
Step #12: Update the draft and finalize the project charter.
Step #13: Get the sign-off.
Your process may differ. Some steps might be informal or optional in your company.
Either way, talk to colleagues with more recent expertise and more authority first. And show the project charter to your project team members.
Does a Project Charter Have to Be a Formal Document?
No, you can skip the formal document.
Collect the same information in meetings, calls, or emails. Then follow up on what you collected, and get feedback and confirmation.
Keep this information in a shared document you can quickly refer to.
How Long Should a Project Charter Be?
A lot of project managers think the project charter belongs to the corporate, bureaucratic world. They picture a long, complicated document that isn’t worth the effort.
That’s not true.
A project charter should be short. A person should be able to read it within a few minutes. Otherwise, no one will read it.
I suggest no more than five pages.
I learned this the hard way. When I got my PMP, I tried to bring its processes to a company that had none. Nobody followed them, and I was back to managing chaos. Since then, I write documents short enough that people read them.
Keep the project charter as simple as possible. A branded rich-text document works best.
Bells and whistles only distract key stakeholders from the main goal of this exercise.
Before you ask for sign-off, run this quick test:
- Your sponsor can read it in five minutes. If it takes longer, cut it.
- Every objective has a number. “Attrition should be reduced to 3%” passes. “Improve customer satisfaction” fails.
- It says what’s out of scope. The example above excludes deployment and database work in two sentences.
- It names who approves what. Designs, the WBS, risks, and the budget each have an approver.
- You could reject a change with it. Read the business case and ask yourself: would it let me say no to a feature that doesn’t serve the goal?
What Project Charter Template Should I Use?
Here’s the truth: there is no universal project charter template.
And a template won’t save your project. You can copy the headings in a minute, and that tells you the headings were never the hard part. The hard part is what you put in them: the business case your sponsor believes in, the scope boundary, the objective with a number. You get those from conversations with your sponsor and stakeholders. Once you understand that, the file is the easy part.
Today, AI builds that file faster than any template. You give it the context, and you get a first draft of your charter in minutes, with your stakeholders, your deadlines, and your constraints in it.
Context is the catch. Type “write a project charter for my project” into ChatGPT, and you’ll get a generic charter that could belong to anyone’s project. In this video, I show that context gap and generate a project charter from a Project Context File.
I put together a free AI Prompt Pack for project managers to close that gap: 27 copy-paste prompts for real IT project work. Two of them fit this article:
- Project Context File Builder (Prompt 0). AI pulls what it can from your notes, transcripts, and emails, then asks you targeted questions about your goal, scope, stakeholders, team, timeline, risks, budget, and definition of success. The result is one file you attach to every other prompt.
- Project Charter (Prompt 6). You attach your kickoff meeting transcript and the Project Context File. AI writes a formal charter in simple language, from the project title to the high-level risks. Where it lacks information, it flags the problem with a 🔴 and lists the questions to ask your stakeholders.
Get the free AI Prompt Pack and run these two prompts right after your next kickoff meeting. You’ll walk into your sponsor meeting with a draft and a list of open questions instead of a blank page.
What Is Included in a Project Charter?
Here’s the full list of common project charter sections.
But there are no hard rules on what to include or remove.
Use common sense. The document should be useful.
Project Title and Short Name
First of all, you need an official name for the project. It sets your project apart from other projects in your organization.
It’s also useful to think of a short name: an abbreviation you’ll use in project management software and other systems.
Project Description
What is this IT project all about?
Here, you create a high-level vision of the project scope.
Also, add a simple description of the project background. It’ll help you connect the project to the business case and understand the requirements.
Use common language that all stakeholders understand.
Assigned Project Manager
That’s the only place that formally states you’re the one who makes decisions on the project.
In the real world, in the IT industry, this section means little.
Project Manager’s Authority
Your authority has limits based on your organization’s policies and the requirements of key stakeholders.
Here, you clarify whether you can determine, manage, and change the project scope, budget, and schedule, and request team members on your own (without the approval of your boss or clients).
Business Case
What is the justification for the project? Is it a financial, legal, or marketing matter? Why did stakeholders decide to do it?
Put it all here in simple words.
A business case may be a separate document that justifies undertaking a project. You can link to it.
The business case in your project charter matters more than any other section!
During the execution phase, check every change to the project against the business case.
If the change doesn’t align with it, you reject it.
Preassigned Resources
At the start of a project, you may not have a project team yet. But someone has to help you with technical matters.
So you’ll have some preassigned resources. Put their names and expected availability here.
These people should be clear on their involvement.
Stakeholders
Name key stakeholders here.
It’s a list of people or groups who can influence your project or will be influenced by it.
You’ll do an in-depth stakeholder analysis later. This is just a starting point.
Known Requirements
Here, you include high-level project requirements as you know them now.
Remember that you can refer to other documents. There’s no need to put the full text in the project charter.
You’ll collect initial requirements from the stakeholders you listed above.
Description of Products, Services, Results, or Deliverables
Here, you list all deliverables and describe the end result, service, or product your software project should produce.
It may include project documentation such as the work breakdown structure, risk register, budget, etc.
It can also be an intermediate result of product development.
Click here for an in-depth guide to project scope management.
Assumptions
Factors that, for planning purposes, you consider true, real, or certain without proof or demonstration.
Constraints
Restrictions or limitations, internal or external to the project, that affect its performance. For example, you may be limited by:
- Project timeline
- Specific deadline
- Must-have features (aka scope)
- Project budget
- Available resources
- Project management software
Project Objectives
This one is crucial! You can fulfill requirements in many different ways.
However, the project was started to achieve a particular business goal.
Your final product, service, or result may be functional and usable and still miss the project objectives.
Make the objectives concrete and measurable. Meeting them means you finished the project successfully.
Project Approval Requirements
This section states which project items need approval and who approves them.
In most cases, you’ll need approvals at critical points in the project life cycle, such as:
- Work Breakdown Structure
- Project Schedule
- Project Budget
- Risk Management activities
- List of required resources
Project Risks
Risks are uncertain events or conditions that, if they occur, have a positive or negative effect on project performance. This section contains only high-level risks. You’ll elaborate on them later in the risk management process.
Signatures of Project Sponsors
The project sponsor signs the project charter.
Project Charter vs. Scope Statement vs. Statement of Work
People mix these three documents up. Here’s how they differ.
| What it covers | Project charter | Project scope statement | Statement of work (SOW) |
|---|---|---|---|
| Purpose | Authorizes the project and gives the PM authority | Describes the scope, deliverables, and exclusions in detail | Describes the work a vendor will do for a client |
| Who approves it | The sponsor or initiator | The sponsor and key stakeholders | The client and the vendor |
| When you create it | At initiation, before detailed planning | During planning, after you collect requirements | Before the contract is signed |
| Level of detail | High level, a few pages | Detailed | As detailed as the contract needs |
The charter comes first. Your project scope statement and work breakdown structure turn its high-level vision into detail.
Real-World Application of a Project Charter by IT Project Managers
As I mentioned above, you create a project charter as a soft agreement that fixes a vision of the project scope, objectives, and timelines.
Then you do the project planning to create a realistic project plan.
As a result, you’ll end up in one of two scenarios:
- The project plan proves that you can achieve the objectives in the project charter. In this case, you carry on.
- The project plan proves that you can’t achieve the objectives. Then, for example, you reduce the project scope or cancel the project.
What Are the Long-Term Benefits of a Project Charter?
Remember these three major benefits of a project charter.
1. The project charter sets a mutual understanding of the project boundaries.
For example, you need to improve a software application.
Project stakeholders come up with hundreds of possible features.
You can spend a fortune and a lot of time, and there will still be room for more improvement.
But will the improvement be worth it? Will we get ROI? Or are we wasting resources?
The project charter sets boundaries with its justification, requirements, and goals. It makes sure each dollar is well spent.
2. The project charter sets the change management foundation.
The project charter states the project objective. After your sponsor signs it off, you spend your effort and resources to reach that goal.
Changes are inevitable, and the project charter helps you control them.
How?
You check every change request against the project objective. If it doesn’t align, you reject it.
The project charter can even give you valid reasons to cancel the project.
3. The project charter clearly defines the project’s start and end.
Quite often, IT projects creep from pre-sales or an initial feasibility assessment right into drafting a project plan. You keep working without clear goals and boundaries.
A project charter helps you avoid poor decisions and wasted resources and time.
You work toward the agreed project goal within defined constraints, assumptions, and expectations.
The same goes for Agile projects. Teams move from one release to another and don’t stop to re-evaluate the initial project objectives. Stakeholders lose track of the business case. A one-page charter keeps that business case in front of everyone, release after release.
Project Charter FAQ
What does a project charter look like?
It’s a short document, ideally no more than five pages, with a heading for each section: title, description, business case, project manager and authority, stakeholders, requirements, deliverables, assumptions, constraints, objectives, approvals, risks, and the sponsor’s signature. You can see a full one in the example above.
Who writes the project charter?
Formally, the sponsor or project initiator issues it. In practice, the project manager usually writes the draft, collects input from the sponsor and stakeholders, and gets the sponsor’s signature.
Which document identifies the project manager’s authority?
The project charter. It names the project manager and states their authority level, for example whether they can select the team and set the final budget without further approval.
In which phase is a project charter created and approved?
In the initiation phase, before detailed planning starts. You then use the project plan to check whether the charter’s objectives are achievable.
What is the main purpose of a project charter?
It gives the sponsor, stakeholders, and team a shared understanding of the project’s goals, boundaries, and constraints. It also gives you, the project manager, the authority to use the organization’s resources.
Do I need project charter software?
No. A shared document that everyone can open is enough. What you need is the right information from your sponsor, and AI can turn that information into a first draft.
Can I download this project charter example as a PDF?
Yes. Download the project charter example PDF to keep it for reference.
Conclusion: Project Charter in Project Management
A project charter takes a few hours to write and a few minutes to read. It gives you a stable base for planning and a filter for every change that comes later.
Keep it short. Put numbers in your objectives. Write down what’s out of scope, and get the sponsor’s signature before you plan in detail.
Then, when a “small” feature request lands three weeks before release, you open the charter, read the business case, and you have your answer. Your project runs on a system, not on overtime. That’s how you stop managing chaos and start managing projects.
Next, turn the charter into a plan: read my guides to project scope, the work breakdown structure, the project schedule, and the project budget. You’ll find the rest of my articles on this topic on the IT Project Planning page.
Before your next kickoff meeting, grab the free AI Prompt Pack and build your Project Context File first. You’ll get a charter about your project instead of a generic one.
Most project managers don’t have formal education. They have to google their way through a project.
But as you can see from this article, you must be a confident manager from day one.
You have two options now:
Option #1: Try to figure it all out on your own and slow down your career for years.
Option #2: Let me explain the practical project management framework in a few days.
My Practical Project Management book covers all aspects of project management you need in the real world. All the knowledge comes from my 15+ years of practical experience.
Get the book. Read it instead of random articles. Master a practical project management approach that will boost your knowledge and skills.
All successful project managers know it’s better to learn from someone else’s experience (aka lessons learned). That’s because you are confident that these tips and tricks do work in the real world.
If you want to become a great project manager, get the book now.