When you work with Fortune 1000 ITOM customers across various industries, you see a lot of different approaches, styles, and challenges. But the enterprise scale is one common thread that creates many of the challenges they face.

Many CIOs talk about their desire to be Agile, but often become their own worst enemies.

In this post, I’ll be discussing what we have found to be three common threads to mistakes they may be overlooking that are preventing CIOs from delivering an Agile ITSM solution.

If you want to watch the entire story, click below, otherwise keep reading.

Let’s dig in.

Mistake #1 in Preventing Agile ITSM: Trusting Only One Analyst Perspective

The first mistake we see is when customers start to evaluate a new IT Service Management solution, they’ll reach out to a single analyst. Many IT organizations have some relationship with a key analyst firm. I’m not here to degrade in any way the role that an analyst plays, but we often see a single vision approach. Customers only reach out to “their” analyst to get a perspective.

The problem is, what we have found over the years of doing IT operations is that analysts sometimes have a bias, or sometimes just have old data.

If you think about how the traditional reports come out, there’s a year of research, then there’s a presentation of that research, and then there’s a year of lag while they continue to research for the next release. In these cases, the data that you see from an analyst could be two years old. For ITOM industry, those things change so dramatically that two years is a lifetime, and things can be very different from when they first created that report.

Is there IT analyst bias?

Many analysts have their own biases based on their own experiences. For example, Gartner proposes it has no bias, but it takes billions in revenue from software vendors. It’s challenging to have an experience across all platforms and understand what’s happened, how the technology has evolved, what new features, what integrations, what capabilities exist. It changes so rapidly that their bias may come into play.

We suggest that when looking at the perspective of an industry leader, get many views. Don’t rely on one. Do your research.

There are even “analysts” out there that are driven purely by crowd-sourced information. So, you get the perspectives of real customers using these tools, not just from an individual or team of individuals that are doing their own reviews.

Challenging the status-quo of one analyst thinking to drive Agile IT Service Management

As an example, we have a customer that leverages Gartner heavily. Whenever this customer makes technology-based decisions, they look at what Gartner says and take that seriously.

We wouldn’t say they unilaterally make the decision that way, but they heavily weigh the comments and feedback they get from Gartner. That’s typically their starting point. And if they get that feedback and start down the path, they’ll get tunnel vision. The reality is, for this customer, they will go forward because that’s what Gartner says.

We would suggest breaking out of that limited perspective. It’s so easy to get that tunnel vision and get comfortable with an analyst.

The best advice is to challenge the Analysts. Even if you’re talking to a customer, companies like Gartner create these peer reviews. You can get into a session with other of your peers from different verticals and industries. They will provide feedback and discussion and kick ideas around where Gartner’s usually coaching all these companies. Shockingly, they’re all using very similar tools.

Then, when you’re an outlier, you get shamed to a certain extent– you’re asked, “why aren’t you using these tools? We are all using these tools. You should be doing the same thing.”

Sometimes people fall for that. But we would suggest that even if it’s a fantastic decision, challenge them.

If you are a decision-maker and have made a choice that costs millions of dollars, it’s common to get around a group of peers and have them all reaffirm that you made the right decision. But we’d suggest that you challenge that line of thinking. Ask yourself some of the following questions:

  • Did you stay on budget?
  • Did you stay on scope?
  • Did you finish when you expected?
  • What kind of feedback do you get from your users if you had it to do all over again
  • Would you follow the same exact path, or would you choose a different approach?

You may end up making the same choice, but you would at least get different perspectives along the way. You might find that if you dig a little bit, you get a slightly different answer. That would suggest that you should continue digging and that you shouldn’t trust one analyst or one person’s perspective.

How limited perspectives sabotages your odds of delivering an Agile ITSM

We’ve seen this limited perspective manifest itself when customers go down this path and make the choice without all the due diligence that is needed.

The first consequence of this ill-advised decision is that the organization’s employees grow resentful because they didn’t consult them. I’ve been in buildings where we have had great relationships with many of the teams associated with supporting service management, and some of them say “they weren’t even consulted.” They were told, “we’re going this route” and they don’t even know:

  • how they’re going to do it;
  • if it’s the right tool;
  • how we’re going to integrate this; and
  • if they’re hiring somebody.

It was a decision made in a vacuum without incorporating the feedback from everyone in your company.

In situations like these, the decision-makers are creating a foundation for failure. If the team has not bought into this, they’re going to look for ways, whether it’s purposely or not, to undermine the decision because they don’t feel part of the solution.

