×

Category: Delivery

Service Owner vs. Programme Manager vs. Product Lead

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?

What's In a Name? A lot. – AE2S Communications
What’s in a name?

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.

Let’s be clear, say what do you mean

How to be a Product Advocate

Why you need a Product Person in your team.

Since joining Kainos a few weeks ago, I’ve had a number of conversations internally and with clients about the relationship between Delivery and Product; and why I as a Product Person moved over to Delivery.

‘Products at the heart of delivery’ image

My answer to that question was that, having spent over 10 years as a Product Person, and seeing the growth of Product as a ‘thing’ within the Public Sector; helping Product grow and mature, developing the community, ways of working, career pathway etc; I realised that what was missing was Product thinking at a senior level. Most Senior leaders within the Programme delivery or Transformation space come from a traditional delivery background (if not an operational one) and while many of them do now understand the value of user centric design and user needs etc; they don’t understand the benefit of a product centric approach or what value Product thinking brings.

The expansion of Product people in the Public sector has predominantly been driven by GDS and the Digital Service standards; with most organisations now knowing they need a ‘Product Manger‘ in order to pass their Service Standard Assessment. However, almost 10 years later, most organisations are still not prioritising the hiring and capability development of their Product people. In May I worked with four different teams each working to the Digital Standards and needing to pass an assessment; and in none of those teams was the role of the Product manger working in the way we intended when we creating the DDaT Product Management capability framework.

Most organisations (understandably) feel the role of the Product Manager should be an internal one, rather than one provided by a Supplier; but 9 times out of 10 the person they have allocated to the role has no experience in the role, have never worked on a product or service that was developed to the digital standards never mind having been through an assessment; and they are regularly not budgeted or allocated the project full time; often being split across too many teams or split between the Product Manager role whilst still working in Ops or Policy or whoever they have come from previously; more often than not their actually a Subject Matter Expert, not a Product Manager (which I’ve blogged about before).

As a supplier; this makes delivery so much harder. When the right Product person isn’t allocated to a project, we can quickly see a whole crop of issues emerge.

So what are the signs that Product isn’t being properly represented within a team:

  • Overall vision and strategy are unclear or not shared widely; teams aren’t clear on what they’re trying to achieve or why; this can be because the Product person is not able to clearly articulate the problem the team are there to solve or the outcomes that team are their to deliver aren’t clearly defined.
  • Roadmap doesn’t exist, is unstable or does not go beyond immediate future/ or the Scope of the project keeps expanding; often a sign that prioritisation isn’t being looked at regularly or is happening behind closed doors making planning hard to do.
  • Success measures are unclear or undefined; because the team doesn’t understand what they’re trying to achieve and often leads to the wrong work getting prioritised or outcomes not getting delivered or user needs not met.
  • Work regularly comes in over budget or doesn’t meet the business case; or the team keeps completing Discoveries and then going back to the start or struggling to get funding to progress. This can be a sign the team aren’t clear what problem they are trying to solve or that the value that the work delivers cannot be/ isn’t clearly articulated by the Product person.
  • Delivery is late/ velocity is slow. This can be a sign the team aren’t getting access to their Product person in a timely manner causing bottlenecks in stories being agreed or signed off; or that the Product person is not empowered to make decisions and is constantly waiting for sign off from more senior stakeholders.
  • Role out is delayed or messy, with operational teams frustrated or unclear on project progress; a sign that the team doesn’t have someone owning the roadmap who understands what functionality will be available when and ensuring any dependancies are clearly understand and being monitored, or a sign that there isn’t someone engaging with or communicating progress to wider stakeholders.

More often than not as a Supplier I’ve had to argue that we need to provide a Product person to work alongside/ with teams to coach/support their internal Product people in the skills and responsibilities a Product person needs to have to enable successful delivery. Where clients have been adamant they don’t want Product people from a Supplier (often for budgetary reasons), we’ve then had to look at how we sneak someone in the door; usually by adding a Business Analyst or delivery manager to the team who also has Product skills, because otherwise are ability to deliver will be negatively impacted.

When budgets are tight, the role of Product person is often the first thing project managers try to cut or reduce; prioritising the technical or project delivery skills over Product ones. As such, teams (and organisations) need to understand the skills a good product person brings; and the cost of not having someone within a team who has those skills.

  • Their role is to focus on and clarify to the team (and business) the problem the team are trying to fix.
  • Ensure a balance between user needs; business requirements and technical constraints/options.
  • Quantifying and understanding the ROI/ value a project will deliver; and ensuring that can be tracked and measured through clear success measures and metrics.
  • Being able to translate complex problems into roadmaps for delivery. Prioritising work and controlling the scope of a product or service to ensure it can be delivered in a timely and cost effective manner, with a proper role out plan that can be clearly communicated to the wider organisation.

