I need help with NETWORK250: Week 1 iLab Activity Voice/VoIP Admin w/Lab

Best Practices for Preparing a Request for Proposal

by Betsy Walli

Copyright 2010, Faulkner Information Services. All Rights Reserved.

Docid: 00018560

Publication Date: 1012

Report Type: TUTORIAL

Preview

A well-crafted, thoroughly defined RFP is the principal instrument for successful procurement of enterprise systems and software. The RFP should focus on the business needs to be addressed by the acquisition, and be designed to elicit vendor responses that are specific, complete, and of a consistent format to allow cross-vendor comparisons. The winning vendor's RFP response can be automatically incorporated into an organized, detailed contract. RFP preparation tools that allow electronic distribution and results processing greatly reduce data entry and analysis time, as well as printing and distribution costs.

Report Contents:

● Executive Summary ● Description ● Current View ● Recommendations ● Web Links

Executive Summary [return to top of this report]

A well-crafted, thoroughly defined request for proposal (RFP) is the principal instrument for successful procurement of enterprise systems and software. An RFP should focus on the business needs to be addressed by the acquisition, and be designed to elicit vendor responses that are specific, complete, and of a consistent format, to allow cross-vendor comparisons. The winning vendor's RFP response can be automatically incorporated into an organized, detailed contract. RFP preparation tools that allow electronic distribution and results processing greatly reduce data entry and analysis time, as well as printing and distribution costs.

Effective contract management comprises a series of steps.

The first step is to determine the business needs that the technology procurement will address. Next a company must prepare and distribute a request for proposal (RFP) that articulates those needs. After evaluating the proposals it receives in response to the RFP and choosing a supplier, the company is ready to negotiate and write a contract with the supplier. The company must then be prepared to ensure contract performance, and to re-negotiate the contract when circumstances change. Each step builds on all the preceding ones. Contract management is most successful when a company approaches each step with this entire process in mind.

The procurement of enterprise systems and software is a complex process that must be carefully planned and executed. A well-crafted, thoroughly defined RFP is the principal instrument for success. Those buyers that develop an effective RFP can reap a significant return on investment (ROI) due to having meticulously described business requirements for a select group of vendors. The RFP is a critical link between the buyer and the seller that enables both to work from the same set of requirements, schedules, and information. The winning vendor is awarded the contract after effectively responding to the RFP’s stringent list of questions and criteria.

Successful RFPs are clear and complete. Many RFPs fail because they neglect to include some basic technical requirements. To enable suppliers to provide the best solution, an RFP must present a clear understanding of all technical issues, as well as providing a method for implementing and managing those issues. RFPs should also be articulate in describing acceptable business practices to suppliers, and they should be designed to elicit a vendor response that can be converted easily into a contractual agreement that retains much of its original form.

Preparing an RFP and reviewing subsequent proposals is a labor- and time-intensive activity, but enterprises that prepare RFPs properly will reap rewards from solid, mutually beneficial partnerships as a result. The time and effort spent reviewing and comparing vendor responses to a detailed RFP can be minimized if a company first narrows the field of potential suppliers to a short list of the most promising prospects and sends the full RFP only to them. RFP preparation tools can reduce the time and work involved in preparing an RFP while still creating customized results. RFP tools that allow electronic distribution and results processing greatly reduce data entry and analysis time, as well as printing and distribution costs. Once a vendor is chosen, that vendor's electronic RFP response can be automatically incorporated into an organized, detailed contract. Another option is to hire an outside consultant with detailed business process knowledge to help with the RFP process and to ensure that all pertinent issues are addressed.

Description [return to top of this report]

An RFP is used to detail the solution an enterprise wants to implement and to evaluate vendor proposals in a systematic and consistent manner. It accurately communicates an organization’s needs, and it enables a company to determine the suitability of a proposed system. An RFP is not used to learn about a vendor’s technology. For that purpose, an enterprise should write an request for information (RFI), which is discussed later in this report.

An effective RFP requires vendors to make concrete and detailed commitments when submitting competitive bids on products and services, which leads to proposals that are easier to evaluate and contracts that are easier to enforce. With a careful RFP process, a company can also reduce the chance of large cost overruns; software that is missing mission-critical features; slow or hard-to-use software; and expensive, unplanned data conversions.

RFPs do not necessarily follow a particular format or outline. They typically provide a list of essential business requirements, with each business process addressed in a separate section. Within each section, the vendor is asked to address how it can meet each requirement. RFPs should be highly detailed. They thus tend to be lengthy.

