Know What’s Holding Back New Product Productivity
Are your teams striving to be better while the end business results indicate little change? Even with activities providing every appearance of improvement actions, there is a troubling factor with results. The expected change may never materialize, or more often the measurement criterion fails miserably at assessing true business success. Open-ended requirements, misguided success guidelines and misplaced assumptions lay the groundwork for an expensive initiative that provides little or no actual improvement to the product release cycle. Keep in mind the natural stability point for any organization is to keep things as they are.
To be fair this is not necessarily an intentional act, it is the status quo powers at work that strive to keep things in balance, a point where things remain comfortably the same. If you don’t believe this is at work in your organization review some of the past less successful initiatives, paying particular attention to success measurement. They were not likely tied to a solid contribution to top line revenue generation or bottom line costs, providing little motivation to move out of the comfort zone. Noticeable results will require noticeable change.
A truly successful endeavor must have a measurable impact on money. Criteria that flaunt a win based on local success within an organization silo should be a warning sign that the net benefit for the business may be non-existent. Limited measurement scope such as this leaves an organization susceptible to terminal sameness, a disease that quietly stymies advancement in new product development efforts.
Make no mistake – Any person will subconsciously strive to maintain the workflow as it is. Sure, there will be plenty of participation and ideas for change going on where others are concerned, thus keeping the workflow focus elsewhere. Ask anyone how new product execution is going and see where the focal point of the discussion goes. Isn’t it ironic that people and organizational silos actually have been granted the ability to grade them selves on productivity? If positive changes in execution are expected, self-assessment of efficiency has no place in the equation, period. A self-evaluation approach is an incestuous path to guaranteeing terminal sameness!
So I have to ask, is new product execution productivity OK or does it need work? Lip service tells me that it needs work, while actions tell me that it is OK. Are you supporting terminal sameness or are you supporting continuous improvement? There are powers at work to ensure nothing significant changes and you hold the key to weakening its grasp on your organization. Stir the pot and drive greater improvement value by measuring against only money and eliminate internally generated productivity assessments; it is a leadership choice.
Why – The Most Important Question
In the world of new product development our days are loaded with decisions, mostly small and routine with a scattering of financially significant judgments that can make or break programs. Are significant decisions born out of sound judgment and great engineering, or are they largely defined by historic reasons? Questioning and challenging historic reasons for decisions is one of the most important aspects of a learning organization, one that consistently displays industry leadership.
We must never base the future solely on how things are done today. Ask why consistently and discover that the solid reasoning of the past is not necessarily valid today. The businesses that failed to weather the financial storm of the past few years became stale and complacent; they were mired in the ways of the past because they did not question the course they were on. What worked yesterday was not working today, and no one openly questioned the chosen direction, until it was too late.
When considering new products in the chip business there are many questions that must be routinely asked to ensure top-notch products and product execution are the norm. Give the following example questions some thought, real thought and then decide if you should challenge a historic assumption that may be stymieing progress.
The Important “why” Questions of New Product Development
- Is a smaller die size at the expense of time to market valid? Why?
- Is a finer pitch technology choice valid for minimizing total product cost and risk? Why?
- Are new product requirements being driven, or are they just happening? Why?
- Are ASP’s really value driven or is cost quietly driving them? Why?
- What percentage of new products are losers? Why?
- Are design environment customizations hindering or helping? Why?
- Is the tool flow for a given technology optimal? Why
- Is the cost vs. benefit analysis of offshore activities valid? Why?
- Is the magnitude of new product approvals damaging your new product success ratio? Why?
- Is product differentiation working? Why?
- Are projects under control? Why?
- Are new product teams accountable? Why?
Actions that are launched from answers to questions such as these will ensure the status quo does not take root and bear the fruit of complacency in your organization. Challenge assumptions by asking probing questions, never accept historic justifications as suitable answers and in no way allow a lack of facts to imply the routine course is correct. Why, the most important question new product organizations need to ask is the only protection against terminal sameness.
What historic assumption will you be questioning today?
Survey – How is Internal EDA Support Utilized
The link below is a survey to identify how your organization is utilizing internal EDA resources, what your expectations are of internal support along with your level of satisfaction. Once you complete the 5-10 minute survey you will be presented with a link to monitor results. Final results will be published here on this blog. Many thanks to those who choose to participate.
Is the EDA Support Model Working?
When thinking of EDA, there are generally two areas that come to mind. The first is the design tool suppliers and the second is the internal support for customization. I also view a third being the end user, the design community itself. Tools are purchased from the supplier, customized and supported by internal EDA support and then are made available to the design community.
This is a traditional approach to EDA and one that is utilized broadly across most companies in the semiconductor industry. It’s historic, bureaucratic and I believe it’s lacking the productivity benefits the industry needs. Why? Simply because the design community does not have a full voting rights seat at the EDA table. This is partly of the designer’s own doing and in part because of organizational structure. How many designers attend the coveted Design Automation Conference?
The EDA support model is rather incestuous, isn’t it? Maybe we need more designer genes mixed into to the pool to provide proper balance and direction. I am curious what the design community has to say on the subject.
Here’s a question for all those designers out there – how’s the EDA support model working from your perspective? EDA types, please be very quiet whilst we here from the design community. They don’t speak very load, especially the analog designers, so we need to keep the volume low so we can here from them.
Designers – stand up and be heard by leaving a comment on your view of the situation. We are quietly waiting to hear from you.
Flow Customization is not Winning the Time to Revenue Battle
What’s the first thing that happens when a new tool becomes available, or even a new major revision is in the works? The discussion about how to “integrate” it into the way we do things commences – customization begins. Is there really only one right way for a tool flow and everyone else chooses the wrong way? I need a really good reason why we are unable to expect a tool to be ready for use out of the box? Why must everyone monkey with tool customizations to make it more right? What we need is freedom from customization!
Think about how much time is spent and wasted on chasing the ultimate, best in class super duper Pcell? There are two things that matter in chip development: 1) Designers must not be battling with tools and 2) The tools need to provide an answer that is good enough to prevent a silicon spin. It’s really pretty simple. If you can build a case for positive time to revenue impact based on diddling with design environment customizations, I would like to hear it. I maintain that tool flow customization negatively impacts time to revenue.
What tends to happen is all this customizing that goes on chasing the ultimate environment creates a maintenance nightmare. The need to make it better has created a headache for both the users and those doing the customization. The biggest complaint I hear from designers is that the tool flow often breaks unexpectedly. If they worked yesterday, why don’t they work today? Something changed, and that change was most likely precipitated by a need to be better somewhere along the flow.
Here’s what we should be able to do. Buy a copy of someone’s design tools, get the PDK from our FAB of choice, design without a hitch, tapeout and get silicon back that behaves the same as we verified in the tools, period; end of story. If that’s not happening there are only two things that could be broken, the tools you bought or the PDK. Get them fixed at the source! If you buy a new car do you hire a team of mechanics to make it better, more like the ultimate car you envision? So why do development teams believe the expensive investment they made in tools needs improvement?
The reality is that there are a huge number of right ways to approach design, not just one. Improved time to Revenue will result from consistency in approach, essentially alignment to a single approach/choice for all steps in the flow. Everyone has an opinion and firmly believes in their right choice and will fight for their cause, disrupting the much-needed consistency. We allow it, we condone it and we whine about it. The truth is tool flow customization is wreaking havoc with new product development efforts. Freedom from choice will positively impact time to revenue!
What’s Analog Rails all About?
Last week I had the opportunity to visit with Get2spec CEO Cliff Wiener and we discussed the upcoming release of their Analog Rails product, advertised to leapfrog past the Cadence Virtuoso suite. Cliff is definitely passionate about the needs of the designer; an area he maintains has not been serviced well by the current EDA suppliers. The following is a summary of the discussion I had with Cliff following a demonstration of the Analog Rails suite.
What is your background in the semiconductor industry?
I have spent 28 years in the business to date. The first 10 years was doing analog design with pen and paper followed by 5 years learning and designing with CAD tools. From there I moved into driving analog and RF design methodologies for 7 years at National Semiconductor, and Motorola Semiconductor prior to starting Get2spec / Analog Rails over 6 years ago.
What motivated you to develop the Analog Rails suite of tools?
There were really two reasons: 1) Frustration with CAD vendors, and 2) I knew how to automate analog. Let me expand. The leading vendor relied on enormous CAD teams, and the tool was overly complex and very generic. There was no built-in intelligence to the tool. I decided to make an analog expert system where no brainers are automatically put into the tool, and all the tools work together through the entire flow. An example of tool intelligence is a simulator that provides information to the placer and the router. Properly using this information, coupled with adhering to analog and RF design methodologies, allows automation to occur.
What sets the Analog Rails suite apart from the others?
The other EDA companies in analog are focused on verification and we are focused on creation. We believe in a correct by construction approach. We automate, they iterate. This is especially important at smaller feature sizes, where the STI effects are more severe. The circuit designer needs the parasitic information right away. We also believe that time to market is everything! Very few new topologies are being created in analog nowadays. The key differentiator today is who can produce the chip according to specification first – first in wins.
Do you have a proudest moment in the development effort that you could share?
Automating switched cap ADC’s (Cyclic, Pipeline, etc). The analog switches are a pain in the butt, but we have the technique down pat. I heard that analog automation is impossible, so doing the impossible is something to be proud of.
Ask me when we release our “design while you sleep” mode. It will optimize, place, route, RC extract and then re-optimize. It’s like the lady from easy-off stating that she is cleaning her oven…while she sleeps. We have the equivalent…for geeks.
What is the expected availability?
April 12th, 2010. We are actively demonstrating the product today.
Explore a Focus Group Approach for Difficulties with Requirements
If new product requirements are a challenge for your team, and they are for many, it may time to consider a focus group or workshop type approach. Most of the problems I see with requirements are related to a lack in focus across the multiple levels of requirements needed for a new product. During this process there tends to be a lot of waiting going on, either for another level to be completed or a decision to be made.
A focus group approach brings all those concerned into a planned and well-facilitated set of requirements sessions. The sole purpose of the group is reaching consensus on a suite of requirements for a new product. You’re thinking that this sounds like a lot of work, aren’t you? In reality it’s not much more work for the team itself; actually it could be less due to improved preparation and focus. Only the person responsible for making the workshop happen will be burdened with extra work.
The alternative to this approach is to continue dealing with the disruptions caused by confusion, poor quality and frequent changes. I might suggest putting a price tag on the present, unfocused effort as a justification for exploring this alternative. You will be surprised to find how much requirements confusion costs in rework and delays.
Below are some considerations for utilizing a focus group approach to create the proper emphasis on requirements. Planning is critical for success and will typically consume 3-4x as much time as the workshop sessions, if done properly.
#1 Objectives
The first place to start a successful workshop is at the beginning – objectives. What is the purpose and charter of the focus group? Identify the scope to be one or multiples of system, engineering, module level, test or customer requirements. Also make sure to identify a sponsor, one who has authority to engage the team members for the workshop.
#2 Ground Rules
Separating a mediocre outcome from a clear success comes down to establishing rules of engagement. The ground rules establish how the team will operate and engage others during the workshop. The group will be a democracy and will need some laws to govern themselves.
- How will decisions be made where the team gets locked up?
- How will a troubling personality be dealt with?
- What about attendance issues?
- How will acceptable look?
- And so on…
It’s important there is guidance in place for situations before the group needs them. Reach agreement and post ALL ground rules.
#3 Inputs
This is the information and materials that are the inputs to the focus group sessions. It includes items such as an agenda, homework assignments, requirements quality checklist, templates, output expectations, existing specifications, business case, ground rules, visual aids and so on. The intent of the inputs is that they provide deliverables that the workshop will consume. Ideally the inputs should be prepared to a through enough degree to prevent the focus group from waiting for further information.
#4 The Main Event – The Focus Group
This is the actual workshop itself. The group will follow the agreed agenda and break up into smaller working groups as necessary to resolve requirements. Employ the agreed decision process when the team hits gridlock and leverage the agreed ground rules where necessary. Facilitation of this process is crucial to keep things moving forward. If the first three steps were done well, this main even should flow favorably; don’t skimp on preparation.
#5 Deliverables
Once consensus is reached it’s time to create specific workshop deliverables such as timing diagrams, models, electrical tables, block diagrams, descriptions and so on. Set actions in place to do this and set the team free. Once completed, pull the focus group back together for final review and acceptance. Depending on complexity there may need to be multiple iterations through focus group (#4) and deliverable generation steps (#5). Don’t get hung up on word for word review of requirements, focus on specific data (diagrams, tables, models). Once this process is complete the detailed requirements documents can be created.
#6 Closure
Hold a post mortem to learn and evolve the requirements focus group process for the next project. Generate specific, traceable actions for any remaining issues, including a follow-up plan to track through closure. Review the decisions that were made.
And so it goes…
If requirements are a battle, and I am sure they are, why not try something different? This approach is not magic; it’s really just about informed focus and will not work by breezing through the first three items to get to the main event. If you’re not willing to invest in the first three steps then don’t bother proceeding with this approach. A meager effort will waste time, provide dismal results and tarnish the reputation of this process.
Go forth and focus on early requirements, but prepare first!
What is NPD Management?
I am a newcomer to the blog ranks here at Extension Media and I wanted to say hello and introduce you to the topic of New Product Development (NPD) management. This is my passion and a broad area that I will regularly post about here.
NPD Management is not tools or project management. Nor is it design techniques or circuit descriptions. More than anything it is about enabling a new product team to be the absolute best at producing new product revenue. Enablers such as crisp requirements closure, internal IP reuse, and clarity of individual expectations are a few examples of NPD Managements focus areas.
Generally, there is always something beyond tools that is inhibiting optimal project execution. The key to continuous improvement will be in uncovering these barriers, developing a solution and rolling out a change in the development process that removes them as an issue. This is what NPD Management is all about.
Thanks for stopping by and stay tuned for tips, ideas and concepts that will help you in your quest to deliver products that produce target revenue quicker and with higher quality. I want to close with a quote on ownership that we must consider as we set our vision on being better.
“If it’s never our fault, we can’t take responsibility for it. If we can’t take responsibility for it, we’ll always be its victim.” –Richard Bach