Six Issues that will Inhibit Profitable Growth in 2010 - Be Ready

Welcome to 2010! The last year was one of survival, where many businesses failed or were on the brink of failure. All attention was focused on making ends meet, where cost reduction was the primary objective. The news of a 2010 recovery for the semiconductor industry has been increasingly positive and the focus will be turning from survival to "profitable" growth. What's on your agenda for contributing to the efficiencies necessary for this goal? To stir your thoughts for 2010 objectives this blog post will share my observations of the high-level execution barriers semiconductor new product development teams are facing.

Over the years I have learned a great deal about the challenges that many organizations face in new product development. Interestingly, there are far more similarities than there are differences within the numerous companies I am in routine contact with. Below you will find a synopsis of the six most common execution barriers I see in product development organizations as of the end of 2009. As you read, honestly look for similarities to your organization and decide what you will be doing about them in 2010, the year of "profitable" growth. Some organizations are aware of these systemic issues and are taking action, some are just painfully aware with limited action towards a solution and others are blissfully unaware; where is yours?

Focusing on Cost more than Revenue Generation
Every decision about making improvements to project execution comes down to incremental cost, seldom about increased revenue potential. Issues that are constantly disrupting projects are rarely put in terms of prospective income that is left on the table; a figure that I assure you will command attention. Building a pure incremental cost case to make a decision leaves out one of the greatest motivators there is, the cost of doing nothing. Consider not the cost of fixing something, but the cost of not fixing something. A revenue based case (investment) will always provide the best decision and measurement base for any proposed change. If an improvement can't be aligned to revenue generation, then it truly has no value.

Who Owns the NPD Process?
Organizations of today are extremely compartmentalized by functional area, creating artificial boundaries of responsibility and ownership. Problems with product development execution are often solved in a localized manner, limiting true cross functional solutions for the full New Product Development (NPD) cycle from concept to revenue. The net result is that improvements may have limited positive impact on revenue, even though they appear as significant improvements from a lower level view. Where does ownership of the entire NPD process reside? If your answer is project managers, that may not be a valid assumption. I have seen many cases where project managers have boundaries of reach into functional areas and across the full development process. Is the owner of your total development process implied or explicitly identified? Make sure the keeper of your NPD process is crisp about ownership, responsibility, objectives and empowerment. This individual must remain vigilant at identifying roadblocks and providing solutions for the overall process, from concept to revenue. "Not my problem" is a phrase the properly armed process owner will never be heard saying!

Limited Organizational Learning
Organizational learning is defined as the open minded ability to explore and adapt to new and fresh approaches to project execution. Learning also includes the capacity to improve the current project work flows by uncovering barriers, discovering root cause and developing solutions to remove execution roadblocks as a continuing source of disruption. Many organizations simply do not have the time, motivation or expertise to develop into a learning organization. A learning deficiency firmly promotes the status quo, further expanding the incestuous pool of same thinkers that stymie organizational growth. Learn to learn and prosper, or fail to learn and "try" to catch up later. Proactive or reactive; it really is a choice.

Overdependence on Tools and Methods as the Solution
There is a preponderance of emphasis on tools and methodologies to fix everything that ails NPD execution. Although tools and methodologies are a significant enabler of success, they become a band-aid for underlying people interaction issues. Tools are no substitute for promoting member participation in solving the issues that personally impact them, an area often glossed over and ignored as tool solutions take center stage. Learn to learn from those that are in the trenches working on new products, listen to what they have to say. Most execution issues are people issues - lack of clarity, lack of expectations, lack of communication and a lack of involvement. It's a people thing!

Acceptance of Schedule Failures
Schedule Failure defined: Not meeting revenue projections (timeline or amount). I am very firm on this definition and no other description is valid. Anything less and your organization will lose the proper focus! The pressure to meet schedules is intense, yet most projects slip and the common belief is that the project must not have been properly planned, or the team did not live up to their "commitment". That's typically the end of the story. The truth is that the reasons for a schedule failure are rarely analyzed, although there would be a wealth of information to be gained in doing so. Reality - schedule failures are both expected and accepted, though no one would dare speak that truth in public. Tolerance will always breed inaction; either a schedule is gold or it is coal - what's it to be?

Living in the Problem, not the Solution
Many organizations will talk about known problems for months or years, never taking the next step towards a solution. This extended period of time wallowing in the problem usually comes down to a lack of ownership, an unrealistic focus on cost, or a belief that the origin of the problem is elsewhere, further strengthening inaction. To put it in simple terms - If the problem is affecting you, it's your problem and what are you going to do about getting it solved? Why isn't now the perfect time to move from an incessant discussion about the problem to getting it solved? Fear of change allows the problem to prosper. Understand the sources of the fear, face them head on and put them behind you. Step up to the plate and hit the problem out of the ballpark!

There you have it, my observations of the most common afflictions I see in product development organizations. 2009 saw many businesses either failing or on the brink of failure, small local businesses as well as large corporations. What brought them there? If you believe it was the downturn, you are likely one who lives in the problem. If you believe they contributed to their own demise, then you may be one who strives for solutions. In 2010 "profitable" growth will definitely mean things will need to be different than 2009. What are your plans?

Mixed Signal Success Requires the Voice of Analog Designers

