Why Your Technology RFP Process is Lousy (And 6 Rules for Success)
Having run technology RFPs from both a vendor and customer standpoint, I’m disturbed by the trend I’m seeing. RFP processes are becoming longer and longer. The depth and complexity seem to have little to do with the actual scope of work the customer is seeking bids on.
Without exaggeration, I recently received an RFP that had 171 long-response-format questions that, in the end, supported a deal that only had a three-year value of about $100,000. Compare that to a 111 question RFP that we won in 2012 for a contract with a three-year value of over $1 million.
We are actually very good at responding to RFPs at Synthesis. We keep the boilerplate information to a minimum and place emphasis on providing deep and meaningful answers to each question.
What troubles me isn’t the effort of putting together a solid pitch in the client’s preferred format. I believe many of these lengthy documents do not support decision-making in the manner they are intended. Even a detailed scoring methodology becomes ridiculous when 65% of the questions are qualitative and another 20% are irrelevant.
Some RFPs have clearly been written by a committee, with each person contributing a set of their own questions. This is a fine strategy except too often no one takes the time to remove repetition or ideas that are irrelevant to the decision.
Here’s an actual example from a recent RFP:
- #3.1.2 – Describe your capacity for project management
- #4.1.1 – What is your project management methodology
- #6.0.5 – What project management activities will your firm be providing
Yes, these are technically different questions, but certainly, these could have been condensed into a single item.
Some RFP’s are written by a strategic sourcing group and contain every buzzword and theme that has ever made it into a business blog.
Here are some of my “favorites”:
Describe your thought leadership activities in your industry
Describe your company’s commitment to green business practices
Does your company have a waste management and recycling program? Do you measure the amount of waste produced vs. recycled?
Does your company have established goals to reduce greenhouse gas emissions?
What is the company’s experience with union labor?
What are your expected profit margins on this account?
Is your company accessing various local small business and minority associations, local chambers of commerce and federal agencies’ small business offices for the identification of Diverse Businesses to be included in contract bidding events?
What do your competitors say about you?
Now, I recognize that we all want to run green, diverse, environmentally friendly businesses and be perceived as thought leaders in our industries. I also recognize that it may be a policy for companies to include certain questions in the RFP.
However, these types of questions do not improve the selection process; they just pollute it with superfluous words and nonsense responses. These unnecessary questions also add time and complexity to the evaluation process without adding value.
On top of that, there is often too little detail about the particulars of what is being bid on.
So what should be in a technology RFP?
First, let’s outline the goals of the RFP. An RFP allows you to:
- Receive a uniform set of proposals from select technology vendors and compare them side-by-side
- Learn which vendors are really qualified to do the work requested
- Make sure the vendors, their technology and operations are mature and sustainable
- Discover dependencies or additional/hidden costs that will need to be considered
- Collect cost estimates
- Obtain a reference list of contacts
I see no practical reason why the vital information above cannot be collected in about 25 questions.
Full disclosure: I am a bit of a hypocrite, and I have a hard time doing this myself. A client recently asked me to write a good consolidated RFP for their document automation solution and I came up with over 50 questions.
So, yes, it’s hard to keep these things short and to the point. If you’d like to also use this template (or a shorter one I’m working on) please contact me directly.
Here are my six general rules for writing an effective RFP for a technology solution:
#1 – Keep it short and to the point
If the question/requirement is not truly a principal evaluation criterion or is a duplicate, cut it! A short and powerful questionnaire is going to create a more effective competition and lead to clearer decision making.
One reason RFPs get blown up in size can be that the committee of constituents writing it has become too large. Once a procurement exercise is labeled “cross-departmental” or “enterprise solution” it becomes increasingly unlikely that a platform will be implemented in anyone’s lifetime. So this leads to my next rule:
#2 – Keep your focus on the specific problem you need to solve
Yes, it’s nice to have one solution or vendor cover a wide variety of business needs and nobody wants dozens of technology silos when they could have just a few. So how do you balance this with the need to get an economical solution selected and implemented this year?
My recommendation is to construct the RFP almost entirely from the standpoint of the principal beneficiary so you stay focused on how well the supplier will satisfy a specific need. It’s usually not a good idea to go for a multipurpose solution if it’s not a good match for the requirement that drove the initial search. Looking for valid extended-use scenarios for a solution is a secondary concern. First, focus on the business problem at hand.
#3 – Check references
Virtually every RFP includes the request for references, but they are called less than a quarter of the time. The excuse is always similar: “No one’s going to put down a bad reference, so why bother to call?”
This is a huge mistake. All vendors are going to “spin positive” in their RFP responses. They will describe their technology as industry-leading, mature, stable and secure, and they will say their professional services teams are the best of the best. The reference list and a set of well-constructed reference interview questions give you a chance to find out if they’ve stretched the truth. In my experience, it’s very rare that a reference will lie if asked a specific question.
Here are some types of questions to ask point-blank:
- When’s the last time the vendor did a real upgrade that improved your operations at his or her own expense? This helps you figure out how much of a “product” it is, and if you’re really buying into a commercial platform or a custom solution.
- How well do you know the people who support you, and how often do you need to escalate support or problem issues to management? This question helps you figure out if the vendor’s claims about their attentiveness and consistency hold water.
- What’s the one thing you would improve about the vendor if you could? Everyone has room for improvement, and no Vendor is perfect every day. Get the reference person to open up, and look for patterns that reveal consistent problems.
- Would you stick with this vendor if you could make a switch to another vendor easily and inexpensively? Figure out if they are in bed with this vendor just because it’s too expensive or too big of a hassle to make a change.
#4 – Illustrate your requirements
You may be shocked to learn how few details are provided with many RFPs to support a high-quality bid. While I’m hoping the advice in this article will apply to many solution spaces, I’ll focus on publishing solutions here.
For a document automation or digital communication solution of any type, you should provide the vendors with a complete inventory of sample materials to review. Let them really see what it is you want to produce better and more efficiently.
You should also provide an inventory grid that describes the cycles, quantities, and totals for each deliverable you’re expecting from the project.
Additionally, you’ll receive better pricing if you illustrate deliverables clearly and specifically.
When presented with vague requirements vendors have two options:
1) Pad the bid to accommodate a large project scope.
2) Bid low and plan to up-charge the client outside of the initial RFP competition.
By providing thorough and complete details on deliverables, you’ll protect yourself from pricing that is needlessly high or artificially low. If the project requirements definition feels bloated, the pricing you will be too.
#5 – Level-set your pricing expectations
This is really a two-fold exercise. First, it’s a huge waste of everyone’s time if you go shopping with a $10,000 budget and the bids all come back at $90,000. Do some research first and ask a couple of vendors (or colleagues) directly to give you an idea of what the costs will look like.
Second, tell vendors to give you their fair-market pricing in the first go-around – no offsets, discounts, or freebies. You can negotiate pricing and packaging of fees later on. In the first go-around, you want to see what the real costs will be for both setup and ongoing work. Be careful when a vendor offers free setup. They could just be desperate, they could have thick margins on the back-end or they may not intend to do much of the work to get you up and running. No vendor is really going to do professional services work for free. High-quality, experienced technical implementation professionals are way too expensive to be thrown around as loss leaders. You’re definitely going to pay for them somewhere.
In my experience, from both the vendor and the customer side, you’re better off not fighting too hard over the price. You want your vendor to make a profit and give them an incentive to serve your needs. You don’t want them working on thin margins and being forced to limit their investments in product development, support or services. Sometimes you can negotiate a little bit, (vendors almost always have something to give off of their initial pricing) but if the deal isn’t sustainable for both parties, everyone loses.
#6 – Put your experts on the phone
When a technology RFP is being run by a strategic sourcing group, conversations end up occurring at arm’s length. Yes, these companies are defending themselves against concerns about graft, kickbacks, favoritism, etc. But you need to have a real human relationship with your vendor to really get to know them, their style, their responsiveness, and their depth. It’s like evaluating a restaurant based just on its facade and the menu in the window.
By having personal discussions you’ll find out which vendors are smarmy, which are pushy, which ask good questions and which just say “yes” a lot. Put your subject matter experts on the phone or in a room with their people. You may be surprised how quickly you can determine which vendor really “gets you” and has the knowledge and experience to meet your needs.
The hands-on detail people who are going to work with the vendor and use the system are the best evaluators of the partner selection. They are also unlikely to be swayed by free lunches or kickbacks. This operational team should be front and center in the evaluation process. It should not be a procurement department or executive steering group.
Thanks for reading! If you liked this article, you can sign up to receive more content like this.Here are some related resources that might interest you:
From the Blog:Pitchbook Problems? 3 Ways Technology Can Help
From the Blog:Key Takeaways From Our 2018 Factsheet Production Study
From the Blog:Build or Buy: How to Decide?