The Security Blog

Article 3 in the ITIL Series: Adopting the ITIL Part 1

By David Moskowitz

Adopting the ITIL is big topic that we’ll explore in two articles.  In this article we’ll set the stage and provide starting points that must be considered. In the next article we’ll get into more details.

The first article in this series talked about what the ITIL is and what it represents. We explored some of the value/benefit proposition for the ITIL in the second article. This week we’ll explore what it takes to adopt the ITIL in your organization. Not every organization needs the ITIL. Further, not every organization will need everything exactly the way it’s described in the ITIL V3 books.  If your organization is thinking about adopting the ITIL as a way to achieve IT Service Management, then this article may serve as a starting point for thinking; it isn’t intended to be a cookbook.

The First Rule: Adopting the ITIL

The first rule requires a change in language from the use of the term implementing to adopting the ITIL. Why? When something is "implemented" the first thought is usually about a project with appropriate initiation, planning, execution, monitor & control, and closure. Adopting the ITIL isn’t about a project or an implementation or even about, "Doing ITIL."  Adopting the ITIL is really about taking a specific approach to achieving IT Service Management (ITSM) that uses the ITIL descriptive framework as a guide.

This is an important point that is based on a simple question: What is the goal for adopting the ITIL in your organization? You don’t "Do ITIL" for the sake of doing the ITIL. You adopt the ITIL as guidance to achieve something we talked about in the last two articles: IT Service Management (ITSM). It’s about the metamorphosis from, "I manage IT," to, "I Deliver IT-based services to support the needs of the business."  Combine that with Peter F. Drucker’s point (in last article) that the purpose for business is to create a customer. The conversion from inward technical focus to outward, business mission support focus (creating and retaining customers) is the transformation required for the business side to develop trust in IT. IT becomes a partner with and participates in the primary business purpose!

Every attempt at "Implementing" or "Doing" the ITIL I’ve seen has either failed or not produced the expected result. Worse, in all cases, the excuse was, "ITIL doesn’t work," or "ITIL doesn’t really fit our organization."  The ITIL isn’t the problem! The ITIL isn’t about "doing" IT processes, it’s about ITSM, IT Service Management which includes the entire organization, both business and IT.

The other problem related to implementing or "Doing" the ITIL is that it’s impossible to cherry pick one or two processes. The ITIL V3 is about IT Service lifecycles, not processes. 

Right Goals to Adopt the ITIL

Adopting ITIL isn’t (shouldn’t be) an IT project. The ITIL represents an approach to IT Service Management that makes about more then just IT, the focus is really on the organization. Not every enterprise should consider ITIL, and the ones that do might not need everything in the 5 core books.

If the goal is REALLY to achieve ITSM, and Change Management is the biggest issue, then that’s probably the right place to start.  But, you can’t really "do" Change Management without information about configuration items that could be impacted by the Change. This means the resulting Change Management process will require that Service Asset & Configuration Management (SACM) process be in place, in some organizations potentially as a prerequisite.  While it might be possible to do Change Management without a Release & Deployment Management (which also has a dependency on SACM), ultimately you’ll also have to add this process, too. 

There’s more: It’s going to be difficult, if not impossible to pilot or determine if the Change is delivering the expected value without Service Level Agreements (SLA) that document targets and requirements that map customer expectations for quality and value; this makes Service Level Management (SLM) another important process. 

Did someone say Value?

Value is the proper balance Utility (fit for purpose, functionality) and Warranty (fit for use, reliability, resiliency, etc.). Without the related processes, it could be difficult (if not impossible) for SLM to do its job to assure customer expectations are met without also understanding the value proposition making Availability, Capacity, Continuity, and Security necessary eventual candidates to get added, as well. 

The focus should be on the customer value: the customer perception of quality. There is a partial quotation from Peter Drucker in the Service Design volume (but originally from Innovation and Entrepreneurship, 1985, Harper ): Quality in a product or service is not what the supplier puts in. It is what the customer gets out and is willing to pay for.  A bit later in the book is this, Customers pay only for what is of use to them and gives them value. Nothing else constitutes ‘quality’.

What if…?

If your Change Management process is broken, you might be able to improve it by migrating to something that is more closely aligned with the description of the Change Management process in the ITIL V3 Service Transitions volume.  Similarly, if users don’t get proper support and don’t know who to call, it might make sense to investigate either changing or adding a Service Desk function along the lines suggested in the Service Operation volume. But taking these pinpoint approaches doesn’t mean you’re, "Doing ITIL."

It’s tough for the Service Desk to really achieve customer satisfaction without supporting processes for Incident, Problem, Event Management plus the SACM and SLM processes noted above. For example, the Service Desk could use information maintained by SACM (in the Configuration Management System or CMS) to determine if there are other services or other users impacted by "this" incident. With that information the Service Desk can be proactive about alerting users before users start reporting. 

How to Get Started

You don’t need the ITIL to have an ITSM focus (though I suspect an examination of the internal processes of the ITSM focused-organization would bear a striking resemblance to descriptions in the ITIL V3).  The ITIL is just one way to get there.  The ITIL could shorten the learning curve to achieve ITSM goals.

The first step is to get management commitment (including funding) that the overall goal is to effect organizational change: IT as a service provider to the business, strategically supporting the business.  You get management attention and commitment with a business case, a Justification for a significant item of expenditure that includes information about costs, benefits, options, issues, risks, and possible problems (from the ITIL V3 Glossary).

This represents a longer term commitment, not only to achieve ITSM, but also to continually adapt and improve as customer and business needs change.  It’s very much like building a Web presence. It isn’t something you can do once and done.  You have to continually add new content, remove outdated material, listen to customers to make it easier for them to search and use the site…  and the list goes on. 

Adopting the ITIL is a strategic decision, not a tactical one. However, like the Web site analogy, you can achieve and expect short term wins from adoption. As with most things, you have to find the right balance for your organization between short-term tactical moves and longer term strategic ones.  

With management commitment consider starting with a series of questions similar to the following:

• What is the business mission? What are the business objectives? What is the context or driver for the effort? What is the business case for the effort? (If there isn’t a business case. STOP; you need one before you proceed — it’s not about IT.)
• What is the current state of affairs?  What’s working? What isn’t? In other words, what is baseline or starting point? 
• What type of improvement (towards ITSM) is desired?  How is that expressed in terms of measurable targets, metrics?
• What’s the plan of action that makes sense for the organization to achieve the goal? What services and processes will be addressed first? What is the road-map to get to where the organization needs to be?
• We have the measurable targets, how will we know that we’re making progress toward the goal and how will we know when we’re ready for the next step(s)?
• Now that the organization can see progress toward "this" goal, how do we keep going? How do we get the next win?

This last bullet reinforces the point made above about long term commitment. You don’t DO ITIL to get to a singular end goal or state. You adopt the ITIL so that IT can participate in the business purpose to create customers, retain customers, and operate in today’s fluid environment. Customers are not static. Customers are fickle and ask a simple question: "What have you done for me lately?" If your organization doesn’t keep pace with changing / evolving customer expectations — and ultimately getting to point of being able to anticipate some of them — then your customers may become someone else’s customers. It’s not just about customers of the business, IT has internal customers, too. BOTH constituencies (the business and customers of the business) must be served.

In the next installment will provide more information about adopting the ITIL that continues this theme of continually improving IT Services (and related processes).

Comments, questions or suggestions:  david.moskowitz@gmail.com