The Use of Measures in Determining Value
Wednesday, January 28, 2015
We live in a world of science and mathematics. Data must be collected. Hypotheses must be proved. Formulas must be applied. In many cases, a rigorous approach can do wonders to improve business outcomes. Unfortunately, this type of rigorous approach can mislead economic actors into purchasing the wrong offerings.
One of my first high-profile projects was to lead a software development effort for an external customer. I received a pile of source code from the original programmers along with a list of work items that had yet to be completed. The code was a complete mess. It was buggy, unorganized and nonsensical. Nevertheless, my team and I worked hard, and delivered an improved, reworked version that was on time and within budget. The customer was ecstatic. We had fulfilled every request that he had made. In addition, we also modularized the code so that future teams could go in and make changes very easily and at a greatly reduced cost.
Our customer was happy. We were happy. Everything was great... until the corporate oversight group found our internal documentation. The original system had been quite large - hundreds of thousands of lines of gobbledygook, while our more functional and more usable version was a mere half of the original size. Unfortunately for us, this meant that the traditional measure of software engineering productivity (a count of the lines of code in a software project) caused us to appear quite inefficient.
Not only couldn't we show the "industry standard" of 4 lines of debugged, functional code per hour, we couldn't even show any at all! By this measure, our net progress had been negative over the course of the project. As if that weren't bad enough, our numbers negatively affected the division's numbers in a report that was owed to senior management. The managers didn't want to read through letters of appreciation or completed requirements checklists. They were rigorous numbers men - and that meant that they needed spreadsheets to demonstrate that productivity was suitably high.
The whole issue generated an amazing amount of dismay, and new rules were issued: no more cleaning up old code. Though this strategy would ultimately lead to lower quality software that was more difficult and expensive to maintain, the new policy would assist in the standardization of metrics and allow teams to be compared to each other with greater ease.
In this case, the managers confused their end-goals with the measures intended to help guide them. As a result, their productivity measures improved while their actual productivity dropped. So, what does this mean for businesses? When one produces a product, one must always think about the criteria that a customer will use to evaluate an offering. There is often a reason to believe that the measures and metrics selected by one party will not be optimal. A vendor has but two choices: train the customers or adapt the offering. If you'd like to learn some more pricing tips, why not contact me for a consult or grab a copy of my book on setting a price for software.