Project Governance

Project governance is the framework which ensures that the project has been correctly conceived and is being executed in accordance with best project management practice and within the wider framework of the internal strategies and processes for each organisation.

Project Governance provides a centralised strategy for project control and reporting, including a set of rules of engagement and guidelines with project teams including external parties.


Project Governance ensures that the business strategy, ethics and accountability align with the organisations strategy, policies, procedures and vision.

Defining the Project Governance at the start of the project is important, as it ensures processes are understood and can be followed by the project team.  Escalation of issues and decisions can be escalated through a pre-defined route to ensure a swift resolution.  If there is a conflict within the project teams, a strategy for the resolution can be found through the Project Governance processes.

It is important that the Project Governance is defined and officially documented in the Initiation Phase of the project, as defined in the PMBoK Guide.  The governance will be detailed in the Project Charter document and will need authorisation from the Project Sponsor.

I use a template for the Project Governance, which include the following topics;

1. Principles - This section details the high level concepts, such as communications, business requirements, security and key personnel;
2. Communications - This is a view of how communication will flow, the meetings that will take place and how escalations are facilitated;
3. Project Team Structure - I would usually draw a diagram to show the various teams and levels of escalation within the Project Community.  Where possible, names will be defined, 3rd parties will be identified and project Teams will be detailed;
4. RACI - A project has a separate RACI, however, I like to include a RACI within the governance pack, to indicate the responsibilities and accountability's of individuals and teams.
5. Work Streams - If the project is to be split into many work stream, I would define each stream and include the individual Work Stream Leader, the Inputs, processes and outputs.  I  would indicate the dependencies of the stream and show the projected time line for the work stream to complete;
6. Project Change Control - This section describes how the project scope will be controlled.  It is not intended to document the systems level, or business change control of the organisation, but a Scope change control strategy for the project, showing escalation routes and processes.

This framework has been the foundation for various projects that I have worked on, from small projects to very large multi-million pound projects.