Why or Why Not?

If you were to hear a proposal for a different path or direction in approaching a project would your initial response be more of a “why” or a “why not”? One response is indicative of an attitude towards continuous improvement while the other signals a belief that things are OK. If we find ourselves routinely asking “why” to change we are sending a message to our team that things are OK, or at least good enough, thereby minimizing valuable opportunities for improvements. A continuous improvement culture is an essential ingredient of continued, long-term success and is the subject for this posting.

Why would we decide to try something different? The path to different is peppered with unknowns, is an uncomfortable journey and has an outcome that is difficult to predict. Staying the same is fairly comfortable and is reasonably easy to predict, at least for now. So again, "why" would we want to change anything? Only if we reach the conclusion that staying the same is going to somehow negatively impact our future. I would think the possibility of losing something important (jobs, revenue, customers, market share etc.) is a great motivator for change, forcing our line of thinking more towards "why not" when considering alternative tactics for managing NPD projects.

How has the semiconductor industries approach to new product development changed over the last 15 years? I would surely think there has been plenty of motivation to improve during this period with all the outsourcing, off shoring and head count reductions that have occurred. Although I am not sure the industry has hit the pain threshold yet. Other than new tools/flows, I do not see the majority of design organizations making any significant changes in the way they have approached design projects. Multiple spins and schedule slips are still accepted as the norm, with reasons usually attributed to tools. "It's just the way it is" thinking lives strong. Through this quiet acceptance there is a continuous message that we we must improve. Interestingly, specific actions for perking up execution tend to be largely downplayed, or given some superficial hand waving attention because we don't have time for such indirect activities. We are caught up in the "why" of change.

Let's step back for a moment and take a look at the US auto industry. Was it tooling capabilities that have eroded their market share year after year or was it the culture? No question the answer is culture. Take a look at Toyota's approach to both development and production. There is a lot to learn from them, if and when we are ready to do so. The employees on the floor are encouraged to continually be challenging the way things are done through real experimentation. The execution focus is always on ideal, a goal that is never reached, although continuously strived for. No one will dispute the fact that their approach has brought them great success. A culture that embraces "why not try something different" has driven Toyota to become a standard for execution excellence. Consider the Prius. A few years back I am sure there was plenty of "why" type thinking going on at manufacturers considering a hybrid type concept, and today those same manufacturers are all playing catch up to Toyota.

Now back to the semiconductor business. Based on my research the majority of design organizations believe they are executing on projects OK, or at least good enough. In fact, the bulk of teams do not regard a concentrated effort on continuous improvement strategies as a practical use of their limited resources. In our industry "why" is a common response to any activity related to changing the approach to projects. For Toyota I would expect the typical response to a question about trying something different to be "why not". How much will we need to lose before we get rattled enough to convert our mind set to one of "why not" when considering changes to the way we execute our NPD projects?

Improving or Reengineering your NPD Process

Once you have decided that your NPD execution will benefit from a focused effort to modify or reengineer your process, there is rewarding work to be done. I have several ideas to get you started. Engaging in a process renewal effort must be broad in scope and include participation of the entire development team. Engaging upon a NPD process renewal with a limited scope of discipline participation is guaranteed to provide limited success. Don't seek justification to limit participation, seek a means to expand it.

Thoughts on Managing Change
The most important concept to address when engaging change (new processes) is that the team will be skeptical of this activity simply because it will be different. Change will always create anxiety among the team member's, an uneasiness that must not be written off or it will definitely impair your plans. The most common reasons your team will be uneasy about change are as follows:

• They may lose a capability that is important to them.
• They do not understand why this process change is necessary.
• They disagree with the risk/benefit of a process change.
• They fear not having the relevant skills necessary to work in the new process environment.

These concerns must be mitigated to produce and enable a successfully deployed process change. Address these items well and your team is certain to be energized about the possibilities to improve his or her productivity.

Start with creating "As Is" NPD Process (What you are doing today)

Brown Paper Session - Hang a large sheet of paper on the wall and use post-it notes to define each step in the process. Involve a cross broad section of your NPD team in this process with the objective of mapping out the flow of a project from concept to production release using the post-it notes (tasks/activities) and arrows (flow). The completeness and understanding of the existing process will become evident during this exercise, a very enlightening experience.

Discovery - This activity is essential to uncover the roadblocks (unknowns) that may exist in the current NPD process. Individual team members know how roadblocks are impacting their productivity, although they may not be able to see that there is or could be a solution. Formal discovery is best handled as one on one discussion using questions specifically tailored to uncovering roadblocks and/or deliverable issues. Share the discovery learning's with your team. More on Discovery

Project Post Mortems - Use project post mortems as a forum to expand learning's about any deficiencies in your process.

Finish with "To Be" NPD Process (Your updated or reengineered process)


Brown paper session - Once you have gathered all your inputs about the existing process I would suggest once again visiting the brown paper process that was created during the development of your as is process. Again pull the key team members together and plan out what your new process needs to be. This is best concluded over a period of several days, making liberal use of timeouts for members to reflect. Once this process is completed capture your process in a tool such as Visio for final documentation.

Process Containers - The medium to be used for your new process is an extremely important step for your successful deployment. It must be something that is easily used by the team, all of the team. The worst thing you could do with your new NPD process is capture it in a form that is not highly accessible by the team, thus leaving your well developed process to gather dust instead of providing the intended benefit. Process containers that I have seen as fairly effective for this purpose include design guides, design travelers, PIEmatrix and possibly schedule templates, although that's a stretch due to limited accessibility.

We are doing Okay - Why Should we Rework our NPD Process?

Statements such as "We are doing okay, so why should we need to rework our NPD process?" are all too common across the semiconductor industry, yet many organizations are challenged in completing projects as planned. How can this be? In the majority of cases design teams will place the reasons for project execution difficulties on design tools with explanations such as they did not work right, had bugs causing delays, did not have the necessary capabilities or failed completely. From a designer's perspective, tools are commonly identified as the reason for project slips.

There is no question as to the tremendous value of design tools in the completion of a chip project; however, tagging all the project execution issues on them leaves significant improvement possibilities out of reach. A belief that project issues are principally tool related minimizes a localized problem focus, purely because they typically can't be fully resolved within an NPD organization. Hence things stay as they are, project after project due to a belief that the source of the problem is out of reach. An unsubstantiated assumption that all issues stem from tools breeds a belief that project execution is doing okay or "good enough", merely because tools are out of the NPD teams jurisdiction.

If you require real improvements, it's critical to look beyond the tools for answers. Below are the major execution issues I have seen from working with many design teams over the years:

1. No scope change control in place - Feature Creep runs free to silently steal away your team's productivity.
2. Unmanaged requirements closure - The process of deciding what to do drags on and on, eating away development time.
3. Deliverable disconnects between deliverer and receiver for a given task - team members are not getting what they need to be successful.
4. Plans that are based on imaginary resources/capabilities that did not materialize - fictional expectations created surprises in the midst of project execution.
5. Sense of urgency that falsely justifies corners to be cut and allows project launch without a proper roadmap (the plan) to successful production. No risk/benefit analysis completed to justify these decisions.

Tool problems are not even on this list! Why not? Because tool issues would be covered under plans that assume imaginary capabilities, item four of the list. Why would a project be approved if the tools could not produce the required results? There must be action around tools expectations and validation as part of the project planning practices and that's a really a process related issue, not a tool issue.

Now back to the original question: Are things really okay or are there some process related activities that will bring positive results? Heroic efforts to make tools work mid-stream in a project will never match the results that can be achieved through a well-developed process; one that is communicated, includes tool/flow expectations, is easily followed, is agreed upon and is believed in.