ITIL (Version 5) im Interview

Why a new version – Roman Jouravlev in conversation with Richard Friedl

ITIL (Version 5) interview, transcript for reading (English, cleaned).

Interviewer: Richard Friedl. Guest: Roman Jouravlev.

Richard: Hello everybody, it’s late spring in Austria and it’s really hot today, so we sit in the garden. I’m Richard Friedl, and my guest today in the garden is Roman Jouravlev.

Roman: That’s me, I’m Roman. I have been working for the last 10 years on developing ITIL, and that’s probably the most important thing about me.

Richard: Yes, and it’s a reason why you are my guest …

Roman: I assumed so 

Richard: … because we had some interviews with authors of the new ITIL version, ITIL version 5. And now we want to bring some things together to get kind of more insights and more background, because you’re the architect for ITIL, and not only for the current version of ITIL; you have also been in the architecture team of a previous version of ITIL. And so the first question is: when did it become clear that we would need a new version of ITIL and not just an update to ITIL 4?

Roman: That’s a good question. Anyone who followed development of ITIL probably heard me or some other team member saying that we designed ITIL 4 for continual improvement rather than major updates, and we wanted ITIL 4 to just evolve naturally rather than require a massive update, like we used to have in previous shifts of the version. However, four things emerged that couldn’t be addressed well enough – not completely couldn’t, but couldn’t be addressed well enough – is continual improvement.

Roman: One, the most obvious probably, is the rapid adoption and rise of AI. AI is in our products and services, and AI is rapidly, is being rapidly adopted for product and service management, and that’s the level of change comparable with previous important changes, such as adoption of cloud or fast internet or mobile or end user computing. It changes the landscape significantly. We needed to address it, and it required major changes.

Roman: Another, probably more important, although less hyped thing is the VUCA-ness: the increased volatility, uncertainty, complexity and ambiguity of pretty much everything of the world around us. And I dare say that version 5 is the first complexity native framework. It was written in the complexity, in the complex environment, it was written for the complex environment. And things such as strategy or transformation – and you already discussed some of them with other guests – they manifest this complexity focus a lot.

Richard: Yeah.

Roman: The third one was the need for better focus on the human side of technology management. I mean the experience book, but not only: many other aspects of the human side of technology management are included in ITIL 5 at the level that we couldn’t have achieved if we were just incrementally adding some small stuff.

Roman: And the fourth one is our intent to bring product and service management closer together. We expanded the scope of ITIL from IT service management to digital product and service management. Yeah, it’s a topic for another three hours discussion, but in the shortest possible form: we believe that the silo mentality that has been forming for years around product community and service community is not good for the communities, and we want to help the industry to bring product and service management closer together. That’s probably the most ambitious intent of all and the hardest to achieve, but we wanted this change to take place.

Richard: I noticed in version 4 that there was the book High-velocity IT, I guess, that had all the four points in it, but it was just a single book out of a whole framework.

Roman: That’s true. Plus, it’s a bit of a marketing rather than content thing, but if you don’t put certain words on the cover, people who are supposed to read don’t know about it. So High-velocity IT, just like CDS and DSV and DPI – the titles of the upper levels publications in version 4 and the respective training – they were not self explanatory. They didn’t tell you that it’s for you …

Richard: Yep

Roman: … it wasn’t area or the capability. It was a correct description of what’s inside, but it wasn’t immediately appealing that, „Oh, I work in product management, that probably is for me. I work in service management, that’s probably for me.“ And that’s one of the things that we theoretically could have achieved through incremental improvement. But again, we used this opportunity with the new version to give a slightly new structure and new naming that makes it clearer and more relatable.

Richard: And of course you get more interest in the community if you announce a new version rather than just an update.

Roman: That’s also true, yes. It was, to an extent, a matter of time when the marketing team decides that it’s time to rebrand it to attract more attention, but it certainly wasn’t their cause or the primary cause. And we could have said that this is ITIL 4.5, and between 4.5 and 5, that’s more a marketing reason. But those four reasons I named, product, experience and human side, AI and complexity, they are true causes for a major update.

Richard: I see. Was there any resistance, internally or from the community, against the plan of a new version?

Roman: I wouldn’t call it resistance, no. Generally, I would say that so far this is the best accepted version.

Richard: Okay.

Roman: Based on the feedback we hear, based on their public reviews from people who are not affiliated, who are not trainers or consultants, who are not our partners, but had a chance to see the books.

