About Us
Site Map
PMP® Certification
PM Tips & Tricks
PM Tools & Techniques
Contact Us



Writing the Project Charter

Project Charters tend to be overlooked on many projects either because the project sponsor and project team are unfamiliar with this document or it is seen as unnecessary because of the scale or simplicity of the project. While it is true that not every project needs a formally written Project Charter, most projects will benefit from one. Moreover, project charters can be scaled to the size and complexity of the project so there is really no reason not to write one. One of the mysteries surrounding the project charter is who is actually responsible for writing it. Although there is a lot of information available on project charters almost none of it will tell you who is responsible for writing it. From the project manager’s perspective the project charter is something that should come from the project sponsor; after all most of the information in the charter comes from the sponsor. The problem with expecting the sponsor to write the charter is that they are even less likely to have experience with charters than project managers and even less inclined to invest time in writing one. My advice to project managers is to take the bull by the horns and write the charter yourselves. If the charter you write achieves nothing else, it can help define your level of authority over the project.


The primary purpose of the charter is to define the parameters of the project the organization will undertake. The parameters should be explained in business terms rather than technical terms. A description of the testing tools to be used in developing the new software system does not belong in a charter. The business goals and objectives the new system is expected to achieve do. The charter should contain goals and objectives related to other aspects of the project as well such as the degree of quality the end products are expected to show, budget targets, and schedule targets. The goals and objectives set out what the project manager and project team are expected to achieve.

The other side of the coin is what the project manager must be given in order to achieve this. Charters were originally granted by monarchs to individuals or organizations and they spelled out the authority the monarch granted as well as the purpose of the charter. Google "Hudson’s Bay charter” if you’d like to look at an example of a royal charter. Your charter should define your authority as a project manager. First and foremost: what is your level of authority over the project team? Do you have hiring authority? Do you have firing authority? Are you one of several decision makers for hiring resources and one of several for firing? Do you have hiring and firing authority over contract resources but not full time resources? These are questions that are frequently left unanswered until a crisis arises where an answer is necessary and then the answer will tend to be one the project manager does not like.

Performance evaluation is another aspect of the project manager’s authority. Even when the project manager does not have hiring or firing authority over the team, the ability to impact a team member’s pay and future prospects with a performance report is a source of authority. It makes sense that the project manager provide a performance review for team members, particularly on projects that deliver an organization’s strategic objectives and of relatively long duration. Don’t expect to automatically assume this authority unless it has been spelled out in your charter.

The issue of the project manager’s authority over the project team will be one that is guided by your Human Resources policies and procedures or union contract. You can’t be given a level of authority that is contradicted by an HR policy or union contract so if you’re the one writing the charter, make sure that you have a command of any applicable HR policies or procedures and contract language, and that the authority you define for yourself is compatible with them.

Goals and Objectives

Goals and objectives should be stated from a business perspective. The organization you work for is not investing the money the project will spend on technical objectives; there is a business need or goal that justifies the expenditure and that need or goal should speak to a return on investment. Some projects will be initiated in direct response to a strategic objective of the organization and if this is the case, that objective should be included in the charter and the project goals and objectives should be directly related to it.

Some projects will be initiated by a Business Case which states the benefits to be derived by successful completion of the project. If your project was initiated in response to a business case, the benefits stated in the business case should be captured in the charter. If the benefits description is lengthy, you can simply make reference to the specific location in the Business Case containing the benefits description. Remember that projects can sometimes change significantly enough to change the expected benefits described in the business case and when this happens the project charter will have to be updated to capture the new benefits.

Goals and objectives shouldn’t be limited to the business; any goals and objectives that the project is expected to meet should also be captured. The goal of the project might be to deliver a software system that will reduce order processing costs by 25% but the organization may also have expectations for project performance such as the project will deliver the project on time or even that each phase of a phased release be delivered on time. It might also have expectations around performance to budget and these should be captured in this section as well. The specific dates or amounts should not be specified in this section, just the broadly stated goal. For example "The project will deliver the work no more than 1 week after the planned delivery date.” Or "the project will deliver the work on or before the planned deliver date.” Actual dates will be captured in the Milestones section. Actual amounts will be captured in the Constraints and Assumptions section.

