The silver bullet for ITSM success

Or agile... or DevOps...

bullet hole window
Credit: Thinkstock

It seems now, to me, that we have an IT Service Management framework and standard out there for every taste and preference. There’s ITIL, the preeminent one, but there’s also CoBIT, ISO 20000, TOGAF, IT4IT, USMBOK, lean IT, agile, DevOps and so on. (You might be thinking that those last two are just for development. I digress.) If there is something to do within IT, someone has thought of something and codified it in a framework.

That’s all well and good. In my mind, all of these things strive to do one thing: assist a person, or a group of persons, in solving a business problem. If you think about it, all of this guidance can be used to reach out to customers, find out what they think is valuable to them and then either solve or prevent IT problems in order for IT to deliver value to the customer.

I’m not here, in this post, to tell you which one to use, or in which order to use them. If you ask me, I will probably tell you that it’s not an issue of compatibility, but of applicability (and probably the topic of another post). What I’m here to tell you is that whatever framework or standard you choose to use, it won’t work to its full potential if an essential element is missing.

That element, dear reader, is management commitment.

I don’t want to pay lip service to this. I’ve seen this work, and the difference between committed and noncommitted management is night and day. And by committed I mean as committed as bacon, not eggs (look it up).

It is about believing that what you are supporting will work. It is about sticking to it and not being discouraged by setbacks and mistakes. It is about learning from those mistakes and encouraging yourself, and the people under you, to improve and keep going. It is about trusting that the people under you will do their very best to deliver value based on the work they do. It is about being open in receiving feedback, even negative feedback, and acting upon it. It is about putting political crap to the side and understanding that we’re all in this together and either we all swim toward the shore, or we all crash and burn.

Case in point: Last year, I had the privilege of working on two lean IT projects that were very similar in their objective, scope and desired outcome. But there was one very clear distinction between the two: the way management was involved and committed.

On the one, management was just a tad aloof; you could say distant, even. Some people felt that they were kept at arm’s length, and having a distributed workforce did not help a whole lot. People, I think, felt that management just wasn’t quite "in it." I felt it as well, as an external party. I had the feeling, at the end of the gig, that management could have done more to contribute to the success of the project. Management behaved as... management in an "old school" kind of way. The project wasn’t a failure per se, but...

Fast-forward to the later part of the year. Similar lean IT project, different client. And boy, what a difference! We went in to do our thing and once management "got it," the project took off like gangbusters. Things happened. Barriers dropped, tasks got done. People actually participated, even the skeptics joined after a couple of weeks. Stand-ups were not missed. People felt empowered to do things. Management turned from "old school" managers to facilitators, coaches and enablers. There were a lot (a lot!) of gemba walks. Everything was exposed, open and transparent. Problems were opportunities to become better.

You see, it doesn’t matter what you use. What matters is that whoever is the sponsor or lead of the improvements or of the problem that needs to be solved needs to be involved, needs to be trusting and needs to become a coach rather than a manager in the "old school" type of way. This is also just not about getting "out of the way" of people and their work. This is about truly trusting in your people and in the method, process, activity or whatever you commit your organization to, and understanding that what you are doing is running a marathon, not a sprint.

I also need to say this: As a consultant, you know that you have "good" clients, "bad" clients and everything in between, and you might think that this is a comparison between a "good" client and a "bad" client. Nothing could be further from the truth. Both or my clients wanted to do what was best for their companies and their clients. It is just simply that one was involved and the other was committed (again, bacon versus eggs).

So, do you want to be successful in your IT Service Management improvement project? Get ready to become truly committed. Become a coach, an enabler, remove barriers, stop the blame-shaming and support outcomes, Then go choose a framework (or frameworks) to follow. This is important. Don’t get discouraged with setbacks; always keep moving. Always keep improving. Have an open mind.

So to all of the managers out there who truly believe in doing what’s right to support business outcomes, my hat’s off to you. It is refreshing to see you work. You raise the bar high for the rest of us. Just remember: Never stop improving. Never stop being committed.

This article is published as part of the IDG Contributor Network. Want to Join?

New! Download the CIO March/April Digital Magazine