As an assessor, I have seen more projects fail their assessments at Alpha (or even occasionally Beta) because they lack that clear understanding of the problem there trying to solve or their success measures etc; than I have because they’ve used the wrong technical stack etc. This can be very costly; and often means undress of thousands (if not millions) of pounds being written off or wasted due to delays and rework. Much more costly than investing in having a properly qualified or experienced Product people working within teams.

While Product and Delivery are often seen as very different skill sets; I recognised a few years ago the value in having more people who understand and can advocate for both the value Product thinking brings to delivery; but also how delivery can work better with Product. People who can not only understand but also champion both in order to ensure we’re delivering the right things in the right ways to meet our clients and their users needs.

Which is why I made the active decision to hop the fence and try and bring the professions closer together and build understanding in both teams and senior leaders in the need for Product and Delivery skills to be invested in and present within teams in order to support and enable good delivery, and I as really glad to see when I joined Kainos that we’re already talking about how to bring our Product and Delivery communities closer together and act for advocates to support each other; and it was in fact a chat with the Kainos Head of Product Charlene McDonald that inspired this blog.

Having someone with the title of Product Manager or Owner isn’t enough; we need people who are experienced in Product thinking and skilled in Product Management; but that isn’t all we need. We need to stop seeing the role of Product person as an important label needed you can give to anyone in the team in order to pass an assessment and understand why the role and the skills it brings are important. We need senior leaders, project managers and delivery teams who understand what value Product brings; who understand why product is important and what it could cost the team and their organisation if those product skills are not included and budgeted for properly right from the start. We need Senior Leaders to understand why it’s important to invest in their product people; giving them the time and support they need to do their job properly; rather than spreading them thin across teams with minimal training or empowerment.

We need more Product advocates.

Touchdown

So this week is my first week in Kainos. I’ve landed. Hurrah!

I’m never generally one for week notes, as I can never manage to remember to write a blog a week, or even remember everything I’ve done in a week to blog about it; but I thought given it’s my first week in a new role it’d be good to write down my first impressions, observations and experiences within my new role.

To be fair before I even started the role, Kainos were giving a good first impression; I’d been sent logins to their onboarding site, where I could see all the tasks I’d need to complete; with welcome intros from relevant senior folks and links to information about the company; as well as a message from Helen, the Head of Planning and Strategy initiatives and Delivery Management in Kainos letting me know she was looking forward to me joining. She also gave me the names of some other key folks in the Delivery community she recommended I talk to once I landed, and sharing details on some of the communities within Kainos I might like to join; which was really lovely.

On top of that, I also had emails getting me set up on their wider systems, and calls from the IT support team to ensure my laptop had arrived and everything was working ok before I started. All of which just made my first day that must smoother. On my first day itself I then got another call from the IT support team before 9:30 to check I’d gotten logged in ok and didn’t have any questions. Honestly, Bravo Kainos. Way to make an excellent first impression. A+

Then we move into the induction; this was really well organised and spread over two days to ensure it covered everything any new starters would need to know Getting everyone who’s starting in the same time period to join on the same day and do the induction together is a really good idea; it meant we could form a little group of newbies all asking the same questions and feeling a bit less lost together. We got a lovely intro chat from Brendan Mooney, the CEO of the company, on the first morning; which was given plenty of time so we could ask questions etc; and made him seem human and personable, which is always a good start. We also had sessions with people from IT support, the people team etc. All talking us through things we’d need to know (like how to do timesheets etc.) and pointing us to the relevant sections on the intranet so we could find the relevant areas and helpful guides should we need them.

On the afternoon of the second day, we moved form the general induction to one for our specific business areas; so we could start getting into the details relevant to our areas, which flowed really nicely. I also found the second day was also spaced out enough that we had enough time to do intro chats with out new managers, and I managed to observe a few meetings for my new teams, which was good.

Day three was then beginning to get stuck in; I had a calendar full of invites to all the relevant meetings I’d need to attend going forward; and an onboarding plan from my people manager suggesting useful people to talk to within my first month or so. I started chatting to a few folks within the various communities and practices that were relevant to me; and everyone was really welcoming and friendly. Already super impressed with the diversity and obvious culture of inclusion within Kainos. Joined a session with Kainos’ women’s network which was really interesting; chatted to some folks from their LGBT+ and Neurodiversity community’s and generally for a really good feeling from the various people I chatted to about how hard Kainos is working to make people feel welcome and at home.

