Make Sure Your Development RFP Isn’t Hurting You!

We see a lot of RFPs for website design and app development. It is both an opportunity and a challenge. We love being considered for all of these projects. It means that we have good brand recognition. On the other hand, it means that we spend a substantial amount of time putting together proposals that we might have no chance of winning… and we don’t even know it!

I’ve been in the creative agency landscape long enough to know that the “RFP game” is different for each organization. But I also know there are a lot of similarities. Yes, some sectors and organizations require competitive bidding with clearly articulated selection criteria. There is no getting around it. While I don’t love jumping through the hoops to answer what sometimes seem like stock or unnecessary questions, I do see the value in making sure that a government agency is making the right choices for the right reasons. We expect that the taxes we pay are spent wisely. 

The other side of the coin is that many—far too many—other companies and nonprofit organizations have adopted a similar process to government. In a perfect world that wouldn’t be an issue. In the real world, there are a number of serious problems with how this often plays out.

Before diving too deeply into my thoughts, here are some similar notions from our friends and DeveloperTown.

Your RFP Might Be Hurting you!

If you are a company or nonprofit organization and you are doing a development RFP for a web or app project, here are some ways you might be hurting your chances of picking the right partner. 

#0 “We don’t respond to RFPs.”

There are a number of very good, very talented, very reputable companies that refuse to respond to RFPs. The reasons are myriad, and most are based on bad experiences responding to RFPs in the past. Here is a small selection of the reasons that companies refuse to respond, and each is unpacked in greater detail below.

1. There are too many hoops to jump through.
2. The selection criteria are too vague to know how to respond.
3. The decision makers already know who they want and are just putting out an RFP because they are required to.
4. The requirements are too specific and don’t leave any room for alternate/better solutions.
5. The budget for the project is too small to warrant putting so many hours into a proposal.

I have seen all of these things happen. I have refused to respond based on these reasons in the past. While RocketBuild doesn’t refuse to respond to RFPs, we certainly review each of the RFPs we receive keeping these things in mind. 

The thing to remember here is that when you put an RFP out into the world, it is being judged based on these things. Worse yet, you are likely removing more than half of the best respondents from your pool just because you wrote an RFP rather than having a more open bidding process. 

For related reading, check out this article from Forbes about why agencies should pass on RFPs.

#1 There are too many hoops to jump through

Rarely, but often enough to be noteworthy, we receive RFPs with some pretty stringent and extensive response requirements. I don’t want to spend too much time on this, but I will give a couple of examples to illustrate why a company like ours may not commit the time and effort to respond.

Example A: 

Recently, a small client in the finance industry asked us to do the following things in order to begin the bidding process for a marketing website (no access to customer or financial data):

1. Ensure that all of our staff is bonded.
2. Increase our insurance coverage to an amount that was 10x our annual revenue.
3. Have background checks on all of our employees.

Example B:

Another recent example from a small Indiana municipal group requesting a redesign of their very basic marketing website asked us to include the following in our response:

• The total cost for services should include:
  1. A breakdown of staff hours for each individual person assigned to the project,
  2. Hourly rates for each staff person, 
  3. Overhead and profit rates and direct costs anticipated in the performance of work including website redevelopment, and content migration.

In both of these cases, the total budget for the project was likely to be less than $50,000, which in the web and app development space would not be considered an especially large project. These requests require the companies responding to do a lot of legwork and potentially invest a good deal of capital in responding to the RFP, with no guarantee of winning.

#2 The selection criteria is too vague

When a company like ours receives an RFP, which are often 10 or more pages long, the first thing we want to know is “how are they making a decision?” The problem is… 

“Most RFPs don’t bother to tell respondents what the selection criteria are.”

That can be very disheartening to those of us who write the proposals. We might spend 20 – 30 hours on a single proposal, and it would be much more valuable time if we knew that what we were writing was actually helping to get us selected, and more importantly, helping to address the criteria that are most important to the decision-makers. 

Help us help you!

