Project Charter
The project charter is how we define the project. It's a document that we create at the beginning of the project that contains the problem statement, timeline, players, and project goals. During the product workshop, we'll define all of these and finalize the document before we beginning real work on the project. The project charter helps us stay focused and ensures the product decisions we make fit in line with our charter.
1. Problem statement
All projects start with a problem, whether it's a business problem, process problem, or customer problem. This problem drives the need for the technology and should also drive the way we understand the project and create our solution.
The problem statement should be phrased as a question. The statement should provide clarity into the product that we're building. It imposes constraint so we can focus on why we are building this product. Some examples:
Problem statement: How can we improve our claims team productivity by automating tasks?
Problem statement: How can we provide live concert experiences to fans when they can't make it to the show?
Problem statement: How can we reduce the time the account management team spends creating shipment tracking spreadsheets for customers each day?
Problem statement: How can we reduce the amount of time hiring managers spend reviewing candidates that fail a background check?
A problem statement should be short, succinct, and focused. It should be human-centered since we're solving a problem for a particular user. The problem statement should be broad enough to allow for creative freedom but narrow enough to be manageable.
2. Timeline
Another important goal of the workshop is to identify the timeline for the project. The timeline is not a schedule. It's a rough idea for how much time we want to invest into product to launch. While the project might have multiple phases that span over a year, it's important to identify when the first version should be completed. The timeline should help us contain the scope of work that we take on and avoid project bloat.
3. Players
Another major component for success is defining all the players involved in the project team. For some teams it can be a single person but for larger organizations there can be various players involved from decision making to integration to operations to sales. Identifying these players upfront help us identify the various points-of-views as we develop the product.
Experts: Individuals within the organization who are subject-matter experts in the area of the business for which the product is intended.
Stakeholders: These individuals are from the business-side, they are usually in charge of the budget and have a business stake in the success of a project.
Builders: This is the team that is accountable of the execution of the product, they could be designers, developers, or project managers. This should also include any individuals with knowledge of other systems within the organization for which we must interface with.
End Users: These are the humans that will be using the final product, whether they are internal company users, customers, or regular people. While they are not formally part of the team, they will play a large role in helping us make informed decisions through user testing and interviews.
It's important to identify which category each of the players fit within. This helps us understand how we should make decisions and from which perspective we should view individual contributions.
4. Goals & Success Metrics
The last part of our charter identifies the goals for the project and how we are defining success. These should be scoped to the project, not necessarily the business goals, although these commonly overlap. Our goals should be achievable through the decisions we make building the product. Some examples:
Goal: Reduce the overall time it takes for a claims representative to assign and dispatch a contractor.
Goal: Customer should be able to track their shipments directly from their dashboard.
Goal: Reduce illegitimate applicant request by automating background checks within the hiring dashboard.
These are attainable goals for our project that the team has control over. A goal like "1,000 new users per week" is not something we can control. But simplifying the onboarding process can reduce abandonment and, in turn, lead to one thousand new users per week.
For each of our goals, we'll set a success metric to identify if we've hit our goal or not. For example:
Success: Average time to get a confirmed contractor dispatched is reduced to from 5 hours to 1 hour.
Success: Reduce need for account team to send shipment tracking spreadsheets by 50%.
Success: Number of candidates dropped for failing background checks is reduced by 85%.
Success metrics should be based on measurable data. If we're going to reduce contractor dispatching from 5 hours to 1 then we must have solid data that on what's involved in the dispatching process in order to achieve our goals.
These goals must match up with our problem statement. If any goals or success metrics don't align with the problem statement then it must be removed or the statement must be accommodate the new direction.