The most fundamental priniciple of Kaizen is the centrality of quality.  This expresses itself in three ways.  First, quality is seen as central to reducing time and cost:  By avoiding defects, you save rework cost and time.   Second, quality is not the responsibility of a separate QA department.  It is everyone’s responsibility from the CEO to the frontline assembly person.  Third, quality is not an outcome but an ongoing process of improvement.  To capture this last idea, the quality goals in Kaizen tend to be seemingly outlandish, such as 1ppm defects (in manufacturing that’s 1 part per million).  The understanding is from the beginning that it will take years to achieve this goal.

Much of this contrasts sharply with how most software or Internet companies used to be organized (and many still are).  Quality is often relegated to a separate QA team.  Having developers code unit tests is a great start, but by itself does very little.  If unit tests are ok but the code does not integrate with the rest of the code, that is a defect.  If the endusers can’t figure out how to use the feature, that is a defect. If features are built that are not needed, that is a defect.

On each of these one can easily see how making quality central will ultimately result in both time and cost savings.  But Kaizen requires “patience, my you padawan."  Instead, many software organizations make time central.  Everything is driven by a release schedule with the mindset that getting the feature released on time not only justifies but requires increased cost and reduced quality.  

Goals too tend to be set based on what engineering believes is achievable without time delay, such as say three nines of uptime. From a Kaizen perspective the goal should be five nines.  With five nines as a goal, uptime has to be a process of constant improvement otherwise you will never get there.

In Kaizen then there is no activity that takes place inside an organization that is not profoundly informed by quality.  So an essential first step is for the top management team to embrace quality because there is no hope of having Kaizen succeed without that.  From there it needs to become core to the organization not as a top down mandate, but through the various Kaizen techniques I will describe in subsequent posts.

The most fundamental priniciple of Kaizen is the centrality of quality.  This expresses itself in three ways.  First, quality is seen as central to reducing time and cost:  By avoiding defects, you save rework cost and time.   Second, quality is not the responsibility of a separate QA department.  It is everyone’s responsibility from the CEO to the frontline assembly person.  Third, quality is not an outcome but an ongoing process of improvement.  To capture this last idea, the quality goals in Kaizen tend to be seemingly outlandish, such as 1ppm defects (in manufacturing that’s 1 part per million).  The understanding is from the beginning that it will take years to achieve this goal.

Much of this contrasts sharply with how most software or Internet companies used to be organized (and many still are).  Quality is often relegated to a separate QA team.  Having developers code unit tests is a great start, but by itself does very little.  If unit tests are ok but the code does not integrate with the rest of the code, that is a defect.  If the endusers can’t figure out how to use the feature, that is a defect. If features are built that are not needed, that is a defect.

On each of these one can easily see how making quality central will ultimately result in both time and cost savings.  But Kaizen requires “patience, my you padawan."  Instead, many software organizations make time central.  Everything is driven by a release schedule with the mindset that getting the feature released on time not only justifies but requires increased cost and reduced quality.  

Goals too tend to be set based on what engineering believes is achievable without time delay, such as say three nines of uptime. From a Kaizen perspective the goal should be five nines.  With five nines as a goal, uptime has to be a process of constant improvement otherwise you will never get there.

In Kaizen then there is no activity that takes place inside an organization that is not profoundly informed by quality.  So an essential first step is for the top management team to embrace quality because there is no hope of having Kaizen succeed without that.  From there it needs to become core to the organization not as a top down mandate, but through the various Kaizen techniques I will describe in subsequent posts.