According to On-Line Consultant Software (OLC), the provider of an automated RFP development tool, a well designed RFP provides the following benefits:

● Requires buyers to define and prioritize their needs. ● Adds structure to the procurement process. ● Allows for "apples to apples" vendor comparisons. ● Provides objective data that support informed decision-making. ● Increases price competition among vendors (which saves the company money). ● Increases vendor participation by showing serious customer interest. ● Minimizes risks in vendor and system selection. ● Involves users in the decision-making process, increasing the likelihood of "buy-in" during

implementation. ● Helps ensure project funding by demonstrating a rigorous, no-nonsense approach to capital

spending. ● Helps in the interpretation of vendor contracts and dispute resolution.

While the details may differ, most RFPs for enterprise systems and software address the same fundamental issues. For hardware acquisitions, these factors include (but are not limited to):

● Performance - What are the minimum acceptable performance characteristics? Response time? Turnaround time?

● Peripheral Equipment - What speed is required? What capacity? ● System Backup - How are backups performed? Is the system configured to conduct full

backups? ● Connectivity - How will the system be integrated into the customer's existing local or wide area

network? ● Compatibility - Is the system compatible with industry standards and the customer's existing

equipment? ● Fault Tolerance - What are the "single points of failure"? Can the system be configured to

minimize or eliminate these exposures? This is particularly important for mission-critical applications that demand very high system availability.

● Maintenance - How does the vendor handle maintenance? In many cases, hardware support is outsourced to a third-party firm. Where is the nearest spare parts depot?

● Upgrade Path - Is the system expandable or upgradable? What is the process and what are the limits on growth?

● Future Product Plans - What are the vendor's plans for new or enhanced systems?

● Price - What is the cost? Are any volume discounts available?

For software procurements, the factors include (but are not limited to):

● Ease of Use - What impact will the software have on productivity? How can this effect be measured?

● License Fees - Is the software licensed by user or is a site license available? ● Compatibility - Will the software run on the customer's current systems, or is additional hardware

required? ● Documentation and Support - What documentation and help are available, and in what form?

Manuals? Online "help" systems? Toll-free customer service phone numbers? ● Installation and Training - How much training and installation support does the vendor provide?

At what cost? ● Upgrade Path - Is the software expandable or upgradable? What is the process and what are the

limits on growth? ● Future Product Plans - What are the vendor's plans for new or enhanced versions? ● Price - What is the cost? Are any volume discounts available?

Current View [return to top of this report]

RFP preparation can be a laborious and daunting process due to the size and highly technical orientation of the document. It can therefore be tempting to buy and use a generic RFP or to reuse an RFP that was developed for a past procurement. The procurement process, however, will be far more successful if the RFP is tailored to a particular organization’s present needs, priorities, and business environment, which requires careful planning and execution. The investment in preparing a well-written RFP will pay off over time as the enterprise benefits from systems and software that best suit its requirements.

Short List Selection. Reviewing and comparing vendor responses to a detailed RFP can be time- consuming. This effort can be minimized if a company first narrows the field of potential suppliers to a short list of the most promising prospects, and then sends the full RFP only to the short list. To narrow the field of suppliers, a company distributes a brief document that covers only its "must-have" major requirements. The best three to five responses to this request for information (RFI) become the short list.

RFP Preparation Tools. Some companies, including Infotivity, OLC, and SupplierSelect, offer RFP preparation tools that reduce the time and work involved in preparing an RFP while still creating customized results. These packages include project domain checklists, sample questions, and RFP templates that a company can fit to a particular procurement situation by adding, deleting, modifying, and prioritizing questions. For example, Infotivity offers sample RFP questions and layouts for a variety of applications, including accounting, electronic document management software, manufacturing, order processing/inventory, web site development, and workflow processing. EC Sourcing Group reports that implementing their sourcing and vendor management software can cut negotiation time and administrative costs by about 50 percent, and that the increased competition it facilitates can result in savings of 18 percent on an average contract.

Electronic Distribution and Processing. RFP tools with electronic distribution and processing greatly reduce data entry and analysis time, as well as printing and distribution costs. Some RFP software includes an electronic user requirements survey whose results can be incorporated into an electronic RFI or RFP, with automated short list preparation based on the vendor responses. An electronic RFP can also validate vendor input and provide on-line help for the vendor.

An interactive, electronic RFP can be distributed via CD or email attachment, or uploaded to a company’s web site for vendors to download and respond to offline. A web-based document that must be responded to on-line can be used for a small request for quote (RFQ) or RFI (less than five pages). Some programs require the vendor to download special software to read and respond to the RFP; others require only a browser.

