U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590
Preparation of a RFP [Request for Proposal], is very common when developing an Intelligent Transportation System. This chapter discuses the technical and project management aspects of an RFP. It does not cover, with the exception of the following chapter on Intellectual Property Rights, contractual or legal issues related to procurement. Procurement options are covered in Chapter 4.9.
The primary purpose of an RFP is to tell prospective contractors what is needed. It is always good to remember,” If it is not asked for, it probably will not be provided”. This is especially true when the procurement is going to be cost competitive. Here, a contractor is going to be penalized if they provide something needed that wasn't specifically asked for. This also will cause difficulty in justifying a higher price. On the other hand, if the RFP is too specific the contractor may be discouraged from bidding a lower cost solution which is perfectly adequate.
Following is a list, and description, of the most commonly found parts of a good RFP. Not all of these parts may be required every time and for every type of procurement.
SOW [Statement of Work]
The Statement of Work tells the potential contractor what tasks are to be performed. The SOW is like the Project Plan discussed in sections 3.4.1 - Project Planning, and 7.5.1 - Project Plan Template. It always contains a high level description of the project to give the prospective contractors a sense of the context of their work. It is generally written by breaking down the work to be done into a number of individual tasks. Then, each task is described by its inputs, approach, and outputs. The inputs are the information needed by the contractor to do the task. The approach is guidance on how the task is to be done [for instance, specific trade-off studies may be required]. The outputs are the products of the task, such as: documents, meetings, and deliverable hardware and software. It is important to describe the contents of any required documents. Chapter 8.4 of this Guidebook gives descriptions of some of the most common documents that could be required. All tasks, including administrative tasks, need to be included in the Statement of Work.
One or more technical specifications may be required to describe the products to be procured. If the product is COTS, a part number or model number is all that is necessary. If the product is to be developed, then a requirements specification is needed. Chapter 8.4.6 provides templates for a requirements specification.
Sometimes the requirement specifications are planned to be written as part of the contractor’s effort. In this case, some level of a description of the intended product is still needed and this must be prepared before the RFP is released.
The RFP must contain a schedule for the tasks. This schedule should be at as high a level as possible. It should only contain dates that must be met by the contractor. Examples include: a start date, a delivery date[s], or a date after which an important external system is available. Let the contractor propose internal dates, such as: delivery of a specification, delivery of design documents, and start of verification. In fact, the contractor should propose a schedule for every deliverable of every task.
List of Deliverables
It is good practice to compile a comprehensive list of all deliverables, including documents, products, and meetings. This identifies, in one location, all of the deliverables needed to complete each task of the project. All deliverables are referenced to the task that produces them. They are also listed as outputs of that task. Documents are referenced to the document descriptions and products are referenced to the appropriate specification, if any. This list includes information about quantities. It also includes ground rules for agency review & comment ,and for incorporation of comments.
Contract Terms and Conditions
Contract terms and conditions are generally provided by the agency’s procurement or purchasing departments. Much of these contract terms are standardized and apply to any procurement. However, some will be specialized to a specific type of contract or procurement. It is important that they are compared to other parts of the RFP package to avoid conflicts.
Format of Proposal
The RFP needs to tell prospective bidders what their response should look like. Generally, this is in terms of both form and content. Quite often, for instance, a page limit is placed on their response. This helps them keep their focus on the items the agency wants to see. The main purpose of specifying the format and content of the response is to make it easier to compare bids from different contractors, and to ensure enough information is available to make that comparison.
A typical proposal may be asked to include:
Qualification and Experience
It is always necessary to obtain information about the qualifications and experience of the contractor and the key employees. This provides an indication that the contractor can perform the work requested. The demonstration of experience should include a list of comparable projects completed and references to the procuring agency. Qualification of employees is often provided in tailored resumes.
Quite often, the RFP requests that all cost data be submitted separately from the rest of the response. This is done so that the technical evaluation of the proposal is not tainted by knowledge of the cost of the proposal.
The cost figures are generally requested to be broken down in several different ways. Typically, costs are broken down by task. Within a task, the breakdown between labor costs and other direct costs [itemized] are shown. Labor is also shown by hours and by labor category [e.g. senior engineer, junior engineer].
Sometimes, a breakdown of the total cost is requested to show labor costs, direct costs, overhead, and fees.
RFP Evaluation Criteria
Evaluation related guidance is given to the contractors in preparation for completing the RFP. It is rare when an ITS proposal is evaluated by cost alone. Generally technical, management, experience, and qualifications are given equal, if not a higher, weighting. The purpose of this part of the RFP is to show contractors exactly what factors [based on information contained in their responses] will be evaluated and what relative weights will be given to each.