Your browser does not support JavaScript!

Chapter 24 - Requests for Proposals and Competitive Negotiations

Appendix D: Contents of a Quality IT RFP

Section Section Content description



Provides a statement of the problem and must be detailed enough for suppliers to grasp the business issues driving the RFP and the technical issues that may have precipitated the problem.


Proposal instructions and administration

Contains all administrative requirements and information with which a supplier must comply in order to submit an acceptable proposal. This section includes ground rules for the procurement, from submitting the RFP to awarding the contract and should contain the following types of information:

  • if and when a pre-proposal conference will be held
  • relevant dates for the procurement cycle
  • requirements for preparing and submitting proposals (i.e., Code of Virginia requirements, as well as proposal protocol)
  • how proposals will be evaluated
  • RFP Single Point of Contact name and contact information
  • when, where and to whom proposals are due
  • other information that is required for a supplier to be fully responsive

If the instructions are incomplete or unclear, suppliers may overlook critical meetings or milestones. Some suppliers may view the lack of quality instructions as a sign of a weak project team or conflicted project which could influence major industry suppliers to not submit proposals. Failure of a supplier to comply with the RFP’s administrative requirements may be cause for proposal rejection. This section should present clear rules for responding to the RFP and to make suppliers aware of the penalties for not following them.


Proposal format

Provides details on how proposals are to be formatted and bound and the required media (i.e., hardcopy, CD, etc.). It is helpful to include a table to show if various proposal sections are to be submitted separately; i.e., technical from cost, redacted, etc.). This section should not duplicate or conflict with the proposal instructions in section 2.


Present situation

Accurately describe the agency’s organizational background and the project’s current business and technical environments so suppliers can effectively and accurately propose solutions to adapt or modify that environment to satisfy the new requirements. Description of the current business environment should include all users and benefactors of the current business services and processes affected. Description of the current technical environment should be a clear definition including all current hardware and software being used, what could be used or should be used to address the project requirements, as well as current interfaces to other existing systems/platforms and/or applications. Workflow and application interfaces may be presented using visuals.


Functional and technical requirements

Provides functional and technical requirements and enough information to enable suppliers to understand the issues and prepare a complete and firm proposal. This overview should address both the current business application and the technical environment (hardware, software, communications). It is recommended that agencies not use “must” and “shall” technical requirements, but allow suppliers to suggest how they will solve the problem as part of a solution- based proposal. The technical and functional requirements section includes questions to which suppliers must respond, such as:

  • critical success factors
  • functional specifications for the current system
  • functional specifications for the projected system
  • performance specifications
  • service level expectations
  • hardware requirements (if mandatory)
  • software requirements
  • security and data protection requirements
  • communications requirements (if mandatory)
  • testing requirements
  • whether their solution complies (or can comply) with VITA Security, Data Standards and Enterprise Architecture and IT Accessibility/508 Compliance ITRMPSGs

Project management requirements state the conditions for managing and implementing the project. This section should provide suppliers with information they need to develop a project plan, risk mitigation plan or other management plan, as required for the complexity and mission criticality of the project and that spans requirements definition, implementation, installation, testing, training, maintenance, and other phases of the project. The proposed project plan provides assurance that the supplier has the resources required to perform the contract successfully. The project management plan typically contains the following:

  • staffing requirements
  • site preparation responsibilities
  • delivery and installation schedule and plan
  • system acceptance test requirements
  • system maintenance requirements
  • system training requirements
  • documentation requirements

Agencies should remember that it is possible a supplier can meet the technical requirements, but cannot meet the management requirements as evidenced in their poor or inadequate responses to this section. The management section will help differentiate between suppliers with mature or immature management capabilities.

You may ask suppliers to identify all assumptions and any potential risks associated with the RFP and desired project objectives; and/or ask them to describe in detail a similar project and how they resolved problems or issues that occurred during their performance to their customer’s satisfaction.


Clear and distinct Performance Measures and Enforcement Provisions

IT solicitations and contracts that meet the definition of “high risk,” as defined in § 2.2-4303.01 of the Code of Virginia, must include clear and distinct performance measures and enforcement provisions, including remedies in the case of Supplier non-performance.

Use the tools below to learn more about clear and distinct performance measures and enforcement provisions, including remedies:

         Minimum Requirements Matrix for Major IT Procurements, High Risk IT Procurements, and

         1.  Delegated Procurements 

         2.  Performance Metrics Tool



Supplier profile

