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?

Taming the Feature Creep WIldfire

Any IC design project will have many changes come to the table during the term from spec closure to tapeout. How those changes are handled is what separates a project that flows smoothly from one that is riddled with unexplained diversions, surprises and delays. Teams that do not drive their business towards a formal process that includes assessment and approval of feature changes will be left to defend unexplained delays on projects with limited evidence as to why things are behind. Either design makes "feature creep" a visible process that leaves a decision paper trail behind or the design team becomes identified as a team that displays poor design execution. It's that simple.

Read more about Taming the Feature Creep Wildfire

If that article was of interest you can sign-up for our monthly newsletter here to get similar articles related to driving excellence in IC design Team execution. See our Past Newsletters.