|
Crafting The RFP For Enterprise Applications
Adapted from Info-Tech Research Group's McLean Report.
Selecting an enterprise application package is a daunting task. It involves a variety of steps such as establishing the selection committee, determining requirements, and—most importantly—drafting the Request for Proposal (RFP). But using the following recommendations from Info-Tech will help you avoid the most common pitfalls of crafting an RFP for applications such as Enterprise Resource Planning (ERP) or Customer Relationship Management (CRM).
Recommendations for Crafting an RFP
1. Establish the core needs. The enterprise application needs to support both existing functions and the functionality specified in the strategic five-year plan. These core needs must be expanded into detailed terms for the RFP.
2. More is less. Too much detail in an RFP can be a bad thing. Info-Tech recommends limiting RFP documents to less than 20 pages for several reasons:
advertisement
Vendor response to long RFPs is poor. Many vendors are unwilling to commit presales resources to the completion of long RFPs. This situation is particularly acute for relatively small enterprises that, from a vendor's perspective, are unlikely to result in a considerable sale. In extreme cases, a long RFP may result in no vendor response.
Long RFPs take a long time to assess. Selection committees have the responsibility to review completed RFPs. And reviewing a large number of 120-page submissions is a very onerous task that, in many cases, undermines the value of asking for submissions in the first place.
They mask the core needs and vendor expertise. Long RFPs often involve a large number of items that aren't reflective of the core needs. Soliciting information on non-core items introduces superfluous information into the decision process. It may also limit the vendor's opportunity to share its expertise.
advertisement
3. Consider the entire project lifecycle. Many RFPs are very technology-centric and make the assumption that the enterprise will be implementing, hosting, and supporting the application internally. But many enterprises seek a single solution provider to deliver all of these capabilities. In this case, these elements must be included as components of the RFP.
4. Don't start from scratch. Where possible, leverage existing RFP templates such as the McLean Report's "Request for Proposal Template."
5. Find substance. Creating the detailed terms of an RFP can be a harrowing experience. There are two common approaches and most enterprises use a combination of the two:
Crib from existing materials. Collect a variety of RFP templates and vendor marketing materials. Sequester the selection committee in a meeting room. Go through the templates row by row and ask the committee: "Do we need this item?" This approach is most often used by teams that lack business analysis experience. It can be effective but has two shortcomings. It frequently results in overly long RFPs and it is blind to requirements that may not be included in any of the sample RFPs.
Develop formal requirements. Another approach is to map existing processes and to model the needs required as part of the strategic plan. This approach is most commonly used by enterprises with an experienced business analysis function. In many cases, much of this documentation may already exist as documentation for other projects. The International Institute of Business Analysis provides additional guidance on modeling these processes, notably in A Guide to the Business Analysis Body of Knowledge (v 1.6) [PDF]. Users of this approach also face two challenges. The first is reifying poor processes and the second is creating overly long RFP documents.
6. If necessary, use an RFI to get the RFP to the right place. Complicated projects involving hosting and implementation, as well as technology, may require the use of a preliminary Request for Information (RFI). The purpose of the RFI is to determine which vendors are willing to respond to such an RFP or which implementation/hosting partners will respond. Info-Tech offers a McLean Report "Request for Information Template."
7. Double check: Do you really need the RFP? Crafting an RFP is often the first response of IT staff. The RFP enables the selection committee to make sense of the project. In many cases, it may also be unnecessary, particularly in situations where there is actually a very limited range of available solutions. The RFP will simply introduce more complexity into the selection process. Never be afraid of not sending out an RFP if the process of preparation reveals that it is actually not necessary. Certain enterprises may, for example, discover that there are only one or two vendors that actually provide appropriate solutions. For other considerations, refer to the McLean Report research note, "Establish Real Need Before Issuing an RFP," which is available from Info-Tech.
Bottom Line
The RFP is an important input when selecting an enterprise application such as ERP or CRM. Use Info-Tech's recommendations to avoid the most common pitfalls of crafting an RFP.
Info-Tech Research Group is a global leader in providing IT research and advice. Its practical, actionable research is specifically designed to have a clear and direct impact on organizations. This article has been reprinted by permission.
Also see: Establish Real Need Before Issuing an RFP, available to your constituents with our compliments.
|
