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.
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.
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.