Topic 3.10: The project charter
The project charter establishes a partnership between the project manager and sponsor, and documents initial requirements.
Chartering a project also links stakeholder expectations of the project to the strategy and ongoing work of the organisation.
As the final output of the project initiation process, the project charter documents:
The project's scope
The project's schedule
The expected budget
Within a ±20% (or organisationally acceptable) confidence interval
Project acceptance criteria
In other words, what constitutes project completion, who decides the project is complete, and who signs off on the project
Critical success factors
These might include any key assumptions, dependencies or risks that it is important for the project manager to know
The name and authority of the sponsor or other person(s) authorising the project
The charter is then assigned to a project manager, at which point their level of responsibility or authority is clearly defined.
This is also when the project governance group is convened and given terms of reference.
Depending on the size of a project and the relative risk it presents to the organisation, a project charter can be either a big, formal document, or something as simple as an email saying get on with it.
The written business case is an example of a project charter, and we will look at it specifically in the next lesson.
Although the charter is often compared to a contract, as in many respects it has a similar intention, the charter should not be confused with an actual contract.
For even if a contract to deliver a project output does exist between a third party and the performing organisation, a charter is still required to internally direct resources (including a project manager) to the project.
After all, a contract will not provide the level of detail necessary to actually deliver the work.
Although a limited allocation of resources may be made in the charter for planning to be completed, approval of the project plan is the real green light to start spending time and money delivering project outputs.
If the purpose of a business case is to persuade an organisation to invest in your project, then the purpose of the project charter is to authorise you to start spending their money.
Therefore, a defining attribute of the project charter is that it is a written agreement.
Although the opportunity may be pitched and even sold in an elevator, boardroom or to a tv studio audience; for the business case to be effective as a charter it should document the following:
You should be aware that in many instances the requesting organisation or client may independently initiate the project – as the project manager you might only inherit and have no prior say on the project effectively chartered for you.
This is especially frustrating when you are handed poorly developed treatments or ones with unrealistic expectations.
If that is the case, you should raise your concerns with the project sponsor as soon as it is practical to do so, and by no later than the end of the project planning process.
Be prepared though to fully evidence your arguments, even if this means deconstructing the existing project logic line-by-line.
After all, by this point the key stakeholders, including the sponsor, have probably invested a lot of effort and ego into the project.
On small or obvious projects, following the full initiation process is a redundant use of resources.
Other projects simply must be done – for example, if a client orders a specific output from you under contract, the business case for it can be assumed (or at least validated as part of the contracting process).
And in some cases, the risk of not proceeding is obviously greater than the impact of doing nothing, such as when a change in legislation necessitates updating a process.
In fact, a project manager may go their entire career and never prepare a business case or even be involved in project initiation.
Many organisations feel they successfully deliver projects without formally going through these steps, going straight to project planning or even delivery.
We often hear executives say, look – there really is only one option, we don’t need to do anything else… let’s just get on with the project.
And they’re probably right – about five percent of the time.
For even if you have only one standout option, you can almost guarantee there are options within it that are worthy of more detailed consideration.
For example, what if we fast-track delivery by 20%? What do we lose? What do we gain? What if we add a few more features?
Or, more critically, have we under-represented or even missed the input of a certain key stakeholder? Have we assumed they will think one way, without asking?
So what are the benefits of properly initiating a project?
The process of project initiation gives the project context.
Done well, it significantly reduces ambiguity for both the project manager and stakeholders, which – as we know – reduces the need for and cost of change in project delivery.
To the project manager’s benefit, the process further details and documents:
- What options have been considered – what is in and (by implication) out of scope?
- What assumptions were made (for example, about time and cost)?
- How important and/or risky is this project to the organisation?
As you will see, making the organisation’s decision-logic transparent in this way makes change management so much easier once project planning and delivery commence.
The concept canvas and business case are the assets that provide context to the project team.
Another important legacy of the initiation process is the stakeholder register.
The project manager who inherits this asset enjoys a significant head start in one of their key functional roles; that is, liaising with stakeholders and managing their expectations.
The stakeholder register also insures the project against imperfect stakeholder memories of whether or not they were given adequate opportunity or scope to engage with the original idea.
When things go right or wrong, the outputs of the initiation process – the concept canvas, stakeholder register and business case / project charter – are critically important inputs into project closure and review.
They provide another window not just into the project itself, but the justification for and decision-making process that led to the project being initiated in the first place.
After all, a perfectly executed project is pointless if it was never the right project in the first place.
Following the initiation process should always be the default; the burden of proof should be on skipping this step.
It is far better to explore all options and make relevant discoveries now than when it is too expensive or just too late further down the track.