TIPS FOR SELECTING THE BEST SERVICE DESK SOFTWARE
THE BEST SERVICE DESK SOFTWARE
One of the most frequent questions that our clients ask us is: What is the best Service Desk Software in the market? We always answer the same: It depends on your organization.
On a particular occasion, a new client contacted us requesting support. I had 7 months trying to implement a Service Desk Software for 3 processes: Incident, Request and Problem. He contacted several suppliers and requested quotes. Then he compared the marketing materials of each tool, prepared a comparison chart and reviewed it with his leader. Combining the comparative table and the budgets, they made a decision.
<iframe width=”560″ height=”315″ src=”https://www.youtube.com/embed/FVfFMMtsD3g” frameborder=”0″ gesture=”media” allow=”encrypted-media” allowfullscreen></iframe>
The supplier / distributor of the tool proceeded to do its part of the work: install the tool and share the documentation. Once the purchase was completed, the questions began: How can I use it with my monitoring system? How can I change the typifications of the service? How can I set up additional notifications? Fortunately, the supplier had consulting plans on the tool. Unfortunately for our client, that was not contemplated in the original budget and could not assure funds to realize additional consulting efforts.
The following weeks (later he told me) were some of the most stressful of his life: Operational areas of the company demanded to see the benefits that were promoted when announcing the purchase of the tool, statistical numbers out of tune, lack of follow-up to user services … An absolute chaos and in the center: the IT department.
Our client did not understand why things could go wrong. After all, he bought a leading tool in the market according to industry publications and it was not cheap. For 3 months he tried to solve the problem on his own until he decided to seek outside help.
In the end, his initiative could survive and the organization could tolerate almost a year of delay. However, the reputation of the IT department was never the same.
The market has led to numerous solutions for the needs of IT service management in organizations, so often that the selection process is overwhelming. A decision can be the difference between potentializing initiatives to implement best practices and losing all the momentum and confidence on the part of the business.
The focus and efforts should be oriented towards the selection process, if we do it correctly, the risk of making an error is considerably reduced. A disorderly or absent process puts us at risk of falling into marketing tactics that could favor other interests that are not those of the organization itself.
The best thing is that before turning to see what’s on the market, let’s perform a self-evaluation to make sure that the processes we want to support with the tool have the following characteristics:
- They are aligned with the organizational strategy
- Satisfy one or several needs (not always obvious)
- They are measurable in a relevant way
- They are subject to periodic reviews
- They are documented
Even if you want to acquire a tool to implement a process, we must be able to design it before the tool is a factor. It is important to remember that the tool is not a process as such, it is just a way to carry out a process in a more efficient way. If the process is prone to errors, we’re only going to make more mistakes per minute.
Something we often forget is that Service Desk Software exists to support processes and not otherwise. Our main concern must be to find a tool that best adapts to the vision, culture and processes of the organization. A common error in the selection of Service Desk Software is the search for the process to adapt to what the most popular tool of the moment offers.
One of the most important things to consider when undertaking the search is to make sure that we have a clear vision of what we are looking for and for what purpose. We should be able to articulate this vision clearly and never lose sight of it.
INTERNAL DEVELOPMENT VS OFF THE SHELF
The first question that we must answer when making a selection exercise of Service Desk Software is: Do I want and can I develop the tool internally or is it better for me to buy an existing one?
Without fear of being wrong, I can say that for the absolute majority of cases, buying a complete product is the best option for most organizations. Internal development should be limited to very specific cases such as whether the tool is part of a business strategy or that there is no product on the market that can satisfy the most important needs of the organization. Remember that at the heart of the Service Management philosophy is the idea that we seek to avoid unnecessary costs and risks to the organization.
In most situations, organizations have very particular uses for a Service Desk Software, and developing one internally represents several important implications:
- The cost is probably higher (depending on the desired functionality)
- The expertise needed to develop a tool (technically and functionally speaking) is not common, nor cheap
- In most cases the ROI will be negative
- The investment must be continuous for maintenance and avoid obsolescence
- Distracts the attention of the organization, possibly neglecting more critical aspects
The wide variety of offers in the market assures us that there is a suitable tool for a high percentage of interested organizations, so it is sufficient that the resources of the organization focus on an adequate selection process.
DEFINITION OF REQUIREMENTS
Defining the requirements that a Service Desk Software must satisfy is, in my opinion, one of the most important steps of the selection process. The amount of financial, human and time resources that we invest in this step will directly impact our final decision and, consequently, the success of our selection exercise.
My recommendation is that we first draw a list of all the things we want the tool to do. At this point, we should not worry about how important the requirement is or if there is a tool in the market that satisfies it.
This list should be developed in an inclusive manner with the participation of all the roles that could use the tool or have an interest in it. All the requirements must be published in a document that we will call SoR (Statement of Requirements) and share it with all the participants.
Once we have this list, we must organize it according to priorities in a format known as MoSCoW, which will help us define the importance of each functionality of the tool to be clear about the needs throughout the process.
The MoSCoW analysis consists of categorizing the functionality requirements in the following sections:
Must: The requirements of this category should be covered no matter what. For example:
- It must work in the cloud
- Must include a self-help portal for users
Should:In this section we will document all the requirements that should be covered but are not indispensable. For example:
- It should be possible to buy permanent licensing
- It should include a consultancy policy for its implementation
Could:In this category we will include all the functionalities that could be covered, as long as they do not interfere with anything else. For example:
- That supports other processes besides those currently desired
- That is integrated with Active Directory
Will not: Here we will list all the features that will not be covered in this exercise, but that could perhaps be considered in the future. For example:
- That is integrated with other tools
- Have certifications
Strictly speaking, our objective would be to obtain a tool that meets all the requirements cataloged as Must. However, the commitment to cover 100% of the requirements could be a recipe for failure. For most situations, a tool that meets 80% of the requirements cataloged as Must should be sufficient. In case there is none in the market, the best option is usually the one with the most functionality in Must.
With these brief considerations, we can surely make a better decision regarding the selection of best practice tools. Including all the stakeholders and documenting the requirements with a methodology will profoundly mitigate the risk of making a wrong decision or spending more.