|
measurement and control |
|
|
However, what cannot be measured cannot be controlled. It is always better to have some reasonable information about what has happened (and is happening), than to have none. Nothing can be learned from no information. Fact-based management will always be better than management by unsubstantiated assertion.
It is therefore necessary to formulate some simple metrics, even if these are rough and approximate. At a minimum, some metrics should be used which represent reported field failures and/or defects from the customer's point of view.
Metrics can give early benefits within a single organization, where the difficulties of calibration do not arise. Metrics increase predictability, and provide feedback that may allow increases in productivity and quality.
Metrics are a management tool, not a quick fix for problems. They must be used for learning, not punishment. Rewards (never punishment) may be associated with external measures (e.g. customer satisfaction).
The SPICE model and the SEI Capability Maturity Model rightly regard metrication as an essential step to get to the higher levels of maturity.
 |
There are many metrics that could be defined. If you used all of them, you would be for ever collecting metrics, and never doing the job. |
|
A few key metrics must be selected. The choice should be based on the quality drivers. This choice will vary by situation, as there is no single right answer independent of context. |
|
Metrication can be supported by tools. This certainly helps lighten the burden of metrics. But be aware of the danger of concentrating your measurement on what can easily be measured, instead of what really needs to be measured. |
|
Conformity to standards is a means to an end, not an end in itself; it is not itself a quality criterion. You should always ask what is achieved by such conformity, what is the purpose of these standards (e.g. completeness, reusability, or whatever); the real quality criteria are found in the answers to such questions. |
|
A metric may sometimes provide the symptom of a possible problem. Further (qualitative) analysis may be needed to determine whether there is a real problem. |
|
Don't restrict metrication to software and the software process. Consider metrics for other aspects of information systems development: planning, requirements analysis, implementation. |
|
All metrication should be available to the people actually doing the job, and training should be provided where necessary to enable them to use the metrics as tools for maintaining/improving the quality of their own work. |
 |
Metrication Barriers and Pitfallsveryard projects > software quality > software metrics > pitfalls |
|
Difficulty selecting & defining metrics |
|
Belief that metrics must be perfectly accurate in order to be usable |
|
Organizational resistance, perhaps caused by anxiety over poor results, fear of bureaucracy or general inertia. |
|
Long term wait for benefits (especially process metrics) |
|
Inadequate or insufficient tools, forcing manual calculation, storage and analysis of metrics. Needs simple automation/integration. |
|
Doubts about reusability of metrics. Difficulty calibrating metrics for comparison between two or more organizations (benchmarking). |
|
Fear of inappropriate (political) use of uncalibrated metrics. |
|
Belief that you can prove anything with statistics, so they are not worth having. |
|
Managers regard metrics as irrelevant |
|
Developers regard metrics as negative commentary |
|
Project staff burdened with data collection |
|
Metrics fail to generate improvement actions |
 |
Six Sigma - a true story
Pitfalls of six sigma metrication |
|
Metrication Shiftsveryard projects > project management > metrication > shifts |
The minister argued that a gap of a certain size was widely accepted by scientists as adequate for the production of "pure" seeds, which means no more than a fraction of a percent impurity. Therefore a gap of this size should also have been adequate for prevention of the spread of GM pollen.
It is interesting how, once a control or performance measure becomes
established for one purpose, it gets applied for an entirely different
purpose. The situation changes faster than the metric.
|
References & Recommended Readingveryard projects > project management > metrication > books |
 |
| title | comment | order details |
| Gerald M Weinberg
Quality Software Management Volume 2 First-Order Measurement New York: Dorset House, 1993 |
As a writer on systems and software, I regard Weinberg's
books with awe. He seems to have an endless stream of relevant anecdote
and insight, logically combined into a thorough and systematic analysis
of his subject. His books are always entertaining to read, and thought-provoking
on every page.
This book contains simple yet powerful techniques for measuring software products and processes, and for using these measurements intelligently. |
|
| top |  |
|
Copyright © 1999-2002 Veryard Projects Ltd http://www.veryard.com/projmgt/metrics.htm |
