That depends. If you have lazy, uneducated, or inexperienced Supply Management personnel (because your Procurement department was staffed like the Island of Misfit Toys), then you want to delete them as soon as you get them because, if a template exists for the product or service you want, it will be sent out more-or-less as is and you’ll get a specification that is two sizes too large, two sizes too small, or very irregular and not at all a good fit for your organization.

On the other hand if you have educated, experienced, go-getting Supply Management personnel who take the time to properly construct an RFX, going through the steps outlined in our last post, then they do have a use. Specifically, as a check-list after the RFQ has been completely drafted to make sure that nothing was missed. Sourcing is complex these days and it’s hard even for an expert to include every relevant detail every time when time and resources are so scarce. There’s a reason that even hospitals and clinics use checklists, because it greatly decreases the chance of a (serious) error being made. If a vendor, that built a template as a result of analyzing dozens of events, included something in an RFX template, then, at least at one point in time, it was very relevant and, as such, should not be excluded from an RFX until a senior buyer confirms that the market or standard operating conditions have changed and that the question, cost component, or requirement is no longer relevant.

So, these templates do have their uses, as long as they are editable by senior buyers. Because, as explained in the last paragraph, over time, some parts of the template will become irrelevant and other questions, cost components, or requirements will become very relevant and need to be in all RFXs related to that product or category. If the senior buyers can completely customize the templates to the categories, products, and services of the organization and configure the tool so that no template is used out-of-the-box (until a senior buyer confirms that it is still accurate enough out-of-the-box), then the templates, and template features, have a use.

But as-is, the templates are probably less useful than calling a supplier over the phone and saying you need a quote for customized circuit boards and doing three-bids-and-a-buy blind.

In other words, templates have a use, which is why the doctor encourages most vendors to have a library of templates that can be used as starting points, but their use, until customized by a senior buyer, is that of a post-RFX creation checklist. Nothing more. And not understanding this can get your organization in serious trouble in its sourcing events.

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.

For almost seven (7) years to be precise – ever since it published its now classic post On Technology RFPs: Don’t Put the Cart Before the Host where it noted that more and more buyers were putting together ridiculously over-specified and complex RFPs for its technology solutions that often eliminated all but the worst solution one could possibly imagine before the first response was even received!

And yet, the doctor missed this two-part series later this spring by Thomas Kase over on Spend Matters where he asked “Why Set Yourself Up to Fail” Don’t Use Traditional Solution RFPs (and Part II).

In it he notes that most RFX Templates are bad — not just the ones for technology solutions (which started my rants seven years ago) — and he’s right! Most 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. As a result you get a one-size-fits-all garment that, depending on your organization, will be two sizes two big, two sizes two small, lopsided, backwards, or even inside out. How can you possibly expect to get a good response from your supplier when you send them a proposal that doesn’t even define your requirements?

Needless to say, the doctor was not surprised to hear Thomas say it was (and probably still is) rare to see a well-written RFP built on a clear use case, with sufficient data and other information to provide the solid assessment of needs that is needed to deliver a response that is reasonably close to what the client needs in order to make a down-selection, or even an award recommendation.

As a result, this is the reason why cold-call solution RFPs (from previously unknown prospects) are unlikely to receive much attention. The better the firm is, the busier they are, and more likely to weed out such RFPs — and the responses you get back can very well be from firms that are either less capable (desperate) or haven’t truly understood your needs. In other words, reducing your chances of a successful first round outcome.

So how can you fix the situation? Come back tomorrow and we’ll cover recommendations from both Thomas and the doctor who has been, and will be, ranting and raving about this for years!