- [David] Hello everyone and welcome back to the QA ITIL4 podcast. I'm joined once again by Paul Wigzell and Martin Waters. So today I was hoping to talk to you guys a bit about the guiding principles, which are kind of a fundamental part as far as I understand of ITIL4 and I was reading the manual and I see this chunky definition. So I was kind of hoping I'll read it out loud to you guys and then maybe you can explain it to me. 'Cause it doesn't make that much sense to me anyways. Not that it's not clear, it's well written, but you know, I'm just not that smart. So the key message here is a guiding principle is a recommendation that guides an organization in all circumstances. Regardless of changes in its goals, strategies, type of work or management structure. A guiding principle is universal and enduring. So maybe you could tell me a little bit more about what that means, Martin?

 

- [Martin] Yeah, sure, David. Good, you know, it's a definition. It's a bit dry, but I'll focus on that bit on the end really. They're enduring and they're applicable to really everyone and every person who's part of the organization. Because as ITIL has progressed over the years and obviously now in ITIL4 we just need to be so conscious that as much as, you know, management comes and goes, working practices can change quite badly Certain things always have to be like at our core of how we do our due every day in a world of really IT enabled business. And that's really where the guiding principles come in because the guiding principles really, exactly as it is in the label, they guide us. They're something that we can reflect to every day. They give us always an orientation point that sets every piece of work, every task that we do, and whether you're just a newly recruited apprentice fresh off the street or if you're the CEO, the most senior of the organization we see the nature of the guiding principles as applicable to every person, every part and facet of the organization. And through that, really, we can almost cope with organizational change and technological change probably within that. And yet still maintain the right equilibrium of really, the work is done well, it's done with a clarity to it. A quality aspect to it. And therefore that's how we often see these guiding principles. The background to them though is not new. ITIL when the practitioner guides came along in 2016, I think it was late 2015, the practitioner guides came along. In that guidance they framed, what at that point nine guiding principles. And alongside the ones we'll talk about here 'cause then they'll kind of distill them down to seven in ITIL4. That was where the initial promotion of in the ITIL framework was around the idea of guiding principles. And really what we've done in ITIL4 is kind of buffed that up a bit more. Yes, they've crunched down from nine to seven as we'll talk about through me and Paul. They design for experience and what we call the observed directly guiding principles have been folded into now part of the elements of the seven guiding principles as they're scoped now. But in respect of that nine to seven the practitioner guidance was all about trying to give, really kind of how, how do I go about doing ITIL to the general population of organizations. And right at the core of ITIL4 they've really decided now to bring that practitioner guidance in and even more focused on as part of like a cornerstone of how any org can orientate itself around ITIL4. So the seven that there are now, as we'll talk about is what we call focus on value, start where you are, progress iteratively with feedback, again that was then the previous set when it was nine, collaborate and promote visibiliy think and work holistically is another one. Keep it simple, practical, that's always a good one to talk about and as perhaps the one that maybe was not absolutely there in the practitioner guidance in ITIL previously was the one that we call optimize and automate. So, yeah, I mean we'll talk through these now in terms of looking at the facets of each of these. So if I can start with focus on value. Really what they mean by that in the ITIL4 guidance is really everything we do, whether it's, you know, a new service that we're starting to bring to life in an organization or how we manage existing services or products that we do on behalf of business. It really is almost like start with the customer in mind. You know, who is the recipient of these services. How is it in their eyes, they're gonna hopefully, you know, experience value, or receive value through the nature of that product, that service. And what's your part therefore as an individual to contributing towards that, how they're gonna actually receive the appropriate value. And, you know, focus on value is a guiding principle therefore means, whether I'm a strategic manager, a tactical or you know, operational person. We're all in that mix of, okay in ITIL4 we've talked about co-creating value with actual customers and users. And if we've always got that thinking point in our head about, "What does this ultimately mean. "What is the value of my activity?" Then, obviously, when we're not producing the right value and it becomes apparent from feedback. This is where it links into other guiding principles. Then at least we can be conscious of that and make sure we change our practices, change our work, you know, our ways of working such that we bring, you know, the service, the products back to the appropriate value that the customer needs. And therefore through that, all of us have got a part to play in adding almost like to the organizational success of the organization. So to me a focus on value is really, it has to be there ticking way at the back of every person's head really in the organization who's involved around service.

 

