What’s the difference? Does the name matter?
Over a year ago, following an interesting chat with David Roberts at NHSBSA, I got to thinking about the role of the Service Owner; and why the role wasn’t working in the way we intended back in the dawn of the Service Manual. This in turn (as most things do for me) led to a blog in order to try and capture my thoughts in the vague hope they might be useful/interesting for anyone reading them.
Ironically, for what was a random think-piece, it has consistently been my most popular blog; getting a least a dozen reads everyday since I wrote it. Which got me thinking again; what is it about that blog that resonates with people? And the fact is, the role of the Service Owner is no better or consistently understood today than it was then. The confusion over the role of the Service Owner; their role and responsibilities, is still one of the most common things I get asked about. What’s the difference between a Service Owner or Manager (is there one)? How/why is the role different to that of the Product Lead? What is the difference between a Service Manager and a Programme Manager? Is the Service Owner different to the SRO? What do all these different role titles mean?
Every department/Agency within the Public Sector seems to have implemented the role of the Service Owner differently; which makes it very hard for those in the role (or considering applying for the role) to understand what they should be doing or what their responsibilities are etc. This is probably why, as a community of practice within DDaT, it certainly used to be the one hardest communities to bring together, as everyone in it was doing such different roles to each other.
Some clients I’ve been working with use the role of Service Owner and Lead Product Manager interchangeably; some have Service Owners who sit in Ops and Service Managers who sit in Digital (or vice versa); some have Service Managers sitting alongside Programme Managers; or Service Owners alongside Programme Directors, all desperately trying to not stand on each others toes.
So what is the difference?
The obvious place to look for clarity surely is the Service Manual, or the DDaT capability framework. The Service manual specifies it is the responsibility of the Service Owner is to be: “the decision-making authority to deliver on all aspects of a project. Who also:
- has overall responsibility for developing, operating and continually improving your service
- represents the service during service assessments
- makes sure the necessary project and approval processes are followed
- identifies and mitigates risks to your project
- encourages the maximum possible take-up of your digital service
- has responsibility for your service’s assisted digital support”
When the DDaT capability framework was first written, the Service Manager was more akin to a Product person; and originally sat as a senior role within that capability framework; yet they were also responsibility for the end to end service (which was a very big ask for anyone below the SCS working as an SRO). But the role often got confused with that of the IT Service manager, and (as perviously discussed in last years blog) the responsibilities and titles got changed to create the role of Service Owner instead.
Interesting in the Service Manual the reference to the Service Owner being the person who has responsibility for the end to end service; has now been removed; instead focusing on them being the person responsible for being the person responsible for delivering the project. While I imagine this is because it’s very hard for any one person (below SCS level) to have responsibility for an end to end service in the Public Sector due to the size of the Products and Services the Public Sector delivers; it does however mean the new role as description in the Service Manual seems to bring the role of Service Owner closer to that of the Programme Manager.
However, in contrast to the description in the Service manual, the DDaT capability framework does still specify that the role of the Service Owner is “accountable for the quality of their service, and you will be expected to adopt a portfolio view, managing end-to-end services that include multiple products and channels.” Obviously the onus here has changed from being responsible for the end to end service to managing the end to end service. But even that is a clear difference to being responsible for delivering a project as the manual describes it.
Some elements of the new Service Owner role description in the Manual do still align to the traditional responsibilities of Product people (mainly considering things like assisted digital support and ensuring you can maximise take up of your service); but the Service Manual has now removed those responsibilities within a team from the Product Manager. Now the Product Manager seems too intended to be much more focused solely on user needs and user stories; rather than the longer term uptake and running of the service. But again, confusingly, in the Capability framework for Product Management there is still the expectation that Product people will be responsible for ensuring maximum take-up of the service etc.
It seems in trying to clarify the role of the Service Owner, the Service Manual and the Capability framework disagree on exactly what the responsibilities of the role are; and rather than clarify the difference between the Product people and the Service Owners, the waters have instead been muddied even more. Nor have they made it any clearer if/what the difference is between the role of the Service Owner or Programme manager is.
The Project Delivery Capability framework states that “there are many other roles that are needed to successfully deliver projects. These roles are not included in our framework but you will find information on them within the frameworks of other professions, such as, Digital, Data & Technology framework” frustratingly it doesn’t give any clarity on how and when roles like SRO or Programme Manager might overlap with roles within the DDaT framework; nor how these roles could work best with the roles within the DDaT framework. Both the Service Owner role and the Programme manager role state responsibility for things like stakeholder management; business case development/alignment; risk management and governance adherence. Admittedly the language is slightly different; but the core themes are the same.
So is the assumption that you don’t need both a Programme Manager and a Service Owner? Is it an either or that has never been clearly specified? If you’re using PRINCE2 you get a Programme Manager, if Agile its a Service Owner? I would hope not, mainly because we all know that in reality, most Public Sector digital programmes are a blend of methodologies and never that clear cut. So are we not being clear enough about what the role of the Service Owner is? Does it really matter if we don’t have that clarity?
Evidence has shown that when teams aren’t clear on the roles and responsibilities of there team mates, and especially those people responsible for making key decisions; then bottlenecks being to occur. Teams struggle to know who should be signing of what. Hierarchy and governance become essential to achieving any progress; but inevitabley delays occur while approvals are sought, which simply slows down delivery.
So can we get some clarity?
At the start of the year DEFRA advertised a role for a Service Owner which (I thought) clearly articulated the responsibilities of the role, and made it clear how that role would sit alongside and support Product team and work with Programme professionals to ensure effective delivery of services that met user needs. Sadly this clarity of role seems few and far between.
I would love, when travel etc. allows, to see a workshop happen mapping out the roles of Service Owner; SRO; Programme manager; Product Lead etc. Looking at what their responsibilities are; providing clarity on where there is any overlap and how this could be managed better so that we can get to the point where we have consistency in these roles; and better understanding of how they can work together without duplication or confusion over the value they all add.
For now, at least, it’s each organisations responsibility to ensure that they are being clear on what the responsibilities for the roles and those people working in them are. We need to stop pretending the confusion doesn’t exist and do are best to provide clarity to our teams and our people; otherwise we’re only muddying the waters and it’s that kind of confusion that inevitably impacts teams and their ability to deliver.
