For the purposes of this chapter, we use the term RFP to refer to both RFPs and RFQs unless otherwise noted. While there are differences, namely that an RFP focuses on the capability to provide a service or product and an RFQ concerns the price of that service or product, they are combined here because the process of writing one so closely mirrors the process of writing the other.
The request for proposals / request for quote (RFP/RFQ) is one of the most important documents you’ll generate during a new technology procurement project. Not only is it critical in evaluating your vendors, it’s often the last stage of the process in which stakeholders can participate.
The process of writing an RFP should be considered as building a bridge between internal discussions and external vendors. It should be a collaborative process that reflects business objectives, business requirements, technical/project specifications and, when necessary, budget restrictions.
The RFP should have the approval of internal stakeholders and present a unified view of the scope of your procurement project. The RFP should also be clear: vendors should not need an intimate knowledge of your internal processes or organizational culture in order to understand it.
That’s a tall order.
But fortunately, there are many best practices you can follow so that your RFP will generate the vendor responses you’re looking for.
In this chapter, we cover:
- How to structure an RFP and what to include in it
- A case study in which a consultant helps create an RFP
- Common pitfalls you’re likely to encounter.
How to structure an RFP
At this point in the process, most project managers or champions are up to their eyeballs in technical requirements, stakeholder needs, and budget constraints. It can be a challenge to capture all of those in a document that vendors will actually be able to understand.
As New Media Campaigns puts it:
“An RFP is the face of your company to potential collaborators, so it’s important to compose them well.”
With that in mind, here’s a format for your RFP that lets you present all of the pertinent information you’ve compiled, in a document that will still be clear and easy to read:
- Brief project overview
- A bit about your organization
- Goal and objectives of the project
- Scope and deliverables
- Technical requirements/existing infrastructure
Let’s explore each of these in a little more detail.
1. Brief project overview
The purpose
The main purpose of the project overview is to introduce your technology procurement project to an unfamiliar audience.
The audience you’re addressing isn’t familiar with all that you’ve learned while working with stakeholders and getting approvals over the past few months. In the overview, they’re reading about all of this for the first time, so you need to write clearly about the technology solution you’re looking to purchase.
Here’s a good way to think about it: if someone only reads this section, will they be able to understand the project?
A concise and detailed overview will also help you exclude vendors who are not a good fit for the project early on in the procurement process.
Many vendors evaluate dozens of RFPs every week, but only respond to one or two. Your overview should give them an idea of what’s involved, so that they’re able to decide quickly whether or not they’re a good fit.
What to include
- The technical environment (at a high level)
- The problem you’re trying to solve and/or the major pain points you’re facing
- The type of software you’re looking to adopt (e.g. CRM, CMS, ERP, SCM)
- Budget (optional, but recommended). Many organizations specify a range to ensure the proposals they receive are in line with what they plan to spend.
2. A bit about your organization
The purpose
You want to work with a vendor that shares your organization’s values, has some experience with your industry or sector, and (ideally) has worked on projects with the same scale as yours. There can be exceptions, of course – for instance, working with a startup – but those are far from the norm.
A brief explanation of who you are and what your organization does will help ensure you receive proposals that are tailored and relevant, so you can sweep aside the generic ones.
What to include
- Your organization’s profile: sector, industry, size, products, services, and more – whatever a vendor might try to find on LinkedIn.
- Your organization’s core values. What does your organization stand for? What products or services do you provide, and how do you help your customers or clients?
- A bit about your organization’s culture. This is where you can set the tone for a relationship. If you’re a suit-and-tie organization, you may want to keep it formal. If sneakers are okay, you can take a more relaxed tone here. Anyone reading this should get a good sense of your corporate personality.
3. Goal and objectives of the project
The purpose
State the goal you expect this project to achieve – right away.
Some consultants believe that any problems or pain points you’re looking to overcome should be masked, so that the competition doesn’t find out what your organization is struggling with. At Enginess, we think this is nonsense.
First, other organizations don’t care. They’re too busy putting out their own fires. And second, an awareness of your organization’s internal problems is unlikely to be leveraged by a competitor in order to make an effective move in the marketplace.
Unless your organization’s particular pain point can be summarized as something like “our product catches fire, please help us fix that,” you’re probably okay.
By outlining exactly what your goal and objectives are, you level the playing field. So you’ll be able to evaluate vendors on the merits of the solutions they offer, not on their ability to decipher your problems.
What to include:
- Your business objectives (at a high level)
- A short description of the problem your organization is facing (e.g. “how can we book more demos for our products?”)
- Your expectations about what a new technology solution will deliver or how it can relieve your organization’s specific pain points.
4. Scope and deliverables
The purpose
This is all about explaining the scope of your project and the type of deliverable you want to end up with.
This is your chance to outline your expectations for this procurement project and offer a rough idea of the shape of the new technology solution you have in mind.
At this point in the RFP, you should pivot from “here is our problem” to “here’s what we think our solution needs to deliver.”
And this is the point where many organizations begin to struggle with an RFP. It’s relatively simple to write about your organization’s particular pain points. It’s more challenging to write about what you think a new technology solution should look like. So an external consultant is often brought in at this stage to help address this challenge.
What to include
- Your business requirements and examples of your technical requirements
- A list of functions you have decided are in-scope and others that are not. Projects can go off the rails when little things like “who owns data migration?” aren’t addressed. Take this opportunity to curb these possibilities before they can materialize.
- A complete, robust list of deliverables. The more detail you provide, the better.
5. Technical requirements/existing infrastructure
The purpose
In this section, you want to outline your technical requirements and your organization’s existing infrastructure in as much detail as possible.
For instance, if you need someone who can work with Amazon Web Services (AWS), or you need a solution that’s going to work with your existing CRM, you should be upfront about those requirements.
There’s no sense rejecting vendors later in the process because they weren’t aware of some of your project’s core requirements.
At this point, you can also include any details you didn’t cover elsewhere or decided earlier weren’t in-scope. For instance, if having a solution that is hosted in Canada – and not in the United States – is important to your organization, you should mention it here.
Most vendors will be able to address any technical requirements you include, but you still need to specify them in order to receive focused and well-informed responses.
What to include
- A complete list of technical requirements
- Any integration/environmental requirements
- Any other specific restrictions that apply for a new technology solution.
An RFP case study: the Canadian Hearing Society
At Enginess, we helped our client, the Canadian Hearing Society (CHS), find their way through the RFP process, and the lessons we learned can be applied to this process at other organizations.
The challenge
CHS was looking to adopt a CRM to better leverage their existing programs. They wanted to replace dozens of manual processes so that they could better meet customers’ needs, enable cross-department engagement, and optimize their service offerings.
CHS was also looking for a solution that would work with their existing technology and be adaptable to any new technology as it was acquired.
However, CHS didn’t have the in-house technical expertise or time to navigate the RFP process. They needed a partner to help guide them through the process, identify a vendor, and manage the deployment and integration of their new system.
The Enginess solution
We worked to understand the business needs of CHS by conducting interviews across six departments and ten programs, mapping critical processes to gain a better understanding of how their workflows functioned.
With those requirements and workflows in mind, we evaluated existing systems and databases to round out our picture of the technical landscape before starting to build a strategic roadmap and budget.
From there, we produced an RFP for CHS that was recognized by Microsoft as one of the most detailed and impressive RFPs they’ve seen for a CRM.
The impact
As a result of our thorough and detailed approach, we were able to secure several high-quality proposals from best-in-class vendors, which in turn saved significant amounts of time and money.
More importantly, we were able to mitigate downstream project risk by front-loading expectations and ensuring that CHS and the vendors were on the same page as to project requirements and expectations.
Chapter summary
- Your RFP should be structured in the following way:
- Brief project overview (an abstract)
- A bit about your organization, covering core values and setting the tone for a relationship
- The goal and objectives of the project
- Scope of the project and a complete list of deliverables
- Technical requirements and existing infrastructure.
- We helped CHS with their RFP for a new CRM by working to understand their business needs, building a roadmap and budget, and then writing and submitting the RFP. That RFP was later recognized by Microsoft as one of the most detailed and impressive RFPs they’ve seen for a CRM.
- Common RFP pitfalls include failing to be detailed enough (more granularity is better), not securing stakeholder buy-in, forgetting to include concerns like shared values and organizational culture, and losing sight of the bigger picture of the RFP’s purpose.