Virtual Event Recap: Understanding ITIL

In early October, Ivanti hosted its first ever virtual event: The IT Leadership Summit. There were a total of 30 presenters, including Forrester analysts, product marketing managers, director-level IT professionals, and executives.

Below is the video and transcript from the session Understanding ITIL.

Hello everyone, and welcome to my presentation. I'm Chuck Spencer, Enterprise Service Management Practice Lead at Flycast Partners, and today we're going to talk about understanding the ITIL service lifecycle. What I hope to give you is a practical guide to using the service lifecycle approach. Now, I'm guessing that a lot of you are attending this session, because you've got questions like the ones shown here. You're trying to understand exactly what is this thing called the ITIL service lifecycle, and how can it help you and your organization better manage the IT services and be successful.

And then, how do you ever implement all of this, you know, how do you learn more, and where can you turn to, to get help, so that you can not only inform your boss, but the organization and help them to improve. Hopefully, by the end of this session, you'll have found an answer to most of these questions. Now, I'm not really sure I can help you with the last one, but perhaps just understanding the challenges before you, and how you might address some of those, might make life just a little bit more meaningful for you.

Let's start by answering the first question, what exactly is the ITIL service management lifecycle? Well, the ITIL service management lifecycle is an approach to service management, it's not the only approach, it was never meant to be, but it does offer best practices in the form of concepts, processes, and tools that can be adopted and adapted, to help you improve your organization's service management capabilities. And that's what it's all about, improving your service management capabilities, which includes the way that you use processes, the way that you use your people, the way that you use technology, to actually deliver services to your customers and your users.

Now, the ITIL service lifecycle consists of five stages, service strategy, service design, service transition, service operations, and continual service improvement, and each stage emphasizes the importance of coordination and control of the functions. And when we talk about functions here, we're talking about teams, or support groups, or organizations like your service desk, but also the importance and coordination of those functions with the processes they perform, and the systems that you use, and all of the things that you need to manage the full lifecycle of IT services. Now, each stage is actually a book within the ITIL library that provides a wealth of information on best practices used within that area.

And the information contained in these books provides a structure of how the processes, the people, the technology, and your partners, can be connected to help you effectively, and efficiently deliver services. Now, I stress the word "can" here, because ITIL is not a standard, it simply tells you what can be done, based on what others have done successfully. And I also want to stress that while the best practices and concepts in these books focus on IT, they were actually drawn from a broader perspective of service management, and can be and have been used to manage services other than IT.

Now, each stage of the lifecycle serves a specific purpose, service strategy is a stage where we define the strategy that, we as a service provider need to follow, to allow the business to achieve the business outcomes that are part of their strategy. And that includes determining at a high level what type of services we need to provide, who the users will be, what capabilities do we as an organization need to develop to be able to provide those services. Again, thinking of processes, and tools, and technology, and our people. Now, how will we fund all of this?

And then in service design, we begin to realize that strategy, by designing not just the services, but also the processes and the functions needed to realize that strategy. And then, service transition is where we build and we test the services, and start to deploy them into the environments. Again, not just the services, but the processes and the tools, everything you need to deliver, manage, and support those services. And then the service operations stage is where we strive to efficiently and effectively deliver, maintain, and support all of the services that we moved into production.

And then finally, continual service improvement is the stage where we monitor, measure our performance in delivering those services, and make sure that the services continually align to the business needs, as those needs change and we all know they change. Now in all, there are 26 processes within the ITIL service lifecycle, and I'll give you a minute to soak that in. Twenty six processes, wow. Not [inaudible 00:04:48] the four functions that are shown here, that's a lot for any organization to take on. And for each one of these processes, there are policies, goals and objectives, roles and responsibilities, metrics, procedures and workflow that have to be defined.

