The first day I attended on an ITIL formation, the teacher told us: “ITIL is suitable for all sizes and types of companies, the secret is to know how adapt it.” But the more I understood the ITIL philosophy, the more I thought that it was designed for big sized organizations. Only in managers and coordinators, you can count more than 30 people. So how can it be adapted to small sized organizations?
In this post I will cover the mayor adaptations of the ITIL framework to IT departments of less of 20 people.
Does it worth to apply ITIL on small organizations?
Definitively yes. Small organizations tend by nature to bad practices like the next ones:
- Non-documented, non-repeatable processes: “If why are only two people who do this task, and we both know how to do it, Why do we need to document it?”. I heard this sentences during a software quality development consulting provided to a small company. People in small companies tend to not document, because of a lot of reasons: “It’s a waste of time”, “No one will read it”, “Why they want me to document the process? To replace me?”.
- Generation of super-heroes: It is easy that at some time one employee would be in possession of a very valuable knowledge or experience in some particular technological field. Everything regarding this technology needs this person. And also this employee itself dictated rules as: “I’m the only one who can touch this!”. I faced situations where the administrator password of one server was only known by this super-hero.
- Experts are managers: The normal trend of this kind of companies is that the best you are technologically, the higher you are at the management chain. It is a fact that good specialist is not necessary a synonym of good manager.
- Existence of the super-manager: Normally there is one pseudo-CIO that is accountable of all processes and directly manages everything. It controls internal software development, incident management, problem management, etc. And also, it could be the super-admin of everything, that is the specialist that comes in help of every employee in troubles.
- IT isolation: I know the case of one company where the IT department door had a sign saying: “MORDOR! Elves forbidden”. This was just a funny reflect of the isolation of IT.
This situation is not desirable at all, and planning an ITIL implementation can be a way to deploy a structured way of working. Next chapters of this post are some advises to plan or modify ITIL framework to better adapt it to small sized organizations.
Prioritize on some processes
Small sized organizations don’t have enough man-power to take care of a correct implementation of all ITIL processes. You need to prioritize on those processes that provided a quicker and clearer ROI. That means to focus on transition and operation phases of the service life-cycle. Under my opinion the most important processes for a small sized organization are (in order of importance):
- Incident Management: It is the best process to start with. The implementation cost is low, and the quick wins are clear at a very early stage.
- Configuration Management: Not under a complex CMDB, but a simply list of assets, just to know what we have.
- Change Management: The most important fact is to define a CAB an approve changes on a predefined set of assets. The objectives: to control and document changes on the most important CI’s.
- Problem Management: This is the most difficult part (talking from experience). To isolate problem management from incident management is not easy in small organizations.
- Release Management (in case of software development): Once you have your support organized, it’s time to organize the software development.
At this point you must consider if other processes are suitable to be implemented.
Dedicated resources for incident management
This is, under my point of view, one of the key factors in a good ITIL deployment on small organizations. The nature of the organization tends to share resources between activities. People are normally organized by technologies, and there is a lack of general layers. The first step is to define a set of dedicated resources with only one attribution: Incident Management. This will be the first layer of support. It could be only two or three people, but there must be at least one. I talk of incident management under an ITIL v2 point of view, where standard changes, service requests and security access are managed insider the Incident Management Process.
Then you can organize the rest of specialists in second or third layers. Almost all IT employees will be located on incident management, but the important fact is that the most valuable resources of your organization are freed from this task on most of cases, placing them on high level layers.
One important decision is to define the incident coordinator. A common mistake is to select an specialist or high level IT manager to this position. The incident coordinator must have exclusive dedication to incident management. So my recommendation is to choose one of the dedicated resources. Choose the one with the better management attributes. He will be accountable of incident resolution and to report the KPI’s of the process.
Problem Vs Incident
When deploying the problem management process is easy to copy the structure of incident management and assign the same people the same tasks. That means that the incident coordinator would be also the problem coordinator, and the layers would be placed equally. That’s an error. Problem and Incident Management processes have different objectives, and it is easy that the shared coordinator will forget the objectives of incident management, trying to pursue the problem management ones. So, my recommendation is to choose a different person to coordinate the problem resolution. And here my recommendation is to choose one of the high level specialists. Not the best one, but the one with better management aptitudes.
Now, the incident manager will be the best impulsion for the problem management, demanding documentation of known errors, creating problems, etc.
Sharing of knowledge
Focus on one objective: Kill the super-hero. As soon as you realize that a super-hero has appeared in your organization, you must kill him. Of course I’m not talking of physically killing people, but to force the transfer of knowledge to other members of your team. The best way to achieve it is through Incident and Problem Management. The main idea is that this super-admin or super-developer is forced by both processes to document the knowledge.
Conclusion
There are some best practices that a service manager must follow in order to control its “little” team:
- Avoid the dependence on super-heroes.
- Share the management over your team, focusing on the best management aptitudes, and not the technically better.
- Document, and implement processes that force that documentation.
Pingback: Applying ITIL on Small Sized Organizations | The Remedy for IT | ITIL Foundation Training