Category Archives: SaaS

Assisted Solution Selection is a Seven Stair Methodology

… and skipping any step breaks the strands that are necessary for success.

And the process is a lot more involved than most consultants or analysts believe it is. But first, let’s outline the steps the consultant or analyst has to walk through if they want to reverse the odds and give you an 80% chance of success vs. an 80% chance of failure.

1. Real Need Identification

We’ve all forgotten the wisdom of Richards and Jaggaer, and the realities of life. You Can’t Always Get What You Want but if you try sometimes you just might find that you get what you need. But you have to try. And so does any consultant or analyst who purports their desire to help you.

2. Holistic Solution Requirement Assessment

This is NOT technology. Not even close. This is identifying what results would define a solution, what processes would get you there, and what resources — people AND technology — are needed to get there.

3. Organizational Maturity

The solution has to be appropriate for the organizational, and technical, maturity of the organization. If someone has only ever ridden a horse to get from point A to point B, you can’t drop them in a Boeing 737 cockpit during mid-flight and say “good luck”. But that’s what happens in the vast majority of technology solution identifications and implementations — an organization running off of email, spreadsheets, and word documents is being told to upgrade to a modern best-of-breed AI-orchestrated source-to-settle platform with advanced optimization models, multi-stage analytics, twelve-step supplier onboarding and evaluation, 360 risk and compliance, multi-channel procurement, AI powered payments, and features with no apparent use. The solution has to be matched to the organizational capabilities with an future upgrade plan consistent with the rate the organization should be capable of maturing.

4. Vendor Pool Selection

The vendor pool has to be a set of vendors that meet all of the core requirements identified in the holistic solution requirement assessment, in a manner appropriate for the client’s organizational maturity. Clients should NEVER have to evaluate whether a vendor meets the core requirements, but how it meets the requirements; what should, nice-to, and value-add functions are included in their offering; and how they can effectively be a partner, and not just a provider, to your organization.

5. Vendor Assessment Process

A seven step process that centers the RFP and helps the client make the right selection.

6. Project Assurance

Processes that stop at the selection of the vendor can cut the chances of success in half. Implementors don’t understand how the conclusion was reached, vendors don’t understand the client’s unique situation, and neither are incentivized to ensure success. Independent, unbiased, project assurance is key.

7. Post Implementation Monitoring, Advisory, and Training

A successful implementation does not guarantee success — that requires adoption, continued utilization, and results. That might require training, that might require ongoing support, that might require additional advisory. There’s no success until an ROI is achieved.

Moreover, each of these steps needs to be powered by an appropriate model and methodology that is standardized, domain appropriate, and continually enhanced by firm knowledge and best practice. Not just a seat of your pants assessment entirely dependent on the individual’s knowledge and experience.

Furthermore, each of the models and methods used in each step has to build on the outputs of the models and methods of the last step so that each implementation requirement can be traced all the way back to a need and each need can be traced all the way forward to an implementation requirement. If you can’t trace complete “strands” from end-to-end, you can’t expect success.

Most Consultants and Analysts Don’t Help You Select Solutions — Just Tech that Benefits Their Partners and Vendor Clients

It might not be the intent of the consultant or analyst who truly wants to help you, but this is what happens the vast majority of the time (and contributes to the 88% tech failure rate and 94% Gen-AI failure rate). There are a number of reasons for this.

From the consultancy side of the equation:

* Most Consultants are told to please clients and give the clients what they want.

The problem here is that clients don’t know what they want, because they don’t understand what they need. So when the client reps are asked they try to sound informed and recite long feature lists they believe that they are supposed to need based upon the most prevalent vendor marketing. The problem is that each of the client’s reps who are interviewed have different long feature lists that only partially overlap and when the consultants are done gathering requirements from the client, they have 500 feature requirements that result in a 600 question RFP that is totally meaningless as it’s functions, not features, that support processes, not tasks.

* Most Consultants are NOT experts on the tech or what’s available in the market.

When a consultancy is also an implementor and has vendor partnerships, their technology and market viewpoint is biased towards those vendors. There are two reasons for this:

  1. that is what their consultancy spends the majority of their time supporting, so they don’t have wide experience (and they aren’t encouraged to get it)
  2. they need to sell a certain amount of vendor partner products to maintain their gold/platinum/diamond standing, which means they are heavily incentivized to see one of their partner’s products as a solution to every problem

* Most Consultants usually start with the understanding of the problem you bring them without validating it’s the right one.

