Breaking Down Barriers to Enable Positive Change

The majority of teams that I talk to have something that they wish would be different, something that has been a problem for a while and is limiting productivity or predictability in some fashion. What I find interesting is the length of time project thorns such as this continue. The difficulty gets plenty of dialogue around the lunch table, or at the local watering hole, however an actionable plan to do something about it is frequently put on the back burner. The reasons sited are typically one or more of money, time, "it will never get better" or "not my problem".

These long term project thorns are similar to an old pair of our favorite shoes. They may be ugly in ways, have obvious defects to most people and everyone is telling us we need to get new ones. We are blind to these facts because they are so comfortable and we know how to walk just fine with them. However, in reality they are probably causing us some physical problems that we may not even be aware of, since the negative change with time is so subtle. Why are we reluctant to buy new shoes? We are comfortable with the ones we have and new shoes will hurt for a while until we work into them. In reality we are afraid of how peculiar the new shoes will feel vs. the familiar old ones and how long it will take for us to adjust to them.

For our projects the major reason we tend to hold back on changing something is also fear centered more often than not. Ouch - am I really afraid to change something? The odds are high that fear is a major non-starter for implementing changes to improve a less than perfect work flow situation. Fear is the result of the unknowns that exist on the path to a change. If we diddle with something to make it better, will I be OK with any impact on my work situation? The common reasons for this fear are outlined below:

• Things may end up worse after the change.
• I already feel overwhelmed; will defining and making this change increase my load?
• Skeptical - will my concerns/ideas be heard and addressed?
• I may be impacted by a change in an unfavorable fashion.
• Change of Habit - Things may not be perfect now, but I know what I am going to do every day when I go to work. How will this change my day?
• I am not responsible for the issue we have. Will I somehow end up more responsible for the problem?

Ignore the reality of fears such as those identified above and plans for change will either never leave the starting gate or drag on and on without any attainable value, leaving you to potentially deal with "see, I told you that would never work" type of criticism. Acknowledgment and handling of the prospective fears will enable a smooth course to the development and roll out of a change.

So how do you handle the diffusion of the fears? The simplest means to a minimally fear filled, maximally beneficial change practice is "Broad Involvement". Each individual's potential solution vector will have different magnitudes and phases for a specific problem. They all need to be as aligned as possible to maximize the effective magnitude and the only way to do that is to engage them, really engage them. Any problem to be addressed and the resulting change will have far reaching impact; therefore a strategy of far-reaching inclusion rather than exclusion of individuals will alleviate fears and tip the scales towards success. Consider that the problem you want to resolve is rarely contained within a given organizational silo, although it may appear as though that is the case due to a narrow view of the project execution landscape.

Why Can't we get Rid of that Thorn in our Process?

When there is a systemic process problem plaguing a development organization it continues to baffle me how long the pain is allowed go on. At times to the point where here is a belief that it is hopeless and will probably stay with the organization until the end of time, even though it really is causing obvious disruption in projects. In most cases the path towards a solution is not something that is a huge mountain to climb, it just takes some specific action and collaboration to gain consensus and be done with it. I believe that it's just that we are creatures of habit and diddling with anything stirs up the "who moved my cheese" type emotions, making us uncomfortable. If we leave things alone our days are assumed to be fairly predictable, thorns and all.

I am going to spend some more time on this fascinating subject next month.

Any thoughts on this?

The Role of the Three Silicon Testing Categories

Proper validation of silicon in support of a production worthy product involves three major categories of testing requirements. These test types include manufacturing, characterization and functional validation. See the table to the lower right for an overview of these test types. Below I will expand upon the requirements of each one of these three essential testing philosophies.

Functional Validation
This type of testing us usually done on a low volume engineering type setup and concentrates on verifying that the silicon meets the original requirements, both electrical as well as functional. There may be specific silicon test modes necessary for functional validation but usually the characterization and manufacturing needs will cover the validation activities as well. The design engineer needs to be highly involved in defining the functional validation requirements, the test fixture definition and the actual validation activities. Remove any barriers (or excuses) that would keep the design engineer(s) away from the bench during the silicon validation activities. Their required participation will provide a minimized path to production and enable the designer's essential "real world" silicon learning cycle.

