Unless you measure something, you don’t know if that something is getting better or worse. You cannot manage if you don’t measure to see what is getting better and what is not.
Measuring performance allows to step away from the busy day-to-day operations and look at your business from a pure numbers perpective to gain valuable insights for improvement. It allows to set get goals and expectations. And to see what works and what does not work. It gives insight in long term trends, and at the same time allows for an early warning system — with leading indicators — when something does not work out as planned.
Measuring performance quantifies your business in a certain state at a certain point in time. This allows for communication about the business without getting lost in perception and noise — the “stories”. It allows you to compare reporting periods objectively, and it gives structure to communication of business results. And more importantly when done right, it gives room for communication looking forward based on leading indicators to influence business results for the next period.
If businesses aim for improvement, and I guess most businesses do, they cannot do without communication about business performance to create the right mindset in the organization.
In reply to Elena G.:
One that programmers will probably dislike, but can be effective is “number / criticality of defects found in production directly attributed to their code”
I always bear in mind that a programmer’s key role is to provide end user functionality. Correct code is a means to this end, so I would not use unit or integration test results for this.
When measuring software developer performance you can determine the efficiency of estimation as the (estimated time – actual time)/estimated time to determine how efficient the estimation is. This will relate to the variable direct labor costs to a project.
Metrics based on lines of code may be easy to quantify using the right change management tools, but do not reflect the efficiency of the developer or the accuracy of calculations or ability to meet other quality standards.
The act of willful measurement helps improve performance or quality of work from an employee (Hawthorne Effect), and I agree with Erik, that you cannot improve what you do not measure.
In reply to Elena G.:
Some could be:
1. How many “new feature additions” per annum, delivered customer outcomes?
2. Ratio of Number of hours used to program vs Number of downloads of the program (eg.: Through the Google Play Store for an Android application)
3. Customer feedback for the software/ feature
4. Number of solutions to incidents/bugs and time spent on the same
5. Number of bugs found during the lab tests and customer issues in UAT
6. Sales (increase/ base) vs cost of creating the product/feature
7. Reduction in the (user) time for the task after the feature/software was added to the live environment.