This article originally appeared in the January/February 2015 issue of SupportWorld magazine.
Those of you who have gone through the process of preparing RFPs for service management software know how laborious it can be. Preparing all the information and organizing it can be the equivalent of obtaining a mortgage and buying a house. We wind up with mountains of documents that are intended to give us clear comparisons among possible solutions, but which may, in fact, merely make the whole process more painful and more confusing. Is it all really necessary?
Forrester research director Eveline Oehrlich has said that there are two major reasons to consider changing service management tools: Either the tool you have does not provide a way for you to achieve the goals you want to achieve, or you are frustrated with your existing vendor.
Which of these best describes your organization? Knowing that answer right up front can help keep you pointed in the right direction and determine some other choices along the way.
Before embarking on the journey to choose a new service management tool, you need to know what your service management needs are.
Know Before You Go
Before embarking on the journey to choose a new service management tool, you not only need to know what your service management needs are, but also what the expectations of your business are. As we have learned in recent HDI research:
- More than half of organizations have adopted or are planning to adopt service management processes and principles outside of IT.
- Of those organizations, 61 percent were influenced by the capabilities of their service management tools.
Will your organization be joining the ranks for those who are expanding service management to HR, facilities, finance, or other areas of the business? That is an important consideration. Even if your organization isn’t headed in this direction, you need to know where it is headed before you start down the road of selecting a tool.
Cross Features Off Your List and Think About Benefits
“Customers often ask the wrong questions during product evaluations and therefore don’t get the answers they need. Think about it—multiple-choice is far easier to pass than an essay-style exam, and do you really need that infrequently adopted ITIL-espoused capability? If you don’t, why on earth are you asking for it?”—Stephen Mann, 50 Shards of ITIL—The Bane and Pain of ITSM Tool Selection.
The often-discussed “shiny object syndrome” can occur when people are persuaded to purchase something based on its features as opposed to its benefits. If, for example, your organization has concentrated on three of the most common ITIL® processes and had no plans to do otherwise in the future, should you be spending time evaluating tools that support a dozen processes? Support for those other processes may be a feature of the solution, but if you are not using it, it is not a benefit for your organization. It’s like buying a pickup truck with a 12,000 pound towing capacity when you don’t own or use a trailer and have no intentions of ever doing so.
You should be thinking about which aspects of a new product can assist you in getting to your desired destination, or beyond. While it’s very nice to have a sports car, the car won’t do you much good if you really need a pickup truck. Then you need to think about whether you really need that expensive crew cab on your truck, or whether a standard cab with a little storage behind the seats will do nicely.
So, Do You Still Need an RFP?
Many organizations—government agencies for example—may have legal requirements to include RFPs as part of due diligence. We have a downloadable RFP template on our website for any HDI member who would like to use it.
Aside from compliance, is there really a need to go through a difficult process that is fraught with political potholes and potential “scope creep”?
Let’s consider what an RFP really is: A method of documenting the organization’s needs and requirements clearly so that better (“apples-to-apples” if you will) comparisons can be made among potential providers. At its root, this is a good thing, and you do need to document your requirements.
But let’s take a look at things from the side of the solution provider.
- Long, detailed RFPs eat up time not only for you, but for the solution provider as well.
- Differences in terminology may cause later issues. You and the solution provider may refer to the same thing in different ways, and even slight differences can mean that something doesn’t work the way you expected.
- Depending on time constraints, a perfectly viable vendor for you might choose to pass on your RFP if they don’t have the available time or think that the chances of a sale are low.
- RFPs developed by you have your current situation and plans baked in, but may not have room for the innovations the solution provider is working on. There may not be room in your RFP for the forward-thinking vendor.
- Your RFP may discourage great new solution providers from responding, simply because they are new and you don’t provide a way for them to convince you they are worth a look.
Many times, what an RFP winds up being is a long and detailed checklist, and the solution provider mainly goes down the list and checks off the “yes” box. And so do all the other solution providers you contact.
RFPs as we know them don’t tell you much about:
- Look and feel—important especially for people who will be in the product day after day.
- Innovation- how the provider is going to grow and change over the next few years.
- The personal factors- ultimately, you’ll be dealing with people, not a company. You’ll need to develop trust and a sense that the vendor understands you and your organization.
If We Do Away with the RFP, How Will We Choose?
There isn’t a magically easy way to choose the right product, and even if you don’t do traditional RFPs you still need to conduct a highly organized search for the right tool and the right vendor. Remember, you are spending your organization’s money, and probably a lot of it. Here are some considerations:
- List the goals you need to achieve with this project:
- Technical goals—what problems will you solve
- Business goals—what processes will you enable and/or automate?
- Get the right people on the project team
- One or more good project managers
- People who understand the technologies
- People who understand the processes
- People who understand the business goals
- Get the right amount of buy-in
- Chances are you will be working across functions. Make sure that you have the management approval and commitment to get what you need.
- Don’t aim for higher approval than you really need; you may delay the project unnecessarily.
- Do a basic search to find candidate solutions and providers
- Use resources like the HDI Buyer’s Guide as a central search point
- Ask around your network and read available reports to find compatible solutions
- Build a simple scorecard based on your own criteria for success. Don’t leave out the “people” part of people, process, and technology.
- Plan a “first pass” and work with your team to narrow the field.
- Seek out existing and past customers of the solutions short list. Interview them in as much depth as time will allow. Find out what they like, what they don’t, and why. Don’t only interview customers that the vendor provides; ask your connections as well.
- Ask the vendors if they need a formal RFP form you, or what format they would like to use. Work with them as a partner seeking the best outcome.
- Build a demo schedule. If possible, get the parties in the same room.
- Watch out for “scope creep” but be flexible enough to allow for some change in your requirements and plans. You and solution providers may each make discoveries as you work together. Establish a deadline and criteria for changes.
- Document your findings and present them to stakeholders.
- Select your best candidate and make the transition to implementation.
If this sounds very similar to an RFP process, it is, but you may be able to bypass the strict requirements of the RFP itself and spend your time in the process of selecting the right solution from the right provider for your organization.
Roy Atkinson is HDI’s senior writer/analyst. He is a certified HDI Support Center Manager and a veteran of both small business and enterprise consulting, service and support. In addition, he has both frontline and management experience. Roy is a member of the conference faculty for the HDI 2014 Conference & Expo, and he’s known for his social media presence, especially on the topic of customer service. He also serves as the chapter advisor for the HDI Northern New England local chapter. Visit www.HDIconnect.com and follow him @HDI_Analyst.