|
We received a request to write an article about why it is so difficult to get consistent middle management support for new approaches to product development (PD) performance improvement. These initiatives go by various names, such as Engineering Excellence, Design Excellence, Next-Generation Product Development, Design for Lean Six Sigma, Lean Design and Lean Product Development.
In my 30 years of PD process improvement experience in over 40 companies, universities and the Department of Defense, I have observed all sorts of management behavior with regard to programs designed to improve product development (PD). I have heard a lot about stalled PD improvement initiatives due to lack of support and follow-through by engineering supervisors, mid-management, directors and VPs of R&D organizations.
Too Many PD Schedules are Driven by Launch Date Only
The most common reason I attribute to the failure to achieve PD improvement is the laser-like focus to launch products on-time. The requirement that is rarely negotiable is the mandated end-date for the project. We have all heard the saying, "You have Cost, Schedule and Performance: pick two!" Well, I am here to tell you that saying is incorrect. Typically, it is Schedule that trumps both Cost and Performance. If you get into the mind and "heart" (...the center of fear!) of any mid-level manager in product development, you will find that they are driven by the launch date - period.
In the early days of Six Sigma, many DMAIC problem-solving projects were focused on fixing products that were prematurely launched after being rushed through development. It is almost always okay to do things over a second or third time and incur the expense to do so. If it were not okay, then upper management would prevent it from happening so frequently.
I also think Six Sigma was used heavily as a crutch to finish developing products and their production processes after launch. I will readily admit, if your new product is based upon a new technology, within a fairly new and forgiving market using new manufacturing technology - then a strategy of rushing the product to market and fixing it later with Lean Six Sigma is not necessarily unreasonable. This should be rare and used only as a short-term tactic as you continuously improve your ability to prevent problems during technology and product development. Ideally, development would be accomplished using a strategy of problem prevention and "do-it-right-the-first-time" work habits.
There are additional possible factors for failure to support PD improvement initiatives. Examples are when PD managers are distracted, overbooked, hands-off, or inexperienced in PD. It's important that PD leaders are proactively involved on (at least) a weekly basis with the project plans and progress, that they co-ordinate their team member's commitments across other projects, and that they have some experience in the unique challenges of the PD profession.
Get Clear With an Honest PD Schedule
Successful PD begins with a detailed, fully-documented, scalable, adaptable PD process that enables rational choices of the right set of task-tool sets to learn what is needed to fulfill the project's development requirements. A best practice is to have generic Microsoft (MS) Project Schedule templates built around your PD phases and gates or risk reviews. Start with the comprehensive generic MS Project template and select only those tasks that fit the specific project. It's easier to delete unneeded or irrelevant tasks from the generic template; that way, critical task details are not forgotten.
If there are multiple companies across your supply chain developing multiple subsystems and subassemblies - then it is essential to compare your PD and Systems Engineering Processes; level-set specific tasks, integrate their flows and establish sets of tools, methods and best practices that will help assure everybody is developing and learning what is necessary in a common, balanced time frame. The only thing left to do is get the actual engineers and supporting team members to sit down to talk their way through the project's task list, discuss the options and estimate how long it's going to take to do this project right the first time. Then run the project plan's estimated task times through a Monte Carlo simulation. If you don't do this exercise, there will be down-stream problems that could have been prevented. Many have told me, "that takes a lot of work!" - yes, it does and it's worth the time, money and courage to invest in an honest project plan!
Requirements are the basis for everything we do in PD. A good PD manager will seek balance between the cycle-time that is designed to rapidly execute the project with the constraints and best practices designed into the PD process. The operative word here is "designed". There is nothing ad-hoc about this environment. The requirements must balance across three key elements for success: the product, the project and the PD process - if you take the time to achieve this balance with reason, discipline and courage, you're on your way to doing things right the first time! |