And of course, all of this has to be documented, the organization trained and governance established, and not to mention, we have to select tools and technology to help us manage all of this. And that all brings us back to one of the original questions, how do we implement this beast? How do we put all of this in place? Well, let me tell you a secret, you don't implement ITIL, that may sound strange, but you don't implement ITIL. As defined in the dictionary, to implement is to carry out or to accomplish, or to give practical effect to and ensure actual fulfillment by concrete measures.

Well, for most of us carrying out and accomplishing the 26 processes defined in ITIL is just not a practical approach or a right place to start, and given that it's a framework of best practices and not a standard, how do you even ensure that you've actually fulfilled these by concrete measures? So, what do you do? Well, if you take nothing else away from this presentation today but this concept, then I've done my job. I mean let's face it, if you were starting from a clean sheet of paper, you had no services, no organization in place, no processes, then you could start by developing your strategy, designing your services, your support organizations, and your processes.

Build and test these, then start delivering and supporting services, but I'm willing to bet that none of you are in that position, and while it may look like it's a serial exercise, and you work your way from strategy, to design, to transition, to operations, and then start to continually improve, that's not the intent at all. In fact, if you look at the ITIL books, you will find the phrase "adopt and adapt" throughout the library, it's a core concept of the ITIL service lifecycle approach. So, you don't implement, you adopt and adapt, and that's going to be the message of what we talk about here today.

Now, let's use a simple analogy to take this a bit further. Now think of building or buying your home, you know, some of you may have been in a position where you had the ability to make a clean start. You selected a plot of land, you worked with an architect, or a designer to come up with a plan for your home, and you build it from the ground up, that's a great way to start if that's where you are. You can define your strategy, gather your requirements, design everything from a clean sheet of paper, take your time inspecting and testing, and then when everything is ready, you go live or you move in.

But, again, I'm betting that few of you in this room are in that position. You've taken a role or been placed in a role, where there are already services in place. You have an organization that needs to be managed, customers that need to be answered to, and fires that have to be put out. So, your world looks a lot more like this, you've got a fixer-upper. So do the same things you would do if you were buying a fixer-upper. You do an assessment, or an evaluation to determine the condition of your home, and then you begin to upgrade and repair as needed to make that home meet your needs.

You start by fixing the bare necessities, you get a roof over your head to protect you from the storms that happen every day. And then, you think about what you want your home to look like in six months, in a year, in five years from now, and you look at your finances, how much can you afford to do now, and how much can you put off. And of course, the question again is, how does the ITIL service lifecycle fit into this, and how can it help, when we're not talking about your home, but we're talking about your service management capabilities. So, to answer that question, let's take apart the service lifecycle, and instead of talking about the specific processes in each stage, all 26 of them, let's talk about what happens in each stage, what are the activities, what are we trying to accomplish.

Now, in the service strategy stage, we've got some processes listed here, and some of these processes might look completely foreign to you, and you're not even sure what exactly what they mean, so how do you know if that's a process you need to put in place, without really doing a lot more study about them? But, if you look at what's really happening here within service strategy, you know, I mentioned some of it earlier, we're determining who are our customers, who are our users going to be, and then what services do those customers and users need to enable them to meet the business outcomes that they're trying to meet.

And then, to deliver those services, what capabilities do we have to develop within our organization to be able to deliver those services? What skills and experience do our people have to have? What tools, what technology then we need to use? What kind of processes do we need to have in place? What kind of management architectures need to be there? And then, for all of that, how are we going to fund it? Where are we gonna get the money from? You're trying to work that out in service strategy. And then how will the customer really determine value from this? What do they perceive as value?

What really allows them to create value? Because that's what it's really all about, it's all about the business being able to create value from the services that we provide. So, you know, how are they going to look at that, and what value are they trying to generate, and how will the services help them create and determine that value? And then, how will we even manage that relationship with the business? How will we keep abreast of what their strategy is, and what their tactical goals, and their operational goals are, so that we can make sure that we align? And as part of this, of course, as part of our strategy, we're also setting our overall policies and our objectives as an organization for IT service management.

