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.

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 differences 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 two parts we addressed the first four pieces of advice and how they have evolved over the years. Today, we continue.

Read the contract

Remember what we’ve been telling you since the beginning.

• There’s no such as a free lunch.
  Free modules? Free support? Free training? Not likely! Either it’s included in the price, is being offered as an enticement to lock you in for a fixed term, it’s being offered in an attempt to divert your attention away from a complex SLA that benefits the vendor and not you, or it’s being offered to distract you from the lack of remuneration when they screw up and cost you time and money.
• Don’t get screwed by the new release (or new functionality).
  As sure as the sun rises in the east, the vendor will come out with a new release, module or offering not long after you’ve bought the current version and expect you to pay a large tranche of money to get (part of) it. You may get offered a small “upgrade” or “new buyer” discount, but you’ll pay, then pay again, and pay again, and again for as long as you own the software. If you’re paying an annual license fee for SaaS, make sure the upgrades are all inclusive.
• Don’t get fooled by the license fee in disguise.
  Many traditional enterprise software platforms have a clause buried deep in the SLA that requires you to pay the annual maintenance fee, or lose the right to use the software altogether even though you have years left on the contract. That’s not a maintenance fee, that’s a license fee. Make sure the maintenance fee is a real maintenance fee for support and bug fixes.
• Don’t get satiated by the presence of an SLA.
  The majority of Service Level Agreements (SLAs) are designed for one purpose — and one purpose only — to give you a false sense of security that will cause you to overlook the fact that the wording insures that the vendor will be able to keep your money for the length of the contract, no matter what. Your average SLA will run for a dozen or more pages with lots of fancy wording around “Level 1” problems, “Level 2” problems, and so on with detailed text spelling out your responsibilities and consequence-free reprieve time for the vendor while you lodge your complaint and fill out the necessary documentation. Unless the SLA allows you to terminate the contract any time the vendor fails to deliver against the SLA, with no penalty, and complete exports, it’s useless.

And then realize that, today, you also have to keep in mind the following:

• Minimum license and maintenance increases tied to inflation are BS.
  Software depreciates with time, it doesn’t appreciate. All code has a limited life-span before it becomes technical debt. Give or take 3-5 years for an average app, 5 to 10 for an enterprise app, with life-spans shrinking all the time. In other words, the code should get cheaper over time unless there is a minimum functionality improvement and minimum service and support levels guaranteed.
• AI Priced Separately … Even When It Should Not Be.
  Some providers are realizing just how costly it’s becoming to run those BS Gen-AI LLMs they built their functionalities on, especially third party ones that have to considerably jack up their token costs over the next couple of years just to break even, and are making you responsible for the third party AI costs. Right now it’s still pretty cheap, so you might look this over, but there are two problems with this. One, if it’s required for the vendor’s product to work, they should be paying for it, not you — that’s what license and maintenance fees are for. Two, letting them pass the buck gives them no incentive to be efficient about their use of AI and could result in your system becoming unaffordable to use in a few years. If the AI is a completely optional plug-in layer, such as a conversational interface to the analytics product that summarizes the dashboard (where you could read the data off the screen yourself, translate it to plain English, and make the pretty powerpoint slide yourself for your mathematically challenged executives), that’s one thing. If the analytics is built on LLMs, that’s a whole other thing — and cost won’t be your only concern.
• Standard limitations of liability don’t work in the AI world.
  You should be responsible for use, but not responsible for any unguarded actions taken by the AI that result in loss, damage, or illegal activity. (After all, most vendors aren’t actually implementing guardrails and just wrapping third party LLMs and claiming they are safe because the third party vendors say they are safe.) But once you give their “AI Employee” the right to auto-buy and auto-pay, that AI Employee can buy illegal drugs on the dark web, send the payment to a terrorist group, and leak your bank details to a scam group. But if you accept the standard verbiage the vendor will give you, you assume all liability for the actions taken by their software. DO NOT!