- [Paul] And I get to do one of the easiest ones I think 'cause one of the guiding principles I get to talk about is start where you are. Now I know that sounds really stupid. Start where you are, well where else would you start from? But actually it's amazing how few companies genuinely do that. Because they have this mind "Oh we want to do this, "let's aim for the stars, let's go, let's go, "let's get these new things, let's do this." And actually very rarely do we say "But let's just stop for a second "before we reach for the stars "what are we doing now? "What are we doing that works? "What are we doing that doesn't work?" We have to remember ITIL is a framework. It's just a framework of advice and guidance. It is about adapt and adopt. So let's look at what we're doing and start from that point and then get it better. Rather than just aiming for the stars and not having any kind of direction. Otherwise you're gonna end up like that Tesla car just heading out the Solar System and you've no idea quite where it's going 'cause no one's actually steering it. So it sounds really stupid at start where you are but I think it's so fundamental. I always say that from any organization, doesn't matter how small you are, how large you are, any sort of improvement, any sort of deliverable is like a journey and if you don't know where you're starting from how the heck do you actually set your destination because you can't plan your route if you don't know where you're starting from. So you need to think about where are we right now. And you can do that, yes you can bring in people who come in and do assessments for you but sometimes, and this is the bit that Martin was talking about, the nine being pulled and distilled into seven. Sometimes the easiest way to start where you are is just to observe what you're doing. So observe what you're actually doing somethings are gonna work, somethings aren't gonna work quite so well and that's our start point. And once we have our start point then we can start to build some cycles of improvement.

 

- [Martin] Leads us nicely to the next, kind of, guiding principle which is the idea of progressing iteratively with feedback. And as Paul was alluding to, often perhaps we do fall into that trap of aiming at the stars and not understanding where we're at right now. But in that idea often in quite large-scale programs of change and service, you know, products being changed within that really we almost try to take on the world and we try to really aim too high in terms almost trying to deliver too much in a cycle of change really. The whole nature of progress iteratively with feedback is to try and make things more manageable. Often staff get overwhelmed with very large-scale project deliverables. Well let's break that down. Let's break it down to smaller chunks of work that are far more easy for staff teams, not necessarily just individuals, but teams to manage. And the whole nature of progress iteratively with feedback is that after each almost like incremental piece of work that we do we then, you know, very actively seek feedback around that, you know, product, that output that we just achieved in a very almost like small manageable way and then by getting that feedback from the target you know, consumers of whatever that change was then we'll be able to adjust and encompass that into the next iteration. And obviously this is heavily promoted in the nature of a lot of working practices. This is very ITIL4 with a nature of the guiding principles around progress iteratively with feedback is taking due account of things like Agile and DevOps and almost like the philosophy of things like minimum viable product etc. That's often used in those kind of guidance. And thereby by doing that we almost kind of guarantee within degrees to keep more on track. It's not like we go away, try and please the world and deliver it six month later and then realize "Ooh, no, we got it wrong." Because we're gonna be in far more kind of timeboxed phase of delivering the changes. Will it be two weeks? Not necessarily true for every nature of a piece of task that needs to be undertaken but with the nature of progressing iteratively with the feedback particularly, that even when we get it wrong within a smaller manageable chunk we'll see that quicker and we'll be able to adjust that quicker and therefore deliver something even in large scale projects if we're using that guiding principle.

 

- [David] And just before we continue on I'm kind of fascinated by this. Is this a new, this principle, is it new specifically to ITIL4? Did it come along even with the guiding principles and that you mentioned earlier?

 

- [Martin] Yeah, I mean it was the idea progressing iteratively was there in the previous guidance within the ITIL practitioner guides that I alluded to back in 2015. But we just see as a whole industry the constancy of the growth of new working practices getting embedded in organizations. Particularly as part of digital transformations that obviously a huge theme in most organizations these days. Within that, the idea that things gotta be delivered quicker you know, the organization needs tangible changes quicker. But it's still to the right quality and therefore if we're using that always in our heads that iterative thinking point around how can I almost like make changed in more timely fashion. But very much with the intensity of still seeking the feedback then we're almost going to guarantee that we don't need to do massive kind of corrections to the tests that we do because we've got that constancy of we're delivering, okay, what you might call Agile speak, you know, minimum viable product or changes.

 

