LICENSED FOR DISTRIBUTION

Redesign Your ITSM Tool RFP Process for Better Results

Published: 04 May 2017 ID: G00327683

Analyst(s):

 Chris Matchett, Rich Doheny, Kenneth Gonzalez

Summary

Choosing the right IT service management tool is difficult due to a market crowded with more than 450 products and increased commoditization. This research helps I&O leaders enhance the RFP process to compel vendors to explain why their offering is best for the business.

Overview

Key Challenges

• Because they are unable to specify which functions of IT service management (ITSM) tools are vital to their business, I&O leaders struggle to identify the best tools for their needs and rely too heavily on price comparisons.
• RFPs for ITSM tools often include requirements that apply only to certain delivery methods, such as SaaS or on-premises, creating bias that makes it challenging to compare tools delivered in different ways.
• ITSM tool RFPs do little to help I&O leaders differentiate vendor offerings because they often are merely long lists of commonly found features.
• Instead of addressing an organization's specific needs, ITSM vendors often provide boilerplate responses to RFPs, making it difficult for I&O leaders to select the right tool.

Recommendations

I&O leaders focused on optimizing IT operations to drive business value:

• Distinguish crucial requirements from nice-to-have features by performing a "must have, should have, could have, won't have yet" (MoSCoW) analysis during the definition phase, and by asking vendors to complete a prequalification questionnaire containing only your must-haves.
• Ensure your RFP fits a wide range of use cases, focuses on outputs and emphasizes value. Use delivery-specific criteria when comparing SaaS offerings with on-premises offerings, or vendor-direct offerings with reseller offerings.
• Share your vision with vendors by identifying the issues and goals that you need an ITSM tool to address and achieve, and by being candid about your current capabilities. This approach will help you identify a solution that suits both the organization's current needs and the processes you plan to implement in the near future.
• Invite vendors to explain why their solution is best for your needs by requesting that they respond to your RFP in essay form. Essay-based responses take longer to produce than yes/no responses, and lazy vendors interested only in easy wins are likely to withdraw their bids.

Strategic Planning Assumption

By 2020, 90% of organizations that invest in an ITSM tool without factoring in their organizational and process maturity will fail to obtain the intended ROI from their investment.

Introduction

IT organizations preparing to select ITSM (see Note 1) tools typically compile a large list of requirements from multiple IT stakeholders and then add generic ITIL process references. This RFP approach results in a long list of technical questions that solicits similar answers from each bidding vendor and does very little to distinguish among offerings. 1

Requirements that loosely reference common ITIL processes are often added, even if the organization is not ready to implement them. This approach frequently results in the selection of a vendor and product based on criteria that are not important to the organization. In addition, the organization may wind up paying for features that won't be used. (See "IT Service Support Management Tool Acquisitions Must Be Based on I&O Maturity." )

Gartner analysts have also encountered prospective buyers reusing the RFP from a previous selection process. This almost certainly means that the I&O leader has not examined the organization's current needs or growth requirements. I&O leaders often select a tool based on the assumption that they will be able to configure the new tool to behave like the old tool. This approach is unlikely to lead to the best result for the organization.

ITSM tool purchasing behavior trends indicate that, by 2020, 90% of organizations that invest in an ITSM tool without factoring in their organizational and process maturity will fail to obtain the intended ROI from their investment. 1

Analysis

Perform a MoSCoW Analysis to Distinguish Crucial Requirements

Because many vendors respond to lengthy checklist-style RFPs with almost identical, boilerplate answers, slight differences in replies tend to have a disproportionally large impact on the final scores. It is therefore of the utmost importance to ensure that your technology selection isn't based on unimportant requirements.

To avoid this pitfall, conduct a MoSCoW analysis to designate the relative priority of different feature requirements. Use the four categories shown in Figure 1.

Figure 1. Categories of a MoSCoW Analysis for ITSM Tool Features

Source: Gartner (May 2017)

Treat must-have requirements as pass/fail criteria. If a vendor cannot meet these requirements, you should remove that vendor from consideration, regardless of how successful it may be in the other categories. If a vendor claims it can satisfy your must-haves without customization, you need to acquire proof before letting that vendor pass to the next stage.

You can simplify the selection process by asking vendors to complete a prequalification questionnaire (PQQ) containing only your must-haves. A PQQ asks vendors to confirm that they meet all your essential requirements, but it does not require or expect them to supply detailed answers for scoring purposes. By either supplementing or supplanting a request for information (RFI), a PQQ can help you quickly eliminate incompatible vendors before starting the detailed RFP process.

However, when taking this approach, you need to ensure that your must-haves really are crucial. Double-check that none of them are actually should-haves before you begin excluding vendors. If possible, analyze the PQQs without revealing to stakeholders which vendors face elimination, so that bias doesn't affect the decision. If a vendor admits that its product cannot meet a must-have requirement without modification, but claims that the product could be customized to add that functionality in the future, treat the vendor as a fail. If all bidders are excluded on this basis, reclassify the relevant requirement as a "should-have (without customization)" and award a low score (such as two out of five) in the final scoring stage.

