How Long Should an ITSM Project Take?

I know that the question “How long should an ITSM project take?” is going to get an answer of “It depends on what you’re trying to achieve”, but stay with me a while and see if you agree with my view on this.

I was running a workshop for a customer recently, helping them to create an operating model for IT support. Participants in the workshop included people from many different parts of the customer organization, and an independent ITSM consultant who the customer had selected to do any process development work that was needed.

The customer already had working processes for most ITSM areas, the trouble was that they had different processes in each of many countries. As part of our plan to consolidate some of the work to fewer locations the customer needed to develop new processes for incident management, request fulfilment and knowledge management. The first stage of the project would require development of the new processes, including defining all the categories, priorities etc. that would be needed by the service desk, and also defining how existing knowledge could be shared more effectively. A later stage of the project would actually deploy these new processes.

I was absolutely astonished when the ITSM consultant told the customer that the process development work would take at least 12 months to complete. Both the customer and I explained that we didn’t need “perfect” processes, just something that was good enough to continue the project. We intended to use continual improvement to make the new processes more effective over time, but the ITSM consultant was quite sure that even this couldn’t be done in less than 8 months, and that it would then take a bigger team than the two people that he had been planning to use!

If ITSM consultants continue to tell customers that they need to run enormously expensive and time consuming projects that take years to deliver any value, then those customers are just going to stop listening. Businesses can’t afford to invest money in internal projects like that anymore, and there are much better ways of working that can deliver value in weeks rather than years. I had some involvement in development of the ITIL Journey, which was published by AXELOS (the owners of ITIL) last month. This was designed to help organizations make significant improvements to their ITSM practices in just a few weeks. There are also some great ideas on how to make quick ITSM improvements in “ITSM doesn’t have to be complicated” by Joe The IT Guy, and I’m sure that many readers of this blog could point me to more examples of how this can be done.

I remember projects from many years ago where we would spend years developing ITSM processes and nobody got any value until we were good and ready, but I thought this monolithic approach to ITSM process implementation had been consigned to history long ago. I hear people explaining that the Agile approach to software development is not suitable for all organizations, and that some critical software development still needs a slower waterfall approach. The examples people refer to are usually design of controls for critical infrastructure, or core financial applications, or other areas with very challenging requirements for confidentiality, integrity or availability. I can see how these critical solutions might need a different approach, but I really can’t see how development of IT service management processes falls into this category. The iterative approach to creating value by implementing the minimum viable functionality and then incrementally improving our solution seems perfect for ITSM. If we take this approach then we can deliver some value in weeks – and the people we are asking to invest in our ITSM solutions will get measureable improvements, and measureable value, in the sort of timescales that make sense to them.

What Can You Do?

If your ITSM project doesn’t plan to create real value in a short time then you probably need to think again. Think about how you can break your ITSM solution down into multiple short sprints, each of which can deliver something you need.

For example here are some things that an IT Consultant could do to shortcut the 12 month process development phase described above.

• Review what is being done in each location to see if you could simply adopt one of the existing solutions, with a view to improving it later if it isn’t 100% right.
• Decide to create very few incident categories for the first release of the new process; it’s easy to add new categories later if they are needed.
• Agree to a basic prioritization scheme with key customers. Again this can be refined later, it just needs to be good enough.
• Trust people to follow high level process documentation and only create detailed work instructions for things that will need many people to behave identically. Again, it is easy to create more work instructions later if people clearly need them.
• Pilot the new processes in a small location to see if they work. This will help to reduce the risk of introducing new processes worldwide in one big change.
• Define very simple customer-focussed reporting for the first release, with a limited set of internal metrics. More KPIs and reporting can be added later if needed.
• Limit the first release of Knowledge Management to simply consolidating all existing knowledge articles into a common structure, so that anyone can find and use them. Future iterations can improve this.
• Only create a small number of automated service requests for the initial Request Fulfilment process. This can be used to demonstrate the value of the tools and process and you can then iteratively add more automated requests.

This is just an example; your situation will be completely different. The key idea to take away is that you can create something valuable fairly quickly and then improve it by incrementally adding more value.

Like this article? You may also like:
Continual Service Improvement (CSI) – The Most Important Service Management Process.

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.