9 Essentials for a Good RFP: Key Elements to Include
About to launch a new technology project? Ready to engage outside vendors? Before you send any emails, ask for recommendations or make any phone calls, your team needs to sit down and write a request for proposals (RFP).
Whether this is your first RFP or your hundredth, making sure the RFP you put out there is just right is a critical task. It’s like your dating profile when you’re ready to find that perfect partner for your project – no matter what your project is (from construction to custom software application development). If you’re going to find the right match, you really have to put out the right details and the right expectations.
What makes a good RFP?
A strong RFP should be a way to clearly communicate to potential vendors what you need for your next tech project. What are your project specifications? What do you have to have and what are nice-to-haves? What are your expectations overall?
But sitting down to write an RFP for a mobile app, a custom software build, or even a website redesign can be overwhelming. How do you convey what you need without writing a novel? How do you communicate what you need so potential vendors will understand, especially if you’re not a technical person?
A good way to start is to break your RFP down into these nine essential pieces. These essential pieces lay out the characteristics of an effective RFP.
Ready to get started? Here’s a step-by-step walkthrough of what your RFP should include to ensure it’s a clear, well planned and well written document.
1. Intro or executive summary
This section should be pretty straightforward. It’s an introduction to your company, your values, and also an overview of the project you’re seeking bids on. A good intro eases the vendor into what they are about to read and provides a brief overview of the project and requirements for your product or service.
In other words, you’re stating the goals and intent behind your project. This task should be one of the easier characteristics of an effective RFP.
2. Business overview and background
It’s important for your vendors to know about your company. Don’t just give a boring company history. An effective RFP is descriptive. It gives vendors some insight into what drives you.
What services do you provide? What are your values? What makes you unique? Why does what you do matter?
It’s important that you select a company that works the same way you do or whose values are a good fit with yours. Yes, each vendor wants your business, but a vendor who really “gets” where you’re coming from is more likely to work with you on budget and timeline. It will make the process more enjoyable overall, too, if you really click with your vendor. It will make your time and work together feel more like a partnership.
3. Project goals and target audience
These two pieces of information are probably the most important pieces you can provide. This section tells your potential vendors whom they will be designing for and what the goals and objectives are for the project. It’s important to include the specific pain points you are trying to solve and why your current solution isn’t working.
Something you should also focus on is articulating the problem rather than describing a specific solution. You may not have the right solution to the problem (which is why you’re tapping an expert). So describing the problem you hope to solve with as much accuracy as you can muster will allow the experts to come up with more creative or appropriate solutions.
You should also outline specific outcomes you have in mind or goals you wish to accomplish. If there are quantitative metrics (better leads, high productivity rate, etc), describe those indicators in this section.
4. Scope of work and deliverables
It’s important that you are as clear as possible about what you want your project to include and the expectations you have for the work. This section of your RFP should be the most thorough (which also means it’s going to be the longest).
A lot of variables can impact the scope of your project. The more detail you put into this section, the less back and forth you’ll have to do once you choose a vendor. Hopefully the cost estimates you get back will be more accurate, too.
It’s OK to not know exactly what’s involved in development. What matters most is that you lay out in detail what you’re expecting to be delivered. Some elements you may need that you may want to include upfront are:
- Project management (do you plan to manage this project or do you expect the agency to handle it?)
- Content strategy
- Copywriting
- Front end design
- Front end coding
- Back end coding
- Testing and quality assurance
- Training your team to use the new app, software or website
- Support after launch
- Ongoing support
- Specific features (ecommerce, mobile responsiveness, etc.)
- Specific back end systems, data sources, APIs and/or feeds your mobile app, website or software will be interfacing with
- Technical requirements or industry restraints (financial industry regulations, HIPPA compliance, etc.)
- Specific language you expect the coding to be in
- Membership management or password protection needs
- Accessibility needs (users with disabilities, larger font needs for elderly users, etc.)
- The devices and operating systems you are selecting and why
5. Project timeline
It’s important to convey the timeline you are hoping for and expecting the project to be completed in. Are there specific deadlines that need to be met? Is the launch of this project being timed with the launch of another product? Give timeline details now, so potential vendors know what kind of timeline you expect.
6. Structure of the vendor proposals
This part of your RFP tells vendors how you would like their proposals to be structured and what you expect them to include. Is there a specific format you’d like them to follow? Do you want the final proposal as a Word document, a PDF, a printed document, or some other format?
Adding thought and detail to this section will make it easier to compare the proposals you receive. When all the proposals follow the same format, you’ll be able to compare vendors side by side more easily. (You’ll also be able to see who follows directions, much like contract riders for musicians. Riders are included not only for diva-esque reasons but to see who is paying attention. After all, if you can’t the details of the dressing room right, did you also get the sound system details, the pyrotechnics details, etc.?)
Typically, a response format should include:
- Executive summary
- Background information
- Proposed services or deliverables
- Timeline and budget
- Portfolio of other work
In other words, the format should follow the outline or format of your own RFP, since the vendor should be answering each section.
When you get the RFP back, a good RFP typically includes this kind of information. These are the kinds of details and answers that will help ensure you are selecting the right agency:
- References from previous customers
- Beyond the portfolio, 1-2 examples of similar projects they have worked on and what the outcomes were
- Explanation of their process (so you can see exactly how they work and what to expect, so you can determine if that works with how you work)
- List of the current systems they work with, so you can compare them to the systems you work with (Follow-up: Ask if they can work with your systems, such as legacy systems, data sources, back-end systems, APIs, feeds, etc.; if they cannot, ask them to elaborate on what changes they suggest and why)
- Rundown of the team that will be working on the project (are they freelancers, full-time employees, remote workers, overseas developers, etc.), because you don’t want a development team that’s pieced together
- Breakdown of who will be completing the work, whom you’ll be interfacing with, etc.
- Resumes of their lead designers (to give you an idea of the caliber of team you will be working with)
- Their measurements of success, analytics, and plan for ongoing improvement
- How the company differentiates itself over its competitors
7. Budget
It’s important to set upfront expectations for budget. Even if you are guessing how much the project will cost, provide a budget or price range. You’d like to spend X but you definitely can’t spend more than Y. Having these numbers as targets is much more helpful than an open budget.
For every project, there are needs, wants and a range of functions and features that could be left out or included. It all depends on budget and scope. Having features and functions broken out this way means the vendors submitting proposals can help identify top priorities over non-essential elements.
8. Selection criteria
This section gives you a chance to lay out clearly how you will be selecting the vendor for your project. Give this section some serious thought. Here’s where you will highlight your priorities, must-haves, nice-to-haves, and the qualities that you value the most.
Laying out your selection criteria will give the vendor good guidelines for what to showcase. It will also save you from reading about things that won’t affect your decision.
9. Proposal timeline
Finally, give a timeline for when you would like the proposals to be submitted and when you will be making your final decision. Timelines will help set proper expectations, plus help the teams and agencies answering your RFP to know if they can realistically balance your project with any others they have at the same time.
Remember: What you put into your RFP is what you’ll get out of it. All this writing and detail will yield better proposals in the end – and better vendors for you to choose from.
If you follow these steps, you’ll have created a good RFP that will allow you to get through more proposals, to weed out the bad apples more easily, and to find an agency that will deliver what you need, on time and within budget. In the end, you should find a better match.
Already have a great idea in mind? If you’re ready to hire an agency and get your project rolling, here’s a word of warning. There’s a lot that can happen during the five different stages of software development – a lot that can go wrong.
But there’s one thing in particular that is guaranteed to make your tech project fail. Want to know what it is? Download this free whitepaper to find out.
