It’s been 17 years since SI published its first major series on generic insider tips back in 2009 where we gave you a lot of advice that more-or-less still stands today if you want to safely acquire software. In our preamble, we overviewed what those 11 pieces of advice were then, and summarized the 6 major difference that affect how you apply that advice today so you can continue to make the right decisions when acquiring software in the age of AI Hype and exaggerated I2O claims. In the last three parts we addressed the first six pieces of advice and how they have evolved over the years. Today, we continue.

Draft a real unbiased RFP

Properly Define the Scope

This was the first tip we gave you 17 years ago, and the first tip we repeat today. As per our Successful Vendor Selection Series, solution selection is a 7 step methodology, and the vendor assessment process, which contains the RFP process as a subprocess, is step 5. That’s because you can’t properly define the scope until you:

1. identify what your real need is
2. holistically identify what a solution needs to do
3. determine your organizational maturity (and the complexity of a solution you can actually support)

Only then can you define the scope and begin to construct a good RFP.

Focus on Functions and Requirements, Not Features

What does it have to do? Why? What processes is it supporting? What user groups? What are their primary and secondary use cases? What level of configuration do you need? What integration does the system need to support.

And definitely don’t use a “FREE RFP”. Those are all vendor generated and vendor sponsored (even if being offered by an “independent” third party) and designed to make one specific vendor look good against peers (and focus on the features they have, not necessarily the features you need). Always have been (since Procuri sponsored the FreeRFP site for Procurement 20 years ago that got them enough attention to be acquired by Ariba). Besides, most applications will be stuffed with features you don’t need and never use. How many (Microsoft) Word features do you use regularly? 30? Maybe 50 if you’re a “power” user. How many features does (Microsoft) Word have? Ten times that (and maybe more). It’s the same with enterprise apps … especially from providers that aren’t providing anything differentiated or actually improving on the core offering and core value … lots of features, few functions, and fewer still that provide value.

Draft the RFP BEFORE You Look at Any Solutions

Or any vendor material — it’s all marketing propaganda anyway! Otherwise, you will be tempted to write the RFP using the terminology and viewpoint biased by the vendors you researched / liked the most from their public marketing and demo materials. This will give them an unfair advantage, that they will take full advantage of, and that can prevent you from getting the right solution.

DRAFT THE RFP BY HAND

DO NOT USE GEN-AI! Sure it can whip up a good sounding 20 page RFP in 20 seconds on a powerful enough server, but sounding good (because it’s grammar and vocabulary is better and bigger than yours) is not being good. It can leave out key requirements. Forget critical specifications. For standards, get the requirements wrong. For integrations, get the versions and extent of requirements wrong. For services, get mandatory SLAs wrong. And so on. Good RFPs are drafted by hand. You can use semantic AI tools to improve the grammar and spelling, and then use Gen-AI to make suggestions as to where you want more detail, clarity, etc, but good RFPs are drafted by hand! (Now, this is for software acquisition and strategic purchases. For tactical commodity tail-spend where it’s just a puffed up RFQ, it’s not as critical you start by hand.)

Define ALL Of Your Evaluation Criteria Before You Send It Out

As well as any core requirements for the vendor / platform that can’t be waived. If there are a number, do a quick up-front RFI where you collect all the financial, legal, compliance, platform, and core function requirements and then don’t even bother sending the RFP to any vendors who don’t make the cut. If the RFI eliminates too many, determine which requirements are really absolute vs. which are strongly recommended (and weighted highly) in the evaluation.

You need to know what you’re looking for and how you are evaluating BEFORE you read the first word of any vendor response.

… as Well As Your Metrics for Measuring Implementation and Adoption Success

A successful implementation is not one where the vendor creates a new instance, connects to your ERP, and sucks in the data. A successful implementation is one that is adopted, utilized, and generates a return on the chosen metrics. That’s why the last step of the seven step process is post-implementation monitoring, advisory, and training. Until you reach the target metrics, the implementation, and vendor, ain’t done. So your prospects need to know up front what’s expected of them, what is required in the SLA, how they will be measured, and what milestones they need to meet.

… streamlined for performance, not wokeness

An RFP defines your solution requirements, not your organizational philosophy. Furthermore, the best vendor could be headquartered half a world away and their operational requirements and societal expectations could be completely different from yours. Plus, your personal preferences in terms of staffing are yours, not theirs, and you should not try to enforce it … especially when doing so could be illegal in your home country or theirs. If you want the best solution, you need to let them do what they need to do to hire the best people for the job. All you can specify is any laws and regulations you are subject to and what your CSR philosophy is. Let the vendor fill in the blanks beyond any absolutes.