“Project Plan vs Project Charter: What’s the Difference?”

What is the difference between a project plan and a project charter?

The shortest accurate comparison is that the charter creates the project and the plan runs it. Everything else follows from that.

Read the “change frequency” row carefully, because it explains most of the practical behaviour. A charter that is updated every week is not a charter — it is a plan with the wrong title. A plan that never changes is not a plan — it is an intention.

What goes in a project charter?

A charter is a decision document, so it should contain only what a decision-maker needs to say yes.

The problem and the case. Two or three sentences on why this project, why now, and what happens if it is not done. If you cannot write this without adjectives, the project is not ready.

Measurable objectives. Not “improve customer experience” but “reduce onboarding time from 9 days to 4 by 30 June, measured from signed contract to first login”. One objective that can be tested beats five that cannot.

High-level scope and explicit exclusions. The exclusions matter more than the inclusions. A charter that says “out of scope: payment processing, mobile app” prevents four weeks of argument later.

Deliverables at the milestone level. Five to eight items, not a work breakdown.

Budget envelope and funding source. A range with a ceiling, not a spreadsheet. The detailed estimate belongs in the plan.

Named project manager and stated authority. This is the sentence teams skip and later regret: what the PM can decide alone, what needs the sponsor, and what needs a board.

Sponsor, key stakeholders, and the top three risks. Three risks, not thirty; the register belongs in the plan.

Success criteria and the definition of failure. Include the kill criteria. A project that cannot be stopped cannot be governed.

What goes in a project plan?

The plan is the operating manual, and it has to be specific enough that a new team member could run the next two weeks from it.

Scope baseline. A work breakdown structure to the level where work can be estimated and assigned, plus the acceptance criteria for each deliverable.

Schedule baseline. Activities, dependencies, durations, milestones, and the critical path. The schedule is the part stakeholders read, so it should be readable without training.

Cost baseline. Budget by cost centre or work package, with contingency separated from the estimate so nobody spends it silently.

Resource plan. Roles, named people where known, allocation percentages, and the skills gap you are papering over.

Quality plan. What “done” means per deliverable, who reviews it, and what evidence is kept. This is the section most often reduced to the word “testing”.

Risk register. Likelihood, impact, owner, response, and review date — a live table, not a list in a document nobody opens.

Communication and stakeholder plan. Who gets what, how often, in which channel. The plan should name the weekly status artefact and its audience.

Change control. How a change is raised, who assesses it, who approves it, and what the thresholds are. This is the mechanism that keeps the plan honest.

Baselines and version history. A plan without a version number and an approval date is a draft, and drafts do not govern anything.

When exactly should each document be written?

The charter is written before the work is planned in detail, and the plan is written before the work starts. That ordering is not bureaucratic; it protects the estimate.

If you plan in detail before the project is authorised, you spend real money — often 40 to 80 hours of senior time — on a project that may not happen. If you start work before the plan is baselined, the first status report becomes the plan by default.

A workable sequence for a mid-sized project looks like this: sponsor identifies the need; PM drafts a two-page charter in a day; sponsor and one or two stakeholders review it within a week; charter is signed; PM runs a planning workshop and produces the plan over one to two weeks; plan is baselined and the kickoff happens. Total elapsed time: three to four weeks, most of it waiting for calendars rather than working.

Who writes and who approves each document?

The sponsor owns the charter, even when the project manager drafts it. That distinction is the whole point of the document: if the PM writes and approves the charter, the project has no external sponsor, and the first escalation has nowhere to go.

The project manager owns the plan. The sponsor approves the baselines — scope, schedule, cost — because those are the commitments the organisation is making. The team contributes the estimates, and the estimates should be attributed, because “the team estimated nine weeks” survives pressure better than “the PM estimated nine weeks”.

In practice, a charter typically has one approver and two reviewers, and the plan has one approver and a longer review list. If your charter needs six signatures, it is either a very large programme or a governance problem.

How do the two documents work together in change control?

This is where the pair earns its keep, and where the arithmetic gets interesting.

Say a project is approved at $180,000 and 12 weeks, with a 10% contingency of $18,000. In week five, the client asks for an additional integration. The PM assesses it: six extra days of engineering, $9,400, and no effect on the critical path. That is a change to the plan: it consumes contingency, gets logged, gets approved by the sponsor at the weekly meeting, and the cost baseline moves to $189,400. The charter does not change, because the project still delivers the same outcome for the same reason.

Now suppose the same request turns out to require a second data source that the client has not built yet, pushing delivery to 16 weeks and the budget to $228,000 — 27% over the original. That is no longer a change request; it is a different project. The plan cannot absorb it, and the charter’s objectives and business case are now wrong. The correct action is to take it back to the sponsor as a re-authorisation decision, not to quietly move the baseline.

