Why doesn’t this work? Don’t blame the ITSM Frameworks

ITSM Frameworks Confusion can be a factor in failed ITSM initiatives

A common problem

If you stop and think about it, I will bet all of you reading this have heard (or said) the words “It isn’t working!” or some variation of them in the not too distant past. The reason I believe this is a safe bet is based on probability, because our world is filled with more opportunity than ever before (thanks to ever increasing technology applications and connectivity and methods for handling them) to encounter something that just is not behaving the way we want (expect) it to.

Not that this situation is new; every technology or methodology change introduced the same effect, with some embracing it, others avoiding it, and the rest somewhere between. The bad part is that we will never leave this situation behind – people are people, and there will always be those filling the lowest-to-highest positions of knowledge or skills across the spectrum of any topic. The good news is that these days the naysayers are not typically looking to burn those occupying the higher end knowledge (Earth goes around the sun, etc.) at the stake.

Though I accept the situation for what it is, there is a side of it I have to admit will always perplex me: when someone that is not using the item as intended lays full blame on the item itself for not delivering the desired outcome.

Sound familiar?

A recent example I have is watching someone (purposely generic in case they read this) interact with the TV and related components. The scene went like this:

Them: “Why doesn’t this work?”

Me: “What can’t you do?”

Them: “I want to find something new to watch, but the remote won’t bring up the guide. It keeps showing me these settings instead.”

Me: “That’s the TV remote; to see the guide you need to use the cable remote.”

Them: “Why can’t I see the guide on the TV? That is what I am watching!”

Me: “Yes, but the signal is coming from the cable, so you need to use this cable remote. Here you go.”

Them: “Well why does it matter which remote I use?” (Takes and uses the cable remote; the guide appears). Pause…then, “Stupid TV”.

Of course, similar conversations go back as far as, say, the use of Fire – like this one from 900,004 years ago (translated from early Homo erectus):

Og: “Why doesn’t this work?”

Bob: “What can’t you do?”

Og: “The fire is getting low so I keep adding wood but it just makes smoke and gets worse.”

Bob: “That wood is wet; fire doesn’t work on wet wood.”

Og: “Why not? Wood is wood, and wood burns!”

Bob: “Yes but the wood has to be dry or the fire won’t burn it.” Gathers some dry sticks and offers them to Og. “Here you go.”

Og: “Well why does it matter which wood I use?” (Removes the wet wood, replaces with dry. Fire burns nicely.) Pause…then, “Stupid fire”.

Most of these exchanges are related to items that are used on a daily basis by the people having difficulty. I used to ask “Did you read the directions?”, or similar, but after enough dirty looks I learned that lesson. Now I just try to gently guide the asking party through the situation, while only rarely getting frustrated to the point that I lose the inner battle that keeps me from saying “It isn’t the XXXX, it’s you.”

Tried it….did not work!

Which is of course where this has been going. When I hear (or see in print) someone stating that “ITIL/Six Sigma/LEAN/etc. does not work”, I know that person is in fact simply expanding on an experience they had that concluded with them uttering the words “Stupid XXXX” (substitute methodology of choice). But why? Each of these examples, and many others, have been proven over time to deliver value, benefits, improvement, etc. when applied as intended or adapted as required. Thousands of organizations have accomplished this, and so we know that they do in fact work. But what about all of those that “tried XXXX” but found “it did not work”?

If you have not already guessed, the answer of course is that someone was using the wrong remote. Or adding wet wood to the fire. Or not adding oil to the engine, using the CD tray as a cup holder, dialing the wrong number, or any of the millions of myriad ways humans have found to do or not do something as intended.

Many factors at play

Perhaps it was poor planning. It might have been hiring the wrong contractor. It may have been having the wrong people running the project. There are far too many possibilities to list, but the point remains the same: If your organization ‘tried and failed’, it was not due to these frameworks or methods themselves. In other words, it isn’t XXXX, it’s you – or more specifically, the way in which your organization adapted or utilized one (or more) of these items.

All too often we struggle with that which does not do what we want, rather than reevaluate our path, method or actions to determine what is keeping it from delivering the results we desire. We just know we are doing it right, so there must be something wrong with this thing!

Find the reasons

When something is proven to work but for some reason does not seem to work for us, we have to resist the temptation to blame the ‘something’ and instead take a step back and ask why it is not working. Get a second opinion. Take another look at the remote. Change the batteries. Read the directions. But don’t let yourself become one of those who throughout history have bemoaned the unexpected by saying “Stupid something”. If it is not working, there is a reason; find it, address it, and rejoice in the fact you won’t miss your favorite show – or miss out on expected business benefits – after all.

Share
Facebook
Twitter
LinkedIn
Email
Michael Keeling

Michael Keeling

Michael has been providing consulting and guidance in IT Operations, ITSM and SIAM to enterprise level organizations in many industries for more than 20 years, and has extensive background in data center and service desk operations, technical writing, mentoring, cause analysis and workflow improvement. He is known for bringing the view of a detective to these efforts, perspective he credits to education in crime scene investigation and over 10 years designing processes and performing risk management in the private security sector prior to his career in IT. A confirmed realist that believes no project can be truly successful unless all involved parties are grounded in reality, Michael is always prepared to paint ‘the elephant in the room’ bright yellow when appropriate….