WIREDGOV

Blog posted by: Patrick Von Schlag – President and Service Management Consultant, Deep Creek Center, 13 March 2017.

It’s a natural response for many IT organizations to think about how implementing tools can be the solution to IT problems.

But it’s a big problem, as there’s no magic pixie dust sprinkled over a tool and it can affect people negatively as much as positively.

This issue has reached a critical point as organizations are now looking for more from tools now and the size of the investment is sufficiently large to warrant a different business case. This involves a great deal of risk assessment as the scope and impact is so large.

In this context, internal IT shops are under pressure to demonstrate the value they deliver to the business and, despite the fact that ITIL® provides guidance across the lifecycle, most organizations have taken a limited operational approach to that. This is no longer viable in the context of fast business change, managing risk and demand for agile delivery.

IT tools and ITSM today

Today, organizations are more interested in an enterprise IT service management (ITSM) tool that provides a single system of record; a consolidated view of support and having records in one repository.

While this is a good thing, problems arise when organizations without maturity and experience in implementing service management practices go out and buy a tool first.

The fact is, ITSM is a thousand tiny decisions you have to make; there’s nothing inherently complex, but there is so much detail in order to get consistency in execution. Instead, when organizations without a background in process architecture buy tools they struggle, though tool manufacturers claim that processes are “baked in” to how their tools work.

Consequently, organizations buy a new tool and spend lots of energy turning it back into the old tool they used to hate!

Before investing in a tool, the basic mantra for organizations should be:

1. Establish governance strategy – be clear what your objectives are for developing an organizational ITSM approach and prioritize your success factors such as financial visibility and resource management.
2. Create viable repeatable processes – this isn’t about adopting 26 ITIL processes simultaneously. Rather, introduce a new tool and process capabilities at the same time.
3. Create a set of requirements for a statement of work – provide guidance to tooling organizations and consultants helping in adoption.

Defining roles and responsibilities

Many organizations don’t really take the time to establish clearly defined roles and responsibilities, but they should. Regarding procedures and work instructions, if you are stipulating the use of “impact and urgency codes 1 to 4” can you define what is a 1, a 2, a 3, etc?

This is about establishing process governance by asking and answering key questions and defining procedures specific to your organization. In ITIL language, it’s “adopt and adapt”. Once you have clarity, tooling can be of value in automating processes.

In the spirit of ITIL® Practitioner’s guiding principle “Start where you are”, organizations will probably have existing knowledge, processes and practices. But are they fit for purpose, consistently executed and in line with organizational objectives?

Taking this approach will also support initiatives aimed at creating more agile practices; offering speed, responsiveness to customer need, collaboration and communication. Defining your communications needs will help identify enterprise tools to support DevOps approaches along with traditional ITSM practices.

So, where does an organization begin? The first step could be an experiential programme aimed at getting people to understand why ITSM makes sense; answering the “why?” question before getting into the detail.

A system of record won’t produce the information you want and need unless processes are consistent and of high quality. Indeed, you can get reporting out of your current tooling but you have to question the quality of the data, as this affects the quality of decision making.

Read Patrick's previous blog posts for AXELOS

Combining ITIL and PRINCE2 principles to achieve end-to-end value

PRINCE2® and PMBOK® – a meeting of project management minds?