Successful Projects Start with Great RFPs

December 10, 2019

Your organization is undertaking an important new digital project and you’ve been tasked with finding a vendor to help make it happen. It’s time to write a Request for Proposal, or RFP.

Those three letters – R, F, P – are daunting. I know first hand. An important part of my job here at Aten is qualifying and responding to RFPs. They’re often huge documents and difficult to get through (let alone create in the first place). RFPs cover everything from the mission and vision of your organization, to contract terms and prerequisite insurance for vendors, to deadlines and formatting for responses, to goals and requirements for the actual project. There is a ton of information to get across, and it can be hard to know where to start and how to organize your RFP to get the best responses.

If you’re tasked with finding a vendor for your next digital project, here are a few tips for organizing an RFP that will help make sure you’re providing the right information, asking the right questions, and offering the necessary background for getting the best responses.

The Purpose of an RFP

Before we get into tips for organizing your RFP, let’s step back and review the reasons that make this document so important in the first place.

Defining Goals and Challenges

While the success rate for digital projects is improving they still remain risky endeavors. One out of five digital projects fail, often due to poorly defined requirements. Writing an RFP provides an opportunity to collaborate with your team and formally define the requirements for a project. It’ll answer important questions like: Who will this project serve? What goals will this project help your organization achieve? What business needs must be met in order to be successful?

Managing Stakeholders

Every project will have stakeholders within your organization with an interest in its outcome. Distributing an RFP for internal review prior to its release is a good way to get all stakeholders on the same page with what you are trying to accomplish.

Selecting the Right Type of Vendor Partner

When you are issuing an RFP, you’re seeking outside perspective and expertise to see a project through to a successful outcome. But, what kind of resources do you need? Do you need subject matter experts? Do you need team augmentation? Do you need a digital strategist to help you codify your goals? Or, do you already have your goals mapped out and you just need developers to implement the vision? The RFP will help you define the type of help you need to bring on, which in turn will help you find the ideal partner.

With these goals in mind, how can you convey the details of your project to your potential partners? And how do you identify the best partner for your project?

Before You Issue an RFP

Define Stakeholder Satisfaction Ahead of Time

A few years ago we worked with a large organization – with dozens of stakeholders – to completely redesign their website. It was a big project for us and a huge undertaking for the client, with impact on virtually every department within the organization. The website launched on time and was a massive improvement. It looked great, communicated effectively, was easy to use, made it simple to publish content, loaded fast; it checked all the boxes for the key performance indicators (KPIs) we had agreed to.

Just a few days after launch, we joined the client for a round-table discussion with various stakeholders from across the organization. We were expecting a celebration and perhaps some blue-sky planning for what might come next. What we got was very different. Several stakeholders were disappointed. They felt the new work didn’t clearly reflect their own departments within the organization. We listened, discussed their needs, and ultimately addressed their concerns. The situation could have been avoided altogether if stakeholder satisfaction had been clearly defined from the very beginning of the process.

There are a number of ways to help make sure stakeholders are properly engaged throughout the process, and it starts with the RFP. Getting input from key stakeholders by sharing your RFP with them before it’s issued will help get their buy-in and give them an opportunity to help define the project. Most importantly, it will give your stakeholders a chance to weigh in on exactly what success looks like to each of them.

Consider a Phased Approach

For larger projects, you might consider breaking the work into smaller, distinct phases. Here are a few questions you may want to ask to understand if a phased approach is right for your project:

Are your functional requirements hard to define or unclear?
Do your stakeholders have very different perspectives about what the final product should be?
Are there key questions that still need to be answered in order to more clearly define the project’s parameters?
Are you open to a range of specific technologies, and interested in choosing the best solution only after thoroughly exploring the options?
Is your timeline vague or complex? Closely related: are there other dependencies on this project that make timing difficult?

Breaking your project into smaller phases (for example, a Strategy Phase, Design Phase, and Implementation Phase) can be extremely effective for addressing issues like those raised above.

Research Potential Vendors

If possible, you should also pre-qualify vendors that you want to work with. Pre-qualifying vendors can be as simple as:

speaking with other organizations that have tackled similar projects
searching sites like Clutch.co that rank agencies
attending related conferences where potential partners might speak or sponsor

Before issuing the RFP, meet with select vendors to gather their input, get a sense of their expertise, and if you think they might be a good fit, invite them to respond to your RFP when it’s issued.

Releasing an RFP into the wild without pre-qualifying potential partners will garner a ton of responses, but there’s no guarantee any of those responses will be from a good partner. The most qualified vendors often do not respond to blind RFPs. An added benefit: you can reduce your workload by only receiving proposals from the best partners that you already know can do the work.

Organizing Your RFP

Formatting Your RFP

Before we dive in on structure, let’s cover document format. RFPs should be issued in a commonly used format: searchable PDFs or Word documents are appropriate.

RFPs should not be issued an unsearchable format like an image-based PDF (a scanned document), or uncommon formats like Powerpoint presentations or Excel spreadsheets. PDFs and Word documents are easy for your ideal partners to scan and search. It’s okay for supporting documentation — like analytics data or screenshots — to be included as spreadsheet or image documents, but the main body of the RFP should be a PDF or Word.

