RFP DOAR, F, and P. Three little letters that equal a world of hurt. Unless you’re required to do so by law, never, I repeat, never write a Request For Proposal for a software development project. We guarantee you’ll end up wasting your own time, but worse, you’ll probably undermine the success of your project. As we see it, RFP might as well stand for Really F’ing Pointless.

The RFP process creates such misaligned incentives at the outset that projects suffer or often 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 an RFP process. It’s not to say that we haven’t won our fair share of RFPs, but we’ve never been involved in an RFP process that added any value to the project.

Here are six reasons why you should skip the RFP:

1. You want a strategic partner, not a commodity fulfillment engine.
A technology consultant is supposed to help you think through the big picture business issues as well as the nitty-gritty technical details. This is the most important value a good consultant can bring to the table, so you don’t want to skip this step.

2. Your RFP won’t have enough detail.
Despite your best efforts, you will never be able to include enough detail in an RFP to provide actionable information to a prospective vendor. Can a single document effectively communicate organizational context and business rationale, requirements and priorities, integration points, and all the other particulars necessary to successfully scope and build technology? Unfortunately, you’re doomed before you’ve even sent anything out the door.

3. Your received 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. Again, this is neither useful nor actionable.

4. RFPs waste 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 is often fraught with stacks of vendors and the proposals are rarely useful, it doesn’t behoove a consultant to put much effort into them.

Furthermore, every RFP I’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 details are left vague or uncertain. Here’s the more likely schedule 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 = TEN WEEKS OF WASTED TIME.

5. The RFP process will never be transparent.
Proponents of RFPs claim the process yields transparency, but admit it, incumbent vendors often help write RFPs and then tailor them accordingly so they’ll win the business. Proposal scoring is rarely, if ever, made public. Nope, in the RFP process everything is just as obscured from scrutiny as the alternative approaches, save for the one initial document (the RFP itself).

6. Pointing to an RFP after a failed project isn’t going to save your job.
If and when a project goes south, your RFP won’t shield you—if you picked the cheapest vendor but they failed to deliver the project, this reflects poorly on you, regardless of whether or not you went through the RFP process.

So, what should you do instead?

Instead of an RFP, consider a structured request for information (“RFI”) to collect salient details from a broad set of prospective vendors. Interview the vendors (in person, ideally) and ask for relevant portfolio examples. Figure out the opportunity your project represents for the vendor, and determine whether you want to be one of their big clients or small clients. Ask for a customer list—not just a list of references—and try to talk to those customers who haven’t been specially handpicked.

Most importantly, after you’ve selected a vendor, START SMALL. At Table XI, we never contract a software delivery engagement until we’ve gone through a structured project kick-off that we call an “inception.” We conduct an intensive, in-person session in which key members of our team meet with key members of the client’s team, and we dive deep into the business problem, the industry, the existing technology, and the organizational context. This is by no means a process unique to Table XI, although lots of inept and/or inexperienced vendors don’t do it.

The biggest advantage to this approach, at least for an initial engagement, is that you’ll be able to tell if your vendor’s a dud. After all, you wouldn’t marry someone before going on a first date, no matter how much structured “due diligence” you did beforehand. Building technology is an inherently messy business, and it pays to test the mettle of your partnership first. If there’s anything that smells wrong, challenge the vendor on it. If they don’t have a good answer, pay them for their time, thank them, and get out. You’ll have saved yourself a ton of time, a ton of money, and you can get to work with someone else who’s a better fit.