Why RFP’s don’t always deliver the best bang for the buck

Why RFP’s don’t always deliver the best bang for the buck

img-blog-bricktechblog-no2

In my 30+ year career in the IT world (23 as a service provider) I have been asked to participate in my RFP’s (Request for Proposal) than I can remember. As our organization matured and we found our ideal client profile, we started participating a lot less frequently.

There are a few reasons for this which I will outline below. Please keep in mind as you read this, it does not necessarily apply to 100% of the RFP cases out there, but rather this is based on my personal and industry experience throughout my career.

Reason #1 – The person(s) tasked with writing the RFP requirements, are not fully qualified to write the RFP.

Now, this may seem a bit arrogant, but it’s not intended to be. I know a little something about the law and accounting, but I certainly am no expert and would always defer to an expert opinion on these (and other) subjects. I have seen countless RFP’s that have very specific requirements for hardware, software, infrastructure, etc. with no context around how those requirements were reached. Upon further questioning and investigation, it became evident that the RFP author either used a template they found online or did a Google search and put their search results into the RFP. In some cases, the questioning has produced additional information and context that was helpful, but more times than not there was a dead end and we had a choice to respond or walk away from the opportunity.

Reason #2 – There are no clearly defined goals or objectives to accurately measure one RFP with another. It becomes a bit of a “subjective popularity contest” of sorts.

This sort of piggybacks onto the first point above. Depending on how the RFP is structured, there may not be any context, goals or objectives and it becomes more like a haphazard shopping list of sorts. You’re then either given free reign to change, add or remove things based on your company way, which then puts the RFP writer in the position to judge what they believe is the best option for their organization by what’s written on paper (or in electronic format as is the case for most RFP’s nowadays)

Reason #3 – The incumbent writes the RFP.

For obvious reasons this is where the organization is merely “going through the required steps” with the intent of keeping the current provider in place. While I understand why some
organizations require 3 proposals for every RFP, when this approach is taken it crosses moral and ethical boundaries for me personally. It’s an intentional waste of everyone’s time and it really doesn’t fully serve the organizations purpose for having the 3-response requirement in the first place.

Reason #4 – The wrong organization objective is in the RFP.

I see this quite a bit where the organization is focused on getting a hardware or project quoted out in the RFP because of concerns over budget. While I certainly understand and respect the need for budget management, the bigger picture is being missed in the partner selection criteria. In order to effectively provide strategic advice to a client, it’s ultra-important to have institutional knowledge that you typically gain through your client onboarding process. To properly propose any hardware or software systems, you need to understand where the organization is today, and where they plan to go over the next 3-5 years. Without that knowledge you’re basically guessing and making assumptions about growth and planning and this typically winds up with and under or over specified project that doesn’t meet the needs over the lifespan of the systems/service.

I hope this has been a helpful exercise and I welcome all comments and feedback. The RFP process can be successful with the right planning, intention and involvement of the right stakeholders in an organization. My goal is for these points to raise some questions internally and create a dialogue that improves process and outcomes for all parties involved.