The only way to truly understand a client’s need is to start by undertaking a collaborative needs assessment based on a collaborative working session designed to get at the root issues the client is having, what processes they need, and where a technology-based solution should fit in the process. Without the right understanding of the core problem, the core processes required, and what type of solution they should be looking at — and why, the consultant is not going to ask the right questions, understand the reason for the “requirements” the client reps are bringing, and differentiate the requests on the right track (which need focussing) and the requests on the wrong track. This is one of the reasons we see so many RFPs with 500+ feature questions, because the clients don’t really understand the critical functions the client needs that should be focussed on.

From the analyst side of the equation:

* Most Analysts spend the majority of their time on the firm’s paying clients

They get minimal time with any non-clients, thanks to the sales gatekeepers who scare everyone away with the five to six figure sales pitches (that guarantee analyst time, research access, and at least one write-up which may or may not be behind a paywall) and thanks to their super busy schedule jam packed with “advisory” calls which usually boil down to “how good is this pricing or contract” or “which of the vendors on your map is best” and not “how do we go about identifying the right vendor with the right solution for us, which might not be on ANY of your maps”.

* Most Analysts base their recommendations off of where the vendor lands in a map, which is a flawed process

The big analyst firms produce quadrant maps that plot a vendor on two axes where one axis is something like “completeness of vision” or “strategy” and the other is “ability to execute” or “current offering”, where these axis are usually defined based on the mash-up of six to twelve scores where the majority are completely subjective on the part of the analyst scoring them. As a result, with the exception of the one analyst who took the vendor demos and did the review, they don’t really have any solid idea of why one vendor is really better than another, or where the biggest differences are. But most importantly, they have no insight into whether the vendor’s offering is best for you based on your needs because they not only have very limited ability to focus in on the dimensions of relevance to you, but very little depth in those dimensions to match to your specific needs.

Since the majority of consultants and analysts work at mid-size or larger Big X firms that have a lot of existing partnerships and vendor clients, that’s why you rarely get a good recommendation from a consultant or analyst, and why you end up being another casualty in the 88% failure rate (or the 94% failure rate if the recommendation involved Gen-AI).

The only real way to have a good chance of getting a good recommendation is to go with an independent consultant or small firm that has no vendor partnerships, no rigid maps, and no incentive to recommend one vendor over another. Because then there is no bias.

However, since you’re astute, you know this is only a baseline requirement. In addition to being independent (1), you also need a consultant and/or analyst with expertise and experience in the domain and the vendor landscape (2), and the knowledge of what process to follow and what questions to ask (3).

If you do a little bit of research (using your brain, not Gen-AI computed recommendations), you can easily find a lot of good consultants who satisfy the first and second requirements. The third requirement is the hard requirement to meet. Why? Most consultants don’t have a model and process backed methodology to do these types of engagements and rely entirely on past projects, so if your project isn’t similar to one they’ve done before, while they will truly be doing their best, they may not hit all the right points, especially if time (or budget) is tight. Your success is 100% dependent on their past experience, and you really have to vet well.

But if you can find a consultant or analyst who is backed up by a model-backed methodology with the right experience, your chances of success will flip from 12% to 88%, especially if that consultant also does project assurance. Because such a consultant or analyst, not biased to any solution, will use all of the knowledge and best practices learned by the firm in past projects (that were encoded into the model and methodology), greatly increasing the chance of a right recommendation for you. While success can NEVER be guaranteed (unlike failure), the chances can be exponentially increased. And that’s how you succeed in the real world in technology-based solution selection.

Rapid Fire Vendor Elimination

Last week, as part 4 of our “MOST Important Clause in Your (Procure) Tech (SaaS) Contract series, we noted that you wanted to know how do I select a vendor NOT likely to screw me over and that this wasn’t easy. There’s no hard and fast rule, and things can go away with even the best of vendors with the best of intentions.

That being said, you can certainly weed out vendors with a high probability of screwing you over in the future, whether they had any intention of doing so or not, because a vendor that is not financially stable is one that will struggle to maintain service levels and possibly even to remain in business.

Moreover, we told you that the best way to gauge financial stability was the relative corporate debt formula, provided you used the right version — one version for PE/VC/investor-backed companies and one for fully private/public companies. Companies with a ratio less than one (< 1) were a risk, and the lower the score the higher the risk. (For example, if the formula came out to 0.5, run for the hills. If you’re risk averse, don’t even consider any vendors with a score less than 0.9.)

We then posted a summary on LinkedIn for feedback, and some people pointed out that the biggest risk in their view is cybersecurity. And it is, for a stable vendor you’ve selected to run your systems or host your data. But the fact that sometimes other risks can be bigger for the organization was not the point.