New team seems great, just a lot to learn as the scope of what we’re doing is pretty big; but reasuringly I’m apparently getting a slow steady handover and into to everyone and everything; which will be a refreshing change to the last few times I’ve started a new role and basically been thrown in at the deep end and left to get on with things.

Day four was a bit quieter on the meeting front, with a few key meetings in with my new Account Director and a first 1:1 into meet with the client; but still plenty of time to dive into the background reading and trying to get up to speed on the programme we’re delivering so I can hopefully start asking useful questions and lending a hand. There were a few areas that I identified in the meetings on day three that I flagged to look into and pick up some conversations on to see what I could do to help; so day four was about giving myself time to read up before I start wadding in.

Day five was more handover meetings and continuing the 1:1 of my intro meetings to the client; with plenty of time to continue reading up and getting up to speed on everything. Also got to listen into a Business Unit update which covered work happening across Digital Services within Kainos which was fascinating and gave a good picture of the pure amount of projects teams are involved in; and had a first chat with the sales team about some potential new work.

All in all it has felt like a really well planned out introductory week. Lots to take in, but I’ve been given plenty of time to land; with room to read and absorb things between meetings rather than feeling like I’m being rushed around like a bit of a headless chicken; which is nice. Everyone so far has been absolutely lovely and very kind and willing to answer all my questions and talk me through things. I’m certainly looking forward to next week and hopefully starting to pick things up and getting properly dug in.

If only all landings could be this smooth! Next week the real work beings!

Delivering Value for yourself and others

Just short of two years ago I accepted the role of Director of Delivery at Difrent, a big move for me as I’d only worked in the Public Sector, but a good opportunity to see how things worked on the other side of the commercial table; and a great opportunity to work with some fantastic people (Honestly, Rach Murphy herself is a powerhouse who can teach the world a thing or two and always worth making time for) outside of the public sector, and learn new skills.

The services we were delivering at Difrent we’re very similar to those I’d been working on before, and I worked with many familiar faces; but still the challenges were new. Working at a start up that was beginning to scale up was a very different environment to working in a large established Government Department. Not just delivering great services that meet user needs, but also building up business processes; scaling up teams; winning new business.

And then there was the pandemic.

Because of it’s strong background in Health, Difrent was on the front line when it came to stepping up and supporting the COVID-19 response working with the NHSBSA; NHSX and DHSC. I always thought that my time on Universal Credit was the most fast pacing and demanding time of my life; which it turns out was nothing compared to being asked to stand up 6 teams of experts within 72 hours at the start of the first wave to support various urgent pandemic related services.

Alongside supporting and delivering high priority COVID-19 related services in unprecedented timescales (we successfully helped delivery of the Home Testing service in under a month) we also had to keep delivering our existing products and services; helping Skills for Care go Live with their Adult Workforce Data Set service, continuing delivery of NHS Jobs, helping the Planning Inspectorate pass their Beta Assessment for their Appeals service and delivering the wholesale business transformation for the British Psychological Society; whilst also picking up and delivering a whole host of other projects and services that we continued to win.

Because of the pandemic, a lot of new teams were beginning to work with Digital Service Standards, and having to go through Service Standard Assessments for the first time; and an increasing amount of my time began being demanded by clients to support them understand and adhere to the service standards. I’ve always joked about my perfect record for passing Assessments (while being clear, that not passing the first time isn’t failure, it just means you have more to learn!) working with one client to turn around their service in under 3 weeks from complete un-adherence to the standards to passing a Beta assessment has got to be a personal best!

The last year has been full on, with long weeks and even longer days. I’m so proud of everything DIfrent has achieved in the last 18 months; but I also recognised the time is right for me to move on and focus more on the bits of my role I am most passionate about.

And what is that? Being hands on and working with clients to solve problems. Having the time to work with teams to understand the issues they’re facing and how to go about fixing them. Seeing the positive changes being made and thinking of ways to keep iterating and improving on what we’ve done. Investing in and building that cultural and organisation change up over time. Whilst at the same time having a proper work life balance again; having time to give attention to my family and friends; rediscovering the things I enjoy doing outside of work and having time and energy to do them. As lockdown begins to end, it’s time for me to have a new start.