And then, when we look at service design, and again, a lot of processes that are here that, you know, maybe just from the name of them, something you recognize, but some of them, you know, maybe you look at them and you're not sure, do we need to worry about that process or not. So, again, let's talk about what's being done here. As I said earlier, this is where we're trying to realize the strategy. We're going to capture and document our requirements now for those services, and the strategy we kind of identified at a high level, what those services need to be.

Here we're actually going out and working with the business to capture and document what are their requirements, and then we're going to define and document services to meet those requirements. As part of that, we're going to design efficient, and cost effective services, but again not just the services, the processes, the policies, everything that's needed to actually manage and support those services. As part of our service strategy, we may have worked out when we were talking about our capabilities, of what capabilities do we need to develop, and what capabilities we will use third parties or providers for, or SaaS services, or cloud services, those kinds of things.

So, here in design, we're gonna now identify exactly which suppliers we're going to use, and how we're gonna manage those suppliers and begin to manage them, and we'll get them to help us in doing these designs. And as part of service design, we're also creating our security plans, our availability, our capacity, and our continuity plans. And while it may seem strange to you, that you're doing this as part of service design, you need to design these things into the services, or they're not gonna be there when you're trying to deliver those services later. So, this is where you really start to develop and create those plans.

Service transition, again, a lot of processes here, you know, a lot to kind of get your arms around and understand, but again, let's look at what we're doing. In service transition, we're trying to implement those new services for the design package or for the requirements that we put together back in service design, and build them to those designs. We wanna build, we wanna test, we wanna deploy our services into the environments, and then eventually, of course into the production environment itself.

Now, as we're doing that, you know, we've got existing services that we continue to have changes come and we need to do, and so we're gonna plan and manage those changes as part of the processes that are done in service transition. And in doing all of that, of course, we're trying to manage any risk to the business because we know that every time we do a change, we're introducing the possibility that something could break, or we can break something else, so we need to manage that risk. And as we're moving these services through the different stages, we're gonna start to acquire a lot of knowledge about how this service performs, and how the components that make it up perform, and how those components even integrate into the service, and are used by the service.

So, we wanna start to acquire all of that knowledge, so that later we can provide it, when it's needed by people, to understand more about the service. And of course, service transition is all about making sure that we really obtain the value that was defined back in the strategy, that we defined our service…or designed our services to deliver, and now as we transition those in, that we're actually able to achieve that business value. Service operation, the processes here are ones that you're probably a lot more familiar with, processes like incident management and service request fulfillment, and event and problem management, all things that you probably hear a little bit more about.

And then, also within this phase, as we mentioned earlier, all the functions, you know, your service desk, your different technology application support groups. A lot of what's here is probably a lot more familiar to you, but again, let's look at what we're doing here. This is where we're really trying to deliver services to the users that are authorized to have those services. And as we're doing it, we're always trying to do that within the agreed on service levels, and we're trying to optimize costs and quality, as we do this, reduce our cost, increase our quality. And as part of that, we're trying to minimize service outages. Service outages are going to occur, you can't absolutely, 100% prevent them from happening.

So, whenever they do, the processes that are here are really involved in making sure that we've got good workarounds in place, and we've got good ways of getting things up and going, by we solve the root cause of the problem. So, some of the processes in here are really addressing that. You know, these processes are the processes that your customers are going...and your users are gonna interact with the most. So, this is where we're constantly trying to build and maintain a high level of user satisfaction, and the way that we perform these processes, and the way that we communicate with our users and our customers, and our professionalism in doing all of this.

And also, as part of this, you know, we're going to be relying on our application or our technology groups and their skills, and so we're always trying to build their skills and their experience, and then leverage that as we're trying to do all of the things we need to do to monitor and manage the infrastructure and deliver these services. And of course, the ultimate goal here is to really enable the business outcomes, enable those things to be achieved that they're trying to achieve by using these services. And then, the last stage of the lifecycle is our continual service improvement stage, where we only have one process here, the seven step improvement process, but it's a significant process, because this is where we're really trying to become more effective and more efficient at the way that we deliver the service.

