Monday, August 21, 2006

Favorite ITSM Tool?

Boy wouldn’t I like to come out and say I have a favorite tool for ITSM. Wouldn’t I love to say that there’s a tool out there that will meet a company’s current needs and is scalable for future needs. But you know what I’m going to say. I will always defer a tool discussion until I understand what the client really needs - there are just too many variables to do otherwise. I had an engagement with a major financial organization to establish a roadmap for an ITSM implementation. While interviewing stakeholders I somehow stumbled across a financial analyst who had worked on a “process” project the year earlier. Note the parenthesis around “process” please because it’s obvious that ‘p’ word never entered into the project lexicon in any way. This guy wasn’t hiding from me but he was never mentioned on my initial inquiry as to who should be interviewed to establish the roadmap parameters. He told me the IT department had spent nearly half a million dollars the year before trying to put a tool solution in place. Now, a year later and a half a million in the hole, they still had no automated change in place nor did they have anything resembling an integrated or scalable configuration management process. Now THAT was a critical piece of information for the program. Now I had to do a root cause on this now visible failure. It was a critical piece of information as this legacy would impact the attitude toward my program. It quickly became apparent that the organization had jumped into an automation solution before really understanding their needs, let alone their processes. As they began developing the solution, they had no project management thus no factors for success and no means to control scope, measure progress or report status.

I suggested, and they eventually agreed, that we use a tools assessment process based on Six Sigma prioritization technology to make sure the program had the right specifications in place BEFORE we spent any additional money. Such a structured evaluation is critical because it provides everyone a means to objectively evaluate any existing tools before looking at vendor products. That way, everyone understands the gaps in their existing tool architecture and is better equipped to address specifications with the vendors.

We all know, of course, that ANY tool with work, in some fashion, if you throw enough money and resources at it. One of my favorite programmers in a former life described this as S.M.O.P - a Simple Matter of Programming. But as the above-described client found out, that was the wrong approach as the “S” is usually translated as a “$”.

I’m still amazed, however, at the laissez-faire attitude this client had toward this black hole. They didn’t think it worthy to mention while we were building a strategic implementation plan. Even without effective project management, even lacking specifications, how is it possible to spend half a million dollars and still get nothing at all - and not feel the least amount of remorse for such an act? Oh, wait. No, I know what you were thinking. But no, this was not a government client.

0 Comments:

Post a Comment

<< Home