Bill very kindly followed up on my earlier post and quite correctly pointed out:
"You cant collect useful metrics until you have a repeatable process because anything you collect wont relate to the process when its performed again - differently - cause its not repaeated".
I agree 100%, however my let out is the phrase 'Useful Software Metrics'. If we have no process to measure then find what can be measured now. Some examples might be: What is the salary bill for our developers? How many support calls do we get? Can we estimate the amount of rework we do from the timesheet system? and so on... Get some simple numbers -- they do not need to be precise or low level. This is your marker that gives you something to aim at and some justifcation for a budget; in the worst case they may be no more than guesses -- which is fine as long as everyone knows that. As you implement your processes then your metrics can become more sophisticated and the old metrics will become useless. Just keep asking the questions: (basically the Deming PDCA cycle)
  1. How much is what I am doing costing me today?
  2. How can I measure that better than I am now?
  3. How can I make what I do better and by how much do I think I can improve it?
  4. Did I improve it?
And further to Bill's chastisement, sadly the word metrics does not seem to have increased the traffic to my blog :-(.

powered by performancing firefox