Quality is an area that is sometimes overlooked when identifying project goals but these goals are as important to the success of the project nonetheless. The quality of the ordering system is likely to impact on the ability to decrease processing costs by 25%. The most obvious area for setting quality goals is defects in the final product. Others may include performance: how responsive does the system need to be to deliver on the promise of increased productivity? Capacity: how much should the system be able to handle? How many users should be able to process an order at the same time? Stress: if the system must support 100 users inputting an order at the same time, how should the system respond for the 101st user? Standards, guidelines, and regulations are other sources for quality goals. The project might be responsible for implementing CMMI level 3 for software development or ISO 9001 for manufacturing. A construction project might have building codes to meet or exceed. A pharmaceutical project might attempt to meet or exceed a Good Manufacturing Practice.

Another possible source for a goal or objective is safety. The organization may set strategic goals around the area of safety in response to concerns around accidents or insurance rates and these goals could impose a goal on the project such as "zero lost time accidents”. These goals should be stated in this section. Corporate Social Responsibility is another source of goals. Strategic goals set by the organization by the group responsible for CSRmay imply project goals in the same way that safety objectives do. The organization may have a strategic goal to reduce its emissions by 50% in 5 years. The organization may want to set a goal for the project which will enable the overall goal and that goal should be stated in this section.

Don’t forget any training objectives the project may have. New software systems may require users to be trained so a suitable objective would be to have 90% of the users trained on the new system before launch. The project may include deliverables that will require users or support teams to be certified. For example a project that will implement an Oracle database might require the Database Administrators to be certified as Oracle DBAs.

The Goals and Objectives section of the charter answers the question: "Why are we doing this project?”

Project Manager Authority

This section should describe the authority the sponsor is delegating to the project manager. The project manager’s authority should be defined in as much detail as possible. For example, if the project manager has authority over spending decisions, what is the level of their signing authority? Can the project manager negotiate with functional managers for the acquisition of full time resources? Can the project manager hire contract resources within their level of signing authority? If they can’t hire or acquire resources what role are they to play in choosing resources for the project?

The flip side of the hiring coin is the firing coin. The project manager’s authority should include their remedies for addressing inadequate performance, including returning the resource to the resource pool or firing the employee. The project manager’s responsibilities for evaluating team members’ performance is a part of their authority and should also be included here. Their authority for rewarding employees should also be stipulated. Can they give out awards within the limits of their signing authority? Can they choose team members to receive rewards from the organization such as spot awards? The project manager’s authority should be such that one could reasonably expect them to achieve the project’s goals and objectives and accept responsibility for the success or failure of the project. Nothing in this section should contradict any of the Human Resources policies or guidelines, or any language in a union contract. The section should be a description of the tools given the project manager for forming a high performing team but not be a description of how that process will be performed. The processes and procedures for acquiring, developing, and managing the project team should be contained in the Human Resources Management plan.


Deliverables are the tangible outcomes of the project. In the case of our project that reduces order processing costs by 25% the tangible deliverable will be the software system. The deliverables should be stated at an appropriate level of detail. For example, the software system might be comprised of a relational database which stores the orders and inventory, a user interface which is used to create and process orders, and a reporting system which is used to manage orders. These are all deliverables which should be included in this section.

Deliverables should not be stated in any more detail than appropriate for your audience. For one thing, if the Executive Sponsor is writing the charter they may not be aware of deliverables at any greater level of detail. For another, the audience reading the charter will not be interested in a description of deliverables in detail or be able to understand the descriptions if they are offered.

If you are writing the charter and it includes some goals and objectives specific for the project, you might agree on the reports that will indicate progress towards them and the deliverables section of your charter is an ideal area to describe these. Complete descriptions of reports, how they are generated, how they are to be communicated, and how frequently they are to be produced will be captured in a Communications Management Plan.

Manuals and other forms of documentation are a frequently overlooked area of project deliverables yet they often form a critical feature of the final product. Thought should be given at this point to how users are to be educated on use of the new system. In-house built systems will require some form of education to be developed along with the system. Education requires a combination of face-to-face training and User Manuals. Software systems aim to achieve improvements in productivity and they can’t realize their potential when the users of the system struggle to overcome a lack of knowledge on how to use the new system. The documentation side of education can come from paper or on-line versions of User Manuals or from feature and function related on-line Help. The Charter should capture these deliverables at a high level, for example "The system will include a User Manual/Guide”, or "The system will include a combination of User Manual and on-line Help”. Decisions on the composition of User Manuals or Guides and on-line Help should be left to the design phase of the project.

