In my previous two posts on Queues, I discussed the basics around Queing Theory, Little’s Law and the effects large queues have on the speed and costs of Product Development. In this post, I write about the devastating impact Capacity Utilization has on Product Development!
Most Product Development Managers (my earlier un-enlightened self included) think that we can complete Projects faster if everybody on the team is working a 100% of the available work-week. So, we assign projects and tasks to everybody on the team assuming they can all put in the 35-40 hrs/week.
But what invariably ends up happening is that the tasks take longer than planned. We have to constantly revise our timelines. A new problem crops up that poses an engineering challenge the team has never solved before. They can’t estimate how long it will take to navigate the roadblock. The junior engineer doesn’t work at the same pace or with the same skill level as the Senior Team Lead. Somebody calls in sick with the flu etc.
Product Development is a very unpredictable process to control. Therefore, loading up the team with work beyond their capacity (Muri), only amplifies the craziness or variability (Mura).
Capacity Utilization
Capacity Utilization is the biggest cause of large queue sizes. It is defined as the extent to which the available productive capacity is being used.
The average Product Development Manager loads their development process up to about 98.5%. When teams are loaded past 60% utilization, queue size roughly doubles. Each time the remaining available capacity reduces by half, the queue size roughly doubles.
My Product Development team at BDI comprises 3 Product Development engineers who work 8 hrs per day, 5 days per week. This means Capacity is 120 hrs/week. So, if I was assigning tasks, setting project timelines and deadlines using the Total Capacity, I’d be at 100% utilization.
However, we spend a lot of that 120 hours in huddles, team meetings, Coaching 1:1’s, unplanned fire-fights etc. It’s unrealistic for me, as the Manager to create Project Deadlines, Milestones and Deadlines using the 120 hrs/week number. In reality, the true available capacity for working on value-added New Product Development related activities is closer to about 5 hrs/day/engineer. That gives me only 75 hrs/week left to assign projects and tasks. That is about 62.5% of the Total Capacity in the week. That drops even further if one of my guys takes a sick day or comes in late.
Therefore, if I load my team up at anything beyond the true capacity of around 60%, it only decreases the chances that waiting tasks will reach the desk of one of my engineers quickly. That means the queue of waiting tasks keeps growing. Working at high levels of capcity utilization also just give your Product Developers less room and time to navigate obstacles and make the best decisions for the product and project. This leads to sub-par product and quality issues down the road.
How to increase Product Development capacity?
- Work on Continuous Improvement when you have downtime! Identify and eliminate wastes in the Product Development process to be more efficient and free up more existing capacity! At BDI, I build in about 2-3 hours/week of Continuous Improvement acttivity into our schedules. This is because CI will never get done if you don’t make time for it.
- Maintain a Time Log over several projects of Hot-spot tasks like CAD, Testing etc to get a rough average estimate of tasks that are common to all projects. Use this data in capacity planning after accounting for all the unplanned activity that crops up. Tools like Harvest plug-in to Project Management softwares like Asana and can simplify the reporting.
- If there’s any of you out there still using 2D CAD like AutoCAD, consider switching to 3D Parametric Modeling software like Solidworks, Autodesk Inventor, ProE etc. Couple it with a Data Management or PLM tool like SolidWorks PLM or Autodesk Vault for even more efficiency.
- Identify external resources to bolster the capacity of your internal team. AT BDI Furniture, we’ve had a lot of success tapping into the CAD and testing capabilities of our Suppliers’ engineering teams and and passing on some of the design work to them. This has an added benefit – getting your supplier’s to do the design work means they design with their manufacturing and process limitations in mind! Less chances of nasty project delaying surprises at the pilot-run stage.
- Cross-train your Product Development team. This allows them to share work more evenly. Also, this allows you to have a common queue of work from which any of the engineers can pull work as they complete prior tasks.
My posts on Queues have all been inspired from reading Don Reinertson’s “Principles of Product Development Flow”. I’ve done my best to try to simplify Don’s teachings into something a little more digestable with real world examples from my work and prior experience.
If you’ve enjoyed this article, please engage, like, share and comment! Consider reading these related articles – 5 Reasons Conventional Product Development does not lead to Innovation and Guarantee Innovation and Reduce Risk with SBCE
One thought