Developing Your Procurement Document

Components of a Request for Proposal (RFP)

Your purchasing department or procurement division likely already have a well-established RFP method that will include the following topics:

1. A Statement of Goals: This section clearly defines the problems that the application of the software being acquired is intended to solve and how it is to operate. A mission statement, a list of objectives, or targeted performance measurements will go a long way toward developing a common understanding among all stakeholders in the system development process.
   
   
2. A Schedule of Activities: Recognizing that dates can be subject to change, producing a schedule of the anticipated RFP activities properly prepares both client and vendor in anticipating time, staff resources and potential travel arrangements required in order to meet expectations. As a minimum, we recommend that the schedule include the following key dates:
   
   
   • Release of RFP
   • Deadline for Submitting Questions
   • Deadline for Question Response: We recommend a minimum two-week window of time between all questions being answered and the RFP Deadline for Submission due date selected to allow vendors to incorporate answers to questions into their response.
   • RFP Deadline for Submission: We recommend a minimum of four weeks from release of RFP to RFP Deadline for Submission due date. For more complex RFPs, we recommend an allowable response period of six to eight weeks. RFPs with tight turnaround times send the message that a preference has already been established for a particular solution or vendor. Shorter response time frames can compromise quality of the proposal and generate fewer vendor proposals to choose from.
   • Short-Listed Vendors’ Product Demonstrations
   • Contract Award
     
     
3. Definition of Terms: This section provides vendors with a clear understanding of technical and administrative terms used by your organization and by the information technology industry. Such a section has proven to be invaluable in avoiding misunderstandings that frequently arise when one party or the other has a different meaning for a term contained in the contract. A glossary of terms can establish and help maintain common understandings.
   
   
4. Current Practices and Expected Change: As previously described, this section provides the vendor with a description of the current practices of your organization and the exact changes that your organization is seeking as a result of the IT application. Include current and anticipated volumes, total number of internal and external users.
   
   
5. Technical and Business / Functional Requirements: As previously discussed, organizations have had successful procurements with either brief or very detailed lists of technical and business/functional requirements in their RFPs. These are often provided in grid/table format.
   
   
6. Your Project Team Resources and Commitments: This section provides vendors with a clear understanding of how your Project Team will be structured, and how various team roles will be resourced. Clearly state role allocations, such as “full-time dedicated position” or “XX hours per week for duration of project”.
   
   
7. Pricing Requirements: This section provides vendors with clear instructions on how to present costs for vendor software and third-party software licenses, vendor services, hardware, and annual maintenance and support services.
   
   
8. Administrative and Contracting Requirements: “Master Agreement” or “Standard Form of Agreement” contract templates are typically provided by your Purchasing Department and/or legal counsel. Please include your boilerplate pro forma contracts, costing, risk management, insurance certification, and other key documents in full for legal review.
   
   
9. Other Procurement/Project Requirements: These are typically provided by your Purchasing Department, Equal Employment Opportunity (EEO) Office, and/or legal counsel. Include anticipated procurement, contracting and implementation timelines. Your procurement and/or legal department may require vendors to comply with certain mandatory terms and conditions in contracts and/or organizational legislation or policies addressing privacy protection (FOIP) or Equal Employment Opportunities (such as participation goals for visible minorities or local small business enterprises).
   
   

Developing Your Evaluation/Selection Criteria

Finally, your purchasing department or procurement division likely has a well-established proposal evaluation format and methodology that represents a properly balanced framework aligned with your organization’s priorities.

Common Proposal/Vendor Evaluation Criteria

Common proposal/vendor evaluation criteria often includes the following:

• Functional fit, end user friendliness of the proposed software
• Fit with your organization’s technology standards and requirements
• Strength and appeal of the vendor’s proposed implementation approach and methodology
• Proposed maintenance and support services; proposed hosting services
• Strength of the vendor’s proposed project team members and team organization
• Client references, client testimonials, client awards
• Vendor’s financial stability; financial strength
• Vendor’s track record for implementation success, failed projects, pending or historical lawsuits or other legal actions against
• Cost, relative to other vendors’ proposals
• Any added value the vendor’s solution might provide to your organization
  
  

Common Proposal/Vendor Scoring Criteria

Overall proposal/vendor scoring criteria typically includes a score or evaluation weighting applied to the following:

• Vendor’s technical proposal
• Vendor’s pricing proposal
• A shortlisted vendor presentation or live demo of the software product
• Client reference checks

NEXT WEEK: Evaluating and Selecting a Vendor.