Preparing for ITSM Tool Implementation

If you are just buying or have bought a shiny new IT service management (ITSM) tool – congratulations! You have many good opportunities coming up to develop your service quality, sort out issues, and generally get more value from your service delivery. Often the procurement projects can be major projects in themselves – it might seem that the hard work is done and that you can relax.

There’s much to do, however, particularly in the next period before the vendor arrives or you spin up your new system. This will in fact be a major influencing factor to determine the level of success for your project and tool implementation.

You may have bought some vendor consultancy and training services to help you to move from your current state to a new world of optimized functionality and operation. All vendors and approaches, regardless of the level of external help used, will make some quick and pressing demands on you to make decisions around structure, data, forms, fields, and tables. In my experience often these decisions are made quickly and without a full understanding of the impact on outputs, reports, and operations.

So it’s important to move quickly towards a common understanding of some key concepts in order to make the right decisions. It’s really useful to take some time and see the bigger picture for data structure, in order to avoid rework and disappointment in the future.

It’s also essential, as part of the project, to take a practical look at what needs to be done, by whom, and when – logistics can be a real killer for organizational change projects. Project Management needs to be pragmatic and resourceful, rather than just following ‘standards’ or ‘best practice.’ ITSM is very definitely NOT a traditional IT Development project.

So let’s look at some key areas where you can prepare early and get ahead of the game:

Data

You’ve probably thought and documented a lot around software functionality – many RFPs go into great detail around specific process functions.

However, the big challenge that gets forgotten and needs to be addressed and defined quickly is: data!

Your vendor will probably provide you with a data workbook in some form or another, requiring you to provide them (or for you to do yourself) with information about the structure, format, source, and content of your tables. This of course is needed to build the system to work for your organization and will in turn provide the basis for your reporting and performance measurement.

Some key questions to answer:

• What data do we need?
• What format is required?
• Where can we access this data?
• Who owns it and is responsible for its quality?
• Is the data usable as is or does it need to be cleaned/modified?
• Dow we need to create some new data from scratch?
• How and when will we transfer this data?
• How will the data be maintained in the new system? By whom?
• Will the new system be the single repository of the data and/or is a regular update required from the original source (e.g. Active Directory)?

These are all important questions, and from a practical point of view there needs to be clarity in planning the migration and ownership around data, i.e. securing key technical resources when needed (from both parties), ensuring that access to original data is agreed and planned, provisioning suitable platforms and storage.

All of these areas need to be coordinated in order to avoid waste and delay. I have witnessed this happening many times, where expensive people have been sitting around twiddling their thumbs, burning precious project funds because a Database Analyst (DBA) hasn’t been booked or on-hand to provide access to corporate systems on agreed and business-critical dates. Be warned!

Types of Data

So what sort of data do we need? This is a key area to do some workshops on as soon as possible and get some common understanding and consensus in advance of working with the vendor.

Organizational Data

This is basically your organization and your Infrastructure. These may seem to be different areas but ultimately they form the backbone of your organization and against which you will log events – and in which format you will want to see outputs. This includes:

• People / IT teams / user departments / projects
• Sites / buildings / rooms / workspaces
• Regions / geographies
• Configuration Items (CIs) – assets, hardware, software, infrastructure, applications (generic and specific)
• Configuration – linked CIs, dependencies, infrastructure maps
• Knowledge – known errors and corporate resolution history, FAQs, information

Service Data

This is where you define the ‘service layer’ of your operation. It includes all the warranty aspects of your delivery, including:

• Service definitions – owners, customers/users, business functions, business criticality, risk
• Service Level Agreements (SLAs) and Operational Level Agreements (OLAs) – availability, response and fix, key metrics, relative priorities
• Service hours / calendars
• Contract and financial details – charging mechanisms, thresholds, penalties
• Support/supply chain information – service hours, support model, support groups, escalation details
• Customer experience – CSAT measures, feedback mechanisms

Transactional Data

This is to support the standard ITSM operational processes, during the fluid lifecycle of incidents, problems, etc., including:

• Priority – impact / urgency
• Status – accepted, pending, closed, etc.
• Logging category*
• Closing category – cause codes, actions taken
• SLA status and reasons for failure
• Problem, change, knowledge links
• Audit trail – user, based, audit trail, social interaction

*Category is often misused and can include data that is already recorded elsewhere. Some operations use this to record high level service definitions, whilst for many it is simply an initial identifier of the incident ‘type’ for escalation purposes. It’s important to separate logging categories from closing (causal) categories – if you want to improve quality and problem management.

It’s vital to be absolutely clear on the definition and usage for this field as it can often confuse staff and lead to inaccurate or untrustworthy output data.

Reporting

An essential element in defining your data structure is the requirement for Management Information – reports, dashboards, etc. – that will be outputs from the ITSM system. These include:

• Volumes of interactions, by department, IT team, region, category, input channel, SLA, etc.
• Service availability and support performance
• Breaching of SLAs and operational targets
• IT team performance, first-level fix, escalation count, backlog
• Dashboards and Red, Amber, Green (RAG) status of services and operational performance
• Consumption of services and request demand
• Costs and ROI on services, products, components
• Asset costs and depreciation

Project Management

As we can see there is plenty of data definition and collection to do in order to prepare for your new tool implementation. The other big challenge area is Organizational Change Management – not just introducing new processes and tools, but making people want to follow news ways of working.

I’ve already mentioned that ITSM is not a traditional ‘development’ project and this means that we need to think carefully about what sort of person is given the task of leading this project. This needs more people and communications skills than might be expected from the traditional development manager. This cannot be someone who has just been on a Prince2 course who only shows up once a week to check on ‘deliverables’ and enters these into Microsoft Project, then disappears.

A successful ITSM project requires someone with great practical, organizational, communications, and influencing skills. I’d prefer to see someone who isn’t technical or even an ITSM expert (although it helps) but who can command respect and get things done – a completer/finisher who knows the organization.

The best ITSM Project Managers I’ve worked with have had a good combination of skills – organization, technical, and ITSM. However it’s hard to find these people and from a practical perspective it can be useful to find someone with some or most of these skills, perhaps topped up by some extra skilled help where needed.

So, when you are kicking off your ITSM tool implementation, get moving on data and project management. The planning will save time and improve value.

Image Credit