How to Write a Project Charter

What is a Project Charter?

The project charter, sometimes also called a Project Overview Statement (POS), is the signed document that formally defines and authorizes a project. Reaching an agreement on the nature of a new project, including its scope, objectives, and constraints can be a difficult but healthy process for a group of key stakeholders in a corporate environment. For that reason, a project proposal should be written and approved before the project charter is established.

Why Do You Need a Charter?

Without a project charter, the goals of the project will be ambiguous and often understood incorrectly by the key stakeholders, each having a different point of interest in the project. The result is a project beset with conflicting priorities, role confusion, and in many cases, as failed project.

What Every Project Charter Should Include

While charters are to written for each specific project, they should contain at least the following aspects:

1.     Project Authorization.

A brief written statement should identify the authorized project by name and/or number.

2.     Project Manager Authorization.

The name of the project manager, including a description of his/her responsibilities should be clearly identified.

3.     Key Stakeholders.

All key stakeholders identified in the project proposal, those who can positively or negatively influence the success or failure of a project, must be identified. Their functions and roles must also be defined clearly to avoid role confusion. List all stakeholders, their roles, and how they will contribute to the project.

4.     Project Goal(s).

Having a clear, agreed-upon, goal statement is vital to the success of the project. The goal statement in the project charter must be identical to the goal established in the approved project proposal. The goal must be:

  • Specific

  • Measurable

  • Achievable

  • Relevant to the corporate strategy

  • Time-lined

5. Project Priorities.

A list of the project priorities (time, cost, scope, etc.) must be included and delineated in the order importance. These priorities should remain constant throughout the project whenever possible. The importance of conveying project priorities to the project manager cannot be stressed enough.

6. Scope Statement.

A scope statement that describes the major activities of the project in such a way that it will be absolutely clear if extra work is added later on. Sometimes it is best to also include what is not in the scope of the project. The scope statement in the project charter must reflect the approved scope described in the project proposal, and may further expand on its details. If a scope statement is not included in the project charter, it must be developed as part of the project scope planning efforts.

7. Product Requirements.

Either marketing personnel, or a customer will identify the product requirements–what the product is expected to do, and how it must perform. Requirements at this stage are embryonic and will be defined during the project planning processes. Remember, most customers don’t know what they want until they know what you can provide, so initial product requirements are often “soft.” Product requirements must be consistent with those in the approved project proposal, and are sometimes included in a document called a, “Marketing Requirements Document (MRD).”

8. Project Assumptions.

Any and all assumptions related to this project must be clearly described. This may include the availability of specific resources, information, funding, and project personnel skills.

9. Project Constraints & Boundaries.

Any constraints or boundaries placed on this project must be clearly described. This might include budget/funding limits, time constraints, regulations, or quality standards that must be met.

10. Initial Project Risks.

Any identifiable obstacles and risks (threats) that might prevent the successful attainment of the project goals must be considered. Each risk must be analyzed, quantified, and prioritized as much as possible with the information available at this stage of a new project. Risk responses, including mitigations, risk sharing, risk avoidance, and risk tolerances should be described in this portion of the project proposal. The risks identified in the project charter must be identical to those in the project proposal, but may contain additional detailed risk management information.

11. List of Deliverables.

The project charter should include a list of deliverables produced by the project and submitted to a customer, or a production manager for acceptance. There can be both intermediate and end deliverables.

12. Cost Estimates.

Any cost estimates that were developed and approved in the project proposal must be reflected in the project charter. These might also contain the following aspects:

  • How fixed is the budget?

  • Why was it set at ($$$)?

  • How far over the budget or how late can we be and still be successful?

  • Do we know have enough to produce a reliable estimate?

13. Schedule Estimates. 

Any project duration estimates that were developed and approved in the project proposal must also be reflected in the project charter. These might also contain the following aspects:

  • How was the project deadline arrived at?

  • Why does the project need to be finished by (date)?

  • Do we know have enough information to produce a reliable estimate?

14. Integrated Change Control.

The project charter must also define how changes to the project charter, or the approved project management plan, will be managed. Processes such as configuration management, or software release centers must be described in detail, including who has the authority to accept of reject these changes.

15. Success Criteria.

In addition to the project goals it is also important to determine the success criteria of a project. Not all projects finish exactly on time, within budget, or with all initial scope completed, but this does not mean that a project has failed. Aggressive, but doable success criteria will ensure having a motivated project team.

What to Do If You Have No Project Charter?

If you as a project manager have no written project charter you should write one and then submit it to your sponsor, and the other key stakeholders, for review, revision, and written approval. It is critical that all project charters be in writing and signed by the appropriate stakeholders.

Michael Taylor

www.projectmgt.com

Share

3 thoughts on “How to Write a Project Charter”

  1. User Avatar

    I’ve found having a 1 page project charter is more effective than a big stack of documents. People have no excuses for not reading a 1 page document that summarizes everything Mike mentions in this blog.

    Last year I put a template and example of a 1 page project charter I’ve been using up on my website along with a bunch of other templates and examples of essential project documents. Have a look: Free Project Management Templates and Examples (They are the ones discussed in my Scrappy Project Management book.)

    Enjoy! – Scrappy Kimberly

  2. Good Day Mr. Taylor,
    After reading the above, can you kindly advise on what are some of the technical, business, social, cultural and ethical issues for a given Project and ideas to solve the above make sound judgments in the absence of complete data. I have been trying to link the elements of a project charter to determine a suitable answer.

    Sincerely
    Ian Samaroo
    (Trinidad)

    1. Good question. There is a disturbing shift in corporate ethics today from deontological ethics to teleological ethics. That’s why we see cases like Worldcom, and others whose executives are behind bars. Ethics must be established within the corporate culture and usually are not mandated within a project charter.
      Michael Taylor

Leave a Reply to Kimberly Wiefling Cancel Reply

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

Scroll to Top