Many people have made quality statements, like quality is free, quality is fitness for use, quality is remembered long after the price is forgotten, and quality is never an accident. I think that quality is the combination of “Understanding Why” and “Deciding How”.
Why?
At first, Quality is Understanding Why. Why a customer needs certain functionality? Why they need it next month, and not at the end of the year? Why they want the system available 24/7? And why they want the software easy to use, and want fast response times? Just knowing what your customer needs (the requirements) is not enough, you must understand why the customer (and your customer’s customers) need it; what is it that they wants to accomplish, what is important for them, what’s the value? Only then can you deliver quality!
Let’s look at an information system that collects and provides profiles about persons. There are many data fields, and often not all information is available when a new person is added. Several sources are parsed frequently to complete profiles as much as possible. This isn’t a perfect process, so sometimes the profile is incorrect. As IT developer, you make it clear to the users of the system that the quality of the profiles will be low.
But what if this is a criminal database, where one of the fields states whether a person can be armed and dangerous? As a police officer, you want this information to be correct, your life depends on it when you apprehend a person! Understanding why a police officer needs this field, and why it has to be accurate, explains the need for quality.
The quality can be increased by using information of different sources to state the chance that a person can be armed and dangerous. And by showing how much (or how little) information is available. This helps a police officer to make better decisions, and maybe ask for backup, before stopping a car or going into a building.
How?
Quality is also Deciding How. How will you deliver a quality product or service? How will you deliver it within budget and time constraints? With the professionals and the knowledge and skills that they have available? And which processes, methods and tools will you use to develop the product, and manage the project?
I see a lot of attention for the How. We have dozens of models like ISO 9000 and ISO 9126, TQM, CMMI, People-CMM, Agile and Lean, and Kanban that tell us how we should develop software, and manage development. We know how to do Agile Self-Assessments, Agile Retrospectives and Root Cause Analysis to improve the way that we do our work. We can even measure quality. But do we give enough attention to the Why?
Do we talk to our customers? Do we know what is important for them and why? Do we actually know who the customer is? Quality is in the eye of the beholder, so in the end, it’s our customer who judging if we are delivering quality or not, and what our product is worth.
Conclusion
Once you know why your customer needs the product or service, you can pick the best way how to do it. My experience is that, the better you know the why, the easier it becomes to decide how to do it: Why over How! The motivation of developers and managers goes up when they understand why the customer wants it.
So if you want to deliver quality, first make sure you Understand Why your customer needs it, and then Decide How to do it.
(This blog was posted aug 5, 2010, and updated aug 29, 2012: Polished and example added and updated dec 16 2013, linked it to customer needs, improvement tools and why over how).
