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.