Once you have determined your must-haves, aim to limit your should-haves to noncommoditized functions and important, but not crucial, capabilities. I&O leaders typically place too much attention on commoditized ITSM tool features such as:

• "Tool generates a unique ticket number for each incident."
• "Tool can create a problem ticket from an incident."

Noncommoditized functions are more likely to be unique to your organization or industry. Consider the following examples:

• "Mobile business user location can be dynamically determined so that the tool can automatically assign the closest on-site engineer at the time of the issue."
• "The tool should provide a dashboard that enables support staff to prioritize incidents from a mixture of phone calls from standard users and appointment requests from doctors, so that the appointments generally take priority."

Concentrating on specific, noncommoditized functions will help to separate vendors further.

Next, limit the number of could-haves because they lengthen the process for all participants without adding value to the final decision. Could-haves should be considered only in the event of a tie between two or more bidders — after factors such as price, total cost of ownership and vendor stability have already been evaluated. You might also want to consider the vendor's roadmap as a potential tiebreaker, although you would have to pursue references indicating how well the vendor sticks to its roadmap.

Won't-have-yet requirements should be documented internally, but not on the RFP. Most RFPs that Gartner sees include requirements that are beyond the I&O organization's current capabilities.

Finally, a MoSCoW analysis requires you to assign score weightings to the different categories of requirements. You do this by assigning more weight to must-haves and should-haves, and less weight to could-haves. The weightings are discretional, but Gartner recommends the following:

• Must-haves: 5x
• Should-haves: 4x
• Could-haves: 1x

Table 1 shows these weightings in action. Although Vendor 2's total unweighted scores exceed Vendor 1's, Vendor 1's total weighted scores exceed Vendor 2's due to better performance on the must-have and should-have requirements, which have higher weightings.

Table 1.   Results of Applying Suggested Weightings to Requirement Categories

Category	Priority (MoSCoW)	Vendor 1  Score  (0 to 5)	Vendor 1 Weighted  Score	Vendor 2  Score  (0 to 5)	Vendor 1 Weighted  Score
Requirement A	Must Have	4	20	3	15
Requirement B	Should Have	3	12	3	12
Requirement C	Should Have	3	12	2	8
Requirement D	Could Have	3	3	4	4
Requirement E	Could Have	2	2	4	4
Requirement F	Could Have	5	5	5	5
	Total Company Score	20	54	21	48
	Average Company Score	3.3	9	3.5	8

Source: Gartner (May 2017)

Use Delivery-Specific Criteria When Comparing SaaS Offerings With On-Premises Offerings, or Vendor-Direct Offerings With Reseller Offerings

ITSM products are available primarily as SaaS or on-premises offerings, but they can also be provided as hosted solutions. Additionally, these tools may be supplied directly by the vendor or indirectly via a reseller.

RFP processes that include a mixture of these options are common, but Gartner finds that the requirements used to compare them are often biased toward one approach. For example, traditional RFPs that include sections contributed by infrastructure staff often list technical hosting requirements, such as server OS support. Such requirements are invalid when assessing a SaaS-based bid, and make valid comparisons harder to achieve.

Also, resellers and implementers may focus more on the implementation project and may be better at restricting the service offering to the project's scope. By contrast, vendors selling direct tend to highlight the full capability of their product, even when it's not suitable for the IT organization in question. The result is that realistic promises often score lower than inappropriate claims.

When evaluating a mixture of delivery formats, change any requests and questions that do not fit all cases into higher-level requests that focus on outputs and value. Table 2 gives examples.

Table 2.   Change Requests and Questions to Focus on Outputs and Value

Before	After
Detail your antivirus update process and frequency on the application servers. We use ACME software for intrusion detection in our infrastructure. Is the ITSM tool fully compatible with this product?	Explain how you guard the integrity of the service against external attack.
How will the software be installed?	Describe the high-level implementation plan for our organization.

Source: Gartner (May 2017)

Share Your Vision, Including Your Issues and Goals, With Vendors

ITSM tool vendors won't understand how to tailor their offerings to your IT organization's needs unless you:

• Communicate your organization's progress through the various phases of IT maturity
• Inform vendors of your issues and goals

For example, if you are using Gartner's "ITScore for Infrastructure and Operations" as a model for improving maturity, communicate your current level to vendors. Then, explain your goal for moving between levels, such as progressing from Level 2 to Level 3. To flesh out your story:

• Focus on specific strengths associated with organizations at higher levels of maturity (for example, effective problem management processes or strong release management programs)
• Provide a few examples of use cases to give vendors more context and a better chance to test their solutions' suitability

Often, RFPs include a list of questions that ask only, "Do you have function A? Do you have function B? Do you have function C?" Accordingly, these questions elicit a long list of basic responses like, "Yes, we do." Even when a vendor replies, "No," that response usually accompanies an explanation of how the vendor will offer the function in the future. The comments that accompany each response make it difficult to understand the extent to which the offerings will enable value. This flawed approach is commonly used when an RFP refers to ITIL processes that the IT organization aspires to, or has heard of, but has no established plan to implement. Ultimately, it produces little opportunity to differentiate between bidders.

