Quality metrics are one of the key outputs from the Plan Quality Management process and those metrics are applicable to both the quality of the product/service/result and the process used to produce that product/service/result.
A simple example might be defect density. We might have a target or goal for how many defects per X widgets we generate and would want to regularly monitor whether we are below that threshold or not.
Quality metrics will depend on the delivery model.
How many part defects per lot is a simple example of measuring quality, but that does not necessarily work for the processes used to create the part.
In an industrial environment where engineering documentation defines the part, rework (documentation revisions) is often considered waste and a measure of quality. High quality documentation should be released once, without errors, and produce a quality part the 1st time. People may hide issues with on-time release performance by releasing a low quality product on-time, and then fix the problems after their initial due date. This is sometimes known as "gaming" the metrics. Measuring 2nd effort can show a team is never late, but always revising their deliverables.
In an iterative agile approach, multiple releases are part of the process. Problems with each release are added to the backlog for inclusion in a later release. Sometimes it is acceptable. Other times it is not, so choose your quality metrics wisely. Saving Changes...
Peter RapinSubject Matter Expect; Project Delivery| Independent ConsultantOntario, Canada
I commend the recognition that there are two quality concerns - the delivery as well as the final product . A high quality delivery should result in a high quality product.
The metrics for each should be established in the initial stages. The obvious metrics for delivery would include compliance with the three major objectives; scope, costs and time. Customer satisfaction is there as well however achieving scope, cost and time objectives tend to result in customer satisfaction. One should also look at metrics related to communications, integration, documentation, etc - anything that can impact on the ability to successfully deliver the product.
In addition to measuring and comparing against a selected 'acceptable' standard one also has to track the trends. Are we getting better/worse? Is our trend going to get us where we want to go? Do we need to adjust?
However, one should not have to wait until delivery of the final product to determine if one has achieved the quality objective thus you need to establish intermediate metrics to enhance the probability of ultimate compliance/success.
Too many project managers fail to quality manage the delivery process. Saving Changes...
Yes, Quality Management is one of the principal areas of Project Management Knowledge, and Quality Metrics attempt to impartially measure a feature's excellence, and that is reflected in the product or service result. Saving Changes...
