In an earlier post we looked at the building blocks of A Well-Built RFP. In this post, we dig deeper into the construction of one of those building blocks – the Written Response.

When you refer to the RFP as a thing, you are typically referring to what we are referring to here as the Written Response. It is the document that should include:

• Project and organization background
• RFP calendar
• Communication plan
• Business or technical requirements in need of written feedback
• Scenarios that will demonstrate functional requirements

We will unpack each in greater detail below.

Project and Organization Background

An effective introduction will describe your organization and what you hope to accomplish with the project. A few questions you should answer in this section include:

• What should the vendor know about your organization?
• Why was this project initiated?
• What are the legacy technologies or strategies you are seeking to replace?
• How is revenue generated by the organization?
• How will success be measured?
• What timeline or other parameters have been placed around the project?

RFP Calendar

Providing your vendors with an RFP calendar can help ensure a smooth process. Key dates to include in the RFP calendar include:

• Date Issued
• Date Vendors must indicate participation
• Date of Vendor Summit / Q&A session
• Date Vendors must submit Written Response
• Date Vendors will be expected to demo
• Date Finalists will be selected
• Date of Final Decision
• Date of Board or Budget Approval
• Date of Anticipated Project Start

For example –

• January 15, 2015: RFP Issued
• January 31, 2015: Initial Vendor Response (accept/decline participation)
• February 5, 2015: Vendor Summit / Q&A Session with Project Team
• February 15, 2015: Vendor Question Deadline
• February 28, 2015: Written Response Due
• March 2015: Onsite Vendor Demonstrations (please select one of the following):
  • March 2-4
  • March 8-10
  • March 11-15
• April 15, 2015: Vendors to be notified if selected as finalist
• April 15 – 30, 2015: Follow-up Sessions with finalists
• May 10, 2015: Vendor Notification of Award
• May 15, 2015: Submission for Board Approval
• July 2015: Anticipated project start

Communication Plan

An RFP Process can quickly get out of control if it is not clear who should be speaking to whom and when. I would recommend establishing a single-point-of-contact, introduce key stakeholders and point vendors back to the RFP calendar to ensure communication is organized and direction is clear.

Below is an example of this section similar to what I have used in the past:

The following contacts have been established by [Organization Name] to help ensure clear expectations around communication and responsibilities throughout this process. [Organization Name] expects all participating vendors to adhere closely to the communication plan outlined below.

Name, Title	Phone, Email	Expectation
[Name], [Title], RFP Manager	(###) ###-#### email@email.com	Single-point-of-contact for all communication. Please direct all communications through the RFP Manager unless directed otherwise. If responding directly to a team member’s question, please be certain the RFP Manager is CC’d at all times.
[Name], [Title], RFP Sponsor	Not available	Please organize all scheduling of time with RFP Sponsor through the RFP Manager.   RFP Sponsor will serve as primary point-of-negotiations should your product or services be selected.
[Name], [Title], [Name], [Title], [Name], [Title], [Name], [Title], [Name], [Title],   RFP Core Team	email@email.com email@email.com email@email.com email@email.com email@email.com	RFP Team will review vendor submissions, participate in demonstrations and otherwise participate in the selection process.   Other participants will review materials and participate in demos as needed.

 

Business or Technical Requirements

Certain requirements are best answered in narrative form. These may be business requirements – or overarching considerations important to your organization. Others are technical requirements not specific to features or functionality. I recommend asking for these early in the process as they are likely to uncover qualifying criteria that will narrow your respondents.

For example, most organizations would consider it a business requirement that a vendor have experience in the nonprofit sector and would therefore ask in the written response for vendors to describe their experience in the sector. Others might consider it important to demonstrate experience with organizations of comparable size and sophistication and would therefore request case studies and references up front.

Technical requirements might include support options, programming language or whether the application is offered in a SaaS model. Responses provided to each of these questions may be critical to the decision you are making.

Demonstration Scenarios

Functional requirements are best understood with context. Rather than provide a vendor with a spreadsheet of hundreds of requirements, I would recommend assembling these requirements into end-to-end scenarios.

If you are seeking a system that will enable gift processing, provide a set of simple data, describe common gift types and ask the responding vendor to step through the process from entry to posting with your general ledger.

Well-designed scenarios should –

• Provide your vendor with understanding of your business needs
• Be possible to demonstrate in the time allotted
• Assist your team in seeing how requirements will be met
• Enable accurate scoring of requirements

Conclusion

Your RFP document – or Written Response – pulls all of the other building blocks together. You have taken your requirements and separated them into those that can be responded to in writing and those that are better demonstrated as scenarios. You have neatly defined the RFP process through a calendar and communication plan. And, most importantly, you introduced this whole puzzle with sufficient background on your organization and the project for your vendors to have a sense of who you are and what you are trying to do.