In our last posting we told you that solution selection is a seven stair methodology, and that the vendor assessment step was itself a seven step process. It’s not just as simple as taking a vendor pool, pulling five names out of a hat, and issuing an RFP, even though some consultancies would like you to believe that it is. But all that does is get you to a wrong conclusion fast.

Vendor selection takes time, sometimes longer than you want, but when you get the right solution, it’s always worth it in the end. Here’s the process outline.

1. RFI Creation

The first step is to create an RFI that accomplishes two things:

1. verifies the vendor has the necessary must-have functionality to meet core needs
2. collects the necessary information for rapid fire vendor elimination so you don’t waste time on a vendor that the business can’t accept

2. Collaborative RFI Review

Once the consultant or the analyst does their initial review, does their initial scoring, draws their initial conclusions and documents the rationale, the next step is to work through the RFI collaboratively with the client to make sure that every vendor invited back is not only acceptable to the client, but both parties understand the reason why vendors were cut.

3. Qualifying Demo

Before the full RFP, a demo verifying the promised must-have functionality must be taken to make sure what was written is currently in production and that the vendor truly understood the requirements. This can be considered phase two of the rapid fire elimination phase and strengthens the reasoning for any vendors pushed forwards.

4. RFP Creation

The next step is to create a full RFP that:

• goes beyond the core and includes questions related to the should-have and value-add functionality appropriate to your needs (not some random feature list)
• allows all organizational requirements for vendor onboarding to be evaluated
• allows for an assessment of the depth and breadth of services and training provided by the vendor
• contains additional questions designed to elicit the input necessary to answer any questions that come up from the RFI and initial demo review
• address all of your business requirements (not just the ones that permit rapid fire vendor elimination)

5. Collaborative RFI Review

Once the consultant or the analyst does their initial review, does their initial scoring, draws their initial conclusions and documents the rationale, the next step is to work through the RFI collaboratively with the client to make sure that the client’s final two/three vendors are not only appropriate, but all of the strengths and weaknesses that can be assessed are understood.

6. Deep Demo Specifications

You need to give each vendor their own demo script that you want them to execute because it’s your problems you need to see solved, not their best whizz-bang features that look good but function poorly.

7. Decision

After the consultant provides their deep dive analysis of the demo and their overall vendor assessment, using all the information at your disposal, you make a decision that you believe will best serve your organization.

In other words, it’s a methodical, deliberate, process that takes what it takes because that’s the only way to ensure you get the right solution. But it will be worth it because the right solution will bring an ROI of at least 5X while increasing efficiency between three-fold and ten-fold once adopted, but the wrong solution will be an albatross around the necks of every employee that depends on it.

… 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.

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.