Often times when an organization feels ready to board the ITSM ship the most common action to take is to seek a Service Management Tool. The expectation is that IT Service Management is automatically implemented when something similar to a process is carried through a tool.
However, one thing that we tend to forget is that the arrival of an automation tool can create new issues or exacerbate current mistakes in our organization. In order to mitigate this risk we must make sure that proper processes are in place and that tools are customized in support to said processes.
Before we even start thinking in purchasing or developing a tool, we should do an auto evaluation and make sure the processes in our organization do, in fact, comply with the following points:
- Are aligned to the business strategy
- Satisfy one or several organizational needs
- Are measurable (in a relevant way)
- Are properly documented
- Are subject to periodic reviews
Once we are satisfied with our current processes we can then proceed to begin the search for a Service Management Tool.
The first question we should be making is: Do we need an off the shelf tool or should we develop our own solution internally? Without a doubt I can tell you: For most companies it is better to purchase an off the shelf tool. Developing a solution should be reserved to very specific situations such as organizational strategies or the fact that there is no product in the market that can comply with the company’s most important needs. Remember: The whole point of Service Management is to satisfy an organizational need avoiding unnecessary risks and costs.
For the purpose of this article let’s assume that it has been decided to purchase a readily available tool. The next point to remember is: Software tools should be used to support processes and not the other way around. Our main focus should be to look for a tool that adapts the best to our vision, culture and processes. A common pitfall in the implementation of ITSM in organizations is trying to re adapt current processes that work to whatever the new tool in town requires.
The most important part of implementing a Service Management tool is making sure we have a clear vision of what we need and what we are looking for. We should be able to articulate exactly what we want to achieve and make sure the objective never leaves our sights.
Defining the requirements a tool should satisfy is, in my opinion, the most important step in the selection process. The amount of resources (financial, effort and time) that we invest in this step will directly impact the quality of our final decision and, consequently, the success of our tool selection exercise.
My advice is to first create a list that includes each requirement that we believe deserves to be considered for the tool selection process. At this point we should not care if the requirement can be satisfied at all by the current market nor how important each item on the list is. Requirements should be documented with help of the stakeholders and published through the SoR (Statement of Requirements).
The SoR can include a MoSCoW analysis which consists in categorizing the requirements in the following sections:
Must – The requirements categorized need to be covered no matter what
Should – Whenever possible the requirements documented in this category should be covered
Could – The requirements included in this category should be covered as long as they don’t interfere with something else
Won’t – Requirements in the “won’t” category will not be covered at that particular point in time (but could be in the future).
A tool should be deemed unfit for purpose if all of the “Must” requirements are not covered but if we set our minds to find a tool that comply with 100% of our requirements we are setting ourselves up for failure. The 80/20 rule should be used: a Tool that covers 80% of the requirements should be considered adequate. There could be cases where not even the 80% can be reached, in such cases the tool with the most “must” requirements covered should be selected.
Vendor invitation and first filters
Once our SoR is complete and RFP could be published to possible suppliers. One important consideration to have is that enough suppliers should be invited to have a clear view of the market but not many as the process could take too long or become confusing.
I personally prefer to have a first evaluation on my own (or with help of an internal team) without the direct influence of vendors. Whenever possible, doing a google search for reviews and opinions can help us reduce the number of possible candidates. Other tools like the magic quadrant can be (and should be) used when available.
Regardless of the method we should send a “big list” to all the vendors that we have deemed relevant so far and provide a reasonable amount of time to make a first round of selections. These first selections should be done with the participation of some of the stakeholders so important functionalities and nuances are considered.
A few ways to make that first long list a short one are:
- Eliminate all the vendors that sent a late proposal (as long as we are sure the time provided to send the proposal is reasonable)
- After a first quick review eliminate all the vendors who sent an incomplete proposal or failed to develop the proposal according to your organization’s guidelines
- Drop all the proposals that are out of the budget. Even if the tool is perfect for the purpose the budget should be one of the main points in the selection criteria
Whenever possible, each person in the selection committee should pick a favorite proposal and present it to the rest of the team. Having a person defending their selection can have a very positive impact in this step of the process as each element will try to highlight all the positive points of the product of their choosing. If one of the products does not produce a “champion” it should be reviewed by person responsible for the selection once more and discarded if no reason to have it in the competition is found.
After this exercise we should be able to reduce our possible candidates to less than 5. Ideally we should make a decision with 3 proposals tops.
Try before you buy
Many vendors offer the option to deploy a demo of the tool in the potential customer’s environment at no cost. If the opportunity is available it should be taken as long as this considerations are kept in mind:
- It does not produce a cost (licensing fees, infrastructure, etc)
- It does not require a long implementation process
- Does not represent tying critical resources to a time consuming task
We should avoid at all costs trying to have the tool aligned to our current processes at this time. Even though it could represent having the definitive answer it will most likely represent a long and resource consuming effort for the organization and, unless that tool is selected, it will not represent great value to the company.
Instead we should be able to use the tool with the processes as they are out of the box and try the tool for the kind of things that would not change if the tool is adapted for the process such as: speed, usability and compatibility.
Testing 3 different tools in parallel is a very daunting task. Whenever possible offload the work to the vendor that owns the tool, they most likely comply in order to have a chance in the selection process.
The head of the committee should draft a matrix based on the MoSCoW analysis, assigning a point value to each one of the requirements’ category and share it to the rest of the team. Each tool champion should then, based on their demo experience, mark the tool on each one of the requirements and publish the overall mark of their product.
A final discussion should take place where the committee can discuss the different tool and try to select one or, in the worst case, select two different tools for a final showdown.
If there are two final options the committee should select 1 person to represent each tool internally in order to make the discussion more streamlined. Each “defender” can now build an argument for their respective tool in a follow up and final meeting. This meeting should take place as soon as possible in order to keep the arguments fresh and that everybody involved remembers most of the tool. If no consensus is reached at this point, the head of the committee should make a final verdict for the tool.
There are often hidden costs that are not 100% clear during the first few presentations. Some things to keep in mind are:
- Licensing models (per user, per process, time based, etc)
- Implementation costs
- Training costs
- Full infrastructure (including platform licensing fees if they apply)
- Expansion costs
Even if there is no Supplier Management process in place, it is a good idea to define a single point of contact for managing the relations with the vendors involved in order to minimize the risk of having opinions and votes swayed for reasons other than the best interest of the process.