Creating a bonus definition for an I.T. Manager - Any Ideas? [closed]

Not sure if this is a META question or not, but...

Anyone know of a good way to define an objective bonus structure for an I.T. manager? I've come up with the following criteria, but I'm not sure how best to evaluate the metrics:

• Operational (network uptime, website uptime, etc.)
• Support (helpdesk ticket turn-around times, etc.)
• Project (on time / on budget, execution, management effectiveness, etc.)

Of course these work great in theory, but how would one evaluate these metrics in an objective / fair way?

We use a 3rd party consulting firm for monitoring our uptime / resources, which could work for 'Operational', we have a Help Desk that I could run a SQL query on to generate statistics about tickets for 'Support', and I concede that at least half of the 'Project' evaluation will have to be subjective...

In any case I thought I'd reach out and see if anyone's attempted something similar.

Thanks...

Solution 1:

Honestly, I don't think IT Managers should get bonuses for uptime — uptime is part of our base job, and if we don't do that we shouldn't have the job. Even then, sometimes things happen outside of our control that pull this down, but that just makes it worse in terms of bonuses: we're rewarded or not for things we can't control.

I'm a little more sympathetic for support, but supporting users is really the same thing and it's just so easy to game. A manager who knows that's where his bonus comes from will have a tendency to create lots of simple tickets so that he meets his metric.

Really, when you're thinking about bonuses, you have to look at the projects. These are the areas where an IT Manager gets to be creative and show that he's worth not only what you pay him, but the bonus as well.

To evaluate projects objectively, you need to look at outcomes vs plans. For example, for next year you might plan a thin-client rollout in an area. The goals for this project are to reduce energy use and simplify management of those desktops, at a net savings of $X per year and initial cost of $Y.

To determine bonus level you might then use a formula like for X*5 - Y as total savings over a five year life of the installation, and put as much as 1/3 of that amount on the table as part of that manager's bonus for the year. Other projects would contribute other parts, and you're realizing potential savings from this project that will last longer than just the five year life of the initial installation because this service level is the new baseline for that area for the next deployment as well.

You then measure the actual costs of the implementation, actual management costs after completion, and actual energy use before and after to see how the manager did relative to the expectations for the project.

By contrast, a similar project in another area that just updated the PCs with this years equivalent model on the normal replacement cycle would not have any bonus impact, because that's just part of the normal function for that position. You want to use bonus money to reward creative work that helps the bottom line of the business.

Solution 2:

There is a large number of studies that seem to suggest that trying to build a bonus for objective criteria alone will just make people figure out how 'game the system' in a way to achieve the objective.

For example when people measure by ticket turn around time people a tech will just close the ticket as quickly as possible even if the problem is not solved.

Trying to measure pure uptime might encourage people to skip applying security patches or avoid required maintenance.

You might want to read 'The Upside of Irrationality', and 'Predictably Irrational' for more examples and discussions of studies that suggestion that bonuses are not as effective as management likes to believe.

If you do need to do this I am not saying objective criteria shouldn't be considered. But subjective criteria will also be necessary. Perhaps measure satisfaction with the resolution of tickets.