Quality and Grade

I and a few other colleagues were discussing software quality over lunch. One colleague was talking about an application which has features like displaying the equivalent database field in the browser tab, when the cursor is set on a screen field and mentioned that applications are not usually made to that quality. I told him that he is mixing up quality and grade and that is why he has made this statement. If you want to know the difference between these two terms that should not be interchangeably used, please read on. Take a best selling car like Maruti 800. It doesn’t have lot of features and it doesn’t make lots of promises other than high fuel efficiency and low maintenance cost. It doesn’t have a power window or a tachometer. It has only 800 cc of power and the pick-up is not so great when the AC is on. In older Marutis, you had to switch off the AC to get that extra bit of juice, when you overtake. Compare this to a Mercedes Benz. Feature wise, a Mercedes Benz any day will out do a Maruti 800. So why is everyone calling Maruti 800 a very successful* car? To understand this in detail, we have to define Quality and Grade first.

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

Coming back to the point where we started, why is Maruti 800 a great car? That is because though it has fewer features, it delivers on what it promises to do. So the next time, some one says that a software is of lower quality because it has fewer features, I hope we now know what to say :-)

*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.