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 it’s 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
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 it’s 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 (“it’s 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 it’s involvement.
5 – Insist on high skill requirement for the end user
An effective way of making sure that no one will use a product configurator when its launched is to insist that the end users has to be someone similar to the most experienced individuals in the internal Engineering team. This way you will end up with a product configurator that has hundreds of advanced input fields to choose from and complex naming of every choice, ensuring that only people that have been in the business for many years can use it (“it has to work exactly the same as our internal processes”). With too much choice, advanced information and edge cases (see section 2) no junior or external individual will have the time or capacity to learn a new complex tool built for internal Engineers that they most likely wont use that often anyway.
6 – Refuse to test anything before it’s bug free
The Engineering team can refuse to use any prototypes of the product configurator before it’s 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 it’s 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.
7 – Invent your own cloud IT infrastructure
Since most of the Engineering teams internal tools are installed on local computes and internal servers it’s 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.
8 – 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.