Roman: I will give you one example: Chris Barrett, who used to work for Axelos many years ago. We worked for maybe a year together in 2016, 2017. He posted a series of posts on LinkedIn about bridging ITIL and the boardroom, how to make ITIL more understandable and clear for the board members, for people in the executive roles. And he was very complimentary to ITIL 5, about ITIL 5, more than he was about the version that he was kind of involved in starting.

Richard: That’s interesting, yeah. Question about the contents of a new version: so you mentioned that continual improvement is something that is very strongly integrated into ITIL since the early beginnings. I guess

Roman: it’s one of the oldest models. Definitely, yes.

Richard: And you use it nowadays for the improvement of the practice guides, because the practice guides are currently improved and, I guess, slightly changed to fit to the new publications. But my question goes in another direction. If we go back in time, ITIL version 1 and version 2, I guess it was 14 processes, it was about IT processes, and …

Roman: yes

Richard: … how to run a data center and what to do. ITIL 4 brought up the idea of value streams, brought up the concept of thinking in practices and processes, and came up with a value chain and a service value system. So big difference, in my opinion, to ITIL version 3. And in ITIL version 5 we see kind of an organization around roles, because books are named like product, service, experience, strategy, transformation, what makes it easier for people to know which publication fits to me and my role. But what was the driving idea behind that shift, the roles or something else?

Roman: The answer is yes, but it’s probably, yes, it probably needs some details.

Richard: Let me add: was your value stream approach not sufficient?

Roman: No, I wouldn’t say so. In version 1, which you missed, like skipped in your description – and I would have probably done the same – but it’s just interesting, a flashback to my recent conversation with Ivor Macfarlane, who was involved in version … in ITIL before it was called ITIL.

Roman: And when he was describing this evolution in a similar way, he mentioned that version 1 was very functionally based, functionally focused. None of the books were actually called, let’s say, Incident Management; they were called Service Desk, they were about teams. And then processes were included to show that teams actually work, that the work flows across teams, that incident management involves multiple teams. You cannot limit your guidance to just isolated teams, it creates silos, and you need to show how the work flows across silos.

Roman: Then we realized that work actually works and flows across processes to support the lifecycle in version 3, and in version 4 to support what we call value streams. Because if you think, for instance, of fixing an incident: it involves – you can call them practices, processes, functions – but it involves service desk, monitoring, incident management, configuration management, very likely change, and if it involves change, it may involve then release, deployment, etc. So certainly we don’t fix incidents with just incident management; we involve multiple practices, or you can call them processes, and of course multiple teams.

Roman: So there are value streams, which involve activities from multiple formal disciplines, under any name. And that’s what we tried to show and provide guidance for in version 4.

Roman: In version 5 we didn’t change the focus significantly; we tried to present it better. So there are still value system and value streams, and practices contributing to value streams, and practices contributing to – like many to many – related to the activities in the value chain.

Roman: So architecturally, in that part version 4 and 5 are very similar, and generally version 5 is clearly an evolution of 4 rather than a completely new view on the world, but it brought in the product perspective, and the naming and the grouping of the content.

Roman: And here you are absolutely right, is addressed to people who are very likely to form a division, a discipline, a group of teams, a team of teams. So product or specialization in an organization: strategy, product, service, experience, and through all of them, transformation.

Roman: So it is not really a conceptual model, it’s more a practical one on how … we really wanted to be practical, yes. In the ideal world, I would prefer eventually product and service to merge, but yes, it’s not the case right now.

Richard: No, I don’t, I don’t agree really, because I think it is a decision that the company has to take, if it’s product focused or service focused. It’s just a decision. You have to take in mind a lot of, a lot of things in order to take that decision. You can sell a product, and upon the product you sell services, or you can sell a service and use products for it, and it can be, yes, quite the same thing that the customer gets, but a different experience.

Roman: Yes. It’s a way to describe it, and this is how we describe it now, because we just reflect what happened in the reality: organizations, yes, and teams identify as product or service, and very rarely as both. But the unified life cycle model that we introduced shows clearly that basically the life cycle of a value creating digital solution, whether it’s presented as a product or as a service, is the same, and these are two perspectives. They are Yin and Yang of the same solution and activities supporting the life of that solution that aims to create value based on technology for the customers.

