How Much ITIL Is Enough?
ITIL, and ITSM process design in general, remain divisive topics, sparking a number of healthy online debates in recent times. There are those who believe that any amount of best practice is overkill and that a framework will restrain their process design (this is a relatively extreme position fuelled by unique requirements or prejudice.)
At the other end of the spectrum, there are those who think that their organizations should adopt all ITIL processes—exactly as the books recommend. Unless you’re trying to achieve formal ISO accreditation, this approach can be highly constraining. In reality, even accreditation does not depend on adopting every ITIL detail.
It’s unlikely that your organization will need to adopt ITIL in its entirety—or even benefit from doing so. Make sure you’re not ignoring all other factors and focusing solely on ITIL. Instead, try to balance the recommendations made in the standard with the realities of their operational environment and business goals.
Following are some helpful filters to apply when you’re thinking about the degree to which an ITIL process will fit your environment:
1.Does the ITIL recommendation support your business goals?
If, for example, a formal problem management process will address greater service stability for the business, you can move ahead—applying more filters to help you decide how much to use or what to change. On the other hand, if that part of ITIL would actively impair your ability to meet a key goal, it can usually be ignored.
A word of caution: If an ITIL process doesn’t support one of your stated goals, look carefully at the purpose of that process. Have you missed an important capability gap in your process audit? Is the ITIL recommendation actually revealing something critical that you’ve missed?
My colleague Anthony Orr, himself an author of the ITIL standard, offers a much more in depth analysis of this step (and other themes) in his series of free BMC ebooks. And if you're frantically revising for your 'Managing across the lifecycle' exam you can read his latest book designed to get you through!
2. Is the formally specified process really needed in full?
If it looks like the ITIL process would support your business goal or close an important gap in your process requirements, you need to review the recommendation and decide how much of it is workable.
It’s possible that the recommended change management process would generally meet your goal of greater service stability. However, implementing it in full could detract from your adjacent goal of increasing responsiveness to the business. You then need to decide what you can safely discard while maintaining the integrity of the process.
In many cases, the ready-made process will be overkill and engineered to meet the most demanding operational environments. Recognizing this, renowned ITIL expert, Malcolm Fry, developed ITIL Lite. You can find out more about it here.
3. Do you have the resources to support the process?
If a specific part of ITIL will support your objectives and could be highly effective with a little adjustment, you need to consider whether you have the resources to actually make it happen.
Clearly, this filter applies less to the core and critical ITIL processes or those cases where you’ve identified important deficits in your current capabilities. You must find the resources to implement and staff these processes.
Instead, this pertains to the more marginal cases and the nice-to-have processes that could bring value to the organization. In each case, you need to assess the relative return associated with the process and decide whether it deserves priority when resources are constrained.
Do you really need to indulge the finer points of configuration management when you have no critical issues, no dedicated staff and no budget to support the process with an appropriate software tool? Be thorough in evaluating ITIL recommendations, regardless of their apparent logic.
New lenses for The New IT: Balancing the Needs of the Business, Technology and People
Whether it’s apparent or not, most processes revolve around a fundamental philosophy or guiding principal. ITIL is a good example of this, as it has introduced the concept of business alignment to many IT teams. ITIL invites us to consider the eventual business value of our ITSM processes and to think hard about including things that will only benefit IT.
While ITIL doesn’t preclude operational enhancements, it always guides us back to thinking about the broader business to some degree. It has become a major influence in shaping process design for many ITSM organizations, even if some have only used it to name their key processes.
Other lenses can and should be applied to process design, especially as IT shifts its fundamental approach in response to the digitization of more and more of the business . These include:
- Balancing the need to serve the business with the need to preserve the integrity of your supported systems
- Thinking about the people who will use those processes
- Ensuring that your theoretically perfect processes aren’t a complete nightmare for anyone who has to interact with them
- Making sure the processes are accessible and people-centric, but don’t compromise the stability of the very systems you’re tasked to manage In process design, the whole picture is very important and, sadly, often neglected. In light of these considerations, let’s look at some alternative design philosophies and how they might be combined:
The technology-centric approach
Naturally, there are occasions when you’ll want to be single-minded in your design approach. Not that long ago, IT support processes existed largely to govern the domain of technology and the people who supported it. This technology centered view barely considered how process design impacted the business. Instead, operational integrity and system performance were top priorities.
This approach still has its place. For example, in safety-critical environments or highly secure operations where integrity is the primary driver behind process design. Of course, there is a payoff for the broader business, even if it isn’t the prime consideration. It usually centers on failure mitigation.
The customer-centric approach
Recently, ITSM teams have been more focused on customer-centric operations. This is partly in response to increasing customer expectations around how and where IT services are consumed. It’s also a result of the unlimited access our internal customers have to information and alternative support networks.
This shift in expectations, coupled with the fact that many employees are now free to choose and run their own computing devices, is prompting many IT organizations to focus their efforts on staying relevant to the organization. The phrase “customer experience” is fast becoming standard ITSM terminology, and, for some, the new guiding philosophy for the services they operate.
For best results, mix with care
The secret of working with these different design philosophies lies in understanding how to combine them effectively and when to emphasize one set of objectives over another.
A good process design will consider the integrity of the technology, the business value and the user experience to varying degrees, depending on the context in which the process will be used.
For example, you could easily construct a self-service request process that’s hugely efficient for the business. Perhaps it enhances the stability of the underlying technology but leaves the internal customer in the dark until the process completes.
In this case, you have failed to consider the customer in a process that is customer facing. This a common mistake that highlights the value of thinking more holistically about process design.
Luckily, these factors build on one another. As a result, every process you design should, at a minimum, ensure the operational stability of any technology involved. As discussed earlier, this technology-centric filter is the only one you may need to apply to some integrity-critical processes.
Just as you wouldn’t construct a customer-friendly process that was operationally risky, you also can’t neglect the impact and broader value to the business. Therefore, our next level of consideration in process design is making sure that what we’ve designed effectively supports business objectives.
Your final step is to consider the human factors in process design, i.e., what it is like to interact with this process and the supporting systems as a process user.
What do you think?
How do you feel about ITIL? How do you approach best practice adoption in your organization? And how has your process design philosophy shifted as more and more of your organization goes digital?
I’d love to hear what you think in the comments section below or you can find me on Twitter as @messagemonger