Many organizations are working to adopt ITIL practices and improve the quality of services they provide to their customers. Yet many organization, especially larger ones with a broad array of potential areas of opportunity, struggle to identify the key critical success factors that make ITIL adoptions successful. We’ve had the privilege of working with hundreds of different companies to “get past talking” and begin to make meaningful adoptions that drive real results, both in improved efficiencies and effectiveness. In this white paper we will talk through three of the most critical we’ve see in our consulting and mentoring experiences.
CSF #1 – Management Commitment (and how would one measure that?)
Literally every publication that talks about successful ITSM adoption begins with the need for “Management Commitment.” Unfortunately, that’s often where it ends, too. That begs some obvious questions. What is management commitment, and how would I know if I have it?
We have seen common traits in successful ITIL adoptions around demonstrable management commitment. Here are a few we see in the most successful ones.
Creation and Funding of a Formal ITSM Program – In most IT organizations, commitment is seen in investment and commitment of resources and time, and a willingness and commitment to effective measurement of the efficacy of the program.
Visible presence – Successful ITSM programs have highly visible executive Champions, who understand the value proposition and advocate for the program and for the achievement of the benefits. Unsuccessful programs often have executives with poor awareness of what ITIL is, but have a general “wish” to be perceived as using best practices. Phrases you might hear include things like “we want to be an ITIL organization.” These executives require substantial consulting and mentoring to understand and prioritize the benefits of an ITSM adoption, or they will go in circles.
Adoption of Owner roles –ITIL and other frameworks like COBIT emphasize the need for effective governance and management of processes, and clear alignment on services, service value, and service delivery. ITIL supports these through the establishment of Service and Process Owners, whose job is to work in cross-functional ways to support delivery of whole end-to-end services and ensure effective role alignment in coordinating process activities. An unambiguous sign of real progress in an ITSM Adoption is the definition of and assignment of these critical roles to appropriate (and often very senior) IT management.
Celebration of achievement milestones a.k.a. support for CSI – Wise managers are well aware that ITSM adoption happens at different levels of maturity in different parts of the organization. Establishing good core practices and intensely focusing on continual improvement , what we often call the ‘Win a little to win a lot” attitude, is critical to keeping the team focused and engaged.
CSF #2 – Define Processes before Tooling
In many organizations that are challenged with their ITSM adoption, there wasn’t in fact much of a strategy, but there had been a substantial commitment: to purchasing one of the major integrated ITSM toolsets.
Our general commentary on tooling is pretty simple: virtually all of the major tool families do a good job with implementing supporting tooling for the core ITIL Service Operation and Transition processes. Unfortunately, even when organizations plan to adopt entire tooling families, individual module implementations tend to take a siloed approach, down to retrofitting poor customizations from previous tooling implementations that would be much better off discarded outright.
A better approach is to lead with the processes first. Establish your core processes (many templates are generally available that would get you 80-85% of the way to where you want to go), and then tailor these to fit your needs. A proper process document will establish your objectives, governance, activity workflow, metrics, roles and responsibilities, and a RACI matrix at a bare minimum. Once you’ve done your due diligence on the process, it becomes an easy activity to look at how to use the tooling to automate the process activities and to create reusable models. Remember that automation is neutral by design; it allows you to do things quickly and with fewer resources. If it’s automating the right activities, it will dramatically improve quality and productivity. Conversely, if we don’t have clarity on our processes and procedures first, it simply allows us to “do bad things fast.”
CSF #3 – High Quality Incident Management Information
Many organizations begin the ITIL journey unhappy with the state of their service desk and their incident management processes overall. In many cases, these issues begin with fundamental aspects of process immaturity: lack of clarity in role definitions, poor or no business awareness training, lack of proper process governance and oversight (or lack of a single process owner and/or process managers with responsibility across technical/functional silos), bad process compliance, and poor metrics definition. While virtually every organization has “incident management,” shockingly few really have a single enterprise process with meaningful end-to-end governance and management. This is especially troubling, because good quality incident data is fundamental to the success of many of our other core process areas: problem management, availability management, capacity management, SLM, change management, configuration management, and we could go on. So job one in any adoption is to ensure the quality of your incident data, and to do this, you must focus on establishing and stabilizing your incident management process. Do you
- Have consistent and appropriate practice for when incidents are detected and logged so the “clock” starts
- Have coherent categorization schema that produce effective assignment and searching as well as a rich source of effective and targeted reporting.
- Have rigorous rules for priority based on business impact and urgency with highly consistent scoring based on established procedures and work instructions
- Have defined incident models for the majority of “routine” incidents
- Have a knowledge base that is usable and effective to support first-level incident resolution
- Have clear rules for resolution of incidents and when the clock stops
- Have clear rules for closure, final categorization, and enforcement of incident resolution documentation
And one to grow on…Service Level Management
Not every organization with successful ITIL adoption activities has formalized Service Level Management. It is entirely possible to establish and improve other process areas without it.
However, the organizations that really get the big wins always do.
Why? It’s really very simple…it’s possible to have processes without services, but it’s very hard to deliver better outcomes for customers without a meaningful process to ensure alignment between IT services and the business workflow and outcomes they support. SLM establishes IT’s “reason for being;” ensuring that what we do delivers the right benefits for the business, and that we have a dynamic way to maintain awareness of business need changes (internally or externally driven) so that we can appropriately evolve services to meet the changing landscape. It ensures that we emphasize end-to-end service metrics and their contribution to business metrics (like revenue, profit, and mission achievement) over technology and raw uptime. It also provides a regular communications vehicle to more proactively identify improvements and potential issues. If you have spent a lot of time (and money) on ITSM adoption with limited buy-in from your business partners, this is almost certainly the “missing link” that will help you get your activities back on track.
Patrick von Schlag is President and Chief ITSM Consultant for Deep Creek Center, a service management consultancy and accredited training organization based in Highland, MD.
