Skip Navigation

Chapter 14—Writing a Strong Request for Proposals

If your organization has chosen to buy an LDS, or at least some portion of it, you will need to write a request for proposals (RFP) to solicit bids from potential vendors. This section will provide a brief introduction to effective RFP writing. The information in this section draws heavily on Nancy Smith's report, Lessons Learned: Writing Requests for Proposals for Statewide Student Data Systems in Education. Additional resources in appendix C include an extensive collection of sample RFPs from state education agencies (SEA).


Basic checklist of RFP development

square icon Know your needs before you write an RFP or begin development work.
square icon Follow your state's procurement procedures.
square icon Define clear, specific, and measurable repquirements.
square icon Delineate critical requirements from optional enhancements.
square icon Focus on both process and outcomes.
square icon Build in safeguards to protect your agency.

Define Your Needs First

Before writing the RFP, you should have already completed thorough self- and needs assessments (if not, see chapters 6 and 8) and be ready to translate your requirements into an RFP that tells vendors what you want to purchase. If you are not sure of your requirements when you write the RFP, the bidding and development processes may become frustrating ordeals for everyone involved, and the completed system might not serve you well. If you did not separate needs assessment into a discrete activity completed prior to the development stage, analysts will have to define needs as they go along and solutions-building may be slowed down.

Start with an "RFI"


Before you write an RFP, consider issuing a request for information (RFI). In this document, an agency presents the problems it wants to solve and asks vendors to propose solutions, pose questions, and make suggestions. The advantages of issuing an RFI are that agencies receive early feedback from experts on the feasibility and cogency of their planned system, as well as learn about the range of possible solutions available to them before they write their RFP.

Take the time to discover your program area needs. How will you need to restructure the data for the LDS? What data will the users need? How will you need to deliver your data to users? How will you need to secure your data to protect student privacy? Try to foresee as many needs as possible to limit the number of requirements added during development. RFPs issued by other education agencies for similar purposes can provide helpful ideas (see appendix C for additional resources, including some RFP examples). A quality RFP contains a nearly exhaustive collection of clear and specific requirements. Encourage vendors to be creative, but do not leave room for misinterpretation. For instance, do not write "etc." in your RFP—say what "etc." represents. Do not ask for "quality"—explain how you will measure "quality."

Writing the RFP

Once you have defined your needs and those of your stakeholders, the next step is to write a strong RFP. This will help you find the right vendor, with the right product and services for the right price. Some states have a standardized method of writing RFPs, others are less formal and prescriptive, while still others do not write RFPs at all but may still need to document their requirements in some form.

The team assigned to write the RFP should include staff from various education agency departments. Ideally, the group should also comprise subject area experts who understand the content and business operations, policies and regulations, and the potential budget; as well as technology staff who understand the codes and bytes. District and/or school representatives should also be involved in defining requirements.

There are many approaches to writing RFPs. For instance, you may write one RFP for the entire system, compose one RFP with multiple components and let vendors choose which parts they will bid on, or create a separate RFP for each system component. If you take the latter approach, however, do not break the project into too many parts and focus too closely on specific pieces of LDS functionality. If the goal is a comprehensive LDS, writing RFPs for many small pieces may attract specialized vendors outside of education while dissuading those with more comprehensive, LDS-specific products and services.

Additionally, the RFP may be based on process or on solutions (deliverables or outcomes). In a process-based RFP, an education agency defines the "process" the vendor must follow. For instance, you might require a standardized development process based on the systems development life cycle, though this approach might discourage vendors from responding if their products have already been through a development process. A solutions-based RFP describes the desired results, but leaves the vendor to determine the process through which they are completed. A combination of these approaches may be best as each may lead to potential problems. Focusing solely on process may affect deadlines or result in final products that do not meet agency needs. On the other hand, concentrating on outcomes alone may ignore important details, such as the frequency of collections and integration with other applications.

Another recommended approach is to find a system that you like at another education agency, get a copy of that agency's RFP, and make necessary modifications based on your specific needs or your agency's RFP-writing guidelines. This will save you the trouble of starting the RFP from scratch.

The Forum has more detailed information...

... about RFP writing:

Anatomy of an RFP

An RFP may be composed of the following sections:

checkmark icon Project overview and administrative section
Consists of an overview or summary of the problem, along with administrative information about the expected management of the RFP.
checkmark icon Technical requirements
Provides technical requirements and enough information to help the vendor understand the request and write a firm proposal.
checkmark icon Management requirements
Specifies the expectations for managing and implementing the project.
checkmark icon Supplier/vendor qualifications and references
Asks for vendor qualifications and references; ideally specifies the format in which these should be supplied.
checkmark icon Supplier's section
Allows vendors to include information about themselves or about the project that is not specifically requested.
checkmark icon Pricing section
Specifies how the pricing information should be provided.
checkmark icon Contract and license agreement
Contains the purchase contract, nondisclosure agreements, and other legal documents.
checkmark icon Appendices
Includes relevant information that is too bulky to include in the RFP such as network diagrams, outlines and requirement studies.

(Reprinted by permission from Smith [2004], Lessons Learned: Writing Requests for Proposals for Statewide Student Data Systems in Education.)

Tips for RFP writing

Here are some pointers to keep in mind during the RFP writing process:

