How to destroy a sales configurator implementation project

Since product configuration, and many other IT-projects in manufacturing, requires lots of technical knowledge it is crucial for success to have a willing and change oriented engineering team onboard when implementing a new sales tools for quotations and configuration (CPQ).

So if you don´t respond well to guidlines of what to do when implementing CPQ, we thought that you might enjoy the opposite approach and focus on what guarantees certain failure.

To guarantee disaster in your sales configurator implementation project the Engineering team can do the following.

1 – Never talk to Sales

To ensure disaster; Engineering should never talk to non technical people like Sales, Marketing or the customer during an implementation project. If forced to interact with these people anyway the engineer can revert to using impossible technical acronyms in everything they say. Or just start ranting about internal requirements that nobody else has a clue about (“..the k-factor and the elastic modulus can never be…”, “the VPN will loose its DNS flood protection”, etc). Ensuring that there is no understanding between Sales, Marketing and Engineering guarantees that there will be no clear requirements of what to focus on.

2 – Include all odd edge cases in the scope

The Engineering has a unique position to set the requirements for first release since product rules (strength calculations, certifications, etc) and previous IT systems (magical excel sheets, etc) are involved. Engineering can therefore just constantly raise the bar for perfection (110%) and ensure that the hardest and oddest edge cases have to be included before release (“lets see how they handle this one that we encountered in the summer of 94”). Together with the possibility to add theoretical cases that could potentially occur in the future there is a steady supply of scope creep that will prevent the project from ever being completed.

3 – Keep polishing forever

Another way to ensure that a sales configurator never reaches first release is to keep polishing it to perfection. Before first release its a potential viral success that everyone on the internet will be talking about. Therefore you can always motivate that we need to adjust or improve what sales / customers will see more and push the deadlines forward (“its not photo realistic enough”, “we must simulate the entire city to ensure that the user can relate”) because nobody wants to risk releasing just a regular sales configurator that takes the usual time for people to adopt (“go viral or don’t go at all”).

4 – Build everything from scratch

To make sure that the implementation project takes forever to complete, Engineering could insist on building the product configurator from scratch in their own favorite system (excel, C# or why not invent your own programming language/framework) instead of using an existing SaaS platform for product configuration (getting started in a day is just not serious). This will extend the time to release by a few years and it will prevent anyone else from continuing development / maintenance of the product configurator without the specific Engineer that created its involvement.

5 – Refuse to test anything before its bug free

The Engineering team can refuse to use any prototypes of the product configurator before its 100% ready (“this is just a waste of my time”, “I found a bug so I’m not testing anymore”). This way the product configurator will be full of errors that nobody will figure out how to address and increase the chance that the entire projects is abandoned before getting released. Engineering can also keep the lowest possible priority on testing and feedback of prototype to ensure that its 2-3 weeks of each iteration. This causes most organisations resource planning to break down as people need to be relocated from the project to other things, which slows the development down even further.

6 – Invent your own cloud IT infrastructure

Since most of the Engineering teams internal tools are installed on local computes and internal servers its easy to insist on a new sale configurator platform running on the companys own servers (“the cloud is not safe”, “I need to know the details of everything things if we are to trust it”). This way Engineering can specify and control the performance making it near impossible for the software provider to ensure fast response times and smooth project. And since internal IT often is busy it will delay the start of the project significantly.

7 – Dont start until everything is organized to perfection

Every manufacturing company has a long list of product improvements that for some reason has not been implemented yet. Engineering can easily stall the sales configurator project by insisting on improving and re-organizing the product/rules before the projects can start (“Im just going to tidy things up for you before I send the rules over”). This will take forever since you will re-discover all the impossible details that caused the product improvement to not be implemented in the first place.

And remember. What ever you do the number one factor to guarantee disaster in any change management project you should ensure that Engineering, Sales, Marketing and Customer never talks with each other and does not understand each others situations.

How to handle complexity in product configuration development

Developing a product configurator can be challenging due to the many design decisions along the way. Two of the most critical aspects that impact implementation time and skill requirements are:

  • Implementation strategy for the rules in the configurator
  • Skill level of the intended user

That is why we have put together some examples to help you determine the complexity level based on the approach you take to the configuration, and hopefully guide you in the way you tackle your development project.

Project plan Template – CPQ implementation

When creating your first product configurator that should help sales, distributors and even customers to configure products and request quotes there are many ways how to tackle the implementation project.

We have therefore created a generic project plan to be used as a template (see below) targeted towards manufacturing companies. To avoid ending up with a long and costly IT project that isn’t used by anyone we have divided the project into a series of steps to maximize the chances of success and to get value of the implementation as soon as possible (start to use the implementation already after step 2).

Guidelines when developing your first customer self service app for CPQ

Customer self service applications come in many shapes and sizes. But they all enable the customer to do more of the sales work themselves which leads to increased customer engagement and should free up considerable time and resources for the internal sales team.

Taking the step from internal sales applications to public ones can however be challenging since it requires a new perspective (the customers) on pretty much everything in an app compared to what previous solutions have been optimized for (the experts). There are lots to be learned along the way when releasing the first customer self service application.

To minimize the risk of a huge development project that costs a fortune, takes forever to complete and is used by nobody afterwards, we have collected some general principles below that can help smooth the ride when developing your first customer self service application. Use the principles below together with our project plan template for implementing a CPQ.

Separating configuration rules from inputs

When working with complex configuration its usually hard to separate visible input fields and variables from hidden rules and formulas. A product expert usually relies on experience when configuring a product, instead of strict rules and formulas. But when anyone should be able to use a product configurator the complexity needs to be greatly reduced, resulting in the requirement of a limited set of easy to understand input fields and a extensive set of hidden formulas that captures all the rules.

Customer journey – Questionnaire for B2B products with quotations

When working with changes in the sales process its essential to have a clear view of the customer journey. Therefore we have created a short questionnaire for some of the basic questions that the sales team should discuss and try to answer.

This can result in a list with the typical steps to a closed deal that can be used when discussing changes.