Mar 2016, Vol 9: #3
 
Skip introduces two paradigm changes for building development schedules. The counter-intuitive message is "slow down to hurry up!" -Carol
Changing Time-to-Launch Paradigms in Technology Development, Product Development and Production Operations
In my consulting practice, I advocate two types of paradigm changes regarding how long it should take to develop and launch a new product. They are:
  1. Don't trust anything that doesn't match up with logic and reason
  2. Slow down to hurry up when attempting to do things right the first time!
Logic, Reason and the Laws of Physics
When I introduce myself to my client's audience, I attempt to build their trust by saying, "If anything I say to you does not seem reasonable and defies your engineering logic as bounded by the known laws of physics, then stop me and let's discuss the issue". I then announce that when you are in my course of study with regard to any form of technical development process, you are in Law School! Smiles form across the room as everyone wonders what this means. I explain: everything we do in the development of technologies, products and production processes must follow The Law! It sounds like I'm talking about Intellectual Property law or some regulatory law like you see from the EPA or FDA. These matter a lot, but the "Laws" I'm referring to are those of Physics and Chemistry. So we are in Law School, and the Laws are those of Conservation of Energy and Mass. The Laws of Physics go to the heart of defining and controlling all functions and design/process characteristics that we are going to identify, develop and optimize. They form the basis for all concept development, mathematical modeling, empirical parametric definitions, measurements and proto type experimentation and ultimately production control specifications.
In the early 1990s, when I was under his mentorship at Eastman Kodak, Dr. Genichi Taguchi began our re-education as engineers by telling us we were confused and off-track by being too "quality-minded". That surprised us because the culture at Kodak was heavily grounded in quality metrics. He taught us to instead follow the mass of a thing...follow the energy of a thing... to understand how a function worked. Once mastered at this level, quality goals could then be considered. If the mass-energy relationships were governed under nominal and stressful conditions, then adjusting and controlling robust and tunable functions and their enabling design characteristics would fulfill quality expectations as much as physically possible.
Logic, reason and the laws of physics prevail during development projects; faith, hope and good intentions are not particularly relevant here. I once worked with a Chief Engineer who told us in a moment of exasperation that we just needed to believe we could meet our goals! As you might expect, it didn't help. The time it takes to develop a thing properly is set by the following of these laws. You might say surpassing the speed limit of learning by going too fast in product development is indeed breaking the law!
Slow Down to Hurry Up
I see many organizations whose marketing or financial management establish an aggressive launch date for a new product without a grass roots negotiation with the engineers and scientists who are going to develop the product. Rather, reason and logic (our first paradigm) should be used to build a bottoms-up schedule of tasks that must be done right the first time to assure the product meets its requirements and constraints. The tasks must be designed in such detail that we can measure progress task-by-task, day-by-day, week-by-week and month-by-month. There is no guessing, no hubris, no hoping that things will just turn out ok. Ideally, there is a work plan that can be modeled using Monte Carlo simulations across a MS Project scheduling plan. The schedule can be repeatedly run through simulation scenarios that apply various stress cases to illustrate outcomes if tasks vary from our estimates that are the inputs to the simulation model. A progressive project manager (PM) builds a bottoms-up schedule, defines milestones within the phases of the development process and tracks progress on a weekly basis. If progress slows, the PM sees it in real time - if you consider weekly attention to progress realistic and reasonable (trust me it is!).
Work Divided into Two Types: Preventive & Contingent
Furthermore, a progressive PM designates the work into 2 types. The first type are tasks that are critical to success and must be conducted preventively and at a rate that assures no foreseeable problems are allowed to stymie progress. The second type are tasks that are contingent in nature. The contingent tasks are designed to progress rapidly, while closely observing for pre-determined leading indicators that fore warn of task rate-of-completion slippage. If an agreed-to trigger point or tolerance limit to task completion rate is reached, the PM switches to a secondary, back up plan that is usually slower and more preventive in nature to assure the task is done completely to meet critical development goals in cost, performance and over all cycle time. Finally is the case where the development team is completely blind-sided by something they could not foresee or plan for. An example might be physics/chemistry-based hyper-sensitivities that are discovered and the problem is so difficult the rest of the schedule can't be met.  Sometimes the surprise is a late-breaking requirements change from Marketing necessitating technical changes to the development tasks, thus changing the launch date. Frankly, this happens often in just about every company I work with.
In summary - the goal is to build rational, logical development schedules that are customized for progressive time management using preventive task execution when the results from the task have to be right, contingent task execution where we can take the risk of more rapid work flow and closely monitor leading indicators that tell us when we must slow down a bit due to problems that materialized, and finally, the unpleasant use of corrective reaction to an unforeseeable event that compromises our schedule. This is what it means to "slow down to hurry up!"
Is there a topic you'd like us to write about? Have a question? We appreciate your feedback and suggestions! Simply "reply-to" this email. Thank you!
Sincerely,
 
Carol Biesemeyer
Business Manager and Newsletter Editor
Product Development Systems & Solutions Inc.
About PDSS Inc.
Product Development Systems & Solutions (PDSS) Inc.  is a professional services firm dedicated to assisting companies that design and manufacture complex products.  We help our clients accelerate their organic growth and achieve sustainable competitive advantage through functional excellence in product development and product line management.
  
Copyright 2016, PDSS Inc.