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.