The electronic RFP is not just a word-processing document. It is linked to a database to enable automatic correlation of vendor responses with RFP questions. Vendor responses can be automatically merged, tabulated, and reported, without the time and errors that would be involved with manual data entry. The electronic vendor comparisons thus obtained can then be analyzed to help select the most suitable proposal. Once a vendor is chosen, that vendor's electronic RFP response can be automatically incorporated into an organized, detailed contract.

Consultants

Another option is to hire an outside consultant with detailed business process knowledge to help with the RFP process and to ensure that all pertinent issues are addressed. Infotivity, for example, provides consultants who can develop vendor and product short lists, and prepare RFIs and RFPs.

Recommendations [return to top of this report]

The success of the RFP is dependent on a comprehensive listing of business-related user requirements. The tedium of the needs determination and RFP preparation process, however, often results in the enterprise omitting some important supplier requirements. Workflow checklists and user survey tools can help speed this process, and they can organize, prioritize, and summarize the information that is collected, to reduce the chance of important needs being left out or overlooked. Automatically converting the list of user requirements to the RFP will ensure that all the user requirements are addressed in the RFP.

Some companies fail to find the best solution for their business needs because they cast their nets too narrowly when assembling a list of potential suppliers. Although RFPs are rarely sent to more than five vendors, RFIs can be sent to a larger number of vendors to gather information about vendors before selecting a short list. For the best chance of finding the optimal solution to its needs, an enterprise should diversify its list of potential suppliers by sending RFIs to both well established large vendors and small enterprise system and software providers.

Importantly, for smaller or less well-established vendors, the RFI vehicle can help provide a "level playing field." Remember, larger vendors have advantages over their smaller competitors. A large vendor will:

● Have more experience in responding to an RPF; and ● Maintain a library of existing proposals from which a new RFP response can be assembled - at

least in part - through "cutting and pasting."

In addition, a large vendor may have a seasoned technical writing staff skilled in interpreting RFP language, and crafting RFP responses. Since the RFI offers a simpler mechanism for promoting a vendor's solutions, it gives smaller providers a "fighting chance" against their larger counterparts.

How to Prepare and Submit an RPF

The following steps outline a best practice process for preparing - and submitting - a request for proposal.

Step 1. Determine the Business Needs to Be Addressed

Prior to writing an RFP, a company should carefully determine the business needs that the RFP will address. This step is described in the Faulkner report, Identifying Acquisition Needs. How well acquisition needs are determined has the potential to affect the success of the entire RFP and contract process. Ultimately, an RFP and contract cannot be considered successful if the goals they achieve are not meaningful to the company. Therefore, it is important for an RFP to focus on business needs, to avoid the mistake of acquiring unneeded technology just because it is available. On the other hand, a company should continue to learn about new technology in order to make informed decisions about whether that technology answers a business need for the company. If an electronic needs survey is used, the survey results can be incorporated automatically into the requirements section of the RFP.

Step 2. Describe the Project Domain

The project domain is the total environment in which the system will be used. Making this information explicit can help the company avoid data incompatibility problems, manual data entry, large error rates, and unexpected ongoing costs. The project domain also describes what parts of the business will be affected by the new system, such as sales prospects, the sales force, customers, inventory levels, project completion time, and business procedure efficiency. This information can help vendors plan configuration, installation, and user training. It can also affect the project schedule by identifying which improvements will have the best ROI and should be completed first.

The project domain covers topics such as

● Current networking environment. ● Space and power available for hardware. ● Staffing, user demographics, and skill sets. ● Current data formats and conversions; data interfaces required with other company and third-party

data bases. ● Boundaries of the new system; where and how it will integrate with other systems, procedures,

and departments; how and where information flows into and out of the proposed system. ● Overview of the business procedures targeted by the new system, the business problems to be

solved, and the goals to be achieved.

● Workflow of the affected procedures.

Some vendors of RFP tools offer a project domain checklist to help identify environmental issues and set the scope of the project. An asset management system can also aid in providing a comprehensive, accurate picture of a company's IT environment.

Step 3. Create a Short List of Suppliers

Before the formal RFP development process starts, an enterprise can use some alternative documents to query vendors about their products and services and to narrow the list of potential suppliers. Among these documents are the request for quotation (RFQ) and request for information (RFI).

