Playbook Logo transparent
David Paulson

CEO

Inquisitive, provocative and results oriented, David is willing to dig into problems until their true essence is understood and the solution is executed. We love that at Playbook!

Posts containing:

3 Secrets of Highly Successful New Product Development Executives

David Paulson- 12/19/13 02:54 AM

 

3 Secrets of Highly Successful New Product Development Executives

At Playbook, we work with a lot of great Fortune 500 companies that are adopting next generation—lean, agile and flow—approaches to new product development.

Here are the top 3 profit making lessons we have learned about from working with some of the best new product development executives. Get ready to change your mindset as you may find some of the secrets to their success counterintuitive.

  1. Cut your number of active projects by a lot (Usually a whole lot!)

    I was talking with one of our clients the other day about new product development. He told me a story about the great success he had when he accepted a new job at a medical device company. Like everyone else, they were having problems getting their projects done on time. In the first few weeks in his new role as Engineering Manager he cut the number of new product development projects from ten to two. A bold move, and seemingly counterintuitive.

    I wasn’t surprised when he told me the teams completed the two projects rather quickly, and my contact got branded a genius and became a VP a couple of years later. Remember, you get paid for how many projects you finish, not how many you start.

    The benefit of having less work in the system is easy to understand, but it takes guts to do. For some reason, people think that if work isn’t coming out of the system fast enough, that they need to put more in. But adding more just slows down what's already in there! The familiar analogy of traffic on the highway should be enough to help us recognize this proven principle, but for some reason people seem to resist it.

    The Success Secret: Limit work in progress. It increases throughput and allows new product development teams to complete work more quickly.

  2. Plan your resources with utilization rates around 60%

    I know I’ll get a lot of flak for this one, but it’s true. Almost every company I’ve ever talked to allocates their resources 100% in their project plans. This makes sense—they’re getting paid for eight hours, they ought to work for eight hours, right? But what do you mean by “work”? They may be at the company that many hours each day, but the number of hours they spend productively pushing projects forward is much less. Usually a lot less.

    Even fully dedicated team members only get five or six hours of work done in a day.

    This isn’t a bad thing; it’s just a fact. But the impact to a schedule for over allocating a resource is detrimental. Eric has outlined the details here, but being 33% over on allocation extends a schedule by 50%.

    The other problem with planning to 100% is that it allows no buffer for the variability that occurs in R&D.

    Ask any manufacturing engineer or manager what percent capacity they plan for in manufacturing and you'll get an answer around 80%.

    Think about that.

    They’re telling you they only plan for 6.4 hours of work each day for their resources!? Are they lazy? No, they know that even in systems with low variability that they need spare capacity to handle the normal variation that will occur.

    You don’t see anyone in Manufacturing getting in trouble for planning with spare capacity, so why does R&D think they have to plan for 100%? This is a big cause of late projects, and don’t worry—lowering the planned capacity won’t make the project take longer.

    The Success Secret: Use a lower capacity utilization when allocating resources. It won’t make projects take longer, but it will give you a more realistic schedule to start with.

  3. Have More Meetings

    Everyone I know complains about having too many meetings. But what they’re really complaining about is the ineffectiveness of them. Having status meetings every two weeks may sound like a good idea, but it causes problems. Since the meetings are so far apart, people have to spend time preparing for them. And then they sit there for two hours while everyone in the room gives their ten minute update.

    How often is something shared that you wish you had known about nine days ago when it happened?

    The information is coming in big batches. And that causes there to be too much information with most of it arriving much later than it should have.

    The solution is to have more meetings. But they need to be very short and very focused. Agile (Scrum) introduced the concept of daily stand-up meetings with great success. The key is making sure the protocol is followed, and the benefit is that everyone has the opportunity to hear about any relevant information within 24 hours of it occurring.

    Product development is really a process of learning, and the better the information flows, the better the system works.

    The Success Secret: Fast feedback is one of the most important elements in any high performance system. Have more, short and effective, daily meetings and you will have happier people and more successful projects.

I know these ideas raise a lot of questions so let me know if you have any. I’d be glad to go into further detail on any parts of these in future posts.

Would you like to learn more about Lean product development methods and tools?  Watch this on-demand webinar on Lean methods and a demonstration of Playbook Lean project management software.

Watch the Demo

Related articles


Guide to Lean Project Management
Guide to Lean Product Development
Science and economics behind “failing fast” 
Lean Product Development the Opportunity of the Century. 
Lean Product Development Case Study 
Principles of Lean Product Development
Lean Product Development Value Chain
Get started with Lean Product Development 
Lean Product Development: Cultural Resistance
4 ways to Ensure Your Lean product Development Initiative Won't Fail