• Fixed user licenses are a fixed drain on your finances.
  If you have to buy on a user-based license model (and you really should be looking for enterprise), you need the ability to shift licenses around as needed, so that you don’t have unused licenses, as well as the ability to fluctuate in a range. You might have to buy a minimum, but you shouldn’t have to buy 1000 if, at any given time, you will only need 700.
• Data Ownership Clauses
  Suppliers will wholeheartedly agree you own your data, tout that you retain ownership of your data that is yours and yours alone in the sales pitches, and then hide clauses that allows them to use any and all of your data to train any and all of their models and even use it to train third party solutions that will profit off it AND leak it to the world — does that sound like data ownership to you?

Forego the Escrow

Finally, remember that the escrow is pretty useless because you don’t have what it takes to even operate the software, yet alone maintain it. And it’s not something you can just throw on a consultancy because it takes a long time to figure out Million plus line applications and get a team up to speed to maintain them. And it’s significantly more costly than switching to an entirely new application and hiring a data migration team to extract the data from the application about to go offline and feed it into a new application.

That’s why, as we’ve repeatedly said, the most important clause in your (Procure)Tech (SaaS) Contract is the one that allows you to get a complete extract of your data at any time with a single click.

However, in today’s world, that should be a minimum. In order to get up and running again quickly, you don’t just need your data, you need your configurations — the business rules that define your processes, the logic that defines your exception handling, the specific analytics that your users need, and the integration configurations the app relied on. You should be able to get a complete export of all of the rule definitions and logic as well as your data. (Since the AI Hype era has finally brought about the importance of contexts, with the introduction of MCP, you need the context to migrate quickly. The I2O players are adopting MCP, and it will soon be quick and easy to migrate to a new application if you need to if you can export all of your data and rules.

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 Part II we addressed the first two pieces of advice and how they have evolved over the years. Today, we continue.

Chuck the checklist

Better yet, go all Chucky on it. The problem with every checklist every created is that its predominantly features, not functions, and leads you down the wrong path. Checklists should be what to look for in a vendor, what to ensure in a contract, what steps you can’t bypass or forget. Not for a list of features, which never compare one to one, when what you really need is functions.

Furthermore, no piece of software can do everything, and checklists always mix must have with should have with nice to have with that would be cool (but totally useless when you think about it), which is rarely done by anyone when you ask them what features they need in a solution). Plus, we know you’re going to jump start your list using BS Gen AI which is going to regurgitate features common to multiple Free RFPs, Trade Rags and Big Analyst Firm lists, which aren’t very good (and that’s why SI has warned you about all of these before).

What you need is a description of the functions that are required to satisfy your process requirements (you mapped those first, right?), user case descriptions that describe how the software will be used and/or needs to be employed, and what the end results need to be. Not a checklist.

Wait for the blush to leave the rose

Although the testimonials and references, from clients who have recently implemented the product, that the vendor brings you, will be sincere, they will also usually be useless. Why?

1. New customers are highly motivated to say the software is great.
   Saying otherwise is paramount to saying they screwed up, and that wouldn’t go over vey well with their management. So even if the software wasn’t working as they expected, they wouldn’t admit to it.
2. Almost all solutions are better than no solution at all.
   So everything looks great when you’ve never had, or even seen, anything else.
3. New customers haven’t experienced what happens when something major goes wrong.
   Something will. It might be their fault, the vendor’s fault, or the fault of a third party like the implementer, the cloud provider, or the AI provider. It’s how the vendor steps up and (helps to) fix(es) it that counts. A reference that will tell you something went horribly wrong but the vendor immediately jumped in, worked evenings and weekends, and made it right is worth way more than a reference who just says its great. Because such a provider would have also done a post mortem, figured out what went wrong, and what they can do to minimize the chance that it happens again (be it better customer training, specific checks in their vendor oversight, real-time monitoring of third party integrations, etc.).

You might have to go out and track down those customers (and references) yourself, but do that if you really want to evaluate the vendor properly.

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. Yesterday we over-viewed 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. Starting today, we address the major points and what you look for.

