Project Charter Guide and Free Templates

A guide to project charters with free downloadable templates. Includes a Microsoft project charter for large projects and one for small projects.

The project charter is simply the “charter” (e.g. contract) between the project team and management to ensure everyone is on the same page. The project team is agreeing to deliver the business case benefits within the schedule and costs outlined in the charter. Management (e.g. sponsor and steering committee) are signing off on their commitment to fund, staff and support the project. The rest of this post will provide a guide to creating a project charter with free project charter templates for download at the end of the post. Sections are organized around the sections of the project charter templates.

Why You Need a Project Charter

You MUST have a charter for every project. I’ve included a one-page template for small projects which can entail as little as a 15 minute meeting with the sponsor. Large projects will require the larger template and may take weeks to develop and get approved. While it can be quick and straightforward, don’t skip the step of getting the understanding of the project in black and white. Also don’t skip the step of getting approval in writing. First, to get true understanding and consensus things must be in writing. People walk away from conversations with different understandings and memories of what was discussed. Second, nothing makes a busy manager pay attention and squirm more than asking them to put their signature on something. I’ve had managers avoid me for weeks as I chased them down to sign the charter. They simply didn’t want to have to make the commitment. If they don’t want to sign, that is a flag that something is amiss and it needs to be addressed.

You must have a charter for every PROJECT. I’ve seen overly eager project managers try to create charters for everything. A project is a significant effort with considerable cost. Timelines are measured in months. Budgets are measured in hundreds of thousands and millions. If something can be accomplished using existing people in your department in a week, than it isn’t a project requiring an approved charter.

I made the mistake once of working on a project without a charter, and I’ll never do it again. A project being run by another consultant was floundering. The first release was due in thirty days and the consultant hadn’t even started testing. I was asked to coordinate the testing effort and try to hit the release date. The first thing I asked for was the project charter. They didn’t have one. I should have walked away immediately. But the project had been running for over six months, there were regular meetings with the steering committee and hundreds of thousands of dollars had already been spent. I thought it was way too late to create and ask the steering committee to approve a project charter. If I’d insisted, I would have saved myself a month. As the release date approached, the consultant started communicating the details of the release functionality to the steering committee. Guess what? No one on the steering committee wanted what was being delivered and the project was scrapped.


Pretty obvious what this section is for. Provide a brief description of the project. Try to tell a story and make it a little engaging. Lead off with the issue or opportunity: “In this modern age of cell phones, state regulations require an employee personally visit a home and provide a final warning before disconnecting electricity for non-payment. Using text and phone calls (as is being done by other utilities) will be far more effective and will reduce labor costs of $3.6M per year.” Other topics to cover are:

  • Purpose – Why is the project needed? For example: “Besides being more cost effective, using cell phone communications are much more effective in helping customers to make a payment to avoid disconnection. In 60% of cases, no one is home when the employee visits the residence. Having more effective communication will reduce disconnects, and thus increase customer satisfaction.”
  • Business Case – The next section will contain the detailed business case numbers, but add some prose to tout the benefits: “With only an investment of $300K to automate the text and phone calls, we can reduce labor for disconnect visits by $300K per month thus achieving a one month payback.”
  • Goals/Metrics – Describe how project success will be measured: “The reduction in unnecessary disconnects is expected to increase overall customer net satisfaction scores by 1 point. Expect to eliminate 6K disconnect visits a month.”
  • Expected Deliverables – Briefly describe what will be built. For example: “An automated system that will generate text and phone call reminders at 7, 2 and 0 days from scheduled disconnection.”

Business Case

The level of detail required for a project business case has varied considerably among my clients. This section of the charter is intended to be a back-of-the-envelope summary of the business case. There may be much more detailed spreadsheets supporting these numbers. Typically, the minimum requirement is a positive return on investment (ROI) and a payback of under three years. Measure the three year benefits from the time the benefits start to be realized (typically at the end of the project), not from the start of the project. It is important to also note which costs and benefits will occur once and which will be ongoing. Don’t list every little cost or benefit. Use the 80/20 rule and list the 20% of items which make up 80% of the cost/benefits and group the rest under “Miscellaneous”.

During the Plan Phase, these numbers should be extremely high level. In some cases, you might want to mark some items as approximate or even “TBD”. By the end of the Analyze Phase, these numbers should be as exact as they are going to get.

Key Assumptions

Notice the title of this section is KEY Assumptions. Only list assumptions which you’ve made which will have a significant impact on the business case and have a reasonable probability of being wrong. You don’t want obvious or highly unlikely assumptions: “Assuming a meteor doesn’t destroy the city.” This list can be fairly long during the plan phase, but should be very short at the end of the analyze phase once you’ve dug into the assumptions. An example could be: “Assuming a 1 point increase in overall net customer satisfaction because the net customer satisfaction for customers disconnected in the current month is 5 points lower than customers that have not been disconnected.”