Request for Quotation. Enterprises can prepare an RFQ to receive quoted or confirmed prices from prospective suppliers for budget planning or for subsequent purchase orders. The RFQ is used as a shopping tool to secure the best price among a group of suppliers selling similar products and services. Enterprises write brief RFQs for routine procurements regarding open or upgraded technology, such as larger hard disk storage capacity. For larger procurements, a more detailed RFQ explains the basic terms of the acquisition, and provides an evaluation structure designed to be fair for all competing vendors.

Request for Information. Enterprises that need to better understand the products and services offered by a multitude of potential suppliers should consider developing an RFI document before committing to the RFP process. An RFI is used to quickly gather information and obtain an overview of different vendors' technologies and approaches, in order to narrow the pool of suppliers to a short list of the three to five most promising companies. RFIs are concise, high-level documents that emphasize the enterprise’s business objectives and "must have" requirements, not specific processes. Once the enterprise collects enough information, it produces an RFP to evaluate the short list of suppliers and determine which one is best suited for the job.

Step 4. Follow a Basic RFP Template

A basic RFP template is shown in Table 1 below. Of course, a company may decide that its procurement situation requires different names or categories from those shown in this template. The category names are less important than the fact that questions and statements are grouped logically to make it easier to evaluate vendor responses. Nevertheless, it is good to start with a basic RFP template to reduce the chance of leaving out important information or questions.

Table 1. Basic RFP Template

Category Content Description

Executive Summary

An administrative information section that provides an overview or summary statement of the project. This one-page synopsis of the RFP's purpose is often the most widely read section of the RFP.

Background Background on the corporation or business division; background on the project; statement of confidentiality. Company history; key executives; sales force environment; technology environment. Current operating environment and business situation. (See the project domain description above.)

Project Schedule Administrative rules and deadlines, including the deadline and location for proposal delivery, the option date for vendor demonstration, the proposed date of final decision on awarding the contract, and the proposed date of project implementation. Also provides contact data for the person at the firm managing the project.

Business Objectives Description of the business problem, its scope and objectives.

Requirements Detailed business and technical requirements for managing and implementing the project, organized by business procedure. Enables suppliers to understand the issues and respond to the RFP coherently. Includes topics such as implementation and training; technical and human resource requirements; customer support and service availability; upgrade and maintenance policies; compliance with government regulations; integration and interfacing; data formats and conversions; and system expansion options and methods. The list of requirements should be comprehensive, including even what may seem like obvious, basic features, because the buyer and the vendor may not be making the same assumptions.

Vendor Profile Helps to assess a vendor’s stability, reliability, and qualifications. Asks for vendor's background, experience, customer references, key executive profiles, and financials (annual reports). Allows vendor to describe in its own words its qualifications for the job. Some RFPs ask vendors for a complete list of customer installations, or for the five most recent installations, so the vendor cannot stack the deck by picking and choosing favorable references.

Pricing Description of all purchase prices, licensing fees, upgrades, and associated guarantees. Initial and ongoing costs associated with the proposed system.

Legal Documents A contract and license agreement section with the purchase contract, non-disclosure agreements, and other legal documents.

Appendices Related white papers, technical diagrams, and any other information the vendor will require to complete its proposal, such as addresses and telephone numbers.

Step 5. Organize and Frame Requirements by Business Procedure

The requirements section of the RFP describes the business problems to be solved and the particular goals or requirements to be met. In this section, companies should focus on simplifying or improving business procedures, on accomplishing tasks faster and more efficiently, and on saving money or generating more revenue, not on the technology itself. For example, a company might state a need for software that is easily modified and expanded, rather than specifying a technique for creating such software, such as Object Oriented Programming. Another company might state a need for more efficient order processing or better inventory control, breaking it down into the components that make up the business procedures, and letting the vendors' proposals translate that into technological features and functions.

For easier budgeting, evaluation, and decision making, questions should be organized by business function category, not by type of technology. All features should be referenced back to the business process they affect, and to the financial impact each business process has on the company.

Step 6. Use Effective Question Formats

The question formats in an RFP affect the usefulness of the information returned, and the quality of the decision that is based on it. Poor question formats can make it hard to compare and evaluate responses, whereas good formats elicit responses that are focused, concise, and consistent.

RFP questions should be written with the evaluation process in mind, in formats that let the company quantitatively evaluate the responses to each question. They should elicit detailed, specific supplier responses that can form the basis of an explicit, enforceable contract. All vendors must be asked the same set of questions, and the RFP should provide a structure and framework that ensures that vendors’ responses are consistent and constrained. Some electronic RFPs validate vendor inputs to ensure the format is adhered to. Each question should address a single concept. If a lot of functionality is bundled into one question, the vendor response can be more difficult to interpret.

