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:

• Go for help first. Before answering any requirement by yourself, identify those ones (or entire sections) for which you will need help from any other organization within your company (or even an external partner). For sure you have seen so frequently these "URGENT HELP NEEDED" where bid managers assigned to people entire blocks of hundreds of requirements saying "by the way, we need them answered by tomorrow" and in fact the RFx had been received weeks before.
• Don’t assign requirements to teams. Avoid sending emails saying “Delivery team, please fill in these requirements”. That will end up in nowhere. People will believe others will do the job and eventually no one will do it. Assign them to individual, specific person.
• When assigning requirements you will have to track progress almost daily. Those people are not owners of the RFx response and often won't feel committed to complete it within deadline or with acceptable quality, and therefore will prioritize any other task before this. Don't be surprised if you see something like "Hey, we are about to collect all responses for submission tomorrow... can you give me the responses to your 200 reqs?". "Sorry, I didn't have time to work on this, I have been very busy".
• In very large RFx's, usually other members of the company have to get involved... essentially because of lack of time to meet the deadline (which is usually 2-4 weeks to submit responses). If we are the Account owner, I would recommend dedicating almost exclusive effort to coordinate responses. I have experienced many occasions where I distributed requirements and kept some sections for me to answer myself, and close to deadline I realized about the disparity of responses among all colleagues involved. Not only about technical content, but also about style, extension, etc. Some may answer with one sentence, and others with several paragraphs. It's extremely important to keep consistency across responses. So I had to spend many hours rewriting text and making it as much cohesive as possible

To finish, let me emphasize again: answering RFx's is one more task of PreSales job and we have to stand out here too. Even if you believe it's a pure formality, you will disappoint customers that take the process seriously. Although we don't see what's behind the scenes, it usually takes them a lot of time and effort to run the process. Real professionalism pops up when we put our enthusiasm in tasks we dislike or don't fully believe in. Good luck with your submissions!

Note: “The statements and opinions expressed here are my own and do not necessarily represent those of MATRIXX Software, Inc.”

David Mariblanca is an experienced PreSales professional, currently serving as PreSales Manager for MATRIXX Software. He is also a member of PreSales Collective.

Connect with David on LinkedIn.

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:

• Go for help first. Before answering any requirement by yourself, identify those ones (or entire sections) for which you will need help from any other organization within your company (or even an external partner). For sure you have seen so frequently these "URGENT HELP NEEDED" where bid managers assigned to people entire blocks of hundreds of requirements saying "by the way, we need them answered by tomorrow" and in fact the RFx had been received weeks before.
• Don’t assign requirements to teams. Avoid sending emails saying “Delivery team, please fill in these requirements”. That will end up in nowhere. People will believe others will do the job and eventually no one will do it. Assign them to individual, specific person.
• When assigning requirements you will have to track progress almost daily. Those people are not owners of the RFx response and often won't feel committed to complete it within deadline or with acceptable quality, and therefore will prioritize any other task before this. Don't be surprised if you see something like "Hey, we are about to collect all responses for submission tomorrow... can you give me the responses to your 200 reqs?". "Sorry, I didn't have time to work on this, I have been very busy".
• In very large RFx's, usually other members of the company have to get involved... essentially because of lack of time to meet the deadline (which is usually 2-4 weeks to submit responses). If we are the Account owner, I would recommend dedicating almost exclusive effort to coordinate responses. I have experienced many occasions where I distributed requirements and kept some sections for me to answer myself, and close to deadline I realized about the disparity of responses among all colleagues involved. Not only about technical content, but also about style, extension, etc. Some may answer with one sentence, and others with several paragraphs. It's extremely important to keep consistency across responses. So I had to spend many hours rewriting text and making it as much cohesive as possible

To finish, let me emphasize again: answering RFx's is one more task of PreSales job and we have to stand out here too. Even if you believe it's a pure formality, you will disappoint customers that take the process seriously. Although we don't see what's behind the scenes, it usually takes them a lot of time and effort to run the process. Real professionalism pops up when we put our enthusiasm in tasks we dislike or don't fully believe in. Good luck with your submissions!

Note: “The statements and opinions expressed here are my own and do not necessarily represent those of MATRIXX Software, Inc.”

David Mariblanca is an experienced PreSales professional, currently serving as PreSales Manager for MATRIXX Software. He is also a member of PreSales Collective.

Connect with David on LinkedIn.