Tenet #6: Standardize the routine
Although innovation necessarily involves risk and variability, much of what is done in Product Development is predictable and routine, so where does standardization make sense in an NPD process?
There are two types of standardization that may be discussed with respect to the NPD system:
- Processes and Tools
Processes and Tools
Let’s start with the fact that NPD is not the same as manufacturing operations. Ideally in manufacturing, there is no need to change anything. From the beginning, products launched into manufacturing are perfect, low cost, high yield and exhibit high reliability. The suppliers will never stop supplying critical parts and there will never be a need for a redesign of the product. Of course, this ideal is seldom achieved, and it is less likely to be achieved the more cutting-edge your products.
Still, there is a great deal about manufacturing that begs for standardization and an algorithmic approach to essentially every task. In fact, we count on this. In an algorithmic approach, you know the goal and how to get there through steps: Perform Steps A, B and C and receive a predictable result. Hopefully this will be a high quality product, on time, and according to customer needs. Of course Continuous Process Improvement (CPI) is needed because the world is not perfect. But even in this CPI effort, the hope is to find a new and improved algorithm on which to standardize, one that will give greater efficiencies and products that come closer to the ultimate goal. Regardless of how far away your processes are from perfect, and no matter how many CPI efforts you have sponsored, it is this standardization that assures the algorithm (the execution of Steps A, B and C) will deliver a predictable and desired outcome.
Research and NPD are inherently different from the manufacturing environment:
- The goal is information. The goal of the NPD process is not to create a product, but to create the necessary algorithm needed by manufacturing to repeatedly deliver high quality products on time, in order to delight customers. The goal is not to create a product, but to create knowledge.
- A cognitive approach is required. Although risk reduces and certainty improves through the product development process from concept to production pilot, some level of uncertainty in the appropriate path to success, the required knowledge, the processes and even the tools is present throughout the lifecycle. To achieve the goal of a solidly engineered solution will require cognitive reasoning rather than an algorithmic approach for most tasks. In other words, while we have growing understanding of what we want, for every project we will often require innovation and probably a new path to get there compared to what we have done before.
- Variation isn’t always bad. Variation in research and NPD is not always a bad thing, and will usually increase knowledge. In fact there is an optimum failure rate to maximize new knowledge generation. Succeed too often and you will learn nothing you didn’t already know. Fail too often and you will also learn very little. Some variation (and in fact some failure) is essential in the NPD process, since the goal is knowledge. Too much standardization and you will learn nothing new.
- There is a trade-off between innovation and standardization. Still, some tasks should be standardized; but you should only standardize those tasks from which you no longer expect nor desire further innovation that will deliver differentiation and value for the company. Standardization reduces opportunity for innovation around that task. For some tasks in NPD, this standardization is acceptable. For others, it is the antithesis of what is required.
Because of this difference between manufacturing operations and NPD, applying the mantra gained from lean theory and operations to “standardize tasks and processes” everywhere and for everything you do is misleading and in fact will choke your innovation engine.
You must be very selective in what, where and when you standardize. However, standardization in the right areas can deliver significant improvement in speed and effectiveness for a product development organization. These specific areas of standardization can be achieved with deep knowledge of the tools, processes, and trained resources needed, plus a knowledge of the efficiencies gained.
Examples of tasks that may be appropriate for standardization are quality checking of software, environmental verification of new hardware designs (temperature, vibration, shock, etc.), and the creation of quick guides for customer documentation. Areas that may make less sense to standardize are the process of designing a low phase noise oscillator, the process of designing a high power output stage or the process of designing a high voltage power supply.
I ran an R/D organization some years ago with a team whose members had a strong internal desire to improve on many levels. There were certain areas where the benefits of standardization were clear, and others that we reasoned should wait. For example, it was clear to us that we could get immediate benefit by standardizing on our engineering documentation by pulling documents out of numerous local servers and placing the information centrally. We created an engineering wiki site and use a search engine crawler to aid in location of key words. By standardizing using templates on the expected format, the result was an easy to find, globally available, easy to navigate tool that encouraged project engineers toward an agreed-upon level of detail in their theory of operation documents. Over time we also migrated to this same site for most running project information include current status. This was a case where we had enough knowledge and experience to know what we needed, and standardization helped us become faster and more effective.
A similar example of the value of standardization was the experience I had with tools for Printed Circuit Board (PCB) Design. We had enough practice with the use of various types of PCB tools to know that our needs broke down into three areas, demanding three tools:
- A larger and more all-encompassing tool for our centralized PCB group,
- A specialized and moderately sized tool better equipped to handle certain technology layouts, and
- A smaller tool for our rapid circuit prototyping (RCP) that could easily be used by the engineers while they were still experimenting with their designs.
When we standardized on these three tools, it represented a significant reduction from the number of tools we had used previously. The change was possible since we had studied the problem, and knew that innovation around the use of a PCB tool would no longer be core to our adding differentiation and value to the company. Standardizing allowed us to design PCBs faster, since there were more people trained on a few number of tools. (It also reduced licensing costs.)
By contrast, here is another example where standardization was purposely delayed. As we were growing rapidly and adding project managers, I chose to allow these managers to use whatever tools and processes they wished to manage their projects as long as they achieved the required results. This flexibility meant that some PMs would drive projects from a Gantt chart, others would focus on Earned Value Management (EVM), some would make daily management and visual boards the center of their management methods, and still others would use critical chain and buffer management to get their results. Most PMs used a mix of these methods, but as the organization grew larger, grew faster and delivered more products into the same manufacturing organization, it became necessary to standardize on best practices. This change in policy was mainly due to the need to the need for speed and greater effectiveness. These project managers interfaced with the same people in other functional areas including manufacturing and marketing, and those partners needed to have all project managers speak the same language to them. We had experimented long enough with various project management tools and processes that we could see what worked best in our environment, so it was a good time to standardize. We had innovated enough, knew that our value added to the company would no longer be innovating around project management, and knew that our goal of fast and effective projects could be better reached by standardization.
Standardization on Designs brings up many of the same points as standardization on Processes and Tools, but also a few unique areas worth discussing. Like the case of Processes and Tools, it is critical that you choose carefully what, when and where you standardize. Essentially the same limitation as described above should be remembered: You should only standardize those designs from which you no longer expect nor desire further innovation that will deliver differentiation and value for the company. Once you standardize, the opportunity for further innovation is lost. With this caveat, standardization on certain designs can help a product development organization achieve significantly higher speed.
Standardization in designs can come in two forms:
- Backward-looking design leveraging
- Forward-looking platform design
Backward-looking (or sometimes called “pull-forward”) leverage is looking back at the designs used for technology blocks in the past and choosing to employ some of them for the new product. An example is leveraging the power supply from the most successful product released in the last 10 years. Backward-looking leverage has some great advantages in speed and other lifetime issues. It is more commonly used in the electronics industry (as compared with forward-looking platform design), but has less overall positive impact on the company. When this philosophy of backward-looking design leveraging has been employed for a number of years, the result is a set of products in manufacturing that are a patchwork of many designs, as illustrated in Figure 6-1. No real gains have been made toward maximization of part commonality, speed in fixing issues in released products, or efficiencies in improving reliability and yield. In addition, the improvement in product development speed is only marginal in comparison to forward-looking platform design. The power of a platform-oriented development strategy has yet to be seen.
Figure 6-1: Schematic representing Backward-looking or pull-forward design leveraging
Forward-looking platform management is looking forward in time with the knowledge of product and technology roadmaps, and building a platform from which to spin off many new products. This method takes more planning, some good guesswork, significant discipline and some compromises on some products in order to fit into the platform; but the results in speed, project cost, maintenance of released products and often even product cost can be significant, as shown in Figure 6-2.
Figure 6-2: Schematic representing Forward-looking platform management
Perhaps the minimum number of platforms for your product area is two: a performance platform and a low-cost platform. Creating these platforms will allow your overall product development speed to significantly outstrip either “no leverage”, or backward-looking leveraging.
A warning is necessary. If you try to create the end-all, be-all platform, the chances are very good that the project will be crushed under its own weight. I have seen this happen to several pure software platforms, as well as several hardware/firmware platforms. Many teams have created great ideas, but ultimately the project turned out to be an attempt to boil the proverbial ocean, and the project is cancelled with little to show for the significant effort. Make sure your goals are not too lofty, especially as you embark on your first few forward-looking platform management efforts.
A good forward-looking platform management process is essential if you wish to increase your product development speed to world class, but keep your initial goals fairly moderate.
In this blog I have described the value and pitfalls of standardization of two areas (Processes and Tools, and Designs) in your product development organization. Standardization carries with both promise and trade-off. It can increase speed in product development. But it will also, by its very nature, limit innovation. For this reason you need to be very careful what, where and when you standardize or you could choke your innovation engine.
In my next blog, “Tenet #7: Decentralize the decision-making”, I will make the point that decentralizing the decision-making will produce a faster organization.