When seeking information about EDA or design execution there is an abundance of substance generated from the digital community. Digital designers and EDA types freely generate articles, papers, blogs and tweets on subjects that impact design execution. However, when the subject is analog design execution we tend to hear predominately from EDA. Hey analog designers, what do you need to be successful on your projects?

Maybe the analog community would be content submitting punch card decks for simulation runs and working with Mylar for layouts? I seriously doubt that. So what’s the deal with the voice of those that thrive in the world between a 1 and a 0? We must hear from them and involve them if we are ever to achieve a mixed signal verification strategy that even comes close to the results of a pure digital verification.

Analog content in the digital world is increasing. The barriers between the two camps must come down. There are digital tools and analog tools. There are analog designers and digital designers. We constantly focus on the differences between the two worlds, strengthening the grasp of the problem. If the spotlight remains on the dissimilarities how can we expect to converge on a solution to the ongoing, long standing barrier to mixed signal first silicon success?

Digital engineers believe 1st pass success is possible, even probable. Analog engineers believe 1st pass success is possible, although not probable. What’s missing in the analog design process that yields a belief in requiring silicon results to finalize a design? If I sit down and ask an analog engineer he will give me his or her gut feel reasons. Where is that industry wide specific list of reasons that outline why the existing tools will not provide the correct answers for analog and what are we doing about it?

If we are ever to solve the puzzle of mixed signal design and verification we had better be talking to the in the trenches analog designers and validating the reasons they believe 1st time success evades them. Waving a flag and banging a shoe on the table to say what’s wrong with the analog flow is not the nature of analog types. They definitely have something to say, we just need a different approach to learn from them. Analog designers – it wouldn’t hurt to take a course or two in advanced shoe banging to help get your message across about the holes in your design world.

Below are a few simple concepts to align our industry with a mixed signal success solution.

• Analog & Mixed signal EDA vendors and support types – be sure you spend more time talking to analog designers than each other; they are the customers.
• Digital designers – recognize that behavior differences will always exist between you and your non-binary counterparts and put that reality behind you. Digital is black and white; analog is gray.
• Analog Designers – take off your shoe and start banging it on the table to be heard; say what you need. You must learn to improve collaboration, thus enabling flawless integration with your binary partners. Recognize that a smooth integration with digital is more than a purely technical task; it requires documentation, relationships and teamwork.

We must fully engage the analog design community in the solution of first time success for mixed signal design. It’s time for a change from a problem centric approach to a solution-based emphasis, from why we can’t to why can’t we. This is attainable only by dissolving the barriers between the two design worlds; it’s a people thing.

Solution Strategies for Solving Systemic Issues

I have a long held belief that any solution is only as good as the buy-in of the team. A weakly supported outcome is really not a resolution at all. For successful fixes, that hold the test of time, it is essential that the team affected be part of the process. I suggest also including those who will be least desirable to involve, as they will bring a healthy balance to the problem along with some valuable debate.

Migrating from problem to solution - when considering solving a pesky and well known project execution obstacle, what avenues for resolution should be considered? Below you will find my most successful approaches.

Brainstorming
This is an old tried and true method that is a good way to get options on the table. It works well, assuming a facilitator well versed in the brainstorming process. Don't get bogged down with tools for this, good old sticky notes (large) work great to capture and organize concepts.

Interviews
This one is not used very often, although it frequently provides some fascinating insight into the issue and possible solutions. The facilitator must be prepared with well thought out questions that target uncovering root cause and ideas for fixes. The environment for the one on one discussion must be one that ensures any barriers to open discussion are minimized.

Outside Assistance
Consider having someone knowledgeable from outside the organization participate in the resolution process to bring a fresh perspective. Often, being too close to the problem stymies the big picture view that can bring unforeseen solutions to the table.

My short rule for successful solutions to nagging issues: Inclusion over exclusion of people, broad functional area participation and an open atmosphere that focuses on the solutions, not bemoaning the problem.

Enabling the Decision to Invest in a Solution

I will bet there is something bugging you about how project execution is going in your group; in fact it's probably been an issue for quite a while now. A solution has not been implemented, although you would welcome the day the problem was gone. There's been plenty of candid discussion about this issue - in meetings, over lunch, at happy hour and quick hallway chats.

At what point does an organization decide that the time is right to solve a systemic issue with new product execution? This will only occur at the point where the perception of the benefit in making a change is considerably greater than keeping things as they are. Perception of cost vs. benefit is the vital decision factor required to tip the scale in favor of investing in a solution. This is true for any product development barrier - tools, flows, organizational structure, processes or procedures.

Building momentum towards a decision to take substantial action against an ongoing barrier is as simple as turning the problem into one of financial impact. If the cost of ignoring a known product development obstacle is presented in terms of lost revenue opportunity, a stronger case for action will result. Link the need for eliminating a known execution difficulty to the impact on money (sooner or more) and gain the support required for a decision to invest in a solution.

A justification built around touchy feely advantages such as efficiency or productivity is weak, and reaching a decision to proceed will be like pushing a rope. The reality is that problems in need of solutions can drag on for years without a well-constructed financial benefit rationale. If there is an obstacle that has been a long-term issue, consider that the case for fixing it may not have been presented with the proper business impact.

How long can problem discussions continue before a decision to take action towards a solution becomes obvious? Without financial impact as motivation, it could be forever. If a monetary case isn't built in support of action for resolving a new product delivery concern, then the perception that it's not a bona fide business problem will continue. The solution, no matter how sound, will likely remain buried for a long time.