Why a Formal Software Selection Process Leads to Better Decisions

I have worked with planning, reporting, and analytics software for more than 20 years. I started as a controller, moved into software implementation, and now advise companies on software selection. One lesson has remained constant: the quality of the eventual solution depends heavily on the quality of the decision process.

Selection mistakes often surface only after contracts have been signed, consultants have been engaged, and expectations have already been set across the organization.

A new selection process usually begins with a specific trigger. A vendor acquisition creates uncertainty about the product roadmap. Cloud costs exceed expectations. An ERP change reshapes processes and data flows. A merger introduces new requirements. Some companies still rely on Excel for planning, which offers flexibility but creates serious risks around scale, maintenance, and control.

These changes create pressure to act. At the same time, the market keeps expanding. Vendors adjust their portfolios, new products emerge, and established platforms gain new AI capabilities. Most companies know two or three products in any depth. That is a narrow foundation for an investment expected to last for years.

How can you identify the software that genuinely fits your requirements, architecture, and organization?

Why Does a Formal Process Still Produce Weak Decisions?

A selection process can look rigorous from the outside. It may include a requirements catalog, scoring models, vendor presentations, and a final ranking. Its value depends on the questions being asked, the ability of the criteria to expose meaningful product differences, and whether every candidate is tested under comparable conditions.

Without a clear target state, available offers and existing vendor relationships shape the shortlist. Weak criteria give too much influence to presentation quality, visual appeal, and the latest fashionable feature. A polished dashboard or new AI agent says little about data integration, calculation logic, performance, or the effort required to maintain models over time.

The choice of advisor matters as well. Implementation partners and IT service providers often know a limited set of products extremely well. Their recommendations reflect their portfolios, capabilities, and commercial interests. Those interests are understandable, but they limit the advisor’s view of the broader market. An organization that will later earn revenue from licenses or implementation does not evaluate alternatives from the same neutral standpoint as an independent analyst.

Generative AI can help generate questions, prepare workshops, and structure an initial requirements catalog. This can save time. Yet many AI-generated catalogs contain plausible questions that nearly every product can answer in the same way. They cannot reliably assess current product strengths, real project experience, partner quality, or fit with a specific architecture. You may also never know whether the underlying LLM carries a bias.

AI helps with preparation. A sound decision also requires current market knowledge, trustworthy comparison data, and tests based on your own requirements.

What Does BARC Research Show About Competitive Evaluation?

An analysis from the BARC BI & Analytics Survey reveals a clear relationship between business value and evaluation method. 72% of leader companies conducted a competitive evaluation before purchasing their software, compared with 41% of laggards. Leaders represent roughly the top 10% of companies based on BARC’s Business Benefits Index. The analysis included 1,014 responses.

The data shows correlation. Companies that achieve high business value are more likely to invest in a thorough requirements process, broad market comparison, and detailed testing of shortlisted products. Companies with weaker results rely more frequently on an existing strategic vendor or an informal recommendation.

Investing time and budget in software selection helps protect the overall investment. A poor decision can lead to additional implementation work, low adoption, weak performance, functional gaps, and an early replacement project. The financial and organizational consequences can be substantial.

What Does a Structured Software Selection Process Look Like?

Our selection method consists of six phases, each with a clear purpose.

1. Prepare: Define objectives, scope, roles, and responsibilities. Clarify who decides, who understands the processes, and who will own the solution after implementation.
2. Gather requirements: Review existing documentation, run workshops, and interview the people in business and IT who understand the processes in detail.
3. Structure requirements: Document, prioritize, and align the findings. Translate them into knockout criteria and a weighted evaluation model.
4. Narrow the market: Reduce a market of more than 100 products to a longlist of around 30 and then to a shortlist of three to five candidates. This phase typically takes one to two months.
5. Evaluate in detail: Test the finalists under the same conditions through structured demonstrations, targeted tests, and, for significant investments, a competitive proof of concept. The phase concludes with a recommendation and commercial negotiations.
6. Prepare implementation: Transfer the selection results to the chosen implementation partner. Good documentation accelerates the start of the project.

Requirements should cover business, technical, organizational, and vendor-related considerations. The relevant criteria depend on the target state and operating context.

A question such as “Does the product support planning?” will do little to separate vendors. More useful criteria examine the required planning logic, the connection between operational plans and financial planning, and the effort involved in changing models later. The team should also agree on the weighting before the vendor presentations begin. Otherwise, a polished demonstration can quietly reshape the priorities.

When Is a Competitive Proof of Concept Worth the Effort?

A competitive proof of concept (PoC) reduces uncertainty when the investment is substantial, the requirements are complex, or individual criteria affect core operations. It allows you to look beneath the surface of the software and see how the prospective implementation team works.

A well-designed PoC should answer practical questions:

• Can future users complete typical tasks independently?
• How does the product integrate and process the relevant data?
• How easily can teams modify models and business logic?
• How well does the implementation partner understand the use case?
• How does the product perform with realistic data volumes?
• How much work will it take to operate and maintain the product and make future changes?

A credible PoC requires careful preparation. The task specification, data, test cases, evaluation model, and schedule all take time. Testing only one product saves surprisingly little effort and does not allow a direct comparison. In most situations, we recommend comparing at least two and preferably three candidates.

When a decision will shape the organization for years, a competitive PoC is usually the strongest way to reduce uncertainty.

How Does BARC Reduce Effort and Risk?

A thorough selection takes time. Proven methods, established requirements and criteria catalogs, and current market data can reduce the internal workload substantially.

BARC is an independent analyst firm. We do not sell software licenses, and vendors cannot pay for a better rating or market position. Our objective is a defensible decision for the client, regardless of which product ultimately wins.

We combine this independence with more than 20 years of market experience and over 1,000 software selection projects. BARC Scores provide a comparable view of product strengths and limitations. BARC Surveys show how companies assess their products in real-world use, including satisfaction and performance.

We use this evidence to create an evaluated shortlist. For a proof of concept, we help design the test brief, support its execution, assess the results, and prepare the final recommendation.

Independent advice and trustworthy comparison data help your team make a sound decision with less research and evaluation work.

What Should You Do Next?

Start by defining the problem. What improvement should the new software deliver? Which processes belong within the scope? Which topics should remain outside the project?

Next, identify the process experts, future users, IT owners, and executive sponsor. The team needs enough time and a clear mandate. Then run the selection process with defined decision points. Repeated delays weaken the result as requirements, products, and commercial offers continue to change.

For more detail on market screening, shortlisting, competitive evaluation, and PoC design, see BARC’s software selection consulting services. If you are preparing a shortlist or proof of concept, you can discuss your selection project with BARC.

On November 24, 2026, Dr. Christian Fuchs will also address the criteria that matter after a vendor demonstration at the BI & Analytics Conference in Vienna.