Avoid Going Directly To Fail

How to avoid going directly to fail?

We’ve been implementing ITSM tools for a very long time and it’s highly unlikely that we will see the pace of implementation decrease anytime soon. Nowhere is this more evident than in the ITSM space.

Despite ITs extensive experience in “implementations”, a quick review of projects shows that we seem to keep making the same mistakes over and over. Each failure (potentially) undermines our customer’s confidence in our ability to deliver on-time and on-budget.

The good news is that this is entirely avoidable. Selecting and implementing an ITSM tool successfully isn’t hard, but it does take some work. The good news is that this work has benefits that can impact your implementation and beyond!

Alignment of team members

“If you are not getting value from your ITSM initiative perhaps it’s because you’re not actually following what you’ve set out to do.”

It’s easier to define a process and implement a tool than it is to get people aligned and moving in the same direction. There is nothing accidental about team member or organizational alignment. It’s an intentional act and requires attention over time. Attempting to enforce a change in culture or create alignment through messaging will only have (at best) short-term, temporary results.

Thinking about it as just implementing a tool

Yes, there is a tool to implement, but that’s only part of what’s needed. Without proper management support to address the cultural change and adoption issues, we are likely going to see an installed product installation, but little else.

“Many of the current generation of ITSM tools are extremely flexible and easy to configure and customize. When you have poor processes, and non-existent requirements, you can end up implementing bad stuff really fast.”

We need to adjust our thinking before critical and costly decisions are made which result in problems. After all, your tool vendor doesn’t want you to fail either – their success is tied to yours!

Adopt and Adapt

Since the early days of the ITIL® framework, two things have always been offered as caveats for advocates:

It is intended to be “descriptive, not prescriptive”

Organizations should approach it from an “adopt and adapt” perspective.

Well, somewhere along the way, either these two messages were either lost or radically redefined to meet someone else’s agenda!

As a result, we’ve found that “Out of the Box” approaches are generally inconsistent with project success and with the level of organizational change required to see that the tool actually gets used properly. As David describes in 5 Reasons Why Any Project Fails:

“There has been a recent trend towards trying to implement IT Service Management tools “out of the box”. The story goes something like “The tool is based on ITIL, we use ITIL so therefore we won’t have to change anything.” With perhaps the exception of smaller IT organizations, this couldn’t be further from the truth. Let me ask you a question “is your organization out of the box”? Ask yourself the following questions; how will the users be defined; what are the notification groups and rules; what are the workflow requirements; what are the escalation rules; what are the reporting requirements? These things are seldom “out of the box” and need to be documented and the IT Service Management tool tailored to accommodate. Bad requirements lead to a poor ITSM tool implementation.”

Organizations need to use and understand how a given tool works before they start to try to make changes. That is different than choosing to rely on a default configuration on which to run the organization. Unless you are willing to make the organizational changes to conform to how your tools work, this is a bad choice. No executives I know would be willing to make this choice. Why should you?!

Taking on the governance challenge

There is nothing in a tool implementation that guarantees effective governance. You may have the ability to define roles, adjust permissions for actions, and control the visibility of data, but as David writes in The Cynical Side of ITSM, there’s more to it than that.

“In my opinion, it is because people are confusing a “framework of best practices” with actually doing the hard work of governing their ITSM programs.”

The key factor here is addressing the governance challenges during the very initial stages of the tool acquisition efforts; paying special attention to ITSM as a program, not as a collection of specific processes to implement.

Managing Requirements and Expectations

“People too often jump into new projects without a clear understanding of what it is going to take. When the project fails, they point to external reasons such as “the tool doesn’t work” rather than looking inwards.”

By the time the tool is installed, if we’ve not already planned how the requirements are satisfied and how to manage customer/stakeholder expectations, we’re probably already feeling the consequences of this mismanagement. At this point, we’re likely finding the “external reason” that David is pointing to! While it might be a very good reason (i.e. an act of God), it’s likely something we had prior knowledge of and either missed or overlooked.

Summary

There are simple set of recommendations and project guidelines that we can take advantage of to ensure that our ITSM tool implementation projects are a success. By leveraging the recommendations here, we can help ensure that any tool implementation project addresses the key factors that are a source of value and goes far beyond just getting the tool into operation.

Guest article by Kenneth Gonzalez

David Mainville

David Mainville, CEO and co-founder of Navvia, is a passionate advocate of Service Management and a frequent presenter, blogger and well known member of the ITSM community. With over 35 years of experience, David has held progressively senior technical and management roles allowing him to "connect the dots" between the Business and IT. At Navvia, David leads the charge to bring innovative ITSM solutions to market focusing on Product Development, Marketing and Operations.