Suppliers are asked to describe their business and professional qualifications and to provide references. They should be asked to present detail about their corporate and financial status and the customers who will serve as references for their professional performance and integrity. The following examples are what is typically required in this section:

  • Supplier’s corporate history, organizational structure, locations and business-size status (i.e., DSBSD-certification status, if applicable).
  • Supplier's general background experience and capability for providing the type of solution or product being
  • A description of the relationship between supplier and any proposed partner/ subcontractor/manufacturer, if any, and how long this relationship has been in
  • Evidence that supplier has the necessary technical, operational and management skills, staff and financial resources and viability to perform the
  • A list of same/similar currently installed products, systems or
  • Names of customers with similar projects, configurations and/or applications who can provide references, including contact names and telephone numbers.
  • Supplier’s qualifications, including resumes, company profile and business
  • Supplier’s usual method of providing services including a description of the work plan, methods to be used and a sample schedule of deliverables/timeline for project


SWaM Section

Suppliers are asked to provide a “Supplier Procurement and Subcontracting Plan” that states the overall commitment percentage that Supplier anticipates spending directly with subcontractors in performing the requirements of the contract. Additionally, Suppliers are asked to provide a list of all subcontractors it anticipates using in Supplier’s performance of the contract. The list of subcontractors should designate those subcontractors that are SWaM businesses, as well as those that are non-SWaM businesses. In the event that a Supplier does not anticipate using subcontractors in the performance of a contract, the Supplier are asked to state this fact in their response.


Pricing information

Specifies how suppliers are to provide pricing information and provides a detailed format for them to follow in developing their price proposals. Instructions should be clear enough to ensure that price proposals can be compared on an equal basis. To facilitate this comparison, consider providing a sample spreadsheet that breaks the proposed system into components such as the following:

  • system software
  • application development software
  • installation
  • maintenance
  • training
  • documentation
  • project management
  • integration of unique hardware or software
  • license fees (ongoing)

Include a pricing schedule/scenario as an example of how proposal prices must be submitted. If lump sum pricing is not advantageous, use a pricing scenario to obtain prices for unknown quantities or hours. Ask for a breakout of recurring versus non-recurring costs. The pricing schedule should be tied to deliverables and must coincide with the method of payment stipulated in the solicitation.

When looking at pricing schedules, pay attention to pricing that involves one-time costs versus recurring costs. The initial price of a software package is a one-time cost; annual maintenance and software licensing fees are recurring costs which must be identified to develop a project’s total life-cycle cost. Pricing is not usually the sole determinant for award, but should be used to break a tie between two suppliers with equally good technical and management proposals.

For complex projects you may also ask suppliers to submit a milestone pricing schedule to which holdback percentages can be applied to be paid after final acceptance on the final invoice. This motivates suppliers and adds protection for the agency if final acceptance is delayed or problematic. It also allows easier contract severability at any milestone if the supplier is non- performing.


Agency standard agreement (i.e., contract template)

Contains a proposed contract template with nondisclosure agreements, confidentiality, data protection and security requirements, warranties, licensing agreement requirements and other statutory, legal and IT-specific terms and conditions, or any federal flow-down terms that may be required. Suppliers should be asked to redline the proposed contract template to highlight all exceptions they cannot agree to. Suppliers should not redline the liability clause at this time.

They can raise issues or comments for the first time during negotiations later. Identify showstopper issues during the proposal evaluation period because it is possible to select a supplier who will not accept the agency’s contract.


Supplier’s section (optional)

Allows suppliers to include information they feel is relevant although not required or requested in the RFP. They can also discuss potential issues that are relevant to the RFP and to their proposal. For example, a supplier may have additional product features to demonstrate that are outside the scope of the RFP, present a unique solution that was not anticipated by the buyer, or may provide a solution to a problem evident in the RFP that other suppliers did not consider. Even if this particular supplier does not win, the explanation of the problem and the potential solution may still be worth considering.



Contain bulky but relevant information such as network diagrams, technical requirements studies, project plan outlines and other detailed information. Examples include the following:

  • Spreadsheets with statistical
  • Communications network drawings and
  • List of current
  • Standards used within the
  • Tentative project plan with
  • Contract template
  • Small business subcontracting plan form
  • Supplier-completed State Corporation Commission form as registered to transact business in the

The information is then available to the supplier but does not distract from the narrative portion of the RFP. Note: Tell suppliers whether they must use this information when developing their proposals.

Search the manual by key words or common terms.