And so, from next week I’m moving on to work with Kainos, I’m really excited about this new opportunity. Going into a larger organisation means there will be more peers to share that load; bigger problems to solve for clients, bigger teams to work with, all with the benefit of the organisational processes etc in place already that we will need to deliver large projects; which will allow me to focus on working with clients fully and ensuring I’m delivering real value to them, and getting real value myself from my work.

Partnership

The good and the bad.

At Difrent we always talk about our desire to deliver in partnership with out clients. To move beyond the pure supplier and client relationship to enable proper collaboration.

One of my main frustrations when I was ‘client side’ was the amount of suppliers we’d work with who said they would partner with us, but then when the contract started, after the first few weeks had passed and the new relationship glow had faded; the teams and the account managers reverted to type. I can’t recall how many times I had to have conversations at the supplier governance meetings where I was practically begging them to challenge us; to be a critical friend and push for the right thing; to feedback to us about any issues and suggest improvements. It always felt like we were reaching across a gap and never quite making full contact.

As such, that’s one of the areas in Difrent I (and others) are very keen to embody. We try to be true partners; feeding back proactively where there are issues or concerns or where we have suggestions. Trying to foster collaborative ‘one team’ working.

We’ve obviously had more success with this on some contracts vs others. There’s always more we can learn about how to better partner with our clients; however; given we see a lot of complaining about strained partnerships between clients and suppliers; I thought I’d do a bit of a case study/ reflection and praise of one partnership we’ve been working on recently.

Difrent won a contract with the Planning Inspectorate last year, and it was the first completely remote pitch and award we’d been involved with on a multi million pound contract.

From the start of the procurement it became really clear that the Planning Inspectorate wanted a partner; that this wasn’t just lip service, but something they truly believed it. As part of the procurement process they opened up their github so we could see their code; they opened up their Miro so we could see their service roadmap, they proactively shared their assessment reports with suppliers etc.

For us this made not only a good impression, but enabled us to develop a more informed and valuable pitch.

Since we put virtual feet in the virtual door that dedication to partnership has remained as true 6 months later as it was then. Outside of our weekly governance calls we’ve had multiple workshops to discuss collaboration and ways of working. We’ve had multiple discussions on knowledge transfer and reflecting on progress and ways to iterate and improve.

Where there have been challenges we’ve all worked hard to be proactive and open and honest in talking things through. They’ve welcome our suggestions and feedback (and proactively encouraged them) and been equally proactive on giving us feedback and suggestions.

This has helped us adapt and really think about how we do things like knowledge transfer, always challenging (especially remotely), but something we’re passionate about getting right. We’ve all worked so hard on this, so much so that it’s become on of the core bits of our balanced scorecard; ensuring they as a client can measure the value they’re getting from our partnership not just through our outputs on the projects we’re working on, but our contributions to the organisation as a whole; which is also really helpful for us to be able to help us analyse and iterate our ‘value add’ to our partners; and ensure we’re delivering on our promises.

I think there is a lot of learning for other Departments/ ALB’s out there looking to procure digital services or capability on how a good partnership with a supplier needs to start before the contract is signed.

Thanks to Paul Moffat and Stephen Read at the Planning Inspectorate for helping with this blog – demonstrating that partnership in action!

Digital Transformation is still new

We’re punishing those who are less experienced, and we need to stop.

The timeline of Digital Transformation. Courtesy of Rachelle @ https://www.strangedigital.org/

In the last few weeks I’ve had multiple conversations with clients (both existing and new) who are preparing for or have recently not passed their Digital Service standard assessments who are really struggling to understand what is needed from them in order to pass their assessment.

These teams have tried to engage with the service standards teams, but given those teams are extremely busy; most teams cant get any time with their ‘link’ person until 6 weeks before their assessment; by which time most teams are quite far down their track and potentially leaves them a lot of (re)work to try and do before their assessment.

Having sat in on a few of those calls recently I’ve been surprised how little time is set aside to help the teams prep; and to give them advice on guidance on what to expect at an assessment if they haven’t been through one before. Thos no time or support for mock assessments for new teams. There may be the offer of one or two of the team getting to observe someone else’s assessment if the stars align to allow this; but it’s not proactively planned in; and instead viewed as a nice to have. There seems to be an assumption the project teams should know all of this already; and no recognition that a large number of teams don’t; this is still all new to them.

“In the old days” we as assessors and transformation leads used to set aside time regularly to meet with teams; talk through the problems they were trying to fix, understand any issues they may be facing, provide clarity and guidance before the assessment; so that teams could be confident they were ready to move onto the next phase before their assessment. But when I talk to teams now, so few of them are getting this support. Many teams reach out because the rare bits of guidance they have received hasn’t been clear, and in some cases it’s been contradictory and they don’t know who to talk too to get that clarity.