Richard: I would really enjoy – and I really hope for it – that the market will respect this and really understand it, because I was very disappointed when I noticed that, to talk about another framework, IT4IT, that is a great framework, but it has, used to have a service backbone and talked about services in former days, and then changed completely to digital product and didn’t mention service at all. And yes, it’s just enough on ITIL 5 that it takes all the good ideas from IT4IT and has understood the ideas of that community, but brings it together with service. And talking about digital product and service management is, I think, the best thing we can do nowadays.

Roman: Let me, let me be clear here: we say that all digital products are consumed and experienced as a service. So it’s impossible to create value with a product until and unless it’s consumed as a service. And that works the other way too: it’s impossible to create and deliver a service which is not based on a digital product. So it’s two perspectives on the same solution, and ignoring one of them means artificially putting shorts or some obstacles to your holistic vision.

Richard: How did you, as an architecture team, decide which publications finally to create and which not? What was discussed and what was rejected?

Roman: You know, the need for the publications, for the, for the, for, yeah, for the publications that we created, it was pretty clear rather early. We knew we want to address the product service thing, so it was a matter of whether it will be one book on product and service, with, like, two sides or two parallel perspectives, or two separate books.

Roman: It was one of the latest decisions. We were working on one book together and then split it in the middle of writing, when it became clear that the difference is quite significant: that the same activities, let’s say build – for product organizations it is mostly about coding, creating software solutions; build for service organizations is more about integrating, taking existing solutions and infrastructure and putting something new together. So the process, the steps, the tools are similar; the further you go into details, the more the differences.

Roman: So it was probably one of the latest decisions. We had some back and forth discussions, and that took a number of review cycles and a number of discussion cycles to finalize the naming, in terms of the actual wording, whether it should be product management, product development, service management, service operation. So that activity about the thing: experience management, strategy management, or what. And we eventually – and I’m very pleased with not only the decision itself but also how it was perceived.

Roman: We removed that activity, because product book is about product discovery, product development, product management, product operations; it’s about managing product lifecycle. The service management is about also full lifecycle: service discovery, service development, service testing, service transition. So it covers them all. Strategy has two cycles, strategy development and strategy implementation. Transformation is about running a transformation, planning a transformation. So all the activities are inside; the books only show the subject. Yeah.

Richard: Yeah, I get the idea, and this is really, if you read the books you also will get the idea. And I think it’s a great thing that you just need to read some parts of the ITIL 5 Foundation book – not, you don’t have to read the whole book – to get the basics, to understand what all the upper level books have in common. And yeah, it all fits together. So this is the first time ever, I guess, since I know ITIL, that I see an architecture that really fits together and has no loose ends.

Roman: Well, I can, I can tell you why. In versions before version 4 there was no official foundation book. Every foundation publication was just an amalgamation, extract from core books that had been written before.

Roman: In version 4, version 4 was the very first version where we had a dedicated foundation book, which was supposed to provide an overall architecture for the following publications. The problem is that at the time of writing Foundation we didn’t finalize that full picture. We were describing the foundational concepts that we believe anyone who starts ITIL journey should know, but we couldn’t map them to what will be in the DSV, because we didn’t have a conceptual view on DSV at that point. With version 5, largely because it’s evolution, because the level of changes at the foundation book is relatively low – many concepts such as the four dimensions, the value system, they are there, the practices are there – so we took the existing architecture, we developed the architecture of the publications to follow. We knew what will be there, at least at a high enough level, and then we could put it into Foundation.

Roman: That’s why in Foundation you can find appendices that bridge the content of Foundation to the following books. Yeah. And to the people who don’t want to attend courses but just want to read a book – you can buy the books – exactly: in every upper level publication, at the beginning, you get that interesting stuff that is in the Foundation book as well. You don’t get the full content of the Foundation book, but you get everything you have to know to build on that.

Roman: There is another example, or another thing that made it easier. Some models emerged as we were working on the second level books in version 4, and I used to say that if I had an opportunity, I would have included them in the Foundation, but we developed them after. One example is the service journey from the Drive Stakeholder Value. Yeah, and now this is in the Foundation as one of the basic models, and then it also serves as a bridge to the Experience book.

Richard: In the very core of ITIL version 4 was the value chain and value stream management and value stream thinking in general, yes. And it is far better now in ITIL version 5, in my opinion, because – thank you – it really is a chain and not something, not a cube, different, or a cube, or whatever it was. It brings in the lifecycle approach again that we had in version three, enhances it to product and service life cycle, not only service life cycle, but uses a value chain activities. That’s very good, I guess. But my question is: why was a value stream approach from ITIL 4 not sufficient?

