For almost 20 years now, large global enterprises have been struggling to get everyone in their local, regional, and global IT support organizations to work together in the same IT service management tool. It is common for these corporations to have office buildings, factories, and research centers scattered around the world. The challenge of implementing a single tool is partly explained by the wide variety in the number of supported employees at these locations and the differences in their support requirements. Add to that the many cultures, languages, time zones, holiday schedules, etc., and it becomes clear why a global ITSM initiative is so different from a single-country deployment.
At the start of the project, a wonderful vision is painted where one ITSM tool gets selected as the corporate standard and all support specialists, regardless of their location, use it to coordinate all their activities. Despite the fact that this vision is completely rational, the end result is typically disappointing. After the project has been completed, most of the enterprise’s support organizations will be managing only part of their infrastructure, and just some of their changes, in the new tool. What’s worse is that multiple disconnected help desk applications will continue to be used throughout the enterprise.
Why is it so hard to get everyone on the same ITSM tool?
Why is it so hard to get everyone on the same ITSM tool? This article looks at three very simple reasons why things turn out so poorly and what can be done to avoid ending up with only a partial success.
What Is Success?
Before we get into the factors that limit the success of a global ITSM rollout, let’s first define success. The reason why a business is willing to fund such an IT project is that it is expected to make IT more flexible and efficient. Fundamentally, this goal can be realized in two ways:
Enable collaboration between the different local IT departments, regional data centers, and global centers of excellence. Collaboration allows services to become standard around the world. Support specialists with a certain expertise can work together as virtual teams to support these services. The number of experts needed to support each global service can therefore be minimized, freeing up resources for additional services that can make the business more competitive. And because the members of the virtual teams responsible for supporting the global services can be located anywhere, the switch to a follow-the-sun support model becomes a natural choice.
Once the ownership of some services has been centralized, the organization is in a better position to selectively outsource the ones that have essentially become a commodity. This approach allows the specialists to focus on the services that are more strategic for the enterprise.
Provide KPI and service level reporting on a local, regional, and global level. The ability to track and compare the KPI trends of the different ITSM processes, as well as the SLAs for each service, and then compare these for each of the support teams and organizations, allows the IT directors and the CIO to make better decisions about resource allocation. Timely information about where what needs to improve allows for more targeted investments and makes it possible to measure their returns.
It’s Not the Money
Now that it is clear what success means for a global ITSM initiative, let’s take a look at the reasons why it is so hard for these projects to realize the envisioned benefits. Clearly it is not because these projects receive insufficient funding. Sure, when things go wrong, most people believe that throwing more money at it will get things back on track. But it is already common for organizations to spend way more than necessary. Spending more, especially on tool customization, will, in fact, only make things worse. So, if a lack of funding is not one of the three simple reasons for failure, what are they?
1. The Specialists Don’t Love the New Tool
The first issue that the global project team encounters is that many customizations are needed to deploy the new tool at the first location. Most of these adjustments are relatively easy to make, so the tool gets customized to ensure that the first migration can be completed successfully.
At the next location, however, several more modifications are demanded. Again, the tool is customized to ensure that the rollout can continue.
Close inspection of the requirements will reveal that most of the customizations did not improve the efficiency or effectiveness of the processes and neither do they provide more actionable management information. Often, the specialists demand changes because they want the new tool to work just like the old one that they have become used to, or because they are simply trying to stop the new tool from getting implemented because they don’t like it.
Either way, as the rollout progresses, more and more of these customizations are implemented in an attempt to make everyone happy. Unfortunately, the opposite is the result. The more the tool gets customized, the more clunky it becomes.
In the end, it is common for ambitions to be scaled back. Instead of rolling out the tool to all specialists, the objective is limited to the teams of the larger support organizations.
The best way to overcome resistance to the new tool is to make sure that it offers a significantly improved user experience. It must be so intuitive that the specialists can see themselves using it without training.
It also helps when specialists from all locations are involved in the tool selection. By inviting them to participate in the proof-of-concept testing of the shortlisted candidates, they can identify showstoppers early on and vote for their favorite. This process will point the global project team to the tool that will generate the least objections.
Before a tool is selected, it is also important to have all the IT directors agree on zero customization. Out-of-the-box, the tool is either enterprise ready, or it should not even be considered. The vendors will say that their tool can meet all requirements because it is so flexible, but in an enterprise environment, it is almost impossible to get all stakeholders to agree on customizations. One adjustment may work fine for some teams, while making life more difficult for others. Removing the customization risk from the project dramatically increases the chances of success.
The global project team can apply one more trick. By inviting specialists from all locations to participate in the tool selection process, the project team gets a lot of early feedback. Use this feedback not only to decide which tool gets selected, but also to look for sites that are so enthusiastic about a candidate that they would like to start using it right away. There are always a few that have wanted a new tool for some time and finally saw what they were looking for. Note down these sites.
Once the tool selection is completed, contact all IT directors and let them know that participation in the project is voluntary. This immediately removes much of the resistance to change. Next, let them know that the project team does not have enough resources to help everyone migrate this year. This makes their support more desirable. Finally, inform them that sites that want to migrate will be helped on a first-come, first-served basis.
Even when some IT directors were determined to prevent the new tool from getting implemented at their site, this strategy will eventually bring them around. That’s because the project team can focus first on the sites that are eager to make their migration a success. By the time the project team has successfully completed the migrations for its supporters, the sites that were initially hesitant are encouraged by the successes and will now also want to join. By the time they are also able to collaborate efficiently with the other support organizations, the ones that were planning to resist are starting to feel left out. One by one they will ask to be allowed to use the new tool as well.
2. The New Tool Is Too Slow
As adoption of the new tool spreads, specialists in far-away countries start to complain that it takes several seconds each time they need to look up some information. The performance of the tool seemed just fine during the proof of concept. What’s going on?
First of all, people are now connecting to the application from all over the world. Network latency has a large impact on the performance of most ITSM tools. This situation is compounded by the fact that over time more records are stored in the application’s database, which affects the response time for each query. But the factor that has the greatest negative effect on performance is customization. The more an ITSM tool is customized, the slower it gets.
The more an ITSM tool is customized, the slower it gets.
Combined, these three factors can destroy the usefulness of the application. If the application is slow, the specialists will no longer look up the information they need in the new tool. Instead, they will maintain their own spreadsheets. Because they no longer use the tool to look things up, they no longer see the point of maintaining the information in the tool. So the data becomes out of date or is missing completely. This makes reports unreliable and prevents other users, such as the service desk analysts, from benefitting from the information.
Response time issues can be avoided by careful proof-of-concept planning. Ask each vendor that participates in the proof of concept to populate its tool with at least 100,000 employees, 500,000 configuration items and 1,000,000 requests. Also get a few specialists at locations around the world to concurrently register new requests and changes, while others search for asset information. Measuring the response times will provide an indication of each proof-of-concept candidate’s performance in a real-world situation.
3. The New Tool Generates Misleading SLA Reports
More is demanded from the SLA tracking capabilities of an ITSM tool when all the parties responsible for the different links in the service delivery chain use it. To illustrate this concept, let’s look at a typical example of a business service that consists of multiple components provided by different parties: the enterprise resource planning (ERP) service.
The ERP service might be provided centrally, but it is configured locally by a small team of experts who have a better understanding of the local business environment and regulatory requirements. The local ERP experts rely on the global ERP team for the availability of their ERP production environment. In turn, the global ERP team depends on the database administrators to keep the ERP databases running.
When an end user notices that something is wrong with the ERP service, an incident is registered. A resolution target is automatically assigned to this incident. This target is calculated based on the SLA that the local ERP support team agreed on with the business.
After the local specialists determine that the issue is caused lower down the service delivery chain, the incident is passed on to the global ERP team. This team performs its investigation and concludes that the issue is caused by something related to the database. By the time the incident is assigned to the DBA team, the SLA target is nearly violated. If the DBA team resolves the issue, the SLA reports will show that the DBA team failed to resolve the incident in time.
It is not easy for an ITSM tool to support this scenario, which typically requires a hefty dose of customization, despite claims to the contrary from vendors. Find a tool with standard functionality that automatically finds and tracks the applicable agreements for each request, without having to spend a prohibitive amount of time administering these agreements. This capability is critical to the success of a global ITSM initiative.
Unless the tool takes the OLAs of the central teams into account, the specialists of these teams will not know if they are meeting their commitments. In environments where the OLAs are not tracked, the specialists of central teams become discouraged. They should not be held accountable for the local team’s targets because they have no control over how quickly the local teams pass incidents to them. The local teams, in turn, will believe that the central teams are to blame for many of their target violations. The result is a negative atmosphere based on perception rather than facts.
To ensure that a tool is capable of providing accurate out-of-the-box SLA reporting, make sure that the above ERP scenario is included in the proof of concept. During the proof-of-concept testing, run variations of this scenario (e.g., by getting the local team to withdraw the request or by getting a global team to decline the incident) to make sure that the input gathering for the SLA reports is robust.
Success Is Determined During the POC
There certainly are many more obstacles that global project teams run into. These can typically be resolved as they come up. This article focused on three specific problems that are rarely considered until it is too late. Once a contract has been signed with one of the ITSM tool vendors, it is next to impossible to start again with a tool that is capable of meeting the enterprise’s needs. It is, therefore, essential to carefully plan the proof-of-concept phase for true global success.
Cor Winkler Prins specializes in translating ITIL theory into practical process definitions and service management tool specifications. His work had a major impact on the service management industry when, in 1999, he developed the first comprehensive set of integrated ITIL-based ITSM processes. The model includes detailed work instructions for IT professionals. This set of process definitions and implementation practices was used by ITSM consultants in more than 20 countries when it was acquired in 2007 by BMC Software.
Cor’s main interests are the financial aspects of IT service management and helping managers optimize service levels while continuously driving down service costs. Follow his work on the ITRP blog, the ITRP Institute Twitter feed @ITRP, the myITRP Facebook page, LinkedIn, and YouTube.