When it's time to update a software system, many IT people dread what they see as the onerous process of creating the request for proposal, or RFP. These documents -- sometimes hundreds of pages long -- seem to take forever to create, collect and review.
At the same time, RFPs are vital to setting the rules of the game with potential vendors and eliminating misunderstandings, says Jay Hollander, managing member of Hollander and Co. LLC. With that in mind, here is some advice from a collection of experts on making this process more effective so that you get started down the right path to choosing not just the right software but also the right vendor to partner with. (Click here for additional online resources.)
Widen the Net
Many RFPs fail because companies don't know exactly what they want or they don't create a robust set of requirements. What does the system need to do? How will it look when it's complete?
To get this information, you have to round up all the stakeholders that the system will likely impact, says John Lakey, manager of the Acquity Group, a business and technology consultancy headquartered in Chicago. "People think that if the system was their idea, they should just go forward with it," he suggests. "But because most systems have multiple uses, all the stakeholders need an opportunity to be heard during the selection process."
You may even want to include input from your customers, especially if 50% or more of your business is geared toward one or two large clients, says Bob Anderson, vice president of small and midsize applications at Gartner Inc. "It makes a lot of sense to talk to customers and see where they would like to see improvements," such as better inventory visibility, he says.
Shorten the Document
Just because you solicit opinions from a cross-functional team doesn't mean you have to include every single requirement in the actual RFP document. You can simplify the document substantially if you include just the critical requirements, according to Billy Maynard, an analyst in the business applications practice at Gartner. "I've seen RFPs close to 1,000 pages in length," he says. "But we recommend that people focus on fatal flaws, those capabilities that are unique to their industry or define their competitive advantage." Maynard suggests limiting the final version to 50 critical requirements.
This will really help hone down the list of vendors you should be pursuing, Lakey agrees. "Eighty percent of requirements, generally speaking, will be met by everybody," he says. "It's that remaining 15% that you should be interested in."
Consider an RFI
Getting to that 15%, however, might require some research on available system offerings, Lakey advises, especially if you aren't on top of current software capabilities. (See which vendors meet your technical and business requirements by using MA's Comparison Tool.)
"After coming up with your key criteria, it might be a good idea to engage some of the players in the software category to show demos of their packaged software before moving into the RFP stage," he says. "Otherwise, you run the risk of not knowing what you should be asking for."
Play it Close to the Vest
You may choose not to reveal the priority status of your requirements, however, as it may tip the vendor off to what it should emphasize in its responses, Burns says.
"If you tell them which are the highest priorities, it might skew their responses a bit," he suggests.
Drive for Specifics
To get the most useful responses to your RFP, you should minimize the vendors' ability to be ambiguous in their answers, Burns advises. "If you give someone the opportunity to be ambiguous, they will be," he says. For instance, a "yes" response can mean anything from "the feature is available out-of-the-box" to "it can be done with some customization or third-party help." One way around that ambiguity is to ask the vendor to respond with a number from one to seven, for instance, where a "1" means the feature is available now and a "7" means it will be available in a later release.
This will also enable you to perform better comparisons. "The RFP document should be structured in a way that allows for easy and objective comparison between vendor responses," Hollander says. For instance, rather than soliciting "essay" answers, go heavy on the "short answer" component in terms of question style, he says. In addition, he advises, ask for response information to be provided in a format of your choosing and insist that all non-conforming responses will be rejected without further consideration.
Talk Turkey
Don't forget to ask for pricing on the RFP, Lakey says. "This will speed the process of down-selecting to two to three vendors for negotiation," he says. You can make comparisons easier by asking them to express pricing in standard terms, such as "per user" or "per CPU," he says.
Other specifics essential to the RFP include when responses are due, when interviews of the resulting short list of vendors will be held, when any supplemental information must be received, and when a decision will be made, Hollander says.
Further Legalities
To hold the vendor to its responses on the RFP document, Hollander suggests requiring that the RFP and the vendor's responses be appended to the ultimate contract signed between the company and the selected vendor.
You should also consider making it known that the RFP is copyrighted and can't be redistributed without permission, Hollander says. This can inhibit vendors from shopping the RFP to freelancers and other independents, and it can stop them from showing the company's project plans to competitors, he says.