Roman: To an extent, because of the way the value chain was described. Because right now value stream, if you look at a value stream as a combination of activities from the value chain – so if your organization is focused on, its operating model is focused on managing digital products and services, then the eight activities from the value chain model that we have, that support the eight stages of the life cycle, can describe the main things your organization does as a service provider or a product vendor or both. We do discover, design, or selected activities, depending on what we decided to delegate, and you can describe a value stream as a combination of these activities supported by the respective practices. With the way activities were described in version 4, it’s very difficult to do this, because activities were double sided, two-worded. Yes. And you cannot say, „and this step of our value stream is design and transition, or operate and support,“ because in some cases it’s either operate or support, and the other part will not be part of this value stream. I get it, so that’s different granularity that made it work better.

Roman: We didn’t abandon the value stream, it’s still one of the core ideas. It’s just the architecture of value streams is clearer.

Richard: Yeah, for, I think, in other words, value streams have always been a great lens, but they didn’t tell you in version 4 who owns the experience.

Roman: That’s true, yes. That’s because it’s harder to use, yes. It would have been possible, but it wasn’t easy to understand. It was more cognitive heavy, and yes, it required more tailoring to start using it.

Richard: That’s true. Critics have always said that ITIL is too theoretical. Is that still true of ITIL version 5, if it ever was true, and if it’s not true, what changed?

Roman: It depends is the answer. We really wanted to make it practical and actionable, and I believe it is practical and actionable if you have certain level of authority. And different parts of ITIL are practical and actionable for different target audiences. So if I work in a service desk team and I read this strategy book, it will be very theoretical for me, and that applies to any strategy book, not only – not any business strategy book, not only ITIL strategy book – just because I don’t have authority for strategic decisions. It may help me in, I don’t know, personal strategy of some sort, but not any business strategy. If I work in service desk, then the service desk practice is potentially way more practical for me than this service strategy book.

Roman: So some parts of ITIL are addressed to different parts, different levels of organizations. Very roughly, we have the track for leaders, we have a track for managers, and we have a track for practitioners. Each of them is designed to be practical for the respective target audience. If you are consultant, then you combine all of them. Even with that, to be a reasonably universal, to stay technology agnostic, ITIL cannot go into the practicalities of setting up particular solutions or making specific organization level decisions, because we don’t know that specific. So it’s a practical guidance at all levels when it comes to supporting decision making. But this machine has no brain, you have to use your own.

Richard: It, we have AI, we don’t need our brains.

Roman: You can try. You can try, and we’re actually working on something like that. You can try getting your case, your scenario, saying, „according to ITIL, what would be the recommended course of action?“ And we are working on a solution like this based on some AI capabilities. Maybe it will work one day, it will probably compete with some basic consulting in a way. But ITIL is certainly designed to be useful, not just interesting.

Roman: There is also something new: that there is now one shared use case scenario across all the publications. It’s the same scenario you use, and it is also used in the exam. Yes, the exams for the upper levels, they are open book exams now. You get scenario and questions according to its scenario, you can use the publication, for you, I got, all publications you have in your library, to write an exam now. That’s quite a different experience, in my opinion. It’s a better experience, because I did the exams recently, and think it’s, that’s also quite practical.

Richard: Was it more a pedagogical decision or a content decision?

Roman: A bit of both, given this choice, more pedagogical. It was, it’s closely related to our ideas of how a good assessment should look like.

Roman: So in ITIL, those who know many versions of ITIL, they know that we tried – or ITIL authors, ITIL designers, architects tried – very different approaches to the exams. People who had experience of service management training for version 2: it’s a 2 weeks training with a 3 hours handwritten, assess style exam after each part. They really praise it, they think it was a real thing, it helped them, based on some, also on some long case, to express, to show their knowledge and their ability to apply it. Many people are really advocates of that approach.

Roman: Except, it’s hard to scale when it comes to writing, and when it comes, more importantly, to marking. It has very limited ability for internationalization, for translating, because you need – if you want to allow people to hand write something or to type something in their native language, you need to have qualified markers, who are people of limited availability and are very expensive, I presume, to process that amount. So it works for very exclusive things, but not for mass market.