And then, again, make sure that we constantly adapt to the changing business needs, and we're aware of what they're changing, and getting our services out there ahead of that, so that they're available when they need them. So, now that you can see the whole picture of what's occurring during each stage of the lifecycle, let me ask you a question, are you not already doing most of these things? Have you not already answered the questions and strategy, and done the activities that are shown there? And maybe you haven't actually implemented a formal service catalog as shown in service design, but you have some list of your services somewhere, and you designed services, and created policies, and identified, and are currently managing suppliers, some of the things that are shown within these activities here.

You know, you're probably doing some level of planning for security, and availability, and capacity, and continuity management. And, again, you may not have very formal documents in place that explain these, but there's no doubt that you're doing that in some way. And then maybe you don't call it a service design package as they do in ITIL, but I'm willing to bet that as you design and roll out your services, you've got some form of a vehicle for capturing and communicating the requirements, and capturing what was designed, and what your test plans, and your test results are, all of those things.

And of course, if you have services, you must have built and tested these, you've done some level of risk management, and started to collect knowledge about those services. And then, finally, if your delivering services, well, you're managing service outages, you're managing incidents, you're trying to minimize the impact in the business when those occur, and you're trying to build and maintain user satisfaction. And just the fact that you're here tells me that you're attempting to become more efficient and effective, and make sure that you can keep up with business needs.

So, again, now that you see all the activity here, let me ask you that question, is your organization not already doing or have done most of the activities shown here? If you are, then you're engaged in service management, and I'm betting that you are. So back to my initial statement, you don't implement the ITIL service lifecycle, you adopt and you adapt. You look at the things you're currently doing, focus on what you might not be doing as well as you need to… You know, what does your fixer-upper really look like, compare it to the best practices, and the concepts, and the processes that are shown in ITIL, and then identify what you need to fix the most, what you can afford to fix, from both a time and a money standpoint, and then you start to make things better.

And so, you don't start from strategy, you start from where the pain is, and you start to adapt and adopt the best practices that are contained in this lifecycle to help you solve that pain. Now, when you're doing this, it may be well to remember that a particular process or area that you're struggling with may not be where the real problem or the root cause lies. It may well be that the output from another process is actually where the breakdown exists. You know, there's a saying we have in Texas, "If the water tastes bad, the dead cow is probably upstream." I guess, that may not be a Texas saying, I kind of made it up, but it proves the point here.

If you're having trouble achieving service targets and operations, the problem may not be in the incident management process itself, but in the design of the service, the way that it was tested during transition, the processes and methods that are used to deliver and support that service. So, it's important that you understand what the inputs and the outputs of each process are, and how they could impact other processes within the lifecycle. And this might also help you in determining exactly where you need to look for, for the best practices and concepts that you may need to adopt and adapt. Again, it may not be specifically the process that you see failing, it may be something upstream from that process, is where the real issue is.

Now, one of the key concepts of the ITIL service lifecycle is the Deming model for plan, do, check, act, and this really speaks to the approach of adopt and adapt that we've been talking about. You know, under this approach, you establish a baseline where you are now, and then plan what you need to do to improve, and do it, and check the results, to ensure that you achieve your goals, and then based on those findings you take action to move closer to the outcome you need, and then you baseline again and repeat that cycle. And you do this in short repeating cycles so that you can maintain momentum, and over time, raise the maturity level of your services and your processes.

