Several years ago, a highly-experienced and skilled co-worker and I decided to collaborate on a white paper of best practices for SPM system implementations.  In the interests of putting boundaries around the problem, we decided that it would be based on the latest available version of the particular software package we supported at the time, as we recognized that best practices might be different with different functionality in the product.  That should have been our first clue.

What surprised me at the time was how well we agreed on the practices we identified as “best”.  Never did we argue for opposing approaches to any particular issue.  So our collaboration went swimmingly.  We sent our Best Practices Guide to the other consultants in the company we worked for and received the thanks of a grateful nation.

And it was, gee, I dunno, three days later when the first project went up in flames and we had to spring into action to determine what the problem was.  Operator error, of course, because the project team did something mind-bogglingly wrong.  And then the chilling words were spoken:  “But we were just following the Best Practices Guide you sent us!”.

Well, erm, yes, we did say that.  But not for this particular circumstance!  No, for the scenario you’re dealing with, this other thing is a much better practice.  We just didn’t write about it because, well, it’s too complicated to explain.

After about a half-dozen conversations like this, we began having second thoughts about the idea of publishing best practices.  Customers got wind that the guide existed and we’d panic at the idea of giving it to them since we knew it would bite us.  Even if we did exactly the right thing for that customer, if the Best Practices Guide recommended doing something different, we knew we would have an uncomfortable or adversarial conversation in front of us to justify our design decision.

Until incentive compensation is standardized across industries and companies, until source system data is standardized and cleansed, until operations processes are standardized, and until all the SPM software packages offer standard functionality and process in a single standard calculation model - i.e., never - trying to define best practices will be tricky at best and risky at worst.  The fact that our guide was only applicable to version X of the software should have shown us this.

“Generally good” practices do exist.  These revolve around generating exactly the right results while performing as well as possible.  But they are implemented differently for each customer due to differences in requirements, data, operations, and plans.  For every best practice I might define, I could probably find three real-world exceptions that would invalidate it.

So why do I write a blog on best practices?  Puzzling, eh?  If you read carefully, though, you’ll see that I very seldom delve into specific calculations or functions.  Instead, I concentrate on trying to find ways to ask the right questions and make systems solve the right problems.  That’s challenging enough.

Technorati Tags: Incentive Compensation, Incentive Compensation Management

Everyone gets a kick out of unintended consequences, right?  I can’t be alone in this.  One that I have seen in a lot of SPM projects is the identification of a Single Point of Contact - a SPOC - on the customer’s project team.  The intention is to streamline communications.

It seems like such a good idea.  You don’t want the project team having to sort through dozens of Subject Matter Experts - SMEs - in all subjects on the customer side to get an answer to a question about requirements.  Just go to the SPOC and ask your question, secure in the knowledge that it will be posed to the right person and that an answer will come back shortly.

And conversely, you don’t want the customer’s user community bugging some poor junior reporting consultant to ask how they will be able to do some process they do today in their legacy system.  No, the SPOC will arrange the proper knowledge transfer from the proper people at the proper time.  So what’s not to love about your SPOC?

First of all, you’ve made the information pipe smaller so less information flows through it.  Conversations that would normally be carried out in parallel now become serial since they all must pass through the SPOC.  And even if the SPOC is completely on the ball and efficient, communication is necessarily slower.  Knowledge acquisition that could be done it two sentences now takes four, as I have to ask my question to the SPOC, the SPOC asks the SME, the SME answers, and then the SPOC comes to me to tell me the answer.  Which is unwieldy enough for a simple yes-or-no question, but becomes painfully inefficient when clarifying questions are needed.

More importantly, information passes through a distorting filter.  The SPOC won’t understand my question unless s/he is also a subject matter expert, which is unlikely.  So my question is subtly interpreted by the SPOC, who asks the SME a slightly modified form of it.  The SME answers the question as asked by the SPOC.  The SPOC again interprets the answer and presents it to me.  So I’m now two interpretations away from the knowledge I’m seeking.  It may not be that bad for a well-defined system like an accounting package, but for something as idiosyncratic as a compensation system, the potential for missed connections is huge.

