Branimir Valentic In my previous blog post Considerations before ITIL implementation we discussed some of the important issues you need to resolve before the implementation starts. If you have taken care of those, then the next step is to start implementation. And that’s when the headache starts.
First things first
There are many reasons why is it important to start your implementation in the right way. Here are a few examples:
- The first few steps that you make will create an opinion about the implementation project. Negative feelings about the project will decrease support and acceptance.
- Waste of resources – starting in the wrong direction usually causes a loss of money. Take, for example, human resources that you use for implementation – you can always express them in monetary value, particularly for external ones (e.g., consultants that are hired on the project)
- Credibility – your results build your credibility in both ways, positive as well as negative. Here, I mean both your credibility inside your organization as well as inside your own team.
So, yes – it’s very important to start in the right way. You can find a lot of resources (You might say – debates) about ITIL implementation. But, you are the most critical factor. Why? It’s simple. You know your situation (i.e., motivation and trigger for implementation), your organization, your people, etc. Namely, the ITIL framework is wide and covers many aspects of IT. Therefore, you should find what is most important for you and your organization, and the issues you are trying to solve. By-the-book implementations are the road to bureaucracy, which is, I assume, not your goal.
There you go
So, you have the OK from your management; you know where you are and where you want to be. I would say that you are really ready to start implementation. That’s usually the point when questions start to arise: What now? What should be done first?…etc.
Although every situation is its own story, there are a few points that are advisable to most of the implementation projects. I will elaborate on them briefly.
Figure: Efficient start of the implementation is essential.
Start smart – It sounds very general, but let me explain the opposite situation (which I don’t recommend). You created a list of the processes and functions that need to be implemented, and you start to implement them in sequence according to your own preference. Such implementations usually never end. Take the opposite approach. For example, create a To-do list with the complete scope of the implementation (all processes, i.e., functions). Assign priority to each one. Consider carefully which ones can be combined and implemented together (e.g., if you need to implement both, Change Management (CM) as well as Service Asset and Configuration Management (SACM), there is no point in implementing CM and then few month later SACM). But, be cautious. You can’t expect to be able to implement all (or many) of the processes, i.e., functions in the scope in parallel. Go step by step and combine when it is necessary (like I mentioned for CM and SACM).
Quick wins – these are the goals that can be achieved quickly and “easily.” Detect quick wins and do them first. In such a way you will gain credibility and your project will defend the reasoning for implementation. In this way you will get much more “space” for the rest of the implementation. Pressure will be lower and, since it will be obvious that you deliver results, you won’t be under a magnifying glass. When providing quick wins, it usually happens that you are left to do your work, meaning that you can completely focus on the project. For example, your organization pays penalties because incidents are not resolved in the time defined by Service Level Agreement (SLA). By implementing Incident Management, you will gain control of your incidents and save money.
Project approach – I already mentioned “project” several times. From my experience, ITIL implementations have all the features of a project (time, resources, goals, deliverables, costs, etc.) and there is no reason not to treat it that way. Quite the contrary, compared to ITIL, Project Management is much “older”; i.e., there are enough reliable project management methodologies that can be your powerful tool to bring the implementation to success.
Control and steer – Independent of scope, ITIL implementation is tricky. It goes deep into operating processes and influences the way people do their jobs, i.e., the way the organization works. Therefore, you have to be very careful and keep your steering wheel firmly in your hands. One of the tools you can use is measurement. Measure before you start the implementation and afterwards. Compare the results and you will know whether you are on the right track. Return on Investment (ROI) is another one. I already mentioned incidents that are not resolved within the target time (i.e., time defined by SLA). When you succeed in Incident Management implementation and achieve incident resolution within the target time, it will be easy to calculate ROI for that process (direct benefits are savings in penalties that are not paid, an intangible benefit is organization’s reputation in the eye of their customer, etc.).
Keep it Simple and Straightforward
Size of the organization, organization’s culture and setup, management, your own team, complexity of business and processes… there are many parameters that can influence and increase complexity of the implementation. On the other side, those parameters are quite often taken as an excuse.
There is a principle that can be used to explain approach to the ITIL implementation: KISS – Keep It Simple and Straightforward. Business life is complicated already, it shouldn’t get worse and topics which implementation covers should be addressed directly. There is enough know-how about ITIL and implementation. Use that know-how, take what is relevant to you and avoid unnecessary complexity. And, get started.
Check our free Virtual Consultant to help you with beginning your ITIL implementation.
