What's Your Take On RfP Versus RfS?

Hi everybody. I'd like to get your opinion on the discussion about RfP versus RfS (Request for Solution). How do you see the difference?

I am always using the term RfP for the activities to invite a vendor to provide an offer for solving business issues. So as part of an RfP, we at Forrester describe the problem, the current state (CMO = Current Mode of Operation) and the to-be-expected future state (FMO = Future Mode of Operation). Despite the fact that we may describe the client's intention of the future state, we always ask invited providers to propose alternative solutions to the problem.

In this respect, I am currently reluctant to accept that we need another term besides RfT, RfI, RfQ, or RfP. From my experience, RfQ and RfP are the two things that differentiate between a commoditized service where you describe what the supplier has to deliver and an RfP in which you ask for a more "solution-oriented" proposal from the supplier. Rather than complicating things by adding new acronyms, I think it would be much better to use existing, well-established terms to differentiate between what we are looking for as a supplier's response.

Thanks for your comments.

 

Lutz

Comments

What makes a good RFP?

I have seen The good, the bad and the ugly RFPs. Some had murky business needs and some had too many constraints, and some were written by ( it appeared to be ) multiple people asking questions, questions and questions. Essential parts of RFP are budget, problem to be solved, timeframe, functionality needed, NFRs etc. If they are there then i would call it RfS

Thanks Yogesh. I totally

Thanks Yogesh. I totally agree to your point on the good, the bad and the ugly. I have seen some of those docs where I was thinking that the value behind those was more the number of pages than getting to the core of the problem.

And the essential parts you are mentioning is what I see as well. But do we therefore really need another term that "simply" tells us that this is a "best in class" RfP?

RFS for telecoms - sounds like something a vendor would push

Regarding networks and telecoms services, many is the service provider vendor who wants to pitch their value proposition/differentiators by telling the requesting user company what they need instead of answering their questions. Granted it's very costly to respond to a complex, multi-service, multi-country telecoms RFP, and we've also seen many substandard RFP documents (post-issue) that blend technical and service requirements specifications with "and other options" (RFI-type "what is your roadmap") questions. A request for solutions RFS suggests openness for a full outsourcing proposal for the category or integration of multiple categories of infrastructure technology. I can see why it would appeal to vendors certainly, but in my view, respectfully, it would be very challenging for IT SVM evaluators to meaningfully compare and rate the different vendor proposals. Recommendation for SVM: Avoid opening the door so widely - ask for proposals based on known technical specifications; respecting vendor roadmaps and broader solutions capabilities, put these broader questions in a separate section at the end, and state clearly in the introductory paragraph that your interest is to achieve a clearer understanding of the vendor's relevant solution/services portfolio and roadmap/plans that may be of interest in the future, but which are Out-of-Scope for the present RFP project.

RFS comparison - that's the issue

Thanks Brownlee. This is exactly one of the main issues that I see when using an RfS approach. It's the meaningful comparison of the proposed solutions from vendors. Even in RfPs clients often have the problem of comparing the responses if the RfP doesn't "dictate" the response format. And I think that using the RfS approach will shift the effort from the pre-RfX phase by making it lighter to the post-RfX phase by increasing the effort analyzing the responses to understand the functional match and the commercial viability.

Lutz

RFS supporter

We have found the Request for Solution language to be of value with our efforts to focus on innovation with suppliers. The traditional RFP is used for evaluation of "known" products and or solutions; we use the RFS when we are specifically looking to explore a solution for which we do not know the answer already. The process is different; the expectations for internal and external participants is different....it's a far more collaborative event.

Interesting approach

Thanks John for sharing this interesting perspective. I think I like this as it puts a different spin on the topic. And with the intention of a collaborative event something like this makes sense. But I think we clearly need to distinguish between the two acronyms - to set the right expectation on both sides.

RFS instead of RFI

John's point is well taken. RFI typically is issued when a user company wants to understand the marketplace ahead of inviting cost and services/solution proposals. Perhaps RFS is something to consider only with strategic suppliers or when consolidating vendors, and would be issued to a prequalified shorter list of vendors with whom the user company is interested in establishing or deepening a strategic-supplier/partner-supplier type relationship. In the communications solutions space, this could be for global hybrid managed-hosted-cloud UC, or for a WAN/LAN integration solution for VoIP-UC-video, etc.

Differences between IFB, RFP, and RFQ

It is important to know the difference of these three types of government solicitation to make sure you are using the appropriate one. Actually, there are four basic kinds of solicitation documents. The first type of solicitation document is used for bidding. In this type, the primary factor is price. For the second type, the focus is more on the factors than on the price. This type of solicitation document is used for request proposals. There is also a type of solicitation document that is used to ask for the qualifications of a certain individual, which is the third type. Lastly, the fourth type is used before the bid or proposal process is started in order to gather information from potential proposers or bidders.