Appendix D: Contents of a Quality IT RFP
Section | Section | Content description |
---|---|---|
1 |
Introduction |
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. |
2 |
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 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. |
3 |
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. |
4 |
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. |
5 |
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:
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:
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. |
6 |
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
|
7 |
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:
|
8 |
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. |
9 |
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:
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. |
10 |
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. |
11 |
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. |
12 |
Appendices |
Contain bulky but relevant information such as network diagrams, technical requirements studies, project plan outlines and other detailed information. Examples include the following:
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. |
Previous < | > Next
Search the manual by key words or common terms.