One of the biggest challenges with adopting IT Service management best practices is to really get the processes working in practice. You are likely to get lost in theory if you do not approach this task with a clear plan of what you are going to do and how you are going to do it. Perhaps the comparison is unfair to both the elephant and the Incident management process; however, I still think that what you need to do is to slice the elephant, um-complicate things. Simply starting to chew on one leg will not do you any good. I have a very pragmatical approach that I would like to pass on to you. However, before we even get started I need to tell you one very important thing.
Adopting ITSM best practices without an initial snapshot, a baseline assessment, is like getting into the car, start driving, without knowing where you are going.
So, once again, do not skip this step, please read some of my previous posts, for example Knowing yourself is the beginning of all wisdom about performing the fundamental baseline assessment.
Now, let us get down to business. I thought I might use a very popular example, the Incident Management (IM) process. In short, I will tell you an extremely pragmatical way for how you could adopt ITIL Incident Management to manage your IT support, or improve the process if you are already using it. These steps serve as a checklist.
- Set the objectives with the adoption of IM, define what you are trying to achieve. This should be very concrete and I always recommend dividing the objectives over time, setting time frames with reachable goals to serve as the overall direction for the adoption of the IM process. This should be related to versions of the process, for example the first version should be 1.0 and so on.
- Sorry for the reminders but it cannot be stressed too much, first you start with doing a baseline assessment of your ways of working with support. Establish a good enough overview of the 4 P´s (People, process, products and partners) to get a clear picture of your current state, your unique set of pre-conditions for establishing, or improving, Incident Management.
- Compare the assessment result with your objectives to get the overall GAPs between where you are today and where you want to be, for some of you this rings the CSI model bell, and this is exactly it, we need to set the direction before getting in the car.
- Now it is time to plan your project, I really recommend executing needed activities coordinated since everything is related and there are many dependencies. I always turn all major parts of what needs to be done into deliverables, to simplify planning and make it easier for everyone to understand what we are doing. Your team should include the people that will work operative in the IM process but also people with good knowledge about the current ways of working. Also, remember, you should work offline; I call this the process greenhouse, to not disturb ongoing operations, only when we are ready for process deployment this process will go live.
- I always start in workshop mode, starting with level 1, the macro-level, process flow. Including relevant people from the organization. I recommend using paper and post-its to keep things interactive, letting people move around steps, decisions and play with the process. As soon as the level one process is done, we continue to the second and, only if needed, the third. From time to time in the workshop check back with the GAPs and focus, areas to make sure you are on the right track. At the end of 2-3 days, you have your own IM process flow, congrats. However, there is a lot of work still left.
- Most parts of the process flow needs explanations, guidelines, rules/policy and there are other more detailed parts of the full process package. For IM there are two very important deliverables, the categorization (including support for functional escalation) and the prioritization matrix. All the deliverables needed will be very clear to you when going thought the process flow. All these deliverables can be produced in small work groups or in workshops. Most of these deliverables is simply documents, think of it as the process package, with controlled documentation that are base for later stages in the process implementation. You also define a couple of KPIs (Key Performance Indicators) and make sure that there is a documented way of how these are collected and calculated.
- At this point, we also need to get technical. You have to adapt or possibly even procure the/a toolset to support your process. For IM this normally involves entering the organization based on your support teams, the categorization (with reference to the support teams), the prioritization and potential other changes/customization.
- Only now you should start with the detailed/operational documentation such as support scripts, the process work instructions, guidelines, FAQs and other practical things. This since you should include tool screenshots, sections from documents and such. This also goes for the training material. At the same time we can set the exact time for go live, it is time to really prepare for the IM 1.0 rollout.
- Assuming a one site roll out the preparations normally includes communicating to relevant parties, setting the date, planning for the training sessions, the follow-up session (do not forget that) and much more. I always try to convince my clients to also include a process party, do a small event, include a process cake, some champagne or likewise. We need to celebrate this but even more important, we need to show the world that something happened. The preparations also includes preparing a hands-on process training, including the toolset close to the go-live.
- The day finally arrived, time to deploy IM 1.0. The training of all relevant parties are either already performed or will be performed today, the deployment and the training sessions needs to be close to each other to keep things relevant. We invite all stakeholders and some other random people to celebrate this awesome event with us, toast and do some story telling from the project, already making this something that people will remember. It is all about showing people what we are doing and celebrating when our efforts pays off.
In a few weeks, the first follow-up will be performed and all training material are available on the corporate Intranet, there is perhaps even an IM Wiki or an IM section in the IT Wiki. Soon no one will have to read the process documents anymore, only the new people working in the process. The process KPIs are reported frequently and there are already a few improvement suggestions. The future is so bright, you gotto wear shades.