This originally published June 29 (2024) and is being reprinted due to how important it is to remember as you enter a new budgetary year and seek out new technology.

This shouldn’t have to be said (again), but apparently it does since Zip has relaunched the FREE RFP madness in Source-to-Pay (that began in 2006 when Procuri first aggressively launched the Sourcing, Supplier Management, Contract Management, and Spend Analysis RFPs) with an RFP that is intake heavy, orchestrate light, process deficient, and, like many RFPs before, completely misses some of the key points when going to market for a technology solution. (Especially since there isn’t a single FREE RFP template from a vendor that isn’t intrinsically weighted towards the vendor’s solution, as it’s always written from the viewpoint of what the vendor believes is important.)

the doctor has extensively written about RFPs and the RFP process here on SI in the past, but, at a high level, a good RFP specifies:

• your current state,
  it does NOT leave this out leaving the vendor to guess your technical and process maturity
• what you need the solution to do
  NOT just a list of feature/functions
• what ecosystem you need the solution to work in
  NOT just a list of protocols or APIs that must be supported
• where the data will live
  and, if in the solution, how you will access it (for free) for exports and off-(vendor-)site backups, do NOT leave this out
• what support you need from the vendor
  NOT just whether the vendor offers integration / implementation services and their hourly / project rate
• any specific services you would like from the vendor
  NOT a list of all services you might want to buy someday
• what the precise scope of the RFP is if it is part of a larger project
  NOT a blanket request for the vendor to “address what they can”
• what regulations and laws you are subject to that the vendor must support
  NOT just an extensive list of every standard and protocol you can think of
• what languages and geographies and time zones you need supported
• any additional requirements the vendor will need to adhere to based on the regulations you or the vendor would be subject to and additional requirements your organization puts in place
  NOT endless forms of every question you can think of that might never be relevant
• your goal state,
  it does NOT leave the vendor to guess what you are looking for (note that “goal” defines what you want to achieve, it is up to the vendor to define how they will help you achieve it)
• what (management) processes you use to work with vendors — and —
• what collaboration tools you make available to vendors and what your expectations are of them

And it is only created after a current state assessment, goal state specification, and key use-case identification so that it is relatively clear on organization needs and vendors have no excuse to provide a poor response.

Furthermore, a good RFP does NOT contain:

• requests for features/functions you don’t currently need (but you can ask for a roadmap)
• specific requests for a certain type of AI/ML/Analytics/Optimization/etc. when you don’t even know what that tech actually does — let the vendor tell you, and then show you, how their tech solves their problem
  (after all, there are almost NO valid uses for Gen-AI in S2P)
• specific requests on the technology stack, when it doesn’t matter if they use Java or Ruby, host on AWS or Azure, etc.
• requests for audits (tech, environmental, social welfare, etc.) when you haven’t selected the vendor for an award, pending a successful negotiation
• requests for service professional resumes when you haven’t selected the vendor for an award that includes professional service, pending a successful negotiation
• requests for financials, when you haven’t selected the vendor for an award pending a successful negotiation
  (because these last three [3] will scare some vendors off and possibly prevent the best vendor for you from even acknowledging your RFP exists)

And, a good RFP, goes to the right providers! This means that you need to select providers with the right type of solution you need before you issue the RFP, and then only issue to providers that you know offer that type of solution. (You can use analyst reports here if you like to identify potential vendors, but remember these maps cannot be used for solution selection! You will then need to do some basic research to make sure the vendor appears to fit the criteria.)

And if there are a lot of potential providers, you may need to do a RFI — Request for Interest / Intent (to Bid) — where you specify at a high level what the RFP you intend to issue is for, and if you get a lot of positive responses, do an initial call with the providers to confirm not only interest but the solution offered is relevant to your organization. (After all, at the end of the day, as The Revelator is quick to point out, it’s as much about the people behind the technology as the technology itself if you expect to be served by the provider.)

And even if you don’t need to an RFI before the RFP, you should still reach out to the vendors you want to respond, let them know the RFP is coming, and let them know you’ve done your research, believe they are one of the top 5 vendors, and are looking forward to their response. (Otherwise, you might find you don’t get as many responses as you’d hope for as vendors prioritize RFPs that they believe they have a good shot at winning vs. random unexpected RFP requests from unknown companies.)

At the end of the day, if you don’t know:

• what the main categories of S2P+ solutions are
• what the typical capabilities of a solution type are, what’s below, average or above
• who the vendors are
• how to determine your current state of process maturity (and how that compares to the industry, market, and best-in-class) and what a solution could do for you
• how to evaluate a vendor’s solution
• how to evaluate a vendor overall
• how to write a good RFP that balances core business, tech, and solution requirements to maximize your chances of finding a good vendor for you

and the reality is that you most likely don’t (as less than 10% of Procurement departments are world class, as per Hackett research going back to the 2000s where they also determined the typical journey for an organization to become best-in-class in Procurement was 8 years, and that’s the minimum requirement to write a world-class technology RFP), then you should engage help from an expert to help you craft that RFP, be it an independent consultant or firm that specializes in Procurement transformation.

It is also critically important that the firm you select to help you needs to be neutral (not aligned with one solution provider who refers implementations to them in return for potential customer referrals) and that the firm does not rely on analyst maps either!

If you want help, the doctor has relationships with leading, neutral, firms on both sides of the pond who can help you, and who he will work with to make sure the technology / solution component is precisely what you need to get the right responses from vendors. Simply contact the doctor (at) sourcinginnovation [dot] com if you would like help getting it right.

Simply put, getting help with your technology RFP is the best insurance money you can spend. When you considering that, all in, these solutions will cost seven (7) or eight (8) figures over just a few years, you should be willing to spend 5% to 10% of the initial contract value to make sure you get it right. (Especially when there isn’t a single Private Equity Firm that wouldn’t invest in a technology player without doing a six [6], if not seven [7] figure due diligence first … and sometimes the firm will do this and then walk away! At least in your case, when you work with someone who can identify multiple potential vendors, you’re certain to find one at the end of the day.)