Charters have a reputation as paperwork, and a good deal of that reputation is earned, because most of them are written to satisfy a stage gate and read once. A charter that does its job is a short document you can take to somebody who is refusing to help, and it is the only artefact on a project whose whole purpose is to establish that the work is real and that you are the person running it.
Section 4 of the PMBOK® Guide Eighth Edition covers the artefacts a project produces and consumes, and the charter sits at the front of that set for a structural reason: it is what brings the project into existence and gives its manager standing.
Authorisation. It records that an identified sponsor has committed the organisation to the work and has appointed somebody to manage it. Without that, a project manager is a person with a plan and an opinion, and the difference becomes apparent the first time a department head declines a request.
Alignment on the objective. It states, briefly, what the project is meant to achieve, which forces the sponsor to write a sentence they will be held to. A surprising number of projects reach month three without that sentence existing anywhere, and the symptom is that two stakeholders describe the purpose differently and both are certain.
The objective in a short paragraph. What will be different when this is finished, in terms somebody outside the project would recognise. Not a list of deliverables, which belongs further down, and not a strategy statement, which commits nobody to anything.
The project manager's authority and tolerances. What they may decide alone, and beyond what limits they must come back. Spend up to this figure, move a date by up to this many weeks, commit these categories of resource. This is the most useful content in the document and it is the part most often omitted, which leaves a project manager to discover their limits by exceeding one.
Key constraints and assumptions. The immovable date, the funding envelope, the regulatory requirement, the assumption that a particular system will be available. Writing these at the outset gives everybody a shared starting position, and it gives the project manager something to point at when a constraint is later treated as negotiable by somebody who has forgotten it was agreed.
The sponsor, by name. Not a department or a committee, but the person who will take the decisions the project cannot. A charter with a body rather than a person in that line predicts exactly the escalation problems the project will have.
An automotive supplier was introducing a new sub-assembly process ahead of a model change, with a project manager appointed from within manufacturing engineering. No charter existed, which was normal in that plant; the project had a budget code, a target date and a slide from a management meeting.
For the first two months it did not matter. Then the project needed eight hours a week of a controls engineer who reported to the manufacturing engineering manager, and the request was declined, politely and twice, because the engineer was committed to line support and nobody had told the manager otherwise.
The project manager had no document that said this work was authorised, that he was running it, or that it had a claim on anybody's time. What he had was a slide, and a slide is not an instrument. The matter went to the plant director, took three weeks and a certain amount of residue, and was resolved in his favour, which did not make the three weeks free.
The charter written afterwards ran to a page and a half. It named the sponsor, stated the objective in four lines, listed the resources committed by department with the sign-off of each department head, and set out what the project manager could decide alone: spend to a stated figure, sequence changes inside the window, and any date movement of under two weeks. It was printed, and it went behind a perspex cover on the board in the line-side office, which was the plant's convention for things that were not to be pinned over.
Two further requests were declined during the project. Both were settled inside a day by a conversation with the page open, because the argument had already been had.
That it is a plan. A charter says what the project is for and who runs it; it does not say how the work will be done. Charters that grow into plans get out of date within a month and are then abandoned, taking the authorisation with them.
That it replaces the business case. The business case argues that the work is worth doing and belongs to the sponsor; the charter authorises it and appoints a manager. They answer different questions and they are usually owned by different people.
That adaptive projects do not need one. A team working iteratively still needs somebody to have said this work is authorised, here is the purpose, here is the person accountable, here are the limits. The content is the same and it is often shorter, because the detailed scope is genuinely expected to evolve.
For a PMP® candidate, the practical reading is that the charter authorises the project and the project manager, so a scenario where somebody refuses to release resources is worth examining for what was ever formally agreed. A response that escalates without a document escalates an opinion. Situations where the work is legitimate and the authority was never written down are a regular feature of a structured PMP exam preparation course.
Where there is no charter, a page will do, and this week is a good time. Objective, sponsor by name, the limits you work inside, and the resources committed with the agreement of whoever owns them. Ask the sponsor to send it out rather than sending it yourself, because who signs it is most of the point.
The charter is the least glamorous artefact on a project and the only one that establishes standing before anything goes wrong. Omega's PMP® Exam Preparation works through initiation as the point where authority is set.
The project charter is described among the artefacts in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
A168: Business Case vs Project Charter: What’s the Difference?
A174: Work Breakdown Structure: Still Useful in 2026?
A170: Decision Log: The Forgotten Project Control
A169: Assumption Log vs Risk Register
A171: Change Log vs Issue Log
PMP and PMBOK are registered marks of the Project Management Institute, Inc.