Principles of Effective Project Governance

Regardless of whether you’re running an agile or waterfall project, effective project governance and stakeholder management underpins project success and results in efficient and timely decision making.
Recently I was working on a project where there were times when decision making was stalled, while the Team navigated through a complex governance matrix, designed by the PMO, to get “everyone’s fingerprints all over it”. The result at the project level were delays — the Team were simplly not empowered to move forward until the governance process had completed its cycle, which included:

  • 6-8 weeks to get stakeholder review.
  • Waiting until Senior Executive and Project Board meetings aligned to facilitate the review.
  • Evaluation and approval of products by all corporate stakeholder groups.

Given our Sprints were four weeks long, there was a very real disconnect. We were falling down on the basic principles of effective governance.
I found Ross Garland’s Project Governance: A practical guide to effective project decision making, a useful staring point to develop a project governance framework that would clearly articulate the accountabilities and responsibilities for the project (RACI-VS model) , was focused on  outcomes and allowed stakeholder feedback to be sought when expertise was required.
Four principles of effective project governance:

  •  Ensure a single point of accountability for the success of the project. This ensures clarity of leadership and timeliness of decision making. In Scrum it is the Product Owner who is empowered to make project decisions. This accountability is not shared by a committee, as the product owner is the single point of accountability. Without this clear authority, the validity of decisions could be questioned if this authority has not been established. In my project’s case, this authority was unclear and therefore consensus and approval was sought from a range of stakeholders and many levels of committees. The result was delay s in decision making and a blowout of timeframes to deliver.
  •  Ensure the project governance is service delivery focused. Service delivery ownership determines project ownership and this places the business (and customer) at the heart of project delivery rather than the supplier/vendor. In Scrum it is the Product Owner who owns the business case and budget and therefore retains the key project decision making responsibility. By keeping the focus on service delivery and outcomes this will ensure that the Team is producing products in ranked order that are of most value to the business and/or its customers.
  •  Separate stakeholder management and project decision making. Ensuring separation of stakeholder management and project decision-making activities helps to  prevent decision-making forums from becoming clogged with stakeholders all wanting to “put their fingerprints all over” the project . On my project, the PMO justified the exhaustive stakeholder group reviews as a way of mitigating risk that the stakeholders would not be accepting of the final decision if they had not been consulted.  Whilst many people may be aware of a project and have input into shaping it, this doesn’t mean that everyone needs to participate in each critical project decision. Stakeholders do need to have the opportunity to raise issues and concerns however these can be done separately in a stakeholder forum rather than in the project decision making forum.
  •  Separate project and organisational governance. This is the big one for me. Project governance, the process by which project decisions are made and issues resolved, is very different to how decisions are made and issues resolved from an organisational perspective. Separation of project governance and organisational governance structures will reduce the number of project decision layers, since the project decision path will not follow the organisational line of command and control. On my project, the organisation structure was used as the project governance structure which meant that decisions were reviewed and approved at each level of the organisation. Consensus needed to be reached at each level before any decision could be made at the top for the final approval. Navigating this structure was complex and time consuming. Sprint reviews became the trigger to start the approval process rather than giving the sign-off and acceptance of definition of done that the team required in order to move onto the next Sprint. In addition to slowing down the decision making process, we found that the quality of the decision was also impacted as some of the stakeholders involved didn’t have the prerequisite knowledge and understanding of the project and its issues.

 Project Governance Framework
 The project governance framework below is based on Prince2. Accountability for the project sits with the Product Owner who chairs the Project Board. The decision making path is clear for the Team who are responsible for delivery of the project. The Product Owner ranks products in the backlog and signs-off on the definition of done according to the acceptance criteria. Stakeholders and subject matter experts are briefed and informed as part of the advisory and feedback paths. This structure recognises that the decision making path is via the Project Board.
project governance
 Implementing an effective project governance framework is challenging and the hardest part is breaking old habits of defaulting to the organisational structure as the project structure.
I have found Scrum within a Prince2 framework to be a very effective in facilitating decision making and applying the key principles of project governance.
 This structure allows the Scrum Master and the Team to make the majority of project decisions on a day to day basis and only those decisions such as endorsing the Business Case or approving the project Plan,  will need to be made at the Project Board level.

Leave a Reply

Related Posts:

“Netiquette” for online meetings for remote and distributed teams

As with face-2-face meetings, online meetings also have an etiquette (“Netiquette”) to make them effective. One of the 12 principles of the agile manifesto suggests face-to-face is the best option but in today’s world of social distancing and WFH, it is no longer an option.

Here are the guidelines we have found useful for having for online meetings with distributed


22 Stances of a Scrum Master

The Scrum Master doesn’t remove impediments from the team. Their job encompasses 22 wider stances for supporting the team to self-organise to remove impediments themselves, coaching the Product Owner and coaching the wider organisation.


Does agility go out the window when we work remotely?

Many organisations are making guidance on what tools to use for remote teams in response to COVID-19. The situation isn’t a tools problem. This is a people problem – how can people, who are social creatures, successfully work remotely without physical interaction?


Copyright © Zen Ex Machina® and ™ (2019) All rights reserved. ABN 93 153 194 220

search previous next tag category expand menu location phone mail time cart zoom edit close