Fast forward a few years, we have seen customers come back and admit that it was a lot more expensive than they thought it would be. Or it was a lot more complicated than they thought it would be, or working with this particular vendor is proving to be a little more challenging than they anticipated.

All of the shiny, exciting things that you heard from other peers that you may be working with or from an analyst get rubbed off, and all of a sudden, you see it’s not as rosy as they said it would be.

Now, you’re stuck with this. Did you make a good choice? And how do you make the best of it? Maybe it wasn’t an altogether bad situation, but a condition that could have been structured better for success from the outset.

Mistake #2 in Preventing Agile ITSM: Lack of Thorough Planning

Number two is a lack of thorough planning. We use the word “thorough” specifically here, because we know in almost every case –certainly enterprise IT –does some form of planning. But how thorough is that planning?

Let me give you some background to understand how thorough this IT planning process needs to be.

So first and foremost, you’ve got to do research internally to understand what the overall goals and objectives of the organization are. We get that when you’re starting to look at new technology, it’s easy to sort of chase this shiny object and look for features and functions that you might think align to the needs of the business. But are you really looking at the business perspective of that?

So, number one, start with overall business goals, and then make sure that as you’re evaluating different technologies, you are answering, if the capabilities that you’re trying to build into your ITSM tool allow you to drive back successful outcomes for those business goals? This is really important.

How do you do that?

The first thing you do is make sure that you bring in all the possible consumers or constituents that are going to touch, use, customize, engage in any way on the IT Service Management platform. No matter what role, whether they are going to be developing, whether they’re outside users, inside users, or their administrators, or they are people that will have applications touching it or integrating into it, it’s critical that they all have a role. So, as you build your future ITSM out, they understand what you’re trying to accomplish, and how it’s driving back to those business goals and how they can help you achieve that.

But that’s pretty tough, right? How do you get that many people involved and get them all to agree on a solution? The answer is you won’t get them all to agree. But if you include them all, it allows you to make sure you’ve taken everything into account. But more importantly, you’ll get a reaction from them. You’ll get engagement that allows you to find compromise. But if your approach is, “If you build it, they will come,” hoping that they enjoy and get value from what you’ve done, they’ll be much more resistant.

If you can get these customers and constituents engaged early and increase participation, then they’ll acknowledge that some of these features or capabilities that they need create big problems for others. Then the focus is on finding a happy medium that allows us all to be successful because we’re pushing towards a common goal that drives better business value.

Mistake #3 in Preventing Agile ITSM: Recreating the same problem you are trying to change

Thirdly, the most important is this idea of leaving behind this monolithic, complex platform that has been very common in enterprise IT for 15-20 years. It’s this concept of a company building IT service management solutions that require lots of consulting, lots of time, complex deployment, months, years, lots of complicated integrations, etc., and then finding themselves some years later, stuck:

  • needing lots of outside consulting,
  • needing to hire lots of internal development resources,
  • unable to upgrade,
  • unable to integrate,
  • and certainly not agile.

They’re stuck! These companies can’t enhance this monolithic platform they have created without a massive investment.

People get excited looking at the new shiny object, thinking they can start fresh and fix all these problems.

Yet, what we’ve seen many customers do, is end up in the same place they started.

  • They say they want to be agile.
  • They want to adopt out of the box.
  • They want to use best practices.

And as soon as they start to engage, they find themselves doing the opposite of agile IT.

  • “We can’t take this out of the box.”
  • “We can’t use best practices.”
  • “We’re different.”
  • “We’re unique.”

We get it. Certainly, there are cases where that’s absolutely true – that the business demands require that level of customization. If that’s the case, then you make that decision and go forward.

But we’re talking about the instances where businesses make the choice that they want to become more agile, and they don’t want to have that monolithic, highly customized solution that they can’t upgrade. And then they rebuild it and create the same problem.

Instead, they choose a tool that requires heavy consulting, requires developers, is expensive to manage, is expensive to upgrade and it is the Opposite of Agile.

Instead of looking for a way to build a standalone, agile IT service management platform, they’ve built this complicated platform that their business flows from, and it’s integrated into everything in business: back-office systems, H.R. systems, etc. And they’re stuck right where they started.

A specific real-life example where we have seen customers go back to where they have started from this big monolithic platform, but wanting to build an all-new agile type, starts with the same words we hear uttered almost every time from a customer.

“We get it. We made a mistake last time. We want to follow best practices. We don’t want to go build all of these custom processes. We want to find a way to restructure our processes, to be lean, agile, efficient.”

Then when we sit down with them and begin the requirements building, and start with, OK, here is what it looks like out the box. Here are the capabilities, the workflows, and the best practices that are built into the tool. And the first time they see it, their reaction is, “Oh, we can’t use that – that’s not going to work for us.” And they start to change it.

