Yes, that’s right, provider RFX Templates SUCK. Just like a Mosquito sucks the blood from your body, provider RFX Templates, used as-is, SUCK the success from your projects. As per yesterday’s post, the majority of them are generalized mash-ups of dozens of RFXs that have been pushed through the solution over the years by a user base which consist of watered-down versions of the most general questions and cost categories, along with a few extra questions and cost requests that the vendor believes are becoming more common and/or more important. They don’t contain a clear use case with sufficient data and related information required to obtain a good understanding of your needs, and thus, don’t provide the supplier with what is necessary to give you a good proposal.

So what can you do to fix the situation?

As far as the doctor is concerned, you need to do, at a minimum, four things:

• Describe Your OrganizationThomas Kase says to start by describing the type of organization that is an ideal user of your solution, but it’s important to separate out the organizational description and the organizational user because even though the ideal user may not be an average organizational user, if the needs of the parent organization are not met, the solution may be vetoed. Describe the organization: the countries it does business in, the products and services it offers, its language and currency requirements, it’s technology systems (and the systems the supplier will have to operate with), its organizational philosophy and CSR mandates, etc.
• Describe Your Organizational UsersThen you describe the intend users of the product or service, their processes, their culture and language skills, and desires.
• Describe Your Organizational Users’ NeedsOnce the supplier has the 30,000 foot view of the organization, and the 10,000 foot view of the users, you drop down to 1,000 feet and describe the process workflow in detail, the tools they have, the gaps in those processes and tools, and the outcomes that are required from the product or service being requested of the supplier.
• Describe Your Organizational Users’ Needs for Knowledge RetentionThen, you land on the ground and describe the knowledge that needs to be provided, elicited, and captured by the products and services you are requesting and make sure that the supplier has all of the information required to adequately address this need.

If you do not do these four things adequately, the chances of getting a decent response are slim to none. Of course, this is just the beginning, and like Thomas says you might also, depending on the circumstances, need to address engagement, collaboration, etc., but where you go from here depends on the specific types of products, services, and solutions being requested.