Instead, more and more of my time at the moment, as a supplier, is being set aside to support teams through their assessment. To provide advice and guidance on what to expect, how to prepare and what approach the team needs to take. Actually what an MVP is; how to decide when you need an assessment, and what elements of the service do you need to have ready to ‘show’ at each stage. What the difference is between Alpha/ Beta and Live assessments and why it matters. For so many teams this is still almost like a foreign language and new.

So, how can we better support teams through this journey?

Stop treating it like this is all old hat and that everyone should know everything about it already.

Digital Transformation has been ‘a thing’ for one generation (if you count from the invention of the internet as a tool for the masses in 1995); Within the public sector, GDS, the Digital Service Standards and the Digital Academy have existed for less than one generation; less than 10 years in-fact.

By treating it as a thing everyone should know, we make it exclusionary. We make people feel less than us for the simple act of not having the same experience we do.

We talk about working in the open, and many team do still strive to do that; but digital transformation is still almost seen as a magical art by many; and how to pass what should be a simple thing like a service standard assessment is still almost viewed as Arcane knowledge held by the few. As a community we need to get better at supporting each other, and especially those new to this experience, along this path.

This isn’t just a nice thing to do, its the fiscally responsible thing to do; by assuming teams already have all this knowledge we’re just increasing the likelihood they will fail, and that comes with a cost.

We need to set aside more time to help and guide each other on this journey; so that we can all succeed; that is how we truly add value, and ensure that Digital Transformation delivers and is around to stay for generations to come.

Talking Digital Transformation

It’s something that has come up a lot in conversations at the moment, what is Digital Transformation? What does Digital Transformation mean to me? I always joke that it’s my TED talk subject, if I had one; as such I thought why not write a blog about it?

What is Digital Transformation?

According to Wikipedia, Digital Transformation “is the adoption of digital technology to transform services or businesses, through replacing non-digital or manual processes with digital processes or replacing older digital technology with newer digital technology.

The Wikipedia definition focuses on 3 of the main areas of Digital Transformation; technology, data, process; which are the areas most people quote when but doesn’t reference organisational change; which is often recognised as the 4th pillar needed for successful transformation.

If we’re being specific, then I agree with the Wikipedia definition at the project or service level, but when someone says Digital Transformation to me; I automatically start thinking about what that means at the organisational level, before moving onto the other areas.

I’ve done plenty of blogs previously on the importance of considering your organisational culture when trying to implement change; and how likely it is that your transformation will fail if you don’t consider your culture as part of it; but that as we see from the Wikipedia Definition; the people side of Digital Transformation is often forgotten.

There’s a good blog here that defines the 4 main challenges organisations face when looking to implement Digital Transformation, which it defines as:

  • Culture.
  • Digital Strategy and Vision.
  • IT infrastructure and digital expertise.
  • Organisational Structure.

Here, we see Culture is the first/largest challenge mainly organisations face; which is why it’s important is’t not treated as an afterthought. Why is that? Is our methodology wrong?

So how do we go about delivering Digital Transformation?

The Enterprise project has a good article here on what it views as the 3 important approaches leaders should take when implementing Digital Transformation.

  • Solve the biggest problem first.
  • Collaborate to gain influence.
  • Keep up with information flows.

There’s (hopefully) nothing revolutionary here; this is (in my opinion) common sense in terms of approach. But so often, when we start talking about Digital Transformation, we can quickly fall into the trap about talking about frameworks and methodology; rather than the how and why of our approach to solving problems. So, are there any particular frameworks we should be using? Does the right framework guarantee success?

There are lots of different frameworks out there; and I can’t document them all; but below are some examples…

This article sums up what it deems as the top 5 Digital Transformation frameworks, which are the big ones; including MIT; DXC; CapGemini; McKinsey; Gartner; Cognizant and PWC. It’s a good summary and I won’t repeat what it says about each, but it looks at them in the following terms that I think are key for successful Digital transformation:

  • customer-centricity
  • opportunity and constraints
  • company culture
  • simplicity

There are obviously a few others out there; and I thought I’d mention a couple:

The first one is this AIMultiple; this one interestingly has culture as the final step; which for me makes it feel like you are ‘doing transformation to the teams rather than engaging teams and bringing them into the transformation; which doesn’t work well for me.

AIMultiple Digital Transformation Framework
https://research.aimultiple.com/what-is-digital-transformation/#what-is-a-digital-transformation-framework

