Roadmap to Superior Design Execution

Design Process Improvement Overview
Both the Business Process Improvement and the Business Process Reengineering tend to focus on the business and it's interfaces into the other sub-processes, rarely getting into much detail on the design team processes and their interfaces. For significant improvements to be identified and realized within design, a focused effort must be completed specifically for product design that includes the interfaces into and out of product design.

There are two phases to design process improvements. The first is the assessment phase to learn, discover, understand and align the team to the current process. The second phase activities are to identify required process changes to meet the end objectives, as defined during the assessment phase. Depending on the magnitude of objectives the process is either targeting incremental improvements or a full reengineering effort, which clears the slate and starts from scratch. The diagram below represents the flow for both phases of design process renewal. Design Process Improvement (DPI) provides incremental improvements while Design Process Reengineering (DPR) is a major overhaul of how the design team operates.

To read full article follow this link.

Finding what we Don't Know

I came across the following phrase years ago and it always stuck with me as being the core concept in an organization that is focused on continuous improvement. "Those that know, know they know. Those that don't know, don't know they don't know." In essence, if we are not looking then we are assuming that we already understand where the challenges are in our product design process. If we are not on a vigilant and unending quest to find what we don't know, then we are headed for stagnation in improvements to our project execution.

For your reference here's a link to a service that is the beginning of finding what is unknown.

Is your Design Process as Good as it Gets?

In many organizations a team is aware of some problems in execution, however they are not deemed a significant disruption and there is a sense that the issues are at an acceptable level. When this is the attitude of the team I would not expect much in the way of improvements. The team has essentially stagnated in their productivity and has become comfortable with the status quo. Reasons for accepting current status range from not having time to elicit change to not having the motivation to improve.

I am aware of one highly successful semiconductor company that makes project kickoff a point of process renewal for each and every project. The team gets trained together, renews their process and best practices together, maps out their plans together and only then do they start the project. This is an excellent exhibit of continuous improvement in action. That organization knows that they do not know what they need to know and believes there is always improvements to be found. It's the culture.

There are three possibilities for your organizations position on the continuous improvement spectrum. Either you are OK with your project execution flow as it is today, you would like to see improvements in specific areas or you believe there are improvements to be found that include known issues and as well as challenge areas you may not be aware of. Where you fall on that continuum will directly impact the emphasis placed on improving.

A belief that it's as good as it gets or that you know everything you need to know about your process breeds a plateau in productivity and very limited improvements should be expected. Try shaking things up and continuously look for what you don't know and you can expect an environment of constant, incremental improvements. Excellence will be the product of an unremitting focus on improvement. Are you wishing for improvements or planning and taking action for improvements?

Parallels and Dichotomies of IC design and Software Development

I have noted on many occasions that the development of a software project has many parallels to the efforts of an IC design project. Both have modularized activities that must be broken down from a big picture view, the system level and architectural work if you will. Smaller tasks must be defined and architected to match up with the high level requirements. If the lower level tasks come in and do not meet the high level interface requirements rework is necessary. Collaboration is an essential ingredient in both environments.

What I do find interesting with IC design teams is that there is far less adoption of formalized program management (PM) methods than I see in the software/IT product development world. In the IC design world there is more reliance on the technical design tools as the main ingredient of a projects success in lieu of a form of PM methodology. This seems to be taking place while the semiconductor business units are making reasonable investments in formalizing PM. Does anyone else see a similar dichotomy between these two product development philosophies? Any comments as to why this me be an accepted practice in IC Design?