RFP Sections

With respect to structure, I'm a huge fan of the RFP structure recommended by Stanford Web Services. During a 2019 Stanford Web Camp session on RFP writing, SWS outlined a structure that clearly addresses the key objective for effective RFPs.

Project Background
Audiences
Project Team
Scope / Requirements
Timeline
Budget

Project Background

In order for your potential partners to understand the value of this project in your organization, it’s important to put this project in context by sharing your organization’s mission and the project history.

Questions to Address Under Project Background

What is your organization’s mission?
What is the history of this project?
Why is this project important to your organization?

Audiences

Websites and most other software applications are built to serve and connect people, so it’s critical to understand your audiences. What do they want from your organization? What does your organization need from them? How do your user’s needs relate to the needs of your organization?

Since it’s likely that you need to think about more than a single audience group, you should define and prioritize your various audiences. For example, if you are an academic unit at a university, your audiences might be listed in the following priority order: prospective students, current students, faculty, alumni, staff, and relevant researchers.

Questions to Address Under Audiences

Who are your users and why will they care about this project?
What do you need from each of your audience groups?
How does your organization prioritize the importance of these audience groups?

Project Team

Your chosen partner will work with certain people on your team. Sharing details about your team’s strengths and the amount of time they have scheduled to the project will help your potential partners better understand the risks and opportunities in this engagement and plan accordingly (e.g. “We have a developer on staff and available to sprint alongside your team 20 hours a week” or “We have a copywriter who has 80% of their time scheduled to work on this project.”).

Questions to Address Under Project Team

Who are the people that comprise the core project team?
What are your team’s superpowers?
How much of your core team’s time will be dedicated to the project?
Outside of your core team, how large is the stakeholder group?

Scope / Requirements

When it comes to digital projects, your partner is typically a subject matter expert on user engagement strategy, design, development, or a combination of all three. You are hiring them for their knowledge and expertise. With that in mind, you have to find a balance when creating your requirements. If your requirements are too vague, your partner might not understand how they can help you make an impact. If your requirements are too prescriptive, you might be limiting their ability to do their best work.

Questions to Address Under Scope/Requirements

What does success look like to your organization?
What do you envision will be the project outcomes?
If you are sharing specific features that need to be implemented, then also share:
Why is this feature important?
Which of these features are among your highest priorities and which are nice-to-haves?
Outside of the scope of the project, but relevant to the RFP selection process: with respect to selecting a qualified partner, what are your scoring metrics? (e.g. “Budget is 20% of the overall score” or “Experience represents 35% of the overall score.”)

Budget

If possible, I absolutely recommend including your budget range in your RFP. Understanding your budget parameters is necessary for qualified vendors to know (a) what to recommend, and (b) if they are even a good fit for the project.

If your budget is 25K and a potential vendor has a 50K minimum, there is no reason to waste time writing or reading a proposal.

If your budget is 250K – let’s say, to build a publishing system that matches the workflow of your editorial team – that’s important information for a potential vendor. The vendor knows not to recommend a custom 7-figure enterprise solution with on-site 24 hour support and dedicated development teams, but also not to recommend a WordPress install with default publish states just “turned on.” It’s going to be something between those options, and it’s going to be tailored to your budget.

Some organizations do not allow teams to share budget details due to a common misconception that withholding budget information will lead to more competitive proposals. In reality, there’s little research to support this point of view. In fact, the research actually suggests that not sharing your budget might be limiting the quality of your responses.

Arizona State University released a whitepaper on why they recommend sharing budgets in RFPs. In the whitepaper, they weigh the pros and cons and summarize the cost/benefit succinctly, “the fear that vendors will raise their prices if you give them your budget just isn’t a real possibility.” They also note that teams at Arizona State that fail to share project budgets risk “scaring away the best vendors.“

Sharing your budget helps your potential partners create project plans in line with available resources. It also gives your selection team an apples-to-apples comparison of the proposals you receive since every respondent has the top-line budget number in mind when drawing up their proposal.

Questions to Address Under Budget

What is your project budget?
Is your budget a fixed number, or a range?
If you’re building software, you will need to support this project after delivery. What is your post-launch budget?

Timeline

RFPs often share the timeline for submitting proposals, but don’t always share details about when a project needs to launch or why it needs to launch before a specific date. Sharing these details will provide your potential partners with critical context for helping make sure the project is successful.

Questions to Address Under Timeline

Why is this project a priority for your organization today? (e.g.: Why not take this on a year ago? Or, a year from now?)
When do you need this project delivered?
What’s driving the project’s timeline? For example, is your timeline driven by an upcoming campaign? Fiscal year end? Was the delivery deadline set by a person in the organization’s leadership? Is your timeline informed by the anticipated level of effort?
What are the RFP submission deadlines? (e.g.: When are questions due? When is the proposal due?)

Why is it important to share all of this information? Ultimately, the purpose of an RFP is to set projects up for success. A well-written RFP creates a shared vision for the project and will attract the best partners.

Need help with your RFP? I’d be delighted to discuss it with you.

Authors