You know what you’re going to measure to determine quality…but you know that the product won’t be perfect the first time out. You’re going to need a way to execute the measurement process multiple times – or at least enough to achieve a level of confidence that you have achieved the required level of quality. The important thing is to consider what you don’t know…about how much could be wrong, about what will need to be done to correct it, and about what it takes to measure again. Quality measurement is about combining art and science to get to the point where you can state confidently that now your product is “good enough".
This is the fourth part of a series of four articles on quality management. This part, Part 4, “Quality Measurement on Your Project: Measuring Quality in Quantity", looks at how to handle the need to measure over and over again – to a point where you can say, “good enough". Part 1, “Quality Management Step 1: Defining Quality on Your Project", examines what quality might look like on your particular project. Part 2, “How to Determine the Required Quality on Your Project", begins to identify the practicality of balancing quality with cost and resources. Part 3, “How to Measure Quality on Your Project", acknowledges that you need to measure in order to manage…but grapples with the challenge of determining what must be measured.
You know what the product of the project needs to roughly look like. You have a balanced view of the specific quality level needed based on making tradeoffs among resources, time, and quality. And you have determined an acceptable mans of measuring the quality, balancing reliability, accuracy, and cost.
And now you’re going to get lots of data as the project drives toward completion – producing a product that is measured to meet the pre-determined quality standards.
So, with lots of data expected, this element of quality management handles uncertainty with statistics and analysis.
In the world of software development, this involves what is simply often called Test-Fix-Test. But it’s not quite so simple, until you get a handle on the following factors:
The project team must be equipped to analyze the quality measurements and determine what changes need to be made to improve the metrics. The team needs to be competent in depth to understand the effects of small changes on the overall product…and come up with a plan to do just enough to move the results forward.
The technical team must be sufficiently competent to execute the determined fix. If the technical team actually analyzed the problem and came up with the solution, this is not so hard. But the team must have the capability to troubleshoot and solve problems down the stretch in order to achieve the desired quality level.
Statistically “Good Enough"
The statistical reality is that the quality measurements will not typically be perfect…but there will be an acceptable level. The key is to pre-determine what that acceptable level of quality is, and then to pre-determine what level of confidence, statistically, you need to have in order for the quality level to be acceptable.
It’s both art and science honing in on the quality level you need to complete the project.
Do you have a firm quality management plan that considers how you will analyze and act upon the quality measurement data you receive down the stretch?
This Post is Part of the Series: Quality Management
This series of four articles teaches how there is a commonality among things that represent quality and how to manage them.