DIGANO - Making a Difference

Implementing IT Service Management: People Some organisations don’t like ITIL, because they’ve tried a whole bunch of other quality frameworks and quality methodologies before, spent millions of dollars and achieved absolutely nada, zilch, nothing. ITSM isn’t about ITIL at all - not for a single bit (or byte). ITSM is about improving your current work practices and instigating a culture of continuous self assessment and never ending improvement (CANEI principle). Improving and changing doesn’t start with someone else, it starts with you. It’s me, myself and I that need to change first, in order to change the environment. That’s what “leading by example” is also all about. I show my new behaviour, I show the intrinsic embedded value, and any smart people out there should start copying me. So, depending on the current culture and attitude towards ITSM or any other quality frameworks and methodologies you may want to consider introducing ITIL not as something new and out of the ordinary, but as something that's going to make everyone's life a whole lot more pleasurable. We're going to improve the current way of working, not redesign it.

Implementing IT Service Management: Processes So many processes, but you don’t have enough people to manage all of them individually? No problem! It’s relatively easy to combine ownership for two or more processes, as long as the roles don’t bite each other! Some processes have a natural conflict of interest, and combining process ownership for them may not be a very wise idea. Making the same person both Incident Manager and Problem Manager may not be a very good idea, not at a management level, but combining the role of Change Manager, Release Manager, and Configuration Manager doesn’t have to be an issue at all. Please realise that we’re discussing the process managers here, not the actual roles responsible for carrying out the various tasks that are performed as part of the process.

Implementing IT Service Management: Products Some functionality may prove to be an absolute must, whereas other functionality is more a nice to have, more like a bonus. For example we may have a functional requirement to capture a customer’s first name and surname as part of the Incident details, it would be nice to capture it based on caller ID, but this is not absolutely necessary. If may be useful to apply weighting factors to the various “must have” and “nice to have” functional requirements.

It’s recommended to set a fit-for-purpose matching score before sending out all the requirements to the various tool vendors. An 85-95% match of what you require isn’t asking too much! Going for less may prove very expensive afterwards because of all the customisation that may be required to match the tool to your specific conditions. Tools that score below your matching score shouldn’t be considered, unless there are no other options available, and this is hardly ever the case with the amount of choice available. It’s also recommended to provide the tool vendors with one or more some scripts that represent how you work and what you want. Their demos always work, and are customised to their tools and their people demonstrating it, so create your own demo! A script going from one or more of your Incidents all the way to one of your Releases will really demonstrate the usefulness and suitability of the tool.

Implementing IT Service Management: PartnersFortunately ITIL v3 provides guidance on how to deal with partners, vendors, and suppliers, and introduces concepts like Service Strategy, Service Level Management, and Supplier Management. It should be obvious that strategic partners deserve more observant care from the business than non-strategic partners. Paper and toner supplies are typically easily replaced, but a full outsourced datacenter isn’t. In other words it makes sense to classify (categorise and prioritise) our partners, and mark/score them appropriately. What underpinning services are delivered by each of them, and what are the dependencies within our own organisation? Strategic partners may well need their own dedicated Supplier/Contract manager, whereas many smaller Suppliers could be bundled and packaged together.

The duration of a partnership should be carefully considered, and the consequences of partnerships going sour deserve even more attention. What are the risks? What’s the impact, and what’s the likelihood that it may happen? A full business impact analysis (BIA) and integration with the business continuity management (BCM) process should be considered, as it’s better to be safe than sorry. Exit strategies, safeguards and alternatives should be considered before a partner deal gets signed – the world is fantastic place, but it isn’t a perfect world as yet. The possibilities of building more efficient and more effective organisations with your partners are endless, and the world today wouldn’t exist without all the fine tuned and carefully managed partnerships in place, where the keyword in ITIL is “managed”.