Archive for June, 2008

SPM News – Big News for Callidus, Varicent and OpenSymmetry

June 26, 2008

Varicent Software Announces Strategic Partnership with OpenSymmetry
Varicent Software, an innovator and provider of the only comprehensive application for sales performance management (SPM), recently announced a strategic partnership with OpenSymmetry, a largest independent consultancy specializing in sales performance management.

Other partners of OpenSymmetry include Actuate, Callidus Software, nGenera, Oracle, Sungard, TerrAlign and Xactly.

Callidus Software Broadens Performance Management Capabilities with Introduction of TrueTarget
The new SaaS-based software module, TrueTarget™, combines SPM and Employee Performance Management (EPM) capabilities to deliver Pervasive Performance Management (PPM) across the entire enterprise. The concept of PPM offers a single, business-wide, pay-for-performance solution for companies.

Pervasive Performance Management goes beyond standard incentive compensation management and includes objectives alignment, goal management, bonus allocation and employee evaluation.

I could be wrong, but as far as I know the only other major vendor currently offering a similar end-to-end solution is SuccessFactors. [Disclaimer: I have not seen Callidus TrueTarget or any of SuccessFactors’ solutions yet]

Don’t Automate Chaos

June 25, 2008

I came across an interesting article by Roy Altman: Avoiding “Gotcha’s” – Tips and Techniques that Drive Successful Implementation Projects.

Roy describes some of the common pitfalls that can undermine an HR System implementation project, including the importance of getting buy-in, of planning early, of knowing your organization, of not reinventing the wheel, etc.

There is one point which I haven’t talked about on this blog so far: Don’t Automate Chaos.

If your processes currently result in chaos, and you automate them, you end up with automated chaos.

That’s something a lot of companies implementing EIM solutions don’t always seem to understand. Many Compensation System implementations are subject to delay, budget issues or even failure because processes are not re-examined. Implementing a new large-scale system should be seen as an opportunity to redefine and improve these processes.

In a typical Customer Relationship Management (CRM) implementation such as SAP or PeopleSoft, business processes generally have to change to be in line with the application. However in the case of an EIM solution, it is easy to make the mistake to try to implement the system in the same way it is currently working… and that can result in automated chaos.

When planning your implementation, set some time aside to map out existing processes and logic to assess if/how they can be improved. Better processes should result in a higher quality implementation which will fulfills business requirements.

Sales Performance Management Glossary

June 24, 2008

There is a lot of very specific terminology used in the world of sales performance management. Different vendors may use different terms, so it is important when starting a project to make sure everybody understands what is what to avoid any confusion.

Callidus has an excellent lexicon of incentive compensation terminology. Here are some important terms used frequently:

Bonus: A performance-based reward or payment to an individual, team, business unit, or work force, made in cash, stock, options, or other form.

Calendar: A set of continuous, non-overlapping periods that define when a compensation plan is in use.

Commission: One type of incentive, often expressed as a percentage of sales, gross margin or dollar amounts per unit sold.

Credit: The amount of credit received for making a sale, where revenue is usually the measure for sales credit, although sometimes the number of units or some other measure is used.

Draw: Cash payment advanced against future income. There are two types: non-recoverable and recoverable.

Formula: A method of calculating compensation that relates pay opportunity to performance achievement, generally falling into one of three categories: 1) Unlinked incentive formula; 2) Adjusted-value incentive formula; and 3) Linked-incentive formula.

Lookup Table: Multi-dimensional: Created by the user to store values for use in rules and formulas.

Participant / Payee: Person participating in your company’s variable compensation program.

Plan: A collection of rules that specify how to compensate the participants assigned to that plan.

Position: Defines a specific, unique job.

Quota: A predetermined sales performance goal, expressed as a percentage, percentage change, in absolute numbers, or in units sold.

Quota Attainment: The percentage calculated from dividing the amount of sales credit earned (represented by a performance measure amount) and the quota for a performance period and participant.

Rate Table: One-dimensional: A lookup table used for calculating commissions. The first column in the table represents ranges of quota attainment. The second column represents the pay-out rate for transactions within that range.

: A way to filter and calculate in the form of an “if-then” statement. The “if” contains a Boolean expression that selects objects from the database (for example, which transactions to use). The “then” part contains formulas that calculate and save new values.

SPIF: Acronym that stands for “Sales Promotion Incentive Fund.” SPIF is a loose term referring to an on-the-fly addition to the compensation plan used to motivate the sales force in a particular way by providing additional sales credit or payment for certain types of sales.

Territory: A way of defining which transactions a participant should be credited with. It is usually a geographic area, but could also be an industry or a specific set of customers.