Now after all, you didn't get in the situation you're in overnight, and you're not going to improve it overnight, it needs to be a consistent, steady approach, to achieve the outcomes that both you and the business really need. Now, what's talked about within the ITIL books is a CSI or a continual service improve approach, and since, you know, what we've been talking about here for…really is the fact that you have services or what you're really doing is trying to improve those services. So, the approach that's shown here is one I use with a lot of organizations when we go in to help them work through what they need to do, and it begins with understanding what's the vision, you know, what's the business vision, what's the business mission, what's the goals and objectives that they have.

Once I understand what that vision is, now I can start to create a business vision, a mission, and some goals, and objectives for the IT organization, of what they need to be able to do to help the business achieve their vision, their mission, their goals, and objectives, and as part of that, one of the things we want to look at are what are the critical success factors? What do we have to do as an IT organization to allow the business to succeed and do what they need to do? And then from that, I wanna look at, where are we now? How well are we doing now against those critical success factors, and from that I'm gonna perform...I'm gonna create a baseline assessment. I'm gonna establish a baseline that I can start to improve on, and I can go back to, to see how much improvement I've made.

The next step is to determine where do we wanna be, and here I want those measurable targets. Again, what do I need my home to look like to be able to move into it? What do I want it to look like 30 days from now? What do I want it to look like 60 days from now? What do I want it to look like a year from now? And so those measurable targets need to be in the form of key performance indicators. What must we measure to show progress towards the achievement of that critical success factor? Once we've done that, now we can start to talk about how do we get there, you know, and what service or process improvement plans do we have to put in place? What do we need improve, and how do we need to improve that?

And then, once we put those in place, we need to be constantly looking back at our metrics to see, did we get there yet, are those key performance indicators taking us in the right direction? If not, what do we need to do to start moving us in the right direction? And then the way that we keep the momentum going with this is the plan, do, check, act cycle, of keeping all of this in short iterative cycles, so that we're always going back and looking at, you know, what's the vision, where are we now, where do we wanna be, how do we get there, did we get there, what do we need to do next. And then, we're starting over again, because we all know that that business vision, their mission, their goals, and their objectives, change, and we need to change ours over time.

And our critical success factors are going to change, as the business changes, and that's going to change our key performance indicators. So, all of this is a very repetitive cycle that we have to constantly engage in, to make sure that we are, as the name implies, continually improving our services. Now, what I'm gonna share with you here is a common approach to adopting ITIL processes, and keep in mind that in some cases, you may already have elements of some of the processes I'm going to talk about here in place. So what you're looking to do is, how can you adopt and adapt best practices, to really bring those up to the next level, to where it's appropriate for you to start now looking at what can I do next, or what's the next level I can take.

And of course, we're doing this, again, in those short, little cycles. So usually, most organizations start out in somewhat a reactive mode, they're trying to keep the rain out of the roof, they're trying to keep the storm from taking everything down, so they're doing things... Well, they have processes of doing for incident management, they're handling service requests, they're probably doing some level of problem management, although it's probably just reactive at this point, which means, you know, I'm looking at problems when an incident tells me I've got something I need to go fix. You're probably doing change management, you're doing some level of understanding what assets you actually have out there, and have some inventories of those. It may not be in your ITSM tool, it may be spreadsheets, but you're doing some of this, and you're starting to get some knowledge about all of this.

What I wanted... What you wanna be doing is looking at, you know, where are you having issues here with these, what's not working quite as well as it should, and then turning to ITIL and to service lifecycle, to see how you can improve this particular area, by applying some of the best practices and the concepts that are there, and ramping up your ability to perform these functions that are here. Hopefully, at some point you'll move to the point where you've gotten through that reactive mode, and you're ready to start looking at becoming more proactive. And so, the processes that we would typically look towards here to help us become more proactive, our transition planning and support, that process that helps us make sure that as we're transitioning things, all the activities that need to be done are actually done.

