Project Charter

What a Project Charter Contains

A project charter is not a detailed plan. It is an authorization document: a formal declaration that a project is approved to proceed and that the project manager has the authority to apply organizational resources to it. Its job is to answer six questions at a high level before any detailed planning work begins.

Project Purpose and Business Case

The most important section of a project charter is the business case: why this project is worth doing and what business problem or opportunity it addresses. The business case ties the project to organizational strategy and provides the filter for every scope decision that follows. When a scope question arises during execution, the business case answers it: does this addition serve the purpose we authorized, or is it something else?

The business case in a charter does not need to contain a full financial analysis. It needs to state clearly: what problem does this project solve, what is the expected benefit, and what happens if we do not do it? One clear paragraph often suffices. The full financial justification lives in the business case document, which the charter references rather than reproduces.

Scope and Deliverables

The charter defines project scope at a high level: what the project will produce and, critically, what it will not produce. The scope boundary is as important as the scope itself. A charter that defines what is in scope without defining what is explicitly out of scope invites scope creep from the moment the project begins.

Deliverables in the charter are high-level: a new billing module, a redesigned checkout flow, a completed compliance audit. The WBS and project plan will decompose these into work packages later. The charter is not the place for that decomposition.

Stakeholders and Roles

The charter identifies the key stakeholders by name and role: who sponsors the project, who will use its outputs, who must approve deliverables, and who is the project manager. Naming the project manager in the charter is what establishes their authority. A project manager without a charter, or with a charter that does not name them explicitly, has limited standing to commit resources, make decisions, or resolve escalations.

The RACI matrix, if the project is large enough to warrant one, is built after the charter is signed. The charter just establishes who the key parties are.

Budget and Timeline

The charter contains high-level budget and timeline information: the order-of-magnitude cost estimate and the expected delivery timeframe, not a detailed budget breakdown or Gantt chart. These high-level figures serve as constraints that the detailed plan must fit within. If the detailed plan exceeds the charter constraints, the project manager either revises the scope or escalates to the sponsor for a charter amendment.

A budget range rather than a precise number is appropriate at this stage: the detailed estimate is produced during planning, not before it. A charter that contains a precise budget number before any planning work has been done is likely to be wrong in a way that creates problems when actual costs are understood.

Risks and Constraints

The charter identifies the known risks and constraints that will affect the project. Constraints are fixed conditions the project must operate within: a regulatory deadline, a technology platform that cannot be changed, a team size limitation. Risks are uncertain events that could affect the project’s ability to deliver on time, within budget, or at the required quality level.

Neither section needs to be exhaustive in the charter: the risk register built during planning provides the detail. The charter serves notice to stakeholders that these risks and constraints are known and accepted as part of the project authorization.

Approval and Authorization

The final section is the approval block: signatures from the project sponsor, key stakeholders, and the project manager. Signatures indicate that each signatory accepts the project as authorized, agrees with the stated scope and objectives, commits the resources attributed to their area of responsibility, and authorizes the project manager to proceed. Without signatures, the charter is a proposal, not an authorization.

When the Project Charter Is Created

The project charter is created at the end of the initiation phase, after the business case has been approved but before any detailed planning begins. In a Waterfall project, the charter is the output of the Initiation phase and the input to the Planning phase. In PRINCE2, it maps to the Project Brief produced during Starting Up a Project and the Project Initiation Documentation produced during Initiating a Project.

The timing matters because the charter serves a specific purpose at a specific moment: it converts a business case into an authorized project. Created too early (before the business case is approved), the charter authorizes something that may not proceed. Created too late (after planning has already begun), the charter ratifies work that was already happening without formal authorization, which creates accountability problems if the project encounters problems.

When to Use a Project Charter

A project charter is appropriate for any project significant enough to require formal authorization: cross-functional projects where multiple departments must commit resources, projects with a defined budget that requires approval, projects with external stakeholders or clients, and any project where the project manager’s authority needs to be explicitly established.

Organizations that run projects without charters consistently encounter the same problems: unclear scope boundaries that grow throughout execution, project managers without the authority to make decisions, and stakeholders who are surprised by project outcomes because they never formally agreed to the scope and objectives.

When a Project Charter Is Unnecessary Overhead

Small, internal projects run by a single team within a single department often do not need a formal project charter. If everyone involved works for the same manager, the scope is well understood, and there is no external approval required, a brief project brief or even a task description provides sufficient authorization without the overhead of a formal document with signatures.

Agile projects operate with a different authorization model. Rather than a single charter that defines the full scope upfront, agile projects typically work from a product vision and a backlog. The vision serves the purpose of the charter’s business case section; the backlog serves the purpose of the scope definition section. Producing a formal Waterfall-style charter for an agile project that deliberately keeps scope flexible creates a false sense of certainty that conflicts with the iterative model.