If there is one document that I consistently see underestimated, it is the humble Project Charter.
I’ve lost count of the number of times I’ve seen project teams spend weeks building detailed schedules, risk registers and cost plans, only to throw together the Project Charter in half an hour because they see it as little more than an administrative hurdle.
That is a huge mistake.
The Project Charter is the document that gives the project permission to exist. Without it, everything else is built on shaky foundations. Think of it as asking an investor to put their money into a business. If you can’t explain why the investment makes sense, why would anyone approve it?
Yet many project charters fail for exactly that reason. They are full of technical language, vague objectives and management jargon, while completely forgetting the one question every executive is silently asking:
“Why should I spend money on this?”
Everything in your charter should help answer that single question.
Why Every Project Charter Should Start with the Business Problem
One of the biggest traps new project managers fall into is starting with the solution instead of the problem. They’ll proudly announce that they’re implementing a new CRM system, replacing an ageing finance package or upgrading the company website.
To them, that sounds exciting.
To an executive, it often sounds like an invoice.
Nobody really buys projects. They buy solutions to business problems.
Imagine going to your doctor and saying, “I’d like knee surgery.”
The doctor’s first response wouldn’t be to book an operating theatre. They would ask what was wrong with your knee.
Projects work exactly the same way.
Instead of saying you’re implementing a new customer relationship management system, explain that customers currently wait four days for responses to enquiries, complaints are increasing and repeat business is beginning to fall. Suddenly everyone understands why the project matters. The software is no longer the objective. It is simply one possible solution to the real business problem.
That small change in thinking transforms the entire Project Charter.
Understanding the Difference Between Deliverables and Benefits
Another area that causes endless confusion is the difference between deliverables and benefits. I still see experienced project managers mixing the two together.
Installing a new payroll system is not a benefit.
Producing a new website isn’t a benefit either.
Those are deliverables.
Benefits are what happen afterwards.
- Payroll processing becomes faster.
- Administration costs fall.
- Customer satisfaction increases.
- Sales improve.
- Employees spend less time carrying out repetitive work.
The organisation doesn’t care that you’ve produced another piece of software. It cares about what changes because that software now exists.
Whenever you’re writing a Project Charter, keep asking yourself one simple question:
“So what?”
We’ve installed a new system.
So what?
We’ve automated our reporting.
So what?
Eventually you’ll reach the real business benefit, and that’s what belongs in your charter.
Defining the Project Manager’s Authority
Over the years I’ve also learned that a surprising number of project problems begin because nobody ever defined what authority the Project Manager actually has.
I’ve walked into organisations where the Project Manager couldn’t approve a £500 purchase without obtaining three separate signatures, yet everyone somehow expected them to deliver a multi-million-pound programme.
That simply isn’t realistic.
Your Project Charter should leave no doubt about who has authority to make decisions, approve expenditure, assign resources or negotiate priorities with departmental managers.
The clearer these boundaries are at the beginning, the fewer political battles you’ll end up fighting six months later.
Keeping the Project Charter Clear and Focused
Another mistake is trying to cram the entire project into the charter.
I’ve seen charters running to thirty or forty pages. I can almost guarantee that very few people ever read them.
Remember what this document is trying to achieve.
- Its purpose isn’t to describe every requirement.
- It isn’t to explain every risk.
- It isn’t the detailed project plan.
Its purpose is much simpler than that.
It is asking the organisation to commit resources to a project.
That’s all.
Think of it like buying a house. Before you exchange contracts, you don’t need to know the colour of every carpet or the exact position of every electrical socket. You simply need enough information to decide whether it’s a sensible investment.
The same principle applies to a Project Charter.
The scope should therefore remain at a sensible level. Explain what the project will deliver, but equally importantly, explain what it won’t deliver. Those exclusions often save more arguments than the inclusions.
Identifying Risks Before They Become Problems
The same philosophy applies to risks.
At this early stage nobody expects you to produce a beautifully crafted risk register containing dozens of detailed entries.
What they do expect is evidence that you’ve already started thinking.
- Perhaps there’s a dependency on a supplier.
- Perhaps new legislation is approaching.
- Perhaps specialist resources are difficult to obtain.
- Perhaps the technology has never been used before.
Mentioning these significant uncertainties demonstrates maturity and realism. Executives know every project contains risks. What concerns them is when a project manager behaves as though everything will magically go according to plan.
Why Executive Sponsorship Makes All the Difference
One person whose role should never be underestimated is the Project Sponsor.
Far too often I see sponsors treating the charter as another document to sign before disappearing into the background.
That’s not sponsorship.
A good sponsor genuinely owns the business case. They understand why the project exists, what success looks like and, just as importantly, what happens if difficult decisions need to be made later.
When the inevitable problems arise – and they always do – the sponsor becomes your biggest ally.
Final Thoughts on Writing a Project Charter That Gets Approved
Finally, let me leave you with one piece of advice that has served me well throughout my career.
If your Project Charter needs forty pages to explain why the project should exist, there’s a fair chance you haven’t really understood the project yourself.
The very best Project Charters I’ve ever read were remarkably short.
Not because they lacked information – but because they contained only the information that mattered.
- They explained the problem.
- They explained the proposed solution.
- They identified the expected business benefits.
- They clarified who was responsible.
- They established the project’s boundaries.
And then they stopped.
That is exactly what decision-makers need.
A good Project Charter doesn’t impress people because it’s thick. It impresses people because it’s clear. It gives executives confidence that somebody has thought carefully about the investment they’re about to make.
When you can achieve that, approval becomes far easier, and your project begins its life on solid foundations instead of trying to recover from a weak start.
