Project Management

Rethinking the Charter

From the PMI Global Insights Blog
by , , , , , , , , , , , , , , , , , , , ,
The Project Management Institute's annual events attract some of the most renowned and esteemed experts in the industry. In this blog, Global Conference, EMEA Congress and experienced event presenters past, present and future from the entire PMI event family share their knowledge on a wide range of issues important to project managers.

About this Blog


View Posts By:

Cameron McGaughy
Dan Furlong
Emily Luijbregts
Moritz Sprenger
Karthik Ramamurthy
Priya Patra
Stephanie Jaeger
Drew Craig
David Davis
Heather McLarnon
Kiron Bondale
Kimberly Whitby
Lorelie Kaid
Laura Schofield
Julie Ho
Brantlee Underhill
David Maynard
Fabio Rigamonti
Marjorie Anderson
Michelle Brown

Past Contributors:

Johanna Rusly
Deepa Bhide
Chris DiBella
Nic Jain
Karen Chovan
Jack Duggal
Catalin Dogaru
Carmine Paragano
Te Wu
Katie Mcconochie
Fabiola Maisonnier
Erik Agudelo
Jamie Champagne
Esra Tepeli
Mel Ross
Geetha Gopal
Archana Shetty
Randall Englund
Kristy Tan Neckowicz
Nancie Celini
Sandra MacGillivray
Sharmila Das
Gina Abudi
Greg Githens
Sarah Mersereau
Lawrence Cooper
Donna Gregorio
Bruce Gay
Michel Thiry
Heather van Wyk
Barbara Trautlein
Steve Salisbury
Yves Cavarec
Diana Robertson
Benjamin C. Anyacho
Nadia Vincent
Carlos Javier Pampliega García
Norma Lynch
Michelle Stronach
Sydni Neptune
Nesrin Aykac
Laura Samsó
Marcos Arias
Yoram Solomon
Cheryl Lee
Kelly George
Kristin Jones
Jeannette Cabanis-Brewin
Annmarie Curley

Recent Posts

Presentation Recap: Building Better Connections and Boosting Team Collaboration with Storytelling

Presentation Recap: The Resilience Mindset: Tools for Navigating Uncertainty in a Post-Pandemic World

Presentation Recap: Leadership Advice to My (Even) Younger Self: Panel Discussion

Presentation Recap: Winning Customer Confidence by Designing a “Transparent-and-Tangible” Commercial Transformation Roadmap

Presentation Recap: Collaborative Leadership in the Age of Artificial Intelligence

Since I retired after 26 years in one company, I have had assignments in various PMOs in different industries.  I’ve been in the energy sector, the insurance sector, credit card services, industrial/manufacturing, and now healthcare.  Every industry has struggled with the project charter.  What does baselining it mean? Does it ever get updated? Who should issue it? And the list goes on.  And while PMOs in all these industries try to invent the perfect process – we are ignoring one important aspect.

The project charter, as defined by PMI, does not meet the needs of today’s business!

Before you call me a heretic and an incompetent – hear me out.  The problem I have with the charter is it becomes a reformatting of existing information, bloated, and redundant – and it doesn’t provide the project team with the most important information it needs.  Shouldn’t the charter give the team a definition of what success looks like?

I propose the charter should be extremely streamlined.  After all, how many people, let along executives, will read a 14 page charter?  Many charter templates contain information that is already in one artifact and will no doubt be included in another.  I propose we throw away the bloated all-inclusive charter of today and replace it with a simple charter.

Project Organizational Wrapper

You need to have the organizational wrapper of project control structures.  If the project pipeline has a defined Demand Process and there is a demand id, it should be in the charter.   This should also be aligned to the business case information – what went into the approval, and other justifications.  No need to repeat them in the charter – they already exist in a corporate database of record.  If information is in two places – that doubles the risk of inconsistency, confusion, and delay.

If you have an integrated project management system (IPMS) that tracks project work in process – then that project id should be there. Projects assume titles and identify from the ideation phase through project initiation.  That title, or name, should be included in the charter because that’s the lingo that has defined the initiative.

Should be results focused

Once the project is ready to kick off, the work initiative needs to be focused on the results.  If your organization is mature enough to be doing Benefits Management Realization, the charter should map directly to the benefit register.  The next section of the charter should be:

What does success look like?

Quite simply – what is the vision in reality?  Knowing what success is far outweighs the value of several scope bullet points.  The definition of success can be expressed in several ways including:

Critical success factors

The essential areas of activity that must be performed well if you are to achieve the mission, objectives or goals for your business or project.

What can we do in the future that we can’t do now?

How do we measure success?

Not calling for specific key performance indicators here, but should have an idea of how we will measure success.  It also provides requirements for the product and what are the critical success factors.

External/legal requirements

If you are driven by a legal requirement or an industry standard (HIPPA or an ISO requirement comes to mind) than that should be identified.  The charter must identify conformation to external factors.

What benefits are being realized?

Again, if you have a mature benefits realization process, then the entire benefits quantification/qualification should be in place and your project is delivering outcomes and capabilities to realize the defined benefits.

Organizational RACI

The charter must be able to identify all the organizations that are impacted by the initiative.  After all, how did you get high level estimates for the business case if you didn’t have a means of identifying organizations involved?  This RACI should then be driven to know which groups need to receive and approve the charter. 

Time Frame

