Five Rules for RFP Authors
It has dominated my life for the last month, and now the RFP is gone. For future reference, if you're going to issue an RFP, here are some rules suggestions.
Number 1 : Do not under any circumstances require the respondents to use the "track changes" feature of Microsoft Word.
This is just evil, especially on a long document. Typically, responding to a several thousand question document requires breaking up that document and having many people work in parallel. However, if you require "track changes" to be on, it is impossible to just paste all of those separate sections into one coherent total document. What ends up happening is one person sits all night cutting and pasting individual requirements into a clean original. And then if typos are discovered, the whole process could start all over. The potential for errors is enormous, as the person delegated to cut and paste can make one mistake and screw up dozens of answers.
Why not just let the responders put the responses in blue italics or something similarly easy to distinguish? There is no value in forcing "track changes" and the pain it inflicts on your respondents is tremendous. Unless that was your goal all along, of course.
Number 2 : Less is More
My wife's company once made everyone fill out an empoyee evaluation form for all employees. The form had 50 categories, meaning that each category was worth only 2% of the total. So, if a category was titled "Propensity for Stealing from the Company" and the employee got the lowest possible score, he'd still be doing just fine overall. The point is that there was no way to get a clear picture or point out areas for improvement when each response was essentially individually negligible.
Please remember this lesson when preparing your RFP. If you include over 4000 questions, the odds of your getting anything useful from the response is vanishingly small. The reality is, as your responders well know, that only 20 to 50 of the questions really matter. The rest is details that can be worked out in later discussions. Yet, if you insist that all 4000 questions are equally important, you'll end up with lousy and rushed answers to everything - including the 20 to 50 that you really care about.
The ideal RFP would be less than 100 questions with opportunities for the responders to fill in detials in informational requests. Asking detailed questions about each requirement - particularly if you're listing all of the requirements in an industry standard - is a waste of everyone's time.
Number 3 : Limit the contributors to your RFP to those who Actually Understand your Business
Yes, it's nice to have everyone help out. And I'm sure that there are people in your organization who would raise a huge stink if they were left out of a major RFP. However, allowing contributions from people who have nothing to do with the business being requested adds unneccesary confusion and wastes everyone's time.
For example, if you are in the market for red widgets, you've probably spent a while talking to all of your widget vendors about your requirements, you're going to based your red widget deployment on your current widget methods and procedures, and you're going to deploy red widgets within the constraints of your existing widget business. Your RFP responders know all of this very well and have been planning their red widget development based on your requirements (if they are worthy widget developers). If you then allow someone from outside the widget department to draft questions in your RFP that refer to shades of mauve and puce, you're just going to confuse your responders.
Do you really want the red widgets that you've been discussing with them for the last few months or have your priorities changed? Are you really going to completely throw out your current widget operating methods and develop a brand new set for the new widget deployment? How could you possibly ever actually administer odd requirements like biometric validation on every widget component? It's all very confusing.
What ends up happening is that your responders spend countless hours figuring out how to respond to these unexpected and often bizarre requirements rather than concentrating on the requirements that actually matter. And that's not useful for anyone.
Number 4: Coordinate between authors
Certainly we all understand that a very large RFP usually requires contributions from many authors with many area of expertise. In an ideal world, each area would be completely self-contained and there would be no overlap. However, we do not live in an ideal world and sometimes overlap is inevitable. For the best RFP response possible, at least attempt to coordinate amongst those authors.
Duplicate requirements are to be expected in a very large document (see Number 2 above). Contradictions, on the other hand, should not be. If one author writes a set of requirements on the blue shades acceptable on your widgets while another author writes all requirements from an assumption of shades of pink, your responders are going to be forced to choose one or the other ... or just lie outright.
The biggest downside to uncoordinated authors is, as with many of the suggestions above, that the RFP response quality is greatly affected. Your responders are forced to spend countless hours trying to walk a fine line between conflicting requirements. No one really expects anyone to be able to build the Frankenstein monster that you've officially requested, but none of your responders wants to take a chance that they'll pick the wrong set of requirements to conform to.
Sometimes it's fun after an RFP is completed to estimate the actual cost and size of a widget that would meet all of the requirements in the RFP. I personally responded once to an RFP that purported to be for a small piece of peripheral telecommunications equipment, expected to fit into a space about 13 inches tall and consume about 100 Watts of power. We estimated that to meet all of the requirements would take well over 2 seven-foot bays of equipment and would consume nearly 2000 Watts of power. That's what happens when you don't coordinate among authors (although some of that problem was also due to ignoring Number 3 above).
Number 5 : Give your responders some leeway
In general, the people responding to your RFP are experts in their area of business. You are expert in your area of business. The overlap between the two should be the subject of the RFP. Do not try to stray into the responders' area, as you're going to seriously constrict what could be some quite interesting responses.
For example, if there are multiple ways of making the spongy interior of a widget, you should write requirements on the elasticity and responsivity of the widget overall. Unless there is a hugely compelling reason, you should not be dictating the implementation of the spongy material itself.
When you unnecessarily dictate implementation, you end closing in your responders and eliminating any possbility of innovative responses. This is not to suggest, for example, that you should not require adherence to industry standards to ensure interoperation. However, trying to prove to your responders how smart you are by listing thousands of implementation details is, in the end, of little use and actually detrimental to finding an ideal response.
Give you responders some leeway. Allow them to describe what they think is the best implementation. Sure you'll get a lot of Marketing sludge, but you'll also get a better understanding of what those folks are capable of doing - at least from the conscientious ones, which are the ones that you want to do business with anyway.
Thank you
Thank you for the opportunity to respond to your RFP. It has been an educational experience and one that we greatly appreciate. We look forward to working with you in the future.
Number 1 : Do not under any circumstances require the respondents to use the "track changes" feature of Microsoft Word.
This is just evil, especially on a long document. Typically, responding to a several thousand question document requires breaking up that document and having many people work in parallel. However, if you require "track changes" to be on, it is impossible to just paste all of those separate sections into one coherent total document. What ends up happening is one person sits all night cutting and pasting individual requirements into a clean original. And then if typos are discovered, the whole process could start all over. The potential for errors is enormous, as the person delegated to cut and paste can make one mistake and screw up dozens of answers.
Why not just let the responders put the responses in blue italics or something similarly easy to distinguish? There is no value in forcing "track changes" and the pain it inflicts on your respondents is tremendous. Unless that was your goal all along, of course.
Number 2 : Less is More
My wife's company once made everyone fill out an empoyee evaluation form for all employees. The form had 50 categories, meaning that each category was worth only 2% of the total. So, if a category was titled "Propensity for Stealing from the Company" and the employee got the lowest possible score, he'd still be doing just fine overall. The point is that there was no way to get a clear picture or point out areas for improvement when each response was essentially individually negligible.
Please remember this lesson when preparing your RFP. If you include over 4000 questions, the odds of your getting anything useful from the response is vanishingly small. The reality is, as your responders well know, that only 20 to 50 of the questions really matter. The rest is details that can be worked out in later discussions. Yet, if you insist that all 4000 questions are equally important, you'll end up with lousy and rushed answers to everything - including the 20 to 50 that you really care about.
The ideal RFP would be less than 100 questions with opportunities for the responders to fill in detials in informational requests. Asking detailed questions about each requirement - particularly if you're listing all of the requirements in an industry standard - is a waste of everyone's time.
Number 3 : Limit the contributors to your RFP to those who Actually Understand your Business
Yes, it's nice to have everyone help out. And I'm sure that there are people in your organization who would raise a huge stink if they were left out of a major RFP. However, allowing contributions from people who have nothing to do with the business being requested adds unneccesary confusion and wastes everyone's time.
For example, if you are in the market for red widgets, you've probably spent a while talking to all of your widget vendors about your requirements, you're going to based your red widget deployment on your current widget methods and procedures, and you're going to deploy red widgets within the constraints of your existing widget business. Your RFP responders know all of this very well and have been planning their red widget development based on your requirements (if they are worthy widget developers). If you then allow someone from outside the widget department to draft questions in your RFP that refer to shades of mauve and puce, you're just going to confuse your responders.
Do you really want the red widgets that you've been discussing with them for the last few months or have your priorities changed? Are you really going to completely throw out your current widget operating methods and develop a brand new set for the new widget deployment? How could you possibly ever actually administer odd requirements like biometric validation on every widget component? It's all very confusing.
What ends up happening is that your responders spend countless hours figuring out how to respond to these unexpected and often bizarre requirements rather than concentrating on the requirements that actually matter. And that's not useful for anyone.
Number 4: Coordinate between authors
Certainly we all understand that a very large RFP usually requires contributions from many authors with many area of expertise. In an ideal world, each area would be completely self-contained and there would be no overlap. However, we do not live in an ideal world and sometimes overlap is inevitable. For the best RFP response possible, at least attempt to coordinate amongst those authors.
Duplicate requirements are to be expected in a very large document (see Number 2 above). Contradictions, on the other hand, should not be. If one author writes a set of requirements on the blue shades acceptable on your widgets while another author writes all requirements from an assumption of shades of pink, your responders are going to be forced to choose one or the other ... or just lie outright.
The biggest downside to uncoordinated authors is, as with many of the suggestions above, that the RFP response quality is greatly affected. Your responders are forced to spend countless hours trying to walk a fine line between conflicting requirements. No one really expects anyone to be able to build the Frankenstein monster that you've officially requested, but none of your responders wants to take a chance that they'll pick the wrong set of requirements to conform to.
Sometimes it's fun after an RFP is completed to estimate the actual cost and size of a widget that would meet all of the requirements in the RFP. I personally responded once to an RFP that purported to be for a small piece of peripheral telecommunications equipment, expected to fit into a space about 13 inches tall and consume about 100 Watts of power. We estimated that to meet all of the requirements would take well over 2 seven-foot bays of equipment and would consume nearly 2000 Watts of power. That's what happens when you don't coordinate among authors (although some of that problem was also due to ignoring Number 3 above).
Number 5 : Give your responders some leeway
In general, the people responding to your RFP are experts in their area of business. You are expert in your area of business. The overlap between the two should be the subject of the RFP. Do not try to stray into the responders' area, as you're going to seriously constrict what could be some quite interesting responses.
For example, if there are multiple ways of making the spongy interior of a widget, you should write requirements on the elasticity and responsivity of the widget overall. Unless there is a hugely compelling reason, you should not be dictating the implementation of the spongy material itself.
When you unnecessarily dictate implementation, you end closing in your responders and eliminating any possbility of innovative responses. This is not to suggest, for example, that you should not require adherence to industry standards to ensure interoperation. However, trying to prove to your responders how smart you are by listing thousands of implementation details is, in the end, of little use and actually detrimental to finding an ideal response.
Give you responders some leeway. Allow them to describe what they think is the best implementation. Sure you'll get a lot of Marketing sludge, but you'll also get a better understanding of what those folks are capable of doing - at least from the conscientious ones, which are the ones that you want to do business with anyway.
Thank you
Thank you for the opportunity to respond to your RFP. It has been an educational experience and one that we greatly appreciate. We look forward to working with you in the future.
Filed in: telecommuncations creations
Labels: creations, telecommunications
8:00 AM
|0 comments
| Backlinks
0 Comments:
Post a Comment
Links to this post:
Create a Link
<< Banana Stew Home