Performance Reviews in Development Teams - KPIs

Every year in the three I've been here at Salmat we've had a different performance review process. From a minimal and uncontrolled process of my first year where we were informed that our results would have no impact on our wage increase to this year where we had a good and indepth review where we were told that our results would directly affect our wage increase. Also worth noting is that the whole company has the same performance review process. This is an interesting scenario. These reviews almost always have KPIs of a quantitative nature. This works fine for some sections of IT, but in development it is very difficult define quantitative KPIs due to the nature of the work. Varying length of projects and the constantly evolving environment are the main reasons for this. For example you can't specify a number of issues for a yearly period. In one year you might complete thousands, and in another perhaps just one. This might be an extreme example, but it makes the point. So how do you define KPIs without quantative results? By having subjective KPIs. For this year I have discussed with my manager the use of subjective KPI ratings that we can discuss with my team during the year at regular review and at the end of the year. I don't know how well this is going to work, but as long as the reviews are regular we should be able to keep track of it during the year. An example of this would be a KPI to do with delivery time. The outcome is defined to be meeting 75 percent development deadlines. This sounds like it may not be all that objective if you track issues close enough, but in our environment there is so much change that deadlines are often redefined to meet the business needs. During our regular reviews we will review the projects for that month and the outcome of the development tasks assigned to each developer. I'd like to keep track of how this goes during the year and update my blog as I go. I'll try to get some feedback from my team as we go as well.