You’ve probably seen this happen: an organization creates a quality department without involving the process team. Or redesigns entire processes without questioning the impact on production. Or tries to solve quality problems without touching the processes that cause them.
The result is usually the same: a lot of effort, little progress — and the feeling that solutions never really stick.
There’s a reason for that. Production Engineering, Process Engineering, and Quality Engineering are not parallel disciplines — they are interdependent ones. Ignoring that relationship means trying to solve a problem with only part of the available tools.
This site exists to explore that interdependence: how these fields originated, where they converge, where they diverge — and how their principles and tools apply to software development and technology as well.
Defining the terms
Before going further, it’s worth aligning on the meaning of a few core concepts.
Engineering can be understood as the application of scientific and empirical methods to the use of available resources for human benefit — whether in the construction of physical works or in the design of systems and organizations.
Quality, broadly and at an introductory level, can be defined as a set of characteristics of a product or service that make it capable of meeting specifications and expectations. It is, however, a concept that resists a single definition — and that resistance is not a flaw, it’s a feature. There are more layers to that definition than first meet the eye. Explore the approaches to quality.
From these foundations, three fields of specialization take shape:
Production Engineering — designs, implements, operates, improves, and maintains integrated production systems for goods and services, involving people, materials, technology, information, and energy. It specifies, forecasts, and evaluates outcomes based on mathematics, physics, and the social sciences, combined with engineering analysis and design principles. (Based on definitions from the Institute of Industrial and Systems Engineers – IISE)
Process Engineering — aims to map, design, and optimize processes, identifying opportunities for improvement with a focus on efficiency, quality, and cost reduction.
Quality Engineering — a discipline that applies methodologies, tools, and technical principles to prevent defects, reduce variability, and ensure that products and services consistently meet customer requirements and expectations.
How these disciplines relate
Start with Production Engineering. Its core responsibilities — forecasting, designing, maintaining, evaluating, and improving — naturally raise questions: how do you forecast? How do you improve? Based on what do you evaluate?
Over time, the available answers stop being enough. Systems grow more complex, contexts shift, new problems emerge. At that point, three paths open up:
- Specialization: deeper expertise within an existing area;
- Derivation: a new field branching off from another (the way Process Engineering grew out of Production Engineering);
- Integration: bringing in complementary fields to answer questions that none of them can answer alone.
Quality Engineering occupies exactly that integration space. It doesn’t replace Production Engineering or Process Engineering — it cuts across both, providing the criteria, tools, and methodologies that make it possible to evaluate and improve what the other disciplines design and operate.
That’s why, in the most mature organizations, quality isn’t a siloed department: it’s a function that runs through the entire structure.
Why this matters for technology
Software has characteristics that set it apart from manufacturing: no physical variability in the replicated product, a marginal cost of copying close to zero, and the fact that what is “produced” in software is essentially the development process itself — not physical units of a product. But in a broader sense, software development is production. It has inputs, processes, outputs, variability, and a cost of poor quality. The questions Production Engineering asks about a manufacturing line are, to a large extent, the same questions a software engineering team should be asking about its development cycle.
Tools like PDCA, FMEA, Statistical Process Control, and value stream mapping weren’t created for software — but they can be applied to it directly, with adaptations or reinterpretations. And frameworks like DevOps and agile practices have conceptual foundations that trace back to the history of industrial quality.
Connecting those origins isn’t an academic exercise. It’s what allows you to understand why certain practices work — and how to adapt them when the context changes.
What you’ll find here
The content on this site follows a building-block logic: from theoretical foundations to practical applications, from the history of quality to everyday tools.
Topics are organized around three axes:
- Quality — the eras, dimensions, approaches, and tools of quality, from Garvin to Deming;
- Production — production systems, lean thinking, continuous improvement;
- Processes — process mapping, BPM, PDCA, and process management.
And running across all three: the application of these disciplines in software development and technology.
If you work in quality, production, processes, or software engineering — and want to understand the connections that often go unspoken in the day-to-day of organizations —, you’re in the right place.
