August 6 by Conga
Implementing CPQ is much more than a technology implementation. When done properly, it transforms the way enterprises price and sell their products and services. Having delivered many successful CPQ transformations in my career, I’d like to share my experiences around planning for a successful programme.
Preparation Is Key
The more thought that goes into a transformation before the technology implementation starts, the more successful the transformation will be. More value will be delivered to your organisation, with reduced risk.
Firstly, align your transformation to your strategy. From your Go-To-Market strategy to your overall architectural and roadmap, having a clear vision of where you want to go makes actually getting there much more likely.
Strategy alignment will also generate clear objectives for your transformation programme and can include principles that will drive the design of your future operating model. Objectives must be accompanied by KPIs that baseline your current performance and demonstrate the improvements that the transformation will deliver.
It is crucial to obtain executive sponsorship at this stage. Commitment from the top, including pledging resources, demonstrates the importance of the transformation to your organisation. This leadership must be visibly maintained throughout the programme.
Now, on to the CPQ-specific preparation – product & pricing rationalisation. Typically, products and pricing evolve over time; products are added and pricing models change, often without retiring the previous ones nor providing a holistic view of the desired future state model. This results in product proliferation and pricing complexity. Your transformation is an opportunity to rationalise and remove complexity, retire old products, and to simplify your pricing models. Without rationalisation, products and pricing can take longer to design and build, and you may pay more for their in-life maintenance after the implementation closes.
Early Value Delivery
Delivering value early via phases has many advantages, so I am always surprised when programmes go for a “big-bang” approach. On paper, a single large release may look cheaper, however:
Delivery risk is higher. There are more things that can go wrong with less time to correct, more stakeholders to engage, more integrations, and so on.
On paper, multiple phases may take a little longer and therefore cost more. However, in practice, big slippages are far more likely with a single release.
An initial phase starts delivering value earlier. If you look the business case, your programme may start to self-fund, but it is certainly likely to offset the additional cost of multiple releases.
An early release gives you the ability to flex as your business changes and act on feedback, by incorporating changes in subsequent releases, as well as building momentum and positivity around the programme.
You need to choose a way to split your scope into multiple phases; typical dimensions are Business Unit / Team, Region, Country and/or product categories.
Celebrating Success and Continuous Improvement
Finally, after your first go-live you can start to measure the KPI improvements against the baselines you previously defined. You should plan for a culture of continuous improvement, considering how your new solution will be supported from business and technical standpoints.
I hope you find these recommendations useful. Please reach out to me on LinkedIn if you would like to discuss these further.