A Request for a Proposal (RFP) can be applied to all manner of projects, large and small. It is also incredibly useful for finding out exactly what a contractor or outside services supplier will offer you for a given job, as well as formalising your relationship with them, laying the ground rules and defining and agreeing costs.

Outside companies read the RFP and write a proposal, or a bid, explaining how they can meet your requirements for the project. Comparing all the bids side to side will then enable you to select your preferred supplier.

Many public sector and government agencies have set requirements and standards for their RFPs. The reason for this is that they can ensure they have covered all the angles, and that there is a written documentation of what is expected, for the sake of both sides. It also ensures uniformity and accountability across projects. RFP documents can run in size from a single sheet to a small book.

Many small and mid-sized businesses, on the other hand, may not have a formal RFP requirement, but it is worth having a formal structure, for the reasons described above. Here are some guidelines on what may be useful to include in an RFP.

Executive Summary

This is a summary of the entire proposal, written in plain business English and explaining the work that is required.


This section will contain a brief introduction to your business and your business processes, and the current issue for which the RFP is being raised. It will also spell out what you intend to achieve in terms of short or long-term business goals.

It might be a good idea to mention the benefits that project completion will bring to the company, and perhaps your supplier evaluation and selection processes.

You could also mention in this Executive Summary your selection parameters, which might include the time it takes to carry out the project, the price, flexibility, and requirements for innovation.

These terms will, of course, vary from project to project, so an IT migration will differ from an implementation, a pilot trial of particular hardware, and so on.

Statement of Need

The Statement of Need, also termed the Requirements Section, is likely to be the largest part of the RFP, taking up to two thirds of the information in the document.

This section talks about why the project is necessary and is the nub of the RFP. The statement of need clearly defines the problem, and discusses why the project needs to happen. It might also describe the positive results of a particular programme or project.

It is a good idea to be as descriptive and detailed as possible in this section because RFPs that have vague requirements often result in wasted interview time and high cost estimates to compensate for the unknown.

You are not aiming to provide solutions in this section, just lay out the issues in a logical manner. With this in mind, you might like to gather and lay out any relevant facts or statistics that will help to explain the need for the project.

Consider requesting information from the relevant departments and stakeholders in the business beforehand to assist with this.

Project Description

In this section, you will describe how the project will be implemented and evaluated. The level of detail is up to you, but it should give a clear indication of what is involved.

This is the place to incorporate any relevant technical and infrastructure information in the case of IT projects, and detail the stakeholders who will be involved. These might be departments, partner companies or customers. Multiple business premises or specific IT systems may be involved.

Organisation Information

This part of the RFP can be used to describe the details of the organisation, and any specific location details. If there are any specific departmental or organisational details that are relevant to the project, they can be discussed here.

Key personnel, important contacts, and partners and customers that might be involved in the project can all be mentioned in this section.

You might also want to flesh out some of the company information given in the Executive Summary, to point out particular hierarchies or business units that might be relevant to the project.

Project Schedule

The project schedule, estimated project duration, including the start and end date, are listed in this section. You might like to include trial or pilot phases, implementation and evaluation periods, and proposed go live dates.


Time is important, and so is money. Consequently, it is important to include a budget in your RFP.

Put aside thoughts that disclosing your budget is a mistake, and that it will leave you open to predatory firms, price gouging, and generally being taken for a ride.

The opposite should be the case. Carefully and clearly-costed RFPs will give confidence to suppliers, and indicate that the project is at a mature stage and has been approved by the business.

Disclosing the budget will also help suppliers to prepare a more sophisticated bid, and help you weed out the ones that are not suitable.

In addition, responding to an RFP also has costs for the supplier, because they will have to put aside dedicated resources, and perhaps invest in staff and research and development, as well as equipment and technology. They may also be turning down other deals in favour of yours. These are all good reasons to get the budget right.

Scope for Vendor Innovation

Vendors, systems integrators, value-added resellers and other service providers all have their own best practices to offer.

So, it is worth making room in your RFP to allow for innovation, and to allow your partner the space to bring in processes that you may not have thought of.

These might include outsourcing parts of an operation, bringing in virtualisation technology to test and scale applications more quickly before going live, using particular business intelligence or analysis tools, or even reorganising teams and departments. Bids that introduce innovative solutions like these may well be worth a second look.

Resources on Writing RFPs

The Request for Proposal Handbook by Michael Asner, New Fourth Edition, Completely Updated, Released June 2010
Request for Proposal: A Guide to Effective RFP Development – Bud Porter-Roth
RFP's Suck: How to Master the RFP System Once and for All to Win Big Business - Tom Searcy – Prewritten IT RFPs – Bid, RFP and proposal software