Four Things That May Be Derailing Your ITSM Activities – Part 1

Sometimes it is a good idea to stop for moment, to take stock of where you are and where you want, or need, to be. Especially when you work in a hectic and high-pressure role such as IT support – I often feel that I’m so busy running around that I forget which direction I should be running in. Not so much “Joe the IT Guy” and more “Joe the Headless Chicken.” With this in mind, how is your IT service management (ITSM) going?

• Is the “ITSM team” meeting its goals?
• Does the business feel that they receive the value the IT organization promised?
• What is the improvement plan for this year, and the year after that?
• Are you happy doing this type of work?

All difficult questions and, mostly likely, me asking these questions immediately invoked some form of feeling in you. Maybe a feeling of success? Maybe a feeling of fear? Maybe a feeling of failure? Maybe simply “meh”?

How Did You Feel?

If you answered with “a feeling of success,” then congratulations! And can you come help me please?

If your answer is anything else, you might be asking yourself “What do I need to do in order to get things back on track?” It’s a valid question but it is not the correct question. You really need to be asking “Why are things off track?”

This blog covers two things that may be derailing your ITSM and improvement projects in particular. And the second part of the blog will add another two.

A word of caution before proceeding though. If things are off track, and pardon my ITSM cliché, then you should undertake appropriate problem management activity to determine the root cause. As trying to blindly implement a solution by simply reading my blog may not help you reach your goal. Instead you need to make sure that you have the correct solution for the correct problem.

Derailment #1 – Lack of Executive Support

Just like any IT initiative, the executive team needs to be committed to providing their full support to ITSM activities. In many cases, if ITSM is suboptimal or failing, then this issue may be a primary cause of derailment.

Of course the executive team members will have their own issues to worry about, such as: the high-value IT projects they are trying to complete on time and within budget, and their view of the priority of these IT projects against the day-to-day ITSM activities; the need to balance the resource pool across the project portfolio; and the customer/stakeholder opinions of IT productivity and efficiency.

With these pressures on their mind, executive team members may look at ITSM operations, and improvement projects in particular, as an albatross that may not help the IT team or more specifically, their own team(s). To help you determine if this is the case, consider the following:

• Can the executive team members verbalize the value of specific IT services and those that manage them?
• How often do you (or the appropriate person(s)) meet with executive team members to discuss how ITSM day-to-day activities and associated improvement projects help their team(s)?
• Are core ITSM processes documented and followed by business teams? If not, why not?

What you might uncover is a complete disconnect between what the ITSM team wants to achieve, what they think they achieve, what they actually achieve, and what executive team members think about the ITSM team. Sorry if that was a little “Donald Rumsfeld.”

And if you conclude that ITSM is misunderstood and potentially undervalued in your organization, this is how you can improve the situation:

• Schedule regular meetings with executive team members to discuss their business and IT issues. Explain how ITSM personnel, processes, and improvement projects can help to solve their biggest problems.
• Ask executive team members when/what they are communicating about ITSM to their teams, if at all. Help the executive team craft the communications to their team members if you think that this will help improve things.
• Establish a “ground rule” of only discussing ITSM and how the processes can help if you are the only one meeting with the executive team member(s). Such discussions need to be concise and at a high level, and having colleagues chipping in with extra detail will probably make it the last time you get an audience with that executive team member. And definitely don’t start a support tool discussion – no one other than you will be interested.

Derailment #2 – Silos in Action

Along with the right people, well-documented and well-executed processes are the backbone to any successful ITSM capability. Your day-to-day operations or improvement project can quickly derail if a team simply does not follow processes. This is often the work of silos in action.

Regardless of whether you call it “office politics,” “finger pointing,” “turf wars,” or some other phrase, it is siloed behavior. And such silo thinking can ultimately damage the reputation of your IT organization and potentially your parent organization. Example identifiers of potential silo behaviors include when:

• Team members only want to discuss a process within the boundaries of “…what occurs in our area…”
• Team members state “…that’s not my job…” or “…it’s team x’s fault…they’re not pulling their weight…”
• Teams seem to work against each other
• Teams and team members do not seem to rally around a common goal
• Customers mention that they see “confusion” in the processing of their requests/projects

If this all seems familiar, this is how you can improve the situation:

• Communicate the ITSM goal in question – work with executive leadership and team leaders to ensure everyone understands the goal and why the goal is important for the organization.
• Audit processes – audit data can show where teams may disconnect with each other, whether that be intentionally or unintentionally.
• Measure the right things related to operational and service delivery performance – a good set of metric data can show how teams perform within a process and help to build understanding of how one team’s actions may impact other teams.

In part two, I will examine two other derailments – “Cookbook” implementations (now I feel hungry) and the biggest obstacle of all.

Image credit