Stay connected with latest information about sales performance management

Contemplating SPM Automation Tools? Is Your Organization Ready For The Road Ahead?

road2Sales Performance Management (SPM) involves multiple business processes, and hence, the procurement and implementation of an SPM Tool (such as Callidus, IBM, Xactly) requires a significant amount of planning and effort.

The planning must start long before you schedule vendors demos. There is no point in conducting vendor demos if your organization is not yet prepared to travel the road towards SPM automation. So how do you go about evaluating your preparedness?

To determine your organization’s readiness for an SPM tool, here are the top 10 questions you should answer:

1. What is the Business Justification?

The answer could be Cost Savings, Enhanced Reporting, Operational Efficiencies, Auditability, Calculating Payments or something related. Whatever it may be, if you can’t come up with a couple of strong business justifications, you will find it difficult to make a business case for the tool. Although it doesn’t all have to be about the financials, you have to be ready with a worksheet that shows the numbers. To learn how to build a business case, here is a link to a webinar that could be very helpful to you:

2. Are the Executives on board?

Have you discussed your plans with your executives? Do they understand the high level budgetary needs for such a project? Do you have their verbal nod for a ballpark budget?

If your executives aren’t okay with the estimated budgets, maybe you have gotten ahead of yourself. Save yourself some time and initiate the vendor demos only after you see your executives warming up to the idea.

3. Are Compensation Plans Stable?

The most common reason for SPM implementation failure is that the compensation plans are in a state of flux, sometimes even changing while the implementation is in progress. Are your organization’s comp plans still going through significant changes because of evolving market landscapes?  If so, you will have a tough time keeping your SPM implementation on track.

Taking this into consideration, you are not ready for an SPM tool. And yes, when you are told that the tool can handle all future changes without any time or effort, take it with a grain of salt.

4. Do you have enough Time?

From vendor demos to go-live, SPM projects will take no less than 4-5 months. If you are too close to the beginning of the new Plan Year and the deadline for Pay file is already in sight, you have probably missed your window of opportunity. If you decide to move forward at this point, you will be scrambling to move fast, thereby compromising the quality of your decisions, and creating a huge risk to the project overall. You are better off planning a mid-year rollout, which will have its own challenges, but at least you have time to plan for it.

 5. Are Business Processes Mature?

When the organization is growing rapidly, HR and Finance are constantly tweaking the organizational framework. For this reason, or maybe due to a recent M&A, if the processes and policies in the organization have not yet been solidified, it is difficult for the implementation team to configure the new tool.  A lot of time and effort would go to waste in changing the tool configuration again and again.

For example, if the new hire draw policy is changing every few months, the SPM tool can’t really be successful.

6. Do you have IT Systems providing Reliable Data?

SPM tools can’t operate in a vacuum. If you don’t have HR systems providing reliable Payee data or ERP systems providing sales data, you will have huge challenges with the SPM tool. Garbage in, garbage out. For instance, if new hire notices are coming to the commission administrator on Post Its, you are not ready for an SPM tool. You must first invest in HR tools and processes.

7. Is IT Leadership ready for one more Tool?

SPM implementation projects require IT budget and resources. If the IT team has resource constraints, or there is another large IT initiative, such as an ERP upgrade planned for the year, then IT will not be very happy about supporting an SPM implementation. A quick synch up with your IT leadership would help ensure that no such major roadblocks exist.

8. Is the Cloud an option?

Almost all major SPM tools are now available only as SaaS solutions, where the software is hosted in the vendor’s Cloud. What that means is, if your organization has a strong preference for On-Premise solutions, your choice of vendors becomes very limited.

It’s better to clarify with your business leaders if Cloud solutions are an acceptable option. If not, knowing the road map for all software vendors, you may want to abort the idea of packaged solutions or wait for your organization’s mindset to change.

9. Do you have Resources to support this Project?

