Skip to content

Top 10 reasons why CPQ projects fail

The CPQ does not have backing from senior management

The CPQ process is spread all over the enterprise and touches many groups including sales, IT, engineering, marketing and order management. The planning and development of a CPQ solution must involve all of these organizations and must address the requirements of each group.

CPQ is a knowledge-based tool, and it's never better than the actual knowledge and data in the tool. Usually the product expert or senior sales rep who is too busy working with deals, is the person most needed for this type of project.

Backing from senior management is essential, to allow for prioritization of the implementation of the CPQ over the day-to-day business tasks for all these organizations, including the busy experts.

 

Scope creep

Scope creep is an uncontrolled growth in a project’s scope after the project has begun. This is very common in CPQ projects as you learn about and define processes that quite often were never documented before. 
 
This is why it's important to define project objectives early in the project, and refer to them as much as possible when deciding on changes to the project. It's also important to have a defined change control process, with a steering group that has backing from senior management. 
 
There's no easy solution to scope creep, but being aware of the problem is essential. 
 

Aiming at 100% of sales done with CPQ

If you ask an engineer working for an elevator company how many floors the elevators can have the most, he might answer 100. However, maybe 95% of the sales have fewer than 10 floors, and all elevators above 20 floors require some engineer-to-order? So, does it really make sense to allow for 100 floors in the configurator?

We recommend aiming at 80-95% of the configurations done automatically by the CPQ software, and allowing for some manual work for the rest. The reason is that there is typically an 80-20 rule in regards to implementation, where the last 20% of the configuration complexity will take 80% of the implementation time of the tool.

It is much better to focus on 80% of the sales initially in the project, and to make sure there is a ready process for the other 20% of the sales. If the project is a success, why not aim higher in the next phase of the project?
 

Bad data quality

A good sales configurator will use your product data existing in current systems. But how good is the quality of that data today? Do you have an organization in which all knowledge is stored in people’s heads and documentation is missing? As stated above, the output from the configurator will never be better than the input, which means you need to make an inventory of your product data and documentation.

You might need to structure and systemize your product data before selecting or implementing sales configuration software. If you don’t, the implementation will probably take much longer than expected, and changes of the tool will be done multiple times back and forth before being able to release.
 

Too few or too many integrations

Implementing integrations take time, whatever the IT-guy will tell you. Even a standard integration may require some adaptation because the software you are already using and want to integrate to is probably customized. Adding integrations to all your surrounding tools will add up to a hefty budget, and with some delays added, your project might get stopped before it is released.

Hence it is important to prioritize integrations, and to allow for manual integration in the early phases of the project. Do your prices reside in ERP? Are they only changed every 6 months? Can you export them to Excel initially, to get the project going? If you can get a manual integration to work, try to push the implementation work to the future.

However, from a similar perspective pushing integrations to the future which require a large amount of manual work is also a bad idea. The manual work will cost money and may cause update errors.
When selecting a vendor, make sure they have standard integrations to the essential systems you need to integrate to. Focus only on crucial integrations in the early phases to allow for a quick return on investment. Add the additional integrations in later phases, and do separate ROI calculations for the specific integrations.
 

The configurator cannot solve the configuration problem

Configuration is a complex subject. To put things into perspective; the number of atoms in the universe is estimated to be 10^80. A configurable product with 100 choices, and 10 alternatives for each choice has 10^100 combinations.

It is important to select a configurator that is able to solve complex configuration problems, an incorrect selection of sales configurator may lead to being force to simplify the configuration problem too much and hence giving incorrect configurations or prices to the sales person.
 

Too much focus on tangible products

A typical product does not only consist of hardware, but also other intangible products. It’s not uncommon for companies to have higher margins on services, spares and extended warranties. These products should not be forgotten when implementing the configurator – because without these the configurator is not complete. And if the configurator is not complete, the deals will either be missing these high margin products, or the sales will simply not use the CPQ due to the missing products.

 

The CPQ isn’t easy to use

If the solution is difficult to use or just slow – it will fail because no one will use it.

Your solution should simplify a complex process, not replace one complex process with another. There are often tradeoffs in functionality when simplicity is the primary goal. Make sure your CPQ is achieving a good balance between these two elements.
 

The CPQ doesn’t focus on the key users

CPQ projects tend to be initiated by all other departments at companies except sales, because sales are too busy working on quotes for customers. Hence the key tasks of the tool often misunderstood and not implemented properly.

The most important task of a CPQ is to help the sales person create a correct, competitive and valid quote quickly – and what that means exactly is different for different companies.
Makes sure key people from the sales department are involved in the selection and development process to insure that their requirements are covered.
 

No focus on data maintenance

In most configurable products, the master data changes continuously. New options are added and old ones disappear, new suppliers emerge, prices change, etc. Often, these changes are made on a daily or weekly basis. Typically, these changes are managed in ERP or PLM systems by people not involved in the CPQ maintenance.

It's vital that master data maintenance requires minimal amount of changes in the CPQ software. It is also equally important that an organization is set up to be responsible for the maintenance of the software, because with even a minimal amount of maintenance it still needs to be tested and validated.

You've reached the end of the page...

Ready to learn more? Check out the online ebook on CPQ with the possiblity to book a CPQ introduction with Magnus and Patrik at cpq.se