The point of the article was that you can spend months verifying a vendor’s solution only to have the vendor disqualified in minutes when Risk Management runs a quick financial analysis, and takes you back to square one — and that you should do a baseline financial stability analysis first before investing too much time qualifying the vendor’s solution.

In fact, you should run a slew of basic analyses and tests that would eliminate the vendor before spending too much time evaluating vendor fit where each of those basic analyses only takes a few minutes. You should only do a deep dive where there is a high probability that the vendor won’t be eliminated due to organization risk and compliance requirements.

In other words, before going through your full evaluation process, checklists, form-fit deep dives into products and services, make sure there’s no obvious gotchas that would invalidate all your effort. And yes, this means you that, on paper, you will be doing some analyses twice (because financial viability, cybersecurity, certifications, etc. will show up twice in the evaluation process, but it’s not like you’ll be repeating the work, it will be you’re diving deeper into key areas once you know the effort is worth it, because you don’t do a full security analysis on a vendor you wouldn’t select, as it can be a time-consuming and costly endeavour in some industries, but you do ensure they have all the basics in place [SOC 2, PCI DSS for payment providers, HIPAA for healthcare platform providers, etc.] before you invest anytime qualifying their product or services).

So you need a rapid-fire elimination checklist before you go too deep in vendor evaluations. It will be different for each company depending on their industry, geography, and risk profile, but it must include high level checks for:

  • financial viability – the relative corporate debt ratio and the absolute minimum the company will accept
  • cybersecurity – SOC 1 or 2 and any technical industry certifications required
  • cloud requirements – is the cloud/stack acceptable to your tech organization (if you need it to be hosted in certain jurisdictions, you might be limited in providers)
  • API/Integration – is it sufficient for the ecosystem you need the application to integrate with
  • certifications – if there are any specific certifications your industry requires, does the vendor have them
  • connected party checks – are any owners or investors restricted, denied, sanctioned, or in legal jeopardy
  • insurance – if you require a certain (liability) insurance level, does the vendor carry it
  • budgetary window verification – including license & annual maintenance, implementation, and integrations

Now, this is not a complete list, but it’s solid starting list for many companies of requirements that can be quickly checked which could instantly eliminate a vendor from consideration if not met.

Furthermore, it’s pretty easy to augment this to a relatively complete “rapid fire elimination” checklist for your company if you simply

  1. analyze each vendor selection requirement criteria employed by each stakeholder and department
  2. extract those that result in a no-go that can be verified in a few minutes

Completing this checklist is an effort that pays for itself on the next evaluation as it will save months of effort determining detailed vendor fit only to realize during the final extra-departmental checks that a rule is violated they just won’t accept.

Jeez. How do I select a vendor NOT likely to screw me over? (Calculating Relative Corpoate Debt [RCD])

i.e. The MOST Important Clause in Your (Procure) Tech (SaaS) Contract (Part IV)

We know what you’re thinking.

After reading your three-part exposé (group) on the most important clause in your (Procure) Tech (SaaS) contract, I’m pretty sure I’m going to be screwed to some extent on a significant number of my SaaS contracts. How can I minimize the chances of this happening?

Do your diligence and limit your pool to vendors with the right vendor profile.

This means you have to go beyond a deep analysis of:

  • the product, and does it do what you need
  • the platform, and will it support growth
  • the services capability, and can they implement and integrate the system without resorting to third parties
  • the consulting/training capability, and can they provide basic help when you need it

which is where most people stop. And then you have to go beyond Legal and Risk Management’s staples of

  • legal status
  • financial stability
  • legal jeopardy
  • brand sentiment

because that’s not enough either! All that does is tell you the likelihood of being screwed over today, it does nothing to tell you the likelihood of being screwed in the next 6 months, 18 months, or 3 (to 5) years, which will be typical contract duration for a SaaS app of moderate complexity and significant importance.

So how do you figure that out? Well, there’s no golden rule or single predictor guaranteed to always work, as anything can happen to the best and worst of companies over time, but there is one highly correlated factor to SaaS company success you need to compute because, when it’s low, chances of crisis (that lead to your company getting screwed) are high.

What is that factor?

Relative Corporate Debt*

In a (PE/VC/etc.) investor funded company, where msi = “months since investment”, this is defined as:


1.4^((60-msi)/12) * revenue
————————————
investment valuation

In a private company, this is defined as:


annual revenue
———————
annual operating cost
 

If this is less than 1, you’re taking a risk!

