Printer Friendly

Automating the administration of incentive compensation at Monsanto.

Companies that historically have reserved incentive compensation for the select few are extending their plans to encompass more levels of management and even nonmanagement positions. As plans proliferate, they often mutate so that no two are exactly alike. Plan administrators accustomed to handling 20 or 30 participants with a word processor or simple spreadsheet find themselves overwhelmed with just the eligibility determination, not to mention everything else that must be done once that is finished.

At some point, you recognize the need to work smarter, not harder. It is hoped that that point is well in advance of scheduled deliverables, allowing you time to involve your computer services (information technology, or IT) group.

What can the IT group do for you? Well, that depends on your budget and their resources, to name just two of the variables to be considered. This article presents a case study of a project at Monsanto that was chartered to automate the administration of incentive compensation, from start to finish. Monsanto is a chemical company with Crop Protection, Produce, Fibers, Saflex, and Nutrasweet counted among the major business units. The project took a full year to complete and successfully automate the administration of nine cash and stock plans covering more than 3,000 participants. This article describes the design process and the challenges that were addressed along the way.


The first step was to have a meeting of "business experts" and IT people to discuss the business area and terminology. It is vital to establish a foundation for discussion so that everyone is talking the same language.

The purpose of incentive compensation was outlined as follows:

* Focus participant attention and efforts on company performance.

* Recognize and reward employee contributions to business results.

* Stress that personal, group, and company successes are interrelated.

* Emphasize long-term, contiguous success.

The plan administration process was summarized as encompassing five functions:

* Eligibility - determining the participants

* Funding - estimating the cost of the plan

* Allocation - calculating objective awards

* Recommendation - assigning actual awards

* Distribution - communicating awards

All plans used the first and last function, but they varied as to their use of the middle three. For example, plans that had a predetermined fixed cost skipped funding, whereas plans that did not allow management modification of calculated awards bypassed the recommendation element.

Expansion Necessitated Improvement

In recent years, Monsanto incentive plans were extended beyond executives to lower levels of management and even into nonmanagement positions. Although success factors were very different (e.g., safety instead of sales, production instead of profit) the purposes of the plans at these levels remained the same. The additional complexity and resource demands brought on by the new plans had already forced some administrators to employ computer spreadsheet programs and, in one instance, a rudimentary computer database. The trend to increase both the number and complexity of the plans triggered the interest to investigate a comprehensive solution to administration.

After review of the current incentive plan administration process, it was agreed that an automated system could provide significant time savings and data-consistency benefits to the overall process. Thus a project was initiated with the following objectives:

* Design a single incentive compensation system for use by all business units.

* Provide administration of all types of plans:

* Management and nonmanagement

* Salaried and wage

* Cash and stock

* Annual and long-term

* Integrate with HR and payroll.

* Interface with other systems.


This author prefers to use an "iterative" or "rapid prototype" approach to systems design and development whenever possible. The approach stresses close and frequent communication with the customer and promotes a team spirit among everyone working on the project. Fundamentally, the approach involved:

* identification of business experts

* establishment of periodic meetings

* evolution of function

* just-in-time delivery

The business experts must include someone with an understanding of plan design (both current and future), in addition to someone with day-to-day administrative knowledge. Someone with plan design knowledge might state that "Currently all incentives are determined as a percentage of salary, but next year it will be a combination of percentage plus a flat amount," whereas a day-to-day person would likely add that "Generally speaking, incentives are calculated as a percentage of salary with different percentages based on grade level. Some plans use actual salary, whereas others use an ending-year salary." Project success depends on seeing the whole picture, not just the portion that one individual is focused on.

Consistent participation and decision authority are essential for business experts. When individual or team continuity is broken, the whole team suffers. Meetings deteriorate into a review of the previous meeting (for those that missed it) followed by a series of tentative agreements to be reviewed at the next "full" meeting. Enthusiasm rapidly fades. Without decision authority, the process of making a "final" decision drags on for days, and the business expert, realizing his or her role as little more than messenger, quickly loses interest.

Our team was made up of four business experts (three compensation, one payroll) three IT people (one senior, one junior, one with prior incentive experience), and one meeting facilitator. The business experts were empowered to determine the features and functions that would be included and those that would be left out.

After a brief initial discussion, everyone agreed that weekly meetings were appropriate, given the aggressive schedule that lay ahead. The meetings were scheduled for two hours over lunch to minimize the conflict with other scheduled meetings not related to the project. We used the first several meetings to identify general requirements with just enough detail to provide the foundation for more detailed discussions later. As we began detailed requirements, the IT staff began prototyping the computer display screens to match the requirements. The first half of each meeting was used to review the prototype and clarify the requirements. The second half of each meeting was used to discuss new detailed requirements so that additional prototype work could continue through the next meeting. This approach proved very successful. Team members were able to see the system evolve, and mistakes were corrected long before the time and cost to do so became prohibitive.

A rapid prototype approach also facilitates a phased rollout for delivering functions. The team agreed, in advance, on delivery dates for each of the five major functions. It was easy to monitor progress against the dates and adjust accordingly so that we delivered each working function just before (sometimes slightly after) it was needed. Then, based on customer feedback for one function, we could alter the design for the next function. A "big-bang" approach of delivering everything at once precludes such in-progress alterations.