Roman: Another attempt was made in version 3, in two ways. The capability exams used to be based on individual cases that were put in front of the every exam question. It was like half an hour – or, sorry, half a page – long scenario, and then a question, and then I have to choose. And because of the cognitive load and the time required to read it, each question could take 10, 15 minutes. That’s why we had only eight in each exam, which means that the cost of mistake was very high. You can miss one question because you misread something, and you lose your exam.

Roman: Then the next attempt was made with, for, with a practitioner. Practitioner is where we tried first time – not we, but the ITIL team that was working at that time – tried to introduce Bloom’s level 4 with very high cognitive load, based on rather big scenario. The problem is that scenario was very new to the users, it wasn’t taught to them in details in advance, and general description of that was a very good content, a very intimidating exam. That was more or less common feedback to that. We wanted to address and to find – to address it, and to find a way to examine people’s ability to apply the knowledge rather than just to memorize stuff, and at the same time make it accessible and keep it accessible.

Roman: So the solution was to make their exams open book and to make them based on the story that people will have an opportunity to learn really well before the exam. And logically, the same story with a little dedicated section, so we know the common background, but we have a one page long additional section which is relevant for each module. And if exam questions are based on that section, they are based – so, based on this scenario, they are based particularly on that section. So we don’t need to introduce a whole novel of that business case to everyone, a new one for every exam. We just had one page of new, relatively new content, but even that one is not that new, because it’s available in every book from the very beginning, you can study it in advance.

Richard: So we really tried, on one hand, to make exams less focused on memorization and more on application, so more practical, to make them, to keep them accessible, and to make them accessible, and to reduce the cognitive load of the scenario on the readers. That’s how it worked. And then, of course, it led us to a unified common scenario, and we were working on it across the books, and we used this again, we built on what we had built in ITIL 4. It’s very recognizable organization, slightly different names, slightly different nuances, but it’s more or less familiar organization to everyone who studied ITIL 4. That’s how it worked.

Roman: Roman, what can a practitioner do after reading ITIL version 5 what he couldn’t do after reading ITIL 4?

Roman: I think many things, depending on what, which, which books exactly. Pick one or two? No, I can easily pick four that we started with.

Roman: The practitioner will be better equipped for complexity, and it means that they will be able to make decisions in more uncertain situations, more better informed, less stressed, and generally better decisions. And then you can apply that to transformation, and in this case the execution patterns based on different complexity, the introduction of changes in situation where we don’t – we are not sure about planning, and more focus on experimentation. And even the continual improvement model changed to address the experimentation as alternative to just plan and implement. So, complexity.

Roman: Another thing, AI. They will be better equipped for dealing with AI, choosing what to use AI for, especially if you take into consideration the AI Governance Book, which is yet to be published this summer. But even if you just look at their already available white paper, then it equips you to make decisions of what you use and how you can use AI without losing control.

Roman: The Experience Book helps you to capture, measure and improve experience, and this is something that we lacked in version 4. That’s completely new material, and that helps you to ensure not only good user experience but also good employee experience in your team, or generally in your organization, depending on your level or your experience.

Roman: And finally, if that practitioner until now has been thinking of themselves as part of the product crowd or service crowd, they will learn how these two perspectives work together, which, ideally – and I hope – will help them to work more consistently, more holistically, and eventually better, because they will be less siloed, less isolated, less in the box.

Roman: So these are things that are really new compared to the previous version. And we haven’t updated the practices yet, so ask me that question in half a year, and there will be more.

Richard: Roman, you have spent years designing this framework. If ITIL version 5 works the way you intended, what will be different in organizations five years from now?

Roman: It would be great to see organizations where product and service management work really closely together, where these silos are finally broken or united, or you name it, but they work closely together. Organizations where AI, or whatever emerging technology will be emerging in five years, are adopted for the sake of bringing value rather than just riding the hype. And organizations where strategy is continuously adjusted, continuously adapted to the ever changing landscape. If we achieve this, and at least to some extent thanks to ITIL, I’ll be very happy about the influence of this version.

Richard: Yeah, then I’m really looking forward to see you again, 2031, in five years.

Roman: Okay, deal.

Richard: See if it happened. So, Roman, thank you very much for being here, thank you very much for answering my questions.

Roman: Richard, thank you very much for having me and for asking all the questions.

Richard: Thank you, and thank you for listening.

Roman: Thank you for listening.