Skip to Main Content

7 reasons you should never write an RFP

Man scattering sheets of paper|Evaluating risk with RFPs|Avoiding the RFP|RFP Waste|

The RFP process — three little letters that can equal a world of hurt. Unless you’re required to do so by law, we beg you not to write a request for proposal for your next development project. You'll end up wasting your own time, and worse, you'll likely end up hurting your final product.

By focusing on the timeline instead of the outcome, the RFP process creates misaligned incentives at the outset. That’s why so many projects that start out with a typical RFP process either suffer or fail outright. We’ve picked up a number of clients over the years who came to us to clean up the messes created by other firms that were “rigorously vetted” through a standard RFP process. After years of winning RFPs at Table XI, we’ve decided to never respond to one again. Here are seven reasons why you should skip the step of writing an RFP:

1. The RFP process helps you find a commodity fulfillment engine — not a strategic partner

When you're creating an RFP, you're looking for vendor who can help you think through the big picture business issues as well as the nitty-gritty technical details. Advising on strategy is the greatest value a a good consultant can bring to the table. One of the biggest disadvantages of the RFP process is that it skips this step altogether. The RFP requirements lay out the what and how, skipping the why. When you follow a request for proposal process instead of starting with a project kickoff meeting to help your vendor understand your business, you’re missing out on half the value of a good service provider.

2. Your RFP template won’t have enough detail

Despite your best efforts, you will never be able to create a detailed enough RFP to provide actionable information to a potential vendor. A single document can’t effectively communicate organizational context and business rationale, requirements and priorities, integration points, and all the other particulars necessary to successfully scope and build software. Unexpected events are always going to creep in. We've seen countless RFP examples, and we haven't seen one successfully account for every need and function. That's where you need a vendor's expertise. We've done these projects dozens of times, so know where the potential pitfalls are. An open RFP process cuts our knowledge out of the process, making it harder on both of us to build great products.

3. Evaluating proposals will be like comparing apples to rutabagas

When you can’t convey sufficient details in your RFP, you’ll get proposals that are all over the map. At best, you’ll see price tags ranging from $X to $5X, but we’ve participated in RFP processes that yielded project estimates ranging from $X to $20X. These budgets are neither useful nor actionable, and you shouldn’t be evaluating vendors solely on budget in the first place. You want to know who’s going to solve your problems with the least risk, not whose imaginary number looks the most reasonable.

Nothing we can do to talk you out of writing an RFP? Learn how to write an RFP that will get you better results.

4. The RFP format wastes a ton of time while adding limited value to the process

Responding to RFPs takes time and money from the vendor, and you can guess who ends up paying for it. Since the RFP process yields stacks of mostly useless proposals, a good vendor often won’t bother to participate. The purpose of an RFP is to find you the best vendor. But if a service provider is already in-demand, why battle it out with the hordes? As a result, you often end up with a lot of proposals from shops who need the work — not the best teams.

Want to start visualizing your project risks? Download our free Software Risk Management template.

Download PDF

Furthermore, every RFP sample we’ve ever seen sets out unrealistic timelines that aren’t met. Two weeks simply isn’t enough time for your prospective vendors to turn around detailed responses to an RFP, because too many specifics are left vague or uncertain. Here are the more likely RFP process steps from beginning to end: two weeks to write the RFP + two weeks to get internal review and approval + four weeks to get responses + two weeks to realize that you didn’t receive a single useful proposal = 10 weeks of wasted time

5. The RFP process will never be transparent

Proponents claim that by definition the RFP process is more fair and transparent. This honesty is supposed to be one of the greatest benefits of an RFP process. The truth, however, is that incumbent vendors often help write RFPs and tailor them so they'll win the business. Proposal scoring is rarely, if ever, made public. Nope, the RFP process is just as hidden from scrutiny as the alternative approaches, save for the one initial document — the RFP itself.

6. An RFP can’t yield an agile process

RFPs lay out the entire scope of the project — including timetables and budgets — before anybody ever has a chance to start analyzing the work. The result is a waterfall process, where everything is determined at the top, then dumped into action as quickly as possible. That’s great, if you want exactly what you asked for a year ago. But if you want a product that reflects the current industry best practices and your current business goals, you need an agile process. By working in agile, your vendor can constantly assess the landscape and respond to changes, reducing risk. The RFP structure, with all its predetermined ideas, can’t give you that.

7. Pointing to your RFP preparation won’t save you after a failed project

If a project goes south, an RFP can't shield you. The executive team will look for someone to blame, and it won’t matter if you were just following the RFP process. If you picked the cheapest vendor but they failed to deliver the project, you’ll still get hit with the consequences. In fact, following the steps in an RFP process can add to the harm, since you’ll have a document saying how much it was supposed to cost and how much time it was supposed to take — even though those numbers weren’t based on a full understanding of the project.

So what should you do instead? We have a whole list of RFP alternatives that are actually designed to help you find the right dev shop, including RFIs, RFQs and risk-based models. And because we know sometimes it’s inevitable, we included a few tips in there to make the RFP process less painful. Even though we still don’t think you should write one in the first place.

Want to learn more about how Table XI gets started with new partners? Check out our services.

Published by TXI in Culture

Let’s start a conversation

Let's shape your insights into experience-led data products together.