Top 10 Considerations for ITSM Program Success

• ITSM

August 14, 2017

A Checklist For ITSM Program Success

When establishing an IT Service Management (ITSM) improvement program, the most common questions that arise tend to be: “How do we get started?” “What is the goal?” “What critical knowledge do we need from People, Process, Product and Partners perspectives?”, etc. This is understandable, especially, since the ITSM program is a people project, supported by tools and processes. However, many times, this program is mistaken for ITSM tool implementation, or process documentation projects. To understand why this is a mistaken identity, lessons from hundreds of customer engagements will be elaborated upon.

Sometimes, well-intended ITIL initiatives also fall short of expectations due to skipping over minor factors during the initial assessment. This can be avoided by using a high-level check-list to identify if a gap exists in your current or future ITSM program strategy. Only through such assessments can critical gaps be filled and a roadmap be developed to fill those gaps in a logical and strategic manner.

In this post, Top 10 Considerations For Successful ITSM Programs, author and ITIL expert Troy DuMoulin provides an excellent summary of key considerations you and your IT Service Management process improvement teams need to consider to ensure successful outcomes.

The First Step towards ITSM Success

So you have taken the ITIL Foundation course and possibly even one or two of the intermediate level certifications and have now been asked to setup and establish an IT Service Management (ITSM) improvement program!

Congratulations, you have been entrusted with a key element of your organisation’s plan to improve service delivery and customer satisfaction. Now the key question is: How do you get started on this major task and what critical knowledge do you need to consider from a People, Process, Product and Partner perspective?

The First Step Is To Understand The Goal!

ITSM programs are really people change initiatives, but that they are frequently mistaken for an ITSM tool implementation or process documentation projects. Because of this mistaken identity, many frustrated IT leaders have invested significant resources, time and money and received very little benefit or return for their efforts.

To avoid becoming an unfortunate statistic, it is critical that you start your journey with a good understanding of the goal you are being asked to achieve and to make sure others, especially your manager, does as well. The following lessons-learned from hundreds of customer engagements provide insight into why this to goal is often not understood or realised:

ITSM and ITIL projects are actually transformation programs requiring significant shifts in behaviour and cultural change across multiple groups that need to define new ways to work in a common manner;
Process documentation is not worth the paper it is printed on without the political ability and organisational will to enforce its use;

• An ITSM tool alone will never enforce new behaviours or best practices;
• Most organisations fail at their initial process improvement efforts by focusing on the technology or tool elements of the project and underestimate the effort required to address the less tangible people and governance issues required to support transformation effort;
• Most projects reveal clear, early people-related warning signs that the project is at risk but these signs were missed, ignored or not managed
• IT professionals prefer to focus on the tangible project deliverables that are within their control rather than wrestling with the people challenges related to attitude, behaviour and culture
• The Goal of ITSM is to get disparate functional groups to work in a common manner based on accepted industry best practices to deliver services that their customers want and value. ITSM is a people project supported by tools and processes, not a tool or process project supported by people!

The first step is to realise that the true goal of an ITSM initiative is to establish a common and efficient approach for the various functions within the IT value chain in order to deliver stable and reliable IT Services to the customer. Process documentation and the underlying IT tools are simply a means to an end, not the end themselves. To avoid repeating these common mistakes, your ITSM program must target the true goal, have the leadership support and address critical success factors.

Evaluation Check-list For ITSM Success

The following tables represent a high-level check-list for you to use when developing or evaluating your ITSM program approach. Use this check-list as the basis for determining if a gap exists in your current or future ITSM program strategy.

1. Effective Project Controls & Roles

• You are applying formal Project Management practices, resources and have controls, and project governance is in place;
• The membership, authority and effectiveness of the projects’ sponsorship and senior steering committee match the organisational scope of the project;
• People’s time, resources and funding are available to the project for the full lifecycle (Plan, Build, and Deployment).

2. Management Of Change Strategy

• Both internal and external stakeholders have been identified and included in a formal management of change plan to move attitude, behaviour and culture to the future state;
• There are ongoing practices to identify, assess and manage people risks related to the project.

3. Integrated Project Plans

• The process, tool and management of change aspects of the program are managed as one integrated and interdependent work tasks;
• There is a clear understanding of which process and tool elements must be designed and configured as shared across multiple process areas.

4. Continual Service Improvement (CSI) Strategy

• A CSI strategy and process is defined, including the definition of a consistent and effective measurement framework to ensure the processes continue to meet business needs;
• You have identified specific people within the organisation to develop ITSM subject matter expertise, to support current and future service improvement.

5. Awareness and Communication Strategy

• The vision is clear, and there is widespread understanding of the vision and objectives of the program as it relates to strategic business and enterprise IT goals;
• A plan and means exist to build to an adequate level; the knowledge ITSM principles to support the ITSM program objectives and deliverable;
• Key stakeholders have been identified and their individual communication needs defined and scheduled into the overall project plans;
• An education/certification plan is approved and funded to equip the project resources with the knowledge needed to design and/or review the project artefacts and deliverables;
• Deployment workshops have been scheduled and developed to train IT staff on the company specific process, policies, tasks, and tools required as part of their jobs.

6. Ongoing Process Ownership and Management Roles

• New process ownership and management roles are defined and resourced at the start of the program, and included in the design, build and deployment tasks of the project;
• An ongoing process governance structure/council has been established to provide oversight and approval to proposed changes and to support future improvements;
• External suppliers are integrated into the process ownership and management structure;
  There is a plan and means to adjust the department, individual and external contract reward systems to align with ITSM goals.

7. Policies, Processes, Roles and Metrics

• The goal and objectives of the processes have been defined and agreed to;
  Enterprise polices have been defined to establish expectation and support compliance;
• High-level workflows have been documented and incorporated into training and communication deliverables;
• Process integration is understood and incorporated into requirements management, design and automation activities;
• Detailed role descriptions have been documented establishing the accountability, responsibility, and communication expectations for the new and changed roles;
• Detailed procedures, business rules, escalation policies, and process forms have been defined as required, based on the workflow, and automation requirements generated from the high-level process documentation and roles;
• Key process classification structures, artefacts, decision criteria, work instructions are defined (e.g. priority matrix, categorisation criteria, risk matrix, service catalog structures and Configuration
• Management Database object models);
  Critical success factors and key performance indicators have been selected to support the process and policy goals and objectives;
  Process measures are presented on management dashboards and reports, and support continual process improvement.

8. The Tool Supports ITIL Best Practices

• The tool requirements are driven by process requirements and not the other way around
• Where possible all process participants use the same tool
• Current and future process integration requirements are taken into account for selection
• Process module integration is understood to be of higher value than best of breed point solutions
• Tool customisation is avoided where the proposed change will break the original intent of the software

9. Ongoing Tool Administration and Improvement Structures and Processes

• A function has been established to install, configure and administer IT Management tools used by enterprise IT processes;
• A process exists to receive, assesses, approve and prioritise changes to the ITSM tool.

10. Tool Configuration and Testing Done In Parallel With Process Design

• The tool configuration is done in parallel, and in coordination with the process design and documentation efforts;
• Separate development, production and training environments exist to support new or updated process design development and testing without impacting production;
• The development environment is used to prototype and test, process and policy designs as part of the process-building phase;
• Testing plans include process, technical and user acceptance testing, based on functional requirements, non-functional requirements, and usability criteria;
• Testing plans include integrated testing to determine the impact on other processes already deployed within the tool;
• Testing plans include process, technical and user acceptance testing, based on functional requirements, non-functional requirements, and usability criteria;
• Testing plans include integrated testing to determine the impact on other processes already deployed within the tool.