The rule of thumb: if the change alters scope, schedule, or cost beyond the approved tolerance, it goes to the charter level. Tolerances are usually expressed as a percentage — often 10% on cost and 10% on schedule — and they belong in the charter so nobody has to invent them mid-argument.

What happens if you skip the charter?

Four expensive things, and they are predictable enough to plan around.

Authority disputes. Without a named PM and stated decision rights, every decision becomes a negotiation. On a six-month project, an extra two hours a week of escalation and re-confirmation is 52 hours — at a $75 loaded rate, $3,900 of avoidable cost, and that is the optimistic case.

Scope inflation. A project with no written exclusions accepts work by default, because refusing requires a document to point at. Teams that skip charters typically absorb 15–25% unplanned scope in the first two months.

No kill switch. Projects that cannot be stopped keep consuming budget. The charter is the only place where “we will stop if X” can be written down before anyone is emotionally invested.

Sponsor absence. Without a named sponsor, no one is accountable for removing blockers, and blockers are what actually delay delivery. The schedule slips while the team is working hard, which is the most demoralising failure mode in project management.

The counter-argument — that a charter slows down a fast-moving team — usually dissolves when you time it. A two-page charter takes four to six hours to draft and a week to approve. That is less time than a single unresolved scope argument.

What happens if you treat the plan as a one-time document?

The plan degrades into fiction, and then into decoration, in about six weeks.

The mechanism is simple. The plan is baselined in week one. Reality diverges in week three. Nobody updates the plan because updating it feels like admitting failure. By week six the plan shows a delivery date that everyone knows is wrong, so the team stops referring to it and starts using a spreadsheet, a chat channel, and memory. At that point you have three plans, none of which is authoritative.

The fix is cadence, not discipline. Update the plan at a fixed rhythm — weekly for the schedule and risks, monthly for the cost baseline — and record what changed and why. A plan with a visible change log is more credible than a plan that has never been revised, because the first one describes reality.

There is a second failure mode worth naming: the plan that is so detailed it cannot be maintained. A 200-line schedule for a 10-week project will be out of date within days. Plan to the level you can maintain weekly, and keep the rest in the backlog.

How long should each document be?

Short enough that the intended reader actually reads it, and long enough that a new team member can act on it.

The pattern is that length scales with the cost of being wrong, not with the size of the team. A $2m project with eight people needs more documentation than a $40k project with thirty.

Does agile change the answer?

Not the concepts — only the artefacts and the cadence.

In an agile context, the charter compresses into a product vision, a one-page project canvas, or a lightweight business case approved at portfolio level. What survives is the essential content: the outcome, the owner, the constraints, the definition of success, and permission to spend. Teams that skip this stage entirely are the ones where a “quick initiative” runs for nine months with no sponsor.

The plan compresses into a roadmap, a release plan, and a sprint backlog. The baseline becomes the sprint commitment and the release forecast, and change control becomes the backlog’s ordering discipline. That is a legitimate substitute — as long as someone can still answer “what did we agree to deliver, by when, and who approved the change” without a meeting.

Which mistakes are most common?

Writing the plan first. It feels productive and it is backwards; you cannot plan work whose existence is not authorised.

Turning the charter into a plan. Ten-page charters with a full WBS defeat the purpose: the sponsor stops reading, and approval becomes a formality.

No exclusions. The single highest-value line in any charter.

Unnamed approver. “Leadership” is not an approver. A person with a calendar is.

Baselines without tolerances. If nobody agreed what “on track” means numerically, every status meeting renegotiates it.

Confusing the two in conversation. When someone says “the plan says we can’t do that”, check whether they mean the charter. Half of all scope arguments are charter arguments in plan clothing.

Where does Doitify fit?

Doitify is our product, so read this as disclosure. The documents in this article are decisions, and decisions need somewhere to live next to the work they govern — which is the gap most teams actually have.

Doitify is built as one workspace for projects, tasks, sub-tasks, checklists, owners, and due dates, with Kanban boards, Gantt charts, roadmaps, calendars, workload views, work and performance reports, project documents, meeting notes, milestones, risks and constraints, and automations. A charter can sit as a project document with an approval record; the plan can be the live schedule, milestones, and risk register that the team updates weekly. That keeps the baseline and the status report from drifting into two different truths.

Conclusion

The charter and the plan answer two different questions, and confusing them costs real money. The charter asks whether the project should exist and who is allowed to run it. The plan asks how it will be delivered, and it changes every week while the charter mostly does not.

Write the charter in a day, get it signed by a named person, and keep it to three pages. Build the plan after that, baseline it, and give it a change log and a tolerance. If a request cannot be absorbed inside those tolerances, it is not a plan change — it is a new decision, and the document that records decisions is the charter.

If this post on project plan vs project charter was helpful, you might also enjoy Capacity Planning in Project Management (2026 Guide) and How to Keep a Project on Track: Early-Warning Tips.