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.
When the concept canvas authorises project planning (in low risk circumstances), it too is an example of a project charter.
The written business case is another 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 low risk projects, following the full initiation process is a redundant use of resources and the concept canvas may be sufficient to initiate the project.
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.
As we saw earlier, you should always run each opportunity canvassed through your risk profile tool. If accepted:
- Low risk opportunities can be chartered on the spot
- Medium risk opportunities should be allocated the resources to prepare a simple business case, and
- High risk opportunities should demand a detailed business case
This point in time is known as decision gate zero.
A decision gate allows the sponsoring organisation to formally decide whether to proceed with, send back a step or terminate a project.
The next go/no-go point in a project’s life is at the end of the initiation process – gate one – when project planning is authorised or refused.
We will introduce the remaining decision gates as we proceed through the project lifecycle and this course.
Unfortunately, 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.