The modern IT department seems to have been under a barrage of fire for a number of years now. With everyone from the CEO down to line managers demanding more for less, it is very unlikely that is going to change. This means that the new pace of delivering services and functionality under budget, and with much smaller teams, will be a going concern.
Naturally, the first place anyone turns when they are forced to reduce cost, and improve efficiency, is process improvement. Though, like many IT organizations before them, process improvement tends to mean a new set of documentation that will be distributed to the enterprise. To make matters worse this is typically a one sided conversation, that rarely contains any room for follow up. If they really want to bat a thousand, someone will pick a set of best practices like ITIL, and "implement" it.
So, with IT content they have found the problems, corrected them in a linear fashion, and distributed the proper fixes, the move on to more pressing matters like triaging the 5000 password requests they received just this week. OK, there is a bit of sarcasm there, and even if this sounds familiar, it should also sound very wrong.
Unfortunately, the scenario above is all too common, and while failure isn't likely to be guaranteed, it is more than likely. This leads to what seems like an inevitable failure of the project or initiative. Now, since the improved processes couldn't be to blame, the more likely culprit always and coincidentally seems to be the implementation standards (read ITIL). Then again, what else could it be? The short answer to that question is everything but ITIL. Though, the real culprit is the organization was most likely not ready for change, and with a focus on speed and meeting deadlines, they took the shortest path.
Don't worry if this sounds familiar. In fact, a recent article over at the Australian edition of CIO.com discusses some of the disadvantage of implementing a set of best practices like ITIL or COBIT. Looking to research from the IT benchmarking and analytics firm compass, there appears to be a chance to even create negative results if the implementation is done as way to create new rules or guidelines. That is, instead of working to change an organization from within in order to "get things done," the often rigidness of just a new set of rules creates a scenario where the business just ends up doing what they need "to get things done."
Obviously, this is not the direction any organization should choose when attempting to implement a set of standards or best practices like ITIL. Most importantly, you need to make sure your entire organization is ready to start an initiative like implementing best practices from ITIL. How do you know if you are ready? Well a great place to start is by taking a look at five of our suggestions below. These should provide a good starting place, and measurement of your preparedness for true, organizational change. Once you reach the end, be sure to check out our Getting Started Guide for Understanding the ITIL Language.
You have proactively identified a problem.
This is a bit different than having a problem brought to you. Proactive problem identification should mean that you are actively seeking to understand your business, and identify areas for improvement. Since this is one of the most important tenets of ITIL (Continual Service Improvement), if you are already doing this, you are heading in the right direction.
You want to demonstrate IT's value to the business.
A number of IT teams have refused to see the shift in the business looking outside of the IT department for solutions to their problems. Thus, many IT teams still believe they are a collection of highly skilled workers that can't easily be replaced. In contrast, progressive teams are looking to better understand the business and demonstrate how to provide value that can't be outsourced to newcomers like "The Cloud."
You understand the difference between requests, incidents, and problems.
Since improving the Service Desk is a very common starting point for process improvement, it helps to know why not all tickets are created equally. Because running a service desk is more complicated than simply resolving issues on a first in, first out basis, understanding how to group and eventually prioritize incoming correspondence from customers is perhaps the most critical part to implementing best practices.
You lack an ITSM solution, or are looking to upgrade an existing one.
Even the best laid plans for IT process improvement can be undermined by the absence of a modern IT Service Management tool. Still, that isn't as bad as those that are unlucky enough to already have an existing solution. No matter which group you fall into, be sure to evaluate new tools openly and honestly. You are likely going to be using the tool for a long time, so it should support our first key item - Continual Service Improvement. It should most definitely not work against any process initiative you have.
You are convinced you are not ready.
In a sense, let fear be your guide. We tend to worry when an organization is completely convinced they have everything ready to go for irreversible, organizational change. If you think you aren't ready, take it slow. In truth, that is an approach everyone should take. As the saying goes, Rome was not built in a day. Along the same lines, ITIL best practices see the most positive results when organizations take time to get the entire business on board.