- [Paul] And also I just through in that this progressive, well, this progress iteratively, or certainly the word iteratively has been around in service management for many years. We always used to talk about William Edwards Deming and the Deming cycle of Plan, Do, Check and Act. So anybody who's done any sort of view or study of service management will see that the PDCA, the Plan, Do, Check, Act has always been within service management about exactly that. About plan a self improvement, do it, check to see where we are and then course correction, change of course or act to start the next iteration. So as Martin was saying, you know, depending on where you are in the world there's always the saying, "Don't eat the elephant all in one go." or "Don't eat the camel all in one go." If you eat it in small chunks, you're far more likely to complete the meal.

 

- [David] Yeah, I'm also just fascinated by thinking about, you know, we were talking earlier about the relationship between ITIL and of course Agile and all of these other things and everyone knows Agile has come out of obviously many IT enabled businesses. And I just think its really interesting that actually you can kind of think of ITIL or even IT enabled service management has been a driving force in, you know, that kind of way of working which has, you know, changed how business is done, you know, now in 2019 most business are functioning in that kind of a way or looking to anyway.

 

- [Martin] Absolutely, its only the large organizations that tend to still rely on the waterfall effects of waterfall project management, yeah.

 

- [David] Well let's keep going, sorry for segueing there briefly.

 

- [Martin] No not at all, because actually what you just been talking about links in very nicely because I'm gonna name it as the fourth guiding principle but it's worth knowing that although there are seven they don't come in any order you know its about seven, I'm literally fourth.

 

- [Paul] Yeah, and they're trying not to and you gotta try to understand they're trying not to call them rules because ITIL doesn't do rules its a framework of advice and guidance. Its about adapt and adopt. But in essence these are just guiding principles so no principle outweighs the other principle they're all coming in with equal value without trying to use that word again. But the next one would be to collaborate and promote visibility. One of the things that ITIL4 is quite keep upon is breaking down the silo. Is moving away from the silo-based organization and actually talking about let's work collaboratively, let's work as a group, let's share our experiences, let's share our knowledge, let's talk about the things that we've done well, let's talk about the things that we've haven't done well. I'm reminded of so many organizations that I've worked with or in where projects, at the end of every project you're required as a project manager to write a lessons learned report. And I can't tell you whether I've ever worked in an organization where at the start of a new project the first task for the project manager is to read the previously written lessons learned reports. So the only person ever really learnt their lesson was the team that was in that little project or the team that was doing that piece of work. We're talking here in service management now about collaborating and promoting that visibility. Talking about things we've done well, talking about things that we haven't done well. We're very quick in the IT world to find blame. "Oh it was their fault they didn't do the testing, "Oh, it was their fault they didn't implement it "quick enough or whatever." We're very bad certainly in Europe but certainly in Europe and the Middle East, we're very bad at promoting what we've done well. We're very bad at saying "That was done well, "good job, well done." And what ends up is that things that are done well are not talked about and things that are done badly are talked about and people are held to account or whatever. So we create this kind of, almost this silo of suspicion and distrust where we don't tell people what we've done and we don't say "Haven't I done well?" and we don't look for praise. Now that's not about saying that we've all got to walk around patting each other on the back but in essence what we're saying is "Let's work together." Let's work together as a team, and let's talk about what we're doing and why we're doing it and look at the aims and objectives and be clear and transparent about that because that will bring people on. That will empower people to work in a similar way.

 

- [David] It feels like we're going into mindfulness again. I absolutely love it. But yeah that is, yeah, I think it is important to promote a, generally, a culture of more you know, positivity and encouraging people and acknowledging good work and also being able to stand up for yourself as an individual and say "This was good work." or "This wasn't" and to acknowledge it and try to let take those lessons on.

 

