Getting Your Project Charter Right
Beyond the project hard facts of budget, stakeholders, dates, and milestones, your project should have a high-level charter that helps align you with the client and the team with the vision.
This can come from the account manager before PM is making a dent in the project. Or you the PM can create this before the project kicks off but some time after your stakeholder interviews, it will depend on your process. Here are some guiding things to think about and consider adding to your project charter document.
Purpose What Is the Issue to Be Addressed? Provide a high-level statement explaining why this project has been proposed. What is the need that this project meets? Is there a business case or value proposition that can be made? Why are we here making the thing? What is the mission? What is the purpose?
Description What Is the Client Asking Us to Do? Describe the specific request from the client. What are they asking us to do in response to the issue/purpose outlined above? Make a website. Make an app. Build an API. Perform a service. Etc
Objectives What Does Success Look Like? Describe the goals and desired outcomes for the project. This should paint a clear picture of what success looks like for this project. We may choose to include both internal and external objectives. How do we know we are hitting the mark.
Deliverables What Will Be Given to the Clients? Deliverables are quantifiable goods or services that are provided to the client upon completion of a project or phase. A deliverable may be tangible or intangible. Are we sharing credentials to a resource, are we submitting a patch. Are we handing off any artifacts?
Activities What Does the Work Look Like? Provide a list of work streams, work packages and/or specific activities that might be included in the project plan. A design phase, a pm resource, a dev track, release management, quality services, on-site, offsite, coding, partnering, meeting, what is going on or happening.
Requirements What Are the Constraints & Assumptions List all known project requirements, assumptions, and constraints. Requirements should map to specific deliverables. This is meant to be at a very high level.
Risks What Unforeseen Events May Impact the Project? Record all known high level risks A risk is an unforeseen event that may impact a project. A risk may have either positive or negative consequences. Consider budget, scope, timeline, quality. You must identify some risks, none identified is a big red flag.
Scope What Are the Key Elements? Define what is and is NOT in scope. Keep it high level. Draw boundaries. Manage the large expectations. Explicitly call out Phase 2 items that have already been identified.
Dependencies What Known Items May Impact the Project? Record all known high-level risks that are based on known dependencies, eg: pending design, an in-flight backend for a front end project, etc.