Re^2: Estimating future project timescales

Another example. I know of a company where they measured the "performance" of their support section by how quickly they closed open tickets. As you might expect, the support folks began boosting their performance rating simply by closing a ticket ... then opening a new one! Now, this annoyed the customer (who was told to start referring to a new ticket for the same problem) but, hey, they got their bonus for improved performance! The lesson here is that metrics become unreliable as soon as they are used as a basis for reward/punishment. Perhaps the best way to measure performance is from outside the team: for example, the performance of a support section is perhaps best measured by asking the customers how satisfied they are.

Comment on Re^2: Estimating future project timescales

Replies are listed 'Best First'.
Re^3: Estimating future project timescales by ysth (Canon) on Apr 18, 2005 at 01:11 UTC
This reminds me of some grocery stores here that have started to measure employees' speed at scanning items at checkout. Some workers (even shift managers) would subvert the measurements by hitting subtotal (which stops the timer) immediately after scanning each item. The loser here is the customer, who no longer gets to see (and validate) the price of each item as it is scanned.	[reply]
Re^3: Estimating future project timescales by DrHyde (Prior) on Apr 18, 2005 at 09:25 UTC
Of course, measuring a support team's performance is particularly tricky. No-one is perfectly satisfied with support teams, because they only get to interact with the support team when something has gone wrong. And that something - despite not being caused by the support team - inevitably sours the relationship somewhat. Better to measure change in customer perceptions (the customer hates us less this quarter) instead of merely what the current perception is (the customer hates us).	[reply]