Title: Occupational grouping, such as engineers, systems analysts, etc. Titles are used to group similar positions related by job function across the organization.

Transaction: The original sales data, wich includes sub-line data on an order.

Variable: A placeholder in a rule or formula for a fixed value, rate table, or territory.

Stick to a Naming Convention – It’s not Rocket Science!

June 23, 2008

Wikipedia has one of the best definitions on the net for a “naming convention”: A naming convention is a convention for naming things. Awesome!

In the Enterprise Incentive Management and Sales Performance Management world, this means naming all plan objects in a consistent way. Naming will vary from tool to tool and there is not a single set of best practices that can be followed. Most vendors provide some recommendations, but it’s up to the implementers to decide which naming format will be used. Since there is no generally accepted “convention”, it may be more accurate to call this a naming strategy.

Why is sticking to a naming strategy important:
Incentive Compensation Management is not difficult. What makes ICM systems complex is the volume of plan elements (plans, rules, formulas, tables, variables, etc..) A large implementation can quickly become a jungle if not everybody agrees on a common way of naming different objects. Not only will it make building and testing the system easier, a good naming strategy will especially be important once the original implementation team is gone and others have to understand the logic of the system. Finally, aside from clarity, a naming strategy will also help search for plan components more efficiently.

Choosing a naming strategy
As I said, since all applications do not share the same objects, and also because each application works differently, I cannot provide a silver bullet for all situations.

Generally, I try to stick to these principles:
  • Make the name descriptive
  • Use abbreviations to identify object type
  • Begin object name with its object type abbreviation

For example, a credit rule could be called CR_AE_description. Some systems could have a direct credit rule and an indirect credit rule; in such case my abbreviation could be DC and IC instead. In some systems I may want to prefix a formula with F (if all objects can be displayed in the same view), if not, then it would not be necessary to explicitly say that a formula is a formula.

Naming of output is also important: The importance of naming an object may be obvious, but in the case of rules, the output of such rule should also be named carefully. A result name that makes sense can often by “Rule name _ result” or something similar.

Getting Started…

It is important to define a naming strategy early on in the project – before any detailed / technical design documents are created. The strategy should be illustrated on one page to enable the implementers to quickly see how to name the different objects. This “page” should be distributed to everyone involved in the implementation and be given to new joiners as well.

The first steps in defining the naming strategy is to find out if the application being used has a set of best naming practices or standards. In the case of an upgrade, it is important to stick to previously used naming strategy.

Happy Naming!

Incentive Compensation News

June 16, 2008

Julien Dionne (Me), Receives the “Hot” Nomination on Popular HR Blog
Thanks HR Wench 🙂

Merced Systems, Inc. Acquires Practique Associates Europe’s Leading Sales Performance Management Vendor
Merced Systems, the leader in Sales and Service Performance Management software, today announced that it has acquired Practique Associates, a privately held, UK-based company, and European market leader in Incentive Compensation Management (ICM) solutions. Practique Associates will operate in Europe as a wholly owned subsidiary of Merced Systems, allowing the company to continue its impressive track record of growth and profitability.

Callidus Software Ranks 4th on CIOZone’s “Surging 60” List of Fastest-Growing Software Companies
Sales Performance Management Leader Ranks Among Top Five on Prestigious List of “20 Fastest-Growing Small Software Companies”

Xactly Appoints William J. Sudlow as Senior Vice President of Engineering
Formerly withIntuit Inc., Sudlow will be responsible for all product development,engineering and quality-assurance activities as Xactly scales its product-development efforts to deliver the market’s broadest portfolio of salesperformance management applications.

SuccessFactors Announces Support for Global Organizations With Simultaneous Product Updates Across 22 Languages
SuccessFactors, Inc. (NASDAQ:SFSF), the global leader in on-demand performance and talent management solutions, today announced that it has made available a number of international enhancements to support simultaneous product updates of its monthly releases in 22 languages.

Success Factors to sell 7.5M shares
SuccessFactors Inc. said Tuesday it plans an offering of about 7.5 million shares of its common stock.

Incentive Compensation Meets HR at The Super Sexy HR Carnival

June 12, 2008

After missing 34 HR carnivals, I finally contributed an article for the 35th, hosted on Jon Ingham’s Strategic Human Capital Management (HCM) Blog.

My featured article is the recent story “The Saga of Purchasing an ICM System“, describing some of the common issues faced when purchasing and starting the implementation of an incentive compensation management solution.

Visit the carnival on Jon’s blog – it’s filled with very interesting and insightful topics from every area of HR.

