Getting better value from your IT spending means making its functions and outputs more valuable to your customers. An industry standard method for achieving that outcome is the IT Infrastructure Library (ITIL) framework for IT Service Management (ITSM).
When done the right way, adopting an ITIL framework gives you the tools and processes to completely expose IT costs as inputs into your specific business operations. That allows you to understand where you can trim costs, where you cannot without damaging your capabilities, and where there is a profitable reason to expand IT spending. This transparency and alignment of IT costs with income-generating products and services is rarely available when IT is treated as a centralised cost shared across all areas of operations.
The best ITIL implementations are those that avoid a few weaknesses that sometimes arise from careless application of the framework. Those weaknesses are mostly related to practitioners being too literal in applying their certification training.
The first step to accessing all the benefits of ITIL ITSM without any weaknesses is to understand how it fits into your organisation’s overall strategy.
Figure 1 shows that the ITIL framework should always be recognised as a sub-set of strategic planning and management, and integrated into every-day operations rather than being its own area of operations. It is also a sub-set of enterprise architecture, meaning that it ought to adopt a service orientation based on its capacity to add value to profitable products and services.
ITSM has synergies with business process management because its processes should adhere to best practices in process design and efficiency. ITSM development should also be aligned with project management disciplines to ensure well-managed implementation.
In other words, to get the greatest value from ITSM it must be integrated into strategic planning and operational management. The best people to help you get it right are those who understand not just the ITIL framework, but also the interrelated disciplines mentioned above. Working with me will give you peace of mind about covering all your bases because I can bring to bear experience and expertise in all of the management and technical specialties required.
What is ITIL?
The ITIL framework arose in the 1980s from the British government’s efforts to consolidate best practice ideas to extract better value from its IT spending and practices. By the 1990s this had coalesced into the Information Technology Infrastructure Library, hence the acronym ITIL. This was a library of guidance publications for IT professionals. Shortly later it was revamped into a formal approach for IT Service Management (ITSM) with fewer but more comprehensive publications. ITIL version 2 (2001) consisted of eight books. Version 3 (2007, refreshed in 2011) consists of six books. There are also subscription-based online supplements and many explanatory documents by practitioners and training organisations.
Like the PRINCE2 project management method, ITIL is today a proprietary methodology commercialised by the AXELOS joint venture between the British government and London-based outsourcing services corporation Capita. That means ITIL certification is a commercial venture with its own business drivers and the diverse profit models of various training providers.
For newcomers to ITIL, the basics are covered more clearly in version 2 documentation than in the most recent update. I regard this as a flaw arising from the profit motive behind the business of selling the publications and certification training. I think it makes it harder for complete novices to know what to do, and I go over some of those initial priorities in the section headed ‘First steps’ below.
What can escape some certified ITIL practitioners in this environment is that the set of ITIL books offer guidance, not rigid prescriptions. The hard work of analysing individual circumstances to customise that guidance, making it fit the specific needs and capabilities of an organisation at a particular point in time, cannot be cribbed from any publication or training course. Moreover, the analytical process does not end: as business environments and organisational circumstances change, its ITSM approach must change with them.
The biggest potential weakness of ITIL practices is that its certification programmes teach rote learning and rigidly doctrinaire application of text-book methods. When I sat for my certification exam, I thought the ITIL foundations course and test were far less useful than the underlying principles.
Being aware of this potential pitfall is the best way of avoiding it. One way of remaining focused on business objectives is to keep in mind an axiom by Grant Thornton UK business consultant Chris Maund: ‘IT projects do not exist, there are only business projects’. While the ITIL framework can be very useful in achieving organisational goals, it should never be allowed to become an objective in its own right, or a bureaucratic paperchase demanding a heavy governance overhead.
How does ITIL ITSM work?
At the core of the ITIL framework is the ITSM lifecycle. That cycle is itself based on the axis of most contemporary quality management paradigms: the Deming cycle of continuous improvement, explained in more detail on my business process management page, and in my essay outlining a brief history of process management.
The ITSM lifecycle illustrated in Figure 2 above revolves around a service strategy that is subject to distinct service design, transition, and operational stages in an iterative, continuous improvement process. That means there is ceaseless tweaking and adjustment of service components based on equally ceaseless analysis for effectiveness and improvement opportunities. This is a wide effort involving all stakeholders, including customers, who can offer invaluable feedback to drive value-added improvements and cost efficiencies. Equally valuable advice may also be offered by vendors with experience of ITIL through assisting other clients.
ITIL ITSM guidelines are simple and flexible enough to apply to any organisation, from a home office to a transnational corporation. These principles are based on the recognition that old-fashioned IT management approaches focusing on resources and infrastructure are of little intrinsic value to a business.
Figure 3, below, illustrates that the idea is to move progressively away from that old-fashioned model to one in which IT services are increasingly exposed as value-added inputs into business products and services.
- ITSM begins with moving away from merely managing infrastructure and providing application support.
- The next step is the development of service catalogues, listing all supported IT components, including their costs and the limits of technical support. These service catalogues form the basis of service level agreements (SLAs) that specify precisely what IT components are supported to what degree (scope and quality), at what cost, and with what escalation paths if things go wrong. There may be only one service catalogue, or dozens, depending on the size of the organisation, but each item in every catalogue should be associated with a product or service to which it adds value.
- If there are IT components that do not meet service level requirements from internal or external customers, these should be culled or improved until they do meet requirements. That means the ITSM effort must be continuously focused on business justifications for the existence of items in service catalogues.
- In larger organisations that leads to the concentration of service catalogues into one or more distinct service portfolios underpinning one or more business divisions.
- An ultimate goal of ITSM might be to create service portfolios recognised as valuable enough to be treated as profit centres in their own right, by being offered as commercial services to clients.
- Amazon, Google, and Microsoft are examples of organisations whose own use of IT led to the development of service catalogues on offer directly to customers, like infrastructure as a service (IaaS) and software as a service (SaaS). A spectacular public sector example is the decision by NASA to release its entire 2017-1028 software catalogue free of charge to the public. Smaller organisations can also develop capabilities valuable enough to others to offer as commercial services. For example, a bicycle repair shop with only five employees might invest enough time and effort into developing an open source content management system listing hard to find parts, buyer and seller networks, and aggregating other kinds of niche information, to make it an attractive option for other bicycle shops to buy or lease the system.
To ensure that the ITSM lifecycle actually creates value for the organisation, the development of meaningful metrics and their accurate, timely measurement are critically important.
Business sponsors of ITIL transformations have to agree at the outset how they will measure success. ITIL literature recommends the balanced scorecard method. This includes financial results, but also some index of customer satisfaction, a means of assessing improvements in organisational agility, innovation, and capability development, and measurement of staff turnover in business critical areas. This last index can be invaluable in gauging the sustainability of service strategy and the culture it has created.
The ITIL version 3 framework can be thought of as a mixture between service oriented design advice and a condensed strategic management guide for IT specialists who might not have that background or training.
ITIL aligns itself with the ISO/IEE 20,000 service management standard, and other international benchmarks in an attempt to become an international standard in itself. However, ITSM is not standards compliant in its own right without making this an explicit goal of an ITIL transformation project.
The current version of ITIL documentation makes it harder to work out where to start than version 2. The authors of version 3 seem to assume that everyone already has some familiarity with the framework. But for organisations just starting to consider ITSM, it is more helpful to look at the emphasis in ITIL version 2 one some basics: the service desk call tracking system; the Configuration Management Database (CMDB); incident management; problem management; and change management. Without creating these basic capabilities, developing baseline measures and ITSM improvements will be a struggle.
The service desk need not actually be a call centre. It is just where support requests come in if something is wrong or users need help with IT functions and systems. But it is critically important that the nature of support requests are captured at this point. There are many commercial service desk software packages that will facilitate this, but I have also seen this done with open source (free and customisable) software. The detail to be recorded has to allow for later reporting on incidents by systems affected, by user groups affected, by frequency of problems experienced, and by the magnitude of the problems experienced (probably expressed in lost income potential or actuals).
The CMDB is an information repository which holds details on all configurable IT assets and items. This includes hardware and software, but also contracts, service catalogues, SLAs, licenses and other documents governing IT services and support. Without a data repository like this, it will be difficult to anchor improvement efforts to a baseline. It would also be much harder to analyse shortcomings, or to conduct change, incident, and problem management. The service desk software might double as a CMDB, but should definitely permit interaction if there is a separate CMDB to permit linking incidents to all relevant configuration items, and to include these linked details when used to analyse incidents for problem management. Interaction between information repositories is also required to update the CMDB when details need to be updated as part of the change management process.
Incident management extends helpdesk functions to include not just resolution efforts, but also reporting to assist with problem and change management. Figure 4 below illustrates a hypothetical incident management process with annotations to explain what occurs at every step.
- Incidents include what ITIL version 3 calls ‘events’, which are automatically tracked problems like server/cloud downtime or heavy loads and waiting times for accessing certain systems.
- Incidents also include all support calls to the help desk. These could be about problems with systems or just evidence that user instruction and/or training are needed.
- The incident management function must include capturing enough detail to identify precisely what configuration items (IT components, contracts, licenses, etc) and user groups are affected.
- Incident management includes on-the-spot troubleshooting with the aim of resolving a service disruption, and, if it cannot be immediately resolved, escalation according to an applicable service level agreement, or according to some other known method.
- In many cases escalation can also be via technical hierarchy to second or third level support teams.
- Important to the ITIL framework is that incident management includes enough logged information to permit reports to be generated that can list incidents by frequency, by affected systems, and by affected users. That is the basis for problem management, and leads onto change management.
Problem management is the systematic analysis of the most frequent incidents to eliminate the underlying problems or causes. Figure 5 below illustrates a hypothetical problem management process, with annotations to explain what happens at each step.
- Where an organisation is large enough, a dedicated problem manager with excellent analytical ability and wide technical skills should spearhead problem management. The problem manager should have ready access to all incident and problem management information already gathered, but also to details of change and project management information that might relate to causes for underlying problems.
- In larger organisations, immediate resolution of problems might lead the problem manager to form ‘Tiger Teams’. Such teams are also known as matrix teams, which come together temporarily, with membership drawn from across the organisation, and perhaps also from vendors, to bring together the expertise needed for rapid analysis and resolution of a particular problem.
- The problem manager may also determine that a formal project is needed to resolve underlying problems. This would trigger an entirely separate process for project and change management. Often the root cause of problems is a previous change with inadequate testing or evaluation processes. It is therefore important to conduct problem management in conjunction with analysis of information about project releases and formal changes listed in the change register.
The usefulness and requirements of change management should be obvious when thought of as the best way to avoid incidents and problems arising from planned and unplanned changes. The objective is to minimise disruption to normal operations arising from change. Every change to any part of a system or user-base should be considered by a change advisory board (CAB), chaired by a change manager. In smaller organisations the CAB could be a single person.
Change management should have its own data repository, preferably linked to the others already mentioned, so that information can be logged about the precise nature of changes. This helps in any necessary incident and problem resolution, and to minimise the potential for introducing further errors by interfering with other changes. Interaction with the help desk logging and reporting software permits notification of changes, availability of help scripts, and access to information on any known workarounds and escalation paths. Interaction with the CMDB is necessary to update the configuration items affected by changes.
Changes should not proceed until the CAB has determined that a sound business justification exists for the change, that the change has convincing test and back-out plans, and that there is plan for a follow-up assessment. More detail is given on my change management page.
Without these basic components of an ITIL framework, developing service catalogues, capturing service requirements, and developing SLAs would be much harder because separate discovery will most likely create conflicting versions of what should be the same information about configuration items.
Information repositories don’t need to be expensive databases. As already mentioned, there a free open source options, and I have seen small businesses do well with no more than spreadsheets and other documents in a shared directory or a SharePoint library (directory tree). The only critical requirement is that records are always up to date.
If any of the methods and techniques I have mentioned here strike you as useful to your organisation, I’d welcome an opportunity to discuss your specific requirements.
What you can expect from me as your ITIL consultant is the experience to make sound judgements about matching your business objectives with ITIL principles to help minimise costs while adding value to your operations. My judgements in this area are grounded in hands-on experience with ITIL transformation projects, and my full range of skills in designing and implementing architectural, business process management, and IT projects.
Use my email form here to get the ball rolling by summarising your details and your needs.
RELATED: Read my case study on the 2016 online census project to understand how some discipline with ITSM might have helped prevent an operational disaster.