Project Charter

This section lays out the project’s big-picture goals—what we’re doing, why it matters, when it’s happening, who’s involved, and how much it’ll cost. If any Discovery & Assessment work was done beforehand, summarize it here—unless there’s already a separate Discovery Charter.

Provide a snapshot of the current process, system, or both. Highlight the existing pain points and challenges driving the need for change. Call out any compliance, security, or other risks that must be addressed.

Explain why this project is critical now. Who benefits? Tie it to strategic or technology goals, roadmaps, or broader business priorities. Specify which service(s) the project supports and how it adds strategic value or boosts market reach.

Describe the consequences of not moving forward. Focus on the potential risks, missed opportunities, or long-term impacts on the organization if this project isn’t prioritized.

Set clear and actionable objectives using the SMART framework: Specific, Measurable, Achievable, Relevant, and Time-Bound. Focus on outcomes like operational efficiency, improved accuracy, or overall effectiveness driven by the project.

Key Performance Indicators (KPIs)

Define measurable outcomes, such as “Reduce processing time for key workflows by 50% within six months.” KPIs act as benchmarks to monitor the project’s success and value.

Success Factors or Benefits

If KPIs aren’t feasible, list the primary success factors or benefits. These will provide a framework for evaluating the project’s impact once completed.

Outline the solution’s key features and the expected benefits, including improved operations, efficiency gains, cost savings, or process changes. Highlight findings from any prior Discovery or Assessment work. Provide clear details on who will be affected, what changes they’ll experience, and when those changes will occur.

List the systems, both internal and external, that the solution will interact with. Specify whether integrations need to be built and identify any upstream or downstream impacts. Include potential effects on staff resources, even for those not directly involved in the project.

Explain how the project will affect individual users, such as changes to their workflows, tools, or responsibilities.

Describe how teams, departments, or larger organizational structures will need to adapt, focusing on operational and strategic shifts.

Detail the implications for systems or processes identified in the Touchpoints section, including ripple effects and dependencies.

Clearly define the features, functions, and tasks included in the project. Organize them by category or functionality for clarity, ensuring stakeholders know what’s covered.

List the features, functions, or tasks explicitly excluded from the project. Provide justifications for their exclusion to manage expectations and avoid confusion.

Outline the key outputs and milestones for each phase of the project. Include planning documents, designs, test plans, and readiness materials, aligning them with specific deadlines.

The template includes usual phase and milestone types, however each project is different therefore given the case-by-case basis of how they're managed, some phases, or milestones may be omitted while others not listed below may be included.

Brief reasoning why the current project organization is suggested.

A simple graph is usually sufficient. It should clearly show how this project is structured and how it aligns with the broader organization. The broader organization could be another project, a program, a portfolio, or the enterprise itself if none of the former apply. External structures should only include the hierarchy leading up to the root entity—the ultimate sponsor or authority overseeing this project and any related organizations.

Break down each role into subsections with brief descriptions. Explain what the role entails and why it is essential within the Project Organization.

Provide a detailed description of each role’s scope, including their responsibilities, accountabilities, key consultations, information-sharing obligations, and primary collaboration partners. For large Project Organizations, include a matrix outlining these relationships first, followed by the verbal descriptions for clarity.

Stakeholders are the people or groups who care about, are affected by, or can influence the success of a project. Think of them as anyone with a vested interest in what happens, whether it’s because they’ll use the end result, rely on it, fund it, or are just impacted by how it gets done. They can include:

• Users: The people who will directly use the product or service.
• Decision-Makers: Those who approve plans, budgets, or big changes.
• Team Members: The folks actually doing the work.
• Support Teams: Departments like IT, HR, or legal who help make it happen.
• External Parties: Vendors, contractors, or even regulators who play a role.

The key to handling stakeholders is keeping them informed, involved where needed, and ensuring their needs and expectations are balanced. Happy stakeholders = smoother projects.