This second one; from ionology, has Digital Culture and Strategy as its first building block; with user engagement as its second building with equal waiting to Processes, Technology and Data. It recognises that all of these elements together are needed to deliver Digital Transformation successfully. This one feels much more user centric to me.

https://www.ionology.com/wp-new/wp-content/uploads/2020/03/Digital-Transformation-Blocks-Equation.jpg

So where do you start?

Each of these frameworks has key elements they consider, in a particular order that they feel works best. But before panicking about which (if any) framework you need to pick; it’s worth remembering that no single framework will work for every business and any business will need to tailor a framework to fit their specific needs. 

How you plan to approach your transformation is more important than the framework you pick. Which is why the Enterprise article above about good leadership for me is spot on. We should always be asking:

  • What is the problem you’re trying to solve within your organisation by transforming it, and why?
  • Who do you need to engage and collaborate with to enable successful transformation?
  • What is the data you need to understand how best to transform your organisation?

Once you know what you’re trying to achieve and why, you can understand the options open to you; you can then start looking at how you can transform your processes, technology, data and organisational structure; at which point you can then define your strategy and roadmap to deliver. All of the above should be developed in conjunction with your teams and stakeholders so that they are engaged with the changes that are/will be happening.

Any framework you pick should be flexible enough to work with you to support you and your organisation; they are a tool to enable successful Digital Transformation; not the answer to what is Digital Transformation.

So, for me; what does Digital Transformation mean?

As the Enterprise Project states; Digital transformation “is the integration of digital technology into all areas of a business, fundamentally changing how you operate and deliver value to customers. It’s also a cultural change that requires organisations to continually challenge the status quo, experiment, and get comfortable with failure.” Which I wholeheartedly agree with.

Agile Delivery in a Waterfall procurement world

One of the things that has really become apparent when moving ‘supplier side’ is how much the procurement processes used by the public sector to tender work doesn’t facilitate agile delivery.

The process of bidding for work, certainly as an SME is an industry in itself.

This month alone we’ve seen multiple Invitations to Tender’s on the Digital Marketplace for Discoveries etc, as many departments are trying to spend their budget before the end of the financial year.

The ITT’s will mention user research and ask how suppliers will work to understand user needs or hire proper user researchers. But they will then state they only have 4 weeks or £60K to carry out the Discovery. While they will specify the need for user research, no user recruitment has been carried out to let the supplier hit the ground running; it’s not possible for it to be carried out before the project starts (unless as a supplier you’re willing to do that for free; and even if you are, you’ve got less than a week to onboard your team, do any reading you need to do and complete user recruitment, which just isn’t feasible); and we regular see requests for prototypes within that time as well.

This isn’t to say that short Discoveries etc. are impossible, if anything COVID-19 has proved it is possible, however there the outcomes we were trying to deliver were understood by all; the problems we were trying to solve were very clear,; and there was a fairly clear understanding of the user groups we’d need to be working with to carry out any research; all of this enabled the teams to move at pace.

But we all know the normal commercial rules were relaxed to support delivery of the urgent COVID-19 related services. Generally it’s rare for an ITT to clarify the problem the organisation is trying to solve, or the outcomes they are looking to achieve. Instead they tend to solely focus on delivering a Discovery or Alpha etc. The outcome is stated as completing the work in the timeframe in order to move to the next stage; not as a problem to solve with clear goals and scope.

We spend a lot of time submitting questions trying to get clarity on what outcomes the organisations are looking for, and sometimes it certainly feels like organisations are looking for someone to deliver them a Discovery solely because the GDS/Digital Service Standard says they need to do one. This means, if we’re not careful, halfway through the Discovery phase we’re still struggling to get stakeholders to agree the scope of the work and why we really do need to talk to that group of users over there that they’ve never spoken too before.

Image result for gds lifecycle
The GDS lifecycle

The GDS lifecycle and how it currently ties into procurement and funding (badly) means that organisations are reluctant to go back into Discovery or Alpha when they need too, because of how they have procured suppliers. If as a supplier you deliver a Discovery that finds that there is no need to move into Alpha (because there are no user needs etc) or midway through an Alpha you find the option you prioritised for your MVP no longer meets the needs as anticipated, clients still tend to view that money as ‘lost’ or ‘wasted’ rather than accepting the value in failing fast and stopping or changing to do something that can add value. Even when the clients do accept that, sometimes the procurement rules that brought you on to deliver a specific outcome mean your team now can’t pivot onto another piece of work, as that needs to be a new contract; either scenario could mean as a supplier you loose that contract you spent so much time getting, because you did ‘the right thing’.