Manufacturing
Once a product is ready for manufacturing the test focus moves from functional verification to the identification of manufacturing defects. Once functionality has been verified via functional validation testing, a defect is the only means that functionality would be altered, hence defects become the primary objective of production testing for manufacturing. Test costs and test coverage to maximize defect exposure along with parametric validation are the principal motivators in decisions about manufacturing test. In digital land this is what motivates an emphasis on scan, which has some very specific silicon requirements to support this mode. In analog land the primary requirement will be visibility and stimulus of internal analog sub-systems, usually accomplished via test modes to mux key internal signals to external pins.

Characterization
This type of testing involves the ability to margin the design by varying FAB processes, supplies, frequencies and signal levels. For analog, this often requires visibility to internal signals, supplies, references and so on. For digital, the silicon support is often the same as the production test requirement of having a scan capability to inject and view the internal data. The process variance is typically accomplished via process corner splits within a given lot. There may also be some specific requirements necessary in support of ESD and/or latch-up testing that should also be considered.

Again, all three of these testing families are essential for a product prior to release to production. Do these well by facilitating an early plan to define the silicon content necessary for all three, thus removing another layer of potential surprises in your product release plans.

What Motivates us to Look at Things Differently?

I posted a question on LinkedIN the other day on the topic of how we motivate ourselves to look at things differently. The exact question was “What motivates you to look at things differently, to be open that there may be possible alternative approaches?” and the link to the question and answers is at http://www.linkedin.com/answers/management/business-analytics/MGM_ANA/312524-3632843. The responses to date have been quite interesting.

The reality is we all want things to be different; we just don’t want any changes to impact us. How many times have you heard someone going on and on about something and never really taking any specific action to make a difference? Verbalizing a problem over and over has never made it go away. The only thing that will make a difference is stepping back and being really motivated to look at the current situation, understand why it is the way it is and then mapping out some real solution alternatives.

The trouble is, in many cases that motivation to do something about it never materializes and the situation stays as it is. Now back to my question that started all of this. What gets us to the point where the pain of staying the same is greater then the pain of making a change, forcing some real action? Why do organizations go on and on living with known process issues without doing something about it? Stated reasons are usually one of money, time or people, although I believe that’s a smoke screen and the real issue comes down to a fear of change. What do you think?

Testing - From Product Concept to Production

When thinking about testing for a new product what first comes to mind? Is it manufacturing, quality or design validation? If you're a designer I believe you would be most interested in functional validation. Someone from the product management organization would probably consider quality or manufacturing first. Tests to cover this broad scope of validation needs carry similar levels of importance, yet have vastly different approaches.

Manufacturing test focuses on time, defects and electrical requirements; quality testing concentrates on characterizing design margin and reliability; design validation directs attention to functionality and parametric data - "does it meet the customers application?" All three testing categories play a considerable role in a high quality product, however they can place very different demands on the silicon content necessary to fully support them.

When defining a new product are you including all three of the test category types as you develop engineering specifications? If not, then your product is left open to higher product costs, or quality and yield issues once you get into production. I find it best that all silicon expectations for testing reside in the engineering specification, further reinforcing the thought process about silicon requirements in support of testing. This also emphasizes test strategies early in the development process, when something can still be done about it.

Make sure you have a process in place for creating a comprehensive test plan that includes all three testing categories. Complete that strategy for testing during the product definition phase and include any silicon content expectations in support of production testing, validation and characterization. Bear in mind that the test strategy is a multi-disciplined effort. Design knows what needs to be validated and characterized while test and product engineering knows the hardware and software capabilities of the testing environment and will bring the required focus on production test costs to the plan. The output of the test strategy should directly drive the silicon requirements to support those tests. Please see the diagram above for a proposed NPD requirements flow that meets the objective of early test definition to drive the silicon expectations in support of those tests.

The days of testing as an afterthought should be long gone in the development organizations of today. Involve test early, involve test in product definition (test modes) and listen to the test and product engineer's inputs on testability concerns. In today's environment there will be no acceptance of a wasted silicon spin to support testing after the fact, nor will there be any tolerance of quality issues due to silicon characterization or validation limitations. Think through testing up front to prevent an inadequacy in silicon validation capabilities from becoming a surprise, just as you are eagerly anticipating a production ramp.