TIP: How to Fill the Scope-Time-Budget Matrix

What Is This Matrix About?

This matrix forces you to prioritize between three critical elements in any project:

• Scope: What we’re delivering. This includes features, functionality, and quality.
• Schedule: When we’re delivering it. Deadlines, milestones, and launch dates.
• Resources: What it costs to deliver. Money, resources, and time invested.

You’ll decide for each if it should be:

• Optimized: This is non-negotiable. We aim to maximize results here at all costs.
• Compromised: We can be flexible. Trade-offs are acceptable to support other priorities.
• Restrained: This is fixed. No changes are allowed because the project would fail otherwise.

Why Is This Necessary?

No project has infinite time, resources, or scope. This matrix forces us to set clear boundaries upfront:

• Ensures everyone knows what matters most.
• Helps avoid conflicts later when compromises are needed.
• Defines what must succeed versus what can adapt.

Why Is It So Restrictive?

This isn’t just a preference; it’s a commitment. Once you fill it out:

• It locks your project’s DNA.
• Every decision made later will follow this logic.
• It prevents scope creep, delays, or overspending from derailing the project.

Why Can’t It Be Changed Later?

Shifting priorities mid-project creates chaos:

• Teams lose focus.
• Costs spiral out of control.
• Deadlines are missed.

This matrix ensures we stick to the plan unless a new project is created to redefine priorities.

How to Think When Assigning Priorities?

Ask yourself:

1. Scope: What are the non-negotiable outcomes? Is there room to deliver less or postpone features?
2. • Optimize scope if what’s being delivered is critical to success (e.g., the core product must work flawlessly).
   • Compromise scope if some features or quality levels can wait for later updates.
   • Restrain scope if changing it undermines the purpose of the project.
3. Schedule: How firm is the deadline? What happens if we miss it?
4. • Optimize schedule if hitting the deadline is make-or-break (e.g., legal compliance or a market window).
   • Compromise schedule if moving dates won’t have catastrophic consequences.
   • Restrain schedule if delays would ruin the project.
5. Budget: How much flexibility do we have financially? Can we afford overruns?
6. • Optimize budget if cost efficiency is the highest priority.
   • Compromise budget if spending a bit more is acceptable to ensure quality or speed.
   • Restrain budget if exceeding the budget would kill the project.

Example Thought Process

Imagine: You’re building a new product for a trade show six months from now. You decide:

• Scope: Compromise. Some features can be delayed until after launch.
• Schedule: Optimize. Missing the trade show is not an option.
• Budget: Restrained. There’s no extra funding available, so we must stick to the allocated resources.

When tough decisions arise (and they will), this matrix ensures we stay aligned on what matters most.

Details like descriptions, spreadsheets, charts, and more will be provided as needed, depending on the project’s complexity.

Details like descriptions, spreadsheets, charts, and more will be provided as needed, depending on the project’s complexity.

Severity rating:

• Critical: Irrecoverable damage done.
• Bad: ​Recovery costs more than the damage done.
• Tolerable: ​Recovery costs as much as the damage done.
• Nuisance: Recovery costs less than the damage done.
• None​: Recovery costs nothing.

Badges:

Critical Bad Tolerable Nuisance None

The applied likelihood rating method must be stated in this section's opening content! Ideally the same method should be used throughout all the assessed risks, however in special cases specificities may apply. In such cases, state the divergence in the diverging risk item(s') contents.

Recommended methods:

• Historical Probability Estimation
• Bayesian Probability
• Monte Carlo Simulation
• Expert Judgment with Weighted Averages
• Empirical Distributions

Recommended color and symbolism:

• Red: greater than 2:3
• Orange: Between 1:3 and 2:3
• Yellow: Below 1:3
• Iconography should use the same temperature icons as the severity ratings.

Assess the risk based on severity and likelihood and decide on the description's level of detail based on it.

Make sure to include mitigation and recovery plans, as fit for the given project.