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. Let’s just keep piling on projects and get as much as we can out of the system.
Sounds good in theory, but it doesn’t work! It not only creates burnout but it also adds delays to your product development cycle due to queuing effects. Queuing happens when project task (arrival process) are waiting to be worked on (service process) and begin to pile up. But we keep adding more and more jobs in the queue and ask our people to do more with less, and wonder why time-to-market keeps slipping out.
People in motion is not a measurement of productivity and certainly not NPD success. It might look as if progress is being made, yet despite all the activity, new product launches are being delayed, and the ones that do launch have issues and need significant rework. And the work keeps piling up and everyone is scrambling to meet deadlines. The light at the end of the tunnel turns out to be a train wreck coming your way.
Keeping people busy is not the same as keeping people productive (i.e. don’t confuse motion with progress). 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. If we could only plan something inherently “new” in advance without making design mistakes. Concurrent engineering would be a smashing success.
What do we mean by productivity? Productivity is defined as the percentage of time spent on value added task. Launching products that have been proven desirable by the market and on time is the ultimate value add. When time-to-market is delayed the impact on the bottom line is very clear: It’s all the lost revenue opportunity a company incurs plus the added cost of your development team trying to get the product to market. That’s just for starters – there are other negative outcomes that happen including time lost on the lack of resources to develop the next great new product.
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.
But it could be worse. That three month window may have allowed a competitor to get to market first – and your market share drops from $4 million to $2 million! Maybe even lower depending on the first mover effect and how late your launch date slips. And perhaps by the time you launch the product, customer attitudes have changed. There are other alternatives available to them by the time your solutions hits the market. You end up with a product dud – doh!
Delaying product launches due to poor development productivity is real and measurable. And pushing your development team to accomplish more with less is a formula for failure. Instead you need your development team to focus on doing less to achieve more. Identify the right product opportunities that have the best overall product life cycle profit potential, and concentrate on these activities. It means cutting down the active projects in the development pipeline.
And be aware of the waste that over utilization of capacity creates. Waste due to over utilization of capacity has many forms including queuing. 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! Remember the Mars Climate Orbiter?
So don’t try to do more with less, but instead do less and accomplish more. Concentrate your resources on fewer and better projects to improve your overall product life cycle profit performance.
And watch out for those queues!
Kevin
Commentaires