checkmark icon Provide background
Tell the vendor about the state's data environment, database development standards, business requirements, and other relevant information about how the agency does business. Without this information, vendors may make erroneous assumptions in their proposal and through the development process.
checkmark icon Do not specify the solution
Focus on the problems you want to solve and the existing environment in which the solution must work, not on a particular, perceived solution. Give vendors room to suggest their own solutions to those problems.
checkmark icon Define clear, concise, and measurable requirements
Distinguish critical requirements from nice-to-have add-ons. The vendor needs to know which requirements to include in the bid and which are optional enhancements that can be priced separately. This will make it easier for vendors to bid, and easier for you to interpret the proposals.
checkmark icon Specify costs, or do not
You may elect to specify the amount you will pay for a solution and have vendors say, "Yes, we can deliver for that price." Or you may withhold cost estimates and ask vendors to make offers. One state uses the latter approach, but asks vendors to submit their costs in sealed envelopes. The agency staff then assess each proposal before opening the envelopes, judging each bid on its merits rather than by its price tag. Once the judging period is over, if favorite vendors' prices turn out to be too high, the agency tries to negotiate a more acceptable fee.
checkmark icon See how much others paid
When trying to assess how much a solution should cost, ask colleagues in other agencies for information on their costs. Consider differences between your state or district and theirs (student populations, varying requirements, etc.) and make necessary adjustments.
checkmark icon Inquire about management practices
Ask how the vendor manages projects in terms of communication, risk management, methodology, quality reviews, etc.
checkmark icon Do not be too aggressive in your timeline
Be realistic and try to strike a balance between quality and speed. In addition to deadlines for the vendor, consider your agency's end of the bargain. What will you need to do or provide, and how much time will you need? In the end, your own education agency may cause the project to fall behind schedule. One state representative suggested that instead of emphasizing deadlines, agencies should put emphasis on quality results.
checkmark icon Ask for references from the vendor, perhaps even for the staff with whom you will be working
Take the time to check these references and see what others thought of the services they received. Are the staff technically capable? Does the vendor have enough staff to support the endeavor?
checkmark icon Ask vendors to propose additional features that could improve the system
Though you may not choose to accept their suggestions, they may have good ideas that could improve the functionality and utility of the system.
checkmark icon Get third-party opinions
Have a variety of people beyond the writing team review the RFP to make sure it conveys your intent and is free of ambiguities.
checkmark icon Realize that your RFP may not be perfect
The requirements, as you have written them, may be flawed and could cause problems during implementation. Allow vendors to offer corrections or alternatives.

On the safe side

What might you include to protect your organization? In your RFP, consider including some safeguards and stipulations to ensure you get what you need from your vendor. Here are a few examples:

checkmark icon Maintain the right to change the vendor's project manager if you are unhappy with his or her service.
checkmark icon Specify a limit to vendor staff turnover, perhaps to 25 percent or less. However, even if you say in the RFP that staff can only change by so much or in certain ways, know that turnover happens and you cannot always avoid it. If change must occur, ensure that the required knowledge transfer will be paid for by the vendor, not the taxpayers.
checkmark icon Specify that the project manager and staff you interview will actually work with you throughout the project. One education agency staffer suggested that vendors sometimes send their best team to the interview and then assign staff of lesser skill to the project once the deal is sealed.
checkmark icon Require that at least some vendor staff work onsite rather than remotely, if possible. Scheduling online or phone meetings can be a hassle and may impede regular and effective communication. If the vendor must work offsite, specify a number of onsite meetings and require that they cover travel expenses. Onsite vendor staffing offers many advantages. For instance, both in-house staff and consultants are more apt to ask questions if the vendor is onsite. In addition, more meetings can be held and they can be more easily convened with specific individuals or groups of people. If vendor staff will be allowed to work remotely (an option that may be more cost-effective and provide more flexibility), devise an agreement to specify requirements such as the number of site meetings needed (and who will pay the expenses); communication planning such as virtual meetings, emailing, and instant messaging; and service-level agreements for off-site staff.
checkmark icon Define deliverables in clear and unambiguous terms. Make sure these requirements have measurable results that hold the vendor accountable. Alternatively, ask the vendor to propose measures that can be used to assess the deliverables.
checkmark icon Require that deliverables meet certain quality criteria before they can be delivered (grammatically correct, spell-checked, formatted according to standards, etc.). Avoid wasting time correcting simple vendor mistakes.
checkmark icon Distinguish critical requirements from optional enhancements. In addition to the benefits discussed above, this can protect you by preventing the vendor from claiming that a requirement was an add-on that should cost extra. Clear specifications up front save time, frustration, and money later.
checkmark icon Ask vendors to include ongoing maintenance and support in their proposals. Agencies report that many vendors just want to build the system, get paid, and then leave the in-house staff on their own.
checkmark icon Request or define a plan for knowledge transfer so that your staff is able to manage the system when the vendor leaves.
checkmark icon

If you intend to rely on your vendor to communicate with the education community, make sure they have an organized approach to communication or, alternatively, include in the proposal a communication plan that they must follow.

  • Determine who is going to write the communications: the vendor may know the product best and should have a communications staff—avoid having the project manager or a technology staffer write communications unless a piece is technical in nature.
  • Define who the audience(s) will be.
  • Define a communications schedule, or at what milestones or intervals communications will be sent out.
  • Define the ways communications will be made.
  • Figure out, in general, what the communications will say (see chapter 12).
checkmark icon Ask the vendor to provide sample communications.

Take care when writing an RFP. Getting it right will save time and resources; and will help you get the system your stakeholders need.