Planning for the Exceptions

As the detailed requirements were identified, it became readily apparent that the 80/20 rule applied also to incentive compensation administration (i.e., 80 percent of the participants consume 20 percent of your time, while the other 20 percent of the participants consume 80 percent of your time). In other words, the majority of your time is spent handling the exceptions. We discovered that we could define rules for properly administering the 80 percent (nonexceptions). On the other hand, we struggled with defining rules to handle every exception.

In general it was much easier to deal with exceptions as "overrides." For example, assume that Jane Doe was not eligible according to the rules, but manager X said she should be included; rather than design complex rules to handle this situation, it was much easier to have an exception list that ignored the rules. As another example, say manager Y declared that all composite engineers in the widgets division should be treated as a grade 38. Again, it was much simpler to allow a grade override to the six people affected in this instance than it was to define an infinite number of rules to accommodate every deviation. It is important to note that overrides must be used for incentive plan purposes only, without changing the original HR data.

Flexibility versus Complexity

Often during discussion of detailed requirements, business experts would be in general agreement (e.g., the incentive calculation should be based on a percentage of salary) yet differ as to the specifics (e.g., one person would have plans that defined percentages by grade, another by grade but different by division for the same grades). The challenge is not in designing a system to handle such differences, but rather in designing one that is flexible without being overly complicated. Generally, the more flexible a system is, the more complex it is to use. However, the goal should be to develop simple features that are simple to use, and complex features should not complicate the simple features. The key to achieving this goal is to rely on your IT staff's experience in designing user interfaces.


Eligibility is the function that determines which employees should participate in a given incentive plan. It is the heart and soul of doing incentive compensation administration. If you don't do this well, you will create numerous problems in administering a plan.

Eligibility is constrained by the plan "period." A period is defined as a start date and end date (e.g., our annual plans were defined with a January 1 start date and December 31 end date). The terms plan and period are used somewhat interchangeably, although in fact a plan usually consists of multiple, separate periods.

The three key aspects of eligibility are (1) who should participate, (2) which data items to gather, and (3) which values to retain. A "rule-based" approach was designed for determining the participants for a plan. The business experts identified each criterion that was applicable for their plans (e.g., the individual must have at least three months of eligibility, only employees from the Fibers organization are eligible). The most straightforward method for specifying these rules was an include/exclude list. Each rule was based on some piece of employee data (e.g., location), and the administrator could choose to include a set of values (e.g., include just Dayton and Springfield), exclude a set of values (e.g., exclude only Detroit and Richmond), or not include/exclude any values (e.g., location does not have a bearing on eligibility). Using this approach provided a simple yet flexible way of defining a nearly infinite number of rule combinations.

Identifying the data items to gather is mostly intuitive (e.g., employee ID, grade). The difficulty comes when trying to guess what items might be needed in other functions, such as funding and allocation, that are not clearly needed by the eligibility function. For example, one plan administrator had no need to define eligibility using the Fair Labor Standards Act (FLSA) status but later, in addressing an allocation issue, realized the need to differentiate participant groupings by FLSA status. As a result, long after we thought we were "done" with eligibility, we had to go back and modify it to gather FLSA status so it could be used in allocation. Every effort should be made to anticipate which data items will be needed. To keep things simple, we decided to collect a common set of data items for every plan and then gave each administrator the option to use or ignore each data item collected.

Another important team decision was that incentive administration should be based on a copy of the HR data. This is a direct result of the (seemingly endless) need to modify the data for incentive reasons only (e.g., treat an employee as a grade 39 even though he or she is really a 38) and the need to summarize (compress) the data to our needs (e.g., ignore all of the history records not significant to a given incentive plan). We also employed a lock indicator for data overrides that allowed for retrieving the incentive data from the HR data without losing the overrides.

Understanding the importance of which data values to keep came late for our team. Don't make the same mistake. A typical employee might have two or three records (e.g., pay change, department transfer, or job change) per year in our HR system, whereas some employees have as many as six or more. Plan administrators needed the ability to define which records were "significant" for their plans. After a less-than-ideal first design to solving the problem, we settled on a "data-value" design. Once again, the business experts defined all of the possible data items that could be significant. Then we designed a panel that allowed them to choose first, each, last, or date-specific data values (within the plan period) for each significant data item. Selecting "first value" for the grade data item, for example, would make it seem as though participants retained their starting grade level for the entire plan period. Assuming the participant was eligible for the full plan period (12 months) as shown in Exhibit 1, then the difference in data value selection would be what is illustrated in Exhibit 2.

Using this data-value approach for each of the data items provided a simple yet flexible way of ignoring unwanted data changes and summarizing the data to any level necessary.