And then there’s the frustration factor.  While I’m wandering the halls looking for the SPOC to ask my question, I might encounter the person who has the answer I seek.  Am I really going to wait for the SPOC, or more likely, will I just get the answer right then and there?  I’m not intentionally subverting the process (okay, I probably am), but it would require more willpower than I possess to find the SPOC when I can get my answer now.

It’s easy enough to get a SPOC out of the way: ask lots of multi-part questions with plenty of jargon and conditional follow-ons early in the project, and by the third week even the most determined and conscientious SPOC will usually let you go directly to the source.  Then communication can begin.

Technorati Tags: Incentive Compensation, Incentive Compensation Management

I was having a conversation recently with a young consultant fella just starting out on the road of life, and he made an observation about the path we’ve chosen to follow - the path of bringing Sales Performance Management to the folks who need it most.  It’s a noble calling.

He said, “Some vendors’ products only do certain things, only have specific functionality, so if the customer needs something more or different, they can’t use that product, right?”  I concurred.  Then he said, “And some vendors’ products do everything anyone can think of, right?  Which means they ask us to do unworkable things with them.”  Correct, sadly.  “Well, just because the product makes something  possible doesn’t mean they should do it, right?  I mean, we help them do dumb things just because they ask us to.  But shouldn’t we be trying to find something better?  Can’t we tell them what they should be doing instead, even though the product might allow them to do whatever they want?”

It was kind of cute, really.  I remember being young and idealistic too.  And what he said gets to the heart of the way the SPM software industry progressed in its formative years.

It might be hard to imagine it now that there seem to be dozens of incentive compensation management packages available, but once upon a time, there weren’t many products, and customers had a hard time taking the ones that were out there seriously.  Working for a vendor that embodied the do everything, no matter how wrong philosophy, our job was to make time run backwards and light bend around corners if we were asked to.  Whatever the question, our job was to find a way to say ‘yes’, if only to show that the software would never be a limitation on their business processes.  It was a credibility issue.  So we ended up delivering some frightening solutions to some wacky problems in the interests of building a market for the product.  And we developed a very complex product because it had to support the wildest dreams of every customer in every industry.

It’s only in the last few years that we have felt like we have been given permission to question the stated requirements and ask whether there might be better ways to achieve the same ends for the customers that would be better-faster-cheaper-easier.  It’s easy to go too far with this idea of consulting rather than just implementing by trying to push aside requirements that might actually be good and sensible responses to the customer’s business problems.  Just because something is inconvenient for us to do is no reason not to do it.  But knowing that implementing a set of rules or policies that will make the system harder to maintain, less auditable, or less likely to get reportable, defensible results, we do have a responsibility to dig deeper into the requirement to determine whether it is really in the customer’s best interest to go ahead with it.

And then go ahead and do the strange thing if the customer insists.  But at least we will have tried.

Technorati Tags: Incentive Compensation, Incentive Compensation Management

One of the harder decisions a company must make for its SPM project, or for any financial application, is when the system should go live.

Easy - on January 1 (or the first day of the fiscal calendar), right?  There’s certainly a lot to recommend that.  It’s a clean break between the old year with the old system, and the new year with the new system.  All of your financial data for the year is in one place.  Go-live on January 1 means your users don’t have to go from legacy system to new system to do research and analysis.  Reports out of the new system have year-to-date data in them, so no need to mix and match the data from different systems.  And you can do a nice clean break from the old system, which could have a financial impact if you are paying license fees for the software.

Excellent - the question is settled then, right?  Well, not exactly.  There are hidden costs associated with making the project finish for go-live on the start of the year.  Let’s start with the operational cost.  Unless you are planning to hire an entirely new staff to run the new system (and here’s a hint:  if you are, do not mention this to the staff running the old one if you want them to keep working), then your existing staff will be up to their ears in year-end operations on the legacy system.  As hectic as year-end always is, it will be twice as bad if your staff have to simultaneously train on and test the new system for go-live the day after the year ends.  When it comes to a scheduling showdown, operations will always win over projects.  Your reps have to be paid - that doesn’t go away with the introduction of the new system to pay them.

And there are other project costs too.  First of all, if January 1 is the start of your fiscal year, then you have a project going into crunch mode around Thanksgiving and extending through the December holidays.  This wreaks havoc on scheduling.  Most project managers take three weeks’ worth of time off the available hours because, strange as it might seem, this is when the project team would like to be with their families, not working the implementation.