EIM Solution Maintainability – Should you care about this?

June 11, 2008

People often consider buying an Enterprise Incentive Management (EIM) solution based on several criteria including cost, performance, ease of implementation, support, etc. One factor that if often overlooked in my opinion is the system’s maintainability.

What is Maintainability?
ISO 9126 defines maintainability as the ease with which a software product can be modified in order to:

  • correct defects
  • meet new requirements
  • make future maintenance easier, or
  • cope with a changed environment

Why is Maintainability important?

The ability to modify a software system is obviously important for any type of system, but it is particularly important for an EIM solution. Why? Because compensation plans, organizational data, quotas, etc typically change at least once a year. Modifying this information is not a task equally easy to perform in all software packages.

How to find out if a EIM solution is maintainable?

Any vendor will say their solution is maintainable… only an opinion from an unbiased person with experience implementing the particular EIM solution will be able to give a true account of how easy it is to maintain the application.

Effective dating plays a big role in maintainability. Being able to modify the information at anytime, but with changes effective only at a certain date, is critical to maintain a system.

Another key aspect of maintainability to consider the impact of year end on the plans. Some of the important information to find out is:

  • Are the plans still going to work at year end?
  • If plans need to be modified, how big of a change is it?
  • How easy is it to modify the quotas?
  • What about the rate / lookup tables?
  • If formulas are embeded within the tables, do those need to be modified as well?
  • How easy is it to move people in different positions?
  • What do I do when people leave the company?

It is not atypical to see a somewhat complex logic which could be impacted by a simple change. For example, a formula referencing a table which contains another formula pointing to a quota. If the quota values can just be updated, it’s not a big deal. If a new quota needs to be created, then the formula will also need to be updated to reflect the new quota.

Another example is when an EIM solution needs to be able to handle last year’s orders at last year’s rates. Depending on the system, this could mean creating new rules, new formulas, new tables, new quotas, etc.

It may not all be about the Product

Implementing a software package is a bit like custom development. A quality architecture results in the possibility to re-use components. Some programming languages are easier to maintain than others; as we discussed, the same goes for EIM solutions. However, no matter how good a programming language, a bad programmer can make the maintenance a nightmare. A bad EIM implementation team can also make the system’s maintenance very hard, no matter how good the product is.

The bottom line:

Finding out the details about how maintainable an EIM solution is, is as important as finding out other characteristics such as how easy it is to implement it. You do not want to have to re-implement every plan every year; not only because it is time consuming, but also because major changes imply bigger risks.

The first part of the battle is to select an EIM solution which will make maintenance as painless as possible, but the battle is not won until the solution has been implemented properly.

Review of Centive Compel On-Demand EIM Solution

June 10, 2008

It has been a few weeks already since Sarah Carlisle, Director of Product Management and Bob Conlin, Chief Marketing Officer at Centive agreed to give me a detailed demonstration of Centive’s on-demand Sales Performance Management solution called Compel.

About Centive

Let’s talk about Centive for a moment: Centive has been around for a while; the company was founded in 1997 and originally focused on delivering on-premise Enterprise Incentive Management (EIM) solutions for very large companies. By 2004, Centive saw an opportunity to leverage the growing on-demand market and began developing the first on-demand sales compensation management solution – this time targeting mid-market companies. In May 2005, Centive released Compel. Shortly thereafter, they divested their original on-premise application business to ensure a focus on the on-demand market.

Compel Review
Compel is another leading on-demand EIM/SPM application with a value proposition almost identical to other applications and companies I have reviewed including Callidus, Varicent and Xactly. One nice aspect of Compel is that all its functionalities are bundled within the core application (no additional modules are required for reporting, modeling, analytics, etc.). Compel is a SAS70 Type II attested application and offers AppExchange-certified integration with Centive also has an OEM reseller agreement with ADP where Compel is sold as “ADP-ICM powered by Compel.”

Many companies like Adobe,, McKesson, and Sterling Commerce selected Compel to automate their sales compensation.

Compel Interface
There are 3 main “views” for Compel, each for a different type of user: the sales user view, the manager/executive view and the compensation administrator view. All views have one attribute in common: they are all very interactive. Any report or charts displayed will provide additional information when the cursor hovers over them. Clicking generally results in drilling down to get more detailed information.

Sales User
The main screen for the sales user displays at a glance all the information the salesperson needs to know. On the left portion of the dashboard they can see their total compensation, along with some details of how the total was derived. Clicking on the underlined amounts will result in showing more details.

The central portion of the screen represents in a graphical format their year-to-date total compensation, and analytics showing earnings and performance (sales vs. target) for each of their plan measures.

