Virtually all the quality training that people receive is designed to encourage a commitment to quality. This means that quality must be defined and then delivered. But, what has developed is a sort of ‘destination fixation’ that can be counterproductive.
The problem with a fixation on quality is that project team members lose sight of quality as a variable. Yes, it would be nice to deliver exactly as planned, but isn’t something better than nothing?
Some would say no – particularly those who have had a lot of quality management training. But the question of what is best needs to be asked of the stakeholders, not just the QC (quality control) staff.
I am not advocating for randomly abandoning quality standards. Instead I suggest that quality standards be prioritized. They need to be considered as variables that can be played against cost and schedule in a managed way.
If project deliverables are going to be useless if delivered late, doesn’t it make sense to at least deliver something? Some would say no, because an abandonment of quality standards can result in useless deliverables.
However, I believe that problems occur when the choice of which quality standards to change are randomly made. If however, there were a strategic reduction in quality standards for those aspects of the project that matter the least (from a QC perspective) then more is gained by a reduction in quality than by delivering a perfect project too late.
Stakeholders must be asked to prioritize quality standards according to their relationships to functionality.
Too little QC
Admittedly there is too little quality control on a lot of projects. However I believe that some of the reluctance to develop and adhere to quality standards comes from a reluctance to be ‘boxed in’.
By developing a plan that has predefined quality steps and priorities, the team is better able to make suitable trade-offs on behalf of stakeholders.
Just like every other aspect of project management, quality control is not a black and white issue. Brilliant quality management does not necessarily mean delivering exactly on specs, it means delivering the best value of specs given all the other project constraints.