Configure price quote (CPQ) introduced well into an organization can deliver significant benefits.
Unfortunately, without effective project management and the right approach, these benefits can take much longer to materialize or, worse, the project can grind to a halt. The reasons for this are varied, but my experience over many years indicates some common traits:
- Trying to achieve too much, too soon
- Getting bogged down with unnecessary detail
- Lack of user adoption
- Poor solution choice
Based on the successful implementation of many CPQ projects over the last 15 years, I have designed and refined a pragmatic approach across my business that minimizes risk and speeds return on investment. There are just three interrelated and self-fulfilling steps.
Before I address these, I think it appropriate to mention software selection. Having replaced ‘failed’ CPQ solutions over the years, it is my my experience that poor software choice is rarely to blame, nor is the selection process. Instead other factors are usually to blame, but the software is tarnished.
However, there is one question that should be added to the selection criteria to mitigate this risk ‘how will we address unknown, unknowns?’ These will always exist, and the answer to this question is simpler than one might imagine – select a flexible system that copes with change quickly and easily.
Assuming the selection process has been thorough and a flexible solution chosen, here are my three tips for CPQ success:
1. Assemble a team of people who want to be involved
The right mix of people on a team will differ from company to company; however, the most successful CPQ project teams I have worked with include experienced representation from sales operations, IT, and sales. With the right team assembled, the challenge is to motivate the members to contribute in a meaningful way. My experience in achieving this is to tap into their ‘intrinsic motivation.’
A quick Google of the term will provide far better definition. However, for brevity, I will summarize this as – our hardwired tendency to want to solve puzzles.
In short, a problem is clearly stated and the team is invited to address this. The key is asking the right question, which leads to the my next factor.
2. Focus on the fundamentals of the problem you need to solve.
This sounds easy and obvious. However, it is not. Often, the temptation is to focus on making the existing process better. My approach is to avoid this. Instead, encourage the team to strip things right back to the business basics. For example, the first question one might ask the CPQ team could be:
What do we need to secure more orders and process them quickly?
Time should be taken to arrive at a statement that defines the project at its most basic level. For example, an answer could be:
The fast production of great looking, accurate proposals by anyone. And a way to automatically generate the relevant order information to be seamlessly pushed into the sales order processing system.
Such an answer helps achieve two things:
- Firstly, it gives focus and clarity to the project.
- Secondly, it enables each team member to think and contribute from their perspective and experience on the bigger picture.
This should then be agreed with the stakeholders and communicated to the wider organization as the stated project objective and the key deliverables. It is also important to set the expectation for an incremental approach that will evolve. It may be that these deliverables are achieved in different and better ways than how it is currently envisaged, which leads to the third and final step.
3. Plan for incremental steps that you can build on
We know the desired end point. Exactly how we get there can remain vague for now. The focus should be to agree some simple, achievable first steps that align with the key deliverables.
Using the example above, we might judge the first step is to enable all users to generate an enhanced proposal document through the new CPQ system. To achieve this, it is usually necessary to consider the individual components of the products and, or services offered, the pricing of these, and, essentially, the presentation of these to maximize the chance of winning the deal.
This is a step where it is easy to get into too much detail or become daunted by the number of products. Our approach is the adoption of what some might consider a counterintuitive and backward step.
We advocate a focus on the document components, then work on building generic screens to do this manually. We deliberately resist the urge to add rules and complex calculations at this stage - even if this is easy to do. There are three reasons we do this:
- It is faster to build out and demonstrate 'success’ to a business.
- Vitally for leveraging team members intrinsic motivation. This leaves room for them to consider and contribute in making the better solutions.
- It results in a faster and smoother adoption of the system, particularly when the users suggestions are quickly introduced.
Having delivered on our first step we can address the next. Each project will differ; however, we find that asking the team to consider the following works across many scenarios:
How can we make the manual process easier?
How can we prevent errors?
Addressing this is easier when the team has a starting point on which to focus. Our experience is that the team will offer their advice plentifully on how things should be improved or streamlined. This will form the basis for your next steps.
To maintain momentum, the suggestions from the users and team must be acted upon quickly. Our approach is to prioritize the requests and ideas into smaller, incremental deliverables. If the above steps have been followed, there will be some easy wins. Then repeat the above approach through as many iterations as are needed.
We adopt this approach as a guide and refine as appropriate. I hope you might find it helpful in delivering CPQ benefits to your business.