Matrix Organizations Fail at Fixing Broad Systemic Execution Issues

A 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.

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!

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.

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!

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.

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.

GM --> Focus on new product quantity, Apple --> Focus on new product quality. Where is your new product organization? Think about it!

Seven Signs of Trouble in New Product Execution

What 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.

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.

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.

1) The Team says it's not OK -
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.

2) Execution issues are never expressed as a cost -
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.

3) Timeline slips to production revenue are routinely greater than 6 weeks -
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.

4) Revenue targets are missed on greater than 20% of products -
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.

5) Discussions and meetings about a suspected problem for over a year -
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.

6) Everything is urgent, except driving change so that everything is no longer urgent -
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.

7) There is a belief that formal project management inherently takes care of execution issues -
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.

"You don't drown by falling in the water; you drown by staying there."
- Edwin Louis Cole

8 Habits of a Highly Successful New Product Organization

Our 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.

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.


Learning
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.


Listening
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.


Evolving
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.


Clarity
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.


Personal
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.


Decisiveness
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.


Planning
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.


Product Launches
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.


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. Go forth and change!

Delivering Lean and Mean New Product Development

Most 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. 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.

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.

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.

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.

Value
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. You must be absolutely certain of what the customer values in a relationship with you on new product. Delivering all aspects of customer value is a distinct competitive advantage.

Identify Value Stream
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?

Create Value Flow
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.

Establish Pull
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!

Seek perfection
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. Lean NPD is a journey, not a destination.

New Product Execution - It's Just not Good Enough

New 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.

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.

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.

An Execution Strategy is Missing
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:

• Regular questioning of why things are done as they are.
• The regular application of learning from past products.
• A participant scope that includes all functional areas.
• Embraces dynamic planning.
• A shared vision of what ideal execution looks like.
• Cover all activities from concept through revenue.

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.

Execution Scope is far too Narrow
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.

Unacceptable New Product Success Ratio
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.

Failing to find what is Unknown
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"

Tools for Enabling Collaborative Environments

What 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.

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. 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.

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.

Scheduling & Managing the Process
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?

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 PIEmatrix due to its slice concept, allowing the establishment of predefined best practices for each NPD role.

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 saleforce.com and allowed their sensitive customer relationship data outside the firewall.

Chat
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.

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.

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 http://xmpp.org for client/server possibilities.

Brainstorming
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 last month's posting for more information on mind mapping.

Collaboration or Extinction
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.

Is 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 “terminal sameness”!

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?

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.

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.

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, it is their primary role.

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!

Wonders of Mind Mapping in New Product Development

Ever 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.

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.

What is a Mind Map?
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.

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.

What Mind Map Tools are Available?
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.

Where can Mind Maps be used in the Semiconductor Biz?
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.

Requirements Gathering
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.

The Product Development Process
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.

Product Portfolio
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.

Project Definition
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.

Are you a Mind Map Type?
Now the test - 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!

Survey – How is Internal EDA Support Utilized

The link below is a survey to identify how your organization is utilizing internal EDA resources, what your expectations are of internal support along with your level of satisfaction. Once you complete the 5-10 minute survey you will be presented with a link to monitor results. Final results will be published here on this blog. Many thanks to those who choose to participate.

Off to the Survey

Is New Product Development Dysfunctional?

So how should the question “Is the New Product Development (NPD) effort dysfunctional” 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. Simply asked - Is the NPD development process broken or not?

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.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.

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.

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!

It’s time to get real about assessing the process of bringing new products to market. Honestly answer the question “Is the new product development effort dysfunctional?” Fully understand the “why” of each key indicator of a busted development process by drilling down and uncovering all 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.

I 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. 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.

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. 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!

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 "Your kids are your own fault" 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. Fact - we are personally responsible for creating and maintaining our work situation as it is today.

If something is impacting your ability to perform your tasks and it's ticking you off, own it as your problem to be resolved and take the initiative to make it go away! Sorry people, but that's the only way things are going to change for you. Stop waiting for someone else to notice how something is impacting your ability to execute and fix it for you. 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.

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. 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?

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. 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. This one is yours!

