The One-Page Project Charter That Actually Works

I've seen project initiation documents that run to 40 pages. Detailed governance structures. Elaborate stakeholder matrices. Comprehensive risk registers. Beautiful formatting.

Nobody reads them.

The sponsor skims the executive summary. The team never opens the file. Three months in, someone asks a question that's answered on page 27, and everyone looks blank.

Here's what actually works: one page. Everything that matters. Nothing that doesn't.

Why One Page?

Constraints force clarity. When you've only got one page, you can't hide behind jargon or pad with filler. Every word has to earn its place.

More importantly, one page gets read. Stick it on a wall. Email it to stakeholders. Pull it up at the start of every steering committee. It becomes a living reference, not a document archaeology exercise.

The discipline of condensing your project to a single page also reveals gaps in your thinking. If you can't explain the "why" in two sentences, do you actually understand it?

The Template

After years of iteration across EU institutions, government bodies, and private sector clients, here's what works:

Section by Section

WHY (The Problem Statement)

This is where most charters fail. They describe what the project will do, not why it matters.

Your "why" should pass the "so what?" test. "We're implementing a new CRM" — so what? "We're losing 15% of leads because sales can't track follow-ups, costing us approximately €200K annually" — now I understand.

Include the consequences of inaction. What happens if we don't do this project? That creates urgency and justifies the investment.

WHAT (Deliverables and Scope)

List concrete, tangible outputs. Not activities, not objectives — things you can point to and say "this exists now that didn't before."

The "Out of Scope" section is equally important. It prevents scope creep by creating explicit boundaries. When someone asks "can we also add..." you point to the charter.

WHO (Team and Stakeholders)

Keep it tight. Core team members with their roles. Key stakeholders who need to be involved in decisions or kept informed.

If you can't fit everyone on one page, you've got too many people involved. That's a red flag in itself.

WHEN (Timeline and Milestones)

Start and end dates. Three to five key milestones — the moments when something demonstrable is complete.

Avoid listing every task. This isn't a project plan. It's the headlines.

HOW MUCH (Budget and Resources)

Total budget. Full-time equivalent resources. If there are significant capital vs. operational splits, note that.

Don't include detailed cost breakdowns here. That's for the project plan.

RISKS (The Three That Keep You Awake)

Not a comprehensive risk register. The top three risks that could derail the project, each with a one-line mitigation.

If you can't identify three real risks, you haven't thought hard enough about what could go wrong.

SUCCESS (Measurable Outcomes)

How will you know this project succeeded? Not "the system was delivered" — that's an output, not an outcome.

Think: reduced processing time by X%, increased customer satisfaction score by Y points, saved Z hours per week.

Making It Work

The charter isn't a one-time document. Use it:

• At kickoff — Walk through it with the team. Make sure everyone understands the "why."
• At steering committees — Display it. Reference it. "As stated in our charter, success means..."
• When scope creeps — "That's not in our charter. We'd need to revise and get re-approval."
• At project close — Compare outcomes against the success criteria you defined at the start.

Print it. Stick it on the wall. Make it impossible to ignore.

What About Governance, RACI, and All That?

Still useful. Still necessary for larger projects. But they're supporting documents, not the charter.

The charter answers: What are we doing, why, and how will we know it worked?

Everything else — detailed governance, communication plans, RACI matrices — supports that central understanding. Create them as needed. Reference them from the charter. But don't let them dilute the core message.

"If I had more time, I would have written a shorter letter." — attributed to various authors

The same applies to project charters. A one-pager takes longer to write than a twenty-pager. It requires ruthless prioritisation. But the result is something people actually use.