Instead, you should identify the goals that you want a new ITSM tool to help you achieve. Ask the vendors to explain how their product will help you reach your goals. Be candid about your current capabilities and maturity, and share this information with them. Most ITSM tool contracts and subscriptions are for 36 months, so ask for a solution that suits both your current needs and your proposed changes — that is, the processes you plan to implement during the next 18 months. By taking this approach, you can avoid overinvesting in features that may not be used before the next renewal.

Consider your reasons for switching from your existing service desk tool, and ask vendors to explain how buying their product won't result in similar limitations and complaints. For example, suppose you are seeking to improve problem management and your goal is to reduce the reoccurrence of outages by 50% or more. The vendor could show how its solution would capture trending information and identify potential root causes more effectively than alternative offerings.

Although your story will not take the form of a numbered checklist, it's still advisable to use numbered points throughout. A numbering scheme will help ensure that all points are covered, because vendors will have to respond to each point. This scheme will also help your procurement department reference the answers in any ensuing contract, to make the vendor accountable for the claims that led to its selection.

This approach helps foster a longer-term relationship with the supplier, which takes some responsibility for the solution. It also creates an opportunity to tie renewal conditions and exit clauses to meaningful system performance. Vendors that are not prepared to do this are identified quickly, giving you early insight into how they would behave after a deal is done.

Implement an Essay-Style RFP to Make Vendors Explain Why Their Solution Is Best for Your Needs

Instead of just answering "yes," "no" or "partially" to the numbered items in your story, bidding vendors should respond in essay form. Request this response format when you deliver RFPs to vendors. Ensure vendors include case studies and reference examples of how they have met such requirements for other customers. The vendor's reference customers should be similar to your organization in terms of size, industry and geographic reach, so that results are comparable. Vendors should provide evidence of positive outcomes, either directly or via references.

Essay-based responses take longer to produce. Vendors that don't expect to be successful, as well as those that are interested only in easy wins, are likely to withdraw their bids. This is a risk that must be considered, but there are obvious benefits to having a shorter list of only fully committed vendors. In practice, vendors that truly want your business will seize the opportunity to respond fully. By contrast, vendors that aren't fully committed won't.

Essay-based responses also take longer for you to score. Processing them incurs more cost from a time and resource standpoint. Therefore, focus on fewer questions that, when thoroughly answered, will give you a true sense of each vendor's ability to deliver a solution that meets your needs. Consider which three questions would give you such a sense. Example requests to vendors include the following:

• Describe and quantify how your solution will improve the efficiency with which my I&O team delivers service.
• Describe and quantify how your solution will make my entire organization better.
• Describe and quantify how your solution will improve the maturity of my I&O organization.
• Describe and quantify how your solution will help me communicate the value of IT service and support to my business.

Because of the time-consuming nature of essay-style RFPs, it's especially important to limit your requirements to critical criteria, as explained above. This will keep the process as short as possible. Concentrate on getting high-value responses to the questions that really matter. When it comes to essay-style RFPs for ITSM tools, less really can be more.

Acronym Key and Glossary Terms

MoSCoW

MoSCoW is a mnemonic that stands for "must have, should have, could have, won't have yet" (the lowercase o's have no representative significance). It is a business analysis technique used to categorize the priority of requirements in a project. The technique was developed by Dai Clegg of Oracle UK Consulting for rapid application development (RAD) projects in 1994, and is now officially part of the dynamic systems development method (DSDM).

Evidence

1 From April 2015 through April 2017, 9% of the Gartner client inquiries about ITSM tools required Gartner analysts to review RFPs, which often contained over 300 line items.

Note 1 
ITSM vs. ITSSM

Previously, Gartner used the term "IT service support management (ITSSM)" to refer to the operational tools used by IT support teams. Gartner now uses the term "IT service management (ITSM)" instead. This terminology change reflects ITSM's expanding importance to more than just support organizations. It also enables our clients to find relevant content more easily. Gartner will continue to segment ITSM tools as basic, intermediate and advanced. All active research on gartner.com that refers to "ITSSM" remains valid and should now be interpreted as describing ITSM tools.

© 2017 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc. or its affiliates. This publication may not be reproduced or distributed in any form without Gartner's prior written permission. If you are authorized to access this publication, your use of it is subject to the Usage Guidelines for Gartner Services posted on gartner.com. The information contained in this publication has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information and shall have no liability for errors, omissions or inadequacies in such information. This publication consists of the opinions of Gartner's research organization and should not be construed as statements of fact. The opinions expressed herein are subject to change without notice. Gartner provides information technology research and advisory services to a wide range of technology consumers, manufacturers and sellers, and may have client relationships with, and derive revenues from, companies discussed herein. Although Gartner research may include a discussion of related legal issues, Gartner does not provide legal advice or services and its research should not be construed or used as such. Gartner is a public company, and its shareholders may include firms and funds that have financial interests in entities covered in Gartner research. Gartner's Board of Directors may include senior managers of these firms or funds. Gartner research is produced independently by its research organization without input or influence from these firms, funds or their managers. For further information on the independence and integrity of Gartner research, see "Guiding Principles on Independence and Objectivity."

•