Let us look at PMBOK’s definition.
Quality is the degree to which a set of inherent characteristics fulfill requirements. Stated and Implied needs are the inputs to developing project requirements. A critical element of quality management in the project context is to turn stakeholder needs, wants and expectations into requirements through stakeholder analysis performed during project Scope Management.
Grade is a category assigned to products of services having the same functional use, but different technical characteristics.
Quality and Grade are not the same. Low quality is always a problem; low grade may not be. For example, a software product can be of high quality (no obvious defects, readable manual) and low grade (a limited number of features), or of low quality (many defects, poorly organized user documentation) and high grade (numerous features).
The variants that come in a car are a good example of grade. A Maruti Swift (petrol) comes in three grades. Lxi, Vxi and Zxi. In case of software, Windows Vista comes in 5 different grades, Ultimate, Home Premium, Home basic, Business and Enterprise. Typically higher grade products have more features and cost more to manufacture than lower grades. While it has been easy to get the definition of quality, getting quality requirements right, for a project is not that easy. Let us see why.
Conforming to quality and maintaining the level of Quality is a tricky business. Quality is also in the eye of the buyer or customer—not only the seller. So every application/product tends to have 2 kinds of “Quality Gaps” – the producer (seller) gap and the consumer (buyer) gap.
Producer gap occurs when there is a difference between specification (documented requirements) and what is actually delivered.
Consumer gap occurs because what the customer wanted and what the producer actually delivered are not the same. While whatever mentioned above is universally true, for software, it becomes a little bit more complicated.
- In case of software, the following things tend to happen
- There is a tension between customer quality requirements (efficiency, reliability, etc.) and developer quality requirements (maintainability, reusability, etc.)
- Some quality requirements are difficult to specify in an unambiguous way
- Software specifications are usually incomplete and often inconsistent.
This is the reason why quality management is an integral part of Project Management and an important area of work for a project manager.The project manager has to arrive at the right level of quality and grade required for a project and ensure that the project output conforms to the same. It is relatively easier to establish grade and conform to it, but managing quality is altogether a different story. In managing quality, the project manager has to manage the consumer gap and producer gap. Consumer gap is the more difficult one to manage since this means knowing what is there in the customer’s mind. Once this gap is covered to a greater extent, working on the producer gap is easier as the target is more tangible.
A Manager has to close the gaps by
- Manage the customer interaction better and set the right expectation to close the consumer gap*.
- Putting in place the right processes that ensure consistency in the delivery to close Producer’s gap
*Here I am making an implicit assumption that success can't be achieved without quality.
*Closing the consumer gap doesn’t always mean providing to the needs of the customer. It should also be looked upon as setting the right expectation – which in turn leads to a gap that is easier to manage.