Request for proposal (RFP) is a document that describes a project and announces it for bidding. Any qualified company can write a proposal based on the RFP document and submit it. Then the proposals are evaluated, and one company is selected to complete the project. This all sounds very simple and sometimes it really is, you describe what needs to be done and someone says how much it costs. However, there are many situations where RFP as a process is very troublesome and since we are a software company, I will try to explain why it is bad in software projects.

Car buying seems easy…

Let’s do a simple exercise of doing an RFP for a car. You write a list of attributes you need, and you send it out into the world. In few weeks you will end up with 100 replies from different car dealerships with what they think is a perfect car for you. Now you have a problem of picking the best one, but luckily for you, your friend Seppo is a car expert and has volunteered to do the job for you, assuming you will provide him some nutrition. Before Seppo starts the work, you tell him your budget is 20 000 euros and not a cent more. Seppo, being a reasonable person, sorts the proposals by price and throws all the proposals over your budget into the trash. Then he will select a best combination of mileage, size, model, and whatever other reason he sees fit. In the end you will have few options and probably select the one that is cheapest or looks the coolest.

…but you shouldn’t buy software the same way

Next day you take your new car and drive to the office, where your boss tells you that the company has identified a need to replace maintenance resource planning software and you’re in charge of the project. You collect your colleagues that use the current software, sit down with them, and write a list of needs. These needs will then form an RFP document that you will send to 5-10 companies that specialize in this kind of software.

Now, those companies need to review your long list of needs and make a choice. First choice is, should they even bother spending hours upon hours on replying, when they know that most RFPs are won based on the price, not the quality of the work. If they would actually want to win and think cheapest has the highest odds of doing so, they will need to choose what is the least they can offer that will still make the product viable. Do you want the software providers to go through all your needs and think of the cheapest solution to each one, or do you want them to identify your most critical needs and offer the best possible solution? In addition to the above, questions in RFP are just begging to be answered yes.

Here are few examples of maintenance task requirements from an actual RFP material:

  • Simple user interface / process for maintenance partners and personnel
  • Structure and clear processes to minimize the time spent and to support maintenance and unit managers
  • Acceptance process flows where relevant

With questions like this I often ask myself, do the buyers really know what they need? Many of the requirements are more of an opinion rather than an actual description of needs. All the relevant software on the market has these functionalities and any trained salesperson can answer yes and provide you with an ambiguous description of the functionality. Follow up round and discussion will of course clear some of the issues, but at that point you might have already dropped the perfect software provider for you.

Getting a new software has connections to multiple groups of people and processes, which usually makes the solutions customized and complex. It is not as simple as buying a car and asking your friend to help to choose the right one. It is a costly and necessary process where you need to evaluate your needs with experts in the field, and then choose the correct partner for the project.

Are you looking for the cheapest software or the best processes?

Even in our daily lives, we rarely choose the cheapest solution for something important. In the United States, for example, the public sector is forced to use Qualifications-Based Selection (QBS) for engineering projects, where the price is not considered in the initial selection. In QBS, the potential partners are evaluated based on their merits and expertise. Only at the last stage the price is considered and cheapest doesn’t always win.

I know that selecting a software provider might not seem as important as selecting a bridge builder for the public sector, but how important it is for you and your company?

Maxim Lehtinen, Project manager