Our firm found inspiration in the American Craftsman Movement of the late 1800’s and early 1900’s. It influenced everything from architecture to economics. The concept we found most appealing was how, especially in architecture and design, the Craftsman Movement represented an effort to emphasize form and function (over excessive decoration or ornamentation). Build something sturdy and it will have a beauty of its own. It will endure.

It is our goal to apply this same lens to technology – to find a way to build systems or make decisions that will last.

In this post we will look at the Request for Proposal (or RFP) process. The RFP is important as, for many of us, it is the primary means for making large, complex decisions. If your RFP process is not built on a sturdy foundation it is unlikely that the outcomes of that process will be any more sturdy.

Building Blocks of an RFP

There are four basic building blocks of a well-built RFP. They are:

• Requirements
• Requirements Workbook & Scoring Matrix
• Demonstration Scenarios
• Written Response

Each of these building blocks will be defined in greater detail below.

1.      Requirements

A requirement is a brief, declarative statement that describes a specific need for the future application. Generally, there are three types of requirements: business, technical and functional. Developing a comprehensive list of requirements should help breakdown the evaluation into measurable pieces. In theory, if all requirements are met, then the sum of the requirements would represent a complete solution.

• Business requirements are those requirements that speak to the larger need of your organization. They may include vendor requirements such as their experience in the sector, financial viability or geographic location. These requirements may also speak to support, account management or service delivery models. Your business requirements are effective if they thoroughly describe the behavior you are expecting from your vendors.
• Technical requirements are those requirements that speak to the technology itself. Your organization may be looking for a SaaS or cloud-based solution. Your organization may wish to select a solution based on a specific technology platform or programming language. Or, you may wish to include requirements that speak to integration potential with related systems that form the larger technical architecture.
• Functional requirements describe the specific needs or features of the organization at a fairly granular level. Typically broken down by business unit or functional area, they will represent the large majority of your requirements. Functional requirements may include needs around gift processing, acknowledgement, moves management or a wide array of other functional areas.

2.      Requirements Workbook & Scoring Mechanism

A requirements workbook is typically exactly what it sounds like – an Excel Workbook. Its primary use is to keep hundreds or even thousands of requirements organized and categorized. The scoring mechanism can be as simple as assigning a point to each requirement and tallying the total points.

We would recommend sharing the requirements workbook with vendors. Vendors should prepare based on the demonstration scenarios and respond to the written response. That being said, the requirements workbook can provide a vendor with the source material that lead to the scenarios and written response. Exposing the scoring mechanism can further emphasis what is most important to your organization.

3.      Demonstration Scenarios

Presenting a vendor with a workbook full of requirements is unlikely to generate the response you are looking for. Rather, we would suggest creating a series of scenarios based on the core requirements. Scenarios can provide the context and meaning behind the scenarios that will allow the vendor to demonstrate how the new solution can achieve the overarching need represented by the scenario.

Some scenarios will require significant depth around a discrete, cross-functional area such as financial reconciliation or membership management. However, it is a great idea to also present cross-functional scenarios that will describe how the organization can best work across business units or even execute strategies that require collaboration across teams that might otherwise exist in silos.

4.      Written Response

The written response should include the goal or anticipated outcome of the project, RFP calendar, contact information and any requirements that can be answered in advance of the demonstrations. You might include the vision of the project, how the project fits into strategic objectives, notes on the operational model of the organization (ex. membership-driven) or otherwise provide high-level context for the RFP. The RFP calendar should describe all critical due dates. Contact information typically establishes the point-of-contact for inquiries and any rules of engagement (ex. all communication flows through one person). Business and technical requirements are often best answered in advance via the written response as they are not easily demonstrated.

See: RFP Building Block: Written Response for more information.

Summary

A well-built RFP can be distilled into four essential pieces. Well-formed requirements will comprehensively describe business, technical and functional requirements of the new system. A requirements workbook and scoring matrix will ensure those requirements are assembled and evaluated in a meaningful way. Demonstration scenarios will help vendors represent requirements in a way that is meaningful to your organization and provide the necessary context for evaluation. And a written response can effectively represent the RFP process and capture the responses to those requirements not easily demonstrated.