What your ideal software partner wishes you knew about writing an RFP

Every software company knows the feeling. It is investigating a possible sale—and then it gets an email with a lengthy RFP attached.

And many companies and organizations know the feeling too—an executive sends word that it’s time to create a lengthy RFP for a project that’s coming down the pike.

The RFP process is common, but it is fraught with problems. So in this post, let us tell you what your software company wishes you knew about RFPs.

First, let’s cover some basics.

BASICS OF THE RFP PROCESS

At Worthwhile, we tell clients about how we can help them move from concept to clarity in six weeks or less using the Examine and Envision steps of our standard process.

But some companies and organizations prefer a more structured approach toward fleshing out a software idea. Many—from governmental orgs to large companies with procurement departments—use the RFP process.

There are variations of these types of requests, notably:
* RFI (Request for Information)
* RFQ (Request for Quote)
* RFP (Request for Proposal)

Often, an organization will publish an RFI and use the responses to finalize an RFQ or RFP. An official RFQ or RFP usually includes a thorough requirements analysis, so that respondents can understand the needed scope and respond with a price.

The RFP process is one of the primary ways companies and especially government organizations and non-profits pick a software partner to build a web application, mobile app, or data solution. As with any process, there are positives and negatives. Let’s break those down:

Good Things about an RFP Process

1. It forces a company to think through what it wants early. This requirements gathering often includes interviews across the organization, which is a vital step of a successful software build.

2. It separates serious bidders from companies that aren’t serious or that don’t have the manpower to fulfill a build. A solid RFP will weed out a lot of smaller software developers, which is helpful when the scope of a project is large. You don’t want a one-man band building a fully functioning procurement management system, given the amount of work required.

3. It provides apples-to-apples comparisons. The company issuing the RFP will have concrete details about price and timeline in writing, which can be helpful in making a decision and forecasting its impact.

4. It collects information in one central place. Whether you’re spelling out API integrations, hosting environment, or compliance needs, it’s handy to have all requirements listed in one place. This can help to save time later in the process.

Bad Things about an RFP Process

1. It’s too much work for a small company to create a thorough RFP. Spending hundreds of man-hours creating a document will stymie more business-critical steps while delaying the actual start of any project.

2. It provides granular detail in the wrong places. An RFP may enumerate in detail pieces of the project management process or hosting setup while leaving huge gaps in actual features and functionality. This can lead to selecting a vendor with the wrong strengths, which leads to a worse solution in the end.

3. It can be easy to game the system. Some software developers may be really good at writing RFP responses, but not as good at actual software development. Is that the kind of company you want to actually hire? 

4. It creates red tape. The RFP process is often arcane, creating more hoops to jump through than are necessary for a successful software build.

5. It creates a list of features without analyzing the real needs of the organization, its users, and its customers. This can lead to scope misalignment, especially if the customer isn’t willing to consider changes to features after selecting a vendor.

6. The RFP leads your organization to create preconceived notions, limiting your ultimate success.

Let’s break down that last point in detail. Here’s an example that we’ve seen more than once: RFPs that state that one requirement is to rank on the first page of Google search results. This statement tells us that a stakeholder has a fundamental misunderstanding of how SEO works.No software developer controls Google. This is obvious, if you think about it—Google sets the rules on how search rankings work, and can change them at any time. Many of them are not public and take observation and inference to find. So while a website developer can build a website in a way that should lead to good Google rankings, it cannot guarantee it. Anyone asking for this in an RFP (or even worse, in a contract) reveals a lack of understanding of SEO and SEM. It’s a preconceived notion that does not actually connect to the reality of how software and the digital world works.

Experienced software developers will notice this, and it will influence what price they quote, or if they even respond at all. And that’s not even the worst-case scenario. If a company promises a No. 1 Google ranking, then it is either a) just as clueless or b) telling you what you want to hear in order to win the deal. Neither of these situations is a recipe for ultimate project success.

Now that we have an overview, let’s break down how to write a successful RFP.

HOW TO WRITE A SUCCESSFUL SOFTWARE RFP

1. Talk about what is more than what could be. This may seem counterintuitive, but it’s vital to success. That’s because you want to leave room for responding software companies to craft a solution based on what you actually need, not what certain people want or what your competitors have. You are hiring a software partner in order to leverage its expertise, and creating too many requirements about the solution will hamstring your partner in the long run. Instead of spelling out every last detail of the potential solution, focus your RFP on your current tech stack, integrations, hosting environment, and hardware, so that respondents know the landscape and can provide a full response.

2. Cover the key areas. Make sure that software companies who respond to your RFP provide key information about key areas:
* Feedback and revision timetables and policies
* Testing protocols
* Hosting and its associated costs
* Ongoing support and its associated costs
* Future upgrades and its associated costs

These help you know what to expect during the software project and after, so you can plan accordingly.

3. Open the door to different processes. The most successful software companies have established processes that help them deliver projects successfully. Forcing a company to alter its process to adhere to what’s in your ERP actually creates risk, instead of limiting it. So while your RFP may suggest a process, it’s more important to call out what you need—regular updates, time to review work, ability to make revisions, etc.—and not how your chosen partner will make sure you get these things. Tip: It’s better to ask questions about process in an RFI than to demand a certain process in an RFP.

4. Describe constraints in detail. Constraint is not a dirty word. Every business faces them, and it’s important to know and understand them from the start. These constraints are external, based on regulatory requirements or legal reasons. They may be internal, based on company policies and IT standards. No matter the form, you need to tell partners what their constraints to ensure that responses will actually work for your business.

5. Require only what is actually required. One of the things that tends to bloat RFPs and slow the process happens when someone on the periphery of creating the RFP throws in a requirement to be included. If this happens a few times (or a few dozen times), you end up with an RFP that incites responses with skyrocketing budgets. We saw this in one 100-plus page RFP document from a professional services firm. It was full of a variety of feature requirements that had the fingerprints of certain executives and stakeholders putting their pet ideas into the document. The result was a website scope that would cost hundreds of thousands of dollars—when a smaller scope would have worked effectively. Be relentless about only including features and functionally that are essential, and then let respondents recommend additional features that can be added in a budget-friendly way.

In Conclusion

The RFP process is not for everyone. There are other ways to vet potential software vendors such as seeking out references, interviewing firms, and online research. If you believe a smaller company can deliver what you want, or if you have an existing relationship with one or more solid software companies, you might be better off saving the time and effort of drafting and administering an RFP process.

But for many larger companies, or for governmental organizations and other NGOs, an RFP process is mandated. Those organizations can take the tips in this post to make the RFP process most effective so they end up with the right partner in the end.

About Worthwhile Storyteller

We'll never tell you a lie, but we might tell you a success story that protects the intellectual property of our clients and partners. Our Worthwhile Storyteller is an amalgamation of all of our thoughts, experience, and expertise brought together to give you the facts about our relentless improvement in the software development space.