Project Charter: one concept, many ways to apply it

This article is about a Project Charter – a fundamental tool in many process improvement activities. However, not about the template nor the content of the Project Charter, but more about the process of creating one. Crafting, discussing, approving, and communicating in different, practical business cases that I’ve experienced in the process excellence area.


Before we begin, I would like to share a brief disclaimer: the content below (as well as in all my other articles) is not generated by any AI tool. I did use AI-supported tools, but only to check and correct the grammar of the source text, which was written purely based on my knowledge and experience. 

I have never thought I would ever declare anything like that. Still, I have decided to do so after seeing interesting comment from someone on LinkedIn: it is more and more frequent to fall into the trap of seems-to-be-interesting text/post/article that, after spending some time on reading it, appears to be just a ‘pulp’ that looks interesting thanks to excellent and convincing language (core capability of Large Language Models), but is not delivering anything meaningful or valuable to the reader. After experiencing this recently, on my own, let me promise: if you found this article not interesting, you should be able to detect it straight from the start and avoid losing your time on something not wanted 😉


But let’s get back to the point. I like to think of the Project Charter as a contract between someone requesting a project to solve a business challenge (usually referred to as the Project Champion, Sponsor, Requestor, or Owner) and someone delivering it (usually referred to as the Project Manager or Leader). A contract that needs to be drafted, discussed, and agreed upon before moving forward.

Let’s review how this process may look in different business cases with increasing complexity:


Case #1

A clear and specific business problem to be solved by a simple project with an impact on just one area that is managed by the Project Requestor. A small team is needed, with all resources directly under the control of the Project Requestor.

In such a clear and straightforward case, it is usually sufficient to have a brief and informal conversation between the Project Requestor and the Project Leader, typically as part of other existing, periodic meetings they already have.

In many cases, there is also no need to use any specific template as a Project Charter; a simple email summarizing the discussion and indicating the goal, scope, and timeline of the agreed project would be enough.

That’s it.


Case #2

Still a simple project, but it may potentially impact other areas; Resources needed for the project (e.g., team members) need to be consulted with others.

In this case, again, a simple chat with the Project Requestor would be enough. However, this time it would be worth documenting the outcome formally on some form, that is, preferably, a commonly known one in the organization.

This formal project charter should then be used to consult the allocation of the resources for the project or to inform other stakeholders about the project that may potentially impact their areas.

When significant concerns are raised by any stakeholders, the initial Project Charter should then be re-discussed, revised as needed, and approved again with the original Project Requestor and all relevant stakeholders. Otherwise, the initial Project Charter stays valid and can be used to steer the project right from the start.


Case #3

Clear business problem to be solved by a specific project within the area managed by the Project Requestor, but with expected impact on other areas as well. Resources for the project need to be agreed upon with others.

Here, a draft Project Charter in some formal form should be created from the start, during the initial discussion with the Project Requestor, as it is known that it must then be agreed upon with relevant stakeholders.

This agreement would usually be easier to get in three steps:

  • Initial discussions between the Project Leader and all relevant stakeholders individually, to understand their point of view on the draft Project Charter, availability of the resources, conflicting schedules, etc.
  • Adjustments to the draft Project Charter to be made by the Project Leader and the Project Requestor
  • Final discussion and agreement with all relevant stakeholders

Case #4

Business problem to be solved sits between two or more areas, managed by different stakeholders. Resources needed are not known yet.

At this level, we no longer have a single Project Requestor who can create (or draft) a Project Charter with the Project Leader. Moreover, the business problem to solve is usually more complex here, harder to frame into a clear improvement project. As a result, more efforts and skills are required from the Project Leader.

