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.
Why Do Excess Requirements Exist?
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:
- “It’s the way it’s done today.” Translation, “I don’t know why because I’m new here.”
- “I have to do this manually now and I want to automate it.” Translation, “I’m not sure how often I have to do this, but I know it’s painful because I had to do it yesterday.”
- “Our people are used to this.” Translation, “I’m scared of asking people to change.”
- “This protects us from some bad behavior.” Translation, “An auditor might shame me publicly.”
- “Our charter is to replace the existing process.” Translation, “I’m not the decision maker.”
Common Excess Requirements
In my experience, there are some common areas where organizations have accumulated excess requirements. Here are the top five:
- Specific rounding rules: There are a couple of different ways to round decimals (bankers, scientific) and some organizations have decided to round or truncate values for the purposes of compensation simply to be consistent and/or predictable (e.g., treating attainments as thresholds whereas 99.9% = 99% and doesn’t round up).
- Complicated proration logic for new hires, transfers, leave, terminations, etc.: Usually, these rules are in place to enhance fairness and reduce windfalls. They can get quite complex when all possible scenarios are counted. It makes sense to analyze the most common scenarios to determine the true value of automating something that could easily be handled manually or as an exception process (e.g., pay new transfers at target for a month or two).
- Over-engineered policies for keeping payees “whole” during certain situations outside their control: Plan designers can get quite clever when trying to account for seasonality, territory transitions, quota ramps, etc.
- Complicated chargeback policies: Rules that must measure activity over time and potentially retroactively adjust pay are always complicated. Especially when you must account for payees’ changing jobs and other system or plan changes along the way.
- Sacred reporting designs: Some organizations have strict mandates on fonts, colors, and other aesthetics. Some have current statements they simply want to duplicate, but haven’t done a lot of analysis. We suggest doing what is relatively easy to build and support, while providing the right data elements.
How Do We Deal With This?
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:
Once you hear something that seems excessive, first ask yourself, “Is this easy to build?”
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…
“What is the core purpose of this requirement? Can we do without it?”
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…
“Can we find an alternative that is easy to build and fulfills the purpose?”
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.