PDF version of this report
You must have Adobe Acrobat reader to view, save, or print PDF files. The
reader is available for free
download.

Best Practices for
Preparing a Request for Proposal

by Faulkner Staff

Copyright 2021, Faulkner Information Services. All
Rights Reserved.

Docid: 00018560

Publication Date: 2112

Report Type: TUTORIAL

Preview

The principal instrument for successful procurement of enterprise systems
and software is a well-crafted request for proposal (RFP). The RFP should
focus on the business needs to be addressed by the acquisition and elicit
vendor responses that are specific, complete, and of a consistent format
to facilitate cross-vendor comparisons. The winning vendor’s RFP response
can then be 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
• Related Reports

Executive Summary

[return to top of this
report]

Effective contract management comprises a series of steps. 

Related Faulkner Reports

Identifying Acquisition Needs Tutorial

Evaluating RFP Responses Tutorial

Negotiating and Writing Contracts Tutorial

Ensuring Contract Performance Tutorial

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 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 renegotiate
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. The principal instrument for
success in this endeavor is a thoroughly defined RFP. Those buyers who
develop an effective RFP can reap a significant return on investment due
to having meticulously described their 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 the one that most
effectively responds 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 articulate 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 the RFP’s 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 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. In addition, RFP preparation tools can reduce the time and work
involved in preparing an RFP while still creating customized results.
Tools that allow both the distribution of RFPs and the processing of
results to be handled electronically can greatly reduce the time and
potential errors involved in data entry and analysis, 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]

After a company has identified its acquisition needs, an RFP is used to
detail the solution the enterprise wants to implement and to evaluate
vendor proposals in a systematic and consistent manner. The RFP accurately
communicates the organization’s needs to potential vendors, and it enables
the 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 a 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 compare, and
contracts that are easier to enforce. With a careful RFP process, a
company can also reduce the chance of large cost overruns; slow or
hard-to-use software; software that is missing mission-critical features;
and expensive, unplanned data conversions.

There is no standard format or outline that RFPs must follow. 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. A good RFP is
highly detailed, and therefore lengthy.

A well-designed RFP provides structure to the procurement process and
helps a buyer to:

• Define and prioritize needs.
• Attract high-quality vendors by showing serious buyer interest.
• Save money via increased price competition among vendors.
• Base decision-making on objective data and “apples to apples”
  comparisons.
• Minimize the risk of selecting an unsuitable vendor or system.
• Increase “buy-in” during implementation by involving users in
  decision-making.
• Secure project funding based on a rigorous, well-researched approach.
• Improve 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 company’s existing local or wide area network?
• Compatibility – Is the system compatible with
  industry standards and the company’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.
• 
  Security
  – Is the system in compliance with all relevant
  security and privacy standards, regulations, and guidelines?
• 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 per user or
  is a site license available?
• Compatibility – Will the software run on the
  company’s current systems, or is additional hardware required?
• 
  Security
  – Is the software in compliance with all relevant
  security and privacy standards, regulations, and guidelines?
• 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?

Request for Information (RFI). 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.

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. However, the procurement process 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 relevant and
well-written RFP will pay off over time as the enterprise benefits from
systems and software that best suit its requirements.

RFP Preparation Tools. Some companies offer RFP
preparation tools that reduce the time and work involved in preparing an
RFP while still creating customized results. Companies offering RFP
preparation tools include:

• Bentley Systems
• EC Sourcing Group
• Infotivity
• PostRFP
• RFP360
• Scanmarket
• Technical Acquisition Specialists LLC

These packages include project domain checklists, sample questions, and
customizable RFP templates that a company can fit to a particular
procurement situation by adding, deleting, modifying, and prioritizing
questions. For example, the solution from RFP360 features:

• RFx development & administration – Manage all requests in a
  template library – simplifying, standardizing and improving every RFx
  you create.
• Workflow & collaboration – Assign tasks, set deadlines,
  collaborate and communicate with stakeholders, suppliers and scorers in
  one solution.
• Evaluation & scoring – Collect, score and compare responses in a
  single view, driving more informed and objective buying decisions.
