Project Direction
This Seems Complicated
Wednesday, March 11th, 2009 | Compensation Plans, EIM, Project Direction, SPM | No Comments
In fact, all of these items are likely to affect the performance of your sales force. A recent Scientific American article by Wray Herbert describes a concept related to our brains’ processing. Herbert discusses the possibility that how a task is described may affect our willingness to do the task and, if we decide to do it, how difficult we expect it to be. Herbert notes that psychologists are interested in “the complex interplay of effort, motivation and cognitive crunching” and cites a study conducted by two University of Michigan psychologists, Hyunjin Song and Norbert Schwarz that investigates the notion.
In the study, Song and Schwarz presented all test subjects identically worded instructions for a task. Some subjects received the instructions printed in the easy to read Arial typeface while others were printed in an elaborate difficult to read font called Brush.
Herbert’s article comments that “there are many ways to make something mentally palatable – or not. You can use clear, straightforward language or arcane vocabulary words; simple sentences or convoluted sentences with lots of clauses.” To simplify the experiment’s execution and provide a scientifically sound apples-to-apples comparison, the psychologists chose to simply vary the font.
The findings were quite interesting. One of the tasks used in the test was the making of a sushi roll. Those given the Brush font instructions estimated that the task would take longer and be more difficult to accomplish and, most importantly, that they would be less motivated to attempt it than those given the same instructions in the easy to read Arial font.
Your sales compensation plan is in many ways an instruction set for your sales force. This study demonstrates that something as seemingly inconsequential as a font choice (albeit Brush font is hideous) can have a measurable statistically significant effect on the perception of a task’s complexity. Compensation plan designers and comp administrators should certainly not underestimate the potentially negative impact of very complicated plan component calculations. In fact, most experienced plan designers are well aware of this. We get a lot of requests from clients asking for help in “simplifying” their plans. Perhaps less obvious are the potential impacts of the clarity of the compensation plan documentation and even the document’s font. Don’t underestimate the impact of even small changes to your compensation program. If there is a choice of comparable options, opt for the simpler. If you can’t tell which option is simpler, present plan communication options to a test group and ask for feedback. Ask them what they’d be motivated to do after reviewing the plan. Be careful not to confuse your sales force; selling is complicated enough.
Similar Posts:
- Can you explain your company’s sales comp plan to a 2nd grader? - MichaelStus
- What’s Your Magic Number? - MichaelStus
What’s in a name?
Tuesday, February 17th, 2009 | EIM, Project Direction, SPM, humor, large projects | 1 Comment
As humans, and if you’re reading this you most certainly are a human, we have a biological need to name everything around us. Whether it’s insects, rocks, cloud formations or psychological disorders… it needs to have a name. In fact, upon encountering a new object such as a star, the first thing we humans do is name it.
Manmade creations such as software systems are not immune to this. When we burn long hours putting in a new HRMS, CRM or SPM system we need to put a moniker on it so that we can communicate. The interesting thing is all systems get a name whether we force them to or not; they take on a name in one of three ways:
1. We can’t think of anything.
Most times there isn’t much thought put into naming a system but it takes one anyway. In this case, probably due to the enormous amount of marketing done before and during the project, the overall system takes on the name of the major software vendor involved. We see many SPM clients refer to their system as the Callidus or the Oracle tool. The problem with this naming method is it is often the case that the calculation engine is but a small part of the overall system. Subsequently, the brand either suffers or benefits from elements it can’t control. Basically anytime anything goes haywire all you hear in the hallways is… “It’s Callidus again; that thing never works.” Who cares if the problem was due to bad data from SAP or a botched network upgrade rather than the vendor software product itself? The name gets the blame and the brand suffers. Many front line reps hate their SPM software vendor and have no idea why. This also hurts the IT department in the long run when they need to make decisions about upgrades and future applications. If you choose the same old vendor who everybody hates, you don’t look very smart.
2. We can’t think of anything but we know what NOT to call it.
I’ve been a part of some real initiatives with clients where they really and truly want to come up with the perfect system moniker… but couldn’t. Either they couldn’t agree or they just didn’t get any great ideas. All they know is they don’t want the words Callidus, Oracle or Varicent being spoken in the halls. This noble effort still produces a name, just not a very creative one. Constituents begin calling it what it is, the system that calculates their paycheck. Usually something like: The Commission System or the Bonus Calculator. In some cases the tool takes on the name of one of its creators. This is how you get enterprise level systems with names like: The Jared Tool or The Tom Report. I personally love it when reps refer to the entire SPM system as a “report”. Another de-facto name origin can be the database where your application’s data resides. That’s how you get names such as MRDB (Management Report Database) and ICDB (Incentive Compensation Database). Usually this kind of name would be relegated to the IT department. Then you might have the unfortunate multi-name situation where IT refers to the system as ICDB, the reps call it The Tom Report and HR calls it The Bonus Calculator.
On a side note, I once worked on a project where two months in we put together a nice big workflow diagram with 21 steps represented as boxes. The boxes were numbered 1 to 21. Two of those boxes ended up becoming user interfaces that were developed roughly 18 months later. What were the names of those new applications? The Number 7 Tool and The Number 13 Tool. We hadn’t bothered to come up with better names and by the time we decided to try it was too late. The original names stuck even though very few people on the team had any clue as to what those names originally meant. I bet there are plenty of similar stories out there.
3. Let’s name this thing properly.
Occasionally companies want to name the system and they do it successfully. The “perfect” name apparently is an acronym that cleverly describes the system and also serves to be a decent name for a compensation system. Here are some good ones.
These are the best I’ve seen.
COINS – Commission and Incentive System. I’ve seen this one at least three times.
CECS (pronounced checks) – Commission Earnings Calculation System
Here are a couple I’ve seen that are at least real acronyms.
CABS – Commission And Bonus System
SCARAB – Sales Commission And Reporting And Bonuses.
On the lighter side, here are some names that didn’t pass either because they’re border line vulgar or downright mean spirited.
CRABS – Commission, Reporting, And Bonus System
CRAPS – Commission, Reporting, And Payment System
MAGIC – Mostly Accurate General Incentive Comp
CLOSE – Commissions and Liabilities Operations System for Employees
ALMOST – Automated Liability Management Of Sales Transactions
ENOUGH – Employee Operational Unit Gage Heuristics
GUESS – Genuine Underwriting Employee System
SCARI – Sales Compensation And Reporting Infrastructure
ACE – Almost Calculates Exactly
CRASI – Commission, Reporting And Sales Incentives
OPTIC – Over Pays Their Incentive Compensation
UPTIC – Under Pays Their Incentive Compensation
No doubt there are many more out there and we’d love to hear them. We’re fascinated by the genealogy of system names.
Similar Posts:
There’s Value in the Journey
Tuesday, December 16th, 2008 | Compensation Plans, Project Direction, large projects, requirements | No Comments
We’ve all the heard of the Law of Unintended Consequences, that is that actions of people always have effects that are unanticipated or unintended. Although this term is typically used to describe government, I’m sure most of us have experienced it. Those of us in the realm of sales compensation know all about this Law. A move that seems beneficial one day can expose massive consequences the next. Conditions are always changing and you can debate decisions for weeks without truly understanding the impacts. But let’s not get too negative here. Why do all Unintended Consequences have to be “Consequences”? Many benefits can also come without warning. The world of R&D is teeming with examples of projects gone wrong leading to breakthroughs in unexpected areas. This kind of serendipity need not be reserved for those in white coats. We should all keep an eye out for the “good” in all this uncertainty. Most of us already agree that all decisions are temporary. That’s why a push to having more system flexibility is vital to having up to date and effective incentive plans.
The need for more flexibility usually leads to a new system altogether. This brings about the most critical decision of all… what do we build and how? So let’s do assessments, let’s do vendor selections, let’s diagram and hypothesize to our hearts content. ROI analysis needs to be done and the numbers have to work. Can we drop headcount? Can we reduce overpayment? What’s the value in turning around plan changes faster? How many hours per day will our sales force rededicate to selling when their reporting is better?
I love the early theorizing about a new system. There is always such optimism. Compensation Managers and Compensation Administrators are usually dying for some sort of relief from their current predicament. I love bringing that relief. I’ve been there and feel for them. That being said, it is rare that the final delivery of a system lives up to these initial dreams. No matter how “realistic” we try to be, the road to get a system up and running always takes a toll on scope and budget.
This is where I offer some encouragement. The Journey brings its own rewards. Often times, we focus so hard on the finish line and lose sight of what we’re learning every day. Take this list of tasks:
· Processes
o Document system workflow for compensation calculations.
o Document business operations workflow for compensation calculations.
o Define ideal skill sets and headcount for IT and business operations.
· Comp Plans
o Obtain catalog of current plan documentation.
o Devise method for managing plan change version control.
o Agree to SLA for turnaround on plan changes.
o Define all key data sources and data elements needed for current and future plan calculations.
· Reporting
o Discover true business critical end user reports and their requirements.
o Investigate need for ad-hoc analysis reporting.
o Define all key data sources and data elements needed for current and future compensation reporting.
· Testing
o Create test cases and methodically test calculation scenarios.
o Identify gaps in automated functionality and devise adjustment procedures that satisfy SOX.
All of these tasks are part of a typical systems implementation. Notice that none of them actually require the building of a new system. Yet, not many organizations can afford to spend time doing all of these tasks without the pretense of a large new system development. What is the value in doing all of these things? In many organizations these would be monumentally valuable especially if you start uncovering gross errors or if your lack of documentation is hurting your ability to handle turnover.
My point is to appreciate the Unintended Benefits of your project—not all unintended consequences need be negative. If you can find a way to predict these benefits, then an ROI case can be made; regardless, at the end of the day going through this process can improve your organization if you take proper advantage.
Similar Posts:
- #2: You painted the wall from bottom to top - JasonKearns
- EIM / SPM system upgrade: port or reengineer - MichaelStus
Beware of unneeded system flexibility
Sunday, October 26th, 2008 | Project Direction, large projects, requirements | No Comments
Software package implementation including EIM/SPM software can be a complex process and many projects are not successfully delivered or are done so over budget. One issue that often causes trouble on projects is the introduction of functional flexibility that is ultimately unneeded. Many times when a business owner is asked about a particular business function there is a tendency to overstate the need. For example plan sales compensation plan administrators often say they need the ability to change a particular commission rate or rule effective at any time, even multiple times within a pay period. In reality based on how the compensation plan is constructed, it may make no sense to do so and the practice may actually never be done this frequently.
Why should software systems implementers and the eventual owners worry about this unneeded flexibility? The simple answer is that if these requirements make it into the final feature set to be delivered, costs can increase dramatically. The direct relationship between feature addition and development and delivery costs is obvious. Additionally, in severe cases of unneeded feature bloat, the system may become undeliverable. Finally, unneeded flexibility may result in a system with increased complexity causing higher post implementation maintenance and operational expenses.
What drives the introduction of unneeded requirements for a software system? Several that I have experienced:
• Business owners do not want to restrict themselves – Business owners do not often find themselves being asked what they want in a new software system. Not wanting to blow this chance, they have a tendency to cloud attention to true practical business need with a kid in a candy store mentality. Additionally no business owner wants to be remembered as the one that gave in on a system requirement that down the road hinders business function. Erring on the side of caution for a business owner means always answering requirements inquiries with the most flexible feature rich driving answers regardless of true business need.
• Limited access to true statistics on business process – A well designed system should best satisfy the automation of business tasks that are most frequently performed and that are most critical to success of the enterprise. Often though, true data about the frequency at which certain business events or functions occur is not known; project timelines often discourage proper analysis which would provide data crucial to the best requirements set determination.
• Inexperience among requirements gatherers - Business analysts or others who have been assigned to gathering system requirements may lack the experience to ask the right questions of more seasoned business experts that will own the system being developed. Additionally, if these business analysts are not familiar with the workings of the proposed software, they miss opportunities to steer or corral functional requests into the most implementable options.
How can this issue be addressed? More education about system delivery process across all members of the project team can help. Business owners and business analysts can benefit from a better understanding of how the software works. Additionally these team members should not be isolated from the development and eventual operational costs associated with the decisions on requirements and feature set determination. Requiring business owners to justify requests with real statistics about the frequency of occurrence of scenarios driving their inclusion can help distinguish absolute from exaggerated need. Finally, understand going live with a system with the critical subset of all desired functions is an option; plan for additions but allow time for the evolution of business process that certainly take place with its introduction to dictate their priority. Encourage all parts of your delivery team to keep these ideas in mind; sacrificing some functional flexibility is well worth avoiding a poorly designed, difficult to operate, or undelivered system.
Similar Posts:
- EIM Solutions Resist Commoditization with Supplementary Features - MichaelStus
- There’s Value in the Journey - JasonKearns