Do you waste 20% of time, AND don’t even know it?

Do you like to completely finish one step before moving to the next step? It does seem like a logical process to do, and many of us fall for that trap.  There may be a smarter way to work and which could result in a 20% improvement! Whilst personal time saving maybe less important to you, it is very important to business.  “Lean” concepts apply everywhere, not only in manufacturing. One-Piece Flow processing is a well-established Lean principle in manufacturing which gains a massive efficiency boast.  As a simple experiment, in the attached link, the Gemba Academy shows a 20% time saving just folding and filling envelopes. I have even applied this to volunteer work.  It allowed me to more quickly complete Scout’s administrative tasks and return to more important things, like planning the next adventure. So why is this so bad? In layman’s terms, completing each step requires double handling that slows things down and results in delays. In business terms, double handling increases product waiting.  When a product waits, no value is being produced the cost overheads and inventory go up.  In addition, if a later step did not work there was a risk earlier steps may need to be handled again. The good old days – software development I would like to discuss this in relation to software development.  In the early 1990’s I was a mainframe programmer working in a small team to develop a payroll capability.  I was responsible to write the main payroll program and I instinctively delivered customer value in small steps, or modules, before moving on to the next.  Working closely in a team, always communicating and bouncing ideas off each other creates a fantastic environment to excel.  Within a three-month period, it moved from a paper idea to running in a large corporation of 50k people and worked with minimal maintenance, even through the intense millennium bug period.  Even today, I am very proud of the high quality rapid delivery of my first complex program suite. During the mid to late nineties, a new improved process was enforced to ensure development staff provided higher quality deliveries every time.   We were instructed that requirements to be written, designed, built, tested and then implemented.  Often each step was done in double stages, high level and then detailed versions. Process Improvement Failed Us - Waterfall This new process was called the Waterfall Methodology, requiring clear validation and signoff of each step, before moving to the next.  This was thought to be a process improvement applied to software creation, ensuring it met the customer’s needs, designed correctly and delivered it to a high standard. As time progressed, bureaucracy increased with good process improvement intents, but failed in outcomes.  The detailed requirements captured upfront, rarely represented the true needs of the business or customer and those needs changed by the time it was available for customer use.  To make matters worse, each step often took months to complete and the available time, until the promised date, was compressed.   Of course documentation is important but the value of a 100% perfect document needs to be assessed.  The last big stage, Testing, was always compromised and often resulted in poor quality deliverables and needing repairs immediately after implementation. As a pragmatic person I was always frustrated by the cookie cutter, one size fits all, process.  In theory, there was no compromise to process to finish one step (eg create a detailed requirements document), get it approved before moving to the next process (eg commencing the entire design), get that approved before any construction commenced.   In my mind it was clearly ineffective, with handoffs to different teams. The Return of Agile “Agile” does to software development what one-piece flow has done to manufacturing.   It focuses on delivering value in small complete units and doing it regularly.  Like one-piece flow, this allows for feedback to be learnt and applied quickly.  Similarly, should the customer change requirements or cancel the order then minimal waste has been accumulated. I believe many early programmers aspired to this logic but failed to capitalise on the efficiencies before the waterfall process improvement took control. A deliberate choice with full knowledge is better than a choice by default.  Rarely are perfect outcomes achieved, so that means there are always opportunities to think smarter and efficiently. Call To Action Get ahead of the game Check out my guide“Growing Your Business Idea” Click here to get the guide right now.