2

I just started to learn the ropes of Project Management. While doing so I was confronted with the concept of Project governance. As I like the concept of scrum I was somehow reminded of the scrum master. As far as I understand I would put the project governance on a higher level than the scrum master (more or less a scrum master of the scrum master and his team).

  1. Is this understanding reasonable? As I do not think this is a proper description: Is there a more accurate way to describe this relation?
  2. Are these two concepts compatible at all? Or do they exclude each other? What are your experiences?
  3. What are the main differences and similarities?

EDIT

Thank you for the fast replies. In the meantime I also did some further research and found an interesting article. I think I have a better understanding how project governance and scrum work together now. Further contributions are welcome.

Improve this question

3 Answers 3

Reset to default
4

My experience is that governance in an Agile setting is successful when it's put in place to enhance the work itself rather than as a means to control the workers.

Scrum has certain elements of governance built in. The Product owner has governance over the Product backlog. The team has governance over the Sprint backlog. Etc.

Basic Scrum does not address governance across larger teams (teams of teams). Certain scaling frameworks address governance (i.e. - Disciplined Agile embraces an architecture owner). Most scaling frameworks allow for a Program Layer and Portfolio Layer that exist above the team level.

Hope that helps!

Improve this answer
1
  • What if the result of tasks is highly dependent on other's task ?
    – Larry Lo
    Jul 25, 2016 at 1:59
2

I have always understood the term 'project governance' to mean the method by which an organisation chooses to apply checks and controls to its projects rather than the hierarchy of management and responsibility over resources within an organisation.

So for example an organisation might define its Project Governance as:

  • The PM will have 10% tolerance over budget and 5% tolerance over timescales
  • We will always use a Project Board comprised of [these] stakeholders and the project manager will report to the Project Board
  • Budgets will be granted by [this process] and changes to budgets will require full change control approved by the Project Board
  • The Project Manager will issue progress reports fortnightly and have a face to face progress meeting with the Project Board on a monthly basis as well as issuing key comms to the wider business on a quarterly basis
  • etc. etc.

I.e. it is a description of the operational mechanics of delivering the project, in sufficient detail to allow the audience to understand how things are going to get done and where the reporting and responsibility lines and demarcations are.

So the specific methods employed within Scrum would form part of the project governance at that organisation, together with other principles and processes within and without the actual delivery team(s).

Improve this answer
0

I appreciate this is a few years old, but it's worth adding a couple of points.

The notion of project governance is built into scrum, but it's treated quite differently. The classical model of project governance is the "iron triangle": scope, schedule/time, and cost/resources (these are the three criteria used in the CHAOS Reports). When you initiate a waterfall project, you define and fix the scope, estimate schedule and cost. You then use the various project governance techniques to measure against these standards. If scope changes, then you need to revisit schedule and cost (a change request process). The CHAOS reports show that most projects fail - with about 10% actually succeeding under Waterfall and about a third completely failing (the rest are challenged - typically going over budget or not to scope).

Agile - Scrum in particular - takes a different approach. In Agile, you shorten the planning cycle, you fix time and resources, then estimate scope. The features should be prioritised in terms of value - delivering working software quickly. Feature governance is provided by the product owner; process governance is provided by the scrum master - but these look very different to project governance. If we go back to the original iron triangle, then you find that agile projects actually do better against these three criteria - with about a third being successful and 10% failing outright.

Agile does well where it focuses on measurable value rather than process measures. There are process measures: velocity, epic forecasts and the like. But these are secondary to delivering working software. Used well, these are tools that help increase efficiency. But they are not the ultimate measures of the process; this is measured by the value delivered.

The challenge lies in working with customers. Managing their expectations and communicating the progress as we go. Ideally, this is done through less reporting and more tangible delivery. This should be supported by well defined measures of success.

Putting traditional project governance like project plans and Gantt charts around an agile process at best consumes resources and at worst leads you towards a waterscrumfall process and the worst of both worlds.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.