Every day, I do a Gemba Walk around the BDI Warehouse. I notice a lot of Inventory around me, both Finished Goods and Work-in-Process. Inventory is nothing but a Queue, which needs to be managed. And just like Inventory, Queues in Product Development are equally harmful.
Why is tracking Inventory so damn important to the CFO? Simple,
Inventory = Cash $’s Tied up in Working Capital.
All the Dollars tied up in Inventory represents an Opportunity cost. If the cash wasn’t tied up in Inventory, it could be used towards other things like R&D, Marketing etc. Also, higher levels of Inventory pose a risk to the cash, in case the Inventory doesn’t sell or becomes obsolete or spoils. The point I’m making is that the big-ups always know the amount of cash tied up in Inventory, both Finished Goods and Work-in-Process (WIP) at any given time. It’s an important metric and they stay on top of it.
So, if I pop my head into my CFO’s office and say – “Hey Balance-sheet Bob, how much Design-in-Process (DIP) Inventory are we sitting on at this moment?”, the reply is usually a weird look and “Oh, what are you talking about? Never heard of Product Development inventory before. Sorry, PK”.
I walk through my own Engineering Department at BDI and there is nothing physically present or visual that shows me my DIP inventory at any given time. Our Industrial Designer and my Design Team Lead could take on 10 new projects overnight and quadruple the department’s workload and there would be nothing physically present to alert me of what just happened.
Why are Design Queues important?
Design-in-Process (DIP) Inventory is a Product Development Queue. It is invisible, and therefore not managed. It impacts the economics of Product Development in ways most Product Developers and Managers do not understand.
Queues in Product Development are worse than queues (Inventory) in Manufacturing. WIP and Finished Goods inventory in Manufacturing can be used up within 1- 4 weeks of production. However, Design-in-Process inventory could take anywhere from 6 to 18 months or longer to flush out, as Product Development is a lot slower than manufacturing. And since most companies do not track DIP, there are no systems to keep them in check.
Effect of Queues
A lot of the waste in Product Development processes are due to Queues.
- Queues increase cycle time and delay costs. The larger your Queue Size (DIP inventory), the longer it will take for those projects to reach the front of the line and be completed. See my last post on Queuing Theory and Little’s law formula.
- Product Development risk increases as Queue Size (DIP) increases. The longer our projects are in the queue waiting time, the more vulnerable the projects are to changing market conditions, changing customer’s preferences, quicker competitor introductions and changing technology.
- Product development process become a lot more variable as queue sizes (DIP) gets larger. WTH does this mean? As queue sizes become bigger, we tend to increase the work-loads on our engineers and developers, pushing them to work beyond their capacity. When people get overburdened, even the smallest changes in work or project scope can cause huge fluctuations and variability in the outcomes.
- Queues increase process costs. The more DIP we have, the more we have to track status on, report progress of etc. That’s just more time wasted in status update meetings.
- Queues reduce quality. They delay feedback from the downstream processes. As an example, I make a certain assumption regarding one of my suppliers’ ability to manufacture something. I e-mail them today asking for a clarification. If I get my answer within a day or two, then I do not make any future development decisions based on a potentially bad assumption. However, If I don’t get a response for another 2 weeks, then I take a gamble that my assumption is correct and make all future decisions for the next 2 weeks based on an incorrect assumption. Queues delay feedback and delayed feedback leads to higher costs due to rework. The waste caused due to delayed feedback increases exponentially, not linearly.
- Queues are demoralizing and demotivating. When engineers and developers can complete work quickly and pass them on to the next waiting process, they feel a sense of urgency and are motivated to complete the work quickly. However, if they know the next downstream process can’t process their work for another 5 weeks, there is no sense of urgency and they feel like they can stretch things out and slow their pace.
Begin measuring your Queues
So, after reading this, I encourage you to take steps to determine what your development queues look like, and begin quantifying them.
Over the next couple of projects, begin tracking the following variables – Average Throughput or Processing Time, and the Number of Projects Waiting in Queues or your Design-in-Process Inventory. Use Little’s Law formula to calculate your average Cycle Time.
Some tools to help manage Queues
- Visually see and assess the Design-in-Process Inventory (Miro)
- Track the number of open projects and tasks (Queue Size), (Asana)
- The Workload and Portfolio features in Asana to track average processing time
- Track the time spent on various tasks (Harvest).
- I run weekly and monthly reports to generate average throughput times for various task categories like CAD, Testing, Prototyping etc.
I am currently researching and evaluating some cloud-based tools like Kanbanize, Playbook etc to help us manage our D.I.P Inventory using Kanban boards. I’ll write a post comparing the various tools after we select one for use at BDI.
 Reinertson, Don – Principles of Product Development Flow