Over Processing : Too Much of  a Good Thing, or the Self Inflicted Waste

Over-Processings Manufacturing Golden Days

In manufacturing Over-processing occurs any time more work is done on a piece other than what is required by the customer or using components that are more precise, complex, higher quality or expensive than absolutely required (sometimes referred to as "gold plating"). Simply over processing destroyed value by seducing organizations into not only paying more for their parts, but also working hand in hand with Delay to slow the delivery of parts. Like his other minions of waste colleagues, Over Processing fell victim to modern manufacturing practices with its relentless focus on increasing customer value and reducing time from concept to cash.

Over-Processing in Software

Just like his colleagues though Over-Processing found fertile ground to destroy value in the software world. Over-Processing is actually invited in by well meaning software development organizations confusing software development discipline with prescriptive practices.  Over-Processing found his home in many organizations as a software process improvement (SPI) efforts. Disguised as discipline by enterprises that were collapsing under the waste created by  random, un-repeatable software development practices, Over-Processing was often heralded as a solution.  He managed very well with the rise of various software quality standards and prescriptive methodologies. However in the early 2000s Over-Processing had quite a scare with the emergence of the Agile and Lean software development movements with their emphasis on fast feedback and value creation.  Fortunately for him he was saved by complex methodological frameworks and mis-application of agile practices. In fact, Over-processing was able to use labels like agile and lean to not only hide himself, but find hiding places for his colleagues….“as long as they think they’re agile, they will not come looking for us!” he would tell his colleagues.

Over-Processing's Vulnerability

Over processing's "discipline"disguise makes him hard to find and often in the software  world he is actually invited in with the best of intentions. There is a fear that if a processing step is not performed, or if a practice is not followed, then waste will be created in the form of defects. Traditional "cost of change" economics often drive this perception.

There is also fear from a social point of view, that if do not have the structure imposed by Over-Processing then we will "not be on the same page". This is at best misguided because this is confusing alignment with organizational structure. One can be well structured and still mis-aligned.

These fears can be mitigated by understanding the economics that are actually driving your software projects. Smaller batches, fast feedback can help us quickly learn the economics driving our software project. Evidence of Over-processing is indicated by long feedback cycles (Delay), and accumulation of Inventory. Also often Unnecessary Motion and Movement can be discovered. Simply creating visibility in the form of a Kanban board can help us discover Over-Processing.