Another project cost is the fact that there will likely be no data for testing the new system.  If comp plans change on the turn of the year, then you can’t do parallel testing with legacy system data because it will be subject to different rules in the new system and your results won’t match.  This makes system and user acceptance testing that much more complex and time-consuming.

Now let’s be cynical.  What if the project runs long?  What’s your plan to configure the legacy system with the new rules or calculations to use if the new system isn’t ready on January 1?  Have you budgeted that effort into the project schedule?

I’d love to tell you what the right answer is, but there isn’t necessarily a good one out there for every project.  You have to decide which costs you would rather incur.

Technorati Tags: Incentive Compensation, Incentive Compensation Management

I read with interest an article in the business section of the local paper about the CEO of a high-tech company here in Silicon Valley who just announced that he was leaving the company to go to work for another one.  The article went on to describe the compensation the CEO was to receive for various reasons on his way out the door.  The quantities of stock options he was granted and in which he was vested were staggeringly large.  Ironically, the stock had lost 80% of its value in the time the CEO was on the job, so there was some entertainment value in the article as well.

I don’t pretend to be an expert in executive compensation the way I pretend to be an expert in everything else - for me, it’s the proverbial riddle wrapped in a mystery inside an enigma.  But one thing in the story jumped out at me:  one of the large option grants, fully vested, was to be given to him upon leaving the company for any reason.  That stopped me in my tracks, and I still wonder why you would offer your CEO, someone you presumably would like to retain, a good reason to leave?  There were other conditions mentioned in the grant - the stock was his if the company was bought, for example - that might or might not make sense.  But at the end of the day, “for any reason” meant that the options were his the moment he walked out the door.  Which, as it turns out, he did.

Okay, maybe not everything is about pay-for-performance.  There might be compelling reasons to throw the guy some guaranteed stock options regardless of performance, longevity, or any other performance related reason.  But even at the depressed price of the company’s stock, there was enough in the grant to let him live without working for a couple of years if he tightens his belt a notch and foregoes the new yacht.

You could argue that, because it’s stock options, the CEO has an incentive to raise the stock price to make his grant worth more, but at what cost to him?  One of the tenets of economic modeling of incentive plans is that people want to do the least possible amount of work to earn their money.  This may or may not be the case, but it’s a good place to start the discussion.  So if a guy sees a long tough road ahead to raising the stock price, with no guarantee that his efforts will return a huge increase, and meanwhile the stock has a known value, why wouldn’t he leave now and just take the money?  Or even hold onto it and hope the next CEO does something right and the stock price will rise because of that?

I’ve mentioned elsewhere that free money is not a motivator.  This was free money, and I hope no one was surprised that the CEO took it and ran.  The company was paying him to do just that!

Technorati Tags: Incentive Compensation, Incentive Compensation Management

We’ve talked about why the Big Bang approach to the implementation of Sales Performance Management systems can be an attractive methodology.  But there is an alternative - the phased approach.  And like Big Bang, it has its adherents too.

When we talk about the phased approach, we typically mean implementing the system for subsets of the intended system population in a series of smaller projects.  This might mean individual business units, sales channels, even classes of payees - for example, direct reps versus management or overlays.  It means doing each logical division a few at a time, rather than the whole all at once.

The most attractive part of the phased approach is that you get ROI that much sooner.  In a Big Bang project, nothing is complete and usable until everything is complete and usable.  If dates slip or dependencies are missed, no one gets to use the system until things get sorted out.  This could be months after the originally scheduled go-live date for a complex enough project.  Doing a series of smaller, more self-contained project phases allows the system to be up and running for at least some of the users in a more timely manner.

And speaking of deadlines and delivery dates, sometimes they slip.  Like, almost always.  But missing a date on a small project probably isn’t as going to be as fearsome as missing dates on a large project.  And as you do different phases, you’ll probably become better at estimating and managing towards deadlines.

