ITSM Doesn’t Have to Be Complicated
When organizations want to improve their IT service management they often create huge projects that take a long time to deliver much less than expected. Why does this happen, and what can you do to make sure your ITSM project is a success?
The basic concepts of ITSM are very simple. Understand what your customers want, understand the constraints you have (money, resources, regulations etc.), and then deliver the best service you can within these constraints. What happens in practice is often not so simple, we document complex processes that nobody would ever have the time to read, we demand that tools are configured to support every detailed step of the newly defined process, however difficult that is, and we create inward focussed KPIs and reports based on the new process.
When I write it like that you can see that it’s not the right approach, but it is still what happens most of the time. We end up with bureaucratic processes, unfriendly tools, unhelpful reports and dissatisfied customers.
The Approach
The biggest mistake here is probably in trying to do everything perfectly in one big project. We have all seen the value that can be created by using Agile methodology to deliver business projects, but too few IT departments think about how a similar approach could be used to deliver ITSM projects. The advantage of this approach is that it allows us to deliver something very fast, and then to incrementally add value. This also allows the detailed requirements to evolve over time, without having to fully understand all the ways we might work in the future before we start.
For example, imagine that you decide to implement problem management. The first thing you might think about in an Agile approach is “What is the vision for project management?” Where do you want to be when it’s all working in the future? This is an important step because it involves getting all the stakeholders to think about the purpose and objectives of what you’re doing, and will make sure that each incremental delivery is leading towards an agreed goal.
The next question to think about is “What is the minimum viable capability for problem management”. In other words, don’t try to create a perfect problem management process in one big project, identify something you can create that will have some value and can then be built on. This minimum viable capability won’t be the same for everyone, I can’t tell you what it is because it has to be what will work for you. In one organization it might be a simple spreadsheet-based process to analyse incident trends. In another it might be a small team that has been trained to use Kepner-Tregoe problem solving technique. Whatever your minimum viable capability is, you should be able to develop and deploy this in a brief time; typically it is best to allow just 2 weeks for a Sprint to put something like this in place.
Moving Forward
Now you have something in place you can start to build on it. Work with your stakeholders to identify incremental improvements that you could add to the minimum capability you have created, prioritize these improvements, based on what value they will create, what they will cost, and how well they align to your overall vision that was agreed at the beginning. Then select your next sprint and off you go.
If you have any Agile experts in your organization then get them involved to help you with this work, if you don’t then you can still get started and learn about Agile as you go along. One Agile technique that you should definitely incorporate is the retrospective. After each sprint hold a meeting to discuss what worked well, what could have been better, and how you could work better in future.
So what are you waiting for? Think about all the different IT service management projects that you’ve been putting off because they are too big, too expensive and too complex, then pick one and get started. You’ll see improvements in just a few weeks, and so will your customers.