Other types of deliverables that should be mentioned in the charter are:

Any tangible outcome from the project’s work that is known at the time the charter is written is a candidate for a deliverable. The Deliverables section should answer the question: "What do we expect to get from this project?”


The Scope Statement tells the reader what the project team intends to do. "We will build, test, and implement an order processing system” is a scope statement. A project scope statement speaks to the work that is required to deliver the goals, objectives, and deliverables already described. The scope of the project will also include administrative work such as planning project activities in the areas of schedule, quality, procurements, risk, schedule, and budget. Plans that describe how the project will administer these areas should be included in the scope statement. The scope statement should also include:

  • Installation of any special tools for development or testing
  • Testing through all the stages of development
  • Training of the team
  • User training
  • Procurement of goods and services from external vendors
  • Any other work that the project team must do to deliver the project
  • Requirements for the project (these will be articulated at the highest level)

The scope statement should describe the project work at a relatively high level for the same reason that deliverables are described at a high level. The scope statement may also include work that the sponsor has agreed is not in scope. The reason for identifying work that is not in scope is to avoid any misunderstanding among the stakeholders and to avoid "scope creep”. Work that stakeholders might have a reasonable expectation to see included in the project but that won’t be done should be included in this section and the section should be clearly labelled so that it cannot be overlooked by a reader.

Scope statements are sometimes written in addition to the project charter and may precede the writing of the charter. In that case, the charter needn’t contain the complete scope statement, a few sentences describing the scope at the highest level and a reference to the scope statement will do. If you so refer to the scope statement in your charter, make sure it’s available to all the readers of the charter or better yet, include it with the charter as an appendix.

The scope statement should answer the question "how are we going to build the project deliverables?”


The milestones to include in the project charter may be those that pertain to the development of the project deliverables or to the project itself. Examples of deliverable related milestones include pilots, proof of concept, completion of development, completion of training, completion of QA testing, or procurement contract finalization. Examples of project related milestones might include gate review meetings, progress reports, or Steering Committee meetings. Specific dates for the milestones may or may not be known at this point. Any dates that are known will act as constraints on the planning process so should also be captured in that section. This section can’t answer the question "When is the work going to be completed?” These dates aren’t usually known until planning is completed. It can answer the question "How will we know when the work is complete?” The answer is "When we’ve reached the ______ milestone”.

Project Team

The project sponsor, or sponsors, should have been identified by the time the charter is written so these folks can be identified, along with their roles in the project, for example "key decision makers”, "project plan approvals”, etc. If the sponsor is writing the charter, the project manager may or may not be known. If they are known, they should be identified, along with their role. The charter is also an ideal document to identify other key team members. These are people who can be identified by name whose contributions will either make or break the projects. If you’re the one writing the charter this is your opportunity to stake your claim on these resources. If you aren’t writing the charter, you will have to negotiate for any resource not named in this section.

Projects frequently use RACI or RASCI charts (Responsible, Accountable, Support, Consulted, and Informed) to identify the project team and their responsibilities to the project. You won’t know the entire team at this point, even if you are the project manager, but you will at least know the sponsor, or sponsors, and any critical resources, plus yourself of course. I suggest you start your chart in the charter. Name the people whose identity is known to you and identify roles or groups where you don’t know identities but have identified a need for resources.

Assumptions and Constraints

We make assumptions when we get out of bed in the morning; we assume that the sun will rise, even if clouds cover it. Not every assumption should be captured in the project charter, not even every assumption that has to do with the project needs to be captured here. The executive sponsor should assume that the project manager identified has a command of the best practices described in the PMBOK® Guide, providing they have been certified as PMP®sby the PMI, but you probably don’t want to include this assumption in the charter; it would serve no purpose. The assumptions captured in the charter should be restricted to those that would have a major negative impact on the project if they should prove false. Let’s take the example of a crane operator on a construction site. The crane operator is essential on any multi-storied building such as yours and you have been promised by the organization that a preceding building project will complete in time for that crane operator to begin work on your project. Based on that date you will plan work that requires the crane to complete. If the preceding project should be delayed for any reason and that crane operator is not available on the specified date, you may not be able to begin the work that requires the crane on time.

