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.

Invest Time in Discovery to Realize Compressed Time to Revenue

Having been successful in making the tradeoff between what's important and what's urgent from my previous posting you now you have allocated time to invest in a better tomorrow. How will you be investing this reclaimed time? I am certain you have a list of items in mind that you have wanted to do for a while; a list comprised of the known issues that impact productivity.

There are changes we know that will bring improvement and then there are the deficiencies that are silently stealing away cycle time, the unknowns. If an improvement effort is to realize expected results, both the known and the unknown roadblocks must be addressed. For those that have been reading my newsletters for while, or have attended one of my workshops the concept of an unknown is not new to you, although the definition may still be a bit baffling.

The simplest definition for unknowns in the NPD process is that they are essential activities or deliverables that are largely unknown to the vast majority of the team. By definition they are unplanned and untraceable, even though they are essential to a products success. Essentially they are hidden and unmanaged roadblocks to your NPD flow that will manifest themselves as unexpected surprises, spawning a flurry of activities to "make things right". Interestingly, unknowns also tend to be systemic issues that are repeated project after project; therefore keen detective work is in order to bring them to the surface, where they can be managed.

Investing time on important activities that improve your NPD time to revenue must include time spent on finding the unknown roadblocks in your development process. A formal discovery activity is the best course of action and should be the beginning of any renewal or reengineering effort for your NPD process. The following three links will provide additional insight into the discovery of unknown and unmanaged activities:
Discovery & Solution Newsletter
Improving Project Predictability (Chip Design Magazine)
Enable Predictable Design Execution by Looking Beyond Tools and Flows (Embedded Intel Design Magazine)

Any NPD process re-engineering must begin with formal discovery. Failure to do so will leave your shiny new process with holes in it, leading to continued surprises on your projects and the flurry of activity to "make things right".

Getting a Handle on Urgent Matters that Run Wild

Here is an example of misplaced urgency I am sure we can all relate to. You are at the store waiting in line to pay and the phone rings. The clerk answers the phone, talks for a bit and then heads off to go find some information for the caller. Here we are, wallets in hand and waiting to improve the stores immediate revenue numbers and the urgency was transferred from taking our money to chasing a possible future opportunity. Was that urgency transfer proper? What was more important here? This is a great example assumed urgency.

How many times in a day are you redirected to something urgent, something that was not on the list when you awoke in the morning? I will place an educated guess that it is easily in the 1-5 range. As soon as an urgent matter comes up we will typically drop what we are doing and tend to it immediately, leaving what we wanted to do drifting off into the land of unimportant stuff. This is repeated each an every day.

At the end of the day we have this nice list of fires that were extinguished, tasks that we had no intention of dealing with when we popped out of bed. The tasks that were on our planned list, the things that mattered most, took a back seat yet again. Items that we were working on to make things better tomorrow, once again did not move forward today. We are drained, yet still lacking a sense of solid accomplishment for the day. Is this a reality for you?

None of us like to operate this way; we all want to do our best job and that means dealing with the unexpected urgent matters as expeditiously as possible. As managers, we take ownership of the urgent matters and drive them to closure. It's our job to make sure these things are dealt with. Let me pose a couple of questions:

• Is it our sole responsibility to own the urgent matter or would the organization better served by delegating the responsibility, empowering another individual to resolve the urgent matter, freeing you up to work on what matters?
• Is the urgent matter really more important than the task we were working on, the one that matters most to the organization and ourselves?
• Should someone else's sense of urgency directly translate to us without any thought as to it's validity?

The truth is we always have a choice to make when an urgent matter comes up. However, we are programmed to react to a sense of urgency by dropping everything and take care of the matter immediately, leaving ourselves with little time to do what's important to the organization; the plans for a better tomorrow that never seem to get completed. It is a choice between feeding a fire-fighting environment or nurturing an empowered environment of continuous improvement. Upon waking tomorrow resolve yourself to working on what's important, not just what's urgent and see how this impacts your effectiveness.