Regardless of whether you’re running an agile or waterfall project, effective governance and stakeholder management underpins success. Importantly, governance should underpin effective and timely decision making.
Recently, I was working on a project when decision making was often stalled. The Product Owner of the Scrum Team was unable to pivot quickly to manage the changes needed to the Product Backlog because the PMO insisted that decisions required “everyone’s fingerprints all over it”. The PMO’s governance matrix and reporting cycle included:
- A 6-8 week lead time for stakeholders to review carefully documented changes and recommendations.
- Waiting until Senior Executive and Project Board meetings aligned to facilitate the review.
- Evaluation, approval, and sign-off of Product Backlog items (and any changes) by all stakeholder groups.
Given our Sprints were four weeks long, there was a very real disconnect.
I found Ross Garland’s Project Governance: A practical guide to effective project decision making, a useful starting point to develop a new governance framework that would clearly articulate the accountabilities and responsibilities for the project (RACI-VS model), one that was focused on outcomes, and allowed stakeholder feedback to be sought when their expertise was required.
Four principles of effective governance
Ensure a single point of accountability for success
This ensures clarity of leadership and timeliness of decision making. In Scrum, it’s the Product Owner who is empowered to make decisions on:
- What will be delivered – it’s made transparent in the Product Backlog
- When it will be delivered – the further down the Product Backlog, the further into the future the items will be delivered. A Product Owner will also typically use product roadmaps to communicate their intentions regarding when features will be released.
- The budget – value drives product development. The Product Owner is responsible for where to invest in order to optimise the delivery of value.
This accountability is not shared by a committee, as the Product Owner is the single point of accountability. Unfortunately, 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 delays in decision making and a blowout of timeframes to deliver.
Ensure the governance is service delivery focused
Many people seem to feel that the Scrum Master is also the Delivery Manager. This isn’t the case. His responsibility doesn’t extend beyond the rules of Scrum.
Products are defined by how they are used, not by the technology or system. Who is responsible for serving stakeholder and user needs? Who is responsible for ensuring the product’s use meetings those needs? Who is responsible for engagement with users, understanding stakeholder needs, and then ensuring that value is delivered? That person is the Product Owner.
Separate stakeholder management and project decision making
Stakeholders do need to have the opportunity to raise issues and concerns. Scrum relies on Sprint Review as a way of obtaining feedback and adapting the work of future Sprints. Unfortunately, many teams only do “demos” and “showcases” and forget that the Sprint Review involves:
- Inspecting the product Increment and getting feedback.
- Discussing what went well during the Sprint, what problems the team ran into, and how those problems were solved.
- Demonstrating the work that the team has “Done” and answering questions about the Increment.
- Discussing the Product Backlog as it stands, projecting likely
target and delivery dates based on progress to date (if needed). - Collaborating on what to do next, so that the Sprint Review provides
valuable input to subsequent Sprint Planning; - Reviewing how the marketplace or potential use of the product might have changed what is the most valuable thing to do next.
- Reviewing the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.
- Adapting the Product Backlog based on the feedback.
It’s the Product Owner’s responsibility to invite key stakeholders to participate in the Sprint Review. Using the Sprint Review as a mechanism to engage with stakeholders reduces the lead time to act on emerging needs.
While it may be useful to use committees to consult and engage at various points throughout delivery, the decision on what is of value, and what the team will deliver, still resides with the Product Owner.
Your governance bodies aren’t the same as your org chart
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 and every level of the hierarchy – going up and then going back down. 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 immediately being able to demonstrate that the acceptance criteria and Definition of Done had been met. In addition to slowing down the decision making process, and slowing delivery, we found that the quality of decisions were also impacted as some stakeholders involved didn’t have the prerequisite knowledge and understanding of the project and its issues.
From Project to a Product Governance Framework
The project governance framework used was based on PRINCE2.
Ultimately, because the Product Owner role was seen as a “team” level role (and so beneath senior managers), most decisions were escalated to people outside of the Scrum Team. The slow decision-making ultimately demanded we evolve the governance away from PRINCE2.
Changing to a product focus
Modern products have a life outside of the temporary project construct. Ours was no different. It would need continued technical support, continued engagement with users. The original notion of outsourcing delivery of the output to a project manager was seen as short sighted. The organisation understood that moving to product- over project frameworks was a necessary evolution.
This change required the following:
- An operating model where there was no separation of business and IT, but a fusion of delivery responsibilities.
- Operating from a single backlog.
- Empowering Product Owners to become Product Managers.
- Management with an active role in managing and improving the system of work over gated approvals.
- A move from focussing on deliverables and output to impacts and outcomes.
Conclusions
Implementing an effective project governance framework is challenging. While projects are designed to be temporary, its governance becomes less effective when this rule is broken and governance structures become permanent structures of the organisation.
Mixing Scrum’s governance within PRINCE2 further complicates things. Project accountability in PRINCE2 conflicts with the Product Owner’s role, particularly with respect to budgeting and the delivery of value. When digital products have lives that extend beyond the “project” it makes more sense to utilise different governance structures – ones that recognise the full lifecycle of a product, its stakeholders’ and users’ needs, and how pivot rapidly when those change.
Product frameworks and operating models put the Product Owner in the centre of governance in order to make decisions quickly, pivot when a change in plan is needed, and continue to see the product meet needs over just delivering an output.
If you’re using project governance frameworks, it’s time to evolve and use something more contemporary with the power to make rapid decisions so you can be faster to market.
M
