Metrics are a vital part of management. They are not the whole of management - one mistake people make is letting the 'tail wag the dog' when metrics drive what they do, rather than using metrics as a tool for making good decisions.
Because they are powerful, metrics, if used improperly, can also be dangerous. The ITIL book 'Continual Service Improvement' (CSI) describes a seven step process for improvement - one step in that process (step 4, Process the data) involved understanding what a metric actually means, in context, so, in the next step 'Present and use the information' it can be presented effectively and used to make sound decisions on what to improve and how. If metrics are misunderstood effort can be wasted in the wrong areas or, worse, the effort intended to make thing better can actually make them worse.
This is why deciding what metrics to measure is not a trivial matter. In fact metrics must be designed - and design takes account of all aspects of why something should be measured, what value it will bring the business and how it will be measured. So that when it comes time to evaluate the results, it is properly understood.
That is why the book Metrics for Service Management: Designing for ITIL specifically mentions design. The book does not simply present lots of metrics with the suggestion that they might work. What it does is, describe how to design metrics.
Metrics have to be designed for services - which requires an understanding of the service and what value it will deliver to the business and the user. The value is defined in the Service Strategy stage of a new service and the detail is documented in the Service Design Package (SDP). The SDP also includes the metrics along with an explanation of what they have been designed to measure and why.
Metrics are also designed to measure processes, both Service Management processes and business processes. The design of these metrics is integral to the design of processes. The whole point of defining things as processes is to enable them to be managed, and improved, effectively, properly designed metrics make the difference between a process delivering value to the business reliably and one that is ineffective and inefficient.
Metrics are important for understanding how well Service Management itself is performing and form the basis for the IT Balanced Scorecard. To design metrics properly it is necessary to understand, top-down, what value IT will deliver to the business, how Service Management will contribute to that and then how progress delivering the value can be measured and improved.
The process of designing metrics give value far beyond simply the metrics themselves. To do the design you have to understand the business, your customer, your users, the services you provide and all the value propositions that make up the business and its processes. This understanding enables you to be more effective in providing value and understanding what, exactly, the business requires in terms of services, processes and support.
Remember, to mention just one practical spin-off from designing metrics properly, that the utility of a service, as defined in ITIL, consists both of the Performance Supported (what the service does - the stuff that IT understands very well) and also the Constraints Removed (which IT tends not to understand at all. Designing metrics involves understanding exactly what the constraints are to the business that prevent it from succeeding in delivering value to its customers. Understanding this enables IT to then design services properly, not just to do impressive looking things, but to actually solve real business problems. Without the detailed work involved in designing metrics it is highly unlikely that IT will be able to understand these. So even the design process itself delivers business value!
Summarising this brief description of the importance of designing metrics, I'd say that you cannot have an effective Service Management capability unless you have an effective design capability to produce the metrics that both measure and define the value.
By Peter Brooks