- [Martin] Exactly, or even the cultural element here of almost having a working culture where it's allowed, trust really, that we can say when we've got things wrong and not see that as individual weakness but then by creating visibility of that with others then surely it prevents the same mistakes, failures occurring again. So there is almost like a, these all lead into really good culture, good service culture to the organization is really the nature of these guiding principles is promoting a lot of that. Which actually I suppose does take us into the next guiding principle 'cause there's a huge amount interplay really between all these as Paul said. Which is the next one, is think and work holistically. And a bit like in one of the previous podcasts we talked about we're all part of a system we might be doing the small part, a small cog that becomes this large, engages with the other cogs that make the engine of the service organization. But think and work holistically is often about understanding of that understanding your place in the greater scheme and that often we have to work with a lot of specialisms these days and we can't all, surely with the nature of IT modern business, we can't specialize in everything. Nevermind in an individual, but in the same team. So therefore we have to work with lots of other specialisms. And the whole idea, you know, really think and work holistically is understanding of that and as you do your task your work you're very much, you know, engaged in and understanding how that impacts upon and needs to be coordinated with many and other team who's got their own distinct specialisms. Very much linking back to the first principle that we talked about 'cause focus of value is ultimately, if we're all part of that system and there's one part that doesn't really understand its contribution to the other parts then the danger is we lose sight of all to what matters to the end customers, the end users, the end consumers. So those who know a bit of their history of ITIL this actually does have its origins really, this think and work holistically almost in some of the practice that we quoted in V3 when we talked about the four P's of service design. And think about the people, the processes and, yes, the products and the partners. 'Cause that's very much a, I think holistically principle a one area impact on the other areas well very much that philosophy now, it's very much come in here and was there in the previous ITIL practitioner guidance this was there as a guiding principle. But see again its even more promoted in the ITIL4 guidance. And if we're doing that alongside the previous one where we said collaborate and promote visibility 'cause to get that almost like systemic view we're gonna have to do more communications, more openness, then we're gonna ensure that the end outputs, the end outcomes, perhaps I should say to the services are sound, are correct.

 

- [David] It seems to me that as you guys talk more about these principles you start to understand how they all have to work together. You can't do one, but when you are working within these, you know, framework of these principles really they're all kind of together promoting a, kind of, best practice really. That's really what it's about.

 

- [Paul] Absolutely, and that's exactly what it is. So, you know, we've already touched on, the focus on the value, start where you are, progress iteratively with feedback, collaborate and promote visibility, think and work holistically. Oh these are wonderful ideas but what we don't want to do is move to the point where we're actually trying to do something really small but now we've gotta think holistically, we've gotta make, and it becomes bigger and bigger and bigger. Because the next guiding principle is really simplistic in every sense of the word. It's keep it simple. You know we've all talked about, and I'm sure in the past you've talked about the KISS principle, you know, Keep It Simple Stupid. But in essence that what we're talking about. What Martin mentioned earlier on about the minimum viable product. What's the minimal thing we need to do? What's the basics it's got to do? That's our start point because it's got to do that before anything else it's got to do that. So when we're starting to talk about the guiding principles one of the first points we've got to talk about is what's the basic outcome, what's the outcome that the consumer or the customer or the user, or even the service provider is going to get. Because that's the minimum viable product. Anything above that is great but that's what we gotta do. So let's not over-complicate it. So one of our guiding principles is keep it simple and practical. Don't over-complicate it. Don't complicate it for the sake of complicating it. Just look at what you need to do, what's the basics and then the bells and the whistles and nice to haves afterwards but it's gotta do what it needs to do. It's a bit like having a mobile phone, your mobile phone, oh it's brilliant, it connects to the internet, oh great it can control my heating at home. Yeah but does it actually make a phone call? And I do appreciate that I am old and therefore I do still use my mobile phone to make phone calls but in essence for me that's what it's gotta do. We talk about regression testing whenever we're talking about delivering new products and, you know, being able to go back and do what the previous version did. When we're talking about keeping it simple and practical what's the minimum viable thing it needs to do and then everything else is a bonus.

 

- [David] Well it seems like it's also a way to help you avoid kind of that sense of paralysis really where if I'm a worker, I'm doing my thing, then the next thing I'm trying to understand the entire system and how every single part of what I'm doing fits into everything else while I should strive to do that I shouldn't let that at the same time, you know, stop me from actually delivering the service. The service should be simple and easy to use for the end user.

 

- [Paul] And the very basics, you know, you can't put the roof on until you've built the walls. And you can't build the walls until you've built the foundation. And it's breaking it down into those small iterative steps that we can do.

 

