Efficiency Metric

I'm inspired by a very simple metric I've seen in a presentation from the lean software institute, which they refer to as "Staff Productivity". It is a deceptively simple equation:

Value Added Effort
----------------
Total Hours

This number cannot exceed 1.0. Value Added is defined in the sense found in "Re-Engineering the Corporation"; it is that value that is tangible to the end customer. I don't believe anyone can build an argument that says that maximizing this value is a bad thing. And therein lies the beauty of the metric.

If you can get your organization to agree that maximizing the metric is a good thing, then you can motivate people to actually measure it. It should appeal to engineers because they value creation, and it should appeal to management because it is a measure of output relative to expense.

Of course, here comes the tricky part: defining what is and is not value add. For example, if your development process includes "refactoring", then you either can include the original development time, or the refactoring time into Value Added Effort, but not both. The customer incurs no tangible benefit by your team re-doing something that is already done. If it needs to be re-done, then you cannot claim the customer got benefit from the original implementation. This is clearly true if the product has yet to go out the door, and perhaps arguable to some percentage if it has.

My point is this: your team undoubtedly has some bureaucracy that can be streamlined or removed. It isn't reasonable to assume you can get this number to 1.0, because you need to invest in the future effectiveness and efficiency of your organization as well as your short term efficiency. But if you define value add correctly, you can both remove unnecessary process steps and identify careless work habits and poor management practices. With appropriate care, you'll be able to justify that new development practice.