This is simply what you’ll be working on, where you’ll be working on it and with whom. Often, the “Out of Scope” portion is what generates any pushback from management, so you’ll want to include a brief explanation of why it is out of scope. For example: “All accounts marked as using life-saving medical equipment will be out of scope for this effort, for the obvious reason that their electricity cannot be disconnected and we do not want to unnecessarily alarm them.”

The grouping of scope items by people, process and technology is simply a prompt for you to consider all aspects of the scope. For people, you should consider which part of your organization is impacted, or which types of customers. For process, you should consider key scenarios that are out of scope like the example above of a customer dependent on a breathing assistance. For technology, you should consider which systems will be impacted.


This will only list the high-level milestones for the project. The most important one at the beginning of the project will be when the first release will be ready. During the plan phase this is an educated guess, but any experienced project manager or IT architect should be able to sense whether a project will take 3, 6, 12 months or longer. Under promise at the plan phase and give yourself a minimum of 20% contingency. So if your team estimates a six month project, put seven months in the charter.

By the end of the analyze phase, this schedule for the first release should be locked down and the team should be held accountable for delivering against the schedule. Timing for later releases will be estimated but should include the minimum 20% contingency since they haven’t been fully analyzed. Besides, the charter is usually obsolete after the first release. Later release timing and budget tracking will be handled in the steering committee presentations. Any major budget increases will be handled by change orders.


This is a list of things that must be delivered by others to keep your project on schedule and are outside of your control. Usually, these are other software projects for systems you’ll be using or that interface with your systems. For example: “There is currently a freeze on building new text messaging campaigns while the automated text messaging system is being upgraded. If the upgrade is not completed by January 30th the start of this project will have to be delayed.”

Project Team

At the end of the plan phase when the charter is first developed, this is a list of the team needed for the analyze phase. At the end of the analyze phase when the charter is finalized, this is a list of the larger team needed to build the first release. I’ve populated standard team roles as a starting point, but there obviously could be other roles on your project. The developer roles probably won’t be staffed until the end of the analyze phase. The percent-of-time column is included because many of the team members will work for the steering committee members, and this is confirmation that they approve dedicating these people to the project.

Primary Stakeholders

Stakeholders are either impacted by the project or should have a say in the project design. Again, use the 80/20 rule and list the 20% of the organization which will feel 80% the pain from this project. For example: “Customer Service – All 500 customer service reps will have to be made aware of the automated messages and be trained on how to respond to customer inquiries.” There are other tools which will track all the stakeholders and impacts.

Unique Risks

Notice this is titled UNIQUE risks. This is a pet peeve of mine. Every time I sit down with a client to write a charter, they want to add a risk that says something like: “May not be able to fully staff the project due to conflicting priorities.” The problem with this risk is that it is obvious and every project has the same risk. Besides, it is the job of the sponsor and the steering committee to set the priorities and assign the necessary resources. The risks listed here should be unique and they should be actionable so that they can either be mitigated or avoided. For example: “State regulators may not approve eliminating personal notifications at the residence. Plan to avoid this risk by presenting the results of similar programs in other states to the regulators and gauging their consent prior to launching a pilot program.”


You shouldn’t have to spend too much time on this section. In most cases, this section should be the same for every project. Just need to get concurrence on how big a change needs to be for the team to get approval. Also, I like scheduling steering committee meetings at key stages of the project when decisions need to be made, rather than a standing monthly meeting. Often, the standing monthly meetings become stale if there aren’t any major decisions to be discussed.


This section is used to record the project approvals by the: product owner, project manager, sponsor and steering committee members. I’ve found it is best to meet one-on-one with the sponsor to go over the charter. Also, I distribute the charter to the steering committee once I’ve incorporated the sponsor’s input, and hold a meeting a few days later to review the steering committee’s input. I ask people to simple send an email approving the charter and then attach the emails to the document. It is critical to get forma approval for the first version of the charter at the end of the plan phase. However, I don’t usually ask for formal approval for the final version at the end of the analyze phase unless there are significant changes.


This section just stores some document information and a log of version changes.

Free Project Charter Templates

The Large Project Charter Template is in Microsoft Word format and is a project charter for ERP implementations or other large software projects. The Small Project Charter Template is a PowerPoint slide and is ideal for small improvement projects like Six Sigma projects.

Related Posts

Managing Your First Software Project

Save Time with Free Excel Software Decision Matrix

Managing Your First Software Project

Please Subscribe to the Project Management Blog

You will receive a weekly email with blog updates. I try to write two blog posts a week.
Your email will only be used for blog updates.

    Leave a Comment

    Your email address will not be published. Required fields are marked *