Skip to main content

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.

Comments

  1. Nice article JR.

    1) Quality and grade are certainly different, but as a PM, grade is usually not in his control. "Grade" is built into the product spec as the preceding market research usually nails the "grade" as part of the product features. PM may get to negotiate bits and pieces, but the major chunk stays non-negotiable. (Or end up negotiating the resources)

    2) IMO, Consumer gap is often a result of poor requirement management or ambiguity in the common terms like "reliability" - if this is clarified with customer and a definite/clear understanding is established, this should go away.

    ReplyDelete
  2. Nice Aritice! Your explanation was simple and clear. Thanks

    ReplyDelete

Post a Comment

Popular posts from this blog

Kano Model of Customer Satisfaction - Notes to Self

Note: What follows is the notes taken from my study of Kano's model of Customer Satisfaction. I came across this model when i wanted to know if there was a structured approach that would help me prioritize features for software product development. 

To evaluate a product or service, following parameters are very important

The value provided - this helps attract customersThe Quality offered - This earns customer respectProduct or Service innovation - This helps differentiate from competition
But these are not perceived directly, but indirectly through the product and it's features. Kano's model help to group product features into 3 categories ( 6 categories, but only 3 are important) and there by makes it feasible to deliver value at a promised quality while offering innovation. 

The 3 important feature categories are 
Basic featuresLinear featuresExciters or DelightersBasic features are that must be present in the product to be successful. They are also referred to as must have…

Knowns, Unknowns and Project Management...

This article is a draft of a paper i started to write in september 2007 and left it where you see it today.  The purpose is to to come out with a conceptual framework through which “the knowledge needed to successfully execute a project” can be viewed and gauged and presents a brief outline of the same. As always comments are most welcome...
Financial Resources, Domain, Technology, Communication, Cultural Differences, Organizational Structure, Organizational Culture and Power Play within an organization are some of the factors that have an ultimate bearing on the success of a project.
All projects come in shades of grey is a fact that has to be acknowledged. For example, when we start a project, very rarely do we know everything about Project Requirement, Scope and other factors that impact the project. There will be lot of ambiguity and this ambiguity has to be accepted and put to proper use.
But the problem is that people usually look at these factors in black and white. This may be ac…

Aggressive Schedules - Few thoughts...

During my early years in the software industry, i used to look at people who worked in projects with aggressive schedules, in awe. The people working in such projects talked about, long hours, working week ends and heroic endeavors in their projects. The people who worked in such projects were given more awards and rewards, compared to others. i thought that this was the way to be.

After working in projects with aggressive schedules, I realized that what I saw was only the silver lining and there was a big dark cloud behind this ( talk about what experience can do for you). The common thread that linked all the projects was that all of them exhibited one or more of the following.
Project ended up delayed by more than 100% Project got cancelled Project got de-scopedProject has a high cost of maintenance.  Having been burnt up by working in projects with “Aggressive Schedules’, (henceforth denoted as AS), I understand that projects with aggressive schedules cause more damage than what we …