Why You Should Include People Aspects of Project Management in the Project Charter

The Project Charter Sets the Project FrameworkAlmost any new project begins with the Project Charter as its first formal deliverable. The Charter focuses on end results, project boundaries, roles and responsibilities, and processes for execution. Sometimes it includes a technology component. But what if it also described a formalized set of tenets regarding the people aspects of project management? How might the success of delivery be improved?

The Project Charter Establishes the Framework for the Entire Project

The Project Charter is the document which formally initiates a project. It is the client organization’s commitment to spend resources to arrive at a result that benefits the organization. Whether the IT solution provider is an external vendor or an internal department within the organization, the Project Charter establishes a partnership between the organization and its IT counterpart, and authorizes the Project Manager to execute the project.

In developing the Project Charter, several standard sections within the document set the overall framework for the project, including:

  • project purpose;
  • project objectives and success criteria;
  • high-level requirements (based on an approved business case);
  • high-level project description, boundaries, key deliverables;
  • overall risk;
  • summary milestone schedule;
  • key stakeholders;
  • formal project approval processes;
  • exit criteria;
  • assigned project manager, responsibility, authority level; and
  • sponsor(s) and authority of sponsor(s).

Virtually every project begins with this framework in place. Yet so many projects have execution challenges as they progress. In thinking about why, it occurred to me that few (if any) under perform or fail outright because of poor process implementation or complex technological challenges. They typically fail to meet the objectives of the project, as outlined in the Project Charter, because of people issues.

Which begs the question: what in the contents of the Project Charter is specifically designed to deal with the people aspects of delivering the project?

The project objectives? Perhaps, but those typically describe the desired end result, not the execution.

The high-level requirements? No, those define the overall functional needs that the system will be designed to meet upon implementation. They do not consider peoples’ conduct on the project.

The Project Managers’ responsibilities? Closer, but this section typically defines the process responsibilities of the PMs in executing the project tasks to arrive at a successful conclusion.

If, as I table-poundedly (my word, and I’m sticking with it) claim, the people aspects of project delivery demand as much focus as the process and technology aspects, where then does the Project Charter address them? (More importantly, where are the people aspects of project management covered in detail anywhere in the entire “proven” practices of managing projects? But that is a subject for another time and another soapbox.)

I understand that formalizing the human factors – the people aspects – of project management into a definitive set of project practices is as challenging as legislating morality in our civil code. But to not even attempt it will only continue to perpetuate our industry’s mediocre project delivery track record. So, where do we start?

The Project Charter Should Include People First Elements

What if we started by enhancing the Project Charter with content that could help govern the people-centric behavior of both the IT and client Project Managers? What if we could formalize putting people first from the very beginning of the project? Adding something akin to the following components into the Project Charter might be a good start:

  • Conflict resolution – a formalized process of arbitration to resolve areas of conflict between the two organizations’ Project Managers or other project executives. The emphasis would be on resolving conflict as soon as it comes up, and before it festers into full-scale project issues. So often projects handle conflict issues by logging a risk, putting a timeline on the logged risk, and reporting on the progress of resolving the risk – in other words, resorting to process rather than just dealing with the issue head-on as soon as it occurs.
  • Communication – this section of the Project Charter grants permission for either party to raise issues at the management level that are of a sensitive nature. Refer to my earlier article, How to Get a Project Started on the Right Foot – Tip 2. In the scenario that I described, had the IT Project Manager escalated the client Project Manager’s words to his management, the project issues that ensued could have been prevented. Note, this formalized communication process would be in addition to the formalized communication plan that every project must have,
  • Decision making – so often decision making is inferred from the project org chart. While the org chart visually depicts lines of authority, it is not always clear how decision making will take place along those lines of authority. Projects have a natural inherent tension which complicates the decision-making process. For example, IT’s need to complete the project on time and within budget often conflicts with the end-users’ need to include all of their functional requirements in the new system, even though the timeline and/or budget may be jeopardized.

    So, when is it appropriate to make decisions by decree rather than consensus? Who has decision making authority over the timeline issues? budget issues? change order submission? Who can challenge a decision? Can the client PM override the IT PM, and vice versa? Often project management staff on both sides feel that decision making is covered in the contract, or in the responsibilities matrix, or in the deliverable approval process, or in the phase exit criteria. But in my experience, decision making responsibilities are often unclear. This then results in prolonged discussions, lost time, and acrimony.

These are preliminary thoughts, but it is my belief that formalizing a tangible focus on the people aspects of project management, beginning with the development of the Project Charter, will put projects on the right footing for success.

2. Initiating Process – Project Integration Management


Merv Jersak
If you want your IT projects to come in on time and within budget; if you want your clients to be your best ambassadors and your project teams to be committed to your success; if you want to stop leaving money on the table – then Merv Jersak is the mentor and coach who will work with you to help attain the results to which you aspire. With more than 40 years’ experience as an IT Project Management and systems consultant, Merv works with IT solution providers and end-user organizations, focusing on the people aspects of project delivery to drive more profit to the bottom line and to have fewer budget overruns.

To learn more about Merv’s service offerings, or to hire him to speak to your organization, visit www.PeopleFirstProjectManagement.com.

EMAIL merv@PeopleFirstProjectManagement.com // LINKEDIN www.linkedin.com/in/mervjersak

52 Project Management Success Tips from Merv Jersak  •  Copyright ©2020. All rights reserved.