12 July 2010

Irrationality's Upside pt1: Business Analyst Bonuses

Dan Ariely'sThe Upside of Irrationality: The Unexpected Benefits of Defying Logic at Work and at Home (Hardcover)(2010)A few nights ago I started reading The Upside of Irrationality by Dan Ariely. If this sounds familiar, its because a few weeks ago I posted about his first book, Predictably Irrational. These are two fabulous books that unknowingly give you a great deal of insight into the economics of projects (and yes, there is an economics side to all projects, but don't think that means its boring!)

Chapter 1 focused on bonuses and their effect on our performance. The basic principle here, and I'm trying not to ruin anything for you, is that offering low (1 day of pay) or moderate (2 weeks worth of pay) bonuses result in relatively the same level of performance on cognitive tasks. Offering high levels of bonus (5 months worth of pay) results in significantly lower levels of performance. If you want to understand why this is, read the book. :) But this chapter got me thinking about how we measure and reward performance for project people. This post will focus on the business analyst side of the equation and I'll hit up project managers in the next post, then end the series with a post about how I believe bonuses should be paid out for people who spend most of their lives in ProjectLand (its similar to DisneyLand, with a cast of crazy characters, but far fewer bright colors).

Bonus Failures

If you're a BA like me and you get your quarterly or yearly bonus, you are often left scratching your head about how companies put together incentive plans. Right now, my bonus structure is tied to the operations function because the development team I work for creates software for the operations team. Sounds logical, right? Well, maybe.

Much of the bonus structure is about driving sales but when you look at the application we develop, very little of it actually focuses on driving extra sales. I can think of two different types of upsells that our order takers must walk through in order to save an order, but if you watch order takers in action, they most always blow right through the upsells. Many do ask the questions even if the system prompts are ignored, but it is rare when you look at the logs that they do anything to drive actual sales.

So what am I to do? Well, I focus on the smaller side of the bonus structure, on finding ways to cut costs. Even small percentage changes in labor and raw materials can make a big impact on the bonus structure, even if the change is smaller than an increase in sales.

But even then, my impact is still relatively small. I can build all the tools in the world, I can help the operations support area create the best training material for our software, but I can not force the field operations team to actually use it as designed. One of the things that has most amazed me in this job is the number of creative, and often counter-productive ways my users find around the controls we build.

Potential Alternatives

Despite the initial thought that aligning my job with operations is logical, it really is irrational. But how then should the company measure my performance if they don't tie it to operations outcomes? Well, I can think of a few ways:

My first thought was that you could tie my bonus to the accuracy of the requirements I elicit from stakeholders, but if I only elicit one requirement and it is correct, is that worthy of my entire bonus? If I elicit 1,000 and only one is right, but that one is worth more than triple the other 999 combined, do I not get any bonus?

But even if you found a correct formula, how do you even know what the 'right' requirement is? What is a 'right' requirement today may be completely wrong after it has been implemented, especially for projects that have a long timeline in industries where the business environment changes rapidly.

Even if you got the requirements 'right' by 'skating to where the puck will be', who measures if this is right? The first thought would be stakeholders, but they have enough trouble knowing what their requirements should be, so what makes us think they would be any better at measuring what was done right? Maybe our people managers could do the measurement, but if we're shared resources, would they even know? Our project managers might be able to do this, but if you're like me and have seen requirements produced by project managers, you're probably frightened at even the thought of that. (No offense PMs, you'd HATE my project plans!)

Having other BAs rate your requirements accuracy might be a possibility, but it that is a fox guarding the hen house. The possibility of collusion among a group as honest as BAs is still high, even if it is unintentional because you don't want to be seen as disparaging a fellow practitioner's work product.

What other problem methods do you see that would be really bad bonus structures for BAs? Let us know in the comments. Stay tuned for the next post in this series which discusses Project Managers and their bonus structure.

1 comment:

  1. Oh, this one of my pet peeves, bonuses based on individual or departmental "performance". To me, this inspires more competition than co-operation in a company. I have seen cases where costs have been shunted from one area to another in the hunt for the bonus.

    A few companies have figured this out; they calculate each person's bonus based on the overall company's performance. Clearly the higher up you are, the more you get, but that's how salaries work, so it makes sense.

    I remember reading the football novel North Dallas Forty, where the main (cynical) character says that he didn't care if the team won or lost as long as he had a good game. Is that how your company to work?