Skip to content
Tiatra, LLCTiatra, LLC
Tiatra, LLC
Information Technology Solutions for Washington, DC Government Agencies
  • Home
  • About Us
  • Services
    • IT Engineering and Support
    • Software Development
    • Information Assurance and Testing
    • Project and Program Management
  • Clients & Partners
  • Careers
  • News
  • Contact
 
  • Home
  • About Us
  • Services
    • IT Engineering and Support
    • Software Development
    • Information Assurance and Testing
    • Project and Program Management
  • Clients & Partners
  • Careers
  • News
  • Contact

Request for proposal vs. request for partner: what works best for you?

Industry pundits have debated the value of conventional RFPs for more than a decade. Researchers at the University of Tennessee have been leaders in studying the shift to bidding approaches of greater collaboration, and have recently weighed in on the debate.

Interested in making a switch? This article provides a comparison between a traditional Request for Proposal (RFProposal) and more collaborative Request for Partner (RFPartner) processes.

First things first

The purpose of any competitive bid process is to help a buying organization find a supplier that best meets its needs. But what many organizations fail to understand is the nature of what you buy should drive the approach to your bid process. For example, many times a CIO or tech leader needs to find a suitable supplier to solve a business need. But all too often, what gets translated into the bid documents is the buying organization’s defining specifications for a product or task.

Think of it this way: you want a supplier to bring their expertise to help you think outside the box to solve a business need, but your procurement team puts the supplier in a box with a detailed spec. We call this the outsourcing paradox because the buying organization outsources to the expert and then tells the supplier how to do the work with the product spec or a detailed statement of work for services. This catch-22 can be avoided knowing the key differences between an RFProposal and an RFPartner, and when to use each.

Focus of bid documents

Regardless of whether you’re using RFProposal or an RFPartner, make sure you have a capable supplier. In many cases, organizations will use a request for qualification before issuing an RFProposal or an RFPartner. Doing so lets you shortlist the capable ones, and once you have them, the nature of the bid documents starts to change. An RFProposal is an efficient choice when the nature of the work is standardized, while an RFPartner is the better choice when the buying organization is seeking a strategic partner for the overall best fit to meet its needs.

When using an RFProposal, the buying organization provides detailed requirements like a description of the goods, services, program management, or support they want. The focus on the bid documents is transactional in nature with the goal of finding a supplier to fulfil a specific request.

Companies often use bid software, such as Ariba, GEP, or Coupa, to manage the bid processes. Buyers enter the question, and the supplier provider provides the answer. One key item the supplier answers is the price. Often, an RFProposal will help the buyer understand a supplier’s prices associated with specific billable line items.

In comparison, an RFPartner changes the focus of the bid documents away from the detailed specification, and focuses on helping the supplier understand the buying organization’s overall business situation and goals. The bid documents typically start with a detailed overview of the situation and provide the bidding suppliers with access to data or information they need to develop their solution.

Unlike an RFProposal, the questions are more open-ended in nature and include a dialogue period where the buyer and supplier collaborate on the best overall solution as described below. The bid process concludes with potential suppliers providing a proposal that outlines their approach to best meet the buyer’s needs.

The result? An RFPartner is better able to help buyers find the best supplier for tailored solutions. To be effective, the nature of the bid processes and the selection criteria for an RFPartner are very different than a conventional RFProposal.

Selection criteria

The transactional nature of an RFProposal makes it easy to compare potential suppliers apples to apples. For example, the selection criteria are based on factors such as technical capability, price, and capacity. The conventional selection criteria are price or lowest price technically acceptable, but the concept of using best-value criteria is growing, which allows buying organizations to factor in selection criteria such as past performance.

When organizations shift to wanting to find a partner with the best possible solution, it’s important to understand the nature of the selection criteria change. With an RFPartner, buyers evaluate suppliers not only based on technical capabilities but also on the best value of the solution. And then there’s the cultural fit with the supplier, which doesn’t mean sameness, but avoids incompatibilities that can create conflict from incongruent management philosophies. For example, do the business partners have a similar view on transparency, or do organizations use a top-down hierarchical approach as opposed to a bottom-up collaborative approach?

Nature of the process

As noted, an RFProposal is best suited when buying standardized goods or services while an RFPartner yields better results when seeking a strategic partner to provide a tailored solution. When making the shift to find a strategic partner with a tailored solution, the nature of the bid processes shift from transactional to collaborative in nature.

For starters, an RFProposal process is typically led by the buying organization’s procurement team and the supplier’s business development team, with the parties focused on buying and selling with a transactional lens. The best practice for an RFPartner process is to create a cross functional deal architect team where a supplier team can work directly with its counterpart from the buyer, which allows the supplier to co-create the best solution for the buyer.

A second difference is the levels of communication and collaboration during the actual bid. A hallmark of an RFPartner process is highly collaborative, in-depth dialogue workshops where the buyer and supplier co-create the best possible solution for the buying organizations. This differs significantly from an RFProposal that generally limits collaboration to Q&A sessions with bidding suppliers.

In addition, when running an RFProposal, the supplier’s questions are almost always shared with other suppliers, and the buyer’s answers are shared with all suppliers to create a level playing field. In contrast, an RFPartner process treats supplier questions as proprietary, and the questions and answers are not shared with other suppliers. The result is that suppliers come to life in the dialogue sessions because they don’t feel they’re sharing trade secrets that will get back to their competitors.

