7 Common CPQ Software Implementation Mistakes

In my role as R&D Director and Software Architect, I’ve been involved in various stages of a number software implementation projects. I started with smaller projects in Italy, and as my career progressed over the last 20 years, the projects have gotten bigger and bigger – spreading into the US and Europe.

Obviously, as R&D Director at KBMax, I already speak daily with developers and system integrators. I also strongly believe that I should directly talk with actual and potential customers, to understand their needs and then find the best solution for their unique set of challenges. As a result, I sometimes ask our Sales team to involve me in their customer meetings.

CPQ Software Implementation Mistakes

A CPQ project is often the ‘last software’ because generally the company already has systems such as: CRM, ERP, PLM, etc. KBMax is generally the ‘glue’ for all these systems and the ‘fil rouge’ of many departments : Sales, quote office, technical department and workshop.

I consider my point-of-view as somewhat of an external observer of a project implementation, but still very close to all the ‘actors’. The following list is not exhaustive, but does act as a collection of pitfalls that I’ve witnessed, and many times they are preventable before they were fully realized. As the book ‘The Art of War’ says, “The supreme art of war is to subdue the enemy without fighting” – in this case, our enemy are these implementation pitfalls.

1. Prioritizing Technology Selection Over Processes and the People

One of the most common questions people ask me is. “What is the best product-fit in choosing a configurator or CPQ solution?” In all honesty, it is not a matter of which product to choose, but which people and business processes you are addressing.

There are products perfectly suited to ‘be configured’, but companies either do not have a process, or their process is needlessly complex. This typically happens because there are multiple layers added over time. It is often very hard to simplify the process, because it means reducing these layers of complexity and the power of some people or teams in the company that does with it. For example, if the Sales team wants to sell whatever the customer desires, these lack of constraints will undoubtedly create a mess throughout the rest of the company, in terms of engineering, procurement, production, etc. These issues are unable to be controlled if there is no process (and, hopefully, supported with software) that can help mitigate this risk.

I sometimes see products that the technical department has practically made as ‘custom’, but might landed here because they’ve introduced a number of completely unnecessary options. As you try to understand why there are so many options, you discover that they exist because many years ago, a potential customer asked for them. It seems to some teams that by creating options and making the process complex, it communicates to their other teams and leadership, “Hey, look how smart we are!”.

I think now you see the challenge: simplifying a process does not mean giving inferior service to the customer, but instead fighting within the company to keep the egos of each department in check. You might recognize this struggle as change management. This reframing of the critical business process of selling and production should keep proper focus on the company at large, rather than single departments or individuals.

As these existing processes are discovered, and new, optimized ones conceptualized, often the idea of automation will come to mind.  But be careful not to introduce this concept too early, before a process is fully thought through. Automating a bad process only makes a bad process run faster. If a CPQ software implementation begins replicating existing, ego-driven processes, it is easy to foresee a disaster where automation is simply more quickly compounding your problems.

2. Too Much Process Customization

Completely related to the point above: sometimes companies have very odd processes. It turns out that they have reinvented the wheel – but in doing so reinvented the wheel as a square. Many times I’ve heard companies proudly exclaim that, “we were never able to find software that satisfies us, so we had to develop our own.” This may be the case for highly specialized verticals such as engineering calculation. However, when an entire software category exists on the market that you don’t think applies to you, this might be an indication of something bigger that is wrong and most likely driven by someone’s ego.

When a customer asks for a customization in CPQ software, one should really go to the root to find why they think it is required. Generally, we find that the needed customization is most often hiding a process problem. Software customizations are very expensive for all parties and can add fragility. So, never give a blanketed “yes” to a software customization without asking first, “why”?

3. Lack of Involvement by Stakeholders to Drive Adoption

Involving all the stakeholders is very important, but can also be dangerous. The ultimate stakeholder is the company. However, not planning the user adoption or obtaining end-user buy in as part of the decision-making process will ensure failure.

At the same time, you cannot let the users unilaterally decide the solution, either. As Henry Ford said, “If I had asked people what they wanted, they would have said faster horses”.

The key here is balance. Leadership, department heads, and team members all need to have a voice in designing the new process. Balance is often what distinguished a successful CPQ software implementation from a failed one.

4. Not Seeking the Best MVP Product

You can find the definition of MVP (Minimum Viable Product) everywhere, so I don’t want to stress much here by adding another definition. The most complex product in the company is not a good candidate like it is not a good candidate, a trivial product. Probably the best candidate is a new product of medium complexity, because it is the one with less bias.

5. Underestimating the Amount of Effort

This pitfall is typically due to having not carefully gathered the project requirements. As a technician, I think that it is very easy to underestimate the time required. Generally, I multiply what I think the effort is by a factor of two. Why? I add this as ‘political time’. It is very easy to get lost in discussions and meetings pulling information out of people, in lieu of the providing properly documented requirements up-front. People like long, unproductive meetings and I don’t know why.

6. Not Understanding the Intent and Boundaries of Applications

When many software applications are involved and connected as part of a process, department, or company, it is often hard to understand ‘who is doing what’. I’m not talking about simple gray areas. I’m suggesting that every software application should be used for what it was designed to do. For example, it is very common to forget the purpose of an ETL tool (Extract Transform Load) and pretend that every software is responsible to push and pull data. When many applications are being employed, you’ll find that some are more flexible, where others are not. It is obviously easier to bend a more flexible software to performs tasks it is not meant to do. However, that doesn’t necessarily mean that you should.

7. Sales Overselling

Here, I’m talking about us – KBMax as a software company. We don’t sell a dream. We find that the overselling problem is greatly diminished since our transition from traditional perpetual licensing to a cloud model (SaaS).

Typically, when a salesperson sells a perpetual license they are interested in getting the software transaction completed and an initial successfully project launched with their client. After that, the customer is no longer ‘the salesperson’s problem’. In a SaaS model, however, the sale must be both an initial, and an ongoing win. Only customers with strong software running a successful implementation will come back for renewals which is the only way that SaaS companies can be profitable.

Other Classic Project Killers

There are hosts of other implementation problems that a CPQ software implementation project can encounter: low/shifting budgets, poor project management, lacking maintenance plans, poor knowledge of the technology, poor software quality, etc. These are dangerous and important to watch out for as they can easily crash a project, but they are pretty obvious and easy to spot in my opinion. In any case, they are not specific to the implementation of CPQ specifically.

Sharing a Better Way to Implement CPQ Software

KBMax has some great resources to help you get started in your CPQ project. We have a great eBook and a series of blog posts that shine light on some best-practices in getting you started:

• eBook: CPQ Software Implementation Guide
• Blog Post: CPQ Implementation Checklist: Everything You Need to Get Started
• Blog Post: Configure Price Quote Software: Implementation Readiness
• Blog Post: What should you do post-CPQ Implementation?