Evaluating Performance for Project Professionals

This post originally appeared December 3, 2010 on BetterProjects.net.

Being a business analyst in the service sector, its always been slightly amusing to me the ways in which my bonus has been structured versus the company’s performance. My main job has always been to design processes and develop requirements for how people interact with computer systems. While I have generally focused more on how the business interacts with the system, there has always been a systems piece to the equation.

Usually my bonus plan is tied mostly to driving revenue. This is funny to me because of how little direct impact I can actually do to drive sales. Yes, my systems element means I can drive sales by making the system usage as unobtrusive and as easy to use for the end user as I can, which means that same end user can take more sales calls. However, when you watch an end user on these systems, the time they actually spend using the system is only a small fraction of the total time they are performing their duties. If a 40 hour per week user only interacts with the system a total of 1 hour during their work week, me shaving off a few seconds here or there isn’t going to do much of anything to drive sales.

This is what Dan Ariely is referring to as ‘random noise’ in this blog post about linking performance pay to outcomes that can not be controlled by the employee. There are a lot of great quotes in this article, but here’s my favorite:

In the real world, the random noise is often more subtle and various—a hundred little things rather than one big thing. But the effect is the same. Rewarding and penalizing leaders based on outcomes overestimates how much variance people actually control. (This works both ways: Just as good managers can suffer from bad outcomes not of their own making, bad managers can be rewarded for good outcomes that occur in spite of their ineptitude.) In fact, the more unpredictable an environment becomes, the more an outcomes-based approach ends up rewarding or penalizing noise.

I see this being applicable to more than just upper management. It applies to those of us in projects as well.

For projects that are very dynamic, especially those that are in organizations operating in start-up mode or in markets facing a great deal of turmoil, outcomes may not be the right success criteria. It might be better to evaluate based on how closely the project keeps to the organization’s goals and standards.

For project managers, especially those on long-term waterfall projects, being on budget may not be as important as keeping the sponsors constantly aware of where the project is tracking against an estimated spend rate and providing input on what can be done to decrease expenditures while keeping the quality and timeliness within expectations.

For business analysts, this could be expressed by basing performance on creative ways to implement requirements without requiring costly system changes.

For both PMs and BAs, part of the bonus could be tied to their own customer service. If each project member were rated by their stakeholders on how effective they were at meeting the needs and expectations of the stakeholders, that would give a better indication as to which project professionals were effective and which were not.

In the end, I come down with Ariely saying that these changes are not easy, but that is no reason for us to not push for them. Yes, there will always be an element of performance that should be tied to pay incentives, but that incentive is often much weaker than our current compensation structure believes it to be.