tag:blogger.com,1999:blog-343633362024-02-20T11:37:15.465-07:00Coaching Excellence in NPD TeamsThis blog is dedicated to the discussion of topics that enable execution excellence in semiconductor new product development (NPD) teams.Jeff Jorvig - IC Design Leaderhttp://www.blogger.com/profile/15518464303087106227noreply@blogger.comBlogger107125tag:blogger.com,1999:blog-34363336.post-24720935568495922252011-05-27T07:15:00.000-07:002011-05-27T07:15:00.733-07:00It's not what you know; It's what you doDo you know how many times I hear "We already know that" when I am discussing the topic of improving new product delivery? I hear this in almost conversation I have on productivity. A considerable gap typically exists between what we know and what we do, and in the semiconductor new product development space the disparity is glaring. The harsh reality is that if productivity knowledge is not being applied, then you don't really know it. Without the application wisdom of successfully putting an improvement concept into operation, a claim of knowing is nothing but smoke.<br />
<br />
Throughout our career we have been presented with techniques, tools, strategies and methodologies that are recognized as a means to improve the way our organization executes on new products. We are all loaded with improvement knowledge, however the odds are that most never get around to implementing and validating those that seem to carry a positive benefit. This calculated procrastination is replayed for weeks, months and years while still claiming that we know how to do this. Implementing and making a change that provides the desired results is the hard part. It's time to put the empty justifications for inaction behind and move forward.<br />
<br />
Honestly there will never be a "good time" to kick-off productivity improvement activities. That ideal point in time where everything is just right will always be safely off at some point in the future; securely substantiated with a list of reasons for inaction today. <a href="http://jorvigconsulting.com/newsletter/may_11.gif" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://jorvigconsulting.com/newsletter/may_11.gif" width="250" /></a> The lack of knowledge in the application of techniques that enable positive changes coupled with a fear of failure is the real barrier here.<br />
Everything that holds back progress is pure FUDD (Fear Uncertainty Doubt and Disinformation).<br />
<br />
The following section is the complete list of the "false" reasons that promote inaction. These are the self-imposed barriers to implementing what we know about improving execution. Use these to check your motives. Once you understand your own barriers you can begin the process to migrate from a book smart knower to a successful implementer of change.<br />
<br />
<div style="color: #cc0000;"><b>Time</b></div>There will never be enough time unless you make it. This is only a convenient excuse, nothing more. Make time in future plans to enable the time to work on what you know will improve capabilities. Any improvement effort must be a sanctioned project with plans, resources and traceability. Never assume a behind the scenes and spare time effort will be successful; such assumptions lead to failure and further justify inaction.<br />
<br />
<div style="color: #cc0000;"><b>People</b></div>People do not want change, however they do want things to be different. Change is something imposed upon them, whereas enthusiasm mounts when they can be a part of making things different in a way that will benefit them. Involve people and solutions grow, exclude people and the barriers grow.<br />
<br />
<div style="color: #cc0000;"><b>Cost</b></div>This one never ceases to amaze me. "It's not in my budget" is simply an easy way to avoid the hard work to apply what you know will create a positive change. All problems have a cost; embrace that reality and turn the solution into a positive investment. If you can't define a problem cost, then it's not a real issue, is it?<br />
<br />
<div style="color: #cc0000;"><b>Not my Area or Problem</b></div>Essentially this reason is exploited to justify the source of a problem rests somewhere else. This is really simple - If something is impacting your ability to efficiently add greater value to new product development then it is your area, and definitely your problem.<br />
<br />
<div style="color: #cc0000;"><b>You</b></div>Check your motives. Are decisions based on comfort or reality? Yes, just like anyone else you can be a barrier in applying steps that are certain to improve productivity. Recognize that possibility and move forward. Get honest with yourself!<br />
<br />
When you can change your response on productivity approaches from "I already know that" to "I have already done that", real progress has occurred. Anything other than implementation is pure FUDD! I know that, others know that and you probably know that. The choice is to either keep looking over your shoulder, or take a shot at making a difference. <b>It's not what you know; it's what you do.</b>Jeff Jorvig - IC Design Leaderhttp://www.blogger.com/profile/15518464303087106227noreply@blogger.com1tag:blogger.com,1999:blog-34363336.post-17443497576092924702011-02-02T10:50:00.001-07:002011-02-02T10:51:50.762-07:00It's Always a Failure to Communicate<b>A failure to communicate is the root of any issue with new product execution; yes ANY issue! </b>Problems with tools, schedules, requirements and predictability to name a few are purely a symptom of a breakdown in the communication conduit. Any execution problem is directly related to the inability of individuals to relay information, debate trade-offs or properly convey a position.<br />
<br />
It's not the schedule that's broken; a lack in communication during schedule development is the problem. It's not that the requirements are wrong; it's the lack in quality communication during requirements development that misdirected the product scope. It's not that something unexpected came up; it's a failure in bubble up communications that allowed an underdeveloped plan to proceed. It's not a problem with the tool; it's a capability expectation that was not properly communicated, debated, verified and agreed upon.<br />
<br />
At any point in a project there are exchanges of information required to enable progression of a new product from its earliest concept to the generation of production revenue. These exchanges must add value to the quality, predictability and profitable revenue aspects of a new product, or failure(s) of the plan will result. Although very simple in concept, this is often difficult in implementation. Success at adding true value along the path results from accurately communicating throughout development.<br />
<br />
How would you define successful communication? Below is my list of attributes that are essential for high quality communication:<br />
<ul><li>Communication is two way, meaning there must be a mechanism for ensuring proper transmission; always full duplex mode.</li>
<li>Effective communication must provide a forum for debate to allow hidden issues or concerns to bubble up.</li>
<li>A high quality communication strategy never assumes physical proximity will be "the" solution to interaction issues.</li>
<li>An ideal communication implementation will remove barriers that inhibit contact between <b><u>any</u></b> two individuals.</li>
<li>The sources of specific information are singular, explicit and electronic for enablement of clarity in communication.</li>
</ul><div class="separator" style="clear: both; text-align: center;"><a bitly="BITLY_PROCESSED" href="http://jorvigconsulting.com/newsletter/feb_11.gif" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://jorvigconsulting.com/newsletter/feb_11.gif" width="290" /></a></div>If projects are going smoothly and predictably then there is a fairly solid communication methodology in place. However, beware if projects are riddled with surprises, delays and missed revenue expectations. A flag should also be raised if your meetings include conversations that frequently begin with the phrases in the above picture. In these cases I suggest looking carefully at how your organization communicates.<br />
<br />
The only way to find out where interaction may be lacking is to ask individuals for both specific instances and their perceived solution. Listen, learn, confirm and then solve. Based on these findings decide what constitutes quality communication and find ways to apply more of the excellent technology that's available today to help. As is always the case with change, persistence and leadership will be essential for success.<br />
<div class="separator" style="clear: both; text-align: left;"><iframe allowfullscreen='allowfullscreen' webkitallowfullscreen='webkitallowfullscreen' mozallowfullscreen='mozallowfullscreen' width='320' height='266' src='https://www.youtube.com/embed/1fuDDqU6n4o?feature=player_embedded' frameborder='0'></iframe></div>So I sign-off with the famous clip from the 1967 movie <b>Cool Hand Luke - "What we have here is (a) failure to communicate".</b>Jeff Jorvig - IC Design Leaderhttp://www.blogger.com/profile/15518464303087106227noreply@blogger.com0tag:blogger.com,1999:blog-34363336.post-26204803054624907822011-01-03T14:10:00.000-07:002011-01-03T14:10:00.464-07:002011 - Concepts for Really Making a DifferenceA fresh year is upon us, the economy is looking up and there is energizing opportunity in the air. This is an ideal time to jettison the organizational baggage that has been holding back new product execution for a long time. This is the year to eliminate a belief system that supports the ongoing systemic issues that keep cropping up product after product, year after year. This first blog of 2011 will provide some fresh perspective on bringing about positive changes in new product execution for your organization.<br />
<div style="color: #cc0000;"><b>Current Situation</b></div>Interestingly, there are far more similarities in new product execution issues than there are differences. Most organizations have very similar stories to tell about the frustrations of getting new products from concept to production, as per the business case projections. Requirements closure, scope control (feature creep), cost/schedule overruns and missed revenue targets are some of the typical themes for product development teams.<br />
<br />
Another common trait is the inability to effectively address systemic issues such as these. From my perspective the reasons for this include limited focus, a lack of assigning individual ownership, a smokescreen of unavailable funding and a limited understanding of the full financial impact of the current situation. Organizations have latched up and are stuck in a loop of purely addressing issues within functional silos, unable to fully visualize the full New Product Development ecosystem.<br />
<br />
The widely used matrix approach has left a huge gap in the ability to address obstacles that span multiple functional boundaries. Collaboration is working well on project specific topics and failing when the subject is more abstract, as in resolving broad coverage systemic execution issues. Get the picture? Take a step back and take a good honest look at what is happening, or actually not happening, when the subject is new product execution.<br />
<br />
A common definition of insanity is doing things the same way and expecting different results. How about making 2011 the year of fading insanity by doing things differently, really differently?<br />
<br />
<div style="color: #cc0000;"><b>Delivering Change in 2011</b></div><div class="separator" style="clear: both; text-align: center;"><a bitly="BITLY_PROCESSED" href="http://jorvigconsulting.com/newsletter/jan_11.gif" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://jorvigconsulting.com/newsletter/jan_11.gif" width="300" /></a></div>The following concepts outline the typical gaps that I have noted in addressing long term new product execution issues.<br />
<br />
<b>Ownership</b><br />
Solution by committee is ineffective because there is no ownership of the problem. Assign the problem, give this individual the proper cross silo power, set clear objectives and measurement and then get out of the way. This role is not a "in your spare time" activity!<br />
<br />
<b>Cost of Current Situation</b><br />
There MUST be a recurring cost identified with any systemic issue that requires a solution. Failing to identify a cost of staying the same allows the "unavailable funding" smokescreen to continue. If there is not a significant cost then it is simply not a substantial issue, real or perceived.<br />
<br />
<b>Involve the Team</b><br />
Solutions that do not include the team members that are experiencing the full impact of a problem are a just a management band-aid. Never forget that real solutions come from those that are experiencing the pain, not from conference room sessions.<br />
<br />
<b>Seek Perspective</b><br />
Be aware that being too close to the problem will shade objectivity. It's human nature to both knowingly and unknowingly substantiate a position that will have minimal impact on us. Strive to always seek out an objective perspective to keep self-serving motives in check.<br />
<br />
<b>Avoid Tool Exclusivity</b><br />
Tools bring significant advances in productivity. However, don't fall into the trap of assuming that the solution to all systemic issues lies in tools. New product execution strategies must include people management, individual communication and the maintenance of personal objectives.<br />
<br />
2011 will be the year of positive change only if you enthusiastically seek it. It is too easy to assume the source of change will originate elsewhere, a common misconception that allows terminal sameness to prevail. That assumption is dangerously easy!<br />
<br />
<div style="color: #cc0000;"><i>"Have you ever watched a fly bouncing off a window pane, even with an open door a few feet away? Many times the fly keeps crashing into the glass until it finally dies. There are many companies in today's world doing exactly the same thing. They continue down 'today's path,' wearing blinders to the possibility of change... until they die."</i></div><div style="color: #cc0000;">-- Mac Anderson</div>Jeff Jorvig - IC Design Leaderhttp://www.blogger.com/profile/15518464303087106227noreply@blogger.com0tag:blogger.com,1999:blog-34363336.post-52790020726494529792010-11-30T10:40:00.004-07:002010-11-30T10:46:27.188-07:00Matrix Organizations Fail at Fixing Broad Systemic Execution IssuesA matrix approach for sourcing projects has been in use for years and is a common practice that is given little thought these days. In concert with formal project management it has been proven to be both an effective and efficient approach for tactical project execution. However, utilizing this same approach in a strategic improvement setting frequently leads organizations down an extended path of disappointing results. This is essentially a "solution by committee" approach that lacks focus on solutions. There is a more effective means for creating solutions to systemic New Product Execution (NPE) issues.<br /><br />Dealing with issues that are completely self-contained within a single organizational silo is a fairly straightforward activity. All the inputs and outputs, the receivables and deliverables are totally within the grasp of the functional unit. The silo leadership can successfully manage these localized improvement activities without the need for information and/or decisions from outside their area of direct influence. This is the easy stuff!<br /><br />Taking on systemic issues that are of a broader functional area scope is where many organizations stumble, latch-up or fail miserably. They meet, they discuss, they add tools and they attempt to persuade for what seems like an eternity. These broad based issues often evolve into something that is deemed unfixable, although admission of such a defeat is never uttered, only displayed by a quiet pullback of focus on a real solution. New Product Execution (NPE) paralysis results from a culture that blindly promotes solution by committee, an approach directly enabled as a byproduct of the matrix methods used for product development.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://jorvigconsulting.com/newsletter/dec_10.gif"><img style="float: right; margin: 0pt 0pt 10px 10px; cursor: pointer; width: 320px;" src="http://jorvigconsulting.com/newsletter/dec_10.gif" alt="" border="0" /></a>While ideal for tactical management of project activities these same matrix approaches fail at developing solutions to broad scope systemic execution barriers, primarily due to a lack of specific accountability. If a particular problem does not have an explicit name associated with developing a solution for it, advancement towards a solution lacks focus. Review your most painful issues with NPE. How long has resolution been sought for this? Is there a singular owner identified and is this owner aware of this responsibility and it's objectives? Without an owner of these systemic barriers in place, solutions will remain elusive; it's really that simple!<br /><br />What's that, there are not enough resources available to assign a specific individual? That's nothing more than an excuse to keep things as they are, a somewhat unconscious means for inhibiting change. Estimate the recurring cost of the most glaring barrier to NPE and the rationalization for finding and assigning an ideal resource will present itself. Failure to do so will strengthen the "work harder, not smarter" philosophy that drives a misused sense of urgency, further eroding efficiency in new product development.<br /><br />Pause, take a deep breath and assign resources to fix issues that feed the insatiable new product frenzy that focuses more on quantity than quality. Reliance on a matrix approach for solving systemic issues will continue the quantity frenzy while individual accountability will enable competitive new product strength through quality, efficiency and working on the right things. It is absolutely a choice, one that many organizations fail to make.<br /><br /><span style="font-style: italic; color: rgb(255, 0, 0);">GM --> Focus on new product quantity, Apple --> Focus on new product quality. Where is your new product organization? Think about it!</span>Jeff Jorvig - IC Design Leaderhttp://www.blogger.com/profile/15518464303087106227noreply@blogger.com0tag:blogger.com,1999:blog-34363336.post-76211963938844863072010-10-29T10:32:00.004-07:002010-10-29T10:38:19.729-07:00Seven Signs of Trouble in New Product ExecutionWhat makes you crazy about NPD (New Product Development) projects? This is easy because there is rarely loss in ability to identify frustrations of dealing with product development. The struggle comes in enabling in an action plan to eliminate key issues, a battle that must overcome a perception that the situation is acceptable for now. It's discouraging for me to hear organizations chanting "we are doing OK " while the team in the trenches is continually bombarded with barriers to getting their job done.<br /><br />The reasons a circuit is not working properly receives a whole lot more attention and focus than why a new product does not meet the businesses expectations. This attention to the technical details at the expense the operational aspects are natural to the engineering profession. Natural, yes; OK, absolutely not! New product team members are saddled with operational roadblocks every day, some subtle and some highly visible. The impact of these obstructions is typically dismissed under the pretense of an acceptable level of NPD execution, therefore NO immediate need for addressing them.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://jorvigconsulting.com/newsletter/nov_10.gif"><img style="float: right; margin: 0pt 0pt 10px 10px; cursor: pointer; width: 320px;" src="http://jorvigconsulting.com/newsletter/nov_10.gif" alt="" border="0" /></a>Reality check - There is a significant difference in execution perceptions between management and team members for NPD. A failure to communicate properly perpetuates an ongoing management illusion of being OK or at least good enough for now. How often do negative surprises crop up in projects? These bombshells are actually signs of execution trouble, an indicator that should bring more reality to any illusions of OKness. To help distinguish illusion from reality, I will share seven signs of trouble in NPD execution.<br /><br /><span style="font-weight: bold;">1) The Team says it's not OK -</span><br />In many cases the team is either not being heard, or the input they provide is written off as whining. The gang in the trenches has valuable input and if there is something that they say is a setback for project execution, it's essential to pay attention. Lean principals work in manufacturing because those in the trenches drive change; the same goes for new product development. The illusion is that management knows best.<br /><br /><span style="font-weight: bold;">2) Execution issues are never expressed as a cost -</span><br />This is my hot button. Everyone talks about the fact that they can't afford to fix an issue. Interestingly, most have no idea what it costs to NOT fix something. If impact can't be expressed in terms of cost, there is no way to know if things are OK or not, is there? The illusion that ongoing problems have minimal cost is a dangerous one.<br /><br /><span style="font-weight: bold;">3) Timeline slips to production revenue are routinely greater than 6 weeks -</span><br />If commitments are not being met, how can things possibly be OK, or even good enough? The source of slips is generally NOT due to the team's lack of motivation to get it done; most teams consistently burn the midnight oil to meet objectives. There is more to this issue than pure motivation. The illusion is that the team is just not giving it their all and that's why products are slipping.<br /><br /><span style="font-weight: bold;">4) Revenue targets are missed on greater than 20% of products -</span><br />Things are not OK if too many products fail at producing revenue. The costs associated with an unsuccessful full product development effort must command a full audit. Any findings should be fed back into improving the product approval process. The illusion is that risk is important to winning market; therefore no further action is necessary. The truth is there is always much to be learned from a failed project.<br /><br /><span style="font-weight: bold;">5) Discussions and meetings about a suspected problem for over a year -</span><br />When operational problems are not settled within a year it is a clear indicator of indecisiveness. Either it's a problem and it will be fixed, or it's an issue with no plan for resolution. The illusion here is a belief that there is actually action going on to solve it! Identify the cost associated with leaving it alone and the cost of fixing it. Create an ROI, build a case, make a decision and be done with it. Dragging issues out for an extended period of time confirms a problem exists, however sidesteps any real solution.<br /><br /><span style="font-weight: bold;">6) Everything is urgent, except driving change so that everything is no longer urgent -</span><br />Does it feel like the people in your organization mimic pinballs, jumping from urgent matter to urgent matter throughout the day? Unchecked urgency is a sign of poor structure and process, not a sign of a team's enthusiasm. Here the illusion is that pinball like activity shows team member engagement.<br /><br /><span style="font-weight: bold;">7) There is a belief that formal project management inherently takes care of execution issues -</span><br />Project management is a tactical approach to getting things done and is not inherently a fixer of all things wrong. Assuming everything is OK under the project management umbrella is a trip down fantasy lane, the illusion should be obvious here.<br /><br /><span style="color: rgb(255, 0, 0); font-style: italic;">"You don't drown by falling in the water; you drown by staying there."</span><br /><span style="color: rgb(255, 0, 0);">- Edwin Louis Cole</span>Jeff Jorvig - IC Design Leaderhttp://www.blogger.com/profile/15518464303087106227noreply@blogger.com0tag:blogger.com,1999:blog-34363336.post-91684502961751612702010-10-04T12:24:00.007-07:002010-10-04T12:38:13.664-07:008 Habits of a Highly Successful New Product OrganizationOur personal habits, both good and bad, often occur without thought, almost at the unconscious level. An organization also has both positive and negative habits, many of which are performed instinctively due to the routine nature of project activities. A highly efficient organization has done a good job of replacing any bad habits with good.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://jorvigconsulting.com/newsletter/oct_10.gif"><img style="float: left; margin: 0pt 10px 10px 0pt; cursor: pointer; width: 250px;" src="http://jorvigconsulting.com/newsletter/oct_10.gif" alt="" border="0" /></a>What you are about to read is an ideal view of a new product development organization, one that produces at a level that is easily envied by others. The fact that it's ideal should not immediately allow it to be dismissed as unattainable, although that is likely the initial instinct due to an anti-change predisposition. The attributes of a high efficiency organization described here is very much a possibility, but only where the knee jerk reaction to dismiss it is suppressed long enough to learn from these habits.<br /><br /><br /><span style="font-weight: bold;">Learning</span><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://jorvigconsulting.com/newsletter/learning_cycle.gif"><img style="float: right; margin: 0pt 0pt 10px 10px; cursor: pointer; width: 270px;" src="http://jorvigconsulting.com/newsletter/learning_cycle.gif" alt="" border="0" /></a>Highly successful NPD business have the capacity to learn from previous product development efforts and apply that learning, knowing that this is crucial for the organizations long-term health. As a learning organization they realize knowledge growth has not occurred simply because they held a lessons learned or post mortem session. They know the learning process is about proactively discovering barriers and then creating and tracking actions to remove those obstacles. If learning was successful they recognize that something must change.<br /><br /><br /><span style="font-weight: bold;">Listening</span><br />The people doing the work on the frontline have much to offer in terms of execution efficiency and a successful new product development machine will leverage this fact; they promote continuous listening for core issues. People clearly know they have a voice and solutions will percolate up from the bottom, not be legislated from the top down. Listening is the culture, and everyone believes this.<br /><br /><br /><span style="font-weight: bold;">Evolving</span><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://jorvigconsulting.com/newsletter/oct_10_2.gif"><img style="float: right; margin: 0pt 0pt 10px 10px; cursor: pointer; width: 270px;" src="http://jorvigconsulting.com/newsletter/oct_10_2.gif" alt="" border="0" /></a>Change is the mantra and perfection is the target. Lean concepts permeate the organization and everyone is energized to make product development efforts better today than they were yesterday. Ego related stances are non-existent; personally being right is far less important than doing the right thing for the business. Cross-functional collaboration is routinely practiced as the primary means of improving new product execution. Change is expected.<br /><br /><br /><span style="font-weight: bold;">Clarity</span><br />Objectives are clear and everyone knows exactly how they will contribute to the success of the product. A process is in place to manage all levels of requirements, minimizing any waiting for decisions and/or answers while supporting the essential agile component in meeting the customer changing needs. Specific requirements items are phased in a way that allows the team to move forward with what is known, while longer lead items have the appropriate focus to reach solid closure. A proper level of clarity within the development team is displayed through a lack of unnecessary rework.<br /><br /><br /><span style="font-weight: bold;">Personal</span><br />People enjoy their jobs and have a passion for making things better. They have a mechanism in place that allows them the freedom to speak and be heard. Management views their inputs as an essential ingredient to producing a more efficient organization. Lean concepts are the lifeblood of the culture.<br /><br /><br /><span style="font-weight: bold;">Decisiveness</span><br />Decisions are well informed, quick, crisp and well communicated. No one is left wondering how to proceed. Where additional information is needed, actions are put into place to drive and track timely data gathering activities. Unsatisfactory decisions are viewed as learning opportunities and are analyzed for future improvements to the development process.<br /><br /><br /><span style="font-weight: bold;">Planning</span><br />Planning is thorough, involving everyone who will be contributing to the project. Milestones are communicated to the degree that anyone randomly selected will be able to properly provide target dates when asked. Owners of tasks also have the information immediately available to them for completion timing and specific deliverable expectations. Projects are successfully meeting ALL milestones at a 90% level.<br /><br /><br /><span style="font-weight: bold;">Product Launches</span><br />The product roadmap is an evolving plan based on current trends, customers, technology development and market intelligence. A product launch commitment is based on solid resource availability, solid revenue projections, sales force engagement, customer engagement and NPD team commitment. New products are meeting business case revenue and margin projections at the 90% level.<br /><br /><br />Development of these eight habits in your organization is well within reach, given a willingness to invest in change. However, do not be fooled into believing it's a part time effort. It is work, it will cost and the payoff will far exceed any expense when implemented properly. <span style="font-style: italic;">Go forth and change!</span>Jeff Jorvig - IC Design Leaderhttp://www.blogger.com/profile/15518464303087106227noreply@blogger.com0tag:blogger.com,1999:blog-34363336.post-82869228989041091092010-09-01T09:43:00.003-07:002010-09-01T09:50:15.852-07:00Delivering Lean and Mean New Product DevelopmentMost are familiar with Lean Manufacturing today, a concept brought into the limelight through the Toyota Production System (TPS). Henry Ford was actually one of the earliest "Lean thinkers" with the notion of an assembly line. In it's early form this waste elimination concept was considered only applicable to manufacturing. Today it has expanded into areas that include healthcare, government, construction and services to name a few. The application in New Product Development (NPD) is a relatively new area that has significant opportunity for improving development time, quality and predictability while reducing developments costs. <span style="font-style: italic;">It is easy to say Lean cannot apply to the non-repetitive engineering and invention aspects of NPD; that's not right, it's just easy to say.<br /></span><br />Let's start off with defining what lean is; put simply, it is about improving efficiency by eliminating waste. The inefficiencies can be in the form of the use of people's time, inadequate tools, rework, overdone requirements, non-value steps/activities/meetings and so on. Waste can be found in many areas, mostly buried and out of sight. Consider Lean as nothing more than creating a culture to drive higher levels of efficiency on a continuing basis.<br /><br />There is plenty of opportunity for leaning up in new product efforts. The scope of any Lean effort must cover the entire development process from initial customer contact to a volume revenue stream with that customer. A localized view of any subset of the total NPD process is actually anti-lean due to an obvious disconnection from the value stream, an error for many improvement initiatives. Lean must be a big picture view that includes all functional areas, both deliverers and receivers of a common value stream.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://jorvigconsulting.com/newsletter/sep_10.gif"><img style="float: right; margin: 0pt 0pt 10px 10px; cursor: pointer; width: 250px;" src="http://jorvigconsulting.com/newsletter/sep_10.gif" alt="" border="0" /></a>The diagram to the right represents the typical components of a lean approach. The cycle is one of continuous learning and an ever-evolving process based on that learning. It never ends; an organization is never done. As soon as there is a belief of doneness, the lean train is derailed. Begin a Lean journey by looking for areas where the principals can be applied to NPD.<br /><br /><span style="font-weight: bold;">Value</span><br />The focus of any new product must always be on the customer value. For any new product you must be able to clearly identify where the customer value is. That is what matters, in fact that's all that matters. Be in the customers shoes, feel the problem to be solved. Think beyond requirements to include interactions, information exchanges, trust, communication and the needs for development of their product. <span style="font-style: italic; font-weight: bold;">You must be absolutely certain of what the customer values in a relationship with you on new product.</span><span style="font-weight: bold;"> </span>Delivering all aspects of customer value is a distinct competitive advantage.<br /><br /><span style="font-weight: bold;">Identify Value Stream</span><br />Anything that does not add to the customer value is a waste; it is outside the value stream. This is a tough one for those that believe everything they do is important, essentially the majority of organizations today. Meetings, documentation, decision processes, procedures, reviews, sign-offs; they are all suspect of being off the value stream in their current form! The value stream is only the activities, information and deliverables that clearly promote the customer value. Can you identify the value stream for new products in your organization?<br /><br /><span style="font-weight: bold;">Create Value Flow</span><br />Now, knowing what the value stream is, build a NPD flow that supports that value stream. Get rid if the wasted activities, meetings and deliverables that do not directly enhance the customer value for new products. What are you doing because you have always done it? This is a great place to engage some good solid discovery, beginning at the bottom and working up. Creation of the value flow will not be for the faint of heart; every activity today is already assumed to be valuable and there are people and bruised ego's to deal with. The output of this phase should be a development flow that is highly efficient in bringing value to the customer at the quickest pace and the lowest cost.<br /><br /><span style="font-weight: bold;">Establish Pull</span><br />This one is a little tricky for NPD. Establishing pull means that deliverables are completed at the latest time possible, where the greatest amount of information is available. Today most are focused on getting everything done ASAP and queued up before it's needed, essentially creating inventory and a push forward. A pull is more like JIT (Just in Time), where tasks and deliverables are completed as needed, at the maximum point of knowledge for the task. Think of pull as tasks that are demand driven. For NPD a pull mindset will have a significant impact on quality and rework. How much is being redone because of not knowing what was needed the first time? Pushing tasks creates rework!<br /><br /><span style="font-weight: bold;">Seek perfection</span><br />To seek perfection is a course of continuous improvement. The lean process is never done and ever evolving, always improving upon knowledge from previous projects. Perfection does not just happen; it is asymptotically being approached with every new project. <span style="font-weight: bold; font-style: italic;">Lean NPD is a journey, not a destination.</span>Jeff Jorvig - IC Design Leaderhttp://www.blogger.com/profile/15518464303087106227noreply@blogger.com1tag:blogger.com,1999:blog-34363336.post-36630674891856297912010-07-29T08:40:00.006-07:002010-07-29T08:53:56.343-07:00New Product Execution - It's Just not Good EnoughNew Product Execution is never quite good enough, although there is certainly a continual business emphasis demanding better. There may be small pockets where new products efforts scream success, although the overall effort frequently comes in with a "C" grade or worse. How's your organizations new product execution grade? No, you can't grade yourself; the only grade that matters is the one from the business GM or the customer.<br /><br />There is a broad belief that if new product execution is failing it's because the development team does not have enough passion to get the job done. I strongly disagree with this narrow-minded perception. My long-term observation is that if execution is failing, it's because leadership has failed the team. Leaderships role is minimally to guide the team to a better tomorrow through the seeking and addressing of systemic issues that are routinely impacting execution. I firmly believe that a key role of leadership is the enablement of an environment that spawns continuous improvement.<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://jorvigconsulting.com/newsletter/execution_roadmap.gif"><img style="float: right; margin: 0pt 0pt 10px 10px; cursor: pointer; width: 325px;" src="http://jorvigconsulting.com/newsletter/execution_roadmap.gif" alt="" border="0" /></a><br />The picture to the right is a list of common objectives and challenges that will pave a path to execution excellence, as each item is addressed. Click on it, print it and hang it on the wall as guide to attaining an "A" grade in new product execution. Utilize the concepts below to further hone a strategy for leaving average execution performance in the dust.<br /><br /><span style="font-weight: bold;">An Execution Strategy is Missing</span><br />News flash - new product execution is lacking a strategy simply because of a misplaced belief that there is one. That ghost strategy is actually a rigid tactical approach masquerading as an execution strategy. An authentic strategic approach will minimally include:<br /><ul><li> Regular questioning of why things are done as they are.</li><li> The regular application of learning from past products.</li><li> A participant scope that includes all functional areas.</li><li> Embraces dynamic planning.</li><li> A shared vision of what ideal execution looks like.</li><li> Cover all activities from concept through revenue.</li></ul><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://jorvigconsulting.com/images/why.gif"><img style="float: right; margin: 0pt 0pt 10px 10px; cursor: pointer; width: 175px;" src="http://jorvigconsulting.com/images/why.gif" alt="" border="0" /></a>If you are really looking for improvement, challenge the age-old tactical sequencing of who, what and when by routinely throwing a "why" in the mix of planning. This questioning nature could mark the beginning of a solid strategy for grade "A" execution.<br /><br /><span style="font-weight: bold;">Execution Scope is far too Narrow</span><br />At what point does new product execution begin? Most would be apt to identify the phase where significant design activity commences. I disagree; execution begins when that first twinkle of an idea begins to glow, where a product concept is born. A misguided assumption that execution begins with later activities allows the critical early tasks to flounder, avoiding the crisp management required to drive efficient closure. The "let's think about it" queue must be considered as execution, with all the sense of urgency and accountability that is expected for any project phase. The deliverables, time line and objectives must be managed from the very beginning.<br /><br /><span style="font-weight: bold;">Unacceptable New Product Success Ratio</span><br />How many products fail at meeting business case profit? Those losers will certainly eat up the ability to execute well on the successful products. Any product that is not a financial success must be scrutinized. The root cause for allowing such products to continue marching forward in the face of eventual failure must be well understood. There is gold in the analysis of failed products and significant mining will be required to gain access to it. Throw on your miner hat, turn the light on extra bright and go about finding the golden nuggets of information that will enable an improved strategy for approving and monitoring new products.<br /><br /><span style="font-weight: bold;">Failing to find what is Unknown</span><br />I have been talking about unknowns since the first day I opened the doors for business and it still baffles people when I talk about them. An unknown is a masked barrier to smooth, orderly and predictable execution in a new product effort. If you are not specifically looking for unknowns and removing them, your new product execution will have an element of time-wasting rework. If you want a higher level of predictability, go out and find what you don't know, and do it regularly. "Those that know, know they know. Those that don't know, don't know they don't know"Jeff Jorvig - IC Design Leaderhttp://www.blogger.com/profile/15518464303087106227noreply@blogger.com0tag:blogger.com,1999:blog-34363336.post-28229846802604974092010-06-30T18:44:00.006-07:002010-06-30T18:55:34.167-07:00Tools for Enabling Collaborative EnvironmentsWhat comes to mind when you hear the term collaboration or collaborate? My definition is enablement of an environment that minimizes disconnects and misunderstandings between individuals on a team. A collaboration strategy should also foster sharing of ideas, concepts and visions of the individual contributors while keeping the team current of the status of the project. Attaining a truly successful collaborative environment will always eliminate any team execution issues related to geographic boundaries.<br /><br />The word collaborate or collaboration is overused, in fact it is safe to say that it's meaning has been minimized to the point where any team is in fact identified as a collaborating machine. Here's the dictionary definition of collaborate: To work together, especially in a joint intellectual effort. "Working together" - that means more than just working on the same project. <a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://jorvigconsulting.com/newsletter/jul_10.gif"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 300px;" src="http://jorvigconsulting.com/newsletter/jul_10.gif" alt="" border="0" /></a>It means synchronization, communicating, shared visions, gaining consensus, sharing ideas, informed decisions, understanding contribution and always knowing status. The sharing of files as a collaborative mechanism for projects is archaic and has no place in a high tech industry! Technology has brought us much, much better ways, if we choose to explore them.<br /><br />There are an abundance of tool solutions available today that foster collaboration and I wanted to share three specific types with you; planning, group chat and brainstorming. I heavily favor hosted SaaS (Software as a Services) solutions due to their cross platform availability and the collaborative enabling aspect of centralized data for all to see. Hosted "cloud" solutions are all web-based interfaces and require nothing to be installed on your computer.<br /><br /><span style="font-weight: bold;">Scheduling & Managing the Process</span><br />First off, in an environment that talks of collaboration, it certainly does not make sense that a single person has a view of the status, tasks due, next steps, overall project flow and so on for any project. The days of a singe person maintaining a schedule file should long ago gone the way of the horse and buggy. There should be no secrets and certainly each individual should be responsible for keeping their tasks current... did I hear a gasp?<br /><br />There are many hosted (web interface) solutions that cover the needs of centralized, multiple platform (even Linux), multiple-site and user-friendly project planning/management tools. Find them via a search string like "SaaS project management tool". My favorite is <a href="http://jorvigconsulting.com/promotions/pie_jci.html">PIEmatrix</a> due to its slice concept, allowing the establishment of predefined best practices for each NPD role.<br /><br />If you are concerned about your planning data residing outside the corporate firewall, many of these companies provide internally hosted solutions also. Personally I don't agree with such concern; look at how many large companies have embraced <a href="http://salesforce.com/">saleforce.com</a> and allowed their sensitive customer relationship data outside the firewall.<br /><br /><span style="font-weight: bold;">Chat</span><br />When you think of chat the last area that you may see benefit of this social technology is managing teams and projects. The latest chat technology standards known as XMPP (Extensible Messaging and Presence Protocol) provide much more flexibility in terms of group level chatting (Persistent Group Chat), opening an interesting door for project collaboration.<br /><br />Consider that specific project group chats could be setup for various chip modules, EDA, verification, requirements, integration, timing analysis, synthesis, test, system verification and so on. Team members can subscribe to only groups of interest to them. This then becomes a real time discussion and communication area for items of importance to that particular chat group. There is even a history capability for documenting the discussion. Via this technology worldwide real time collaboration can become a simple task for projects spanning multiple continents.<br /><br />Individual chat servers could be setup inside the corporate firewall for each project and then configured to provide specific chat groups of interest for that project. There are also several hosted chat solutions that provide similar features. The technology exists, is supported on multiple platforms, including smart phones, and costs range from free to low. Why not give it a try? Search for "persistent group chat" to find hosted solutions. Check out <a href="http://xmpp.org/">http://xmpp.org</a> for client/server possibilities.<br /><br /><span style="font-weight: bold;">Brainstorming</span><br />There is no better way of collaborative brainstorming than the use of mind maps. Many are hosted and allow real time map sharing for multi-site brainstorm sessions. Review <a href="http://iccoach.blogspot.com/2010/05/wonders-of-mind-mapping-in-new-product.html">last month's posting</a> for more information on mind mapping.<br /><br /><span style="font-weight: bold;">Collaboration or Extinction</span><br />The largest issue I see with project execution is due to a lack in the most fundamental of capabilities, a deficiency in individual communication. If people are not communicating well they are certainly not successfully collaborating. Tools that enable better communication will also facilitate the much-needed collaboration that will bring about change. A cure for "Terminal Sameness" is an incremental choice, one antidote at a time.Jeff Jorvig - IC Design Leaderhttp://www.blogger.com/profile/15518464303087106227noreply@blogger.com0tag:blogger.com,1999:blog-34363336.post-3750312330655562842010-06-18T09:47:00.002-07:002010-06-18T18:15:11.103-07:00Is the Productivity Scorecard Measuring What Matters?After years of talking with and working with New Product Development (NPD) teams, my productivity report card is in and the grade is not good! Acceptance and tolerance of the current situation scores high; while real, substantial and sustainable productivity improvements for the overall development process clearly gets a failing grade. Sorry people, but our industry is stuck in a mode of <span style="font-weight: bold;">“terminal sameness”</span>!<br /><br />When the subject of productivity comes up in the semiconductor industry the discussion immediately goes to tools, EDA and all the wonderful things going on in that sub-segment of the chip development world. So, how has that focus been working out for the last 15 years? Are chip developments now predictable and smooth? Yes, I know; more integration, more transistors, embedded software, tighter technologies and the like are keeping projects messy and that’s the reason why new product efforts are still behind, over budget and require multiple spins. Really?<br /><br />My observation is that new product execution is not being properly measured or managed. Project management methods have been in place for years now and they deal superbly with the tactical approach to guiding projects. What is missing is a strategic approach to managing a project and by that I mean really understanding what is not working and fixing it.<br /><br />I frequently talk to teams that are dealing with highly visible execution problems for years with no solution in sight; and I do not mean tool issues. I am talking about team dynamics, mechanics and cross silo operational issues that siphon off a team’s productivity and are often not included in the productivity scorecard. That kind of short sightedness is just plain anti-success and merits an F in the productivity area.<br /><br />The sad part in this is that there is large acceptance of non-tool related barriers to productivity, and I just don’t get that. How can leadership turn a blind eye to glaring issues that allow a NPD team to stumble over each other, project after project? From my perspective leadership is all about removing the barriers that keep their teams from being the best they can be, <span style="font-style: italic;">it is their primary role.</span><br /><br />If the productivity scorecard is to significantly improve it will require the addition of a dedicated effort to locate and repair new product operational issues, an area that is not receiving the focus it deserves today. It means spending more time looking at people issues. If you’re a leader, I challenge you to prove that I am wrong!Jeff Jorvig - IC Design Leaderhttp://www.blogger.com/profile/15518464303087106227noreply@blogger.com0tag:blogger.com,1999:blog-34363336.post-85442178156573152152010-05-27T10:50:00.006-07:002010-05-27T11:08:08.225-07:00Wonders of Mind Mapping in New Product DevelopmentEver heard of a Mind Map? Most people either already routinely use them or are completely in the dark about them, as I was a year ago. Since I reluctantly made the Mind Map plunge I have found them to be of great value early on in any project, helping greatly to clarify mission, objectives and strategies. Now I don't do anything without first starting with a Mind Map. This month's newsletter will be a journey to the wonders of mind mapping in the semi business. And yes, this blog topic originated as a mind map before I typed the first word.<br /><br />I got hooked on Mind Mapping a little over a year ago and now find that it is the beginning of anything I do, from writing blogs and newsletters to strategizing detailed proposals for my clients through planning out full projects. I now view the mapping process as essential for helping me think things through and presenting ideas, concepts and proposals. In fact the entire Mind Map for this newsletter is included at the end; you decide if it was quicker to read the words or look at the map for information of interest to you.<br /><br /><span style="font-size:100%;"><span style="font-weight: bold;">What is a Mind Map?</span></span><br />A completed mind map is simply a pictorial view of concept expansions, much like an outline on steroids. One difference being an outline is linear, whereas a Mind Map is not. The beauty of the map is not so much the finished product, but the process in getting there; the thought processes, discussions, brainstorming and non-linear thinking utilized in developing a map.<br /><br />The key features of a mind map tool typically include graphics, links, text expansion as well as connectors to indicate relationships between concepts. They are graphical tools that allow simple and quick manipulation of concepts, making them ideal for group brainstorming. An added advantage of a hosted web based mind map solution is that it allows for multiple locations to join in for real time collaboration on a single map, great for multi-site brainstorming.<br /><br /><span style="font-size:100%;"><span style="font-weight: bold;">What Mind Map Tools are Available?</span></span><br />There are a variety of client based as well as hosted (web SaaS) Mind Map solutions available. I prefer the hosted solutions because they are platform independent and I can get to my maps from anywhere. Some hosted solutions even provide for offline work, making them the best alternative, in my opinion. If you would like to review my links to specific tools download my blog map (It will be a pdf) at the end and click on the various links associated with the "Mind map tool links" concept.<br /><br /><span style="font-weight: bold;">Where can Mind Maps be used in the Semiconductor Biz?</span><br />If there is an idea that needs a path to closure, consider the Mind Map process as the guide. There are multiple areas where I believe Mind Maps will provide value in new product development.<br /><br /><span style="font-style: italic; color: rgb(204, 0, 0);">Requirements Gathering</span><br />Pulling together features is a great way to leverage a mind map to easily capture, drill down, prioritize, brainstorm and decide upon new product requirements. Use a mind map in a requirements workshop session or a team meeting and see the magic of high-octane collaboration. All levels of requirements such as IP, Chip, module, product and system would realize benefit from the Mind Map process to generate and sort through possibilities.<br /><br /><span style="font-style: italic; color: rgb(204, 0, 0);">The Product Development Process</span><br />If you need to brainstorm reasons why the development process is done a certain way, conceptualize process alternatives, identify barriers or hash out the design flow consider a mind map as a guide to capturing ideas and guiding the discussion. Large groups, small groups or individuals will appreciate the non-linear thinking, quick capturing and idea drill down of the mind map process.<br /><br /><span style="font-style: italic; color: rgb(204, 0, 0);">Product Portfolio</span><br />Hash out the product roadmap, build decision trees or construct a new product decision process with the use of a mind map. Once completed the information can be captured in the standardized forms for your organization. Remember, the mind map is guiding the thought process, not necessarily producing the final documentation.<br /><br /><span style="color: rgb(204, 0, 0); font-style: italic;">Project Definition</span><br />This is my favorite use of a mind map; in the early stages of planning where the projects are just beginning to form. Brainstorm to identify, dismiss and accept project alternatives. Do the same for risk and mitigation strategies. Specific task identification, drill down and development are a natural for the Mind Map brainstorming process.<br /><br /><span style="font-weight: bold;">Are you a Mind Map Type?</span><br />Now the test - <a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://jorvigconsulting.com/newsletter/semi_mind_mapping.pdf"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 320px;" src="http://jorvigconsulting.com/newsletter/semi_mind_mapping.gif" alt="" border="0" /></a>review the Mind Map for this article (click diagram for pdf download) and decide if it is more efficient for you to scan the text or utilize the mind map to retrieve information of interest to you? If the text wins you are predominately a linear thinking type. If the mind map was more advantageous for you, then welcome to the world of non-linear thinking. Go forth and map your way to better ideas, concepts, decisions and collaboration!Jeff Jorvig - IC Design Leaderhttp://www.blogger.com/profile/15518464303087106227noreply@blogger.com0tag:blogger.com,1999:blog-34363336.post-37472767790970437232010-05-14T05:38:00.002-07:002010-05-14T05:41:47.232-07:00Survey – How is Internal EDA Support UtilizedThe 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.<br /><br /><div style="text-align: center;"><a href="http://survey.constantcontact.com/survey/a07e2w6mq3ug95ldgwv/start">Off to the Survey</a></div>Jeff Jorvig - IC Design Leaderhttp://www.blogger.com/profile/15518464303087106227noreply@blogger.com0tag:blogger.com,1999:blog-34363336.post-50905079609641079282010-05-12T09:48:00.004-07:002010-05-12T10:03:32.712-07:00Is New Product Development Dysfunctional?So how should the question <span style="font-style: italic;">“Is the New Product Development (NPD) effort dysfunctional”</span> be answered? It’s a simple question with a yes or no answer; there is no middle of the road response allowed here. Hanging out in the intermediate zone permits the warm fuzziness of maybe or sort of to cloud the issue. <span style="font-style: italic;">Simply asked - Is the NPD development process broken or not?</span><br /><br />If any of the answers to questions the below are yes, then the NPD process is not working. These three simple assessments should be considered key indicators of a dysfunctional development process.<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://jorvigconsulting.com/newsletter/npd_dysfunctional.gif"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 420px;" src="http://jorvigconsulting.com/newsletter/npd_dysfunctional.gif" alt="" border="0" /></a>And the answer is a big yes; the NPD process is dysfunctional, right? Any one of the three indicators posed above involves a great deal of lost revenue and should command real attention. There is typically a firm management directive that states these items are unacceptable and must be resolved. It gets brief attention, limited direct action and then the lost potential revenue is swept under the rug.<br /><br />Here’s the deal – the NPD process is broken. Admit this and do something about it or deny it and do nothing. Stop hanging out in the middle, burning precious resources on misdirected activities that are really lacking the buy-in, resources or broad impact that will guarantee success. The middle ground incremental improvement efforts lack the proper focus on fixing the development process. Additionally, these solutions are falsely deemed a success by an achievement measurement that means little or nothing to a big picture victory.<br /><br />For success on a scale large enough to repair dysfunctional product development efforts, there must be a direct assault on the key indicators, the bulls-eye of true improvement! Whoa, how can we possibly take those on? It’s long past the time of small thinking, a belief system that wastes money and does not address the core problems. Remember, solutions must address the fact that the overall NPD process is dysfunctional on multiple fronts!<br /><br />It’s time to get real about assessing the process of bringing new products to market. Honestly answer the question <span style="font-style: italic;">“Is the new product development effort dysfunctional?”</span> Fully understand the “why” of each key indicator of a busted development process by drilling down and uncovering <span style="font-weight: bold;">all</span> the reasons that they are occurring. Engage in a grass roots effort to fix what is found. Stop the “We are getting better” dance, unless there is quantifiable impact on the key indicators.Jeff Jorvig - IC Design Leaderhttp://www.blogger.com/profile/15518464303087106227noreply@blogger.com0tag:blogger.com,1999:blog-34363336.post-23258560805934143682010-04-29T11:54:00.005-07:002010-04-29T12:10:25.263-07:00I am Mad as Hell and I am not Going to Take it Anymore!!!Has the title of this blog gotten your attention? The title is a key line from the 1976 movie "Network" where the news anchor gets a large portion of the population yelling this from their windows to vent frustration with things. <a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://www.youtube.com/watch?v=dib2-HBsF08"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 200px;" src="http://jorvigconsulting.com/newsletter/mad_as_hell.gif" alt="" border="0" /></a>So what does this movie have to do with the chip business? Read on to find out how the famous line from this movie forms a strategy that will guide you towards making a difference in your work situation.<br /><br />The level of frustration I feel on all levels of the semiconductor new product organizations are at an all time high. It's pent up, steaming and being held close to the chest; further weakening the possibility for solutions. <span style="font-weight: bold; font-style: italic;">Issues are being aired around the lunch table with great ease, plausible solutions are being generated and then people go back to work, sitting silently in the great wasteland of sameness!</span><br /><br />Here's the deal. Things are exactly the way you tolerate them to be. There is a lot of acceptance of clearly negative sources of impact going on, and that's the problem at large. I read a book review in the newspaper paper this past week titled <a href="http://www.yourkidsareyourownfault.com/">"Your kids are your own fault"</a> by Larry Winget. I have not read the book, only the synopsis. Interestingly, this title made me think long and hard about the situation with project execution, outsourcing and the working climate we have today in the semi industry. <span style="font-style: italic; font-weight: bold;">Fact - we are personally responsible for creating and maintaining our work situation as it is today.</span><br /><br />If something is impacting your ability to perform your tasks and it's ticking you off, <span style="font-style: italic;">own it as your problem to be resolved and take the initiative to make it go away!</span> Sorry people, but that's the only way things are going to change for you. <span style="font-weight: bold; font-style: italic;">Stop waiting for someone else to notice how something is impacting your ability to execute and fix it for you.</span> It's just not going to happen that way, so stop with the empty whining and take action. I have talked with a lot of people on new product teams and the way I see it is there are a lot of them waiting for someone to remove a barrier that is personally impacting them.<br /><br />Everyone wishes things were different. The business manager wishes new products would meet expectations for delivery timing, quality and functionality - just be predictable. Designers wish the tools and flows gave them what they needed, always. The test people want to be involved earlier in products. <a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://jorvigconsulting.com/newsletter/frustration_solution.gif"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 300px;" src="http://jorvigconsulting.com/newsletter/frustration_solution.gif" alt="" border="0" /></a>The product people wish designers would communicate better. The project manager wishes people would do what they said they would do. The wish list goes on and on. What's on your list?<br /><br /><span style="font-weight: bold; font-style: italic;">Get mad, mad as hell about what's causing you grief on projects. Feel the impact of the problem on your activities and the sleep you lose over it. Stop accepting the situation as it is, you don't need to take it anymore. </span>Now here's the big step - take that frustration burning within and own the source of it. Make it your personal objective to eliminate it as a source of aggravation. Stop falling into the sameness trap of making sure the problem is not yours by creating justification to transfer ownership; remember you are mad as hell and not going to take it anymore. <span style="font-weight: bold;">This one is yours! </span>Jeff Jorvig - IC Design Leaderhttp://www.blogger.com/profile/15518464303087106227noreply@blogger.com0tag:blogger.com,1999:blog-34363336.post-24270631159969143302010-04-13T09:46:00.002-07:002010-04-13T09:57:38.598-07:00I want things to be Different, but I don’t want to ChangeEveryone has something they would like to see different, some aspect of the development process that they view is causing continuous disruption in new product releases. Reflect on your businesses ability to react to near term project execution crisis. Like most, the ability to resolve an immediate roadblock that is impacting a specific project is quite impressive. The team rallies to action in a high-energy fashion, makes a decision and moves on to a solution very quickly.<br /><br />Now consider an issue that is systemic in nature, in that it’s omnipresent and has the ability to disrupt a wide range of projects. How’s the energy for resolution in this situation? I am sure it lacks the vigor that is observed for a project specific emergency. The persistent systemic execution barriers routinely take a back seat to the highly visible, project specific issues that crop up and block a project. Interestingly, the more pervasive problems are generally much more of an execution hindrance than the high intensity, bang on the table and fix it now project glitches that demand immediate solutions.<br /><br />There is an interesting dynamic going on between these two different scenarios. In the case of a project specific problem, the team only needs a specific one-time solution to a highly visible problem; a perceived permanent operational change is not expected. For systemic execution problems the issues tend to be insidious and behind the scenes, often not displaying an obvious specific project related fire to be put out. Operational change is assumed to be the solution in this situation.<br /><br />A new product team rallies to high profile fires very well, a concept that could be leveraged to deal with the more pervasive issues; the ones that are subtly, although more significantly impacting project execution. Does that mean solutions to the systemic issues are as close as setting them ablaze, thereby attaining much needed attention? That’s partially true with one very important caveat to consider. Solutions to systemic execution blockages will also involve “changes” in core processes and procedures, something that is rare in dealing with project specific issues. Individuals generally repel change, unless the change is elsewhere and will not directly impact them. <span style="font-style: italic;">Where are you and your organization with respect to seeking, owning and accepting real change?</span><br /><br />Here is the most important concept when dealing with change. Most individuals will internally believe in the statement<span style="font-weight: bold;"> “I want things to be different, but I don’t want to change.”</span> This is a stark reality that must be considered and mitigated. Once the realization of a potential personal change takes place, individuals will pull back and solution energy will fade. This fact leaves most organizations trapped in a mode of “tweaking” their new product development process, with results that provide unimpressive incremental improvements.<br /><br />Where dramatic improvement to new product time to revenue is an expectation, real change is the only enabler that will produce this level of results. This is possible only when organizations stop fooling themselves that they can “tweak” their way to significantly better new product revenue and begin a grass roots assault on the “historic” ways of doing things. Anything less is a smoke screen to protect individuals while placing the organization at risk of a slide towards extinction. Terminal sameness can be successfully reversed, if properly diagnosed and treated in time.Jeff Jorvig - IC Design Leaderhttp://www.blogger.com/profile/15518464303087106227noreply@blogger.com0tag:blogger.com,1999:blog-34363336.post-37875644094407992202010-03-31T08:57:00.003-07:002010-03-31T09:27:04.267-07:00The Antidote for Terminal SamenessEveryone has something they would like to see different, some aspect of the development process that they know is causing continuous disruption in new product releases. The frustration is obvious; the major steps to make it go away rarely occur, often smothered by a battery of excuses that keep a complete solution just out of reach. The fact is that a solution that involves significant change enables the most basic instinct – fear. That unchecked fear is keeping significant new product execution improvements from being realized.<br /><br />Does the following statement reflect your reality? <span style="font-weight: bold;">“I want things to be different, but I don’t want to change.”</span> If you are in alignment with the majority of the population then this is indeed a core belief of yours, although one that is definitely not publicly disclosed. This sentiment is the primary reason that new product execution stays pretty much the same. Maintaining an emotional bond to the comfortable known keeps valuable change out of the picture.<br /><br />New product execution remains in a status quo state not because of technical reasons, but because of a deep-rooted fear based anchor. Organizations are technically brilliant while failing at execution, simply because they are dinosaurs when it comes to engaging real change. If things are to be significantly different, there needs to be significant change! <span style="font-style: italic;">There is no other way; recognize that, deal with it and move forward.</span><br /><br />Harsh? Absolutely! Many organizations are perplexed by their inability to significantly improve new product efforts. In reality they have fallen into the pit of terminal sameness and are unable see the situation as anything but one of maintaining the status quo. The execution problems have consumed them. They are unable to get enough of a grasp on the big picture to see the major root issues that are siphoning off the teams productivity. So yes, I am being harsh, only in the hopes of jarring some brave souls to take a realistic view of the fears of change that are holding them back.<br /><br />To the right is a list of the most likely fear based reasons that keep people from changing. <a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://jorvigconsulting.com/newsletter/change_fears.gif"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 320px;" src="http://jorvigconsulting.com/newsletter/change_fears.gif" alt="" border="0" /></a>See them for the de-motivating fears that they are and move on. Risk-averse types will see these as solid barriers and continue to thrive on crisis management as the norm. Risk-takers will see these as hurdles to be dealt with, knowing a better way is on the other side. Where are you?<br /><br />Project execution stagnation is the norm today and the contenders for solutions have been an ever-increasing emphasis on the technical tools and methods for tweaking them to a higher productivity. How’s that been working out? Tweaking keeps the fear of change in check, while also failing to provide solutions that make a substantial impact in time to revenue. When ready to make a real difference it will require a real change, not a tweak.<br /><br />It’s imperative to honestly ask yourself if you are keeping things the same out of a fear of change. If this is the case you are unknowingly suppressing substantial improvements, so be real in your personal assessment. If you want things to be better, really better, then you along with everyone else will need to embrace change. The new mantra for your organization must be <span style="font-weight: bold;">“I want project execution to be significantly better and I am ready to accept substantial change as a solution”.</span> There is no shortcut! Fail to embrace change and your new product execution will continue to be consumed by terminal sameness, expect nothing different.<br /><br /><span style="font-style: italic;">“Again and again, the impossible problem is solved when we see that the problem is only a tough decision waiting to be made.”</span> -- Robert H. SchullerJeff Jorvig - IC Design Leaderhttp://www.blogger.com/profile/15518464303087106227noreply@blogger.com0tag:blogger.com,1999:blog-34363336.post-71575076617749502602010-03-15T11:06:00.002-07:002010-03-15T11:10:43.502-07:00Tools are “a” Solution, not “the” SolutionThe tools we have available today for producing chips have advanced a long way over the years. There is no question of the tremendous value they bring to new product development (NPD) teams. Even with all this capability at our disposal there are frequent problems in meeting new product revenue plans. How can this be?<br /><br />Maybe our expectations have reached an unhealthy dependency on tools for project management, design, verifications, validation and even overall product management. We are a proud family of techno-geeks and it is our nature to depend on technology, a reliance that is blinding us to non-technical root issues. Maybe it is time to consider the possibility of gaps between what technology provides and the needs of the team. When a problem has shown itself during a project, how often is it pinned on the tools or the improper inputs to a tool? How long will we continue blaming tools and then wonder why a predictable path to new product revenue remains out of reach?<br /><br />If projects have systemic and repeating barriers to predictable execution then there is something missing. There are issues just out of view that are not being addressed. In situations like this consider that the team members are not getting what they need to be individually successful. This unseen gap is rarely about a tool, but a lack in information such as project requirements, individual requirements, and deliverable expectations to name a few. Gaining insight into the individual success deficiencies that are quietly siphoning the teams effectiveness is essential.<br /><br />How do you find them? Ask each member of your NPD team the following question in a one on one setting: <span style="font-weight: bold;">"What changes in deliverables to you or additional information would improve your ability to complete your tasks?"</span> Now learn by listening and “hearing” the answer. Continue digging deeper until you believe the root issue has been uncovered. Address what has been learned. This is an example of <span style="font-style: italic;">“Plain Old Management Style”</span> (POMS) at work; no tool or methodology will provide the wealth of information that can be learned by this simple technique.<br /><br />New product projects are not only about managing schedules, risk, technology, tools, budgets and data; they must also include management of the most variable, unpredictable and challenging component of all - the people. Recognize this and new product opportunity will flourish, deny this and become a dinosaur entombed in technology. New product execution excellence is a people thing and practicing a <span style="font-style: italic;">“Plain Old Management Style”</span> is certain to produce positive impact, where a pure reliance on tools has not.Jeff Jorvig - IC Design Leaderhttp://www.blogger.com/profile/15518464303087106227noreply@blogger.com0tag:blogger.com,1999:blog-34363336.post-87508364045225422482010-02-26T16:31:00.012-07:002010-03-01T10:28:50.650-07:00Requirements Closure - Stop being held HostageNew Product Requirements Closure - something that everyone has hopes would go smoother, however inevitably drags on longer than planned and is often lacking the quality that prevents frequent revisiting of items assumed to be closed. Crisp requirements closure is one of the most significant issues I hear about, yet it receives the least amount of attention to resolve. Cost associated with delayed and/or low quality requirements should command significant attention, nevertheless organizations continue to be held hostage as the new product team battles it's way out of gridlock. It's time to release the new product requirements hostages!<br /><br />First off, when you consider requirements closure what comes to mind? It has multiple definitions and the one that you are most familiar with generally depends on which functional area you are supporting for a new product. There are typically several types of requirements that are strung together, providing a <span class="blsp-spelling-error" id="SPELLING_ERROR_0">roadmap</span> from product scope through production release. <a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://jorvigconsulting.com/newsletter/requirements_cycle.gif"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 320px;" src="http://jorvigconsulting.com/newsletter/requirements_cycle.gif" alt="" border="0" /></a>Examples of the most common requirements forms include customer, system, engineering, test, chip and module. Further complicating the situation is the fact that there are several owners supporting closure of each level of requirements.<br /><br />Critical to on time product release is one strategic concept - all the various levels of requirements must be in alignment early in the development cycle and stay in synchronization throughout it. The cost associated with requirements confusion is huge and most organizations are in denial about the level of impact this has to new product execution. Once the reality of requirements confusion influence sets in there are several approaches that can be considered to address this.<br /><br /><span style="font-weight: bold;">Manage the Requirement Process</span><br />Are you sure the process is being managed the best it can? If you really look into what's going on you will find that those responsible for a set of requirements are frequently in a holding pattern for one of two reasons. The first is that they are <span style="color: rgb(204, 0, 0);">waiting</span> for another set of requirements to be completed enough so they can get started. The second is that they are <span style="color: rgb(204, 0, 0);">waiting</span> for a decision.<br /><br /><span style="color: rgb(204, 0, 0);">Waiting</span> is the primary requirements closure killer and these nonproductive periods must be managed to keep things moving. Here's a question for your organization: Who owns "the" requirements process? Most likely the answer is many people and that is simply not working well, is it? There must be someone that owns the entire requirements process, a "requirements architect" if you will. In short - someone must manage the wait states, bring structure to the overall process, establish both a decision-making and change management procedure and use them religiously.<br /><br /><span style="font-weight: bold;">Analyze and Fix what's Broken</span><br />If requirements closure is dragging on and on there is clearly something broken. Do you know what it is? Where are the <span style="color: rgb(204, 0, 0);">wait</span> states and why are they there? With so many people involved there are ego issues, communication breakdowns, missed expectations and generally a lot of confusion and blame; all generating misguided reasons to <span style="color: rgb(204, 0, 0);">wait</span>.<br /><br />There must be an effort to find out what the systemic barriers are to smooth requirements closure and then remove them. Investigate and repair what is found. Nine times out of ten the largest contributors to closure will be people issues; yes it's not technology but good old communication difficulties between individuals that is enabling the need to <span style="color: rgb(204, 0, 0);">wait</span>.<br /><br /><span style="font-weight: bold;">Consider a Workshop Approach</span><br />A requirements workshop is an agile approach that brings much needed focus and gets everyone together to hash things out in an environment conducive to attaining prompt closure - the <span style="color: rgb(204, 0, 0);">wait</span> states are eliminated. <a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://jorvigconsulting.com/promotions/req_ws_flow.gif"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 320px;" src="http://jorvigconsulting.com/promotions/req_ws_flow.gif" alt="" border="0" /></a>A winning workshop is a well-planned event with <span class="blsp-spelling-error" id="SPELLING_ERROR_1">pre</span>-work, ground rules, a defined decision process and the right people getting together. A workshop is not throwing everyone in a room to roll up their shirtsleeves with orders to "figure it out" because the schedule is in jeopardy.<br /><br />Quality facilitation is the primary enabler of a workshop that meets expectations. Don't skimp on the skills of the facilitator; they must fully understand the process, drive the planning and <span class="blsp-spelling-error" id="SPELLING_ERROR_2">pre</span>-work, ensure proper attendees and guide the team through the decision process and ground rules generation. For a workshop that hits the mark, planning will be everything. The facilitator must in no way be a decision maker on any specific requirements; their role is to strictly keep things moving forward.<br /><br /><span style="font-weight: bold;">Tools</span><br />There are a number of tools that can help with the requirements process. I caution you in making any assumption that tools will be a fix-all for the issues you may be having. Any tools will augment a good requirements strategy; however will not fix what is broken. Most tools I am aware of target the software industry but could also be a great value to the semi biz. Here's a few links to get your started in your research:<br /><a href="http://www.volere.co.uk/tools.htm">http://www.volere.co.uk/tools.htm</a><br /><a href="http://gatherspace.com/">http://gatherspace.com/</a><br /><a href="http://www-01.ibm.com/software/awdtools/reqpro/">http://www-01.ibm.com/software/awdtools/reqpro/</a><br /><a href="http://www.accompa.com/index.html">http://www.accompa.com/index.html</a><br /><a href="http://www.sparxsystems.com.au/">http://www.sparxsystems.com.au/</a><br /><br /><span style="font-weight: bold;">Modeling</span><br />Writing and reviewing written requirements documents is pretty archaic in these days of high technology. We must get to electronic requirements (modeling) through the entire thread of requirements. Modeling is very common within the design domain but must be advanced into the marketing domain via an industry common language such as <span class="blsp-spelling-error" id="SPELLING_ERROR_3">UML</span> or more precisely <a href="http://www.sysmlforum.com/FAQ.htm"><span class="blsp-spelling-error" id="SPELLING_ERROR_4">SysML</span></a>. An emphasis on early modeling over written documentation also yields access to Agile methods, a very successful iterative approach in software product development. Isn't it time it time to advance the art here?<br /><br /><span style="font-weight: bold;">Final Thoughts</span><br />The requirements process can be improved significantly, although only if someone is in the drivers seat to make changes. I must emphasize again the need for a single point of requirements ownership, a requirements architect. This is the individual responsible for eliminating the <span style="font-weight: bold; color: rgb(204, 0, 0);">wait</span> states by enabling the flow of information and establishing focus for all requirements types. Skimp on responsibility here and closure will just float along as it has in the past. There is a better way and it begins with an owned <span style="color: rgb(204, 0, 0);">focus</span> on the full suite of new product requirements.Jeff Jorvig - IC Design Leaderhttp://www.blogger.com/profile/15518464303087106227noreply@blogger.com0tag:blogger.com,1999:blog-34363336.post-22703290374537693212010-02-18T09:23:00.003-07:002010-02-18T22:39:35.768-07:00It goes go on and on and on…How true is the following statement for you? <span style="font-style: italic;">“We are having problems with closure of requirements, some of our projects should have never been started, project scope control is out of control and of course we are missing production dates. Everyone misses dates and it’s not something we have any direct control over anyway because ….”</span><br /><br />I hear something like the statement above on a regular basis and it is always is followed up with some sort of validation as to why the situation has been this way for a long time. There is acknowledgement of a problem, there are unverified reasons for the situation, there is unwarranted acceptance and there is blame; action towards a solution is what’s frequently missing.<br /><br />I know, I know; everything is actually going fine, or at least OK and there is ongoing work for improvements in some areas. Here’s a test – pick a problem in your new product development process that is a nasty thorn for you. Now think back a year, did the problem exist then? Do you believe that 365 days from now that same unpleasant barb will be causing you aggravation? If you answered yes or maybe to both of these you are dealing with a known problem that has a lifetime of at least two years; now tell me why that isn’t totally unacceptable?<br /><br />Here’s what’s going on - the unresolved long-term problems continue disrupting projects because they are allowed to. Sure there are reasons, everyone has a reason and it will be one of money, resources or time. These are only excuses, the real reason is that an owner does not step forward and take action to make a known new product development issue go away. Issues lacking owners continue to thrive, creating frustration and impacting projects for a long time to come. I came across this quote recently that captures the ownership dilemma beautifully:<br /><br /><span style="font-style: italic;">“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.”</span><br /> -- Richard Bach<br /><br />When we stop trying to ensure new product development execution inefficiency is someone else’s responsibility and own the path to a solution, we will stop being victims of what is rarely fixed and often talked about. It’s well past the time to stop talking and take action to get one of those two year old plus problems off the table; you know just the one I am talking about. Are you ready to step into the light and own the solution or will you continue to be a distraught victim? It is a choice.Jeff Jorvig - IC Design Leaderhttp://www.blogger.com/profile/15518464303087106227noreply@blogger.com0tag:blogger.com,1999:blog-34363336.post-1960678984827247372010-02-02T06:37:00.008-07:002010-02-02T13:32:55.705-07:00Why your Internal IP Reuse Strategy is not WorkingInternal IP reuse is something that every business wants, although the current scorecard indicates these objectives are not being met. A fairly large gap exists between leadership's vision of an ideal internal IP reuse strategy and the implementations in place today. Management views IP reuse as an essential ingredient of quicker time to market while the design communities perceive it as a road plagued with dangerous potholes. <span style="font-style: italic;">Reality - continue overlooking the designer's needs and internal reuse will remain a distant vision.</span><br /><br />Every organization has some type of reuse activity going on. For some, they are content with their current approach in handling reuse. However, for the majority there is more effort required to achieve anything approaching an ideal set of reuse objectives. At the low end of reuse strategies, what I affectionately call Whack and Plop (WAP), is where IP blocks are excised out of an existing chip and dropped into a new design.<br /><br />A more desired implementation of reuse includes a full repository scheme where the designer can eagerly shop for IP and download it with a full suite of documentation, test benches and characterization data. This ideal vision of reuse is where most want to be, some form of WAP is where most are today.<br /><br />So what's keeping reuse in the dark ages? It is simply that the needs of the re-user are not being attended to, technology is in charge instead of the needs of potential end users. The fears of reuse are not being addressed and the design community is pushing back because the deliverables associated with IP are not mitigating these concerns. Without proper IP content designers will only reuse what they are comfortable with, either their own work or someone else's work that they respect and have easy access to. The major hurdle today is in achieving a level of IP deliverable content that will diminish the fears of reuse, thus allowing designers to develop the confidence to favor formal IP reuse over WAP or the initiation of a new design.<br /><br /><span style="font-weight: bold;font-size:130%;" >First Rule of IP reuse - Content Rules</span><br />It's not the repository that will cinch reuse; it's the content deliverables for specific IP. If a designer digs through a wonderfully crafted repository, downloads the deliverables and finds <a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://jorvigconsulting.com/newsletter/ip_content.gif"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 320px;" src="http://jorvigconsulting.com/newsletter/ip_content.gif" alt="" border="0" /></a>a deficiency in IP content, you have lost them for a very long time. Start with content, not a fancy repository; <span style="font-style: italic;">content is the foundation of any IP reuse growth strategy.</span><br /><br />The worst implementations will be those that are developed solely by a team of non-designers that are great with software. Keep in mind that reuse enablement is not a software or EDA task; it is a deliverable content development task to provide the essential design collateral designers must have to be able to validate and gain confidence in another designers work.<br /><br /><span style="font-weight: bold;font-size:130%;" >Second rule of IP Reuse - Address Reuse Concerns</span><br />Know what the concerns of reuse are and address them. Talk to your design community and make sure you understand both what would enable them to reuse and what would turn them off. This is as simple as listening and applying what is learned. Leave this vital process out and you may as well stay with a WAP reuse strategy; you will be wasting time and money trying to make it work. You can lead a horse to water but you can't make him drink; the solution is finding out what will make him want to drink.<br /><br /><span style="font-weight: bold;font-size:130%;" >Third Rule of IP Reuse - Marketing Strategy</span><br />Develop a marketing strategy to define and roll out the internal reuse implementation. Consider this as a product with customers that need to be wowed. The designer's are not generally a captive audience where reuse has been legislated, therefore it is essential you properly market IP as a product. A proper marketing strategy will also drive closure on the first two rules of IP reuse - giving customers what they need.<br /><br />Consider the following:<br /><ul><li> Appeal - Why would someone want to use it?</li><li> History - Has it been used before? Where? Any data?</li><li> Features - Overly complex or not enough bells and whistles.</li><li> Options - Does it need configuration options to cover a broader design space?</li></ul><span style="font-weight: bold;font-size:130%;" >Fourth Rule of IP Reuse - Only Quality in Repository</span><br />After the first three rules have been addressed it's time to put the IP into a repository. I suggest something pretty simple since there is not likely going to be a large initial offering. The repository can be enhanced over time as you get feedback from the users. A word of warning - don't put anything in the repository that does not meet the first two rules. Any perception of garbage in the repository will ruin your efforts for a long time. Remember - Content rules! <span style="font-style: italic;">The repository leaves a short term impression, what the designers receive from it leaves a long term impression.</span><br /><br /><span style="font-weight: bold;font-size:130%;" >Closing thoughts on Internal Reuse</span><br /><ul><li><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://jorvigconsulting.com/newsletter/ip_focus.gif"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 290px;" src="http://jorvigconsulting.com/newsletter/ip_focus.gif" alt="" border="0" /></a>The end user will make or break your reuse strategy. It is paramount to understand what will "make it work" for them.</li><li>Think first about what is needed... the deliverable content.</li><li> The repository will leave a short-term impression on the end users. The IP deliverable content impression will last a lifetime. Focus on what matters!</li><li> Creating reusable IP should not be much more effort than a good, high quality design effort!</li><li> Reuse content will need to be kept current based on silicon usage and tool updates. Don't ignore or underestimate your work here.</li><li> Reuse enablement requires the matching of re-user needs with cataloged content.</li></ul>Jeff Jorvig - IC Design Leaderhttp://www.blogger.com/profile/15518464303087106227noreply@blogger.com2tag:blogger.com,1999:blog-34363336.post-20523562674582319742010-01-25T05:43:00.001-07:002010-01-25T05:46:54.431-07:00What are the Incentives for Improving the Development Process?A truth – project execution today has many of the same symptoms we have been dealing with for many years. We are still routinely facing delays; projects are riddled with unpredictability and there is a lacking sense of urgency in affecting changes that result in execution improvements. Everyone will have a reason for this progress plateau - likely to revolve around a lack of time/money, a lack of ownership or limited jurisdiction to bring about change. All of these mask the core reason - a lack of incentive to do more. There really is no substantial motivation to improve. The reward system in place today firmly establishes the status quo as an acceptable means of chip project delivery.<br /><br />A new product success or failure can significantly impact a business, however has little financial effect on the resources responsible for delivering the product. Sure, there are bonus programs in place to reward success, however they typically provide a level of potential income that is considered “expendable”. So I ask again, where is the motivation for a team to continually drive sustainable improvements in the way projects are executed? The system we have today is not enabling the essential synergistic energy that results from strong alignment to a common personal objective.<br /><br />Maybe we need to emphasize more reward for meeting success objectives and less for just putting in time. Essentially sharing in both the wins and the losses. I am sure the thought of tampering with the sacred “pay for time” model makes the hair stand up on the back your neck. Radical – oh yes, but then the alternative is new product delivery staying pretty much the same as it is, the same as it has been for a long time. It may be time to consider alternatives to the current financial incentive system, an area that has traditionally been hands off. How much money is wasted on unsuccessful and delayed products? This figure can help quantify the pool available for success sharing.<br /><br />Think about the possibilities for objectives, collaboration, planning, productivity, execution, decision-making and product approvals where notable financial rewards are at stake. The “not my responsibility” claims will be replaced with a self-managing mentality of working smarter together towards product success. Listen to the thoughts going through your mind as to why this will not work; reasons such as “I have no impact outside my functional area” or “It’s not my job” or “That’s not my decision” probably cross your mind. These are the very same items that have been keeping things as they are; the self-imposed boundaries of responsibility for project delivery.<br /><br />Everyone has a jurisdictional border; the safe zone that allows localized success, even in the face of project failure. Product launch decisions, specifications, tool deployment, tapeout, characterization and qualification are all examples of localized success within a safe zone. These borders have existed forever, methodologies and tools have had minimal impact on them because it’s a people thing; technology simply does not solve emotional people things. For new product execution to accelerate beyond the current plateau state, the age-old safe zones must be eliminated. A synergistic “common cause” mentality must rule project decisions and direction. If a change to the financial reward model would not do this, then what would?Jeff Jorvig - IC Design Leaderhttp://www.blogger.com/profile/15518464303087106227noreply@blogger.com0tag:blogger.com,1999:blog-34363336.post-14604143667035933122009-12-30T18:08:00.020-07:002010-05-27T11:07:29.890-07:00Six Issues that will Inhibit Profitable Growth in 2010 - Be ReadyWelcome 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.<br /><br />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?<br /><br /><span style="color: rgb(204, 0, 0); font-weight: bold;">Focusing on Cost more than Revenue Generation</span><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://jorvigconsulting.com/newsletter/cost_or_investment.gif"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 320px;" src="http://jorvigconsulting.com/newsletter/cost_or_investment.gif" alt="" border="0" /></a>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. <span style="font-style: italic; color: rgb(204, 0, 0);">Consider not the cost of fixing something, but the cost of not fixing something.</span> 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.<br /><br /><span style="font-weight: bold; color: rgb(204, 0, 0);">Who Owns the NPD Process?</span><br />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. <span style="font-style: italic; color: rgb(204, 0, 0);">Is the owner of your total development process implied or explicitly identified?</span> 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!<br /><br /><span style="font-weight: bold; color: rgb(204, 0, 0);">Limited Organizational Learning</span><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://jorvigconsulting.com/newsletter/learning_cycle.gif"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 300px;" src="http://jorvigconsulting.com/newsletter/learning_cycle.gif" alt="" border="0" /></a>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. <span style="font-style: italic; color: rgb(204, 0, 0);">Learn to learn and prosper, or fail to learn and "try" to catch up later.</span> Proactive or reactive; it really is a choice.<br /><br /><span style="font-weight: bold; color: rgb(204, 0, 0);">Overdependence on Tools and Methods as the Solution</span><br />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. <span style="font-style: italic; color: rgb(204, 0, 0);">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.</span> 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!<br /><br /><span style="font-weight: bold; color: rgb(204, 0, 0);">Acceptance of Schedule Failures</span><br />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. <span style="font-style: italic; color: rgb(204, 0, 0);">Tolerance will always breed inaction; either a schedule is gold or it is coal - what's it to be?</span><br /><br /><span style="font-weight: bold; color: rgb(204, 0, 0);">Living in the Problem, not the Solution</span><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://jorvigconsulting.com/newsletter/successful_change.gif"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 300px;" src="http://jorvigconsulting.com/newsletter/successful_change.gif" alt="" border="0" /></a>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? <span style="font-style: italic; color: rgb(204, 0, 0);">Why isn't now the perfect time to move from an incessant discussion about the problem to getting it solved? </span>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!<br /><br />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?Jeff Jorvig - IC Design Leaderhttp://www.blogger.com/profile/15518464303087106227noreply@blogger.com0tag:blogger.com,1999:blog-34363336.post-78140501773489803162009-12-15T08:47:00.003-07:002009-12-15T08:53:07.526-07:00Mixed Signal Success Requires the Voice of Analog DesignersWhen 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?<br /><br />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.<br /><br />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?<br /><br />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?<br /><br />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.<br /><br />Below are a few simple concepts to align our industry with a mixed signal success solution.<br /><ul><li><span style="font-weight: bold;">Analog & Mixed signal EDA vendors and support types –</span> be sure you spend more time talking to analog designers than each other; they are the customers.</li><li><span style="font-weight: bold;">Digital designers –</span> 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.</li><li><span style="font-weight: bold;">Analog Designers –</span> 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.</li></ul>We must fully engage the analog design community in the solution of first time success for mixed signal design. <span style="font-style: italic;">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.</span> This is attainable only by dissolving the barriers between the two design worlds; it’s a people thing.Jeff Jorvig - IC Design Leaderhttp://www.blogger.com/profile/15518464303087106227noreply@blogger.com0tag:blogger.com,1999:blog-34363336.post-78110721365152170012009-12-10T05:07:00.002-07:002009-12-10T05:15:49.244-07:00Solution Strategies for Solving Systemic IssuesI 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.<br /><br />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.<br /><br /><span style="font-weight: bold;">Brainstorming</span><br />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.<br /><br /><span style="font-weight: bold;">Interviews</span><br />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.<br /><br /><span style="font-weight: bold;">Outside Assistance</span><br />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.<br /><br /><span style="color: rgb(204, 0, 0); font-weight: bold;">My short rule for successful solutions to nagging issues:</span> Inclusion over exclusion of people, broad functional area participation and an open atmosphere that focuses on the solutions, not bemoaning the problem.Jeff Jorvig - IC Design Leaderhttp://www.blogger.com/profile/15518464303087106227noreply@blogger.com0tag:blogger.com,1999:blog-34363336.post-16640310490427167872009-12-02T15:21:00.004-07:002009-12-02T15:26:13.419-07:00Enabling the Decision to Invest in a SolutionI 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.<br /><br />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.<br /><br />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. <a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://jorvigconsulting.com/newsletter/dec_09_1.gif"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 300px;" src="http://jorvigconsulting.com/newsletter/dec_09_1.gif" alt="" border="0" /></a>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.<br /><br />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.<br /><br />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.Jeff Jorvig - IC Design Leaderhttp://www.blogger.com/profile/15518464303087106227noreply@blogger.com0