The bottom portion of the screen show alerts which can be either system generated or input by a business user, and more details on measure results.

Hovering over a graph displays additional information:

Drilling down from the Incentive Payment section shows information at the transaction level:

Another very interesting feature of the salesperson dashboard is the ability to display sale opportunities (from or other CRM/SFA systems) and the effect they have on the rep’s total compensation:

Manager View
The manager view has a very similar look and feel to the salesperson view, but displays information for the entire team:

Results can also be expanded to easily find details about how a transaction was commissioned:

Comp Admin View
This is where plans are created and configured.. Unlike other systems I have worked with, Compel abstracts the process of creating calculation and crediting rules through their Plan Builder wizard. Plans are created by defining and grouping the “Measures”by which reps will be compensated. First, the measure name, description, period, and type of measure is specified.

The next step consists in specifying what is being measured, and defining any filters (for example, exclude sales to existing customers):

The administrator just needs to choose the appropriate option and click on “Next” to the next configuration window.

Other systems have a component approach, and maintain a component library. In Compel you build measures. You can clone measures or plans, so if you need to build a new plan it is easy to clone an existing measure and re-use it as is or modify it using the plan builder wizard

Effective Dating:
I described effective dating when reviewing the latest version of Xactly Incent and discussed how critical effective dating is in my opinion. Centive uses effective dating for everything: people records, quotas, measures, plans, transactions, results, reports, etc . which makes its maintenance much easier. It also solves the difficult problem of handling prior period adjustments – Compel recognizes the crediting rules, roll-ups and structures that were in place at the time of the original transaction, and trues-up the adjustment to the current period.

The following plan builder screen capture shows how each plan uses effective dating:

I would probably need to work with Compel to make-up my mind about if I like the concept of how plans are built, since it is so different from the other applications I have seen. It’s very exciting to see a different way of thinking.

What I can say is that configuring a plan seems to be a very user-friendly step-by-step task. The user interfaces for sales people and managers are also very clean and display all the required information at a sight. Compel also seems to offer all the functionalities anyone could be looking for, and does so without the need to purchase additional modules.

The Moral to the ICM Saga

June 9, 2008

Read Part 1 and Part 2 of this story first.

The blame cannot be put on one person. ABC Corp, the ICM vendor and the consultant all own some of the responsibility for the issue.

The entire situation could have been avoided if the requirements had been better designed. Requirements could have been better designed if the compensation plans had been completed with enough details. The vendor would probably have done a better job at scoping out the work initially or in certain situations may even have not submitted a proposal.

What can we take away from this story?

  • Requirements cannot be fully defined unless the compensation plans are finalized. Requirements may be inaccurate or incomplete unless compensation plans show sufficient details and examples.
  • An ICM solution cannot be selected unless the requirements are fully defined.
  • Not all ICM solutions can handle very complex compensation plans (no matter what the vendor’s rep says). Some solutions are better suited for certain situations.
  • Good requirements are the foundation for any IT project, mess up the requirements and the entire project will be shaky.
  • Using an experienced consultant to help out with the requirements design, RFP writing and solution selection could be a good idea to select the ideal solution.
  • Consultants and vendors alike cannot “always” guess client’s intentions.
  • Mentioning or emailing a requirement is not enough, this requirement must find its way to the requirement document to ensure it is met by the implementation and properly tested.

The ICM Saga Continues…

June 5, 2008

It’s Thursday; meeting time. The vendor explains the requirements from the RFP did not accurately reflect what needed to be performed by the ICM solution. “Because the scope of the project did not include all this additional work, it will cost more and take more time to complete”, says the vendor calmly. “But your sales rep said it would not be a problem!”, exclaims the comp director of ABC Corp. “We specifically asked about this during the presentation and your rep said it you could do it!”.

The vendor finally agrees that because the relationship between their companies is valuable and because of their strong work ethics, they will honor the agreed cost and do everything they can to meet the deadlines.

However, problems keep piling up. The ICM solution is not intended to perform what would be required for the compensation plans to work how they are supposed to work. Data integration, workarounds and clever tweaking pushes the ICM solution to its limit. The client is asked to only include what is absolutely necessary in this release and push out the rest. The deadline is missed. The solution is finally implemented, but User Acceptance Testing keeps revealing new issues. The second pay-roll date is approaching but there is still no solution in sight.

Does this sound like a familiar situation?

Who should be blamed?
The vendor’s implementation team for not working harder, their sales rep for having mis-represented their solution or not asked for more detailed requirements, or the ICM solution for not being powerful enough? ABC Corp’s team or their consultant for not having defined the requirements properly?