Don’t Get Blind-Sided

There are two primary ways you’re going to get blind-sided with tech acquisitions in a modern Procurement organization. The first is still as it was 17 years ago — IT. In many organizations, IT still has too much power over software acquisition. Where the software is cross-department and enterprise core, it should have a considerable say, but for department/function specific apps or apps that sit on top of the core platforms, IT’s influence should be limited. But in organizations where IT still has too much sway, when IT decides it doesn’t like one of your choices, it can step in and, in a very public way say “we already have a product that can do that with extra licenses (and we just need to add one module)” or “it won’t work with our infrastructure, but this other product we’ve been looking at will” and, even if both of their suggestions definitely won’t do what you need them to do from a functionality requirement, it doesn’t matter, the damage is done, your selection (which might have undergone months of research and negotiation) is dead and it will be all you can do to prevent the bad choice from being mandated by the COO or CFO.

As we said before, this does happen but can often be easily prevented simply by taking the time to get IT on board before you present your suggestion and, preferably, before you even make the final selection. Find out day one any absolute and desired requirements they have, incorporate those that are truly absolute and relevant into your RFP, and be sure to convince IT up front that your process addresses your needs and theirs. Then get IT on board with the selection before going to the C-Suite.

Speaking of the C-Suite, this is the second primary way you’re likely to get blindsided. In the age of AI Hype, when every CXO is being convinced that, if they don’t have AI they’re going to fall behind, chances are they’re going to have their favourite overpriced Big X consultancy make a provider recommendation for whatever tech they think you need and then tell you after they’ve signed the deal that provider X with BS “AI” product Y is your new solution, and you better make it work because they just blew the software budget for the next 3 years.

This will generally be last generation junk with a bit of automation being sold as next gen AI or a hallucinatory Gen-AI LLM in a shiny wrapper with no real, solid, functionality, and neither will solve your problem.

The only way you can prevent this is to ensure you’re on top of all the major C-level consulting engagements and their purpose. That Procurement is seen as central in all services and consulting as a knowledgeable provider that can not only select the right Big X partner (event though the CXO’s favourite provider often isn’t the right one, you will never convince a CXO with a predetermined mindset otherwise) but ensure the organization gets the best deal possible. That Procurement should be kept apprised to ensure the invoices are accurate and the services delivered. That way you can understand what they’re looking for and monitor how the engagements are evolving, and once you see that the goal is to identify a product or service that will impact, or, even worse, be forced upon, Procurement, you can start educating the C suite as to what a true solution is, what the organization really needs, and how to weed out the charlatan solution providers from the real ones. You may still get stuck with a sub-optimal solution, because the C-Suite will insist on a big-name vendor with “AI” inside, but at least you’ll get one that at least partially solves the problem you have.

Watch Out for the Big Lies

Traditionally, the big lie was that many software vendor sales reps would lie and say “yes, we have that capability” when asked if their software could do something specific even if it couldn’t because, if asked to demonstrate it, they could say “it’s in beta and we can demo it next time ” (and assume their team could get it done, or at least enough fakery done, to convince you, by the next demo).

But now we have a new lie — and it’s the biggest lie of all. AI (or AGI) exists, it can do whatever you need it to, and its your new employee. And CEOs, supposed to be brilliant leaders, are falling for this BS left, right, and center. There’s no AI, Gen-AI hallucinates unpredictably on a regular basis, and it’s just as likely to bankrupt your business on a single buy than save you $1. As Joël Collin-Demers stated in his AI post (linked in this post), vendors with real AI (where AI stands for Augmented Intelligence, as that’s the best you can get)
tell you exactly what they do, in which sequence [to employ it], and [help you] understand how it solves your exact problem. They don’t sell just on AI hype, they show actual solutions.

There’s a reason I’ve advised you repeatedly to ban “AI” from your RFP responses and kick out any vendor that leads with AI, and that’s because those vendors are mostly, if not only, selling BS.