When it comes to ITSM processes, just how much process is too much?
To many of us in the IT industry, process is a “dirty word”, a necessary evil. The word conjures up images of mindless IT bureaucrats more focused on forms than on getting things done.
How many times have I heard “we’re too busy to look at our service desk processes right now” or “Change Management will just slow us down” or “it’s a SaaS application, just turn it on”?
What many organizations fail to realize is that the reason they are so busy fighting fires, are swamped with failed changes, or are up to their neck in rework, is specifically because of lack of ITSM processes.
Let’s take a moment to debunk a few process myths.
- We’re too busy to stop and improve our processes. That’s like saying you’re in too much of a hurry to change a flat tire. The reason you are so busy is you’re fixing the same incident over and over, or you’re dealing with irate customers who still haven’t received their new PC.
- Change Management will just slow us down. Good point! Why waste time on Change Management when you have so many failed implementations that need your attention? Most IT folks know that failures are most often the direct result of a change, so why not save yourself the trouble and do it right the first time.
- It’s SaaS, just implement it out of the box! Of course, because your company is just like every other one out there. You are organized the same way, have the same IT services, the same user community and the same regulatory requirements. While the basics may be the same across organizations, there is still a requirement to tailor your processes and tools.
There is no better way to improve the effectiveness of your IT organization, while reducing the cost of infrastructure and operations, than the implementation of IT Service Management processes.So where did ITSM processes get such a bad rap?
The processes unto themselves are not to blame. The failure lies with the people responsible for designing and implementing the processes, combined with the lack of governance once they are rolled out.
Here are some of the common mistakes I’ve seen that contribute to “process fatigue”.
There is no need to talk to our clients because we know what they need
You can’t design a process sitting in isolation at your desk. Not because you are not capable, or smart enough, but because the adoption of a process requires buy-in, and for that you have to get people involved. The trick is balancing consensus building with getting things done. A small core team, with representation from across your organization, is the best way to proceed. Just make sure the team is empowered to make decisions
The “12 processes in 12-months syndrome”
If having one process is good, then having twelve in place must be even better! While a twelve month plan may look good on paper, there is just no way any organization can adopt that much change in such a limited timeframe, not to mention the effort in having to implement the processes in a tool and training people to use them correctly. An overly aggressive schedule is the sure way to set yourself, and the program, up for failure.
ITIL is a standard, and our tool is ITIL compliment, Ipso facto…
It sounds logical, but there are two problems with the statement. First off, ITIL is not a standard, and secondly, there is no such thing as ITIL compliant.
ITIL is a set of high-level Best Practices– there is nothing in ITIL specific to your company or organization. It’s a great conceptual framework from which to start, but there is a lot that needs to be done beyond the ITIL books to make it applicable to your needs (think organization, procedures, tools…).
And when it comes to tools, how can they be compliant to a standard that doesn’t exist? Sure, they may use ITIL terminology in their application, but every vendor implements their own interpretation of ITIL. There is still a lot of tailoring and tweaking required once the tool is bought.
This misunderstanding of “what is a standard” and “what is compliant”, combined with the unrealistic mandate to implement the ITSM tool “out of the box”, is one of the main reasons for failed ITSM tool implementations.
So, just how much process is enough when it comes to ITSM?
I’ll try to answer that from two perspectives, quantity, and complexity.
When looking at how many processes to implement, remember it’s a journey and not a race. The other thing to remember is that some processes require others to be in place (you can’t measure availability, and, therefore, service levels, without first tracking incidents).
I always recommend that companies start with Incident Management, Change Management, and Service Request Fulfillment. Why? Because these are the processes that directly affect your customers.
- People want new stuff quickly and accurately– That’s’ Request Fulfillment
- Folks want that stuff fixed when broken – that’s Incident Management
- Customers want stability – that’s Change Management
Do those things well and you will earn the credibility, and buy back the time, to implement the higher order processes such as Service Level Management, Availability Management or Catalog Management.
You need to be doing the basics before tackling the more advanced processes.
The next consideration is the complexity. Whenever you are designing a process you have to constantly ask yourself “is this step necessary, is this information required, is this tool tweak needed?” The best advice I can give is to challenge everything and throw away anything you don’t need. It is way better to have a simple process that everyone follows than a complex process people try to avoid.
There is value in the process.
Whether it’s the way Disney orchestrates your visit at their theme parks, the care Starbucks puts into delivering a consistent experience or the quality of products from Apple – the world’s best companies run on process.
Shouldn’t we in the world of IT Service Management do the same?