ITIL makes sense in concept: focus IT efforts on the support and delivery of services that meet the needs of the business. Manage risk. Improve. Rinse and Repeat. It’s really a common sense approach, and it’s hard to argue with that.
The CIO who attends a 60 minute talk about IT Service Management likes what she hears, but at 2:00 AM she wakes up with some nagging questions:
So… How do we actually DO this? ITIL talks about all of these different types of Managers… Change Manager, incident Manager, Problem Manager, Configuration Manager, Availability Manager, IT Service Continuity Manager, Capacity Manager, etc, etc…
Does ITIL require us to hire an additional management team? If we repurpose the managers we have, how will all of the existing managers’ work get done? They’re already overwhelmed as it is!
Indeed, this is a common dilemma. The IT organization already has a number of Managers, but they’re arranged in a different way. For example: a Director of IT Operations, a VP of Engineering, Several IT Managers (broken up by technical and functional group – i.e. Linux Manager, Desktop Support Manager, Network and Telecom Manager, Storage Manager, etc).
The problem is that the majority of the IT organization is currently built around delivery of technology, not services. Even if everyone wants to deliver end to end service, the daily activities of the staff are focused on delivering the technology that they are responsible for. The Network team is focused on network throughput and uptime, the Unix / mainframe / storage teams work on the equipment of their particular type, and so on. Everyone has their own set of metrics to concern themselves with, and problem solving often involves proving that the root cause lies elsewhere.
Specific projects bring resources from the separate areas together, but projects are, by definition, temporary. Moreover, these cross functional projects are often seen as a nuisance and an interruption to the “normal” workflow, since they require one or more members from a given team to be pulled out of the rotation.
To address this issue, start by writing job descriptions for everyone in IT (your legal and HR teams will likely agree that this is a good exercise anyway). What you’re likely to discover is that the existing managers all perform a LOT of different roles, and that there is a lot of overlap.
To illustrate, here are some of the tasks I performed as Manager of the Linux and Enterprise Storage teams at a well known Domain Name Registrar:
- Select hardware and software vendors, evaluate solutions, manage contracts
- Develop reporting tools and forecast future purchasing needs
- Develop operating and capital expenditure budgets
- Hire and manage staff, conduct performance reviews, develop quarterly MBO’s for each staff member
- Serve as Project manager for any storage or Linux related project
- Develop system architectures, including software, OS, hardware, and network concerns with a focus on business continuity and high availability
- Evaluate and approve changes to the Linux and Enterprise Storage Infrastructure
- Lead team in scheduling and deploying new applications to the live environment
- Troubleshoot incidents and determine root causes “often with only a portion of the information necessary to make a decision” (quote taken directly from my job description)
- Manage software and OS licenses and support contracts
- Research and evaluate new technologies, make recommendations, purchase when appropriate
- Work with corporate accounting team to track physical assets from purchase to retirement and schedule depreciation
It should be obvious at this point that many of these job responsibilities could be consolidated into process focused roles. The above job description contains elements from at least 8 different ITIL process areas. Getting all of those things done was a tall order, and my peers (Windows and Data Center Manager, Network and Telecom Manager, Database team Manager, and the NOC Manager) all had similar daily responsibilities. The organizational capacity was there; it was just a matter of redistributing the work
In this case, assigning the “Service Desk” and “Incident Management” roles to the former “NOC manager” was easy enough, and that person made sense as the Configuration Manager as well. The roles of Change Manager, Release Manager, and Problem Manager were a natural fit for the person formerly in charge of the Windows Server infrastructure, and my role became more focused on Availability, Continuity, and Capacity Management. The specific assignment of roles will, in practice, vary according to the skills and attributes of the individuals involved. However, the likelihood is that most IT organizations already have the necessary personnel (or at least the right number of people) to allow for a successful ITIL implementation.
As I’ve said before, this definitely requires a phased approach. In general, starting with the Service Desk and Incident Management is easiest because the majority of the heavy lifting required can be done within one department and without having to shuffle the org chart elsewhere. Plus, the Service Desk has a great deal of customer interaction, so wins here are highly visible, thus lending credibility to future efforts. Once Incident Management is in place, add problem management. Refine the Configuration Management, Release Management, and Change Management processes next; improvements here will strengthen and underpin every other ITSM process. These are only guidelines; there may be a business case for starting elsewhere in your organization.
As we move through the ITIL Service Lifecycle:
Operations ->Transition -> Design -> Strategy
We’ve now addressed processes contained within the two areas on the left. If we’ve done our jobs properly thus far, we’ve been able to show significant and quantifiable value through the retooling of what ITIL v2 referred to as “Service Support” processes. Moving into the areas of Service Design and Service Strategy (these processes were the “Service Delivery” processes in ITIL v2), we begin to involve staff from IT development, Finance, Security, Business Continuity, and –most importantly- customers.
As stated above, some of these roles may come from within IT. For example, some existing IT managers could form an “architectural team” responsible for Availability, Capacity, and Continuity. Other functions may be performed by resources from other areas of the business: you may need to bring in an asset from the corporate finance team to support IT Financial Management operations on a full time basis, or appoint a Project Manager to the role of Continuous Service Improvement Manager. The Service Level Manager function requires a unique skill set (customer ambassador to IT and IT marketing rep to customers, among other things), which may not currently exist in the organization. Some companies may need to train or hire this role, or even outsource it.
As an aside, the importance of proper training cannot be overstated. There are multiple levels of ITIL training available, and with good reason. It is not reasonable to expect someone with an ITIL Foundations Certification to fully design and implement the Change Management process for your organization. This is equivalent to asking someone with Microsoft Windows Desktop training to design and deploy an enterprise data center. Make sure that the level of training provided matches the expected results to be delivered. Investments in ITIL training will quickly pay for themselves in efficiently designed processes and IT services.
Restructuring the org chart of the business will obviously require management commitment at the highest level. Still, the benefits of restructuring are significant: Focus IT efforts on the support and delivery of services that meet the needs of the business. Manage risk. Improve. It’s hard to argue with that.
