- From day one this project was driven as a requirement by the CIO – he wanted to do this and had clear reasons for doing so – i.e. to develop meaningful service-based reporting, to build the service Catalog so that he could then look at how to sensibly present the business value of what IT does. However, he had clear requirements for this and these were passed down to his staff to action as a key objective. This does make such a difference…
- The IT team took a little time to really embrace (1) the mechanics of SLM and (2) the potential value. The mechanics were fairly easy to explain and work through in a 1-day workshop. It took a good few weeks and months longer for each team member to see what the value was for them. The Project Manager (also the Service Desk Manager) was initially unsure and said he understood the concept but couldn’t see the value. His epiphany came when we drew up a ‘traffic light’ report on 1 page for all services – he could then see how the information that he was compiling would go towards building this and also making it credible. He also did most of the customer meetings and said he’s learned a whole lot of new things about how the business works.
- We defined the overall structure of services in the initial workshop. We then spent a good amount of time defining what each service was and how this would be reported on. So each service ‘metrics’ would be comprised of a number of different components, each weighted appropriately for the service. We took a view on the relative importance for each service of availability, incident/request turnaround, customer feedback and the key measure (moment of truth) by which that service would be viewed by the customer.
- This was all started and ended with customer discussions so that they could review and verify what had been agreed. Most of the customer changes were tweaks, with a few larger alterations, but in general it was a good reflection and the customers are now happy to get a simple compound picture of their service.
- Once the structure and services were defined and documented, the technical teams were then asked to define their configurations that supported the services. In fact, this proved to be one of the most useful and to me positive parts of this project, as there are now a number of really well-put-together maps and simple documents that explain how each service is comprised, with relationships etc. It’s a great DR tool, but it’s also a great source of helpful information for problem determination and root cause analysis – all in one place…
- It’s not a huge organisation (global investment managers), so that definitely helped in terms of gaining access to the right people and being able to make decisions.
- Finally as I mentioned the organisation did this themselves – they used external services in a guiding and mentoring role, with some initial ‘kick start’ activity. As a result, the level of ownership and commitment to this working has been excellent. I do see the value of consulting as helping people and organisations to make positive change happen, rather than forcing it from the outside. Certainly in this case the desire came from the right place in the organisation and this really made it a success. I’m delighted for all those who have contributed, however.