We regularly pick up work midway through the lifecycle; sometimes that’s because the previous supplier didn’t work out; sometimes its because they were only brought in to complete the Discovery or Alpha etc. and when it comes to re-tender, another supplier is now cheaper etc. That’s part and parcel of being a supplier; but I know from being ‘client side’ for so long how that can make it hard to manage corporate knowledge.

Equally, as a supplier, we rarely see things come out for procurement in Live, because there is the assumption by Live most of the work is done, and yet if you follow the intent of the GDS lifecycle rather than how it’s often interpreted, there should still be plenty of feature development, research etc happening in Live.

This is turn is part of the reason we see so many services stuck in Public Beta. Services have been developed by or with suppliers who were only contracted to provide support until Beta. There is rarely funding available for further development in Live, but the knowledge and experience the suppliers provided has exited stage left so it’s tricky for internal teams to pick up the work to move it into Live and continue development.

Most contracts specify ‘knowledge transfer’ (although sometimes it’s classed as a value add; when it really should be a fundamental requirement) but few are clear on what they are looking for. When we talk to clients about how they would like to manage that, or how we can ensure we can get the balance right between delivery of tangible outcomes and transferring knowledge, knowledge transfer is regularly de-scoped or de-prioritised. It ends up being seen as not as important as getting a product or service ‘out there’; but once the service is out there, the funding for the supplier stops and the time to do any proper knowledge transfer is minimal at best; and if not carefully managed suppliers can end up handing over a load of documentation and code without completing the peer working/ lunch and learns/ co-working workshops we’d wanted to happen.

Some departments and organisations have got much better at getting their commercial teams working hand and hand with their delivery teams; and we can always see those ITT’s a mile off; and it’s a pleasure to see them; as it makes it much easier for us as suppliers to provide a good response.

None of this is insurmountable, but we (both suppliers and commercial/procuring managers and delivery leads) need to get better at working together to look at how we procure/bid for work; ensuring we are clear on what the outcomes we’re trying to achieve are, and properly valuing ‘the value add’.

Agile at scale

What do we even mean when we talk about agile at scale and what are the most important elements to consider when trying to run agile at scale?

This is definitely one of those topics of conversation that goes around and around and never seems to get resolved or go away. What do we even mean when we talk about agile at scale? Do we mean scaling agile within a programme setting across multiple teams? Do we mean scaling it across multiple programmes? Or do we mean scaling it using it at scale within a whole organisation?

When ever I’m asked about what I believe to be the most important elements in enabling successful delivery using agile, or using agile at scale, the number one thing I will always talk about isn’t the technology; It isn’t digital capability; or experience with the latest agile ways of working (although all those things are important and do obviously help) it’s the culture.

I’ve blogged before on how to change a culture and why it’s important to remember cultural change alongside business transformation; but more and more, especially when we’re talking about agile at scale I’ve come to the conclusion that the culture of an organisation; and most especially the buy in and support for agile ways of working at a leadership level within an organisation, is the must fundamental element of being able to successfully scale agile.

Agile its self is sadly still one of those terms that is actually very marmite for some, especially in the senior leadership layers. They’ve seen agile projects fail; it seems like too much change for too little return, or its just something their digital/tech teams ‘do’ that they don’t feel the need to really engage with. GDS tells them they have to use it, so they do.

Which is where I think many of the agile at scale conversations stumble; it’s seen as a digital/tech problem, not an organisational one. This means that time and again, Service Owners, Programme Directors and agile delivery teams get stuck when trying to develop and get support for business cases that are trying to deliver holistic and meaningful change. We see it again and again. Agile delivery runs into waterfall funding and governance and gets stuck.

As a Service Owner or Programme Director trying to deliver a holistic service, how do you quantify in your business case the value this service and this approach to delivery will add? The obvious answer, hopefully, is using data and evidence to show the potential areas for investment and value it would add to both users and the business. But how do you get that data? Where from? How do you get senior leaders to understand it?

In organisations where agile at scale is a new concept, supporting senior leaders to understand why this matters isn’t easy. I often try and recommend new CDO’s, CEO’s or Chief Execs ‘buddy up’ or shadow some other senior folks who have been through this journey; folks like Darren Curry, Janet Hughes, Tom Read and Neil Couling; who understand why it matters, and have been through (or are going through) this journey themselves in their organisations and are able to share their experiences for both good and bad.

