Biggest problem with Software RFPs

Request For Proposal (RFP) is a powerful document. By publicly soliciting bids on your software development project, you can get price quotes from a variety of IT firms. And of course, your RFP can be very carefully written to ensure that your every demand is met, and to lay out the measures that will be used to assess the final product once it has been delivered. Ideally, the RFP is a relatively quick way of finding the best and/or lowest bidder who can solve your problem by helping you write some software.

But ideals rarely become reality, and the RFP is not a magic bullet that will solve your software development woes. In fact, it’s an often-misused tool that can lead companies down inefficient, wasteful paths—and sometimes leave them stuck in bed with the wrong partners.

The biggest problem with RFPs is that there’s often a difference between what you think you need and what you actually need, both in the sense of the short-term systemic needs of your software and the long-term strategic needs of your business. Companies that see a problem and immediately issue an RFP are skipping a crucial step in the software development process: discovery.

The discovery process in software is a bit like the discovery process in law in that it’s about studying the situation and all the evidence before the action (the trial or the software development) begins. Lawyers go through discovery so that they can go into a trial knowing exactly what they’re facing, having reviewed all of the evidence that’s out there and thought through how it can be best used to support their case. Companies with software development needs should be doing the same thing: going through discovery before development begins in order to assess their own needs, planning out the software development roadmap, and ensuring that those plans align correctly with the company’s broader strategic vision.

Software discovery is typically broken down into two basic steps. The first step is to identify the problem and the specific needs the development project needs to address. This might include reviewing your company data, talking to management, and even interviewing customers (none of which is possible in the confines of the RFP bidding system). Once these needs are identified, they must be analyzed with a view towards the development pipeline: what specific features will need to be written? How will they interact with each other? What will the completed solution that includes all of the necessary features look and function like? Only when these questions are thoroughly answered can proper development begin.

One reason companies often shy away from discovery is that it can seem expensive because the up-front costs come with no guaranteed end product. But in actuality, going through discovery is probably cheaper than skipping it. You might pay for an IT contractor to do the discovery process only to learn that you don’t really need what you thought you did. Having paid that $5,000 up front won’t hurt nearly as much as it will if you realize the custom software you asked for in your RFP doesn’t really solve your problem after you’ve shelled out $500,000 to have it developed.

Discovery Process

Discovery can be a useful tool for discovering whether or not you’ve really made the right match with your IT contractor, too.

When a software company is going through the discovery process with you, you’ll be in close contact with the key members of their team that would head up your project’s development. If that’s not a good match, it’s much better to have learned that up front, when you’ve sunk a relatively small amount into the development, rather than discovering after paying in full that you’re stuck with a partner you don’t like.

Another problem with relying on an RFP to generate bids for a project is that the responses to the RFP don’t actually tell you what company will do the best job with your development task. What they tell you is which companies are best at writing RFP bids. Many firms that respond to RFPs have a dedicated writing team that puts their bids together, meaning that the developers who’ll actually be working on your project may not have seen any details or had any input whatsoever into the bid you’re seeing. What looks like the best bid to you may be a reflection of that firm’s skilled writing team, not their ability to solve your problem.

Then, there’s the danger of the temptation to go with the lowest bidder when you start the development process by trying to determine the bottom line. Obviously, budgetary constraints are a factor in any development project and they need to be taken into account. But when you start with the price, the pull of lower prices can be strong, despite the fact that they often mean working with second-rate teams and could ultimately mean a longer, less successful development process for your project.

It certainly isn’t as quick and easy as issuing an RFP, but companies with software outsourcing needs would be well advised to avoid the easy path and take the time to look for true partners, not just the lowest bidder. Getting referrals, researching online, having honest-to-god conversations with the folks at potential vendor firms—these things take time and effort, but the end result will likely be a better match.

The discovery process can be used as a dry run; a test of sorts to determine both how well this vendor works for you and precisely what you need to hire this vendor to do. It’s more effort and more up-front cost, but in the long run you may save money, and you’re far more likely to end up with a software solution that actually solves the problems you set out to solve.