Common mistakes organizations do when implementing ITIL
Implementing an IT Service Management (ITSM) program based on the ITIL processes adds value, governance, and standardization to an enterprise organization. The ability to turn chaos and exceptions into standardized outcomes is appealing. ITSM programs are built by implementing processes and an ITSM tool according to an agreed-upon roadmap. This roadmap should incorporate an appetite for organizational change, processes to be implemented, training, metrics and reporting, and leadership support.
While most ITIL implementations are successful overall, each will have successes and shortcomings. Most organizations struggle in the implementation in one of two ways: Either lacking leadership support OR trying to implement too much too fast. There are many other reasons ITIL implementations fail, but they usually roll up into one of these two categories.
Without organizational and leadership support, the ITSM program will fail. Adding a structured and standardized process for resolving Incidents needs support from all leaders. If one or more groups do not report their Incidents, there is no way to understand all the outages business stakeholders experience. The same goes for Change Management. If there is not a consistent manner that new Changes are assessed, approved, and scheduled, outages will continue to occur. Change Management needs leadership support to ensure all Changes pass through the same process, with no exceptions. Implementing these two processes offer value to the organization but cannot be successful unless all parties abide by the same rules. Contention usually arises when an organization looks for an agreement on a policy before implementing the process. Policy adherence is tied to performance goals and even employment tenure or termination. This is where the proverbial rubber meets the road. It is one thing to give verbal support to the implementation and another to possibly lose a top performer because they are not following the newly-implemented ITSM process. Every leader will have reasons not to support the initiative, but the solidarity of leadership is essential for success.
Attempting to implement too many processes too quickly is a pitfall that many organizations have fallen victim. The initial roadmap must consider the organization’s appetite for change. This roadmap should also include ITSM tool implementation and enhancements. Each new process creates change for the organization. Each new process is a new way of doing things and every organization can only go through so much change at any one time. To best avoid this potential pitfall, it is recommended that the roadmap begins with a tool implementation and three processes, at the very most. The three most common processes to begin the ITSM journey are Incident Management, Change Management, and Request Fulfillment.
When we look at these two potential pitfalls in tandem, the impact is huge. Each new process needs advocates, process managers, process analysts, training, and metrics. So, imagine trying to implement ten processes and needing the above resources for each. That would be painful. Let’s look at each of these resources in a little more depth:
- Advocates – Each process must have advocates to succeed. These advocates include members from all levels of the organization and include an executive sponsor, change agents, and a support organization. Also, advocates are needed in the business areas. Collaboration with business stakeholders is required for success.
- Process Owners, Managers, and Users – Every process needs an accountable party (a Process Owner) and several people to execute the process. The Process Manager is responsible for carrying out the process on a day-to-day basis and there are several others that log Incidents, submit Changes, for example. This group, and the one above, represent the “people” aspect (of People, Process, and Technology) needed.
- Training – Every role in a RACI (Responsible, Accountable, Consult, and Inform) need to be trained for every process so they can execute their specific role.
- Metrics – Part of every process design needs to include metrics and ways to measure the health and maturity of the process.
If an organization attempts to implement too many processes at once, it will struggle with too much change, too few people resources, too much new training for personnel to consume at a given time, and immature metrics to separate which processes are doing well and which are not since the outputs of one process or the inputs of another.
Lastly, the goal of each process is to become standardized and repeatable, gaining maturity over time. If an organization implements too many processes at once, all are immature at the same time. It is difficult to mature (and measure maturity improvements) concurrently. Conversely, if the processes are implemented in a phased manner, resources may be concentrated to mature each from design to implementation to measurement to improvement.