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 make 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 a 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.
One of the biggest issues we have today is the concept of over-selling. We have salespeople who are rewarded on contract signature rather than on the project’s profitability at 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.
Producing Quality means that you are performing engineering practices in a manner that is consistent with the role of an engineer. This means a useful combination of analysis, planning, monitoring and controls.
The first question an engineer should be asking is related to the level of Quality expected. If I am building a bridge, I need to understand whether it is destined for an occasional pedestrian or a major city’s rush hour traffic – everything will change based on that simple metric; if I am building a train, I need to understand whether it is going to run in -40C in Siberia or in +40C in Saudi Arabia. If I am building software, I need to understand the type of person who will be using it, the expected throughput, the environment in which it will run, the degree of portability and maintainability that is required, the potential consequences of a failure. In addition to that, I need to understand the resources I will have to develop the product: the tools at my disposal, the competencies of the team members, the level of motivation, the relative importance of budget, schedule and Quality and more.
It we are going to produce Quality, it is not enough for the product “to do what it says”. We need to make sure it is adapted to expectations.
Quality engineering should always take into consideration the qualities of the product – these are measurable, demonstrable attributes of the product, such as portability, reliability, flexibility, maintainability and many others depending on the type of product being developed. These are qualities which can be discussed with the client, built into the product, measured and proven to satisfy requirements and potentially expectations, they should be considered in the engineering phases: designed, developed, embedded into the product, tested and demonstrated.
All people make mistakes, that is a fact of life. The purpose of quality practices, such as quality control and quality assurance is to see if the mistakes can be removed early in the lifecycle and lessons learnt before the mistake becomes a defect and requires increasesd resources to correct the situation. I am using different words here to clearly separate the lifecycle of an error from when it is under the full control of the author to when it used for a subsequent phase: “mistakes” are made but can be easily corrected; “defects” are mistakes that have been handed over to someone else for processing (e.g. coding errors found in testing, or requirements errors found in design).
Engineering quality involves planning, designing and building specific functions and attributes. This starts at the beginning of the process, when a plan needs to be set up defining what activities will be performed and how these support the focus on quality by the team. This is developed by the person responsible for coordinating the work (project manager, team leader, scrum master, programme director…) in collaboration with a person having the role of “quality assurance”.
Quality assurance will continue to support the project manager by ensuring that activities are not forgotten or missed, and, should it be necessary to deviate from the plan, lessons are learnt by the organization. The role of Quality Assurance is to proactively assure that people know what they are supposed to be doing and are doing it correctly to produce the desired level of quality; this is very different from quality control which reactively controls the quality of the products which have already been produced.
While the qualities are a major component of the Quality of the product, they are not everything.
If we are going to produce Quality, in addition to the standard engineering practices, we need some level of control that people know what they are doing and have the means to do it correctly. The final Quality involves the perception the user has of the product; that involves a number of characteristics which are not covered in the engineering values, including the environment in which the product will be used, as well as the items such as sensory perception, experience, emotions, ethics, language and culture of the users.
These aspects are rarely understood or managed efficiently as engineers believe that most people think as they do, and yet they are frequently more important than the actual intrinsic engineering quality of the product. This understanding places additional emphasis on the need to truly understand the expectations of the users, beyond their requirements.
Engineers, and particularly software engineers, are frequently higher than average on the autistic spectrum. This means that they have problems understanding that not everyone thinks in the same manner as they do and are baffled by statements such as “I don’t like it”, while they are busy explaining that the user interface is 87% more user-friendly than the previous system.
Focusing on Quality means understanding more than the minimum technical aspects of a product, it means understanding the context in which this is going to be used. If you run an airline, this can be relatively easy, because the users are all in a confined space which you can furnish and decorate; when creating a software product, which will be used in a number of different places, or in offices you have never visited, the problem is much more complex and needs more than engineering to be understood and managed. If you cannot afford to invest into the necessary sociological and environmental studies to manage that, you need to be absolutely sure that every other aspect of your product is technically of the highest standard. Remember that your unhappy clients will be more than happy to share their complaints with the rest of the world.