Questions should be objective and quantitative whenever possible, and avoid using subjective, general, or vague terms or statements. Terms should be defined if there is any possibility that vendors may have different definitions of the same term. If the RFP is unclear and vendors must call for clarification, it is difficult to make sure that each vendor receives the same information and instructions.

Different topics and questions will be suited to different question formats, so the RFP should use a variety of formats. Some topics will be expressed as statements of requirements, not questions. For example, the RFP can state that the vendor must provide source code; the vendor either accepts the stipulation or is disqualified. Other topics are suited to the multiple answer format, which lets vendors check off multiple answers to a single question.

Feature Support Matrix. Yes/no questions can be tricky. While it may seem that there are only two possible answers to a question about whether a certain feature is supported, vendors will often answer yes when that capability is partially supported, could be added through custom programming, or will be available in a future release. A better question format that distinguishes among the ways that a feature will be made available is the feature support matrix, which asks whether a capability is

● Standard and fully supported. ● Standard and partially supported. ● A free enhancement (added through custom programming). ● A paid enhancement (added through custom programming). ● Available in a future release. ● Not available.

This information can help determine both the suitability of a product and the risks involved in its implementation. For example, a feature provided through custom programming has a greater risk of being delayed or unreliable. A separate follow-up question can allow the vendor to explain its answer, and to commit to a cost for custom programming or configuration.

Freeform Questions. Freeform questions give vendors the opportunity to fully express what is distinctive about their capabilities and can include room for explanations and details. It can also be productive to ask vendors about possible alternative solutions that were not addressed in the RFP. Freeform answers, however, must be interpreted and compared manually and subjectively (not quantitatively). They are difficult and labor-intensive to compare because vendors' answers can differ in length, form, and level of detail. Therefore, the number of freeform questions should be minimized; they should be used only when other formats are not suitable.

Step 7. Assign Weights to Questions

To ensure that the most important requirements are given proper weight when evaluating a proposed system, questions should be assigned priorities and ranked by importance. Mandatory, or "must have," features can then carry more weight in the decision than merely important features, which in turn should carry more weight than desirable, or "nice to have," features. The mandatory list will include system constraints (such as the need to use an existing database or to interface with a legacy system), as well as key features. This ranking makes it possible to perform weighted grade point scoring when evaluating RFP responses.

Step 8. Send the RFP Electronically to a Short List of Suppliers

Electronic distribution and processing greatly reduce data entry and analysis time, as well as printing and distribution costs. An electronic RFP can automatically correlate vendor responses with RFP questions, so vendor responses can be automatically merged, tabulated, and reported, without the time and errors that would be involved with manual data entry. Moreover, once a vendor is chosen, that vendor's electronic RFP response can be automatically incorporated into an organized, detailed contract.

The enterprise should include a statement informing bidders that it will screen out all non-responsive and incomplete proposals to focus on acceptable proposals. Likewise, suppliers are not obligated to respond to the RFP if they find it poorly written. Suppliers will likely be selective in responding to multiple RFPs

with similar requirements and will opt to respond to the ones that are professionally packaged.

The buyer is not the only one shopping around for the best deal. The supplier, too, often perceives the buyer as a potential business partner, and the RFP is likely to be the first step to developing a successful business relationship.

Step 9. Schedule a Vendor Q&A Session

Even the best-written RFPs will prompt questions from the responding vendors. Also, many of the questions will be similar in nature. To avoid answering the same question twice, or worse, to avoid giving two different answers to the same question, schedule one vendor question-and-answer session, usually about a week after the RFP is transmitted. The best forum is a limited-duration joint teleconference, in which each vendor is asked to submit their questions - in writing - about two days in advance. The enterprise submitting the RFP will collate the questions - eliminating any duplicates - and prepare appropriate responses. On the occasion of the teleconference, an enterprise moderator will read the questions and answers, leaving perhaps fifteen (15) minutes at the end of the session for spontaneous vendor queries.

Web Links [return to top of this report]

EC Sourcing Group: http://ecsourcinggroup.com/ Infotivity: http://www.infotivity.com/ On-Line Consultant Software: http://www.olcsoft.com/ SupplierSelect: http://www.supplierselect.com/

About the Author

[return to top of this report]

Betsy Walli is a graduate of the Massachusetts Institute of Technology with a Ph.D. in linguistics. Ms. Walli is an independent writer and editor with experience in academic, technical, and marketing writing.

[return to top of this report]