After organizations decide to implement service management utilizing the Information Technology Infrastructure Library (ITIL), they seldom know where to begin. Chances are, they’ve done their homework and generally understand the responsibilities for each of the 10 Service Support and Service Delivery processes. It’s likely they’ve also completed a process maturity assessment indicating where their trouble spots are and the amount of work that needs to be done.

But starting the evolution for any IT organization can be a real challenge, especially for a consultant who is hired to implement ITIL for a client. Here are four criteria that my company evaluated before choosing where to start.

Assess available resources
Our IT senior management team had decided that we would simultaneously work on three ITIL processes—Incident Management, Change Management, and Service Level Management—to improve our Service Management. The goal of IT Service Management is to ensure that IT services are aligned with client needs, improve the overall quality of IT, and reduce IT’s long-term cost.

Like most IT departments, we didn’t have “extra” resources to use for special projects like these. But, we did recognize that there would be more strain on the organization in the future if we did not make an effort to improve our processes. We would certainly feel short-term pain from taking people away from their regular assignments to work on the Service Management projects. However, this pales in comparison to the potential cost of not working on these projects, which could potentially mean losing staff.

We formed three 8- to 12-member teams, representing a cross-section of the entire IT organization, and asked them to develop project plans, including the amount of time needed to work on their assigned processes. The management team did not impose a deadline for implementation; rather, it allowed the teams to determine how much work was involved and how much time they required for the tasks. The expectation was that each team would be able to implement its process improvements within six to eight months.

Each team was responsible for submitting its project plans for final approval. The management team reviewed the various project plans for these projects, as well as all of the other projects on which the organization was working.

In some critical areas like the Help Desk, the management team brought in temporary employees who filled in for some of the positions vacated by those who were assigned to project teams. For some project teams, IT management limited the number of working days that the project team would be dedicated to the Service Management project so that disruption to normal operations would be minimized.

Review the ITIL framework
The ITIL framework is a building block of sorts. Although the Service Support and Service Delivery processes are intertwined and interrelated, some of the processes can be viewed as building blocks for others.

When offering advice on where to start, carefully evaluate the current state of the IT organization. For example, you’ll probably find that the assessment score for Problem Management—using the assessment tools that are part of ITIL—will not be higher than Incident Management’s. That’s because Problem Management depends on solid Incident Management, so you can’t have the former without the latter.

A similar comparison may be made between Change Management and Configuration Management. Beginning with Configuration Management before Change Management is probably not a wise decision. Once an inventory is taken of all assets, it quickly becomes obsolete, because there is no consistent, repeatable way to track changes to it.

My company decided that our Incident Management process needed some more refinement. Our process was best described as somewhere between “defined” and “controlled,” based on the maturity assessment that we completed. Adding the fact that Incident Management is really a gateway to Problem Management meant that selecting Incident Management was an easy decision. (Always consider Incident Management as the first place to start.)

Score quick wins
Recognizing that Incident Management was very close to being in a “controlled” state according to the maturity assessment model, we also determined that implementing the ITIL standards for Incident Management could be a good choice for the IT organization.

As part of our overall ITIL implementation, we determined that achieving some “quick wins” was critical to the execution of our project. We needed to ensure that the IT staff would be willing to support our efforts to transform into a best-practice, process-driven shop. The staff needed to be able to see, for themselves, the benefits of adopting the ITIL framework. And the work needed to be timely so that the staff did not lose enthusiasm or momentum.

Our Incident Management project team worked for about six months re-designing the process that manages incidents logged by the IT Service Desk by comparing our organization to best practice. A good Incident Management process makes a distinction between closing an incident in the tracking system and resolving the incident to the satisfaction of the client, which we didn’t recognize until the team redesigned the process. During the time that they were redesigning, they sought input from all of the IT staff and shared information every step of the way by posting process flow diagrams and offering question-and-answer sessions.

Since we implemented our Incident Management process, our IT shop has paid closer attention to managing the incidents reported through the Service Desk. Everyone was retrained in resolving incidents, and our clients are receiving better IT support services through our adherence to new response and resolution times, not to mention that the IT organization can take pride in the fact that it has successfully implemented a process to ITIL standards.

The greatest client impact
Obviously, improvements to response and resolution times have a positive impact on our clients. My company decided that the focus on Incident Management was not enough and began a second project to improve Change Management at the same time. Good change management can decrease the time it takes to implement a change—such as replacing an aging application or piece of infrastructure—as well as minimize the adverse impacts of changes made to the production environment. Both of these potential results should have a noticeable and positive impact on the delivery of IT service to clients.

Our process maturity assessment—the evaluation of how the quality and effectiveness of our processes relate to operations and support—indicated that our Change Management process actually needed more help than our Incident Management process. Our organization lacked a high-level understanding of the change process and performed activities on an as-needed basis. In contrast, the assessment showed that our organization demonstrated commitment to the Incident Management process, even if all of its activities were not formalized.

Therefore, the Change Management process did not score as high as Incident Management in the assessment. We believed, and the assessment proved, that we had what could be termed as “pockets of excellence” in Change Management—teams that were performing appropriate Change Management activities within the organization—but we lacked a consistent, repeatable change process that everyone followed. In other words, some areas within the IT organization implemented changes well, while other areas needed more guidance.

By improving the overall Change Management process, our organization would be able to measure, consistently, the result of changes to the production environment. And, we could finally prove to our clients that we could successfully deliver changes that they requested without also breaking something else.

Implementation of the Change Management process has also improved communication among IT teams, which has led to a greater understanding of the potential impact on our clients if changes go wrong.

Improving service to clients resulted in the decision to improve the Service Level Management process along with Incident Management and Change Management. Many people compare the Service Support and Service Delivery processes to rooms of a house and the Service Level Management process to the roof of the house. While it might seem strange that we put the roof on our house before all of the rooms were finished, we chose Service Level Management because of its significance to our clients.

In our process maturity assessment, we scored as high on Service Level Management as we did on Incident Management. Beginning Service Level Management made sense because of its relatively high maturity score and the fact that we could leverage it to help demonstrate to our clients the value of the work we were doing on the other processes, since every process impacts Service Level Management.

A quick read of Service Management resources will prove that there are no magic formulas to implementing solid, proven Service Management techniques. The results of a maturity assessment of IT processes are the starting point. Understanding the relationship of those processes to the strategic goals of the organization will help you to determine the “correct” order of implementation of best practices, according to the ITIL framework.