If you want to make sure you are getting responses from fully qualified and appropriate firms, try clearly articulating what factors are most important in making your decision. These might include:

• Budget: “This is a high priority project, and we anticipate dedicating significant resources to making sure it is successful,” or “We do not presently know what a total budget will be, so we would like to have respondents propose options for tiered solutions.”
• Timeline: “We have a large industry event in June of 2020, so we need the new app to launch in May of 2020.”
• Team Fit: “It is really important that our team be able to work closely with the selected vendor, which means that regular communication will be key,” or “Having a local team of developers will be critical because our internal developers will need to partner with them to review code.”
• Required Tech: “Our IT team will be required to support the site going forward, so it must be built in PHP or .NET.”

#3 The decision has already been made

It isn’t uncommon for an organization to release an RFP when they already know exactly who they are going to work with. Sometimes the pre-selected company can even be involved with writing the RFP. This inevitably leads towards the process being biased in their favor, and not the client needing the work done.  

I don’t really have much to say here other than… Please, please, consider if an RFP is required for your project before sending them out and draining many hard working companies’ precious time.

If you have a requirement to release an RFP for projects, I understand. But, you have already skirted the intent of the RFP requirement by pre-selecting your partner, so just go to the last step and let the rest of us know (quietly) that we shouldn’t bother submitting. We’ll all be happier for it!

Alternately, and preferably, stop prejudging. Your board chair may have “recommended” someone, or your marketing director may have a favorite firm, but just keep your mind open. If you are willing to put together an RFP, be willing to assess the responses on their own merits. 

#4 The requirements are too specific/stringent

Generally, when an organization releases an RFP, it is because they need a level of expertise that they do not possess internally. This is certainly the case with RFPs for web design, software development, or technology consulting. Most companies simply do not have the proper staff to engage in these services themselves. 

So, with that in mind, please don’t tell the respondents all of the answers you want in their proposals. Let us be the experts. Let us ask the right questions. Let us recommend the best answers. Let us implement the best solution. 

If you already know all of the technical specifications for what you want built, the tech stack you want to use, and all of the use cases you are solving for, then you probably just need an inexpensive implementation partner. That doesn’t require an RFP. Just solicit bids without the unnecessary complexity of adding RFP writing and reviewing to the mix. Remove strategy from the engagement and hire the labor you need, through contracting or augmenting your current staff.

#5 The budget is too small to warrant an RFP

Before submitting an RFP to a reputable development firm, ask yourself, “will this be worth their time?”

That may not be the easiest thing to judge, but here are some guidelines to help.

• A good firm in Indianapolis will charge something between $120 – $180 an hour as a blended rate. 
• An RFP will take somewhere between 20 – 30 hours to respond to.
• So, out of the gate there is a cost of $2,400 to $5,400 in just responding to the RFP.
• If a company tries to average 30% profit on a project (which is pretty normal), that means that the project budget needs to be $8,000 just to cover the cost of the work for a small company on a small RFP, and more like $18,000 for a large company on a big RFP. 

All that to say, if you have a project budget of less than $20,000, you should strongly consider only sending your RFP to a few small companies. Honestly, for even smaller projects, you might want to consider freelancers as a cost-effective option at that price point. 

To make it worthwhile for a reputable firm to respond to an RFP, engage in the interviews and Q&A, scope the project, and account for project overhead, you need to be looking at something closer to $50,000+ for a budget. 

And that’s just for the development and technical consulting portion. Assume a nearly equal amount for strategy and design. 

Fix It By Making the RFP Process Transparent

There is one surefire way to make everything work out. Be transparent during the RFP process. Answer questions openly. Be willing to answer questions to help firms disqualify themselves early, before they put in a lot of work that won’t ultimately benefit them or you. Doing so will create feelings of mutual respect. 

There are some pretty hard questions to ask that are much easier to answer. Be willing to answer questions like, “do you already have a firm in mind,” or “what is your anticipated budget range?” The answers to those sorts of questions can help everyone move forward more productively.