Assembling the Project Team: Developing the Project Team Charter

Working with a client recently, I was reminded of the value of a project team charter.  Having been invited to review the progress of the project and to make recommendations for improvement, it became increasingly clear as I talked with the project team and various stakeholders that not everyone understood the project, its objectives and its value both to their own organization and to the client.  In fact, there was little understanding of who was actually involved and why.

Yes, the Project Initiation Document and other associated documentation had been written, but where was the understanding about how the team would work together to run and deliver the project?  How did everyone understand who was doing what, where roles overlapped and who was responsible for what?  After all, you’re bringing together a set of individuals who probably have never met or worked together, each with a particular set of skills.  The best teams are the ones where the individual members understand that their particular skills sets compliment, rather than compete, with each other.  And if all that understanding is missing, where is the engagement to help them in working together as a high-performing team?

Without getting into discussions about project sponsors or Senior Responsible Owners, as the designated project manager or project lead you are responsible for the way in which the project will be run and delivered.  These responsibilities include helping team members to provide the best performance they can by providing the culture and environment in which they can provide the best performance they can, and helping the team to gel together early so moving through the Tuckman phases of forming, storming, norming, performing as well as adjourning.  And that includes the basic courtesy of ensuring that the team members know who each other are, why they have been included in the team and what they are expected to deliver.

If you use a particular project approach or methodology it might specify how you should assemble, co-ordinate, support and review the project team; regardless, there are some basic principles which can be applied and which are common and straightforward ways of ensuring your team members understand the project, how it will run and why it is important.  Further, that they have some basic behavioural ground rules about how they will work with each other and with you.  The project team charter is one of these ways. 

What is it? The project team charter is one of the project documents which provides clarity and focus.  It ensures that the members of the project team understand what they are supposed to be doing, what the purpose of the project is and how they are going to work together to deliver it regardless of where they are located, which time zone they are located in or which organization they belong to (client, commissioning organization, key supplier, etc.).   This is just as true for the start-up phase as an early part of the project, as it is for other phases of the lifecycle as project team members move in and out of the team as needed.  As such, it needs to be developed and agreed with those project individuals it touches. 

What it is not! It isn’t a list of all possible project stakeholders throughout the lifecycle of the project.  By all means do the usual stakeholder identification and mapping but also ensure there is clarity around what is meant by “the team” regardless of location, function, hierarchy or organization. 

Content. Typical content includes:

• Introduction: why the team has been put together, what their role is in the project, the purpose of the project and any highlights (objectives, timelines, success criteria, anticipated benefits, project vision, etc.).

• Who is it? who does the project team include?  You might choose to include only those within your organization, or to include key members from the client and supplier organizations.  Your team members may be located on-site and easily accessible, or working remotely a continent away.  You may choose to differentiate between a “core project team” and a “secondary project team” at particular phases of the lifecycle, especially if this is a project likely to see a regular change of team members or a long-haul project likely to extend over a number of years. 

• Roles and responsibilities: specifying who is responsible for what and will do what for the project.  Each player does their part and has a particular role to play.  This is not just putting a job role together for the big, obvious, sexy stuff (such as Solutions Architect, Lead Engineer, Technical Project Lead, Quality Lead, Test Bed Manager, Head of PMO, Project Finance Manager, Client Business Readiness Lead, etc).  These roles and responsibilities need to include the little “hidden” stuff which still needs to happen (documentation creation, client liaison, meeting logistics and minute-taking, organizational networking, acting as ambassadors for the project, providing informal communication and marketing for the project, etc). 

We all know that project personnel often have their own day job to do as well as their project role, or even are running with more than one project at a time.  So not all project team members will be full-time with the project; do make clear which roles are full-time, which are part-time and when each team member is available to the project during the working day/week/month.  I also recommend specifying who has what levels of delegated power or authority: this helps to minimize turnaround times for decision-making, financial and other sign-offs without having to refer back to functional or departmental heads for agreement. 

• How the team will work together: this is one of the most important parts of the project team charter.  It sets out agreed behaviours and values to help the project team define how they will work together and foster the strong working relationships that are needed.  In my experience this can help the team accelerate through the forming, storming and norming stages to become high performing.  We don’t typically like having those “crucial conversations” or challenging inappropriate behaviour, but agreeing up front appropriate ways of working helps to facilitate those discussions at a time when they are needed most. 

It also documents contact details, out of hours access, how the team can get together across different geographies, time zones and (if appropriate) organizations.  How will you keep distant team members close, providing regular opportunities for the team to plan together, to review progress and to discuss anticipated problems when they are not located at the same site? 

What will you do with it? So having developed, agreed and documented the project team charter, what next?  Too much project documentation is produced as a tick-box exercise and, once completed, is filed and forgotten.  The project team charter is one of the key pieces of documentation providing the context for how the project will be run, so make it work for you and the team by referencing it within other project documentation and storing it centrally with all project documentation so that it is easily accessed.  Update it as necessary as the project moves into a different phase or when there is a change of project team members. 

If you’d like to understand more about the project team charter, building high-performing project teams or using projects to plan and deliver business critical initiatives, use the contact form at Contact Us.  We look forward to hearing from you!