From the white paper:
Metrics are collectable statistics about a project or some aspect of it. They are important because they allow us to more objectively measure the status and progress of the project, as opposed to the classic (and usually inaccurate) "Well, it's about 80% done" estimate. They are also important because that which gets measured gets accomplished. Careful selection and collection of appropriate metrics can help drive a project to successful completion, since you can tie them to essential goals. Likewise, failure to do so can have serious consequences; Capers Jones cites "inaccurate metrics" and "inadequate measurement" as the two most serious risk factors in software projects (Jones, 1994).
Not all metrics are of equal value; some metrics are or can be irrelevant, misleading, or even counterproductive, especially in object-oriented development. For example, the classic "lines of code" (LOC) metric is dubious at best in traditional software development. What's more, it can actually be damaging in OOD if used as an indicator (and director) of progress, since OOD involves refactoring of class hierarchies to promote common code upwards, often reducing the lines of code. Therefore, you must carefully select metrics for relevance and with the aim of achieving agreed-upon goals.
Metrics must also be objective and repeatable (Henderson-Sellers, 1996). Objective means that the actual metric result must not vary significantly as different individuals collect it. Repeatable means that the same metric applied to the same project in the same state must not vary significantly (if at all) when collected.
Finally, for metrics to be effective, they have to be collected, examined, and used. This most often requires automated tools of some sort; manual collection of most significant metrics is too difficult for any but the smallest projects. Once collected, metrics are only as good as the attention paid to them.