Assumptions are risks. For every assumption captured in this section of the charter, you should describe a corresponding risk. Taking the example above, the risk event might be that "the crane operator does not become available in time to begin work on (the work the crane is required to perform) and that work is delayed until the operator becomes available”

Constraints are any circumstances that will limit your options when the project is planned. For example, a budget maximum might eliminate much of the overtime that would otherwise be possible. The constraint might also have more far-reaching effects on the project goals and objectives as the project work is planned and costs are estimated. For example, one of the project objectives might be the certification of the organization as CMMI Level 3 compliant. A budget constraint might lead to a choice between other project objectives and this one as the cost of the work is estimated during planning. Schedule constraints may serve to limit planning options in the same fashion. A need to deliver the solution by a deadline imposed by a government regulatory body might mean that some work might have to be contracted out at greater expense but shorter timeline as opposed to being done in-house for less money but a longer timeline. Stating these constraints in the charter will identify these choices in the planning phase when the organization has an opportunity to address them in an orderly fashion.


Every assumption is a risk, but not all risks are assumptions. This section of the charter should contain any risks to the project known at the time of writing. The starting point for risk identification here is the Assumptions and Constraints section of the charter. Each assumption should be translated into a risk event and captured in the Risk section. Other risks may be identified as the project’s goals, objectives, deliverables, milestones, project team, and constraints are identified. Remember that this is not the risk identification exercise that will be part of your Risk Management Plan. Identified risks should be described with a simple risk event description. People can tend towards cryptic statements or descriptions of results when describing risk events. "Strike” is not a risk event, "a masons’ strike occurs before all masonry work is finished” is. "The start of the project’s crane work is delayed because a crane operator isn’t available” is a description of the impact of the risk event, "the crane operator does not become available in time to begin the crane work” is.


The charter should be approved by the project sponsor, or Executive Steering Committee. Approval can also include stakeholders if the sponsor chooses to include any. Of course, if the sponsor is writing the charter, there may not be any further approvals necessary. Those that approve the original charter must approve any changes to the charter which suggests a correlation between the charter approvers and the project Change Control Board.

Changes to the Charter

I’ve mentioned that the information you put in the project charter should be of a general nature, a 50,000 foot view as opposed to a ground level view. Excluding information that is of a detailed nature will serve 2 purposes: it makes the document readable and it avoids the necessity of updating it whenever a discovery requires a minor change in the plans. Otherwise, you would need to update the document every time one of the goals, objectives, milestones, requirements, resources, or constraints changed. The greater the level of detail, the greater the chances of a change over the course of the project.

Your charter should have version control and the understanding with stakeholders that the current, approved version of the project charter describes the agreement with the project manager and project team. The charter version should not change without a change request which requires the approval of the CCB (Change Control Board). The update of the charter and version number will be a part of the change management process when a change request that impacts information in the charter is approved.

Using the Project Charter

The project charter should be the first document in the sequence of project documents; it is written as early on in the project lifecycle as possible, ideally during project initiation so documents developed during planning including scope statements and Statements of Work (SOWs) can refer to the charter for project information. The only document it will not precede is the Business Case. The other project plans, including the schedule, budget, quality management plans, human resource management plans, communications management plans, change management plans, risk management plans, and procurement management plans can also refer to the project charter for information.

The charter can also be used as a guide to validate project plans. For example, requirements identified by project stakeholders should support one of the project goals, objectives, or deliverables. Requirements that are not associated with these are invalid, unless they are valid and the charter needs to be changed. While it is always possible that the charter should change, it requires the approval of the original approvers of the document to do so.

The section identifying project work that is out of scope can be especially useful when collecting requirements from the stakeholders. This information can avoid the hassles that accompany the identification of a requirement as surplus baggage because it doesn’t support one of the goals, objectives, or deliverables in the charter. Reading the charter carefully should prevent stakeholders from identifying requirements that are dealt with in the "Out of Scope” section of the scope statement.