• Dashboards & reporting – Generate reports for insight into past
  responses and glance at dashboards to see the status of RFPs and tasks.

The cost of RFP preparation software should be at least partially offset
by savings from increased efficiency, accuracy, and competition.

Electronic Distribution and Processing. RFP tools with
electronic distribution and response processing greatly reduce the time
and potential errors involved in data entry and analysis, 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 improve the quality of data
collected from vendors, by validating vendors’ responses as they are
entered, and by providing on-line help for vendors.

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.

By using electronic bidding and evaluation throughout the sourcing
lifecycle, companies can also meet requirements for transparency and
auditability in public procurement. For example, ProcureWare (from Bentley
Systems) automates supplier diversity tracking, sealed bidding, and an
auditable log of bid events.

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.

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 often results in an 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. Automatically converting the list of user
requirements into 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 providers of enterprise systems
and software. Since an RFI offers a simpler mechanism for promoting a
vendor’s solutions than a full RFP, it can “level the playing field” and
give a small provider a fighting chance against a larger competitor (who
may have more experience and resources for responding to RFPs, including
technical writing staff and even a library of existing proposals
which can be modified and submitted with little effort).

Beware the Omnibus RFP

RFPs should not be overly broad, with requirements that only a major
provider could satisfy. While sourcing all requirements through a single
provider might be attractive from a supplier management perspective,
splitting an large-scale RFP into two or more smaller RFPs might yield better
results, since more specialized – and, potentially, more capable – smaller
providers can more readily respond to more narrow requirement sets. Sourcing
hardware or software requirements through multiple providers may produce
integration issues but overall product and service quality should improve.

How to Prepare and Submit an RPF

The following steps outline a best practice process for preparing and
submitting an RFP.

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. 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, and data interfaces required
  with other company and third-party databases.
• 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.
• Special security requirements, such as adherence to the European
  Union’s (EU’s) General Data Protection Regulation (GDPR) or other
  similar standards or regulations.
• 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.

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 help determine
the project schedule by identifying which improvements will have the best
ROI and should be completed first.

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 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 gather information
quickly 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, rather than 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.

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

RFP questions should be written with the evaluation process in mind. 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 difficult to compare and evaluate responses,
whereas good formats elicit responses that are focused, concise,
consistent, and specific, contributing to an explicit, enforceable
contract.

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.

RFPs should also provide a framework that ensures that vendors’ responses
are consistent and constrained. Some electronic RFPs validate vendor
inputs to ensure the format for each field is adhered to.

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. Nonetheless, without
freeform questions, vendors might be denied the opportunity to
accurately and comprehensively describe their offerings.

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.

Another way to assign weights is to use percentages that indicate how
important each feature is to the final decision. For example, if price
will count for 30 percent of the decision, the price section can be
assigned a weight of 30. Such rankings make 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 the time and
potential errors involved in data entry and analysis, 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 is often evaluating the buyer as a potential business partner,
and a well-designed RFP is likely to be the first step to developing a
successful business relationship.

Step 9. Schedule a Vendor Q&A Session

Even with the best-written RFPs, vendors will often ask for
clarification. To ensure that all vendors are given the same
information, and to avoid answering the same question more than once, a
vendor question-and-answer session should be scheduled, usually about a
week after the RFP is transmitted. The best forum is a limited-duration
Zoom-style teleconference, for which each vendor is asked to submit
questions in writing about two days in advance. The enterprise
submitting the RFP will collate the questions, eliminate any duplicates,
and prepare appropriate responses. On the occasion of the teleconference,
an enterprise moderator will read the questions and answers, leaving
perhaps 15 minutes at the end of the session for spontaneous vendor
queries. Instead of a live Q&A session, some companies receive and
answer vendor requests for clarification online.

Web Links

[return to top of this
report]

• Bentley Systems: https://www.bentley.com/
• EC Sourcing Group: http://ecsourcinggroup.com
• Infotivity: http://www.infotivity.com/
• PostRFP: http://www.postrfp.com/
• RFP360: http://www.RFP360.com/
• Scanmarket: http://www.scanmarket.com/
• Technical Acquisition Specialists LLC: http://www.rfpteammanager.com/

 

[return to top of this
report]