Every major project seems to start the same way.
The procurement process concludes. Contracts are signed. Mobilisation begins.
Then someone asks:
"When are we doing the charter?"
It has become as routine as contract execution. A recognised milestone in project mobilisation. Almost a symbol that the team is serious about collaboration, culture and performance.
The irony?
Many project charters are never used again.
They become beautifully designed documents that capture a moment in time, before quietly disappearing into SharePoint folders and induction packs, rarely influencing a decision, resolving a conflict, or changing how people behave.
The charter gets completed.
The work of creating a project culture does not.
Why Charters Exist at All
There is a reason project charters became so prevalent.
As Sun Tzu famously observed in The Art of War, "a battle is won or lost before it is fought."
The same is true of projects.
Many projects succeed or fail long before the first activity is undertaken, the first design is produced, or the first asset is constructed. Success is often determined during mobilisation, when expectations are formed, relationships are established, decision-making approaches are agreed and a collective understanding of success is created.
This is where the charter can play a vital role.
At its best, a charter helps answer questions that contracts alone cannot:
- Why are we here?
- What are we trying to achieve together?
- What matters most when difficult trade-offs arise?
- How will we behave when pressure emerges?
- How do we want to be remembered at the end of this project?
These are not trivial questions. In fact, they are often the questions that determine whether a project becomes merely compliant or genuinely exceptional.
The problem is not that we have too many charters.
The problem is that we often mistake the completion of the charter for the achievement of alignment.
Completing a workshop is easy.
Building a shared understanding that influences thousands of decisions over multiple years is considerably harder.
That distinction matters.
Because the value of a charter is not found in its development.
It is found in its application.
Why We Keep Creating Them
At their best, charters serve an important purpose.
They create alignment around:
- Shared purpose
- Project objectives
- Expected behaviours
- Decision-making principles
- Ways of working
For large, complex and high-risk projects, this can be invaluable.
When hundreds of people from multiple organisations are attempting something never done before, collective alignment cannot be assumed.
It must be built deliberately.
The problem is that many projects have adopted the practice without being equally clear on the purpose.
The result is a familiar workshop.
A vision statement is written.
A list of objectives is agreed.
A set of behaviours is selected.
Values are debated.
Everyone signs the document.
Then, too often, everyone returns to operating exactly as they did before.
The Three Components Nobody Questions
Most charters contain three common ingredients. Some contain more.
1. Vision
Usually expressed as a shared purpose or aspiration.
2. Objectives
The outcomes the collective team is seeking to achieve.
Sometimes these are contractual requirements.
Sometimes they are incentive outcomes.
Sometimes they are simply aspirations.
3. Behaviours
The agreed standards for how people will work together.
Increasingly these include language around trust, transparency, collaboration, accountability and respect.
None of these elements are inherently wrong.
The question is whether all of them are necessary.
And whether they are being used.
What If We Only Designed What We Needed?
Instead of building a full charter because every project does one, what if we started with a simpler question:
What problem are we actually trying to solve?
If the challenge is behavioural alignment, perhaps the project only needs a behavioural framework.
If decision-making is the issue, perhaps it needs governance principles.
If purpose is fragmented, perhaps it needs a compelling shared vision.
Not every project requires the full architecture.
Perhaps we should become more disciplined about designing only what is required.
From Document to Architecture
The more useful way to think about a charter may be as project organisational architecture.
Projects routinely define:
- Which safety management system applies
- Which document control system applies
- Which reporting processes apply
- Which governance forums apply
Yet when it comes to culture, we often create an independent document and hope it somehow influences the project.
A better approach might be to deliberately connect these elements.
If collaboration matters, how is it reflected in governance?
If accountability matters, where does it appear in decision-making?
If values matter, where do they show up in recruitment, onboarding, recognition and performance conversations?
Culture becomes real when it is designed into the operating system of the project.
Not when it is documented beside it.
Make It Governed
One of the biggest failures of most charters is that they sit outside governance.
They have no owner.
No review cycle.
No reporting mechanism.
No agenda time.
The Steering Committee reviews delivery performance.
The Project Leadership Team reviews risk.
The commercial team reviews cost.
Nobody reviews the charter.
So perhaps the challenge is not writing a better charter.
Perhaps it is embedding the agreed principles directly into Terms of Reference, leadership accountabilities and governance processes.
What gets governed gets discussed.
What gets discussed gets managed.
Keep It Alive
Another uncomfortable truth is that most charters are written for the mobilisation phase but expected to remain relevant years later.
Projects evolve.
Teams change.
Relationships mature.
Priorities shift.
The charter rarely does – and this isn’t helped when our legal-folk embed charters into contracts – because this makes them harder to adapt.
It’s rarely argued that they should remain living documents. Most tend to consider their reviews annually or as project phases move on, refreshed at major project transitions.
This enables leaders to adjust expectations and signals as the needs of the project change.
Charters should not be protected from evolution, but strengthened by it.
Design Culture Intentionally
There is another question projects seldom ask.
Who is supposed to create the culture?
The answer changes the design approach completely.
Some projects genuinely want culture to emerge from the workforce and broader project community.
Others want culture to be deliberately defined by leadership and cascaded through the organisation.
Neither approach is inherently right or wrong.
But they are fundamentally different strategies.
As Roger Martin and organisational thinkers such as David Friedman have argued, culture does not emerge accidentally. It is designed through the systems, behaviours and expectations leaders choose to reinforce.
If the culture strategy is top-down, the charter should reflect that.
If the culture strategy is bottom-up, the development process should reflect that.
Too often projects attempt to do both and achieve neither.
Rethinking the Vision Statement
Perhaps the biggest opportunity lies in separating the mandate from the vision.
The project mandate already exists – that’s what got the business case approved. It is defined by the client.
Deliver the asset.
Meet the budget.
Achieve the program.
Manage the risk.
The vision should be different - it should describe the possibility the team sees within that mandate.
What could this project become?
How might it leave people, organisations or communities better than it found them?
What would make participants proud to have been involved?
The mandate explains what must be achieved.
The vision explains what could be achieved.
Those are not the same thing.
Before You Ask for a Charter
The next time a project asks for a charter, pause.
Before commissioning a workshop.
Before debating behaviours.
Before writing another vision statement.
Ask a different question:
What are we actually trying to create?
Alignment?
Trust?
Decision-making clarity?
Cultural consistency?
Shared ambition?
Governance discipline?
Because once you know the answer, you may discover you don't need a charter at all.
You need something much more specific, or a charter more tailored, more clear.
And much more useful.
So what?
The charter becomes the symptom, not the solution.
The real work is identifying the organisational mechanism the project actually needs and designing that deliberately.