Professional Services: Where does a Product Owner Fit? | synvert TCM
by Antony Melvin — Head of Professional Services
In developing an Agile Scrum framework for a Professional Services Organisation (PSO), one of the key challenges is the role of the Product Owner (PO). In a traditional scrum setup the PO will work as one of the three amigos, will prioritise the work backlog and own ceremonies like the sprint review.
If a company has an Embedded Services Organisation (ESO) — an in-house team — or a Product team, the role of PO tends to work in a more traditional sense (I’ll leave the nuances for a different time). But for a PSO the PO role is trickier to define.
At this point I’ll offer the disclaimer that I’m a Scrum Alliance certified Product Owner.
A PSO basically operates by selling its expertise to client companies, either by embedding consultants or delivering projects. In this type of relationship, the client company logically should identify someone to act as the PO. The PO is invested in choosing the priority of the work backlog and ensuring that the right things are worked on in the right order and if the company wants the project to change tack the client PO should make and justify that decision.
Whilst it is logical for the client to offer up a PO, it is quite common for a client to offer up a Project Manager (PM).
A project has been bought for a certain amount of money, to be delivered over a certain period, to deliver a defined scope — this is textbook PM territory. Especially if a client company isn’t wedded to Agile practices.
It would take the word count of a thick book to properly explore the challenges this offers to a PSO working in an Agile fashion, the main one I’d like to explore in this blog is how to proxy the PO role so that PMs have the tools they need to answer to their internal stakeholders and maintain a bridge into the project itself.
So, I’m going to be a bit simplistic here for brevities sake.
PMs tend to see a Project Proposal or a Statement of Work — even one at the start of an Agile project — as a long ‘To Do’ list that needs ticks rather than a backlog that needs curating. PMs have their tools like Risk registers, RAID logs, status reports and so on. If they have gone through the PRINCE 2 route, they will know all about the importance of managing stage boundaries and the documentation required for changing course. In overly simplistic terms, PMs tend to work on a project by identifying and clarifying what is going to plan — and what isn’t going to plan. There is a PRINCE 2 agile pathway but the way a Scrum Agile project zigzags around rarely suits a PMs toolset.
Even if a PM is in place with good agile experience, it is still challenging for a PM to be a proxy PO. If a project delivers A, B & C over 3 months — but a month into the project this becomes delivering A & D over 4 months, there are tricky hurdles to clear. If there was a PO in place, they would then own these changes and sell them back to the stakeholders, acting as a proxy stakeholder.
But a PM rarely has that authority.
A client PM is often allocated to a project without an instruction that they can change the project scope, budget, or timelines as they see fit — and dropping some commentary into a weekly status report that the project is now heading first class for Canada rather than hitching to Dubai is not going to be enough.
A client PM needs an airgap.
The PM needs someone to own any changes and deliver a change request each time there is a significant project change, so that the PM can comfortably report back each change order and the impact this has on deliverables and timelines — with wrapper documentation to justify the delta. This gives the client stakeholders the right information to make decisions without leaving the PM on the hook for the implications.
One way to create this airgap would be to simply introduce a PO to work with the PM in the client organisation or pay the PSO for this additional member of the team. Unfortunately, the additional cost involved may make the project less tenable and undermine the client PM. A client may well ask why should they employ a PM and a PO with overlapping responsibilities for a single project?
The way synvert TCM squared this circle, admittedly not without some false starts, and without adding in additional client cost was to elevate the Scrum Master (SM) role into a Scrum Master Plus role. This Plus role helps the project team in all the ways that a Scrum Master should; but also helps the client PM with regular check-ins and by giving them a series of PM artefacts like weekly status reports, RAID logs and change requests.
This enhanced role at synvert TCM is called a Delivery Lead and means that our Scrum Masters work directly with client PMs to deliver projects. Generating the benefits of an Agile delivery process as well as supporting the client PM but without requiring the cost of an explicit PO.
Want to know more? Get in touch today!
