Avoid the Breakdown

[Sheila Llewelly]

     Breakdown? What breakdown? The IT Service Management (ITSM) tool implementation breakdown is what I’m talking about. I’ve been in IT Project and Portfolio Management since 2001 and I have seen my fair share of unsuccessful transitions. The excitement of a new tool is almost giddy in acceptance. The business unit builds a feasible charter showing Return on Investments that can melt the hardest CTO heart. The project plan is a work of art in tasks and timelines. The development team is ready and waiting. All is good. Or is it.
     There are ways to avoid implementation breakdown and it starts with sitting down with the Customer and talking with them about what their ITSM life looks like right now. Find out what works and what doesn’t in their current environment Before giving a demo of the tool, ask what the customer expects to solve. What processes are in place and what is working for them right now. Then go to what is not working and how would they like to see that process improved on.
     In seeking an unbreakable solution, make sure the focus is on the process, not the tool. A noted ServiceNow developer I know suggests the need is to work with the Customer in documenting out their processes beginning to end before even looking at what the tool can do. His sentiments were, “Forget about the tool, make sure the process is in place first.”
     Many Customers may have a preconceived notion of what an ITSM tool should do so they try to fit the process to the tool rather than fitting the tool to the process. I was privileged to earn a Six Sigma Green Belt and one of the hardest lessons in that training was to not go into the problem with a solution. The fact is, we often did not really know what the problem was until we were through the metrics and discovery of what was broken.
     Having said that, a best practice, in order to avoid ITSM implementation breakdowns, is to do a complete discovery of existing workflows and integrations with other applications before documenting what we need the tool to solve.
     A sure show stopper in Return on Investment is when a new tool introduces a new process that requires redundant effort because the workflow or incumbent application was not taken into consideration in the requirements gathering for implementation of a new tool. Legacy processes often interfere with the efficiency an ITSM tool can bring. These processes must be reviewed with an eye on what can break down the road and what may hinder the value of the implementation.
Remember, investigate before you implement, and you will many times avoid implementation breakdown.