Something else to like about the phased approach is that it gives the customer project team and users the chance to really understand what the system can do.  Not many people have real, deep knowledge of what best-of-breed SPM systems can deliver - it’s still a relatively young market.  Often requirements are made too granular or not granular enough because the systems’ users don’t know what they should ask for.  They might ask for every exception to be coded in, or conversely, they might not ask for enough flexibility.  By using the phased approach, when the first business unit is up and running, the users can see whether the requirements they have defined really make sense for the larger system as a whole.  Requirements can be re-thought after a much lower cost has been incurred.  It’s more than a proof of concept; the actual production system has been built, but the lessons learned can be applied to the next phases.

Finally, it allows you to spread the expense of the project across quarters or years, and across business units much more accurately.

So what’s not to love?  My biggest concern is always the siloed requirements gathering that takes place in a phased project.  I have worked on projects where a Phase 3 requirement invalidates major design decisions for Phase 1.  The impact of this can be greater than just rework - it can almost require a reimplementation.  But I’d like to think there’s a middle ground between phased and Big Bang, and I’ll discuss that in another entry soon.

Technorati Tags: Incentive Compensation, Incentive Compensation Management

I normally try to avoid religious discussions, but I think I’ll delicately touch on one here.  I’m referring to the Big Bang.  Not the creation of the universe Big Bang.  No, I mean the project approach of trying to create the entire compensation universe in one large all-encompassing project.  Big Bangists prefer this approach to the one favored by the Phaseurs, who advocate doing their comp projects in smaller, more manageable chunks.  The disagreements between them can be passionate and irreconcilable.  It’s tragic, really.

There is much to like in the Big Bang approach.  It’s like taking a mighty swing at the first pitch and hitting the ball out of the park- it’s so satisfying when it works.  And there’s no doubt that there is a huge return on investment when you can get the job done with one mammoth effort.  You don’t have what feels like countless other projects staring you in the face starting the moment you finish the current phase.  That can be disheartening to project teams - they feel like they never really finish anything because Phase N+1 starts the Monday after the Friday that Phase N is completed.

There are other, more practical advantages as well.  In a Big Bang project, you know, theoretically, what must be accomplished end-to-end in the system.  This really matters in a compensation system because compensation is so exception-driven in most companies, and because every sales unit or channel tends to have its own way of doing superficially similar things.  There can be many ways to solve individual requirements, no matter how unusual, but every additional unusual requirement you throw at a system limits your flexibility for solving all of them.  There might be any number of “right” ways to solve Requirement One by itself, but perhaps only one “right” way once you also know Requirements Two and Three.  In a Big Bang project, you know Requirements Two and Three up front while you are in design.  In a phased project, you might not hear Three until after a formerly “right”, now “wrong”, solution for One has been long-since built and tested.

Another practical advantage of Big Bang implementations is the much smaller amount of time you must have systems operating in parallel.  You might have your legacy system(s) available for a few months for research into historical issues, but all work is done on the new, slick, streamlined system from go-live day going forward.  It’s a bit of a process re-engineering effort to get all of your users up and running on the new system, but in a very short time you gain the efficiency of having a single, hopefully well-implemented system to work in.

The most practical advantage of all?  You only need to get one round of project funding from the Finance Committee.  And who really wants to go through that process more often than you have to?

All that being said, there are disadvantages with the Big Bang approach too.  Perhaps we’ll examine them in future blog entries.

Reminder - don’t forget to read the free Santorini Consulting white paper on Minimizing Risk in an SPM System Implementation.  Just register on the website to download your copy.

Technorati Tags: Incentive Compensation, Incentive Compensation Management

I recently had to tell someone that there was no “right” answer for a particularly thorny SPM system design question.  There were a lot of answers that could potentially work, each with pros and cons.  The solution we would eventually choose would be, with luck, the “rightest” answer, or maybe, the “least wrong” answer.  As I’ve made a career of demonstrating, incentive compensation management software has to solve a lot of very bizarre business problems, and the way it does that is more or less elegant depending on the business policies, the available data, and the reporting requirements at the end.

So how do you know you’ve picked a relatively right answer?  I think that has to be viewed in light of where work can be done in the system, and whether you have given the work to the part that can do it best.  By my calculations, there are four ways to get results into and out of a system, what I call the Axis of Heavy Lifting:

• The rule or calculation engine
• Data integration, including pre- and post-processors
• Reports
• Manual intervention - the users

