Case Study – Considerations on a major Service Management Implementation
Posted on 04. May, 2009 by Sunit Prakash in IT Service Management
Introduction
A major national bank commissioned its telecommunications vendor to refresh its data and voice network, roll out voice over ip (VoIP) telephony nation wide including all branches, regional and softphones at corporate offices, and implement a new billing and reporting system. Each of the streams was run as sub-projects within the overall program. Service Management sat across all 3 technical silos.
Coming to the end of a 2 year Service Management implementation, here are some reflections on what went particularly well, what did not go so well, and what I would do differently if it had to do it again.
Background
This was a managed outsourced service model, it was incumbent on the service provider to build & deliver the solution. As the specialist from the client side, the role was to ensure Service Management requirements were captured, met, agreed processes documented, the service management solution built, tested, accepted and rolled out.
In some ways this was the easy bit. The hard part was determining what the optimal Service Management solution would look like. The client had atleast 2 sets of IT service providers and so also atleast 2 sets of processes for end users to access technical support. This was based on their heritage of two previously disparate organisations coming together and with it the issues to do with multiple process protocols, reports, service levels and differing end user experiences.
The scope for improvement was tremendous, and also obvious. As a first step, impacted services were reviewed (eg: desktop support on account of softphones) and a new, harmonised service management model built. This involved transitioning several service desks between internal and external service providers.
The Gotchas
- Security – network infrastructure is a key business enabler for any financial institution; group security policies need to be converted to requirements; these need to be translated into design and then when built tested and accepted. Do not underestimate the time and effort this key activity takes;
- Silo Approach – stock standard ITIL processes, even if customised for a client does not work. Based on the end-user or the technology, Service Management needs to build processes that suits each the constituent user of that particular solution (eg: the Incident Management process for a softphone user will be different from the process for a power user of the billing & reporting system); beware, generic cookie cutter processes will not work across all silos;
- The network touches everything – be prepared for the unexpected; in this instance, even though ATMs were outside of the scope of the project, Service Management processes needed to be put in place since changes to the network infrastructure impacted on ATM monitoring and alerts. New processes needed to be agreed;
- Work Requests from End Users – the stock standard ITIL processes “assumed” the process would kick of once the work request was received by the service provider. It became evident that to get the work request from the client organisation to the vendor organisation was a major “gotcha”; the vendor organisation understandably required detailed information to provision new phones or services, this needed to be balanced against complexity of the form and the end user experience….and also physically make its way across. Spend time to ensure the interlocks are properly understood and defined;
- Organisational Change – in a project spaning several months, and in today’s financial environment, the only thing that remains constant is change. As the client organisation flexed and changed, processes that were initially built to cater for one or two individual end-users at a time needed to cater for “bulk” changes; make sure your processes are scalable to allow for changes relating to tens or hundreds end-users;
- Organisational Change and System Owners – as a corollary to the above, managers and staff members who had participated in the requirements either moved on to other roles, or were performing dual roles while newly created vacant ones were being filled. In this environment, as the new solution started coming online, finding “business as usual” (BAU) system owners to take ownership and manage will have it challenges;
- Process Documentation – often a key deliverable to ensure that the service provider properly documents processes, make sure you agree the level of detail that will be written to. It is easy to “copy & paste” stock standard ITIL processes, it is another thing to customise them so that interlocks, communication & communications between the two organisations is documented properly. It is important to understand the difference between the procedures manual and work instructions; decide what is most appropriate for your situation;
- Technology supported by Multiple Parties – softphones is a good example where an end user may have a simple issue (not being able to make a call), but the underlying problem could be with any number of internal of external parties (pc, cable, headset, lan, network, telephony infrastrucutre). Per item of technology that the end user touches, use “use cases” to work out all the processes that need to be in place to support the customer;
- Levels of Maturity – it is possible that both the client and the vendor will agree to use the ITIL framework. The project management and delivery methodology needs to be robust enough to take into account and cater to the different levels of maturity of the two parties. Generally speaking you are expecting for the vendor to have a higher level of maturity than the client’s, all hell will break lose if it is the other way around !
What went well
- Vendor Team – comprising the “A Team” of an accomplished Project Manager, ITIL subject matter experts & very committed BAU staff working and pulling together to deliver the solution; make sure the project team and the BAU team are engaged constantly and that the solution is not built and “thrown over the wall”;
- BAU Team – for the solution to be built properly, and then for ownership to be taken by the BAU team, the client BAU team needs to be available for workshops and reviews. Ensure the BAU team are involved and have skin in the game.
- Service Management Technical Architect – ITIL processes are fine, a large component involves the toolsets that support and deliver Service Management. These include not only the Service Desk tools themselves, but also network monitoring tools, alerts, auto-ticketing, security considerations etc. A top notch Service Management Technical Architect to review the system design is invaluable;
- Service Desk Cutover(s) – a project of this magnitude will involve setting up new service desks, as well as transitioning existing service desks from one provider to another. Be very proactive in managing these transitions, they are very visible changes and not doing them properly will generate negative user perception of the entire project;
- Reporting – a key deliverable. If you start with the end in mind, these should already be well defined in the requirements. There is no need for long drawn out workshops to discuss the reports, expect a draft template and fine tune them into production;
- Timing – “security” requirements, implementation and sign off being a good example of how short lead times make for quicker acceptance. Security was the last cab off the ranks in terms of design review, the shorter the time gap between requirements building and solution delivery, the quicker and easier it is to accept and implement.
If I had to do it again, what would I do differently ?
- Reduce rework – ask the vendor to table existing material in terms of process documentation. Review for level of detail and applicability to your situation. Ensure you are not paying for a copy & paste job from standard ITIL books. See comments above relating to understanding the difference between a Procedures Manual and Work Instructions.
- Use Cases – for each technology silo, define typical end use cases. Break them up into “get it”, “use it”, “fix it” or “retire it”. Then work the process from the customer backwards; make sure this includes any forms, test the flow of forms from the client to the vendor and the feedback loop. Test the interlocks particularly if more than one internal or external service provider is involved.
Net nett
With the new network being rolled out, the ITIL processes designed have gone live are being stressed and used in anger. The BAU team from both the vendor and client side have stepped up, taken ownership of the solution and engaging at different levels. Already operational & SLA reports have been tabled and reviewed. Open items in the risk register, workarounds and open issues will be closed or handed to the BAU team.
Service Management moves on to the next phase of the project; building a model to include multiple vendors so that the technical solution can be extended to other parts of the organisation.
