As I write this post, I assume that the 8 Wastes of Manufacturing are pretty well documented and known. The 8 Manufacturing wastes (abbreviated as D.O.W.N.T.I.M.E) are Defects, Over-production, Waiting, Not Utilizing Talent, Transport, Inventory, Motion and Extra-processing.
In manufacturing, once you learn about the wastes above, it is relatively easy to visually and physically identify the wastes, quantify them and work on reducing them. For example, you can move a Torque Wrench from the tool supply cabinet to the operator’s workbench, and save 90 seconds of “motion” waste from the cycle time, and be able to quantitatively calculate that the move saved the company $2000 in labor costs over the course of a year.
However, as you move upstream to the Product Design and Development process, the wastes and inefficiencies become much harder to see and quantify. Moving a CAD Plotter or Test Lab closer to the Engineer will not do much to reduce the overall product development cycle time. Traditional work techniques like multi-tasking, or project management methods like GANTT, that seem to be tried-and-true ways of running an organization, often end up causing massive problems for Product Development.
So, without further ado, I’ll deep dive into the 8 Wastes of Product Development. I’ve categorized them under Mura, Muri and Muda because Mura is pretty much the category of waste that sets everything else in motion. I’m only focussing on the wastes that aren’t typically in the spotlight. Wastes like Rework, Over-processing etc are quite obvious and do not need further explanation.
Mura – Waste of Variation, Irregularity and Unevenness
High Process Variation – is caused by everyone performing tasks in their own way. This leads to the downstream functions receiving their tasks without a schedule or any predictability. Process Variations are generally caused due to not having standardized requirements for tasks or due to uneven skill-sets between members on the team. They can be minimized by a combination of professional development for the team-members with a focus on problem-solving, evening out skill-sets and setting standardized requirements for common project tasks such as Testing Procedures, CAD Drawing requirements etc.
Task Arrival Variation – Task requests that arrive at varying times without any schedule or predictability, can lead to varying delivery of completed tasks to the downstream customers. This can propagate Arrival Variation throughout the system, causing work to pile up and many other wastes. Task Arrival Variation can be reduced by using a Kanban-style pull-system, where the Task backlog and current tasks are visually displayed, and Engineers “pull” new tasks when current tasks are completed. Managers must try to prevent the team from getting sucked into constant fire-fighting by training teams on root cause analysis.
Stop & Go Tasks – Every time a person has to stop a task and pick it up again at a later time, there is a mental and physical “set-up” or “re-orientation” time involved. As Managers, be mindful of pulling your team off of current tasks to work on other “hot fires”. It can’t be avoided, but should be an exception, not become the norm.
Muri – Waste of Overburden
System Over-utilization occurs when a system is overburdened by too much work, far past a reasonable capacity. Once a system has reached approximately 80% utilization, adding even a little more work into the system can dramatically increase lead-times of all the existing work in the system. It also ends increasing Variability (Process and Arrival Variation) which only reduces the chances of the extra work getting completed on time, as the people doing the existing work get busier and busier.
Example: Imagine a popular 4-Lane free-way that thousands of commuters use everyday. In non-peak times (11am – 3pm), cars entering the freeway from the exit ramps can easily merge onto the free-way without causing any back-ups or bottle-necks. However, those same cars entering the free-way from the exit ramps in Rush Hour, can’t merge easily and start backing up both the Exit Ramp and the Free-way causing an accordion like ripple effect throughout the free-way and increase the amount of time spent in traffic by hours for everybody already on the free-way. So, the solution would be to install a “metering” traffic-light on the Exit Ramp that controls the pace of, and limits the flow of extra cars entering the free-way during Rush Hour. This example also serves to illustrate a solution to Task Arrival Variation.
Un-synchronized Concurrent Tasks – Concurrent Engineering is a method used in Product Development where different stages/teams/functions try to run simultaneously instead of sequentially (traditional waterfall/GANTT). When done correctly, it can shave weeks or months off the Product development cycle time. However, many teams try this without understanding it (un-synchronized) and end up creating high process and arrival variation, rework and overburden the system.
Traditional Product Development is Sequential 
Lean Product Development is concurrent or simultaneous
The key to synchronizing Concurrent engineering is to spend time mapping and understanding the inter-dependencies between the various stages and functions and knowing how much of the information being passed concurrently is STABLE! Let the downstream teams know how much of the data being given to them is stable and how much is likely to change as new information comes to the team. A little bit of rework is inevitable, but at least the downstream stages can plan for or around it.
For example, after a Pilot Production Run, your team discovers unexpected failures that require you to explore some last minute design changes and additional testing. You are not going to change the Raw Materials or the Quantities you order in Production, so you release the suppliers to go ahead and buy Raw Materials. This helps buy some time for additional testing, saves a few weeks worth of purchasing lead-time, as the Suppliers will have the Raw Material ready in Inventory by the time testing has completed and the “back-up” design is ready to go into Production. The Raw Materials and Production quantities were the STABLE information in this example.
Muda – Pure and Incidental Wastes
Since Product Development is a game of gaining knowledge as quickly as possible, the pure and incidental wastes deal with how that Knowledge is made ineffective, disrupted or left unused.
Scatter are actions that disrupt the flow of gaining knowledge and make it ineffective. Examples of scatter include –
- Reorganizing your team when things are going badly. This effectively cancels out any knowledge the old team might’ve gained by interacting with each other.
- Adding more tasks and checklist to the PD process when there are many product failures. This just distracts the PD team. The lean response is to find and fix the root cause.
- Adding rush development projects when the customers want something new. This just overloads the team and produces new failures. The lean response is to have a product road-map that generates a cadence for launches of new innovative products.
- Harassing team for faster results. This only works for the harasser, but the rest of the team gets slower as they drop one project for another and that reduces efficiency.
Hand-Offs occur when transforming information or material from one team to another. Hand-off’s are a very common outcome of traditional sequential Product-development approaches when moving from one stage to another. Why are Hand-off’s considered a waste? The best teachers on their best days get across only 30% of their knowledge. So, when you take a large batch of information and hand it off to another team or function, it results in them making poor decisions because they don’t understand the information well enough. Hand-off’s generate the other wastes of Useless Information and Waiting. Examples of Hand-off include –
- Holding Project Managers responsible for meeting specifications defined by some other department.
- Breaking Engineering groups up into various sub-teams – CAD, Testing, etc
- Transferring a large packet of Product CAD drawings to Manufacturing without ever asking them for their feedback during the development process.
Wishful Thinking is making decisions blindly without having data or hard evidence. It includes making decisions assuming certain events will occur in the future (the TAMH effect – Then a Miracle Happened!). Wishful Thinking often results in the wastes of Discarded Knowledge. Examples of Wishful thinking include –
- Setting rigid specifications at the very beginning of a project. Boxing yourself in at the beginning of a project without being open to new information that develops during the course of the project is terrible!
- Testing to specifications instead of testing to failure. You learn a lot more when testing to failure, information that can help the next project.
- Assuming knowledge gained over a project will be re-used on future projects. Unless a study of past project failures is built into the PD process, it will never happen.
- Assuming Manufacturing will figure out a way to make a complicated engineering detail without Quality issues. Always include the Manufacturing teams up-front during the development process.
6 Thoughts