Expertise Beyond the Numbers

The Secret Sauce to Enterprise Software Selection

In today’s day and age, we are inundated with choices, sometimes too many. Even something as simple as a work trip across the pond landed me on Amazon, in search of a critical travel component—an outlet adapter to charge all my devices. But I wasn’t just looking for any adapter, I needed the highest-rated, Prime-eligible­ adapter. As I scanned through the items, applying sub-conscious filters to weed out any adapters that appear over or underpriced, or “sponsored”,  I simultaneously opened up two more tabs—one for Target, and one for Wal-Mart—to scan for equivalent adapters and vet the reviews. You know, just in case I wanted to brave the conditions and drive 10 minutes to the store rather than wait less than 2 days for that brown box to arrive on my doorstep.

Fast forward two days, and here I am typing away at this blog, while charging my laptop on this brand new, Anker Elite USB/Wall Charger.

Does this process sound familiar? It seems like so many purchase decisions now follow this sort of decision tree—whether it’s a $10 wall-adapter or a $200K+ enterprise software purchase—and it has become the norm. While the adapter example may be a bit extreme, it’s a microcosm for what we’re seeing across the board with clients.

Decisions of such magnitude on the software selection front are no easy task. They consume an exorbitant amount of time, are under close scrutiny, and require rigor to ensure the organization making the purchase is getting what they need to improve their business without crippling them financially. This is why organizations often bring in a third-party to help with enterprise software/system selection processes, not only to bring objectivity and experience to the selection, but also to act as the scapegoat¹ if the decision ends up being the wrong choice!

¹Disclaimer: That last part was for humor, we never make the wrong choice! 

The recipe for successful software selection is a multi-step, multi-ingredient approach, and it must juggle finding the right balance of secret sauce while avoiding the hiccups, in order for an organization to serve a winning dish.

KEY INGREDIENTS

  1. Get Executive Sponsorship
    • It is always important to setup any transformation effort in an organization with a “top-down” mentality.
    • Conduct interviewing sessions with key leaders to get their “wish list” and understand what they want to see improve as a result of a system/software implementation.
    • Use this list as the basis for every discussion/meeting to set the tone/goals of what needs to be accomplished.
    • This is also extremely important for change management down the road once the software is being deployed.
  2. Apply Objectivity with Subjective Inputs
    • Create/use software selection documentation that captures all of the user/business requirements that need to be fulfilled.
    • Ensure a scoring/grading system can be applied to the defined set of user/business requirements.
    • Allow stakeholders to apply prioritization to the requirements so that the most important carry a higher weight.
    • Include note capturing fields so that comments/justifications can be recorded to substantiate the rankings and scoring.
  3. Obtain Order of Magnitude Estimates Early
    • By obtaining estimates early on in the process—even if they are ballpark estimates—the software selection process will be much more efficient.
    • An overarching budget can be set for the software purchase and implementation, which can be re-used and tracked against after the selection process.
    • Software products or implementation vendors that are clearly over-budget can be eliminated from the process (that way there will not be a shiny, unaffordable toy dangled in front of stakeholders).
    • Internal resource estimates can be created based on which products require more administration/maintenance effort (i.e. cloud product versus an on-premises hardware-based application).
  4. Go Beyond a Software Product Demonstration
    • Demonstrations are great as they show the “art of the possible” for each software product you may be considering for your organization, but they are often dressed up more than a kid on Halloween.
    • Before holding a demonstration, provide the party performing the demo with a small “use-case” or requirement criteria for your business.
    • Shortly after viewing a software demonstration, ask for customer references that utilize the desired functionality that your organization requires. We typically recommend talking to at least two other companies that are using the product and functionality in a live production environment, and to also conduct the call without the software vendor on the line. And, don’t be afraid to ask questions! Peers are often more than willing to share information to help you make an informed decision.

INGREDIENTS TO BE THROWN AWAY

  1. Trying to Perfectly Calculate ROI
    • Understanding how much purchasing new software will cost and comparing it against what you are paying for the legacy software currently in-place is important. It will likely be the biggest deciding factor in the choice to compliment the scoring on the product’s capabilities. However, the quest for a perfect calculation can be an endless effort. (i.e. Attempting to guess/determine how much a license renewal will increase after the first contract is over.
      1. Will the increase be different for each product?
      2. Is there opportunity to negotiate down further at that time?
    • Will the increase follow the same model as legacy on-premises versions? This example along could have multiple outcomes.
    • One way we have combatted this issue is by holding certain assumptions, such as internal system administration support costs, true across all software products being evaluated. Certain items like this should not have a material swing on the analysis, and will prevent undue effort trying to estimate the costs with utmost certainty. Of course, if there is a material difference in the internal resource cost to support one of the of software products (i.e. one software will require two administrators vs one), it should be included in the analysis.
    • Also, we have found trying to calculate the ROI for back office software to be more of an art than a science (it is easier to do with software that has some revenue generating measurability). For these types of products, we recommend sticking to a five or ten year cost of ownership analysis as the basis for comparison.
  1. Running the Process with “Uninformed” Resources
    • All too often we run into an individual from an organization’s procurement or project management team attempting to run a software selection process for a Finance, Accounting or IT department. This individual can quickly become overwhelmed by the process, as they are neither experienced in the software solutions under evaluation, nor an expert in the service they provide.
    • We recommend appointing a team of resources from the department that will use the software product to champion the software selection process.
    • These champions should be the ones to define and prioritize requirements, as well as score the software on how well it meets the organization’s needs. They will know the nuances of what will make a difference in their day-to-day processes, and will be the ones to own the solution once it is selected.
    • These champions can lean on procurement for documentation, research, scheduling, negotiations, etc., but should not expect those individuals to drive the selection process.
  2. Making Decisions Without Buy-in
    • The last item that cannot occur is making decisions throughout the software selection process without getting the appropriate stakeholder buy-in.
    • For instance, a Director of FP&A cannot simply task their team with finding the next financial planning solution. They need to be involved in key requirements meetings, and should also review the list and ranking of requirements to ensure it fits the organizations goals and objectives.
    • If key resources are not involved early and often, it can be a recipe for disaster—likely resulting in missed or improperly prioritized requirements—and may create re-work for the selection team.
    • Also, ensuring that all parties are involved in the selection process will lead to far greater participation during implementation, as well as adoption of the new-solution.

It’s not all going to be wrapped up and on your doorstep in two days, but the end-product is sure to whet the appetite of your key stakeholders when its effectively meeting business needs, scaling to support future growth and delivering on the promises from the product sales cycles.

With a healthy dose of preparation and close attention to detail, it’s a selection process that can be a piece of cake.

Considering the cloud? Learn More