The process to actually scan the HR data and create a copy for use by an incentive plan was designed as a "batch" (it did not monopolize the administrator's computer) process because it could take between 15 minutes and six hours, depending on a number of different factors. Success, of course, is always a relative thing.

I found it interesting when one administrator called me with concern. He had set up all of his eligibility rules in a matter of minutes, yet the automated process to gather all of the participant data took five hours to complete. I was elated, although he did not understand why until I asked how long the process had taken the prior year without the automated system. "Four or five days," he said.
Exhibit 2

Data Value Selection

Selection          Eligibility

First Value        12 months at grade 32
Each Value         3 months at grade 32
                   8 months at grade 33
                   1 month at grade 34
Last Value         12 months at grade 34
Date-Specific      12 months at grade 33
Value (Aug. 1)

One other note about eligibility: Earnings data were collected because most cash-plan awards were based on a percent of individual earnings. Tracking multiple currencies through each function creates complications, so we decided to collect participant earnings using the actual (international) currencies and then convert to a common (U.S.) currency for use throughout the rest of the incentive functions. Initially, at the request of the business experts, we allowed each incentive plan to have a different set of currency exchange rates. Later, the system was simplified to work from one standard set of exchange rates common to all plans.


Funding is the function through which the total cost of a given incentive plan period is estimated (usually for accounting purposes). Whereas the eligibility function determines who the participants are, funding determines how the participants will be treated. It is likely that you will need to subdivide your plan participants into groups, as was the case for most Monsanto plans. The reasons may be to assign different account numbers to charge or to allow for different performance results. Whatever the reason, the easiest way to determine who falls into which group is to use a rule-based approach, much like the one used for eligibility determination. Now, however, you have a set of rules for each group you define that specifies which participants are assigned to each group. Using this approach, it is entirely possible for one record of a participant to be placed in a different group from a second record for the same participant. Our team again identified the need for handling exceptions. Allow for a method to specify, regardless of the rules, that certain participant records should be placed in certain groups. Once each participant record is assigned to a group, it is a fairly straightforward matter to combine the participant information with the group information to calculate a forecasted award. In practice, our administrators run funding several times a year to provide data to the accountants regarding what the plan expectations are.


Two functions address award assignments: allocation and recommendation. Under allocation, an objective award is calculated when the end-of-period performance numbers are available. Although the business experts made a distinction between funding and allocation, it could be argued that allocation is simply one more iteration of funding using actual, rather than estimated, data. However, the functions were kept separate because allocation required hierarchically related groupings (Exhibit 3) of participants to allow for "rollup" summary reporting (e.g., report the total awards for Division B of the Fibers unit). So rather than complicate funding, the team decided to keep the functions separate. In practice, it is interesting to note, administrators generally have need for many fewer groups in funding (2-5) than they do in allocation (20-200). Incentive award calculations in funding and allocation were not directly tied to individual performance review ratings, although it would have been fairly easy to do so had there been such a requirement.

Recommendation is the function through which subjective awards are assigned to groups and individuals. The intent was to provide managers an easy tool to modify the subjective awards that were allocated for both groups and individuals they manage. For example, a manager might reduce one participant award by $500 and increase two other participant awards (by $200 and $300, respectively). Or, as another example, a manager might reduce one group's award pool by $7,000 and increase another by the same amount. Of course, the system tracks totals and balances to assure that awards do not exceed the available pool for each group. In the cases in which a plan did not call for modification by managers, the recommended award amounts equated to the allocated award amounts.


Distribution is the function that communicates awards to all of the people and all of the other computer systems that need to know how much was awarded to each participant. Based on the requirements provided by the business experts, we designed a program to print manager and employee notifications, feed data to payroll, print stock option certificates, feed data to stock records, defer cash amounts based on prior deferral elections, and numerous other tasks. Perhaps the most difficult aspect of distribution was the multiple options requested for sorting and formatting the printed notifications. Such options, although simple to present to the administrator, make the program itself considerably more complex.


The project successfully achieved the goal of automating the administration of nine cash and stock plans covering more than 3,000 participants. During the last two years, the system has been enhanced to handle a variety of nonmanagement plans (including plans for wage employees) in addition to improving features for management plans. In 1995-1996, the system was used to successfully administer 112 plans encompassing over 20,000 participants, with no increase in the number of administrators.

Automation of incentive compensation administration can pay back large dividends in process consistency and time savings. If it seems like an easy project, then you probably need to look closer. If it seems like an insurmountable effort, then you should subdivide the process into component parts until the pieces seem manageable. Plan ahead. Be prepared to begin the project at least one full year before you expect to use the system. There are far worse problems than finishing a project ahead of when you actually need it to be completed. Make your system as flexible as possible without being needlessly complex.

Tom Scheifler has ten years of experience in database applications. Currently, he is principal analyst at Monsanto in St. Louis, Missouri, where he has implemented and customized the PeopleSoft client/server human resources software. During the last three years, his focus has been on the design, development, and implementation of a flexible incentive compensation administration system.
COPYRIGHT 1996 Executive Enterprises Publications Company, Inc.
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 1996 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Scheifler, Tom
Publication:Employment Relations Today
Date:Mar 22, 1996
Previous Article:Taking work off-site - AEGON's telecommuting program.
Next Article:Learning from Japanese companies and Japanese transplants in the United States.

Terms of use | Privacy policy | Copyright © 2019 Farlex, Inc. | Feedback | For webmasters