What is a project charter?
A project charter is a (usually) short, formal document that officially authorizes a project. Depending on the organization, it may be a powerpoint slide, or it may be a multipage spreadsheet! It serves as a foundational agreement, outlining the project’s purpose, objectives, key stakeholders, and scope of work. Providing a high-level overview ensures everyone involved understands the project’s core elements and shared goals. This can be used as a tool to help team members prioritize and make decisions that come up during development, similar to the way that a vision/mission statement can help projects align to company goals.
Who owns the charter?
The project manger is responsible for creating the charter, but it's not done in isolation. In order to identify goals, stakeholders, priorities, and budgets, the PM will need to communicate with many people internally to produce something that will get approval. Depending on the company and the size of the project, it may require an executive sponsor or steering committee to approve it.
It's not a project plan
The charter establishes the initial scope and impetus of the project. It doesn't change, even when the project (inevitably) does, because it represents the approved contract for that project.
What goes in the project charter?
This will vary from company to company, but at a high level, it should define the project, the reasons that it's being done, who it impacts, what the high level scope, budget, and timeline is, and what risks are known. We'll use a simple project charter that ignores some of the complexity of a real project (like budget and approvals) and focuses more on scope and purpose.
- Project Name
- Project Purpose
- Potential Users
- Scope
- Milestones
- Risks
Project Name
OK, this is pretty self explanatory, but frequently having a good project name can help get a project approved. Having a good acronym or an awesome tech sounding name can make it easier to convince your management to move the project forward. This should not be just what the project is - "A social media application to allow people to pursue casual online gambling" is a stupid name when compared to "Operation Jackpot".
Project Purpose
Why do the project at all? What problem does it solve? What niche does it fill? What is different about this project from all the similar software that currently exists (and there is ALWAYS software that currently exists).
Potential Users
Who are the people you hope will be your users?
- Are there multiple groups, like in an LMS where there are students, teachers, and adminstrators?
- Why are they using this, is it for work, like an office hours scheduler or for fun like a fantasy footbal league?
- How often would they use it, is it a daily interaction like a social media feed, or something they might use once or twice a year like a trip planning app?
- In what context will they use it - is this something you do on a desktop/laptop on a regular schedule, or something you do on your phone anywhere, or both?
Scope
What features need to be there in order for your project to function? What features will you explicitly not include, due to time/cost/feasibility? This doesn't need to be detailed (that's for the scrumboard and requirements) but should contain high level elements such as
- Platform : Is it a responsive web app that will be tested on chrome and firefox, or it is a native iOS app, or it is a desktop application targeting windows only?
- Hosting : Where will it be deployed?
- High level features : Social Media might include a list like profile, posting, friends, notificaitons, and chat. A marketplace app might include a list like user and admin roles, posting items for sale, negotiating price, leaving reviews and feedback, admin access to review/approve/ban content and users.
- Out of scope : Is it Android only? Will it not include real time notifications? Will it not include payment gateways?
Milestones
What will the focus of each sprint be? This will tie into your roadmap, and the high level sprint definitons. When sprint 1 is done, what should you have? 2, 3 and 4?
Risks
What potential risks exist, and how will you mitigate them? Is the team new to the technology? Do you need to use an external API but are not sure which one? Is the project dependent on external data, or does it have potential resource issues, or is it constrained to a particular technology that doesn't support features you would like to have?