I think it is difficult to do, but possible, if you use good case management software like FogBugz and keep track of old data. Obviously you can't say that we will improve performance by an exact number like 15%, but you can definitely do something about it.
So let's say you have:
1 month release cycle
These have to be pretty consistent from release to release, otherwise accounting for those can get messy. Here are some things you can measure and improve.
-- Estimates vs actual dev time.
Similar to Agile velocity.
If developers are planning to work whole month let's say 20 days or 100 days for 5 devs this month. They estimated all their tasks and told management that they can fit all the features. But it actually took 120 days instead of 100 days.
the 20 days (4 extra days for 5 devs), developers where under a lot of pressure and wrote a lot of spaghetti code.
So to improve performance - increase estimates for next month by 20% and see how much closer it becomes to actual time. Keep updating it for future releases if it is still way off the mark. The performance improvement will not be 20%, but should be substantial, since there is going to be a lot less stress, bugs, and working weekends.
-- Amount of time spent by developers for fixing bugs found by QA
Let's say for this rollout, it took 5 man/days for QA to test.
You can try to improve this number by having less bugs:
- Introduce Dev automated testing
- Make sure to allocate time for Refactoring and optimization before QA gets to it
- Code reviews
Keep measuring bug fixin time every release and you should see improvements if you introduce the things above.
-- Do some research on bottlenecks to development
You may find that there are other things, like communication between Business Side and developers, that are having a huge negative effect on performance. Many times a project can be delayed because of scope creep or feature requirements not clearly communicated. This usually happens over and over again.
This one is a bit hard to measure, but use can use measurements from 1. for this.
-- Type Faster...
Words per minute is a proven way to measure performance not only for developers but also anyone else using computers.
-- Measuring dev performance ain't easy
As other people already mentioned it is not easy thing to do, so how you communicate it to "upper management" is really important. They need to understand that measuring development is not like measuring sales. There is no hard numbers, but there are definitely some things you can improve. So you can give them a plan with some of the improvements and use measures from step 1. and 2. to demonstrate if there is improvement.