There are a lot of reasons why companies struggle with product development cycle times. Sometimes NPD teams simply underestimate how long it really takes to commercialize a new technology. Even the best of planning can’t totally eliminate unforeseen design challenges that throw monkey wrenches into the development cycle.
And have you ever been involved with a development project where a critical deliverable from a key vendor gets delayed pushing the launch date out further than was originally planned? Even if a team is able to redesign the critical deliverable out of the design, they are still faced with an unanticipated delay.
But perhaps the biggest problem affecting new product development cycle times is trying to do too many projects with too few resources.
Full utilization of development capacity is good, right? After all, under capacity is waste, right? So perhaps it makes sense to fully load your product development resources and get as much out of them as you can. Last thing we want is to have expensive resources sitting idle. But is that really true?
More activity leads to less productivity
In a study of productivity of engineering time, Wheelwright & Clark (Revolutionizing Product Development, 1992) determined that the ideal number of projects assigned to a single engineer is about two. According to their study, with just one project, productivity was around 70%.
The productivity is limited by dead time while waiting for input or actions that enabled work to continue. With two projects, the average productivity increased to 80%. An engineer can successfully address a second project during these wait times. Interestingly though, with 3 concurrent projects, productivity declines to 60%, and quickly drops and below 50% for 4 projects and continues to drop below 20% for 5 projects.
This productivity effect cascades across the product development system. Task are getting stuck in queues, and people are either waiting for outputs and or jumping ahead hoping all designs outputs will eventually converge and integrate perfectly as initially planned. In addition to effecting cycle times, queues also add risk and reduce quality by delaying feedback from downstream processing.
For example, if a designer makes a bad assumption about an interface specification, that isn’t discovered till near the end of the project because the test queues were too long and delayed – then a project team might be facing a huge redesign during final integration Or worse, during deployment! Just ask Health and Human Services Secretary Kathleen Sebelius what happens when feedback and testing is shortchanged in the NPD process!
Product launch delays can mean the difference between success and failure
Delaying product launches due to poor development productivity is real and measurable. Donald Reinertsen (author of The Principles of Product Development Flow) put it this way:
“Life cycle profit impact is ultimately the measurement of product development success…. Let’s say your new product introduction is projected to ramp up to $4 million per month by month two after introduction. And you delay the introduction by three months. You would effectively have lost $8 million dollars by delaying the project 3 months.”
Why do companies try to do more with less?
There are many factors involved ranging from the pressure of trying to get the most output they can from their limited development resources and “spreading risk” by doing multiple projects just in case a couple of them are duds. Nothing good in terms of development performance results from this misguided practice.
There may also be a real lack of understanding how much resources are really available in the product development pipeline (capacity), how much resources are required to complete development projects in progress (load), and a general lack of understanding of resource efficiency and the associated negative impacts of over loading the product development pipeline, including project delay and burn-out.
Too many projects? Your Project Portfolio Management System is probably broken
Too many projects in the product development pipeline is a sure tell-tale that a company lacks an effective product development portfolio system. A product development portfolio system provides a solution to selecting the best projects in the first place, and then allocate adequate resources to complete the active projects in the portfolio.
The first function of a portfolio system is to screen out product ideas that simply have marginal commercial value, poor strategic alignment, and/or too far outside the current capabilities of the company. There are many approaches to screening product ideas. The best approaches incorporate several factors including strategic fit, technical and core competency fit, market attractiveness, product and competitive advantages, and financial reward.
Focus on the best projects, and forget the rest
Too many projects in the product development pipeline almost always yields product launch delays and burned out staff. Your development resources are finite and they need to be managed and not over taxed. A product portfolio management system provides a solution to invest limited development resources on the best “bang-for-the-buck” opportunities while balancing risk and reward.
Here’s to achieving more by doing less!
Kevin