The easiest way to make software selection harder than it needs to be is to start comparing software.
I have known businesses to spend months comparing products, sitting through demonstrations, building spreadsheets, and negotiating pricing, and in the end the only real conclusion was that they never clearly pinpointed what they were trying to solve in the first place.
It’s an awkward situation. You finish the software selection process with a perfectly good product and yet it turns out your decision was still wrong.
After thirty-odd years of working with software, I have learned that one thing never changes: the best starting point should be the business. And this starting point can be boiled down to three questions:
- What is not working today?
- What needs to improve?
- What does the company need to be able to do that it cannot do now?
Now we can continue the conversation to find the right fit.
If someone asks me which approach to use when choosing the right software, I would break down the decision-making process into 7 steps. And this goes for everything, whether the answer ends up being an off-the-shelf product, custom software, or some combination of the two.
Step 1: Define the Business Problem Before You Start Thinking About the Software
The first step in any software selection process is understanding why you are looking for a solution.
It may sound simple, but companies tend to move too quickly here. Moving without a well defined reason is a poor strategy.
A leadership team might decide it needs a new application because “the current one is outdated.” Another company might want to replace its existing software because its “existing systems don’t communicate well.” A growing business might start shopping for a new platform because “employees are spending too much time moving information between systems.”
Those descriptions are useful, but they are not yet requirements.
Start with the Outcome
Make a list of what you need (and want) the business to do better.
Is your goal reducing manual work? Maybe you need to process more transactions without adding people. Possibly reporting takes too long. Maybe employees are entering the same information into multiple systems. Or potentially your existing software is preventing you from introducing a new product or entering a new market.
The answer should be so specific that afterwards, you can tell whether the investment worked or not. In other words, define what success looks like and how it creates value for the business.
For example, “We need better reporting” isn’t something easily evaluated.
“Our managers need to be able to see sales and operational data updated daily, without manually combining information from three systems” gives you something you can tie to exact requirements.
Turning the Problem Into Requirements
Once your goal is clear, translate it into functional and technical requirements.
A good requirement describes what the process needs to accomplish, instead of just naming a nice-to-have feature.
This is an important difference for comparing products. Vendors are very good at showing you what their software can do, it’s their job. Your job is to determine what your business actually needs it to do.
Step 2: Understand How the Business Works Today
Before you decide what should replace (or supplement) your current software or processes, make sure you understand the environment you already have.
Review Current Processes and Functionality Gaps
Map the workflows your new software should support.
Where does work slow down? Where do you need to move information from one system into another? Which process depends on spreadsheets or other external documents? Where do employees have to create workarounds?
Finding those gaps and staff pain points is more eye-opening than a product feature list.
I have also seen organizations assume their root problem is software one, when the process or model itself was actually causing most of the friction. Automating a poor process or updating an old business model in those cases simply allows you to do the wrong thing faster.
Talk to the People Doing the Work
The person approving a software purchase and the person who will actually use that software eight hours a day usually have different priorities.
Executives may be thinking about cost, risk, growth, and reporting. Operations teams may care about reducing repetitive work. Finance may care about controls and auditability. Employees’ priority might be completing a common task without five screens and three workarounds.
They are all stakeholders, and you need all of their perspectives.
Step 3. Separate What You Need From What Would Be Nice to Have
A long requirements list can quickly become a problem of its own.
If everything is a priority, nothing really is.
Prioritize Your Requirements
I usually think about requirements in three broad groups:
It’s important to agree on the categories before the vendor demonstrations start.
If not, the software with the flashiest presentation can accumulate points simply because it has more features. That does not necessarily make it the better choice.
Think About Growth Without Buying for an Imaginary Future
Scalability is one of the most important things to think about, but I would be careful about buying for a hypothetical company that may never exist.
Think about realistic changes over the next few years.
Will the number of employees increase? Will transaction volume grow? Will you operate in new markets? Will you need additional integrations? Will new security or compliance requirements affect the system?
Those are reasonable questions.
Buying a massive platform today because you might need one of its features five years from now is a different proposition.
Step 4. Evaluate the Whole Environment, Not Just the Product
Once the requirements are clear, you can start comparing software.
This is where the traditional software selection criteria comes into play, but the evaluation needs to go beyond functionality and price.
At a minimum, I would look at functionality and fit, reliability, security, compatibility, integrations, data migration, scalability, usability, vendor support, implementation requirements, licensing, and total operating cost.
Pay Particular Attention to Integrations
A software product does not exist in isolation.
It may need to connect to accounting software, customer-facing applications, payment processing, identity management, internal applications, data warehouses, or older systems that the company still depends on.
A product can be excellent on its own and still be a poor choice for your environment if connecting it to everything else creates a complicated collection of workarounds.
I would also look carefully at data migration. Moving data from one system to another is rarely as simple as exporting a file and importing it somewhere else. Data structures, history, duplicate records, relationships, permissions, and business rules all matter.
Consider Security and Compliance Early
Security should not be something you check near the end of the process.
The same applies to regulatory requirements.
For a financial institution, for example, security, auditability, permissions, resilience, reporting, data handling, and regulatory controls may carry much more weight than an otherwise attractive feature set. The same goes for healthcare and other heavily regulated industries.
Establish those requirements before comparing vendors, not after you have already become attached to one.
Compare Cloud, SAAS, and On-Premise Options Realistically
There is no universal winner here either.
SaaS can reduce infrastructure responsibilities and make deployment easier. Cloud-based systems can provide flexibility and scalability, but they still need to be evaluated for security, architecture, integration, data handling, and operating costs. On-premise software may make sense when a company has particular infrastructure, control, or regulatory requirements.
The question is which model fits the business and its constraints.
Step 5. Decide Whether to Buy, Build, or Blend
This is one of the most important decisions in the entire system selection process, and I do not think it should be treated as a binary choice.
Buy When the Problem Is Common
Off-the-shelf software can be the obvious choice when your needs are well understood, mature products already exist, and your processes fit reasonably well with the way those products work.
There is little value in building a custom accounting system simply because you can.
Buying can also make sense when speed matters and your organization does not want to take on the responsibility of developing and maintaining another core system.
Build When the Business Really Is Different
Custom software becomes more compelling when the workflow is highly specialized, the process itself creates competitive advantage, or available products force the organization into too many compromises.
This does not mean custom software is automatically better.
When you build, you also take responsibility for maintenance, security, upgrades, staffing, and documentation.
That needs to be part of the decision.
Blend the Two When That Makes More Sense
This option gets overlooked.
You might buy your accounting platform and build a custom workflow that connects it to the other applications your business uses. You might keep a legacy system that still does one thing very well while replacing the part that is holding the business back.
In my experience, some of the better technology decisions are combinations rather than attempts to force the entire business into one product.
For more on this decision, read about the tradeoffs in Build vs. Buy Software: How to Make the Right Call for Your Business.
Step 6. Evaluate the Vendor, Not Just the Software
Software can be replaced. The relationship around it can be much harder to unwind.
That makes vendor evaluation part of selecting software, not an administrative step that happens afterward.
Ask Questions the Demo Will Not Answer
How does the vendor handle support? How often is the product updated? How does pricing change as you add users? What happens to your data if you leave? Which integrations are supported? Which capabilities require customization?
I also want to know how much experience the vendor has with businesses facing similar requirements.
Whenever possible, test the software with your own workflows and data.
A demonstration shows you what the product can do. It does not necessarily show you what it will be like to live with.
Use a Software Selection Matrix
A software selection matrix gives everyone a clear way to compare options:
I’m not pretending the numbers make the decision scientific. But they do something more useful: forcing the team to agree on what matters.
A software selection template can be as simple as the one above. No need for 50-page procurement documents.
Step 7. Plan out the Implementation Before You Make the Decision
When you sign the contract, it’s not the end of your software decisions. In some ways, that is when the hard work starts.
Build a Realistic Timeline and Budget
While estimating the cost of a new system, include more than just licensing.
Think about implementation, configuration, integration, migration, testing, training, support, and the hours employees will spend adapting to the new system.
The same applies to the timeline. A six-month implementation can mean very different things: employees gradually adopting a new workflow is very different from the business having to switch everything next Monday morning.
Reduce the Size of the Big Switch
I generally recommend approaches that allow the business to keep operating while the new system is introduced.
Depending on the situation, that could mean migrating one department first, moving a specific workflow, running old and new functionality alongside each other, or creating a bridge between systems.
Sometimes a complete replacement is the right thing to do. There are also many situations where it’s possible to change one part at a time.
The implementation plan should be part of the software choice. A solution that looks excellent on paper becomes a completely different proposition once you understand what it takes to put it into production.
A Practical Software Selection Template
Here’s a simple cheat sheet to help your decision making, in the form of a software selection checklist:
So, make sure the same questions are being asked of every option.
Common Categories of Business Software
The category changes the details, but the same business software selection principles still stand.
Accounting and Financial Management Software
Look at reporting, controls, auditability, permissions, integrations, and the financial workflows the business actually uses.
Customer-Facing and Operational Applications
Consider how well the applications support your customer relationships and internal workflows. Look at reporting, automation, integration, usability, data migration, customization, and implementation requirements.
Business Intelligence or Workflow Software
Consider data sources, data quality, permissions, reporting requirements, performance, and how information will reach the people making decisions.
For financial institutions and other regulated organizations, security, compliance, auditability, resilience, access controls, and data handling carry much more weight than additional features.
Common Mistakes in Software Selection
After seeing the end result of these decisions over the years, I noticed a few mistakes come up repeatedly.
Choosing a Product Before Defining the Problem
The evaluation starts revolving around what vendors sell instead of what the business needs.
Letting the Best Demo Win
A polished demonstration is designed to be persuasive. Your own workflows are what actually matters.
Letting Price Be the Deciding Factor
Price matters, but it should not be the deciding factor. What are others saying about the software’s stability, usability, etc?
Ignoring Integration and Total Cost
A new system can work beautifully by itself, and start creating headaches when it has to communicate with everything else. Licensing is easy to see. Migration, implementation, training, support, customization, and lost productivity are harder to measure.
Forgetting the People
A system can satisfy every technical requirement and still fail as an investment because the people you expect to use it cannot or will not adopt it.
Assuming Newer Means Better
I have spent enough time around technology to be skeptical of this assumption. Sometimes the existing software is doing its job perfectly well. The only question is whether it still supports the business you are running today.
The Software Should Fit the Business
The longer I work in technology, the less I believe that you can find the “best” software in the abstract.
There is no single best application, platform, or architecture for every business.
There is only the solution that fits the problem you actually have.
Sometimes it’s buying an existing product. Sometimes it’s building something custom. Sometimes it’s keeping part of an older system and replacing another part.
A good software strategy should give you a clear reason for the choice, an understanding of the tradeoffs, and a realistic plan for living with the decision after you make the purchase.
That is what good business software selection should accomplish.
Explore 2am.tech's Software Consulting Services
