Project Charter: The Document That Launches the Project and Grants Authority

Many project managers start work before they hold the right to do it. Someone asks them verbally to "follow up on this," so they begin assembling a team and requesting resources, and then collide with a department head asking: on whose authority? The charter is the written answer to that question. In the Eighth Edition it is not a formality but an instrument of permission: issuing it brings the project formally into existence and creates the manager's authority to allocate organizational resources to its activities.

Definition and Foundation

A project charter is a document issued by the project initiator or sponsor that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities. That definition carries three elements that cannot be separated:

• The issuing party — the project initiator or sponsor, not the project manager. A manager does not grant themselves authority.
• Recognition of existence — with the charter the project becomes an entity the organization acknowledges, with an official record of its own.
• The grant of authority — the right to apply organizational resources to project activities. That right is the practical difference between a project manager and a coordinator with no power: the first requests a resource backed by a document, the second backed by a personal relationship.

The process that produces the charter in the Eighth Edition is Initiate Project or Phase within the Governance performance domain: it officially authorizes the start of a project and grants the project manager the authority to allocate organizational resources to project activities by creating a project charter or similar document. The wording there is precise and worth noting: authorization is "typically, but not always, via a charter." The charter is the usual vehicle, not the only one.

What the Eighth Edition adds most usefully is that this authorization establishes a direct link between the project, the business case, and the organization's strategic goals, creating an official record of the project and demonstrating the organization's commitment to it. The process is usually carried out once or at certain points during the life cycle of a project, depending on the development approach — so it is not necessarily a once-in-a-lifetime event.

How It Works in Practice

What precedes the charter: project justification

Project justification and organizational strategy, often detailed in a business case, provide the project team with the information necessary to make decisions that meet or exceed the intended business value. Desired outcomes should be clearly described, iteratively assessed, and updated throughout the project life cycle using quality gates, feedback loops, and regular reviews. The charter does not invent the project's rationale; it carries it from the business case into a binding document. The two are therefore read together rather than separately: one holds the reasoning, the other the permission.

What follows from the charter

The charter becomes an input to many later processes. The clearest is in the Scope performance domain: Elicit and Analyze Requirements takes it as an input alongside the project management plan and project documents. The charter defines the frame within which requirements are elicited, and attempting to elicit requirements without one produces a wish list with no boundary. The charter also appears among the project documents created across the five Project Management Focus Areas — initiate, plan, execute, monitor and control, and close — meaning it is not a document of the initiating stage alone but a reference invoked later whenever a boundary or an authority needs settling.

The charter as a reference in disputes

When parties disagree over scope or authority, the discussion returns to what was authorized. The Eighth Edition notes that key performance indicators may be included in the project scope statement, project charter, business case, or contracts. The charter is therefore one of the places success criteria are defined, which is what makes it a reference rather than merely a launch document.

The charter and the continuation review

The link the charter establishes between the project and the business case is not for the opening alone. The project team should adapt to changes and continuously evaluate alignment with the desired outputs, baselines, business case, and intended outcomes. If misalignment persists or the project is unlikely to deliver the intended value, it may be best to terminate the effort. That sentence appears outright in the guide and changes how the charter reads: it is an instrument of continuation as much as of launch. Add to it that all projects exist to pursue target organizational objectives worth more than what is invested in pursuing them — often significantly more than what might be available via alternative investment options. The comparison is not between the project and nothing, but between it and what the organization could have done with the same money.

On the Exam

A point worth pausing on: the 2026 ECO does not name the project charter in any enabler. The nearest tasks are Domain III, Business Environment, Task 1 — define and establish project governance, with its enablers on describing and establishing structure, rules, procedures, reporting, ethics, and policies; defining success metrics; and outlining governance escalation paths and thresholds — and Domain II Task 1, develop an integrated project management plan and plan delivery.

The dominant pattern is a scenario describing a manager without clear authority and asking for the action. Four keys settle most of it:

• Work that started with no formal authorization → the charter first, not team assembly.
• A dispute over the manager's authority to request resources → back to what the charter granted.
• A question about who issues the charter → the initiator or sponsor, not the manager.
• A project no longer delivering the intended value → evaluate alignment with the business case; termination may be best.

What deceives is that the options offer active steps that look proactive: starting requirements gathering, building the schedule, or negotiating with a department head for a resource. All are premature if no authorization exists, because each consumes people's time the organization has not yet permitted anyone to consume. So does an option making the project manager the one who both writes and approves the charter — contributing to the writing is plausible, but approval belongs to the sponsor.

Detailed Mistakes

Confusing the charter with the business case

The business case details the project justification and organizational strategy, answering "why is this work worth the investment." The charter answers "has the organization authorized it and who holds the authority." The first is analysis preceding a decision; the second is a decision in writing. Presenting a business case as a charter leaves the project manager with nothing to stand on when requesting a resource from another department.

Treating the charter as a document filed after launch

The link between the project, the business case, and the strategic goals should be iteratively assessed and updated throughout the life cycle using quality gates, feedback loops, and regular reviews. A charter that is signed and then archived loses its second function as the reference for reviewing whether the project should continue.

Assuming the charter is always issued once

Initiate Project or Phase is usually carried out once or at certain points during the life cycle, depending on the development approach. Multi-phase projects may authorize each phase separately. Assuming one permanent charter overlooks that moving into a new phase can call for fresh authorization and amended authority.

Where It Does Not Apply

The guide leaves a door open in its own wording: authorization happens "typically, but not always," via a charter, and the initiating process creates "a project charter or similar document." The substance is not the document's name but its function: formal recognition that the project exists, a documented link to the business case and strategic goals, and a clear mandate to apply organizational resources. In organizations working adaptively that function may be carried by a product vision document, a work order, or a board decision, so long as it holds all three elements. The failure does not occur when a document titled "charter" is absent, but when one of those elements is — work begins with no official record, or with no link to a justification, or with no documented authority over resources.