Irrationality's Upside (3 parts): A Sensible Project Bonus Structure
This post was originally 3 parts (part 1, part 2 and part 3) and appeared on BetterProjects.net the week of July 12, 2010.
***Part 1***
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.
***Part 2***
In part 1 of this series, I took a look at how the bonus structure for Business Analysts is not very efficient in driving better results. This time we’ll look at the structure for Project Managers and an alternative method for structuring their bonus plan. Part 3 will discuss what I consider to be a 'better’ way to structure bonus plans for all Project People.
If you want to know more about Dan Ariely, or his new book, check out some of the interviews with him over at Big Think.
Setting a Baseline
PMs, like BAs in the last post, usually find themselves receiving bonus payments based on whatever business unit happens to pay their salary. If you’re part of IT, you follow whatever bonus structure they use. If you are part of a PMO and report directly up to the COO, then you’ll find yourself following that structure. Wherever you are, it is often a place where you may find yourself having trouble making a direct contribution to the company bottom line.
I’ve seen PMs who are BOK-WONKS (a person who spends their time studying a Body of Knowledge instead of on more socially acceptable non-work activities) complain when anyone even mentions the 'Project Triangle’ in a post. Its outdated and legacy theory that has been replaced by more accurate representations, you say. Quite true I say, but one thing you can’t fault the triple constraint for is providing an easy to use and easy to understand relationship between multiple, competing factors. All of you BOK-WONKS out there hold on to the pitchforks for a moment because while my example here may be less precise, I’m going for a directional position and the triple constraint does a really good job at proving the point.
You’ve got Time, Scope and Budget. Failing to deliver on any of the three is a potential negative to the bottom line, even if it is only failing to correctly estimate the number of deferred hours needed to complete the project. But is this your fault? You don’t control the requirements, so when the BA fails to correctly specify all the needs of the business, that is not your fault. If the developer runs over schedule by months because they are a code perfectionist and the resource manager won’t agree to add more people to pull the schedule back in, your recourse to keep your bonus is limited.
While PMs are responsible for 'cracking the whip’, if the whip-ee refuses to budge, you are not usually their resource manager so you’re left with pushing issues up to a sponsor team to resolve. You report on the schedule and on the weekly burn rate, but other than suggesting ways in which people might perform multiple tasks at once or ways to slim costs by cutting scope or hiring cheaper inputs, you generally don’t have the authority to actually implement any of these resolutions.
Now What?
Lets say that your management team decides to restructure your bonus calculation and ties it directly to your ability to predict and report on changes to that triple constraint. They want to see how accurately you can forecast and divine the winds of the project landscape.
You find out that 1/3 of your bonus is tied to each of the areas of the triple constraint. The closer you are to being on budget, the more of that 33.33% is yours. The same is true for schedule and scope. The problem here is similar to the problem with a BA, how do you measure each of these areas?
Lets take time… are we talking duration or effort? Both? If you end the project on time, but blow labor by 20% because you hired a bunch of contractors at the end of the project, should you really get the full bonus percentage for the time segment of the calculation? You may have hit your dates, but your effort is way out of proportion with what your resource managers felt the project would need. Similar problems would exist for quality (I shipped it on time and on budget, but it was unusable) and budget (throwing more bodies at it).
But there is a more fundamental error with this calculation, namely that being accurate in a measurement does not necessarily translate into better results. I had a PM trainer once tell a story of how, while he was PM for a project to build a palace for a Saudi prince, they came in on time, on budget and to the exact letter of the original plan. The prince, when being given a tour of the palace, stormed out within 5 minutes, refusing to talk to anyone about the building and refusing to take ownership of the property. After months of work, the project team finally got an audience with the prince.
They explained how they completed construction on time, how they were good stewards of his money and how they fulfilled the letter of the design. The prince’s reply was simple, “But you put vinyl tile in my foyer. I’m a prince, what do I care about time, budget or scope if I am ashamed to show off my palace to the other princes because it looks cheap!”
The project team measured everything exactly, but failed in the most important ways, namely to meet the needs of their customer. Tying the bonus of a PM to their ability to accurately measure a project will not work because accurate measurements does not necessarily translate into correct results.
But Wait, There’s More…
Part 3 of this series will arrive very soon, so watch for it in a couple days. Until then, amuse yourself in the comments by letting us know of other ways you’ve had your bonus calculated as a PM!
***Part 3***
In parts 1 and 2 of this series, I tossed out a few examples of current and bonus structures for BAs and PMs. Then I walked through the ways the current structures failed to drive results. Lastly, I looked at alternative options that, in my opinion, would be just as bad, if not worse, than the current methodology. Now lets turn our attention to what I think is a methodology which has the potential to drive better results.
To find out more about Dan Ariely, check out his website.
A Different Approach
We’ve rulled out measuring based on our customer’s results and on trying to find the 'right’ requirements for BAs, so what is left? If it were up to me, I’d do it in two ways, mostly depending upon how much revenue or customer satisfaction is directly attributable to your work or on how much cost you avoided by your efforts.
Let me return to m 'upsell’ example from part 1, with numbers that are totally fictional for my organization. Lets say that I determine those upsells are bypassed 100,000 times per day and are only effective 50 times during any given business day. If those upsells produce $2 in extra revenue each, that’s $100 per day. If I determine that each upsell takes approximately 5 extra seconds per customer call, then that’s 500,000 seconds per day. Divide that up by an average 8 hour shift and you have approximately 17.36 hours at an average cost of $10/hour, making an expense of $173.60 per day. Say that of the $100 in revenue, you only make $15 in profit (before labor is removed) but have $173.60 in labor expense and those upsells start to look like a REALLY bad investment.
Not only could I actually save money by eliminating the upsells, but I save money by having a smaller code base and thus, less maintenance and documentation for developers and analysts. I’m sure there are other costs you could conceivable add in here (electricity, wear on servers, drive space, you get the idea) but the numbers make up the point.
Lets flip the scenario around and assume I figure out a way to make those upsells intelligent by looking at the customer’s past order history, the items they’re ordering now and the types of products other customers with the same demographic profile and then making smarter recommendations. If I up the number of upsells from 50 to 10,000, then the picture starts to look very different. Suddenly, I’m making $4,000 in profit (again before labor is removed) on $173.60 worth of employee time. When the order takers start to realize how potent of a weapon that upsell is in driving sales, they’ll probably pay more attention and use it more, driving even more sales.
Still Not Perfect
Once again we’re at a problem in our measurements because how do you know what is directly attributable to your performance and what is not. If you captured the requirement, but it was really the idea of a stakeholder, should you get credit for that? If the developer is the one that did the analysis to find the exact ratio between all the inputs, should all that revenue pot (or a percentage of it) be theirs?
This is where you have to factor in two more items: team and time. You really need to take a look at who was involved and their contribution to each saving or selling that made the difference. Second, you can’t do one project, feature or phase, but have to measure over time. You get a slice of every addition you make and then each of those slices are averaged over a long horizon, and I’m talking years here not just a financial period.
By focusing on a team, and I don’t mean that in the reporting structure definition of the word, you get lots of other side benefits like cohesion, group survivability, etc plus you remove the problem of needing precise measurements of who added what to each individual project. If someone fails to perform over time, the rest of the team will ensure that they either begin to contribute equally or that the underperformer leaves.
Measuring over time takes away the pressure of the financial cycle and puts the focus on long term health of the business. It also ensures that knowledge stays within a business and, if combined with an HR team that really understands how to recruit and retain top talent, allows for new, high-performing junior team members to gain an immediate foothold and be rewarded for their contributions.
Analysis
So, am I dreaming here? Does this make sense? Do you have a better idea? Let me know in the comments!