The Project Charter: Stakeholders, Risks, Delivery Outcomes, KPIs

In our previous articles, we've explored key sections of the project charter such as goals, constraints, and resources. This article focuses on other crucial components that are often included in a project charter.

Stakeholder Section

This section typically identifies two primary stakeholders: the sponsor and the manager. It's essential to clearly understand who initiates the project and who implements it, noting that their roles are complementary rather than contradictory. What happens if there's a change in management or sponsorship? Such changes are viewed as significant disruptions, necessitating a project restart.

Typically, the manager drafts the charter, while the sponsor, often the director providing resources for the project, signs it. The charter is critically important for the manager, as it outlines their responsibility to ensure the project's success and alignment with strategic goals.

Including the Customer in the Charter

Should the customer be included in the charter? Engaging customers can be beneficial. However, there are clear situations where the charter should not be shared with them. For example, revealing the budget details in the charter can lead to complications, especially as the project budget usually does not match the customer's payment. Similarly, disclosing the team's composition might raise concerns if the customer feels the investment does not align with the team's size.

Risk Section

The charter should specify "terminal non-mitigable risks" — those that could spell the end of the project if they materialize, such as natural disasters or regulatory changes.

This distinction helps sponsors understand situations beyond the project team's control. Conversely, issues like key team members leaving are not considered terminal risks, as managing such scenarios falls within the manager's purview, particularly in strong matrix organizational structures.

Delivery Outcomes

Besides the mandatory sections, the charter can include segments that refine the project's goals and scope. A common addition is the "Delivery Outcomes and Key KPIs" section. 

Let's assume we have a project for creating and implementing an Electronic Document Management System (EDMS) at a company. The content outlines the key tasks we will undertake, and what we will not. Following this, we need to decide how we will verify that the system has been created and implemented. This is where these two points come in.

In the delivery outcomes, it is specified what constitutes the system's creation physically. This is usually a flash drive or another data storage device. But what does it mean for the system to be implemented? It means that it has been installed at workstations, tested, and official documents, such as training logs, have been created. Essentially, these are artifacts for legal or accounting purposes.

Key KPIs

When will we truly consider the system to be created and accepted? For creation, we can develop some test programs. But what does it mean for the system to be implemented? Can installing it on a single workstation be considered as implementation? Does training two people count? 

Usually, digital criteria are used to assess implementation. For example: the system is installed on no fewer than 100 workstations, at least 200 users have been trained, and these users have entered no less than 10,000 documents into the system.

Documenting the Charter

The format of the charter is crucial. Since it is immutable, it is best maintained as an uneditable electronic document or printed on paper. 

Bringing a paper document to a sponsor/director for signature, it is generally the most reliable way to ensure they have actually read it. 

At that moment, if they have any questions, these can be immediately discussed before the project starts.

Putting a seal on it is absolutely unnecessary. The charter is not a legal document. And if you were not given the resources, you wouldn't go to court anyway. It's simply an internal agreement.

Afterwards, the charter can be scanned and uploaded as an electronic document. Importantly: the entire team sees the charter. Because it contains goals, constraints, everyone understands whether the system has been implemented or not, what the KPIs are, what we are doing, and what not.

Conclusion

In summary, the project charter is more than just a document; it is a foundational tool that encapsulates the essence of the project, aligns it with organizational goals, and sets the stage for successful execution. 

It is the first step in turning an idea into reality, providing a structured approach to planning, executing, and closing projects. By clearly defining the project scope, goals, and responsibilities, the charter ensures that all parties are aligned from the start, reducing the likelihood of project failure and increasing the potential for achieving the desired outcomes.