I want things to be Different, but I don’t want to Change

Everyone 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.

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.

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.

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. Where are you and your organization with respect to seeking, owning and accepting real change?

Here is the most important concept when dealing with change. Most individuals will internally believe in the statement “I want things to be different, but I don’t want to change.” 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.

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.

The Antidote for Terminal Sameness

Everyone 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.

Does the following statement reflect your reality? “I want things to be different, but I don’t want to change.” 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.

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! There is no other way; recognize that, deal with it and move forward.

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.

To the right is a list of the most likely fear based reasons that keep people from changing. 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?

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.

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 “I want project execution to be significantly better and I am ready to accept substantial change as a solution”. There is no shortcut! Fail to embrace change and your new product execution will continue to be consumed by terminal sameness, expect nothing different.

“Again and again, the impossible problem is solved when we see that the problem is only a tough decision waiting to be made.” -- Robert H. Schuller

Tools are “a” Solution, not “the” Solution

The 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?

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?

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.

How do you find them? Ask each member of your NPD team the following question in a one on one setting: "What changes in deliverables to you or additional information would improve your ability to complete your tasks?" 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 “Plain Old Management Style” (POMS) at work; no tool or methodology will provide the wealth of information that can be learned by this simple technique.

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 “Plain Old Management Style” is certain to produce positive impact, where a pure reliance on tools has not.

Requirements Closure - Stop being held Hostage

New 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!

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 roadmap from product scope through production release. 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.

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.

Manage the Requirement Process
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 waiting for another set of requirements to be completed enough so they can get started. The second is that they are waiting for a decision.

Waiting 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.

Analyze and Fix what's Broken
If requirements closure is dragging on and on there is clearly something broken. Do you know what it is? Where are the wait 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 wait.

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 wait.

Consider a Workshop Approach
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 wait states are eliminated. A winning workshop is a well-planned event with pre-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.

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 pre-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.

Tools
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:
http://www.volere.co.uk/tools.htm
http://gatherspace.com/
http://www-01.ibm.com/software/awdtools/reqpro/
http://www.accompa.com/index.html
http://www.sparxsystems.com.au/

Modeling
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 UML or more precisely SysML. 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?

Final Thoughts
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 wait 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 focus on the full suite of new product requirements.

It goes go on and on and on…

How true is the following statement for you? “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 ….”

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.

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?

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:

“If it's never our fault, we can't take responsibility for it. If we can't take responsibility for it, we'll always be its victim.”
-- Richard Bach

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.

Why your Internal IP Reuse Strategy is not Working

Internal 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. Reality - continue overlooking the designer's needs and internal reuse will remain a distant vision.

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.

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.

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.

First Rule of IP reuse - Content Rules
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 deficiency in IP content, you have lost them for a very long time. Start with content, not a fancy repository; content is the foundation of any IP reuse growth strategy.

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.

Second rule of IP Reuse - Address Reuse Concerns
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.

Third Rule of IP Reuse - Marketing Strategy
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.

Consider the following:

• Appeal - Why would someone want to use it?
• History - Has it been used before? Where? Any data?
• Features - Overly complex or not enough bells and whistles.
• Options - Does it need configuration options to cover a broader design space?

Fourth Rule of IP Reuse - Only Quality in Repository
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! The repository leaves a short term impression, what the designers receive from it leaves a long term impression.

Closing thoughts on Internal Reuse

• The end user will make or break your reuse strategy. It is paramount to understand what will "make it work" for them.
• Think first about what is needed... the deliverable content.
• 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!
• Creating reusable IP should not be much more effort than a good, high quality design effort!
• Reuse content will need to be kept current based on silicon usage and tool updates. Don't ignore or underestimate your work here.
• Reuse enablement requires the matching of re-user needs with cataloged content.

What 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.

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.

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.

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.

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?