And that’s the beginning of the end; the beginning of the failed implementation because they won’t entertain the idea of changing their processes.

This is a debate in the ITSM world: should the tool be flexible to allow the customer to modify them in a way that it aligns to the customer’s best practices, or should it be the other way around? And we get into this debate with our customers.

We always tell them, sure you can change it, but we work hard to explain the impact and repercussions of making that decision. Do you recognize that if you go down this path, here is what you say twelve months from now? Almost every one of these customers that chooses to change the tool rebuilds it into exactly what they were trying to change.

We understand that it can be a political battle. It’s very challenging to sit in a room with all of these key influencers, consumers, etc. and try to get them to agree on a common approach to anything associated with this.

We’re talking about heavy lifting process changes that everyone has got to adjust to, and nobody wants to fight that battle. Instead, they rebuild and recreate the same problems that they were running away from.

If you compromise, and you’re not willing to fight the difficult battles as part of the planning and building of your new ITSM tool, then you’re moving away from agility. And yet it is agility that is the key driver of what enterprise IT demands today — finding ways to be agile to keep up with the demands of the business. And yet, as soon as you go down these paths of rebuilding, you will

  • not be agile;
  • be struggling with those demands;
  • have frustration from the business; and
  • be looking to re-do this all over once again

Another outcome of chasing this “shiny new logo” that you end up rebuilding too add in all that customization, is the developer cost impact. And so, the total cost of ownership is going to increase significantly.

Certainly, if we got into a more in-depth discussion about the total cost of ownership, lack of planning is going to create situations where there’s more re-work. And if you choose a platform based on one analyst perspective, it doesn’t mean it’s going to work well for somebody else.

Every company has different politics or different technology skills or different underlying business systems. Demands from customers are different. And so, if you don’t align the tool properly with the needs of the business, and if you don’t plan accordingly and then build in lots of complications, all of those drive up total cost of ownership significantly.

For example, when they get their hands on the tool, if they want to move fields around or change drop downs, so that you can choose the simple task, something that should be quickly done. Someone internally should be able to do that and not require a lot of planning.

And yet, as systems get progressively more complicated and customized, people become afraid to touch it. And so if they want to make simple changes – as in be agile – now that is impossible because now simple changes require planning, engagement of the manufacturer or the consulting firm that helped them build it, and require release cycles. All of a sudden, simple, agile changes to the system become bigger projects or get rolled up into a massive upgrade, and it becomes almost a re-implementation of the entire system.

Another outcome of building these monolithic platforms of fifteen years ago, is that you’re creating a platform for business flows. We see a lot of customers, a lot of advertising, and a lot of activity around using service management as the business flow engine.

We would suggest taking a look at a way to break those apart. Have a business flow engine product that allows you to build those business flows, but keep it separate from your IT service management platform. That allows you to stay agile and focused on the role that IT service management platform.

Even if we start to look at where IT service management is headed, you can still have an enterprise service management platform that is the single place for consumers to access anything that the business needs that doesn’t necessarily have to be the business flow engine for the rest of the company. Keeping them separate allows you the chance for having an agile solution across both fronts. But the more you integrate these into common platforms, you create a single place that is very difficult to address the needs of all of the consumers at the same time.

In summary, to avoid three mistakes that we see preventing CIO’s from building an Agile ITSM solution.

  1. Get plenty of input from multiple sources.
  2. Do thorough planning. Have a process from a planning perspective to engage all the proper constituents and make sure you start with business goals and objectives first, not technical features and capabilities.
  3. Choose a platform that allows you to be genuinely agile. One that is easy to use, easy to integrate, and forces you along the lines of best practices so you don’t build yourself into a box once again.

We know that the three challenges that we’ve highlighted here are certainly not comprehensive, but they’re the ones that we see most commonly.

If you just would like to have further dialog on IT Service Management or Enterprise Service Management, we at Whitlock are always happy to have that dialog as well.

If this really resonated for you and you’d like to dig deeper in service management, we have a trademarked Value First methodology, which we can walk you through. If you’d like to have an initial dialog to see if there is an opportunity to collaborate, we’d love to have that conversation.

Our methodology will tease out some of the internally challenging aspects, the assumptions that may have been made based on the current tools selection or what you’re thinking about today. This will allow you to start to think more objectively and critically around how you might implement an IT Service Management platform going forward.

To reach me directly email jeff.jamieson@whitlockis.com or call 919-941-1900.

LEAVE A REPLY

Your email address will not be published. Required fields are marked *