In this article, you’ll find project charter examples for a real-life project. Then, we’ll discuss how to use it in the real world. In addition, you can get a simple project charter template I developed and used throughout 12 years as an IT project manager.
A project charter is arguably the most critical document on a project.
However, many project managers omit it…
…and it leads to project failure.
What is a project charter?
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, a project manager creates a project charter:
A project charter acts as a soft agreement between a project manager and project owners not to change the project timeline, scope, and budget without proper consideration and impact analysis.
This is to allow you to conduct project planning on a stable vision at the start of the project. After that, you’ll use the project charter to keep to the project scope and objectives.
Let’s review how it works.
Table of Contents:
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 Real Project
You can download the project charter examples in PDF for your future reference. Download the PDF
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 the new website should 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
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
How to Create a Useful Project Charter
Step #1: Check who is responsible for creating the project charter. Is it mandatory?
Step #2: Check if there is a project charter template in your organization. Ask your manager and peer colleagues. If there’s no project charter 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.
Step #4: Understand the project objective and how it is aligned with the business case.
Step #5: Try to identify real expectations from 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 if needed with risks and assumptions from other projects.
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.
For sure, the process may differ. Some steps might not be formal or mandatory.
Nevertheless, communicate with colleagues who have more recent and better expertise and authority first. Likewise, show the project charter to the project team members.
Does the project charter have to be a formal document?
No, you can avoid creating a formal document.
Collect the same information in meetings, calls, or emails. Then, follow up on the collected information, get feedback, and confirmation.
Keep this information in a shared document that you can quickly refer to.
How long should a project charter be?
A lot of project managers think that the project charter is something from the corporate and bureaucratic world, that it is a long and complicated document, and that efforts spent on it are not worth the benefits.
That’s not true.
A project charter document should be short. A person should be able to read it within a few minutes. Otherwise, no one will read it.
I would suggest no more than five pages long.
Keep the project charter as simple as possible. A branded rich text document works the best.
Any bells and whistles will only distract key stakeholders from the main goal of this exercise.
Now, let’s review what information you should include in a project charter.
What is Included in the Project Charter?
It’s a full list of common clauses of project charters.
But there are no hard rules on what to include or what to remove.
Use common sense. The document should be useful.
#1: Project Title and Short Name
First of all, you need an official name for the project. It’s the way to differentiate your project from other projects in your organization.
It’s also useful to think of a short name. An abbreviation that you will use in project management software and different systems.
#2: Project Description
What is this IT project all about?
Here, you create a high-level project scope vision.
Also, put a simple description of the project background. It’ll help you to connect with the business case and to understand the requirements.
Use common language that all stakeholders understand.
Assigned Project Manager
That’s the only place that formally states that you are the one who makes decisions on the project.
In the real world, in the IT industry this section has little sense.
Project Manager’s Authority
Your authority has limits based on the policies of your organization and the requirements of key stakeholders.
Here, you need to clarify whether you can determine, manage, and make changes to the project scope budget, schedule and request project team members on your own ( e.g., 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.
Business case stated in project charter has an exceptional importance!
During the execution phase, any change to the project should be checked against the business case.
If the change is not aligned with it, it is automatically rejected.
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 will have some preassigned resources. Put the 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 of people who can influence your project or will be influenced by your project.
For sure, you’ll do an in-depth stakeholder analysis later. That’s just a starting point.
Known Requirements
Here, you need to include high-level project requirements as they are known as of now.
Remember that you can refer to other documents here — no need to put full text in the project charter.
You’ll collect initial requirements from the stakeholders you listed above.
Description of Products/Service/Results or Deliverables
Here, you’ll list all deliverables and a description of the end result, service, or product your software project should produce.
It may include project documentation such as work breakdown structure, risk register, budget, etc.
Likewise, it can be an intermediate result for product development.
Click here if you want to get in-depth knowledge of scope management.
Assumptions
Factors that, for planning purposes, are considered to be true, real, or certain without proof or demonstration.
Constraints
Applicable restrictions or limitations, either internal or external to a project, will affect the performance of the project. 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
It is crucial! You can fulfill or implement requirements in many different ways.
However, the project was started to achieve a particular business goal.
While your final product, service, or result may be functional and usable, it might not be able to achieve the project objectives.
Project objectives here should be concrete and measurable. Meeting these objectives will mean you finished the project successfully.
Project Approval Requirements
This section should state what items of the project should be approved and by whom.
In most cases, you’ll need to get approvals at critical points in the project life cycle like:
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 a high-level risk. They will be later elaborated on during risk management processes.
Signatures of Project Sponsors
All in all project sponsor should sign the project charter document.
Real-World Application of a Project Charter by IT Project Managers
As I mentioned above, you create project charters as a soft agreement to fixate on a vision of the project scope, objectives, and timelines.
Then, you conduct various project planning activities to create a realistic project plan.
As a result, you’ll end up in two major scenarios:
The project plan proves that it’s possible to achieve the project objectives stated in the project charter. In this case, you carry on.
The project plan proves that it’s not feasible to achieve the project objectives. Then, for example, you can reduce the project scope or cancel the project.
What are the Long-term Benefits of a Project Charter?
There are three major benefits that you need to remember about creating 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.
As a result, you can spend a fortune and a lot of time, but still, there will always be someplace for additional improvement.
But will the improvement be worth it? Will we get ROI? Or do we just waste resources?
By providing project justification and setting specific requirements and goals, the project charter sets boundaries. It ensures that each dollar is well spent.
2. Project charter sets the change management foundation.
The project charter document states the project objective. After it is signed off, you will be spending efforts and allocated resources to reach that goal.
Changes are inevitable, and the project charter will help you to control them.
How?
You will be able to check and ensure that every change request is aligned with a project objective. If not, it must be rejected.
Project charter can give you valid reasons to justify canceling the project.
3. The project charter clearly defines the project’s start and end.
Quite often, IT projects creep from pre-sale or initial feasibility assessment right into drafting a project plan. You continue your work without clear goals and boundaries.
The contents of a project charter will help you to avoid poor decision-making and the waste of resources and time.
You’ll work towards the agreed project goal within defined constraints, assumptions, and expectations.
Likewise, IT projects that use agile frameworks move from one release to another.
They don’t stop to re-evaluate the initial project objectives.
As a result, project stakeholders lose track of the business case that we pursue.
What Project Charter Template Should I Use?
The answer is simple:
You should use the project charter template that you created yourself.
Do it once, from the beginning to the end. And create your own project charter template.
It will pay you back many times more.
Why?
There is no universal project charter template!
You can download the free project charter template and the project charter example I shared.
However, it’s only to help you to understand the concept!
But make a commitment and create your own project charter template. The process takes a few hours.
Conclusion: Project Charter in Project Management
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 12 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.