A six-point framework for selecting the right technology

Uncategorized


We’ve spent a lot of time over the years working with companies to select new technology and we’ve seen the good, the bad and the ugly. Whether we come in at the beginning, the middle or after a company attempts to go live on a new solution, we’ve seen many mistakes that could have been avoided if the right selection framework was employed at the start.

As we’ll discuss, there are wrong ways to select a new technology. If you go down any of these paths, you are setting yourself up for pain – in terms of wasted time, increased costs, frustrated employees, and potentially a solution that meets little of your requirements. But, if you follow our six-point framework for technology selection, then you’ll come out at the end with the right technology every time.

The wrong way to choose a technology

There are several approaches companies take to select a new technology. There are the companies that say they have a need, document a few simple requirements, and look for a product to solve it. Many skip to the middle or end of the selection process, where they start looking at a few product demos and then make a decision.

These approaches result in one major challenge – there is no context for what you are evaluating against.

Context is critical. Without it, you will have unfulfilled or missed expectations. We have worked with companies that chose to go live with solutions where they didn’t do their homework and suffered the consequences:

“We thought we could replace other enterprise platforms but didn’t realize that the new tool was missing such-and-such critical capabilities.”

“We discovered after signing the contract that the solution doesn’t work in such-and-such country, which represents half of our business.”

“We didn’t consider the such-and-such process and weren’t able to support those transactions when we went live on the new solution.”

In the end, you can’t perform the functions you should be able to, or you find yourself scrambling to come up with workarounds to address the shortcoming.

At a minimum, you run the risk of exposing yourself in terms of risk by not definitively and thoroughly evaluating solutions against a clearly defined feature list.

We emphasize the need to go through a solution evaluation process that starts with requirements definition to help get the company on the same page. It forces the evaluation team to make decisions and trade-offs consciously, and it mitigates, if not eliminates, the finger-pointing when things go wrong.

There’s only one right way to select new technology: have a business-driven, objective, and methodical framework that defines how you will evaluate potential solutions.

Here’s our recommended technology evaluation framework.

1. Bound the problem

The most important thing you need to do is define the scope of the process(es) you are looking at.

If you are selecting an enterprise solution, it’s easy to say everything is in scope. But you need to decompose it down into functional and process areas. For example, you can break down a marketing solution into campaign management, content marketing, website management, analytics, and so on. For finance and accounting, does the solution need to include invoicing, budget forecasting, etc? For operations, does it need to include production planning, demand forecasting, inventory management, etc.?

The idea is to take a top-down approach to decompose the scope of the solution to buy, so you have a clear understanding of what is in scope versus out of scope.

2. Walk through the process

To have a clear understanding of what you need, the best way to start is to go through how you currently perform a process. When you start here, you identify the concerns about how things are presently done, including key pain points that you believe new features, capabilities, or enhancements could resolve.

Make sure that you’re willing to take a hard look at whether or not the current process is the right way to be doing things.

Also, reviewing the current process serves as the basis for enumerating some of your most critical requirements. Some companies want to focus purely on the future state, but this tends to gloss over foundational core requirements that you need to address.

A blended approach that is process-based (or workflow or use case) is the best path forward. With this approach, you profile the required processes and identify each discrete requirement needed to conduct each process, as well as map them to the pre-defined process hierarchy.

3. Prioritize pequirements

With your processes and requirements defined, you can next classify requirements in terms of priority (i.e., mandatory, aspirational, etc.).

At this point, the goal is to have at a minimum:

  • A clear, discrete description of what it is that you’re looking for.
  • How it maps back to the functional hierarchy you outlined.
  • The prioritization of each requirement.
  • Mapping to the major pain points or new capabilities you identified (this will inform potential tradeoff decisions).

Our advice is to take an engineering approach to designing how the solution needs to support key processes.

It is critical that you have representation from the functional areas you are evaluating when you are defining and prioritizing requirements. You must validate what you have documented and ensure that the representatives agree.

4. Shortlist solutions

In parallel with validating solution requirements, you can start shortlisting potential solutions. In conjunction with the framework that you use for outlining and documenting requirements, you need to do the same in terms of how you want to evaluate solutions.

Functional fit is critical. By creating a matrix of requirements and associated priorities, you can start to check off if a solution meets the requirements. You can also further qualify it by indicating if it meets the requirement out of the box, requires minimal configuration or customization, or does not meet the requirement. Completing these matrices, you can evaluate solution fit by functional area and priority of requirements.

You’ll want to evaluate more than functional fit. Cost is certainly critical. Break down costs for a solution in terms of one-time cost to implement, and ongoing costs to support and maintain (net of expected benefits, of course).

Market position is also important to consider. Is the solution provider a strong player in the market? You don’t necessarily want to be the largest customer because you take a risk if that provider goes under or cannot handle supporting such a large customer. Some people look at this differently, saying that being the largest customer gives you power, but we tend to see more problems than upside with these situations.

Implementation timelines should also be evaluated. You’ll want to assess the availability of resources, both from the solution provider as well as third party providers that could help you implement the solution. Look at the solution provider’s customer base. Is there a demonstrated record of successful implementations for companies similar to yours in terms of size, scale, and industry? Or are you an anomaly in their portfolio?

Finally, what flexibility does the provider have for installation options? Do they have a cloud solution? A hosted option? If you need an on-premise solution, do they offer that?

5. Narrow down the shortlist

When you start shortlisting solutions, you typically start with many possibilities (sometimes as many as 10-20 options). But you aren’t going to conduct full-blown pilots with this many solutions. You might do an initial website scan, then an initial sales demo. As you evaluate these solutions according to the requirements above, you’ll wean down that list accordingly.

When you get down to about three solutions, then you start to get into the intensive evaluation. At this point, you’ll want to see live demos specific to your environment that enable you to gauge whether or not the solution can meet your requirements.

You will give the solution providers key data, both master data and transactional data related to how you work currently and how you want to do business. You want them to present their solution live, demonstrating how it works with your data. And you’ll want to do this in a short time period to give yourself the confidence this solution can actually meet what you’re looking to do out of the box.

At this point, you’ll choose a solution, keeping one as a fallback in case your preferred choice doesn’t work out.

6. Governance is key

A final point that is key to the success of this framework is governance. Make sure you have the right governance structure in place, including a leader who is in charge of, and accountable for the initiative. From a project management perspective, this person will ensure the right processes / artifacts are in place, including a project plan, budget, status reporting, issue management, risk management, and so on.

You also need the proper executive sponsorship and representation from a steering committee level to provide guidance and adjudicate issues that can’t be decided between divisional peers.

The right technology selection framework

Did you notice that throughout this entire framework, which typically takes about two to three months (depending on scope), we didn’t say anything about technology? There are almost always non-technical reasons why companies choose the wrong technology. This framework ensures that you evaluate technology for the right reasons, and it will help ensure you select the right solution for your needs. Get in touch if you want to learn more about our approach for evaluating technology — we’d be happy to talk!