And now, we're gonna take those service assets that we maybe just have some inventory about, and we've, you know, hopefully, started to move into our ITSM tool at this point, and we start...we wanna start to add some relationship information to those, so that we turn it really into now service asset and configuration management, where we now know when we do a change, you know, what's being impacted upstream and downstream of that change, so we know what else might be involved. And then, there are processes like release and deployment, where we can now start to look at how we actually take a release through those different stages of a transition, through the different environments that we have, to really get us to where we can move it into production, and how do we do that, and how do we manage that somewhat better.

Now, I would offer that to do either service asset and configuration management, or at least management, you do have to have some good level of change management in place before you can even consider even doing these, so all of this kind of works together here. Service level management, this is the point where we're starting to get proactive, where, you know, back as we were at incident management and request management, we should have been tracking how fast can we resolve incidents, how fast can we respond. So, now we're at the point where we can go out to our customers, and start to negotiate some service levels to them, because we've got some data to work with now.

We can say, historically, this is the service level we're able to meet. you know, we need to meet a better service level, then we need to talk about what we need to improve and how much it's gonna cost to make those improvements, to decide whether or not we could…to ramp up that service level, or what we're going to need to ramp up that service level. Problem management, here I'm starting to look at becoming more proactive, I'm analyzing some of that information I have now from incident management, looking at some trends, to talk about, you know, what could we be doing to head off these incidents before they occur by identifying and solving these root causes. And I'm doing release and deployment, and I'm tracking my releases, and as part of that I'm tracking bugs.

I can now start to open problems [inaudible 00:27:12] from those bugs, so that I know, when they occur, you know, what the workaround for them is, and how to get around them, which also feeds into knowledge management. Event management, this is where I'm now looking at the different things that are happening within my infrastructure and the way I'm monitoring those, and hopefully being able to automate some response to those events, so that I'm actually proactively resolving that event, resolving that issue before my customer or my users even see that incident, and are affected by it at all. So, again, I'm more proactive when I look at those kind of processes. To go a little bit farther now and become more customer focused, I wanna look at processes like capacity and availability management, and make sure that I'm planning for the capacity and availability they're going to need going forward, and that those are all part of my plans.

And to do that, I've got to have good business relationship management in place, I've got to be in tune with what they're doing, and so this BRM process really helps me do that. And so that might be a process I'd look to the service lifecycle for some information about how to perform this better. You know, at this point we, you know, we may wanna, if we haven't already developed a service catalog, really look at developing a good, strong service catalog that we can offer to the customer, so they can order services from that catalog, and know what to expect in terms of the services they're going to get, what makes up those services, what the service levels are, all of that.

To become more customer focused, you know, we're spending the customers' money and with these suppliers, so we need to now look at doing, perhaps, a better job of supplier management, making sure that we're getting the right level of value from these suppliers, and there are things within the service lifecycle and the processes, and concepts around supplier management that will help us in doing that. And then, financial management, this may be the point where we wanna start to look at now and understanding more about what does it really cost us to deliver these services and support these services, so we can take that to the next level now.

And in business focus, you know, we'll start to talk about, you know, is it appropriate for us to maybe do some chargeback on these, to help control demand for those services a little bit better, and then also looking at this point of, you know, how do we make sure that we have an IT continuity plan that really aligns with the business continuity plan, so we're again, we're really focused on what the business is doing, and what the business would need to do if they have some sort of a disaster or a disruption that forces them to invoke their plan. And then, finally, becoming value focused is all about making sure that our service portfolio is totally in tune with the business strategy, that we know where they're going, we're working with them ahead of time to make sure that we're starting to get our services in our pipeline and starting to work with those.

And we're also making sure that our strategy is very well aligned with their strategy, and that we're lockstep with where they're heading, so that we can make sure our services are there. So, again, this is a way of looking at what processes and how to move yourself up that maturity level ladder a little bit in implementing your processes. You may have some of these in place already, and this may just give you an idea of what you need to do to move to the next level. And certainly, this is not a definitive plan, it's just an approach that can be used to help you really look at improving your service level maturity.

