Personal RFP’s….what are they, and how do we make them happen?

At the VRM West Coast workshop, Don Marti led a session on Personal RFP’s, which then led to the issue being debated further on the mail list and built out in this post by Alan Mitchell. Here’s my contribution, looking as much from the CRM/ recipient perspective as the VRM one – ultimately I think that until we look at both simultaneously then we won’t get much up and running at any kind of scale deployment.

Firstly, I think we need to get our terminology in order; as Craig Burton pointed out…we do not yet have a clear VRM lexicon accepted and understood by all project participants.

Here are a couple of references from Wikipedia, that relate to/ illustrate the background to the terms Request for Information (RFI) and Request for Proposals (RFP). I think we need to look at both in tandem because typically they interact with each other.

Request for InformationA request for information (RFI) is a standard business process whose purpose is to collect written information about the capabilities of various suppliers. Normally it follows a format that can be used for comparative purposes. An RFI is primarily used to gather information to help make a decision on what steps to take next. RFIs are therefore seldom the final stage and are instead often used in combination with the following: request for proposal (RFP), request for tender (RFT), and request for quotation (RFQ). In addition to gathering basic information, an RFI is often used as a solicitation sent to a broad base of potential suppliers for the purpose of conditioning supplier’s minds, developing strategy, building a database, and preparing for an RFP, RFT, or RFQ.

Request for ProposalA request for proposal (referred to as RFP) is an invitation for suppliers, often through a bidding process, to submit a proposal on a specific commodity or service. A bidding process is one of the best methods for leveraging a company’s negotiating ability and purchasing power with suppliers. The RFP process brings structure to the procurement decision and allows the risks and benefits to be identified clearly upfront. The RFP purchase process is lengthier than others, so it is used only where its many advantages outweigh any disadvantages and delays caused. The added benefit of input from a broad spectrum of functional experts ensures that the solution chosen will suit the company’s requirements. Effective RFPs typically reflect the strategy and short/long-term business objectives, providing detailed insight upon which suppliers will be able to offer a matching perspective.

I think the background to these terms is key to how we must think of them in VRM world if we are to understand how best to deploy them. What does that mean in practice?

  1. The RFI and RFP processes originate from professional procurement functions, that have the time, funds and incentive to make the process work
  2. There is an implicit logic in the process for both parties, architected around eliminating guesswork and waste; i.e. we’ll tell you what we want to know about (RFI) and, based on that information, what we want to buy (RFP) to save you having to market and sell to us; and by being more organised we’ll be able to do a more efficient deal for both and generate a win-win
  3. They are business processes, not just technologies or data flows
  4. The communications channels through which the interactions and transactions are exchanged should be standard, mass market, not niche
  5. They need two parties, issuers and respondents, both of whom understand how the process works, and both of whom have to do a lot of work to make the exercise work
  6. They typically relate to fairly complex requirements, because the cost of the process is high enough to eliminate the value in applying it to simple/ low cost purchases
  7. The buyer requirement/ seller response is rarely just about lowest price, items suited to that are dealt with in commodity markets

In addition to these characteristics, it is also worth noting that over time intermediaries have emerged (e.g. TEC) who, amongst other support services, make whole series of standard RFI and RFP templates available at no or low cost in order to stick themselves into the value chain.

My view of the above is that a) the originators of the terms RFI and RFP now have finely honed processes for dealing with them, they do enable win-wins for buyer and seller, and intermediaries have emerged to deal with some of the hard stuff – like finding common terminology, and b) they are typically not automated processes and thus not not at all like what will actually be required to do the things we have commonly described as Personal RFPs in VRM discussions, (e.g. i’m here, and I need a stroller for twins).

SO: Before we progress, we may wish to change our terminology around the RFI/ RFP issue – to more accurately reflect what the individual needs; otherwise we risk being confused with the prior deployments of the terms which actually have very little in common with what the individual might deploy right now.

Here’s my view of what those needs are:

  • To be able to articulate a requirement for information about a product or service in ways that can be discovered by potential suppliers or other third or fourth party service providers (assume by a machine but not exclusively so). This area is where Alan suggests there is the biggest gap at present; and that’s quite right – if that gap was not there we’d have had personal RFP type things going on years ago.
  • To share that requirement for information without compromising ones data privacy beyond that required to receive the information sought.
  • To match ‘information requests/ buying intentions with their equivalent information provisions and proposals (that’s the really smart bit!!!!).
  • To receive responses to the information request through one or more communication channels.
  • To be able to interact with responses, including follow up to complete a sale, or to extend an information request.

If we look hard enough we’ll find that there are already architectures out there, that do 2, 3 and 4 – and bits of 1 are around that can be picked up and added in, either directly or (more likely) via fourth party services. For example, the architecture below has been doing its stuff on the web since way back in 2000; a proposition called 2busy2surf that was way ahead of its time. Unfortunately that business has now gone, but the architecture and buyer-seller matching engine has been white-labelled into 20 or so propositions since then. It is still churning out stacks of permissioned requests for information and requests for proposals, and returning matched information packages or offers. These come direct from the selling organisation, or more typically through the affiliate markets (third party services).

RFI & P Architecture 1

So, to get what we used to call personal RFP’s up and running, what we need to do, in my view, is:

  1. Sort out our terminology/ lexicon
  2. Build out the Requirements Articulation piece, adding search maps, comparison engines and other added value buying services into the spec)
  3. Tell the story of the architecture
  4. Get it running in a few business in a more overtly VRM way
  5. Publish the architecture as an open standard

That’s going to take a bit of time and effort. It’s on the agenda for the User Driven and Volunteered Personal Information working group at Kantara; this group has now been approved and will be up and running shortly. I’ll post the details on how to join that as soon as I have them.