Here are the steps I am recommending taking in such cases:

  • Initial, individual discussions with relevant stakeholders. Both with decision makers (potential future Project Requestors) and with process experts (those dealing with the problematic process first hand). Not to find the solution, but to better understand the nature of the problem
  • Quick review of the available data connected with the business problem. How big it is, when it started, which areas are impacted, etc.
  • Draft of the Project Charter by the Project Leader, with supporting information gathered so far, and indicating also resources (team members) that will be required for the project.
  • Formal discussion and approval of the project with relevant decision makers (Project Requestors, forming now Project Steering Committee)
  • Confirmation of the resources, including nominating specific names (if not identified before), supported by the Project Steering Committee.

It is essential to keep all steps brief and concise. It is easy to get into the trap of analysing all the details and trying to solve the problem right from the start, just after one more week. And one more, and just another one…

However, the goal here is to start a clear project as soon as possible, not to solve the problem. I recommend limiting the time for this phase to one to two weeks, at most three weeks. Then, call for a formal discussion and approval of the project, using whatever information is available at this moment.


Case #5

A complex business problem involving different teams, areas, and stakeholders, with very different opinions about the nature, source, and goal of the potential improvement project.

This case differs from the previous one primarily in the way various stakeholders perceive the problem. In Case #4, stakeholders generally agree on the nature of the problem, but it was just hard to frame it into a clear project. Here, some stakeholders believe that the root cause lies in area X (and that the project should be led and scoped there), while others point to area Y.

The main challenge for the Project Leader is to achieve an optimal consensus with all stakeholders regarding the project’s shape, which is necessary to solve the problem.

Here are some steps that can lead you there:

  • Do individual research on the problem by looking at previous project results, available reports, shared emails, presentations, etc. The goal here is to “learn the language” of the problem, familiarize yourself with key terms, and understand some relevant facts. Just to be able to talk about it and learn more.
  • Identify stakeholders of the problem: those who are experiencing it and have some decision power. This can be achieved, for example, through conversations or interviews with relevant individuals.
  • Organize a workshop with stakeholders, where their different opinions about the nature of the problem would be surfaced, discussed, and concluded. Different versions of affinity diagrams are helpful here, especially those that can indicate cause-and-effect relations between top-level groups
  • Conclude the workshop with a consensus about one or more projects that need to be launched to tackle the business problem, indicating also the optimum sequence of launching those projects. If possible, create initial project charters for them.
  • Proceed with tuning and accepting the charter for the most critical project, as described in Case #3 or #4 (depending on the complexity)

Case #6

Complex business situation that is perceived as a problem by some stakeholders, but not by others. It is hard to identify or collect some objective data to quantify and narrow down the problem into a clear and acceptable topic for all.

When there is no consensus among decision-makers to start a project to improve the business situation (as in this case), the way forward may be to start a project to … achieve this consensus. Especially if the work to collect relevant data and conduct a study of the problem is complex and time-consuming.

Here is how it may look in practice:

  • Agree with stakeholders seeing the problem to start a study project – to perform analysis of the situation, not to improve it
  • The goal of such a project would be to collect data, analyse the situation, and prepare recommendations on how to tackle it, for example, in the form of charter(s) of the actual improvement project(s) to be launched
  • Resources needed for such a project are process experts, preferably from different areas, and with some ‘influencing power’ that may be important at the end of the project when actual improvement projects would need to be launched
  • Even if this is a „study project”, all project management principles should be firmly in place (scope, goal, timeline, resources, etc.)

In many cases, when a ‘study project’ is concluded with a decision to start an actual improvement project, this new project is assigned to the same Project Leader and, most often, the same project team. This helps to speed up the improvement and ensures continuity of the work. 

It is, however, important to formally change the scope, goal, and timeline of the project to reflect its new nature.


Summary

Of course, this is not a complete list of cases. There are many more, and with plenty of ‘hybrids’ falling between those listed. After all, every project is different and requires a unique approach to start it well and manage efficiently and effectively.

However, all of them would benefit from a clearly stated and agreed-upon project charter – even if the steps to achieve one may be very different.

Happy Project Chartering!


PS. If you have already started a project as a Project Leader and are looking for some advice on how to organize the work with your Project Team, you may find this article helpful: Project Leader and the Team

Leave a comment