Switch pricing toolswithout repeating his mistakes
.avif)
One underutilized tool contains valuable information (the specific causes of adoption failure, which must be identified before making changes), and the Standish Group’s CHAOS Report notes that only 31% of IT projects are fully successful, 50% are delivered with compromises, and 19% fail completely. The migration of existing data (history, catalog, rules) must be an explicit requirement in the specifications, not an option.
Ensuring successful adoption is the role of BOOPER’s Change Management module: to support business teams so that a new tool does not suffer the same fate as the previous one.
An initial pricing tool that was never fully configured or truly adopted is not an isolated case; it’s a scenario that occurs regularly in specialty retail. The contract expires, and a new partner must be chosen—with one explicit goal in mind: to avoid repeating the same failure.
This guide explains what needs to be assessed before reissuing a request for proposals, how to build on what already exists rather than starting from scratch, and why the timeline for the change is just as important as the choice of service provider.
It doesn't have to be the case that a first tool goes underutilized
It’s a familiar scenario in the specialty retail sector: a pricing tool deployed several years ago, never fully configured, and never truly adopted by the teams. The contract is about to expire, and there’s a strong temptation to treat the renewal as a simple comparison of features and pricing (the same mindset, at times, that guided the initial choice).
It’s a missed opportunity. An initial deployment failure provides valuable insight: the specific reasons why adoption didn’t take place. Ignoring this analysis to focus on the new software is like switching cars without understanding why the first one never left the garage.
Why Software Migration Projects Fail So Often
31% / 50% / 19%, breakdown of IT projects according to the Standish Group CHAOS Report (2020 edition, an industry benchmark since 1994): 31% are fully successful within the planned time frame and budget, 50% are “challenged” (exceeding the time frame, budget, or scope), and 19% fail completely.
This figure applies to all IT projects—not just pricing—but it highlights a key point: half of the projects that are “successful” in the strict sense of the term achieve that status by making significant compromises on scope or actual usage. A tool that is delivered but never fully configured typically falls into this gray area.
According to Prosci, a leading firm in change management (which has been conducting ongoing research since 1998), 30% of change project leaders cite employee resistance as the number one obstacle to a project’s success, ahead of a lack of sponsorship or budget.
In other words: in a significant number of deployment failures, the software itself is not to blame. The problem lies in how the project is managed (training, support, and buy-in from the teams who will be using it on a daily basis).
The Right Assessment Before Making a Change: Tool or Adoption?
| Observed symptom | Probable cause | Involvement |
|---|---|---|
| Few active users | Insufficient training; absences on the part of the project team at launch | Project Management |
| Configuration remains incomplete | Insufficient data to complete the intended configuration | Data Reliability |
| Missing feature confirmed | Actual limitation of the software despite full utilization and clean data | Justified tool change |
| Launch During a Busy Period | The project began at the same time as another operational peak | Project Timeline |
To put it this way:only the third point alone justifies switching tools. The other three relate to how the project was carried out, and will recur with new software if they are not explicitly addressed.
Build on what already exists rather than start from scratch
Switching tools doesn't necessarily mean starting from scratch. The price history, the existing product catalog, and the business rules already developed with the first service provider—even if they haven't been fully utilized—represent a wealth of business knowledge that is worth building on rather than rebuilding from scratch.
A criterion that is often overlooked in migration specifications: the new service provider’s ability to quickly restore a functional environment based on what already exists, rather than requiring a new data collection project to be started from scratch.
The Specifications That Help You Avoid the Pitfalls of Your First Project
1. Require a data assessment before configuration. The service provider must be able to specify, before signing the contract, which data can be used as-is and which data needs to be validated.
2. Prioritize usability for non-experts. A tool reserved for a handful of in-house experts replicates the dependency and fragility of the previous system.
3. Include the import of existing data as an explicit criterion. Price history, catalog, and predefined rules should be considered a selection criterion in their own right.
4. Align the change management process with the company's actual schedule. Training, support, and implementation should be planned for periods outside of operational peaks.
To compare offerings based on the same criteria, our comparison of retail pricing software reviews five categories of solutions across ten criteria.
The Schedule: Why Timing Matters Just as Much as Choice
Best practice: One of the most common reasons a project is abandoned partway through is poor scheduling. Launching a migration project in the middle of the annual rate update period, during peak season, or at the same time as another major IT project greatly increases the risk that the configuration will be postponed and then abandoned.
A realistic timeline clearly distinguishes three phases: selecting the service provider, ensuring data reliability, and training teams in advance; followed by the actual start of configuration once the period of heavy operational workload has passed.
Mistakes That Cause a Second Attempt to Fail
- Don't base your decision solely on budget considerations. An attractive price does not make up for a poorly supported project.
- Do not involve future users in the selection process. A tool chosen solely by management will replicate the lack of buy-in that likely contributed to the initial failure.
- Underestimating the effort involved in data migration. Starting from scratch with the catalog and history makes the project more time-consuming.
- Launch the configuration at the worst possible time in the business calendar. Even an excellent tool that is poorly timed will meet the same fate as the one before it.
Frequently Asked Questions
Assess the situation before making a decision: if the tool has never been fully configured or if the team isn’t using it due to a lack of training, the problem is often the project management, not the software. Only a genuine functional limitation—one observed despite full use of the tool and clean data—justifies switching to a different tool; other common causes will recur with new software if they are not explicitly addressed.
In most cases, yes, at least partially: price history, product catalog, and predefined business rules can be reused to avoid starting from scratch. One criterion that is often underestimated in migration specifications is the new service provider’s ability to quickly restore a fully operational environment based on the existing data, rather than requiring a new data collection process from scratch.
During a period of high operational workload, annual rate updates, seasonal peaks, and another major IT project underway, a realistic timeline clearly distinguishes three phases: selecting the service provider, ensuring data reliability, and training teams in advance, followed by the actual start of configuration once the period of high operational workload has passed.
There is no one-size-fits-all timeline: identifying the causes of the initial failure, ensuring data reliability, training teams, and launching the system outside of peak periods are steps that cannot be rushed. What truly speeds up the project is leveraging the price history, catalog, and business rules already developed with the first service provider, rather than rebuilding everything from scratch.
At the very least, the teams that will use the tool on a daily basis—not just the management team that signs the contract. A tool selected solely by management often leads to the same lack of buy-in that contributed to the initial failure; involving future users in the selection process is one of the best predictors of successful adoption the second time around.
See also in this series:Before deploying a pricing tool, ensure your data is reliable · Integrate your pricing data without a major IT project · Pricing, procurement, category management: Move Beyond Separate Files.
It has become increasingly common to compare two implementations of the same general-purpose language model before deciding which one to use to drive pricing; but the real question isn’t which one to choose, but where to position each one.
A general-purpose LLM lacks four key components required for pricing decisions: access to real-world data, explicit business rules, impact simulation, and explainable governance—these are the responsibilities of a specialized solution, not the LLM alone.
Generative AI projects that combine in-house expertise with that of a specialized partner have a significantly higher success rate than those developed solely in-house: 67% versus 22%.
Auditing a rule verifies that a calculation was executed correctly. Explaining a decision reconstructs the data, the expected demand, elasticity, cannibalization, the rules applied, and margin-volume trade-offs. According to Sage & IDC, 71% of financial executives would reject an AI tool that is 99% accurate if it cannot explain its answer.
A pricing tool faithfully processes the data provided to it; the quality of the results depends first and foremost on the quality of the input data. Three tasks are priorities before any configuration: a product catalog free of duplicates, synchronized prices and costs, and a continuous sales history. There’s no need to wait for perfect data to get started: an initial setup using files allows you to gradually improve reliability.
This is precisely what BOOPER’s Change Management module addresses: supporting teams to ensure that this data analysis does not hinder the adoption of the new tool.