Thoughts anyone?

Iain

4 Comments

  1. Charles Andres says:

    1. Sort out our terminology/ lexicon
    +1. Many more definitions needed to describe who(or what) acts (on what, in what order, etc). Automated procedures need to be described along with expectations of what information from buyer is needed to process the request and advance it to supplier-matching. Simple and complicated examples needed. (i.e. Does the buyer know what they want, are criteria prioritized, bundled services, etc.? a camera, a camera with these 3 must-have features, when, where, with specific lenses…)

    2. Build out the Requirements Articulation piece, adding search maps, comparison engines and other added value buying services into the spec)
    – This looks to be a multi-tiered task that may need to be broken down to make progress. For example consider the complexities of:
    — What assumptions do we make about the buyer? If they just want a camera this year, it has to be one that already exists, in which case they need to trade off their requirements vs. what’s available. If it is a camera that doesn’t exist, it needs to be described.
    — How to treat availability? If I want it in less than 24 hours, I have to be willing to travel to a supply depot/store. Am I willing to tradeoff my requirements for convenience? Will I pay rush charges?
    — How do I treat service level? Do I need someone to show me how to use this particular device?
    — Assume I my needs are for a service. What are my criteria for the service provider? location? demeanor? education? recommendations by knowledgeable trusted sources?

    3. Tell the story of the architecture
    We are likely to be describing a buyer ceremony that does not currently exist. Most consumers have not thought through what they are shopping for. Those that have often know exactly what they want, and now are looking for flexibility on price, location, and availability only. Selecting specific examples may help flesh out initial prototypes. (I remember the ‘change of address’ example last year was first dismissed as being ‘too easy’ and then consumed a year’s discussion.)

    4. Get it running in a few business in a more overtly VRM way
    It would be good to describe existing business processes that are VRM-friendly, or meet some minimum VRM criteria even if granularly applied to specific process steps. For example, if I am in the market for a new camera, I will start my research at sites that cover most brands. I will research what cameras are available, and begin to narrow down what features and usability issues I think are important. Do I want a lightweight portable one or one that I can attach multiple lenses to? etc. By the time I have narrowed down what models I want, I can then start the task of searching eBay, NY Discount Cameras, et.al. to narrow in on price and availability. If I know what I want, the RFP is done. I can use SEO techniques to find my potential supplier. Isn’t this a VRM-friendly (although cumbersome) process?

    5. Publish the architecture as an open standard
    Presumably, the end game here is to create a description of something that can be implemented at or employed by multiple websites. If it is not explicit down to an API level, this can’t happen. Considering the potential semantic issues/assumptions re: how a potential buyer communicates their wants/requirements/limits, it would be wise to pick some examples. Making the architecture generally applicable to buying airplane tickets, lattes, clothing, vehicles, medical procedures, and house repair would be advantageous. It would be especially useful to isolate common architectural components within requirements articulation such as those needed to guide the buyer to be explicit, the gamut of specialized requirements, etc.

  2. alex says:

    Iain,

    I think, quite rightly, you focus on business. Business exists to make a profit, and is therefore going to be motivated by improving procurement processes.

    In the UK public sector and government, there are different, additonal terms such as PQQ ( pre qualification questionnaire ) and ITT ( invitation to tender ). These may follow EU rules.

    One of the issues that we always encountered was the difficulty with faceless communication when inviting tenders for a service. 100 black pencils is OK ; the provision of advocacy services to mental health patients at xx hospital may prompt further questions as to what this is, and what it will cover. Of course the buyer can say, you tell me, but invariably they would try to provide an answer to all potential tenderers.

    My own view, based on the experience of working on some of these tenders, is that the public sector procurement process is largely a waste of time and money. One might as well say that all organisations in the UK can bid for any UK public sector work. Procurement is a sham profession, and much of it a sham process. Its primary purpose is for the tenderer to be able to say ” I followed the EU process so you cannot fire me “.

    What no-one has ever tackled is the lack of successful outcomes, the absence of true commissioning, the inability to specify outcomes, the 12 months that it can take to run a procurement process ( rendering the original spec. invalid ), the inherent prejudice against SMEs

    What it needs is for government to see themselves as a business, not a self-preservation order

    However, assuming that in other parts of the economy it does serve a purpose, and clearly it does, then what you suggest makes eminent sense.

    Start early, start small, start open and learn, then iterate

  3. Iain says:

    Hi Alex, yes I’ve just had a flashback to a govt project I was working on years ago in which the procurement folks proposed to kick off a three month study to determine how much govt was spending with supplier X. Then some smartass (might have been me) said ‘wouldn’t it be a lit easier to just ask supplier X. Needless to say, what we found when we asked supplier X was that there were 65 contracts in place, all doing pretty much the same thing, all put in place by so-called professional procurement…

    So, I’d agree, procurement and public sector is not a good mix.

    I think it works better in private sector, but usually because there is a ‘partner manager’ somewhere in the mix to remind the procurement folks of the need for a quick win.

    And, as you say, professional procurement are often a major barrier to SME’s working with big business, no matter how valid the SME offering is.

    So we need to make sure that VRM does not reinvent procurement without fixing these negatives in the process.

    Thanks

    Iain

  4. Iain says:

    Hi Charles, yes I think this will take a while to tackle; we’ll be doing so in the newly formed Kantara Working Group – which is charterd for 5 years I think; hopefully that will be long enough!!!!

    http://kantarainitiative.org/confluence/display/WGUDIT/Home

    I expect we’ll be tackling pretty much all of the points you raise in your comment.

    Cheers

    Iain