An intercontinental tools implementation proposal - part 2
Guest Author: Bruno Calver
In my previous blog entry I spoke about some of the general aspects of what to consider when specifying an ITSM tools implementation project, as well as some of my experiences working offshore. I also highlighted that it was imperative to show you understood some of the client’s challenges. I want to explore this area in a little more detail and discuss some of the questions and challenges that our client was facing.
Our starting point was to demonstrate our alignment to, and understanding of, the client’s business drivers, strategy and tactics. These were implicitly and explicitly stated in the Request for Proposal (RFP), official publications and also based on our knowledge of the client organisation. The key themes were simplification, standardisation and efficiency. No surprises that reducing the Total Cost of Ownership (TCO) also made an appearance. We ensured that these points recurred throughout our proposal.
The next stage was to consider the specific challenges the project might face during implementation and present our solutions. At this point there was a mild tension between focussing on technical challenges and project challenges. The key thing here was to try and understand the audience and adapt accordingly. Let’s take a look at a few of the top challenges and our solutions.
The client wanted to implement an out of the box ITIL based tool, this challenged the existing environment, which was highly customised. Organisational stakeholders have been used to having things their way and so more than a technical challenge this would be a cultural issue. The benefits of this approach stemmed from the clients key themes, simplification and standardisation of the existing environment (and therefore lower TCO in terms of support and future upgrades) and efficiency resulting from alignment to best practices. We suggested a two pronged approach, kind of a good cop bad cop tactic. Good cop was to undertake an exercise to understand the existing environment and start building consensus around the benefits of a standardised environment and put in place measures to address the key organisational concerns. Bad cop was to establish an early requirements baseline and put in place a robust and authoritative Change Control Board (CCB) that would require thorough justification for any deviations.
The next challenge was technical, mainly around the process implementation order and infrastructure platform. Again the aim was to simplify the architecture onto a single shared platform, in turn reducing the TCO. In addition clear guidance was required on the correct order of implementation of the various process/service management modules to simplify the project approach. Our proposed solution showed a clear point of view on architecture and an assessment approach regarding the existing platform's long term suitability. We also showed the dependencies between the processes and a recommended order of implementation. For example, Change Management must be prior to Service Request Management as service requests often become changes and transferring tickets en masse between tools is not desirable.
The last challenge I wanted to talk about (there were others of course) was around managing the risk of business disruption leading up to and following the stages of cut-over to the new toolset. In preparation we would need to train users across the globe in varying concentrations. We also needed to suggest ways of reducing the risks of disruption following the actual cut-over to the new tool. The benefit of this would be to reduce the operational cost of the implementation. Our proposed solution was many fold. First we would deploy training through a variety of channels, including class room sessions for larger concentrations of support groups and NetMeeting for lesser numbers. We also suggested combining process training with tool training to reduce the time out of the day job for support staff. On the preparation front we suggested a sand-box environment for remote life like testing/practice on the new tools. As for the cutover itself we included the suggestion of a pilot rollout first, then a main rollout building on the lessons learned from the pilot. In addition, a rapid response hotline would be provided to enhance early life support. The last piece of the puzzle would be to have clear live cut-over testing plans and a back-out procedure to provide an escape route if needed.
Hopefully the above gives a flavour of some of the typical challenges faced when considering an ITSM tools implementation and some of the options you might consider to counter them. I think it is fair to say that the first challenge is the most significant and requires the most time and energy in addressing, especially where you are working with a global organisation. Sponsorship from the client organisation is usually a critical success factor.
On a lighter note, one of the interesting debates when working on this proposal was whether it was acceptable to use capitals for the first letter of words in titles or that they should be reserved only for proper nouns. My feeling is that the trend is moving towards only using capitals for proper nouns, especially in presentations where there are many titles. I think the rules of language are actually defined by use rather than any kind of official guide, any thoughts on this?
That's all for now, my next blog entry will be talking about the good and the bad of offshore consulting delivery and some aspects of life in India...