Now there are some guiding principles that were released as part of the ITIL practitioner documents, books, and courses that were set out back in 2015 by Axelos once they took over ITIL. I actually think this is one of the better things to come out of ITIL in years, and I hope that there's a lot more like this in version 4, when it comes out, and we really expect it to be. But, just looking at the principles they have here, I think you can apply these and really help you with what you're trying to do to apply the lifecycle. The first one here is keep it simple. You know, when you're designing or improving your processes, use the minimal number of steps that are really necessary to get the results or the outcome that you need.

And then, once you have those in place, now, then take it to the next level, and move on up, now this is where adopt and adapt really comes into play. You know, just because something is a step in a best practice approach, it doesn't mean that it's right for your organization at the level of process maturity that you're currently at. If it doesn't produce a valuable outcome, then ask yourself, why are you doing it right now? Maybe you can set this aside and work on something else, and then later come back to this, and implement it, when it really provides more value to you. Next, here is collaborate. The more people that you have involved in your improvement efforts, or your adopt and adapt efforts, whatever you want to call this or even if you want to call it your implementation effort, then the more the amount of information you're going to get is going to increase, and the better able you're going to be to make the right decision, not to mention the fact that you're going to get more effective buy-in of what's being done, and what needs to be done, and it also just kind of raises the awareness of why you need to do things, and really starts to speak into organizational change management, which we'll talk more about in a few moments here.

Now, along with this comes transparency. People need to know what's happening, why it's happening, what the expected outcome or result is going to be, and then the success or failure of that effort, when it occurs. And if you do fail, you need to make sure that you're turning that failure into a learning experience, and that as you go forward, you're gaining from that. You wanna observe directly, and this is a key concept, it's also a key concept within lean and Lean Six Sigma, you know, it speaks to the fact that the closer you can get to the work being done, the more likely you are to identify information that will you allow you to make better decisions and manage things better.

You're not gonna be able to adopt and adapt ITIL from a glass tower. You've got to get down with the people who are doing it, and understand what they're going through, and really help them adopt and adapt this by having a good understanding of where they are and what issues they face. You do wanna progress iteratively, and this goes back to the concept of plan, do, check, act, and the entire continual service improvement approach that we talked about earlier. You wanna keep the improvement efforts organized into short cycles, with specific targets that are smart, and hopefully, we all know what smart are, these are targets that are specific, they're measurable, they're achievable, they're realistic, and they're timely.

And then, we wanna focus on value. I often hear IT organizations say, "We have to create value." And I sometimes argue with them that that's not the role of IT. IT should enable the business to create value. Everything that we as a service provider do should be targeted at enabling the business to achieve the value, the outcomes that they need to be successful. And then design for experience, and here we're talking about the customer or the user experience. Design your services and your processes around what the customer will experience when they're using those services or interacting with the processes. What are their preferences? You know, how do they want to request and use the services? What are their expectations when there's a service incident? You know, what are their expectations when they go to your service board level, what they're gonna see, and how they're gonna interact?

You know, what communications or information do they need? You know, be cognizant of all those things and design everything around what your customers and your users are going to experience. Next, start where you are. You know, as we've been talking about throughout this presentation, you most likely have processes and services that are in place. So, identify what's working and then build off of that. Don't just throw everything out and reinvent the wheel. And if what you have is completely unusable, then still don't just start from scratch, look at best practices, and then adopt and adapt those to really meet your needs.

And then, finally, no process of service exists in a vacuum. Every process in the lifecycle has inputs and outputs to other processes, and every service relies on other services. So, you always have to consider that bigger picture, and make sure that as you're doing something, you're not hurting something else than what you're doing. Now, I can't understate the need for organizational change management as part of any effort like this. Improving your organization's capabilities for service management involves changing the way the organization works, the services they use, the way they use them, the way that you as an IT organizations deliver and support those services. And many continual service improvement or ITIL efforts fail to achieve the desired results simply because they fail to address the people side of these changes. You know, people generally don't like to change, and the benefits must be explained to them to…so that everyone throws in their support, and to ensure that they break out of the old habits and embrace the new way of doing business, and this involves effective organizational change management.

