It\u2019s about time we faced a reality that we conveniently ignore: we constantly and continuously hurt our IT Service Operations. Yes, it is through us \u2013 our actions or lack thereof \u2013 that make our service operations, and the service desk in particular, perform and look bad and be widely derided by our user community. It\u2019s time that we look at service operations in a very different light. \nLet\u2019s talk about fundamentals\nAs you know in ITIL parlance service operations is the lifecycle phase that ensures that IT services are delivered effectively and efficiently. This include fixing incidents (it\u2019s broken, fix it!), service requests (I want something, give it to me!) and problem (I really don\u2019t know why it broke. Let\u2019s investigate!). It also includes our functions which includes the service desk, application management and so on. It is said that it is in Service Operations that customers see \/ realize the value of a service. But when is this not the case?\nMany times, when customers and end user complain about a service not working or delivering to expectations the knee-jerk reaction of many IT leaders is to blame...the service desk! It is the service desk that\u2019s \u201cnot working well\u201d. It is the service desk that\u2019s \u201cnot executing the incident management process correctly\u201d. It is the service desk that\u2019s using bad tools and \u201cwe need a new one\u201d. You\u2019ve probably heard variations of this throughout your career or your department and the end result is always the same: let\u2019s bring in an outside consultant to \u2018assess\u2019 our processes and \/ or re-do our process documents. This probably happens every three or four years, maybe even less.\nWhat if I told you that some of the issues, many even, can be traced not to the service desk and the execution of the service operations processes, but to things that that the organization missed doing or did poorly? There are two very specific things that I\u2019d like to talk about here, which hopefully will shed some light on this issue.\nFirst off there\u2019s Service Design, whose objective is to design new services as well as changes and improvement to existing services. This may sound a bit simplistic, but it is not. If you don\u2019t design it correctly, how can you expect it to work correctly, let alone be supported capably by anyone! Many organizations out there don\u2019t \u201csweat out\u201d the design of a service enough to make it meet all of the requirements, which include operational requirements and organizational changes that go beyond backup and monitoring. You want to make sure that whoever ends up supporting it is able to do so without affecting day to day delivery of the service. \nOne of the problems, though, is that Service Design processes are often considered and executed in isolation and\/or in a very day-to-day operational perspective (e.g., availability management) as opposed to continuously checking the actual design (the blueprint) of the service against these issues. If you have opportune capacity or availability issues, for example, it is up to other processes to alert availability management and what should happen is for a service improvement initiative to be spun up to find out why it happen and then modify the design to ensure it doesn\u2019t again. Simple, right?\nThen there\u2019s Service Transition. One of the issues I\u2019ve seen regarding transition is that it is often considered and executed in piece meal fashion, particularly change management which often turns into a bureaucratic exercise in frustration and futility. Just like design, transition processes need to work together to provide better results. It\u2019s not just about passing a change or a project from point a to point b! One of the main outputs of this lifecycle, aside from a release or an approved change is information. There\u2019s information that goes into the configuration management database (CMDB), into one or multiple knowledge management databases, or into training information (because you do want the service desk and operations to be able to spot and handle errors detected in development, right?) that contributes and supports a clean transition.\nThere is no try\nDoing, or trying to do, these two lifecycles well will save a whole lot of pain for those involved in Service Operations. Note that I said \u2018well\u2019 and not \u2018good\u2019 or \u2018perfect\u2019. I am often the first to realize, as should you dear reader, that the pursuit of executing a \u2018perfect\u2019 process, at least as it relates to IT service management is utopia. What you can do is to understand that you should always pursue improvements, no matter how small. Once you understand what is required out of each lifecycle, you need to empower your resources to drive improvements throughout the entire service management system which includes the service itself, processes and people. \nThe second thing I would like to talk about is that some organizations spend too much time just literally transcribing processes from one place to another without actually sitting down and planning what a process should do, perform and behave against a service or services. \nDon\u2019t get me wrong: having documented processes is great, and it is a requirement sometimes if you\u2019re going to get audited. But think about this: several of the processes in the ITIL framework (and it\u2019s close cousin ISO\/IEC 20000 standard) have not really changed in years! You can probably close your eyes and recite the activities that occur during incident or change management quite easily! On the other hand, you and your organization change constantly to many things: the market, competition, new technologies and techniques, even people. So it is in your best interest to know how everything influences the execution of the process, not the process itself.\nGo look, for your own good\nSo if we go out and revisit our design and transition activities, and then on top of that start planning out our processes and all of the elements that support it, we can start becoming better at executing them and making them standard work something that will certainly make things easier during day to day work, or if you want to pursue something like DevOps.\nMany of these processes can fit in a couple of sheets of paper (yes, really!). Let\u2019s take incident management, for example. Unless your organization does something wildly different than every one else, the process is roughly the same: log, categorize, prioritize, try to resolve, escalate (if needed), resolve and close. Note that I am not going into the nuances of the process itself (what does first call resolution look like, when to escalate). This is because I would spend some time defining these elements outside of the process itself! Probably in a separate \u2018plan\u2019 document that is constantly reviewed and constantly updated by everyone in involved in the execution of the process.\nIt is the plans where we sweat out the details as to how the process will execute. This should include all of your status definition, rules, the tools you\u2019re going to use and the data they will collect, communication, training and automation rules! This last point is important because you want to have full control of the rules and mechanisms you\u2019re automating at all times. Having automation without rules or definition will probably add little value to the activities the process is supporting. \nLastly, you want these plans to be created and revised throughout the entire lifecycle. Isolating a process to its lifecycle because \u2018that\u2019s where it fits\u2019 is of absolutely no value to the organization. ITIL\u2019s strength lies in it being integrated and not isolated.\nStop the hurt\nSo there you have it: two things that you can start thinking about doing right away. Where to next? Here are a couple of tips:\nWhen was the last time you checked your Service Design Package (SDP)? Do you have one? As the SDP is one of the most important outputs of Service Design, you might want to spend time either tracking it down or checking the one you have. Make sure all elements of design were considered and if not, consider initiating an improvement initiative to fix any issues\nService transition is not just change management! If your other transition practices aren\u2019t up to snuff, all you\u2019re doing is approving and tracking requests. A good solid CMDB is crucial, as well as good knowledge tracking. (By the way, think that building a CMDB is hard? I do, too. But there are ways to make it through. I\u2019ll talk about it in a future post)\nStart thinking about planning over processes. You already have them, and you understand what they\u2019re supposed to do for you. Start looking critically at how. How will activities be supported? How will automation work? How will we classify information? These are vital elements that support the execution of any given process. You may already have these documented, just make sure everyone understands the \u2018how\u2019\nLastly, involve your service operations people. For all of the things you set out to do, bring your best people forward and that includes people down in the trenches getting their hands dirty fixing issues and dealing with customers every day. I know that the Service Desk, for example, is often looked as low skilled, repetitive work (I should know. At one point, I was there) that has nothing to contribute. I fully disagree. A truly empowered individual at the Service Desk is one of the most valuable resources that you can have in any service design or transition team. They deal with issues every day! They know what\u2019s happening down where value is being either created or destroyed. Their insight can provide elements of design and transition that other people in your organization may have missed.\nThese things will take time, and there is no silver bullet or quick technological solution for it. The best thing you and your organization can do is to go forward with a small, continuous improvement approach, along with the thought that failures will happen, but you can learn from them and emerge better on the other side.\nAfter all, Rome wasn\u2019t built in a day. Right?