- [Martin] I think also on top of that it's almost by the keeping it simple and practical guiding principle hopefully again, we're back to culture really. It promotes staff in terms of if they're seeing perhaps an overly procedure where they're seeing activity, steps that are meaningless, they're not helpful in terms of the ultimate activity output they're trying to achieve, well then, hopefully they keep it simple and practical promotes this idea that we can challenge that in a positive way and say "Well let's make this procedure simpler." And I'm sure anything simple is obviously gonna engage with other teams better and they're gonna be able to understand a bit and follow a bit and therefore we're back to being more unified in terms of how we achieve our outputs, our outcomes. And again I think some orgs almost like rest on their laurels because they see certain established procedures, practices etc. are just the way they are. And yet they're overly complex without enough value to them. So well let's challenge that. But in a way that is, you know, not there to score points off of the staff of the parts of the org it's there because there's meaningfulness to all of us by challenging that and making the practices, the processes, whatever, simpler. And simple is good.

 

- [Paul] And the real example of that for real life things is in the old days you wrote a check. And then you wrote a check, you had to have your bankcard to prove that you were that person. So we had a fairly complex system. So then they produce a card that you can put into a machine and you can put a pin code into it. Now you've got contactless. It's just making it more simple.

 

- [David] I do like contactless. Although it is a very easy way to spend way more money.

 

- [Paul] You can spend a lot more money than you otherwise would have done. Well I'll redigress. I think, are those all the principles?

 

- [Martin] No, we've got one more to talk about.

 

- [Paul] We have one more. Excellent, let's get through it.

 

- [Martin] We've talked about six of them, and okay, again the last one but again emphasis there's no order here is the guiding principle that we call optimize and automate. And as we've said with several of these is there's a lot of interplay with some of the previous ones that we've talked about. But I suppose this is the one that wasn't as, well it certainly wasn't as formally there as much in the ITIL practitioner guides as it now is in ITIL4 guidance about this idea that as we progress as a services world in any kind of organization we need to be conscious of almost, do we apply the human resources to the best effects of the organization. And yeah, just talking about process, even if we simplify a process, a practice in ITIL4 speak and then get humans to do those tasks in that process, that practice then there should be a question point about is it ultimately the right use of that human resource. Can we not use automation to literally almost like take the strain to some degree off staff, still produce the right qualitative outputs by using automation and let's face it, automation done well should produce those outputs quicker than typically any human could. But that doesn't mean to say that we're getting rid of the staff, we're then applying those staff, you know, where they can add value through their expertise typically. You know, they can do better analysis into better You know, packages of work really without having to do slavish, really often quite mind-numbing tasks. And that's why we see a lot of the automation potential coming in. But before we automate we've obviously got to optimize existing workflows. So ITIL's not just saying automation for automation's sake. And I think maybe that's a trap that some services orgs fall into. But we're saying let's optimize what we've got, our working practices, our whole what well call the service value system in ITIL4 is very much means that kinda optimal optimization principle around it. But where relevant, yeah, let's put the automation in. And we shouldn't be afraid of that. Cause ultimately it should achieve and speed us towards achieving a lot more quicker but still high quality outcomes to the organization through the services that we're managing.

 

- [David] I saw you nodding away there, Paul when Martin mentioned the optimization for, sorry, not optimization--

 

- [All] Automation.

 

- [Paul] Automation for the sake of automation's sake, yes. There are sometimes when you think "Really? "Really, was that easier?" Not sure.

 

- [David] So we've all experienced systems like that before.

 

- [Paul] Booking an airline ticket comes to mind, but we'll move on.

 

- [Martin] Yeah, we'll move on.

 

- [David] No companies mentioned. Yeah, this has been a really fascinating discussion and I think, you know, when you look at that one statement at right at the beginning of this Podcast actually just how deep ITIL4 is, but at the same time I think it is actually simple to understand, it's not rocket science. It's actually been created in a way that is accessible and that is there to help people at all levels of any organization to kind of have that focus on taking demands and creating value.

 

- [Paul] Absolutely, even if you're working in rocket science.

 

- [David] Even if you are working in rocket science.

 

- [Martin] I think, by following the guiding principles in ITIL4 really, you could almost publish them, print them out, put them all walls, put them on whatever login prompts when people login in because they're so, you know, they do apply universally. And, you know, I know often these principles behind the guiding principles are very in the back of our heads but sometimes we just need to bring them more round to mean put more promotion round them and that's what ITIL4's doing here. We're shining a light on "Let's promote these." And constantly promote them. And by doing that, guess what? We'll become an even more value-oriented, focused organization, and therefore succeed.

 

- [David] Fantastic. I think we're gonna wrap this one up at that point. So thank you Martin, thank you Paul for joining me today. And I look forward to our next conversation.