I will always give full praise to Alan Eccles CBE who was previously The Public Guardian, and chief exec of the Office of the Public Guardian, with out whom the first Digital Exemplar, the LPA online, would never have gone live. Alan was always very honest that he wasn’t experienced or knowledgeable about agile or digital, but he was fully committed to making the OPG the first true Digital exemplar Agency; and utilising everything digital, and agile ways of working, had to offer to transform the culture of the OPG and the services they delivered. If you want an example of what a true Digital culture looks like, and how vocal and committed Alan was to making the OPG digital, just take a look at their blog which goes all the way back to 2015 and maps the OPG’s digital journey.

Obviously, culture isn’t the only important factor when wanting to scale agile; the technology we use, the infrastructure and architecture we design and have in place, the skills of our people, the size of our teams and their capacity to deliver are also all important. But without the culture that encompasses and supports the teams, the ability to deliver at scale will always be a struggle.

The commitment to change, to embracing the possibilities and options that a digital culture and using agile at scale brings at the senior leadership level permeates through the rest of the organisation. It encourages teams to work in the open, fostering collaboration, identifying common components and dependancies. It acknowledges that failure is ok, as long as we’re sharing the lessons we’ve learned and are constantly improving. It supports true multidisciplinary working and enables holistic service design by encouraging policy, operations and finance colleagues etc to be part of the delivery teams. All of this in turn improves decision making and increases the speed and success of transformation programmes. Ultimately it empowers teams to work together to deliver; and that is how we scale agile.

Buy out, or buying in.

Welcome To The Party Richter GIFs | Tenor

So, we’re ten days into Difrent being ‘bought’ by The Panoply group; people keeping saying ‘congratulations’, ‘how’s it working for a new boss/ company?’, ‘how do you feel about the buy out?’ So I thought it was a good opportunity to reflect on my thoughts about the acquisition.

And the answer is, I’m feeling pretty good actually. Honestly, so far there hasn’t really been much difference, other than the feeling that we’re part of a larger group of likeminded people.

Difrent is still Difrent, my boss is still my boss, my teams are still my teams and my peers are still my peers. What it does mean is that I now have more peers to talk to, share lessons learned with and bounce ideas off of. It means there are potentially more opportunities for our people to get involved in, bigger communities of practice to be part of and more slack channels to share pictures of my dog on.

A picture of a black dog
The Dog.

Chatting to some of my team yesterday, and the best analogy I could think of about the Panoply group and my understanding of how it works is actually the Civil Service.

Within the Civil Service you ‘belong’ to a certain Government Department, I was at DWP for ten years, and even years after leaving there’s still a part of my brain that think of myself as a DWP person, even though I worked in 5 different departments in my tenure in the public sector. But as a Civil Servant, although I was in DWP, I had opportunities within and across the Civil Service that others outside the Civil Service didn’t. If you were at threat of redundancy in the CS, you got first dibs on other job opportunities, not just in your in department but across the Civil Service and secondments and training opportunities across government departments were possible to further your career development etc.

Within the Group we have the opportunity for our people to go on loan to another company in the group, to further their career development, or because the project they have been working on has ended and we don’t have something else for them to immediately move onto, but someone else in the group does. This is a massive bonus for our people. It gives them so many more opportunities, and takes aware some of the fear you get in agencies about ‘what happens when this contact ends?’ We’re already sorting out access to the communities of practice within the group and discussing opportunities for our people to do secondments in the future/ and vice versa for others in the group to come work with us.

These options to be part of something bigger, to open up and share more opportunities for our people, to work together with likeminded folks was one of the reasons I voted for joining the group when I was asked my opinion. And it certainly doesn’t hurt on a selfish level that so many people I know, have worked with before and respect are also in the group; Within the first 10 days I’ve already had fantastic welcome meetings with so many folks across the whole of the group.

My first ‘catch up/welcome to the party’ call with Ben Holliday was like we were picking up where we were last time we worked together, and Carolyn Manuel-Barkin and I have already put the world to rights and discussed all things Health related; all definitely good signs for me. And being part of the group is already paying off for us, with some joint opportunities with Not Binary and the fantastic folks there already looking very positive (honestly David Carboni has not only the most relaxing voice, but is also really interesting and if you get the chance to hear him talk tech and good team dynamics you should definitely take it). [EDIT: since posting this blog this morning, we have now won our first piece of work with Not Binary!]

Difrent is all about delivering outcomes that matter about adding value and making a difference; and we’ve always been vocal about working better in partnership, both with or clients and other suppliers. Panoply will help us do that.