14 July 2010

Irrationality's Upside pt2: Project Manager Bonus Structure

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!


  1. Anonymous1:15 pm

    BOK WINK! Hilarious :)

  2. Anonymous11:33 pm

    would be nice to see an example of a good PM bonus structure. how about wrapping Customer Satisfaction rating into the mix?