The rule engine is all about handling the IF-THEN logic and doing the math, and generally it does that very well.  But doing lookups of data for nit-picky conditions is a drag on the system and has an impact on performance and the users’ ability to maintain the system.

Data integration, on the other hand, is a great place for moving data and looking up information stored across objects.  But embedding a lot of IF-THEN into pre-processors isn’t generally a great idea because it moves business logic away from the business users and buries it in the IT department.  And certain forms of logic really bog SQL down.

Reports can do certain calculations if needed, but anything beyond fairly simple aggregation results in hard-wired business logic in a system that’s generally out of the users’ control.  And it’s really not a lot faster to do the calculations in reporting than it would be to do it in the rule engine.

Finally, there are the business users of the system.  Theoretically they could figure out all the results and enter them manually, though that’s clearly not practical and it would be hard to show ROI in a system that requires that.  But where there are exceptions that can’t be neatly handled by the system, and most importantly, are not so numerous as to be burdensome to deal with, manual intervention is a perfectly acceptable design - that’s why applications have user interfaces, after all.

In an ideal world, the system would look something like this:

In the real world, with real world bad data, exceptions to exceptions, and detailed reporting requirements, it often ends up looking more like this:

That’s hardly elegant, and we strive to do better.  But at the end of the day, you have to ask yourself whether you’ve given the heavy lifting to the part of the system that can do it best?  If so, that’s probably about the “rightest” answer you’re going to find.

Technorati Tags: Incentive Compensation, Incentive Compensation Management

Santorini Consulting is offering a free white paper entitled Minimizing Risk in a Sales Performance Management System Implementation, a common sense approach to avoiding pitfalls in compensation system projects.  The paper is free.  Just register on the Santorini Consulting website to download it.  We hope you find it useful if you’re considering an SPM project soon.  Thanks very much - David

 I was recently pointed towards an article by Joel Spolsky on the Inc.com site entitled How Hard Could It Be?:  Sins of Commissions.  Aside from the great title, which I will probably steal at some point, the article confirmed many of my beliefs that employees will always find ways to make commission schemes backfire.  Mr. Spolsky described the tricks a clerk used to entice him to buy - even at a huge discount - an add-on product in a shoe store with his purchase of shoes.  He then dissects the clerk’s behavior in light of the likely commission plan in place to sell the add-on.  The clerk, whether through fraud or creativity, discounted the shoes to make the add-on nearly free, which was not at all what the comp plan designer had in mind.  It’s a great story and analysis and it’s well worth reading since I can’t do it justice in the space available here.

The point being made is that it’s nearly impossible, or according to Mr. Spolsky, completely impossible, to come up with a plan that won’t have unintended consequences.  And the reason why is that you can’t control behavior at a distance using a comp plan, you can only reward or punish measurable outcomes of that behavior.  But often those measurable outcomes can also be impacted by other behaviors.  In a complex environment, there are sometimes many levers to tweak, not just the one the comp plan designer had in mind.

So what are you supposed to do if you want to make good behaviors happen?  If there’s no way to create a comp plan that’s foolproof and that will only reward the “right” behaviors, does this mean you shouldn’t even try?  That’s not a very satisfying option.  The fact is, you still have to try, because if you don’t provide guidance and motivation to your sales staff, they won’t sell enough of the right products to make you successful.

But you must approach it from the right frame of mind.  Know your payee population - they are likely very different kinds of people than your finance organization or sales operations staff.  They think differently and will react in their own way to the commission plans put in front of them.

So maybe you can co-opt them?  Have your finance person come up with a plan candidate, then bring in your oldest and wiliest sales people for a meeting.  Tell them you’ll pay an instant bonus to anyone who can “break” the plan - and make the bonus higher than the amount they might be able to divert their own way if they game the plan.  Use the input you get and tweak the plan until you stump them, or at least, slow them down.

It still won’t be foolproof, but at least you have a shot at eliminating the easy workarounds and loopholes.

Incidentally, Joel Spolsky cites Robert Austin’s book, Measuring and Managing Performance in Organizations, in his article.  The book is an examination of failures in the measurement of behavior.  It sounds fascinating and I have my copy on order.  What can I tell you - I’m a failure geek!

Technorati Tags: Incentive Compensation, Incentive Compensation Management