The Point Model
This is the most important because it is the foundation for product quality. The sponsor's purpose or "point of quality" for the project is uncovered and clearly articulated. This is the closest our new quality model comes to the classic mantra of Customer Satisfaction, but with the critical difference that it is the result of a logical progression rather than a response to a survey.
Customers tend to consider quality primarily in subjective terms, so the PM uses the Point Model to ensure a shift from subjective to objective. Even this is an incomplete transition; objectives are usually only demonstrated when the product is largely finished, by which time it is too late. The model therefore requires a further decomposition of objectives into tangible product quality factors.
A product quality factor is defined as an observable feature of product design that promotes a desired quality objective (conformance to commercial or technical standards, ease of usage, ease of maintenance, adaptability, expandability, durability and etc.). Quality factors that support these objectives are evidence of product quality and may be graded as basic, standard, or superior. This way of thinking not only creates a logical and unambiguous method for documenting quality specifications in the quality plan, but also allows for the grade to be negotiated, rather than the politically fraught idea of negotiating to reduce quality.
Implementation Notes
Although the Point Model is universal, support in terms of checklists for common quality objectives and commonly derived quality factors are dependent on the application. IT and software development in my experience are lacking such support and this would be a useful inclusion in a reference guide.
Techniques are also needed to link subjective expression with derived factors. For example, sessions based on the Socratic Q&A method, bringing technical experts and customer requirements experts together, would proceed using the following high-level question set:
- What are your quality goals for the product? This yields a list of largely subjective needs.
- How will you know if your quality goals are met? This creates a list of quality objectives.
- What product feature would contribute to each of these objectives? This is the end result of the exercise, a list of definable quality factors to be built into the product.
Supplementary questions driving at system life and durability requirements, tangible benefits of quality factors, error-tolerance, maintenance and so forth, should also be prepared. Project time should be allocated for analysis of proposed quality factors.
Other techniques, such as Failure Analysis and Marketplace Analysis, can also contribute. Prioritization techniques will help prepare for potential trade-offs if this need is foreseen.
| 
Overview of the Quality Models
