This is a follow-up to my previous post on the broken RFP process. I'd like to take a step back and cover what should be the easiest part of the RFP: the document format itself. Instead of straight-forward Word or Excel documents with question and answer sections, we've moved to nonsensical formats such as a PDF embedded in an Excel spreadsheet that is part of a Word document that is tied together with macros. Please stop the insanity and stick with the basics.
How Does an RFP Get Answered?
It'd probably help to explain how the RFP gets answered before explaining why multi-pick color-coded dropdown macros are awful. Most companies do not have a dedicated "We Answer RFPs" department. The responsibility largely falls on the local sales team. The sales rep gets a copy of the RFP, the questions get a quick review to make sure the technology is a good fit, and the RFP gets handed to the sales engineer. The sales engineer then acts as a coordinator for the RFP.
What does coordinating an RFP response look like? Well, it's project management. The SE will answer as many questions as possible, send the unanswered questions to the correct teams, collect all of their responses, plug them back into the RFP, review it once again, etc. There are also tools available such as RFPIO that make it a bit easier. You import the RFP, it'll auto-answer what it can, you can assign questions to other people, etc. It makes it less painful, but it's still a manual and time-intensive process in the end.
A Real-World RFP Analogy
Let's say you'd like to find out if a grocery store carries a particular item. Most people would simply call the store and ask. Take it a step further: the person you're speaking with is new to the store and doesn't actually know if they have it in stock. They simply put you on hold, call the department, get the answer, and relay it back to you. Problem solved!
Now, let's say instead of calling the store and asking, you decide to build a multi-tree automated phone application that will call on your behalf. It calls the store clerk, plays a pre-recorded message with the question, and allows them to press "1" for yes, "2" for no, or "3" for N/A. That same clerk presses "2" for no. They're now presented with a new set of choices such as "we never carried this", "we're currently out of stock", "this is a special order item", etc. You also add a voicemail section at the very end where the clerk can add additional details.
Unfortunately though, the menu was missing a few pieces of logic, and it would disconnect the phone call on anything other than "we never carried this". That is how most macro-enabled RFP multi-pick multi-cell dropdowns look to someone who is answering an RFP, complete with the missing logic because something wasn’t copied and pasted correctly. I'd run out of fingers and toes if I listed all the RFPs that involved fighting against macros, or RFPs that included direct links to file shares that only exist on the customer's network.
What's Wrong With My Document Format?
The TL;DR is that the more complex you make the RFP formatting, the more difficult it becomes to either (1) send the question to someone else on the team that can answer it, or (2) correctly upload it into an RFP tool. The obvious answer is "just send the whole document to everyone" and collect the answers, but that goes back to the project management issue that I described in the beginning. There will be lots of mistakes and unnecessary work if you're trying to coordinate 10-15 people answering separate copies of an RFP, especially when you have sections that overlap.
As an example, I just dealt with an issue where the "completed" RFP was exported, but the macro in the RFP only showed it as being 54% complete. Why? Because selecting an answer from a drop-down triggered a macro that caused other questions to appear, which in turn would trigger other questions. It might look fancy to someone showing off their Microsoft Office abilities, but I can promise anyone answering that RFP will wonder what the author was thinking when they put it together.
What Should My RFP Format Look Like?
The underlying theme is keep it simple, aka the KISS principle. You're doing it incorrectly if you need to enable macros or create complex formulas in the RFP. That's also ignoring the fact that every security-minded individual absolutely cringes when they need to turn on macros just to review a document. Your goal is to get answers to your questions, not to build a Turing machine in Excel. As someone that has answered RFPs for close to two decades, the best ones typically follow this format:
- Written in Microsoft Excel.
- The first sheet includes a basic description of the RFP and any additional instructions for completion.
- Each sheet of the XLS references the major sections. This might be "Company Description", "Tech Questions", "Security Assessment", etc.
- Each sheet contains a header row that includes a description of the columns, e.g. "Question Number", "Question", "Answer", and "Additional Information".
- The columns are consistent. Don't have "Column D" be the answer section for some questions, the additional information section for other questions, or potentially a drop-down for even more. That "Column D" should always be for the same type of answer.
...and that's it. It makes copying and pasting simple for everyone involved. Best of all, the majority of RFP assistance tools can import and export that without any issues. I found a perfect example on the State of Vermont Green Mountain Care Board website. I have no idea who wrote that or what the RFP is for, but the person who put that XLS together is my hero. I'd look at that during import and think "this person knows what they are doing".
Conclusion
Sarcasm and bad analogies aside, I truly hope this article causes someone to rethink their approach the next time they're building an RFP. You have questions, we have answers. Don't add unnecessary complexity between the two.
Random RFP writer person at the State of Vermont Green Mountain Care Board website, I salute you.