In the second case, for a private company that isn’t yet profitable, unless you can plot a trend line over the past year and a half on a quarterly basis that sees the vendor reaching profitability within a year and a half, you’re taking a big risk as loans and founder savings tend to only take a company so far. (And if the ratio is greater than 1, the company is stable and has a good chance of staying that way if it has a solid solution that improves annually.)

In the first case of an investor funded company, you need to understand that a provider that just raised 7, 10, 15X its current annual revenue is not a guaranteed winner. In fact, it’s not even guaranteed to be stable in the long term! One needs to remember that most investors expect a return within 5 years, and many of the bigger firms will expect a return within 3 years (and will slash operating expenses, i.e. headcount, to get it, especially if they bought it to flip it to a bigger investor down the line). This means that the investors who invested amounts at these ridiculous valuations are hoping it’s the next unicorn and expecting exponential growth.

But exponential growth is very hard to obtain!

First of all, exponential growth either requires creating a whole new market, which takes time, or displacing a lot of established competitors, which also takes time … especially if the majority of customers are still locked into those competitors for years. In the first case, it also requires businesses creating whole new budgets and then taking money away from other functions, which takes time. Plus, in both cases, it requires the company to create a broad and deep platform capable of displacing mature providers who might have spent a decade or more on their products, and that also takes time. Just like 9 women cannot have a baby in 1 month, there is a limit as to how fast even the best teams can create broad and deep software that is better than the last generation, scalable, secure, and reliable. (Given that [almost] half [or more] of AI code has been found to contain [significant] security flaws in multiple studies, AI code is not going to accelerate development as much as the AI players want you to believe. Sometimes it slows things down!)

Moreover, even once the market is ready (as a result of existing contracts expiring, millions of dollars spent on marketing to normalize the new player, millions more on development that might be enough to displace customers where the existing solution was bloatware), there is not only the resistance to change to overcome, but the reality that a provider can only take on so many customers so fast and support them adequately.

Despite what the investors want to believe, and what the C-Suite might promise, most back-office installs aren’t just “flipping a switch” and require a lot of time and effort by the provider to load data, integrate with the key back-end systems, configure the systems to the client’s needs, train the client’s personnel, monitor the system and usage during the first few months to make sure everything goes according to plan, etc. That means a provider can only handle so many new customers a month. Moreover, you can’t just add people at will to handle support needs because those support people will need to be trained and that will also require time from existing personnel, which will then have less time to support the clients.

The harsh reality is that, in IT and SaaS, most companies CANNOT grow at more than 40% year-over-year and maintain aggressive platform growth and leading customer support. Any growth beyond that leads to development slowdowns, significant interruptions (to complete failures) in customer support, and other missteps.

Doing the MATH, this means that a company can’t realistically grow more than 5X in 5 years without making some sacrifices along the way, which, in IT/SaaS, typically means SACRIFICING YOU! And that’s what the formula captures! Realistic growth expectations against current revenue and whether it will hit investor expectations in time!

So this means that if the provider accepts funding at a valuation that is significantly more than 5X, their chances of meeting the investor expectations are not good (unless, of course, they significantly raise prices on the renewal, which will also screw you), and that means your chances of great support will steadily decrease as time goes on and your chances of being one of the customers that eventually gets screwed (even if there was no ill intent or false promises when they signed you) increases.

Moreover, if the provider accepts funding at a valuation of more than 7X, their chances of meeting the investor expectations are really (really) bad. If they can more-or-less double functionality and increase the average annual sale price by about 50% within a year or so, then they can make 7X, but beyond that, there’s usually no way to make the math work in a manner that can be expected to satisfy the investors!

So do the math first. If the investment multiple is too high, or the company too far from profitability, it doesn’t matter how good it, or the solution, looks. If you want stability in your purchase, you need to walk away. If the situation changes in a couple of years, there’s no reason you can’t look at them again if the provider you go with ends up not doing everything you wanted. After all, if you ensured the contract had the IT’S MY DATA clause, and tested it rather promptly after implementation, nothing stops you from switching.

And this clearly demonstrates yet again why the IT’S MY DATA clause is the most important clause and any vendor who can’t, or won’t, guarantee full access to all of your data all of the time is not one you should go with.

Furthermore, and this is the kicker, chances are good that any vendor who is confident not only in their solution but in their ability to keep improving their solution will happily guarantee this. And who’d you rather? A vendor that feels the need to lock you in to a proprietary solution that holds your data hostage in order to keep you as a customer or a vendor that is so confident you’ll stay with their solution after mastering it that they give you the access codes to their competitor’s suite? I know who I’d rather!

* (which is not the same as relative debt in estate law by the way!)