Answering RFx's

Years ago, I was interviewed for a PreSales position and the hiring manager (who eventually became my boss) asked me the question: "as PreSales, what's the job or task you hate the most?". Well, I had doubts whether to say "answering RFx's" because, although it was totally true, it may have ruined my chances to get the job. But I did it. I openly said "I hate these RFx with hundreds of requirements to answer". The (future) boss replied "totally agree, I hate it too". I got the job.

I must say today it's exactly the same situation... it's a task I don't enjoy at all (I don't know anyone who likes it) but it's part of the job. And this is where a Master in PreSales excels and demonstrates professionalism, more than in other attractive responsibilities where we feel motivated to measure up and deliver excellent results.

Assume our company took the "Go" decision to answer an RFx that a customer recently issued (I am not going to argue about the overall usefulness of the RFx process, there are other good articles about it). We have now plenty of documents to generate and requirements to answer. We as PreSales professionals must take over most of those deliverables. "You are the PreSales team and you are the owner of our response". However, ownership does not mean that we (PreSales) have complete control of how to answer the RFx. The reality is that there are multiple aspects that bias the overall response, such as:

Compliancy Rate: "Our Full Compliancy rate is very low. We have to make it at least 90%", you hear. Unfortunately, we know that "Fully Compliancy" is an "objective" gauge the buyers base their decision on. We all know since some years back there has been a culture of answering FC while it was not true. Vendors who answered FC to 100% of requirements while in reality they were 70% (or less) FC and the contract went to them because "we know they are lying but they are extremely cheap", the buyer said. So you wonder "why aren't we going to do the same?”

Feature Compliancy: In theory, "Fully Compliant" usually means that you have the feature "Out of the box" in your product/platform but that can be interpreted in many ways. Someone will say: "Yes, we can do it with our software out of the box... plus a few hundred of human days of delivery effort but well, that's configuration. All projects involve some configuration tasks, don't they?".

Standards Compliancy: Almost all RFx’s refer to standard bodies and regulators at some point (e.g. ISO, 3GPP, ETSI, IEEE, etc.). Some Customers consider this extremely important. Leaving these requirements not properly answered or even NC will not be well perceived. And answering “we are not compliant to this but we will do it if we are awarded” is extremely vague. You may be underestimating a very costly task and the customer knows it.

Price: In the end, we all know the price factor is the nearly the most influencing. You have heard conversations like this:

  • "This is very expensive. We have to reduce the price".

  • "Well, I am Presales and don't decide on prices. But tell me which feature(s) I can scope out".

  • "Just remove the unnecessary ones".

  • "Hmmm... Ok, I think features 3, 8 and 24 are not absolutely necessary but then, in order to be consistent, I have to remark the associated requirements as Not Compliant".

  • "Why? We are still compliant, we can do what those requirements ask about".

  • "Right but we are scoping them out. The platform we will eventually deliver to them, won't include those features. If we answer FC, they will expect those features to be delivered".

  • "No no no...we are answering requirements, it is just about telling them our capabilities".

I bet you will find these situations familiar. Unfortunately, answering an RFx is not like a math exam where answers can be right or wrong. As I said, there are so many factors that influence how to answer and where to put "FC", "PC", etc. There is no magic recipe that will tell you the response strategy, which will have to follow a company directive or ad-hoc strategy per RFx. Nevertheless, I share here my experiences and good practices (in my opinion) of how to respond to an RFx. They will sound familiar to most of you and you may say "I already do that" but it's always rewarding to think "Hey, this happened to me as well!".

Make the "response strategy" clear from the very beginning. I mean, get a directive involving every stakeholder in your organization. Perhaps you have experienced the frustrating situation where you answered every requirement in a succinct way, expressing compliancy with full honesty and transparency, how your product/platform was compliant here, why it was not compliant there... and eventually the directive was "put FC to almost everything" which then spoiled all this work.

Remember to involve EVERY stakeholder. We have seen cases where one day before submissions, a Senior Director popped up (he hadn't been involved so far) asking for changing all responses.

Be honest when answering requirements. We all have seen companies that marked everything as FC even without reading the requirements. One of the reasons why the RFx process is wasted, is because others copied them and in the end you were the only fool who was telling the truth. There is still time to revert this tendency.

When submitting a joint response with a partner, try to avoid individual, separate answers as much as possible. We have all seen "Requirement X: The system has to support this and that, blah blah blah..." and then the response "Company A: FC, we support it this way. Company B: FC, our platform complies by that way". Try to provide a unique and cohesive answer, as much as possible.

Never wait until the last minute to submit your RFx response. I have seen cases where we were about to submit 1 hour before deadline and then problems arose with the upload platform of the customer: maximum file sizes, file formats (that we had to convert in a hurry), platform out of service due to overload, etc.

Try to avoid your own company's jargon and acronyms. Instead, use well-know standard acronyms. Or at least if you use yours, expand them frequently so that the reader knows what they are. Note that the Customer may distribute chapters among different readers so if you expand an acronym or explain a proprietary concept only in requirement #1, a reader who has been assigned requirements #300-400 won't understand it.

When it comes to dealing with RFx's the most critical aspect is requirement distribution within your organization. From experience, I have found this is true and thus I deemed it was worth a block of bullet points: