The following is a guest post by Peter Leeson. Peter Leeson is an international speaker and consultant in process and quality improvement, as well as a CMMI specialist and quality manager for White Clarke Group (UK) and the author of “Orchestrated Knowledge“. You can follow Peter on Twitter (@PeterLeeson) and LinkedIn.

Understanding Quality

The concept of Quality is a strange one. We all believe that we want Quality, but we are mostly unable to define it or explain it clearly. I want to buy Quality, I want to produce Quality, I want to sell Quality, yet I am unable to define what that means. Typically, we fall back on generic concepts that Quality is good enough to satisfy requirements, that it is the absence of defects. Like beauty, we cannot define it, because both are related to the relationship between the subject and the object. What I see as Quality is not what you see; in English we say that “beauty is in the eye of the beholder”, the same is true of Quality. What makes a book or a piece of music be considered as Quality?

In the world of IT, can we limit Quality to the “mean time between failures” or “meeting client requirements”? How can we ensure we are doing Quality work?

It has often been said that if you cannot define it, you cannot achieve it; the second version is that if you cannot measure it, you cannot define it. This would entail that it is critical to making sure you have some kind of definition which suits your circumstances, and yet, few companies manage this elementary step, but continue to advertise the primary importance of Quality within their strategy. “We don’t know what it is, but is most important.”

Understanding Quality is critical in a competitive world, and it needs to be understood in both a qualitative and a quantitative manner. Read that sentence again. Yes, I am saying you need to understand both the Quality of Quality, as well as being able to measure it objectively.

What does the Quality of Quality mean? If you have ever used the term “good quality” or “bad quality”, you have started to define Quality in qualitative terms. Meeting your clients’ expectations is not good Quality, but it is Quality: it is the minimum contractually required. You may believe that having no defects in your product is good quality, but it is not Quality, it is just what was expected – that is why you are required to correct defects free of charge.

Quality is the relationship between a subject (your client) and an object (your software), it is therefore how your software is perceived by your clients rather than anything intrinsic to the product itself. Quality is not objective, and it is not subjective, it is the link between the two. For many years, I have been using the formula Q=P/X to define this concept; it means that Quality is what you Produce divided by your clients’ eXpectations. In fact, I should probably update it and point out that the expectations aspect is a lot more important than previously considered: Q=P/X2 may be a more accurate formula.

Breaking this down into its component elements, what do we get? I will analyse them from right to left: Expectations, Production and finally Quality.

Quality Expectations

One of the biggest issues we have today is the concept of over-selling. We have salespeople who are rewarded on a contract signature rather than on the project’s profitability at the time of delivery. As a consequence, they are encouraged to promise more than is realistic and, raising expectations in terms of the features included, the time of delivery, the skills available, etc. When you have sold all the workforce to existing clients, you cannot sell more without creating issues in terms of expectations and the Quality of the projects, products, and services.

But the salesforce is not the only one to blame in our failure: it requires communication, understanding, and negotiation at the team level. It is very rare that expectations are clearly expressed, typically only requirements are communicated by the client; there is a big gap between requirements and expectations, and you need to understand and manage that. Talking to the client and finding out the expectations is something which has been promoted in theories for decades in the IT industry. We had, in the 1980s a software development lifecycle called “spiral”, in which prototypes were cumulatively constructed and reviewed by the client so as to ensure that no expectation was misinterpreted.

Today, we talk about Agile and Scrum as ways of expressing the same concepts, through continuous delivery and the management of change; this is basically a reinterpretation of the spiral lifecycle, with an additional part that corresponds to the “quality circles” which were also popular in the 1980s.

Unfortunately, this approach is rarely performed as recommended, meaning that, while the concept is in place, the client or end-user is not sufficiently involved in the process, instead s/he is replaced by a “customer representative” whose opinions are guess work, as (in)valid as anyone else.

Editor’s Note: This post is part one in a two part series. Part two will be published next week, July 26th.