Learn about the 6 most common challenges of ITSM implementation. These are not problems, mistakes, or criticisms directed at customers – rather, they are tips to sensitize you to some of the issues when discussing the implementation of an ITSM solution.
An ITSM platform is a solution that needs to be well aligned with your business operations. It is not an “out of the box” tool that you can install and start using it like a simple word processor. As a rule of thumb, the more complex the solution, the more possibilities it offers and the more areas it facilitates by digitizing processes, and the more difficult it can be to implement. But fear not, all you need to do is apply to a contractor who has experience in this, listens to your needs and looks for the best functionalities to meet them. So let’s get to the tips that will help you more easily control various situations and challenges during implementation. Let’s get started.
1. Lack of commitment
This term can refer to a variety of situations. One is the lack of involvement of the team on the customer side – that is, the lack of involvement of those responsible for the shape that the processes implemented in ITSM should take to meet the company’s needs. This includes postponing or failing to attend meetings or failing to fulfill agreed tasks. Such behavior results in increased project time, the risk of errors, and the prospect of repeated revisions. This is not what we care about, whether as a supplier or a client.
Another case is avoiding joining conversations with a certain person or team, as mentioned in the text: ITSM: Business Analysis. The 4 most common challenges.
Recommendation: even if you are afraid to include someone in the project because they may hinder discussions, you should still do it. In this way, you will avoid the situation when someone shows up at an advanced stage and completely changes the concept, making the work return to the starting point.
The third situation is a lack of commitment on the part of the contractor, that is, a focus on getting paid and not necessarily on implementing a valuable solution. It wouldn’t be fair to leave out such a scenario, and based on conversations with customers, these are not at all rare cases. If the company you contracted to implement an ITSM solution doesn’t ask anything about the requirements, doesn’t try to understand the processes thoroughly, doesn’t get into how they work – then something is wrong.
Recommendation: during implementation the most important thing is cooperation – the client does not need to have experience or very good knowledge of ITIL and good practices. That’s our role. As a contractor, we are supposed to build awareness of the solution, recommend best practices for the client’s needs, sometimes we have to advise against something, knowing that the idea simply won’t work. The commitment has to be on both sides.
2. Placing unconsidered demands on the system
Placing ill-considered requirements on the system is also a frequent impediment. This includes the creation of convoluted process paths and unrealistic requirements, such as expecting the solution to handle many processes across multiple company branches right from the start. This approach is not good for at least two, main reasons:
- The higher the entry threshold (i.e., the greater the difficulty of learning a new solution), the greater the reluctance of employees and the longer the time to master the tool.
- The more processes deployed at once, the more complicated, longer tests, the greater the risk of errors, and the more difficult it is to expand the infrastructure with more components.
A high degree of complexity and a very large number of processes implemented simultaneously also entail a huge amount of work on documentation – a lot of descriptions of processes, functionalities, and information flows have to be drawn up, which often turns out to be impractical and unnecessary (although documentation in itself is crucial, don’t take this as a criticism of documentation per se!). On the other hand, excessive automation can hinder process flexibility, limit the ability to perform actions in the system for a given role, delay service time, or even make it impossible to react in urgent, exceptional situations.
It is also sometimes an unconsidered requirement to expect a huge amount of customization to the exclusion of commercially available solutions. In such a case, work is done unnecessarily, because someone has already created the functionality in question, there is no point in wasting time and resources on it.
Recommendation: the method of small steps gives much better results both from the technical point of view – because it is easier to test, implement, and then complete smaller components than to deal with a very complex system at once; and from the perspective of employees, who have to get used to the new solution, master all the paths of information flow, and get used to the new way of working.
3. Standardization with no margin for exceptions
Striving hard to standardize all activities to work the same way for everyone can be confused. After all, not every team has the same needs and operating model; it’s good to keep room for making exceptions or changes. Sometimes we also need to bend the best rules, ideal in theory, to the specifics of the company’s operations; leaving room for possible or planned improvements that the company does not currently possess, but anticipates developing over time.
Recommendation: Let’s follow ITIL best practices consciously yet flexibly. Sometimes it is necessary to deviate from the model. Let’s put the value and goals of the solution for the company first.
4. Lack of building awareness of the new solution among employees
Employees don’t like changes, and new tools require learning and developing different habits. They will also cause discomfort due to, for example, not being able to move on with an activity without receiving approval from a supervisor, or by streamlined solutions for monitoring the time it takes to perform a particular service. If teams are to change work tools, they should know what the reason for this is, what the goal of the change is, and what the organization is aiming for.
Recommendation: the company should plan communication about the changes and progress on the implementation. While training on the new tools is essential, it should not be the sole activity aimed at building awareness of the new solution.
5. Lack of test environment and testing
A major oversight is the lack of a test environment and testing of the solution itself. Fortunately, these are marginal situations. The company should test all implemented processes in a test environment before they go into production. This allows us to identify and correct any errors.
6. Migration from the old tool, to the new one
While it may seem innocuous, transferring old requests that were processed differently before the implementation of changes can significantly complicate the handling process and pose a risk of data loss.
Recommendation: old submissions are better archived and kept in their original state, rather than trying to adapt them to the new environment. Likewise, current, up-to-date submissions – they should complete their life cycle in the tool that is being extinguished; treat the new tool like a clean sheet of paper and don’t litter it with unnecessary data.
Summary Tips:
Finally, I pass on a few more tips:
- Don’t approach ITSM implementation as a one-time activity. If you treat it that way, you will not be ready to properly maintain and develop it.
- Don’t be afraid to engage yourself and others. Bet on communication, because even the best algorithms can’t replace people.
- Turn to partners who have ITSM implementations in their portfolio. Ask, discuss, and benefit from their experience. ITSM covers many areas, and something that seems unnecessary today may be desirable tomorrow. Experienced implementers can spot such issues.
- Not all at once: consistent, staggered extinguishing of the old tool and implementation of the new one step by step, service by service, according to established criteria is the best way to make the transition to ITSM.