Service Matters! ITSM & IT Management

Long due and much awaited, the three-four page treatment might still appear high-level and possibly a disappointment to some. What strategy does one adopt to implement an IT Service Management (ITSM) tool? Are there standard approaches? How about investments in existing tools? Any way of maximizing these? How does one manage Organizational Change Management (OCM) during roll outs? Is an out of the box (OOTB) implementation preferable to customization? How much customization? And many more such questions come to mind ... But then, there is only so much that can be covered before everyone starts complaining about the thickness of the books.

A while back, I was involved in a Proof Of Concept (POC) deployment of ITIL Change Management process and the associated out of the box ITSM tool implementation. While there wasn't an initial ITIL assessment carried out in this case, an out of the box POC was the preferred route. Why? An urgent need to ensure safe changes, reduce availability impacts, standardize processes, get rid of home-grown ITSM tools / bespoke applications and so on ... sounds familiar?!

Here are some insights that we re-discovered on our way that I thought might interest you. If you are planning to implement or refresh your ITSM processes and tools, some of these might help you better understand what you are going to be up against. If you are looking for quick answers, tread with caution! This probably will raise more questions …

For starters, a quick question - is it really possible to implement an ITSM tool (and associated processes) out of the box? Why not? After all, you have pre-defined process flows, a defined scope of service / business lines, defined timelines, established business drivers ... sounds relatively straightforward? Hmmm ... think about it. There are some tight and rather intriguing constraints right behind these that you would want to keep in mind when you go OOTB.

What You (Don't?) See Is What You Get: Keep a tab on your requirements
Until the tool is really deployed into the environment, very few actually realize what the tool really looks like. Demos and walk-throughs are good, but only go so far. Net net this means - most stakeholders really don't know what they are up against while specifying what they want the tool to achieve. And to add to this, most requirements end up becoming "must-haves". Even at the fag end of the deployment, you could just about find yourself going back to rewording and reworking your requirements.

Hammering in the processes: Training and all that ...
Several organizations prefer to go OOTB so that it can be replicated as a "hub" and deployed on a larger scale. And of course it also means support costs are potentially lower. Given that a POC comes with tight timeline and the need to deliver demonstrable deliverables, does that leave you with enough time to get your processes hammered in right? Training and communication are key. But they take time. More importantly, do you have sufficient time to drive behaviour change? Or would you rather go for customization now and revert back to out of the box practices somewhere down the line? And what does that really mean to revert?

Mapping the Reporting Beast
Associated with Organizational Change (OCM) comes reporting. Several of you might wonder how reporting is linked with OCM. But will you continue to report the same metrics or has your senior leadership bought into the new processes enough to agree to more suitable metrics? And will you end up creating a little old-world reporting monster in your new ITSM tool? Beware …

Who will do what: Future roles and responsibilities
How do roles defined in the out of the box tools map to the roles defined as per your processes? They should map 100%. But do they? Really? And in turn how do these roles map to your organization? Constructing a simple matrix to map “organizational roles” to “process roles” to “tool roles” can be a simple but powerful start. For example, an organization may have a role called Change Originator, if it feels most employees are comfortable with that term. This in turn may map to two “process roles”:

1. Change Requestor or the individual(s) asking for the change to be raised, such as a business partner
2. Change Initiator or the operator who actually logs the RFC into the tool

Per your ITSM tool, this may map to a set of privileges and rights such as "Raise Change Record", "Edit Change Record" and so on that need to be tightly linked back. Fairly common sense, but truly worth a relook to make sure they are in place!

Phew ... and all that while you align with Best Practices.

So, have you an interesting out of the box tool / process deployment story to tell? And did you stay out of the box?