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.

SI has been giving you best practice advice on acquiring software to solve your extended sourcing and procurement (related) needs since the beginning, with deep dives into every major technology you might need, and deep exposes on (fake) tech that didn’t work.

However, it’s first major series on generic insider tips on software acquisition was back in 2009 when it published a seven-part series on the seven-shards of software acquisition that gave you a lot of advice that more-or-less still stands today. In a nutshell that advice was:

• don’t get blindsided by IT
• watch out for the big lie
• chuck the checklist
• wait for the blush to leave the rose
• read the contract
• forego the escrow
• draft a real unbiased RFP
• … streamlined for performance, not wokeness
• separate software from service
• monitor the market
• skip the mind games

And it more or less stands today. The main differences are where the sideswipes come from, what the big lie is, what you have to look for in the contract, what you really need in place of the escrow, how software and services are blurring in new ways, and what to look for in the market. The rest remains the same. So to ensure you know what to look for and that you continue to get the best deals on your software (because, regardless of what new fangled terms are used to describe it, or the delivery mechanisms, it’s all still software), we’re going to revisit these series and make the necessary updates.