• The Terms Have Changed But The Song Remains the Same
• Part II
• Part III
• Part IV
• Part V
• Part VI

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

Separate software from service

Seventeen years ago we wrote:

Many software products aren’t really software products at all. In other words, there is some incantation that has to be performed by the software vendor, in the form of services, configuration, or other magic, on a regular basis, to keep the software running. In this case, you haven’t bought software, you’ve bought software plus services. What’s even worse is that you’ve single-sourced it. If the vendor goes broke, or can’t deliver, you have no options.

This is still a reality with many products, and, even worse, in the age of AI-based “agentic” offerings, they only keep working if the vendor is constantly monitoring, maintaining, upgrading, retraining, correcting exceptions and errors behind the scenes that you don’t see, etc. There’s more hidden services than ever. That, combined with the escalating token costs, is why they have to sell you on “outcomes” because they can’t charge SaaS fees and survive. (And that’s why outcomes is a dirty word. Just remember freedom of speech means that they can say anything they want, even if it’s not true, but that you have the right to ascertain the truth and demand that word never be used again in their RFP responses! [As well as “AI”.])

Good software is very affordable today. If it’s too expensive, it’s either relying too much on experimental AI that doesn’t work, stuffed full of features you don’t need, or hiding services behind the scenes you don’t want to be paying for.

Monitor the market

This isn’t 20 years ago where there were very few price benchmarks beyond what you could collect from an RFP and a few general price ranges from your favourite consulting firm that were wider than an average football field, this is now where there are dozens of platforms that monitor SaaS spending and a few big consultancies that specialize in not only monitoring and pricing how low a vendor will go, but breaking apart their combined bids into individual SKUS because they have hundreds of data points to compare against as they have been collecting that data for years as they negotiated on behalf of their clients. If you do the research, you should know exactly how much each vendor will charge, on average, for the solution you are looking at for an organization of your size, what the price trends are, when they make the best deals, and what the best pressure points are. If you don’t, you shouldn’t be making major 6, 7, and even 8 (when you consider lifetime) figure software acquisitions. Period. Market monitoring is a must!

Skip the mind games

Abruptly end a meeting mid-stream to make a point? Make the salesman sweat at quarter-end to squeeze a few extra discount points? Scream emotionally that they are price gouging and you’re going to not only report them to the Better Business Bureau but tell all your friends in the local Procurement Association? Threaten to use Klod or Chat J’ai Pété to build it yourself? Lie and say you can make do with your current system for another quarter if you can’t come to a deal or just select any random competitor at DPW?

Sure you could use these techniques to try to get a better deal using an antagonistic wild west negotiation philosophy, but at the end of the day, it will cost you more than you save because even if the rep caves (because the rep knows if he doesn’t close something, he’s the next rep walked out the door by the investors to make a point), how incentivized is the rep, and the vendor as a whole, going to be in helping you to succeed? Especially if their profit margin is close to 0 in a best case situation? Answer: not very. They will do the absolute minimum to meet their contractual requirement, and then take the phone off the hook, tell the chatbot AI to infinitely loop you when you try to contact support, and, when there is an actual bug, make sure you are last in the queue to get serviced, waiting until the last minute of the SLA to do it

Focus on the value you are getting, a price point based on real market data and intelligence that they should be able to match (and make a fair margin while actively supporting you to meet the ROI metrics they promise), and delayed payments until the module is actually live and users actually onboarded before you start paying for it. (In other words, if you buy six modules, but only two are available day one, two more won’t be available for 90 days, and two more for 180 days, you don’t pay the full license fee until all modules are live AND all users set up. And implementation/integration payments are tied to milestone completion.) That’s way more effective.

Now, as always, there are a lot more tips and advice we could give, but these are the biggies. If you want more details, dig deep in the archives. Or, you can contact <font=black>the doctor for an engagement.

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.