Quality is not an accident and not the talent of individual employees, it is the result of built-in rules. This sentence is easy to say and very hard to live by. Most companies I have worked with understand quality control like this: at the end of the process stands a person who looks at the result and says "good" or "redo". It is like placing a single guard at the exit of a huge factory and hoping he will notice everything that went wrong in forty workshops.
I came to business from programming, and in programming this illusion died long ago and loudly. A tester at the end of development does not make a product high-quality. He only finds some of the errors that have already cost money. The client finds the rest. And the same thing happens in any business: in manufacturing, services, sales, delivery.
The guard versus the immune system
There are two fundamentally different approaches to quality. The first I call "the guard": checking at the exit. The second is "the immune system": quality is built into every cell of the process, and an error is detected where it occurs, while it is still small and cheap.
In the second half of the last century, Japanese car plants did something famous: any worker on the assembly line could pull a cord and stop the whole line if he saw a defect. American colleagues watched in horror: stopping the line costs a fortune. But the Japanese did the maths differently. A defect caught in the third minute of assembly costs pennies. A defect that reaches the buyer costs a recall, lawsuits and reputation. A couple of decades later the whole world was learning from them.
The moral is simple: the earlier an error is found, the cheaper it is. In software development there is a rough rule that an error found at the requirements stage is dozens of times cheaper than the same error found after launch. For business the proportions are similar, only instead of lines of code you have spoiled orders, unhappy clients and returns.
Tools that actually work
Checklists for recurring tasks. The most underrated tool in the history of management. Pilots use checklists before every take-off not because they cannot fly, but because even the best pilot will one day forget a detail. Surgeons introduced checklists in operating rooms, and complications dropped noticeably. If you have a process that repeats more than once a week (shipment, client onboarding, a release, month-end closing), it needs a checklist. A short one, five to ten items, only what people actually forget.
Customer feedback. The client is the best quality inspector because he evaluates the result, not the process. But you have to ask the right way. A survey "rate us from one to ten" is almost useless. What helps is the question "what should we have done differently" and a call to everyone who gave a low score. One such conversation gives more than a hundred questionnaires.
Internal process audits. Once a quarter someone with fresh eyes walks through a process from start to finish and writes down where he stumbles. He is not looking for culprits but for places where the process relies on memory, luck or the heroism of a specific person. That is exactly where quality leaks out.
Automatic checks. Everything a machine can check should be checked by a machine. The system will not let an order ship without payment, will not let a deal close without a signed contract, will not let a release go out if the automated tests are red. People get tired, get distracted, and check worse on Friday evening than on Monday morning. Code is equally picky at all times.
Quality nobody ordered
There is a flip side people rarely talk about. Quality can also be excessive. I have seen teams polish an internal tool for five employees as if it were a product for a million users. And I have seen companies introduce ISO not because they needed it but because "it looks respectable". A year later they had three thick binders of regulations nobody read and the same quality problems.
The right question is not "how do we make it perfect" but "what level of quality does the client need and how much is he willing to pay for it". Supermarket bread and bread from a good bakery differ in quality, and both have their buyers. Simple bread is not the problem. The problem is when it is fresh today and stale tomorrow. Quality is first of all predictability, not luxury.
Standards like ISO 9001 are useful when a company has grown and needs to prove its quality to large customers or regulators. But starting with them is like learning to swim by signing up for the Olympic trials. First learn to stay afloat: checklists, feedback, automatic checks. A formal quality management system will grow out of that naturally.
Quality metrics worth watching
- the share of orders or tasks reworked after delivery;
- the number of complaints and returns per hundred sales;
- the time from discovering a problem to fixing it;
- the share of clients who came back again.
The last metric is the most honest. A returning client has voted for your quality with money. No audit will tell you more.
Where to start tomorrow
Pick one process that generates the most complaints or rework. Walk through it yourself from start to finish, with a notebook. Write down every place where the result depends on whether a person remembers to do something. Turn those places into a checklist, and whatever you can, into an automatic check in the system.
At Ingello Systems we do this constantly, in our own processes and in our clients': when we automate accounting and operations, the first thing we build in are checks that stop an error from travelling past the place where it was born. It is more boring than a beautiful interface, but it is exactly what separates a system that works for years from a system that works until the first Monday after the key employee's vacation.
