Measurement is no longer optional

Measurement is no longer optional

Measurement is a topic that most IT practitioners would rather avoid discussing. Many practitioners feel that it not possible to measure software, or that all that matters is whether the customer is satisfied. IT managers tend to have a point of view that incorporates customer satisfaction and at least a notional view of how efficiently they are spending their budget. When managers or other leaders do discuss the topic of measurement, their arguments for measurement tend to begin intellectually.  Arguments begin with statements like, “we need to measure to ensure meet a model like the CMMI,” or “we need to measure to build knowledge so that we can estimate.” While these are good reasons to measure, many measurement programs are being driven by more basic and powerful need: the need to demonstrate efficiency. The demand for IT continues to explode in every organization I speak with. The problem is that IT, whether developing, enhancing or maintaining software, is expensive. Couple that expense with the cost to acquire and maintain hardware and the budgets of some IT organizations become larger than moderately industrialized countries, and are growing. The pressure that growing IT budgets create on the bottom line means that efficiency can no longer be a dirty word in IT organizations. If efficiency is, or is about to become, important then organizational measurement can’t be far away.

Much of the effort in the development field over the past ten to twelve years has been focused on effectiveness and customer satisfaction, as evidenced by the Agile movement. Efficiency has begun to creep back into the conversation under the auspices of Lean. Measurement programs focused on customer satisfaction now must be refitted to discuss time-to-market (how much time is needed get a unit of work to market), productivity (how much effort is needed to get a unit of work to market), cost efficiency (how much does a unit of work cost to come to market) and quality per unit of work. All of these metrics and the measures are based on need to be comparable and combinable across the whole of the IT organization.

A roadmap to develop measurement program can be as straightforward as: Defining Goals and Values

  • Developing Common Measures
  • Mapping the Linkage Between Goals and Common Measures
  • Identifying Measures and Metrics (Including Gap Analysis)
  • Validating Metrics to Needs, Goals and Values
  • Developing Metrics Definitions
  • Mapping Metrics Data Needs
  • Defining an Overall Dashboard

In 2014, many IT organization budgets are beginning to recover and grow; however, because of the huge backlog in demand for IT services and products the need for IT department to efficiently use their budgets is not going to change. What is going to change is the need for individual teams to solve their own measurement quandary, because all IT work needs to be combined, compared and evaluated. Solid measurement programs have to balance efficiency, effectiveness, quality and customer satisfaction.  The process starts with understanding the goals of the organization and then ensuring what gets measured and demonstrate progress against those goals.