Article originally published with Xactly in preparation for CompCloud 2017. Author: Jason Kearns, Canidium VP of Technology Services.
In my years of experience helping companies automate compensation solutions, I’ve seen a lot of things go right, and a few things go wrong. As a consultant, I take a lot of pride in helping organizations overcome obstacles during system development, and the most frustrating obstacles are excess requirements.
Excess requirements are requirements for processes or features that don’t positively impact the desired outcome of the solution relative to the cost of implementation. Usually, the requestor doesn’t realize requirements are excessive. (Hence the problem.) Functionality, if costly to implement, can hurt ROI.
It’s like a city requiring all fire engines to be red, even if the cost of red paint were three times higher than the other colors. It’s a requirement — and hence a cost — imposed that really doesn’t impact the true value. Fire engines help put out fires; the color has almost no impact in the long run.
We see excess requirements all the time in compensation systems. Certain excess processes are lumped in with valuable requirements for a variety of reasons. The requestors aren’t trying to be mean. Here’s what may be behind their answers:
In my experience, there are some common areas where organizations have accumulated excess requirements. Here are the top five:
I suggest the following thought process for addressing requirements during the discovery phase of a project. The primary focus should not be telling the customer what to do – instead, it should be listening to determine their true intentions.
Sometimes there is value we don’t see because we’re coming from a different perspective. Sometimes our fresh perspective can help…as long as we talk through it.
Here is an example of addressing requirements:
If yes, just do it and pick another battle to fight. I’ve built many compensation features that seemed unnecessary, but were easy. For example, a client once wanted to calculate and display a measure on a compensation statement that showed the number of units needed to achieve the next level. It’s anecdotal at best to suggest this is truly motivating on a compensation report (since they also had plenty of daily sales performance reports), but it wasn’t costly, so we obliged.
If no, then ask…
If yes: Customers can come to this conclusion because plans and processes are stale, and haven’t been calibrated in a long time. I’ve had customers remove entire sections of a comp plan, because they finally realized it wasn’t serving any real purpose. Good candidates for this are SPIFs that have never been removed, and therefore, aren’t really SPIFs anymore. On the other hand, I’ve had customers still implementing logic to pay commission for selling products the company doesn’t carry anymore.
If no, then ask…
If yes, this could be simply changing the way a calculation is done. I once had a customer who pro-rated bonuses based on business days in the position for the quarter. Most compensation systems can more easily calculate days in a position based on calendar days. After some analysis, it was evident that this change didn’t have a huge impact and still served the same purpose. Success! This is why listening is important. Most customers don’t want to hear what the system can’t do, they just want a solution. You need to figure out the true purpose.
If still no,
Then let’s look at the cost of building and maintaining, and weigh it against the benefit. Perhaps it makes sense to keep this specific function manual. I’ve had customers with very complicated chargeback policies that required a great deal of logic. For example, a retail bank paid for new checking accounts, but required a certain threshold of balance and activity over six months – or the commission was charged back. We discovered that the chargebacks kicked in very rarely, and it wasn’t worth the cost of automating. Instead, we developed some reports that made the pertinent information easily available for review by an analyst. In 20 minutes a month, this person could determine if chargebacks were necessary and could issue an adjustment. Sure, we could have fully automated this requirement, but there wasn’t honest ROI in that effort.
Change isn’t easy, but it is justified when it’s giving you more reliable functionality at a reduced level of cost and effort.