After the tool is implemented, you may be able to cut the headcount in commission operations. But initially, you will have to dedicate a great deal of time and energy in evaluating and implementing the tool. If you are unable to free up any of your current resources and can’t find the budget to hire external consultants, it will be extremely challenging for you to get this to the finish line.

10. Is there an M&A on the Horizon?

Last but not least, if there is an M&A on the horizon, it’s better to wait on an implementation project. The new company may already have an SPM tool, and it is almost guaranteed that your business team will want a single SPM tool catering to the joint salesforce.

If you need further assistance with getting you prepared for an SPM project, please contact us at

How To Measure The Success of Your SPM Implementation

During an RFP process, I was in a customer reference call and a question came up – Did you have a successful implementation? They gave their answer but it got me thinking – what exactly defines the success of an SPM implementation? Of course the straightforward answer is within-budget and on-time delivery. But what are some of the other metrics besides the obvious?

SPM projects are intended to deliver much more than just $ savings. Therefore the conventional ROI calculation doesn’t work here. Some of the non financial parameters to consider :

  • Time/Effort in Comp Administration- Has the system enabled you to normalize headcount or working hours?
  • Sales Incentive Plan Document distribution – Are those being routed on time?
  • Agility in making Comp Plan changes – Are you able to make quick changes to comp plans, or do you still have to push back?
  • Commission Forecasting Accuracy – Are the actual and forecasted numbers comparable?
  • Fiscal Year Beginning Draws – How long are the payees on draws before actual commission is paid?
  • Volume of Disputes – Is the team now able to catch issues before they become disputes. How quickly are discrepancies resolved?
  • Meeting Payroll deadlines – Is it a comfortable run to the finish line, or is it still a mad rush?
  • IT Support Head Count – Has it reduced? How much value is the support team adding?
  • Reporting – Do sales folks actually understand and use the reports? Do the reports provide necessary insight to higher Sales Management?

If your answers to all or any of the above is positive, then you have a winner!

ICM Implementation Project Gotchas – Part II

In my last entry, I talked about the issues involving project objectives, software selection, business processes and data feeds. In Part II, I will cover common issues during implementation and testing phases.

Over Customization – As I have stated in the previous post, your best bet is to buy a product that fits most of your needs OFF THE SHELF. Sure, customization does address some of the needs but the overall outcome may nullify the positives. It can put the package out of warranty, cause support problems and lead to performance issues. Performance and other benchmarks provided by the vendor are useless in case of significant customization. So educate your stakeholders about the risks of customization. Learn to live with what you get out of the box!

Insufficient and Inaccurate Test Data – Often times, customers are reluctant to release real data(customer numbers, revenues, account numbers etc.) to external consultants for testing. I strongly recommend using a data scrambler to hide the real numbers but use SIMILAR VOLUME of data as it is in your production system. Compromising on the quality or volume of data leads to poor testing. If you can’t get a data scrambler, put in adequate time to generate realistic data and scenarios. For instance, generate enough data to walk each tier of a Rate Table.

Too many reports – Prioritize. Prioritize. Prioritize. Loading up the project with too many reporting requirements causes a huge distraction from the main objectives. Break down the reporting wish list into multiple phases. Identify the ones that are absolute must-haves for Phase I and defer the nice-to-haves to Phase II. The fewer reports you have to deal with in Phase I, the better your resources can focus on the more important aspects of the project.

Perpetual Parallel runs – I have seen parallel runs go on and on and take over the entire project. It not only drains the budget and resources, but also risks the Project Go Live! A common mistake is to perceive parallel runs as ‘extended testing opportunity’. It is important to remember that the objective is to prove the integrity of the new system and not achieve a 100% match between the two systems. In order to manage a parallel run, limits need to be set and cross-checking criteria clearly defined. Set up a weekly status review to do a health check and resolve issues ahead of the go-no-go decision. It is important to publish a date for the end of parallel run, so users are prepared to cut the chord when the time comes.

