About four summers ago I spent two days in a hotel meeting room with colleagues on a sales training thing, and one of the key messages the instructors had was that as soon as an RFP dropped in my Inbox, I was to delete it.
RFPs, he said, were a sham. If I received one, it was almost certainly pre-baked for another vendor and was not worth my time to even open up the PDF file and have a boo at it.
Hmmm, I thought. I’d certainly seen my share of digital signage technology RFPs that appeared to be written with a vendor in mind, or even written (obviously) by the vendor. They were optics exercises done to calm down anyone who complained about single sourcing or a failure to canvass the marketplace.
But, I also thought, they’re not ALL bad. Some are legitimate. And some just have to be responded to, as the companies are too big to just dismiss. Do you really just delete a request to bid for the business of a company that could, if won, change your career and company?
Four years later, I find myself in the curious position of writing RFPs on behalf of companies – producing the documents and managing much or all of the process because the client doesn’t have time (usually) or expertise (often), or wants a detached point of view (always).
In a truly curious twist, I actually like doing them.
Between many years responding to these things, and more recently writing them, I have learned a few key things the buyers and sellers should bear in mind.
1 – Only put out an RFP if you are serious and the project is budgeted and supported. These things take a lot of time and resources to pull together, and it makes no sense to start unless there are clear outcomes in mind.
2 – Ensure those who are invited to respond, right out of the gate, that the process is legitimate and they actually have a reason to bother putting in an effort.
3 – Explain very clearly, once again early on in the document, what you are looking for and what constitutes an ideal solution. The more respondents understand what you are after, the better the quality of response. You will also weed out companies that recognize this is either not what they want to do, or not what they do well.
4 – Don’t base the quality of the RFP on the number of questions you can conjure. The more questions you ask, the greater the chance some respondents will have a look and say, “Forget it. This will take a week!” It’s OK to ask a lot of questions, but ensure they are relevant and might unearth important responses. How network security is managed is important. Whether the system supports .PPT and .GIF files is not. I always include in the narrative that there are no bonus points for longer than necessary answers, which helps keep the wordiness in check.
5 – Tailor the request to the recipients. Bigger companies have boilerplate RFP documents that they recycle over and over. That can be OK, but what can happen is stipulations can get left in place – like labor and insurance requirements – that make little or no sense for a software service job. You may leave stuff that has the respondents crossing their eyes and deciding to opt out. I looked at one that wanted a $5 million, I think, certificate of insurance so I could write an RFP for an airport. Huh?
6 – Explain what you now do and how you do it. Providing a lot of background on your company and processes will help frame better answers and also stop a lot of follow-up questions.
7 – Be reasonable, whenever possible, in response timelines. That’s not always possible for varied reasons, but when it is, give the targeted vendors enough time to develop quality responses. Think about what your weeks look like and how much time you’d need to set aside to respond yourself, and recognize that like you, the people on the other end probably already had a full calendar and this has to get wedged in. And don’t ask for silly things like stacks of printed, specially bound documents on a certain size of paper, and so on – particularly when you know it will just be read on a laptop.
8 – Develop your short-ish list ahead of time, and limit your distribution. Government agencies may be required to make a job available to all, but if you are not held to that, keep your numbers down. If you let anyone read and respond, you could be reading Word docs for months. If you don’t know who the best target vendors would be, do your research or find someone (that’s not my consulting plug, just common sense) who can help you define that list.
9 – Define the process, follow it and keep people informed. I absolutely tore into a company a few years ago that issued a fishy RFP that was too big to delete, because they did not follow any of their stated timeline or review processes, did not keep anyone informed, and at the end of it all just went ahead and awarded the job to the people who were already in there. Awful, and too common. If you say you will make a short-list and have presentations and reviews, actually do them. And let the respondents know where they are at in the review, and in the end, why they did or did not win the business.
10 – Have a well-defined review or evaluation process. That may be weighted scoring, that may be a review team. But you need something that clearly defines how you come up with a winning vendor.
1 – Don’t mail it in, so to speak. If your response is going to be half-hearted, don’t even bother. Just send a note saying “Thanks, but we don’t think we’re a good fit!”
2 – Answer the damn questions, not your interpretation of what the question should really be.
3 – Verbosity is not a virtue. It’s OK to just confirm you can do something, and quickly explain how. This is not a Grade 7 History essay where there are extra marks for going past the minimum word count.
4 – Remember there are likely multiple people reading and reviewing the document. A software RFP will have people reading from different departments and different perspectives, so if you hand the response document off to a sales engineer, consider some of the people reading it won’t be very technical. In the same vein, the guys from IT might write the response off as the work of lightweights if the technical responses are the superficial work of a junior sales guy.
5 – Follow the process. The timelines and milestones may seem rushed and unreasonable, but you are not driving the bus. It’s OK to ask if a time extension is possible, but don’t expect to get it.
6 – Follow the template. I have seen responses on RFPs come in that ignored the Q&A and response template and tried instead to use a firm’s own pretty or pre-baked response format. First, you are irritating that people who laid out the template for a reason. And second, the requestors need some way to compare apple to apple responses, so sending in a banana is just stupid.
7 – Be honest. If your software doesn’t support something, declare that and suggest alternative approaches or timelines to remedy. If your office in New York is the kitchen table of a business development guy, you don’t have an office in New York. If your team is small, that’s not necessarily a bad thing. It may be a plus.
8 – Have references. Make sure they are good ones and on-board. Don’t recycle the same contacts over and over, and if you know a person will get called, call them ahead of time, let them know what’s up, and make sure they are cool.
9 – Don’t boast. Eyes will roll if the response looks like it was written by the marketing department and is filled with, “We’re the best, we’re the leaders, we’re innovators, we’re freakin AWESOME!!!” You may well be, but you are better off just impressing people with your capabilities and not your pom-pom shaking skills.
10 – Have your business questions ready and aligned. Let’s be honest. Most of what your technology can do, can also be done by your competitors. The requestors probably know this, or will draw that conclusion after reading responses. A big part of how your response will be judged is the business strength of your company. In effect, they want assurance that you will be around and thriving for years to come. That means they probably want to see some financials, and responding with, “We’re a privately-held company and we don’t share that information” probably won’t cut it. Whatever it may be, you will almost certainly need to have something you are comfortable handing over (NDA in place) that gives clear insight on how things are going.
I could go on and on, but hope this starts to give end-users and vendors better insight into the process.