A third difference is in how the contract is negotiated. In an RFProposal, buyers and suppliers often find themselves in tough contract negotiations after the supplier is selected. An RFPartner, on the other hand, integrates the contracting phase into the bid process with the preferred supplier.

Because the tailored solution is so critical to the success of what the buyer is seeking, typically at least a third and up to 80% of the supplier’s deal architect team is part of a stay-behind team to ramp up and operationalize the solution. This prevents the supplier from having their sales team sell a solution that may be a challenge to operationalize.

While buying organizations are leaning into the idea of using an RFPartner approach, many question whether it’s worth the effort. EY’s Magnus Kuchler, markets leader and country managing partner for EY, Sweden, has advised 185 deals using both RFProposal and RFPartner approaches with a range from highly traditional and transactional relationships to true strategic business relationships.

“On the surface, an RFPartner sounds like a heavy lift, but we find that the overall time and effort is about the same,” he says. “In an RFProposal, the buyer is spending more time upfront defining the specs and in contentious negotiations. The RFPartner process flips this on its head and creates a more integrated bid solution that generates better solutions, spending more time together with the supplier co-creating, especially if your aim is making the shift to a highly collaborative vested business model to achieve strategic business outcomes.”

The bottom line

Complex sourcing initiatives demand a more collaborative bidding strategy. If you find yourself in a catch-22 buying a transaction when you need a more nuanced solution or business outcome, consider investing in learning more about how to run an RFPartner. For more information, UT has two white papers and three case studies on the RFPartner approach as part of its research library on collaborative win-win business relationships.


Read More from This Article: Request for proposal vs. request for partner: what works best for you?
Source: News

Category: NewsJuly 8, 2024
Tags: art

Post navigation

PreviousPrevious post:10 ways to prevent shadow AI disasterNextNext post:DHL Supply Chain supera los 500 millones de ‘picks’ gracias a la robótica

Related posts

IA segura y nube híbrida, el binomio perfecto para acelerar la innovación empresarial 
May 23, 2025
How IT and OT are merging: Opportunities and tips
May 23, 2025
The implementation failure still flying under the radar
May 23, 2025
보안 자랑, 잘못하면 소송감?···법률 전문가가 전하는 CISO 커뮤니케이션 원칙 4가지
May 23, 2025
“모델 연결부터 에이전트 관리까지” 확장 가능한 AI 표준을 위한 공개 프로토콜에 기대
May 23, 2025
AWS, 클라우드 리소스 재판매 제동···기업 고객에 미칠 영향은?
May 23, 2025
Recent Posts
  • IA segura y nube híbrida, el binomio perfecto para acelerar la innovación empresarial 
  • How IT and OT are merging: Opportunities and tips
  • The implementation failure still flying under the radar
  • 보안 자랑, 잘못하면 소송감?···법률 전문가가 전하는 CISO 커뮤니케이션 원칙 4가지
  • “모델 연결부터 에이전트 관리까지” 확장 가능한 AI 표준을 위한 공개 프로토콜에 기대
Recent Comments
    Archives
    • May 2025
    • April 2025
    • March 2025
    • February 2025
    • January 2025
    • December 2024
    • November 2024
    • October 2024
    • September 2024
    • August 2024
    • July 2024
    • June 2024
    • May 2024
    • April 2024
    • March 2024
    • February 2024
    • January 2024
    • December 2023
    • November 2023
    • October 2023
    • September 2023
    • August 2023
    • July 2023
    • June 2023
    • May 2023
    • April 2023
    • March 2023
    • February 2023
    • January 2023
    • December 2022
    • November 2022
    • October 2022
    • September 2022
    • August 2022
    • July 2022
    • June 2022
    • May 2022
    • April 2022
    • March 2022
    • February 2022
    • January 2022
    • December 2021
    • November 2021
    • October 2021
    • September 2021
    • August 2021
    • July 2021
    • June 2021
    • May 2021
    • April 2021
    • March 2021
    • February 2021
    • January 2021
    • December 2020
    • November 2020
    • October 2020
    • September 2020
    • August 2020
    • July 2020
    • June 2020
    • May 2020
    • April 2020
    • January 2020
    • December 2019
    • November 2019
    • October 2019
    • September 2019
    • August 2019
    • July 2019
    • June 2019
    • May 2019
    • April 2019
    • March 2019
    • February 2019
    • January 2019
    • December 2018
    • November 2018
    • October 2018
    • September 2018
    • August 2018
    • July 2018
    • June 2018
    • May 2018
    • April 2018
    • March 2018
    • February 2018
    • January 2018
    • December 2017
    • November 2017
    • October 2017
    • September 2017
    • August 2017
    • July 2017
    • June 2017
    • May 2017
    • April 2017
    • March 2017
    • February 2017
    • January 2017
    Categories
    • News
    Meta
    • Log in
    • Entries feed
    • Comments feed
    • WordPress.org
    Tiatra LLC.

    Tiatra, LLC, based in the Washington, DC metropolitan area, proudly serves federal government agencies, organizations that work with the government and other commercial businesses and organizations. Tiatra specializes in a broad range of information technology (IT) development and management services incorporating solid engineering, attention to client needs, and meeting or exceeding any security parameters required. Our small yet innovative company is structured with a full complement of the necessary technical experts, working with hands-on management, to provide a high level of service and competitive pricing for your systems and engineering requirements.

    Find us on:

    FacebookTwitterLinkedin

    Submitclear

    Tiatra, LLC
    Copyright 2016. All rights reserved.