Photo by Finn Mund on Unsplash

I often use the process of chartering projects as an example of the application of pragmatic project management.  Project charters are a commonly used tool for initiating a project that capture critical information needed to gain sponsorship for a project and to begin work.  There is some variation in the information included in project charters based on the needs of their target audiences and standards set within organizations using them.  Determining what to include in your project charters illustrates 2 key principles of pragmatic project management.

The first principle is for every tool and each element of a tool, know its purpose. By knowing each element’s purpose then for the project being considered you:

  • Can determine if the element is relevant and needed.
  • Can understand what is needed to meet its purpose and then can focus on ensuring that its purpose is met.
  • Can choose to use the tool for analogous situations that don’t specifically require it but where it provides significant value.

These in turn allow you to make decisions about how to apply each element of the methodology or plan intelligently to achieve the purpose as efficiently as possible.

In my teams, a project charter is intended to answer these essential questions:

  1. Identify key indicators of the need/problem.  How can the indicators be changed?
  2. What strategies are supported by solving the problem?  What is the impact to those strategies of the problem not being solved?
  3. What other initiatives are competing for resources?  What is the opportunity cost of waiting?
  4. What is needed to achieve a solution?  What needs to change to make it work?  What could impede achieving the solution?
  5. When is a solution needed?  What happens if the solution is delayed?
  6. Who is impacted and in what way?  How are they expected to view the change?
  7. Has the project been approved appropriately?

To answer those questions a typical charter will contain the following elements:

  • Business need/problem description
  • Goals and objectives
    • Strategic alignment
    • Business case – Why?  Why now?
    • Prioritization against other work
  • Solution resource needs, schedule, risks and other impacts
  • Sponsorship & stakeholder alignment

An element of a methodology or a step in a plan is expected to yield a certain value to the project – the team shouldn’t spend any more effort than is necessary to gain that value. Therefore the second principle is scale the effort to the value derived – which is essentially a restatement or an interpretation of the Agile Principle #10: “Simplicity–the art of maximizing the amount of work not done–is essential.”

Applying this second principle to the process of chartering projects allows a project manager needed discretion in defining the level of detail needed.

At the largest level the framework of a project charter often requires creating a substantial document.  Answering each of the questions may need significant discussion of context, to provide evidence supporting the conclusions, consideration of alternative approaches, and to anticipate the needs of future readers in understanding the project and why it was initiated.  Meeting all these needs and anticipating the value it will provide over time drives greater investment in the process of creating the charter and in the deliverable itself.

However, at the smallest level, the framework of a charter might be used simply as a mental checklist for a project manager to ensure the success of a single meeting or workshop.  In that context, some of the answers to the key questions, like the questions of stakeholder alignment, might be inherited from the project for which the meeting is being held.  However, some of the questions may have unique answers apart from the project that the project manager should think through as part of planning the meeting.  Examples include the specific goals and desired outcomes of the meeting or resource constraints due to point-in-time scheduling concerns.  In this context, the project manager can scale the effort invested in ‘chartering’ the meeting and may not need to create a document at all, but rather use the key questions to ensure that communications about the meeting, invited attendees, and the meeting structure maximize the value the meeting provides to the project and stakeholders.

This example illustrates the use of the two principles together.  By knowing the purpose of the elements of a charter, a project manager can reuse the framework at nearly any level of initiating a task or body of work and scale the effort invested to achieve the goal without wasting time or resources.

For more on charters – and on scaling them to different purposes – see the excellent PMI article The charter: selling your project.


Chris Powell

Pragmatic PM is written by Chris Powell, a PMI certified Project Management Professional and Scrum Alliance Certified Scrum Master with over 20 years of project management experience. Currently an Associate Director of PMO at the University of Washington, his career spans a wide variety of industries including financial, manufacturing, aerospace, government, higher education and software products and supporting R & D, sales, marketing, operations, and customer support business functions. He has presented on project management topics at local communities of practice and at national conferences focusing on his pragmatic approach to the project management discipline.

1 Comment

An Agile Approach to System Documentation - The Pragmatic PM · April 9, 2021 at 4:11 pm

[…] While a popular conception is that Agile methodology opposes the creation of documentation, most mature Agilists disagree, including the originator of the Scrum approach.  In Sutherland’s OOPSLA ’95 paper, the first to define Scrum, he describes a robust design and documentation phase called the ‘pre-game’ occurring prior to the beginning of sprints and additional documentation at the conclusion of sprints prior to release.  Scott Ambler, author of Disciplined Agile Delivery makes an exhaustive case for why and when Agile practitioners should create documents.  The following briefly summarizes the case and best practices he recommends and applies them to projects managed by my team (see also my specific discussion of project charters). […]

Comments are closed.