The new ITIL Product and Service Lifecycle Model – views from the front line
Across the two orbiting worlds of digital product management and digital service management, is there clarity about the purpose of each function – and, equally, what the other one does?
Megha Jain, Head of Product and Transformation in the UK Civil Service – writing on the government’s digital, data and technology blog – said: “True product management is about crafting a compelling vision, understanding user and customer pain points, steering the product team towards a prioritized roadmap, and delivering a product that users adore: one that makes their lives a tiny bit easier.”
Meanwhile Stanford University IT’s description of service management “refers to all the activities involved in designing, creating, delivering, supporting, and managing the lifecycle of IT services.”
Though clarity on their separate roles is indisputable, in neither case does one function mention the other. To many people working in these fields, this will come as no surprise.
Siloed working – a historical trend
When trying to manage digital products and services effectively, “the disconnection between teams is the biggest thing”, according to Scott Everett, Head of Application Management at Anglia Ruskin University and a beta tester for ITIL (Version 5).
And this leads to “fragmentation of services, delivery, quality, surprises between teams and not delivering outcomes”, he added.
Alex Harding, Head of IT Services at Runshaw College, said: “We work in a world where silos appear (we know they shouldn’t, but they do); teams are responsible for different workstreams, and so, if nothing is done, they will undoubtedly work in different ways.”
He described how digital products were created, traditionally, at the college by the development team that existed in an administrative area rather than IT, while IT had a service desk that focused on core infrastructure and the service overlay for applications created by the development team:
“Having them separate meant each group could specialize and get very good at what they did. And, previously, though different tools and processes existed, nothing really suited product lifecycles. So, in some ways, it was easier to keep them apart,” Harding added.
However, going back to Megha Jain and Stanford IT, both indicate how teams working in isolation are sub-optimal:
“Great products are not made by a single, great superhero, but by a team of great people who understand the vision and can do the challenging work to bring it to life. We do not want to be working in isolation…nor in silos,” Jain said, while Stanford IT takes its lead from ITIL 4’s definition of a service – a means of enabling value co-creation – which is underpinned by working in partnership.
Traditional product and service management – the uncomfortable truths
Despite what seemed like the easier option to keep digital product and digital service management in “splendid isolation” at Runshaw College, Harding was unconvinced:
“Let’s be honest: it created more problems than it solved. We ended up duplicating effort with two sets of processes, two sets of tools, and often two sets of priorities. It encouraged a silo mentality, where teams were more worried about their own KPIs than the bigger picture.”
Consequently, customer experience suffered because, as they became more interlinked, managing products and services separately was a barrier to getting things done.
As PeopleCert’s David Cannon and ITIL 4 co-author and ITIL (Version 5) reviewer, Barclay Rae, commented recently, having two diverse lifecycles but with very separate people, skills, and activities can lead to a lack of cohesion and synergy across functions. This results in predictable friction and problems such as lack of control, lack of governance, compromised security, heightened risk, and inefficiency.
Making the case for a shared approach
While “out of the box” thinking is often the way to tackle difficult problems, Catherine Bordinat – global IT service and project manager and member of the PeopleCert ITIL and DEVOPS INSTITUTE advisory board – suggests using “toy box” logic in this instance:
“Thinking of a digital product – or application – as a “box”, the “toys” inside are like services that the user can pick and choose from,” she explained.
“But the box won’t be fit for purpose if you don’t know which toys will go inside. In other words, the life of the box (the digital product) and the toys (the digital services) are interdependent.”
Instead of having a well-organized “toy box”, Harding’s experience was often the opposite: “In one project, which launched a new feature in our main product, the service desk wasn’t briefed properly, and within hours, users started calling in with questions, and the analysts were caught on the back foot.
“We’d see projects stall at the handover between product and service teams, with finger-pointing when something went wrong.”
He’s quick to emphasize that, while people working across both products and services cared genuinely about these issues, it was clearly time to look at a different way of working.
Combining products and service teams and the ITIL Product and Service Lifecycle Model
According to David Cannon and Barclay Rae, the only way organizations can expect systems and applications to enable greater productivity and deliver customer value is through effective collaboration between digital product management and digital service management teams.
They add that digital products and services share the same lifecycle and should be managed with an integrated approach – something now captured in the new ITIL Product and Service Lifecycle Model.
Even before its appearance in the latest version of ITIL, Alex Harding and his team had the opportunity to adopt the model as part of a wholesale change at Runshaw College:
“All of our digital product and service teams came together in what we call IT services, and we started by mapping our customer journeys end-to-end. We identified three customer personas as a result, and identified what they needed from both our products and our services, which allowed us to see where the overlaps and gaps were.”
With the “right people in the same room”, including developers, service desk analysts, and infrastructure engineers, the teams recognized their shared end goals, leading to “lots of great synergy”.
Citing the ITIL guiding principle of ‘Collaborate and promote visibility’, Harding said: “At the IT leadership level, we agreed on some shared goals, factored in service elements to our change and release/transition processes, and service desk analysts were involved in design. Now, we share what’s new and what’s happening regularly so people can voice their thoughts from whichever angle they represent.
“It wasn’t about reinventing the wheel, just making sure everyone was pulling in the same direction. I’m a fan of evolution over revolution or, as ITIL says, start where you are.”
Scott Everett sees the ITIL Product and Service Lifecycle Model as “bringing clarity across teams” about “which pieces of the model they touch, who they engage with – and with each part of the model named clearly, people can grasp the concepts more easily”.
“By aligning everyone in one, strategic direction, it enables people to reduce waste, cut duplication, streamline operations, improve delivery speed and deliver better quality,” he added.
Creating a collaborative ecosystem, not a silo
The ITIL Product and Service Lifecycle Model – according to Catherine Bordinat –represents the holistic lifecycle of products and services, and “organizations can identify their activities in a way that provides value in one or more stages, rather than in a silo. It’s a flexible way to work, depending on an organization’s focus, without losing sight of other parts of the model.”
She adds: “It enables top management to articulate a vision in a concrete and structured way with the right touchpoints while, for middle management, it’s a great way to remind them that they work in an ecosystem, not a silo, and to be mindful of input from various teams.”
Runshaw College’s IT services team has made the theory a reality, with product and service professionals working together with shared objectives, KPIs and a focus on value.
Harding explains how creating the service catalogue for staff and students involved everyone – development, service desk, infrastructure – from the start: “When we went live, the transition was smooth and user feedback was positive from day one.
“It’s not perfect, but it’s a big step forward, and the atmosphere in the teams is much more collaborative when, in the past, it would have been a few weeks of teething problems.”
Managing the reality of modern digital organizations
The Product and Service Lifecycle Model forms a central part of ITIL (Version 5) and – in the real-life experience of Alex Harding and Runshaw College – connects clearly with ITIL guiding principles: “Formalizing the lifecycle [in ITIL (Version 5)] gives everyone a common language, structure, and it lets us think and work holistically.”
“With early access to the digital product and service lifecycle concept, finally, we have a model that helps describe what we do and can support organizations that create software, physical digital items, and provide the services that support them.”
“ITIL (Version 5) reflects the reality of modern digital organizations, where products and services are inseparable. Having a formal model helps us manage risk, compliance, and quality consistently, end-to-end.”
Take the next step with ITIL (Version 5). Find out how the new ITIL Product and Service Lifecycle Model reflects the reality of modern digital organizations—and how ITIL guidance and certification can help your teams work as one, from concept to value realization.