That means creating a vision of what the organization is going to look like after the change, having strong and effective sponsorship to lead the organization through the changes. You have to have well-defined roles and responsibilities, not just for who is going to do what during this change, but also who's going to do what after the change is in place. And then stakeholder management, you need to have, to ensure that the impact of the change that reach stakeholder group is understood and then it's effectively communicated using a well-planned communication strategy and plan. And then, it means empowering the people to make that change, like giving them not just the responsibility, but also the authority that they need to do that.

And also giving them the skills, and the experience, and the tools, and the resources they need to make that change. And it means planning ahead for any resistance to the change, so that when that happens and it will happen, it can be dealt with immediately and effectively, and get it out of the way. And then, most important, celebrating the successes that you achieve through these continual service improvement efforts, in a way that both recognizes the past efforts, because oftentimes you're asking people to be...to give up something that they were part of creating. And so, you know, recognize how valuable that was in its time, but also recognize why there's a need to change it now, and why it's important, and then again celebrating that, and getting things to move on.

So, let's go back to our original questions, and why you were here, you know, what is the ITIL service lifecycle? Hopefully, we've explained that and you've got a better picture of what it really involves. You know, it's more than just an icon, there's actually a methodology, a framework behind it that's based on ITIL and you've got a little bit of idea of what that's all about. Hopefully, you've seen a little bit of how this can help your organization be more successful, again by adopting and adapting the best practices that are here, where they can help your organization. And also, I want at this point encourage you to… As I said earlier, this is not the only framework, there are other frameworks like lean, and agile, and DevOps, and all of those things that are meant to play with the ITIL service lifecycle and the processes that are within ITIL, and really help you in implementing those.

You know, how do you implement the beast, where you don't take it all at one time, you don't try to chew it and take it all down? You try to adopt and adapt it in pieces, and take the things that really help your organization, and implement those. You know, how do you make your boss think you really know about this stuff? Well, as I said, these... What's behind this lifecycle is contained in the five books of the ITIL library, and so get your hands on those books, and start to read them and understand them, or get people who read and understand them to come in and help with your organization. And now, what's the true meaning of life? Well, I only promised I was gonna do four out of five, so I don't know that we answered that one, but, hopefully, we helped you a little bit with, again, understanding, you know, what you need to do and what your challenges are, and how you might face those challenges.

Now, I do have just some parting thoughts here that I wanna share with you. You know, if you think about the fable that's out there, the parable about the blind men looking at an elephant, and you know, each one of them sees that elephant from a different perspective based on their experience with that. Well, if you think about all of the different emerging frameworks that are out there, and the technologies that are out there, and the other methodologies that are out there, like the ones I mentioned, like, lean, and agile, and DevOps, and some of the new and emerging technologies that are being talked about, perhaps, at this conference and in other conferences, to me, all of those are still talking about the same thing, they're still talking about service management, and it's just they're taking their twist on it, based on, you know, how they're seeing it or how it infects their view of it, and their view of the world, but the processes that they're all talking about and the processes that they're all implementing are the processes that are in the ITIL service lifecycle. They're just often giving you a different priority for those, and a different way of looking at those, but it's still all at the core is all of the processes that are in ITIL are part of that. You know, that's my view on this, and kinda my parting thoughts to you, to think about as you're doing this.

Again, it's not the only framework, it may not even be the best framework, but it's the one that's most widely used, the most successful, and it really allows you to then take your view of it from your viewpoint, and apply what you need to apply, to an adopt and adapt for your organization. So, I hope this conversation has been very useful for you today, and I'll be certainly glad to... If you have questions on this, you can certainly submit those to the team here, and we'll get those answers out to you, and I wish you good luck.