Unclear Go-No Go criteria – The previous point leads into this one about defining the acceptance criteria for the new system. If limits aren’t set on what is acceptable and what is not, it is impossible to change over from the old system to the new. Projects are seen to be abandoned at this stage not because the testing did not meet the criteria but because of lack of clarity on the acceptance criteria.

When to Go Live? – It is common for business teams to overlap the go-live with the new fiscal year roll out, so they can get away with one time testing for both the projects. This is a double edged sword since the testing scope is generally very different for both the projects. In my experience, it is a better to keep the two projects independent from each other, especially in large scale implementations. The project team gets overwhelmed by taking on both the projects simultaneously, leading to poor planning and testing.

This brings me to the conclusion of the list. There are a lot of things that can go wrong in a perfectly well thought out project. Timely action can prevent the project from going off track but just being aware of what can possibly go wrong is a first step in the right direction.

Your comments are most welcome!

ICM Implementation Project Gotchas

Every growing business feels the need at some point or another to automate their day to day business processes. This means they are implementing software of some kind, be it CRM or ERP or ICM. But how many actually do it the right way? Where do they go wrong? Why does this happen?

I have been involved in ICM implementations for a while now and in my experience, a very small percentage of the overall success actually depends on the software being implemented. It is the treatment of the overall process that is the bigger contributor to the success or failure of a particular implementation.

And no, I am not alluding to any particular ICM package. The issues are common irrespective of the package.

So what are the common gotchas for ICM implementation projects?

Here are a few of the common pitfalls that I have experienced,  listed in the order as they crop up in the project cycle. The list is long, so I’ll spread it out over a couple of posts. Here is Part I.

a. Cloudy expectations

A typical ICM project goes much beyond business process automation. It also entails issues like business strategy, employee morale, contractual obligations etc. Often times there are multiple  stakeholders including HR, Sales, Finance and Legal to name a few.  Each one of these stakeholders has distinct and sometimes conflicting objectives.

It is crucial to agree upon a list of common project goal(s) and priorities.  Make it loud n clear, that not all goals would be met in phase 1. Be prepared to articulate a roadmap for subsequent phases, in order to get the buy-ins for the initial implementation.

b. Shoe doesn’t fit?

There are a lot of vendors in the market for ICM software – Callidus, Xactly, Merced etc.  Accept and broadcast the fact that no off-the-shelf package can solve 100% of your  problems. Pick a vendor that can handle majority of the requirements out-of-the-box. Don’t wast time trying to fit every single exception into your RFP and vendor evaluation. Treat exceptions as, well, exceptions!

Look at what your industry peers are doing. I like the analysis provided here by Julien Dionne on industry sectors and their choice of ICM solutions.

But again, as I said before, doing it right, is more important than choosing the right package. So after the decision has been made, focus all the effort on the actual implementation.

c. Rigid Business Processes

If you have chaotic processes, implementing an ICM package may quite well end up in automated chaotic processes. The message here is to examine the business processes, streamline them or even redefine them if needed and better leverage the new software.

Adapting the business processes to the new system would increase the overall productivity and offer the biggest bang for the buck.

It is sometimes difficult to get all stakeholders to be flexible. Getting  an industry expert to work closely with admins and IT to provide recommendations might be a way to obtain signoffs on new processes.

d. Devil is in the Data

Garbage in garbage out! And if it comes from multiple sources, it is gargantuan garbage.

Data Reconciliation is especially crucial in a Compensation system in pretty much all the areas since it a system of records for commission payments. There is no room for errors. Spend enough time to analyze each and every data source.

Consider a scenario where order information is coming from a channel partner’s order system. One can’t really control the quality of data coming  from various partners. Take a count of various such data sources and put a plan in place to deal with each one of them. If you cut corners now, be ready to deal with testing problems later.

So IN SUMMARY, if you take care of setting realistic project objectives, realigning processes and analyzing the data feeds, your project should have a solid foundation.

The road ahead has some more challenges, so stay tuned for my next post.