Lean Project Charter Canvas
In the realm of Project Management, the Project Charter describes the project vision and objectives. It summarizes at a high level the project strategy, scope, organization and implementation. It also helps control the scope of the project, by defining what it is that you have to achieve.
The project charter has classically been a formal, written document which includes:
Reasons for undertaking the project
Objectives and constraints of the project
Directions concerning the solution
Identities of the main stakeholders
In-scope and out-of-scope items
Potential risks and constraints
Target project benefits
High level budget and spending authority
The project charter canvas provides a quick and broad definition of a project in a single overview. Here is an example of a project charter canvas with its 15 major “building blocks”.
15 building blocks of the Project Charter Canvas explained:
Summary: A brief but specific statement that describes the project.
Purpose: Describe the overall intent of the project and what caused the sponsors to decide to initiate the project. Here’s an example: “metrics show that conversion rates are slipping, and an analysis of the problem identified that the check-out process is too long for many shoppers. This project seeks to optimize the check-out process to increase conversion.”
Justifications/Benefits: List the concrete benefits that users will have when the project is successfully completed. What will they gain from it? This can include things like “faster check-out times” or “more control over their own content” and so forth.
Goals and Objectives: Focus on the project goals first. Keep the program goals in a separate list if you don’t want to lose them.
High-level Requirements: High level requirements describe in broad terms what you are looking for in a project. For example if you are designing an A/P system, a high level requirement would be to allow coding the G/L account number in the system. Low level requirement describe the details such as the input screen must have a method to search for the G/L number. Or it must validate the number.
Success Criteria: The metrics that will determine whether or not the project is successful.
Budget and Costs: Both cost estimates and budget are needed in order to determine the cost performance baseline and the project funding requirements.Cost estimates are the estimated costs for each work package or activity, whereas the budget allocates the costs over the life of the project to determine the periodic and total funding requirements.
Timeline and Milestones: List the key dates and events that frame the overall timeline of the project. This doesn’t need to be a detailed project plan. It should include things like “workshop with senior management,” “user testing sessions” and a launch date.
Major Deliverables: List the documents that will be delivered. This doesn’t need to include internal working documents, like spreadsheets and analysis documents. It should only include things stakeholders or other teams will see, as well as assets that appear in a product or service that customers may see.
Assumptions: Events that are expected to occur during a project’s life cycle, often without any proof. They are accepted as truths at the start of a project, though they can turn out to be false.
Risks and Issues: This is a list of potential future events that can have a negative impact on the project. For instance, recruiting users for testing may be a risk for target groups that are difficult to get to: in this case the impact would be slippage in testing timelines or a reduced sample size. You can also list how you might mitigate known risks here.
Constraints and Dependencies: Time and money are always constraints, and you need not list them here. Resources are also a typical constraint, so only list exceptional resource constraints. The focus should be on overarching limitations on work products and processes. For design, this may be something like: “the designs must comply with the CI guidelines.” Include technology and platform constraints here as well. For instance, if a website needs to work on an iPad and smartphone, you’ll want to know about it from the very beginning.
Structure: These are the methods and approaches you’ll be employing on the project. Examples include “User research,” “Persona development,” “Concept design,” “Wireframing,” “Creation of detailed mock-ups” and “User testing,” to name just a few design-related activities.
Stakeholders: This should include all people involved in the project in some way. Distinguish roles at high level with three separate lists: 1. core team, 2. stakeholders and 3. interested parties.” Include individual names as much as possible. Optional: in the lower half of this box you can show dependencies.
Team Roles and Responsibilities: Roles are the positions team members assume or are assigned --the part that each person plays in the organization. Responsibilities are the specific tasks or duties that members are expected to complete according to their roles. When roles and responsibilities are clearly defined, team members look beyond their own individual positions and learn to understand, respect, and value the unique contributions of one another, and they recognize that the overall success of the team is a function of shared responsibility and ownership.
A Project Charter Canvas can be anpowerful tool in a cross-functional project team meeting before project kickoff to initiate the conversations necessary to surface the assumptions, issues, risks, constraints, and definitions of success.