This template is based on the “PMI Way” based on the PMBOK6. This also includes the wisdom of Tom Kendrick, PMP, who has helped the world with his project management expertise by writing many books, offering webinars, and more. We have incorporated his 3×3 matrix below. You don’t have to necessarily put a matrix in your charter, rather you would grab your sponsor and validate the Project Objectives and Priorities section of this charter. Grab other key stakeholders as well. (Without physically touching anyone of course… lest you get yourself in trouble! 😉 )
This template has been marked up with important notes.
Project Charter Template
Project Title: [Insert Project Title]
Project Sponsor: [Insert Sponsor Name]
Date Prepared: [Insert Date]
Project Manager: [Insert Project Manager Name]
Project Customer: [Insert Customer Name]
Project Purpose:
The purpose of this project is to [describe the main goal and intent of the project, e.g., “develop a new software platform for enhancing user experience and operational efficiency.”]
Measurable Project Objectives with Success Criteria and Relative Priorities:
Use the 3×3 Project Priority Matrix to define relative priorities among scope, time, and cost constraints. Constrain means zero wiggle room. Optimize means some wiggle room. Accept means you have a bunch of wiggle room. Having all 3 constrained is unrealistic. From PMI Infinity: “From these reports and general industry understanding, it’s inferred that the percentage of projects with absolutely no changes in schedule, scope, or cost is likely very small, potentially in the low single digits or even less than 1%. Most projects encounter some level of change due to evolving requirements, unforeseen issues, or necessary adjustments during execution.” What does that mean? If your stakeholders constrain all 3, you can guarantee, with 99% certainty that the project will fail. (For stats look to Standish Group, PMI’s Pule of the Profession Survey, PERIL database, KMPG, etc). Ask probing questions to figure out — up front — which of these do have wiggle room… Otherwise you will have the fun of sorting this out later… Or your project will simply fail.
3×3 Matrix Example:
| Scope | Time | Cost | |
|---|---|---|---|
| Constrain (least flexible) | |||
| Optimize (Somewhat flexible) | |||
| Accept (Most flexible) |
Project Objectives and Success Criteria:
| Objective | Success Criteria |
|---|---|
| Scope: | [Define scope success criteria, e.g., “Launch of the software platform as per the finalized specifications.”] |
| Time: | [Define time success criteria, e.g., “Completion by [Insert Date].”] |
| Cost: | [Define cost success criteria, e.g., “Within the budget of [Insert Amount].”] |
| Other: | [Define other success criteria, e.g., “Achieves specific performance metrics or goals.”] |
High-Level Project Description:
This project will involve [briefly describe the main activities and outcomes, e.g., “designing, developing, and implementing a new software platform that integrates with existing systems to provide a seamless user experience and improve overall efficiency.”]
High-Level Requirements:
- [Describe requirement, e.g., “User-friendly interface.”]
- [Describe requirement, e.g., “Compatibility with existing IT infrastructure.”]
- [Describe requirement, e.g., “Scalability to accommodate future growth.”]
Project Boundaries:
The project will include [outline the major boundaries, e.g., “developing a new software application and its integration with existing systems but will not include training end-users or long-term maintenance post-implementation.”]
Key Deliverables:
- [Describe key deliverable, e.g., “A fully functional software platform.”]
- [Describe key deliverable, e.g., “Integration of the software with existing systems.”]
- [Describe key deliverable, e.g., “User documentation and training materials.”]
Overall Project Risk:
- [Describe risk, e.g., “Potential delays in system integration.”]
- [Describe risk, e.g., “Changes in user requirements during the development phase.”]
- [Describe risk, e.g., “Resource availability constraints.”]
Summary Milestones and Due Dates:
| Milestone | Due Date |
|---|---|
| Phase 1: Initial Planning | [Insert Date] |
| Phase 2: Requirements Gathering | [Insert Date] |
| Phase 3: Design | [Insert Date] |
| Phase 4: Development | [Insert Date] |
| Phase 5: Testing | [Insert Date] |
| Phase 6: Deployment | [Insert Date] |
| Phase 7: Post-Deployment Review | [Insert Date] |
Preapproved Financial Resources:
Financial resources are approved by [insert approving body] and agreed as per the document [insert document name] dated [insert date].
Stakeholder Roles:
Ideally you will have insight into project governance at this point and reflect that in the roles below.
| Stakeholder | Role |
|---|---|
| [Insert Name, e.g., Project Sponsor] | Overall project oversight and funding approval. |
| [Insert Name, e.g., Project Manager] | Day-to-day project management and execution. |
| [Insert Name, e.g., IT Manager] | Technical oversight and system integration. |
| [Insert Name, e.g., QA Manager] | Quality assurance and testing. |
| [Insert Name, e.g., End-User Rep] | User requirements and feedback. |
Project Exit Criteria:
The project will be considered complete when:
- [Define exit criterion, e.g., “All key deliverables are accepted by the stakeholders.”]
- [Define exit criterion, e.g., “The project is within the approved budget.”]
- [Define exit criterion, e.g., “Post-deployment support is handed over to the operational team.”]
Project Manager Authority Level:
Staffing Decisions:
In consultation with [insert relevant roles or committees].
Budget Management and Variance:
The budgeted value for the project is $[insert amount]. This includes a [insert percentage]% contingency reserve. Budget variances of up to [insert percentage]% can be approved by the project manager.
Technical Decisions:
In consultation with [insert relevant technical roles or committees].
Conflict Resolution:
Handles first-level project conflict resolution. Escalates unresolved conflicts to [insert next level of authority].
Issue and Risk Escalation:
If you know anything at this point it is good to document the rules of escalation. That way you are setting the stage for everyone to be clear on their scope of control when it comes to decision making, tradeoffs, action taking, etc… And everyone will know when to “raise their hands,” and to who.
Sponsor Authority:
- Schedule and budget control.
- Approval of technical requirements in consultation with [relevant roles or committees].
Approvals:
Project Manager Signature
[Insert Project Manager Name]
Date: [Insert Date]
Sponsor or Originator Signature
[Insert Sponsor Name]
Date: [Insert Date]