What time frame is expected for the organization to start to realize benefits?  Let’s avoid the charade of bottom up estimates and defining the schedule after you have all requirements defined etc.  We are driven by budget cycles and funding is only approved to last so long.  This isn’t to say those things can’t and shouldn’t happen, but at a Charter level – the approval has a defined end time.  This also helps define the scope.

I have purposely omitted several pieces of what is considered part of a charter.  Not that I don’t think they are important, I do, but they belong in defined sections of the project plan.  There is no need for budget as that should already be in the business case approval – and I don’t know if it directly contributes to the definition of the outcomes and capabilities.    Scope is implied in what success looks like and the Critical Success Factors.  If during requirements definition, a question is raised that doesn’t directly support the definition of success, than it is out of scope.  Assumptions, risks, issues, and constraints are all important, but they live elsewhere.  The charter should identify the future state, not dwell on the challenges of the present state.  And the charter should be a onetime document that is not modified or have addendums.  It initiates the work – other artifacts ebb and flow during the project life cycle.

In closing – the purpose of the charter is to authorize the project manager to start delivering on the project.  It is not to cut and paste from all over to make an all-inclusive summary of all business intelligence that justified the project.  I propose to make it a lean document focused on the outcomes and capabilities and the definition of success.  Items that have a workflow/life cycle (risks, assumptions, issues, etc.) do not need to be in a charter, they are taken care of elsewhere.  A lean, concise, and easy to read charter allows the team to focus on delivering within the success criteria.



Please sign up for a 1:1 with me while at the PMI Global Conference! We can talk about PMOs, healthcare project management, teaching project management, or any other topic related to project management!

To schedule a 1:1, use the SIGN UP button on this page.

Posted by David Davis on: October 21, 2017 06:03 PM | Permalink

Comments (7)

Please login or join to subscribe to this item
Thanks for the article.

Completely agree regarding the level of detail. Should be fit for purpose ensuring engagement from senior management, buy-in for the project and high-level summary to enable the PM to kick everything off with the correct backing. Also agree that it should not be something that requires updating unless the purpose of the project significantly changes.

Not sure I fully agree with your statement:
'The project charter, as defined by PMI, does not meet the needs of today’s business!'
Although PMI lists out a number of areas that the charter should satisfy, I have never really taken this as a definitive list that necessarily need to be specifically covered in the document, but maybe this is more due to my cowboy interpretation...
I take this as areas to have been thought through and then an appropriate level of detail included in the charter to ensure key areas for the particular business are called out. Generally be as a minimum: purpose, high-level scope, constraints, assigned PM and sponsor their responsibilities.

Thanks for the feedback. I don't disagree with what you say - my comment regarding doesn't meet the need was more directed toward the project being a collection of what is as opposed to identifying what needs to be. All those things do need to happen, I just don't think they need to be in the charter.

Againt, thanks for the perspective and I welcome "push back"

Hey Dave,

It is not often that you and I disagree, but this is one area where we do!

I believe a charter is the exact place for assumptions, constraints, scope, budget, and other project wrapper elements.

First of all, they belong there but at a very high level. Secondly, they belong there because the charter is the official blessing of the project, and if the blessing is made based on certain assumptions, constraints, budget dollars, or whatever, then it needs to be noted. The business case may indeed include these elements as well, but, the business case is not a formal approval to begin the project, and in many cases what the business case requested was not what was approved in the end.

Our charters are typically 2 pages long, although we had one crazy big project that had a 57 page charter that was truly our source of truth for any questions about the project. That was a very rare, $100M project that included 300 full time staff for two years.

We also know that the PM will take those high level constraints, assumptions, budgets, timelines, etc. and dissect them into more accurate components, and those are typically included either in the project management plan or its supporting project documents. This is the ONLY reason why I would suggest the charter is a bad place for them, even at a high level, is because they will change and the idea of the charter is that it does not change.

So we do agree - at least in part.

We agree for the most part. My point is it should be focused on definition of success. I can live with the 2 page charter - we're not there. Our charters are getting bloated and almost taking the role of project plan.

Remember, my title is to rethink the charter :)

I like it. As collectors of project information, it's up to us to find the right way to package the information for greatest effect. I personally like keeping scope information in the charter because I teach my teams to refer to the charter often if there's any debate about scope or the direction we are going.

Greetings David, it's been a long time since we've last chatted and I think this is a topic that is going full circle. When I started with 'formal' PM the charter was designed to be short, looking to provide just enough information to allow for an informed decision as to whether a project should move forward or not. Over time the charter became more complex and bloated providing more information, perhaps due to a well intentioned effort to avoid a problem in a previous project. I have even heard a seasoned PM state that they didn't need to plan for their project as everything they needed was in the charter!

Based upon your environment/need you may need to provide high level costs and estimates, (knowing the risk that with the limited information you have during initiation people will want to hold you to your estimates) but the purpose of the charter should be to provide just enough information to make an informed decision whether to move on into Planning, or to place a hold on the effort.

I would still want to keep my charter up to date and in alignment with the overall project, as long as I provide the history of revisions for my lessons learned, however if the charter is at a high enough level the need for revisions will be limited to more drastic changes within the project. Just my two cents worth.

Great article and much appreciated.

Interesting, thanks for sharing

Please Login/Register to leave a comment.


"I would never die for my beliefs, cause I might be wrong."

- Bertrand Russell