Coaching Excellence in NPD Teams

It's not what you know; It's what you do

2011-05-27T07:15:00.000-07:00

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

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.

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. The lack of knowledge in the application of techniques that enable positive changes coupled with a fear of failure is the real barrier here.
Everything that holds back progress is pure FUDD (Fear Uncertainty Doubt and Disinformation).

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.

Time

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.

People

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.

Cost

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?

Not my Area or Problem

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.

You

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!

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. It's not what you know; it's what you do.

It's Always a Failure to Communicate

2011-02-02T10:50:00.001-07:00

A failure to communicate is the root of any issue with new product execution; yes ANY issue! 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.

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.

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.

How would you define successful communication? Below is my list of attributes that are essential for high quality communication:

Communication is two way, meaning there must be a mechanism for ensuring proper transmission; always full duplex mode.
Effective communication must provide a forum for debate to allow hidden issues or concerns to bubble up.
A high quality communication strategy never assumes physical proximity will be "the" solution to interaction issues.
An ideal communication implementation will remove barriers that inhibit contact between any two individuals.
The sources of specific information are singular, explicit and electronic for enablement of clarity in communication.

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.

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.

So I sign-off with the famous clip from the 1967 movie Cool Hand Luke - "What we have here is (a) failure to communicate".

2011 - Concepts for Really Making a Difference

2011-01-03T14:10:00.000-07:00

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

Current Situation

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.

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.

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.

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?

Delivering Change in 2011

The following concepts outline the typical gaps that I have noted in addressing long term new product execution issues.

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

Cost of Current Situation
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.

Involve the Team
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.

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

Avoid Tool Exclusivity
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.

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!

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

-- Mac Anderson

Matrix Organizations Fail at Fixing Broad Systemic Execution Issues

2010-11-30T10:40:00.004-07:00

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

2010-10-29T10:32:00.004-07:00

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

2010-10-04T12:24:00.007-07:00

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

2010-09-01T09:43:00.003-07:00

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

2010-07-29T08:40:00.006-07:00

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

2010-06-30T18:44:00.006-07:00

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?

2010-06-18T09:47:00.002-07:00

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

2010-05-27T10:50:00.006-07:00

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

2010-05-14T05:38:00.002-07:00

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?

2010-05-12T09:48:00.004-07:00

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

2010-04-29T11:54:00.005-07:00

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

2010-04-13T09:46:00.002-07:00

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

2010-03-31T08:57:00.003-07:00

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

2010-03-15T11:06:00.002-07:00

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

2010-02-26T16:31:00.012-07:00

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…

2010-02-18T09:23:00.003-07:00

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

2010-02-02T06:37:00.008-07:00

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?

2010-01-25T05:43:00.001-07:00

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?

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

2009-12-30T18:08:00.020-07:00

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

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

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

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

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

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

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

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

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

Mixed Signal Success Requires the Voice of Analog Designers

2009-12-15T08:47:00.003-07:00

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

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

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

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

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

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

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

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

Solution Strategies for Solving Systemic Issues

2009-12-10T05:07:00.002-07:00

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

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

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

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

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

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

Enabling the Decision to Invest in a Solution

2009-12-02T15:21:00.004-07:00

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

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

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

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

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

The NIH Factor may be Putting your Business in Peril

2009-11-23T05:41:00.001-07:00

We are all aware of the existence of the NIH (Not Invented Here) factor, where open-minded judgment is overshadowed by a misguided emotional stance to keep things as they are. It is often talked about it in 3rd person, as if only exhibited “somewhere else” in the organization. Any evidence of its existence is regularly swept under the rug; it’s considered a reality of business in the engineering world. What price is paid when the NIH factor is allowed to routinely guide decisions about products, processes and ideas?

NIH is inversely proportional to an organizations creative ability. The more NIH is allowed to prosper, the less an organization will push the bounds of revolutionary discoveries. Left unchecked, NIH can lead to a stale organization where the imaginative juices stall, eventually leading to creative bankruptcy. Contemplate the US automakers current situation – NIH undoubtedly played a significant role.

The truth is it’s difficult to directly monitor the existence of the NIH factor and it’s impact on a business. However, consider that the same forces that enable an aversion to continuous improvement are also at work to drive up the NIH factor. Evangelize continuous improvement principals as a way of life, and NIH becomes a non-issue. An organization plagued with NIH is certain to have a culture where the status quo is an accepted approach to New Product Development.

As a leader, your teams will follow by example; they will align with your displayed support or opposition of practices that diminish NIH. What do they see? Your true motives will come through load and clear, accordingly it’s essential that you pay close attention to the reasons behind decisions. Stay on the lookout for decisions that were made out of a need to feel comfortable about a path of action. Comfortable usually means a familiar coarse of activity, one that is often repeated and perceived to carry limited risk; one that is also likely brimming with a healthy dose of NIH.

Where is your organization on the NIH culture scale? Not knowing is passive ignorance, not trying to find out is dangerous and not doing something about persistent NIH is disastrous. Once more, contemplate the US auto industries NIH affliction. Too big to fail – think again!

Concepts for Improving New Product Transparency

2009-11-13T07:21:00.002-07:00

Transparency - Ensuring everyone has the information that allows them to maximize their contribution and enable informed decisions for the ultimate success of a project. Unpredictability will always be the result of a constriction in information, where transparency has not been a priority. Below are some thoughts on mechanisms that will pump of project transparency.

Visible Milestones
You don't want your team fishing around for key milestones. Take the key dates such as tapeout, 1st Si, characterization and product ramp and post them - BIG. You can see them from across the room size. As a project approaches a key milestone, post it on doors as they enter the area. This stuff is not a secret and there is no excuse for everyone on the team not knowing what the next key project event is.

Workflow Management
There must be an easily accessible mechanism where the team can go to find out where things are at, specifics on deliverables and the best practices for the project. This is not a set of documentation gathering dust on the shelves, or a rarely accessed read only file wasting space on a hard drive. It is an interactive guide for the team's activities where the user is adding value to the content in addition to seeking best practices guidance and deliverable expectations. PIEmatrix is at the top of the list for this application followed by Design Guides.

Bi-Directional Project Meetings
Make sure there is more to routine project meetings than updating status and directing activities. Don't forget to listen - where are the areas of concern from the team and what can you collectively do about them. This is promoting upward transparency from the team to leadership and will only provide continuing results where the team realizes actual benefit. Encourage open communication and problem solving and reap upward transparency rewards on a long-term basis.

There are many other possibilities for improving transparency. Bear in mind that the objective is that no one is ever surprised, from the lower levels all the way to the top. Ponder what can be done to enable this goal. Best of luck and may transparency prosper and deliver the new product development predictability that your business requires.

How Limited Transparency Impacts New Product Efforts

2009-11-03T18:14:00.005-07:00

Project transparency - What thoughts do you have about this for your organization? Transparency is a mechanism that facilitates information flow both up and down through the project hierarchy - a means to observe status and decisions while also delivering essential information to the members of the team. Contemplate heightened transparency as an enabler of predicable new product development efforts. If New Product Development (NPD) surprises are common to your business, there are issues with project transparency that must be resolved.

When thinking about transparency for a new product development effort, do you believe it's a problem for your organization? Here's a simple test, pick some in the trenches team members at random and ask them something you believe they should know about a project. Questions like tapeout, characterization or qualification planned dates are simple yet revealing. For a bit more of a challenge you might try a question about inclusion of a specific feature that has recently been in a state of flux and is now resolved. Does the team accurately know the decision of that feature? Odds are high that you will be surprised at what team members should know, but don't. These are a few examples of easier project transparency issues.

How visible is a project when in the early stages of assessment, the period from product concept through a decision to launch or drop a product development effort? Having broad based input on risks, scope and effort is critical for a fully informed decision. This is certainly not the time for a project to be out of view. How many times has a sanctioned product been killed, significantly delayed or has failed to realize financial objectives? An unacceptable success rate is a solid indicator of deficient transparency during the vital new product assessment phases. For failed projects, something largely unknown (invisible) did not have the opportunity to surface during the new product consideration phases.

How often does a completed activity need to be reworked? Yes, you guessed it - rework is another example of inadequate transparency. In this case an individual did not have access to the current information they needed to successfully complete and/or properly deliver their contribution. A high rate of revisiting completed activities should be another flag that there is work to be done for improving transparency of project activities.

Why would an improvement in transparency ever be bad? Maybe when attempting to keep a thorny issue under wraps, typically hiding it from someone who will have an opinion we don't want to deal with. So, how has that worked out in the past? Limiting transparency to avoid conflict rarely leads to a project success story. Full disclosure real time keeps us all honest and ensures that a new product does not end up a victim of unrealistic expectations. If you find that there is an item that you prefer to de-emphasize, that is a flag that it's time examine your motives.

The benefit of expanded transparency is hard to argue. Be open, be honest and be prepared for ideas, concepts and opinions that make you squirm. Hanging out in the comfort zone is not a place where product excellence is nurtured.

Organizational Silos - The Enemy of Project Execution

2009-10-23T05:26:00.003-07:00

So how are projects working out for you? I ask this question frequently, to just about everyone I talk to in a professional setting. And the most common answer is – “We are doing OK”. If I take the same question and pose it in a fashion such that the focus is in a different functional area from the individual I am asking, the answer is entirely different. Apparently there is much more to say when talking about how project execution is going outside a person’s sphere of responsibility. Translation – “We are doing OK, but those people over in ______ need to get their act together.” This is human nature, although amplified by the organizational structures in place today.

Consider that collaboration blockages flourish through the functional silo based organizational configuration. Even though matrix project teams are widely used, allegiance of each individual remains within their organizational unit. Why? Loyalty naturally rests at the source of performance reviews, personal objectives, raises and functional area workflows. An individual on a matrix team will primarily be measured, directed and rewarded based on solid line organizational reporting. However, the business success depends on the effectiveness of the temporary matrix reporting within a given project. This is a major disconnect!

Who is ultimately in charge of a projects success or failure - where is the accountability for a project? Project execution responsibility typically rests with the project manager, however they are often lacking the full breadth of authority to carry through. Additionally they are generally not fully skilled and/or sanctioned to gauge and direct the sub-flow details within each of the silos. The functional area towers have the skills for the detailed sub-flows, although they typically lack the formal project management skills or motivation to properly assess and plan a sub-project. This is a system that is ripe for finger pointing, blame, collaborative blockages and ownership issues.

Fact - the current project system is not providing the full spectrum of results businesses require. The organizational silos believe they are doing OK, while the businesses experience an element of unpredictability; leading to surprises and delays on the path to new product revenue. Given this, it may well be time to step back and take an honest look at the mechanics of current project delivery. Business success dictates that we engineer a system that promotes accountability and collaboration, addresses individual project skill gaps, and measures/rewards contribution based on enabling project revenue success.

The current project management strategies have been in place for greater than 15 years and have provided significant benefit to new product development. Advancing to the next generation of project delivery will require that the walls of the organizational silos come down and a structure based on project execution be constructed, collaboratively stitching the functional areas together. Are you in this race to win, or are you in the race to hang with the pack - Isn’t it time for change?

Short Project Execution Survey - See Results Upon Completion

2009-10-15T08:55:00.004-07:00

I would like to ask for your help by completing a survey to provide visibility into the project execution barriers our industry faces. This short five minute survey is targeted at providing insight into the barriers to project execution and why they may not be resolved. Once completed you will be provided a link that will allow you to monitor the anonymous results, giving you a view of the project challenges your counterparts face in the semiconductor industry.

Please, only proceed with the survey if your business is related to semiconductor product development. Thank you for your valuable time!

Off to the survey

Using the Project Premortem to Identify Risk Areas

2009-10-12T09:57:00.002-07:00

Last week I came across an article titled Performing a Project Premortem written by Gary Klein of Applied Research Associates. The commentary presented the concept of a project Premortem to aid in identifying the potential project roadblocks, before they have a chance of derailing the project. It is essentially risk assessment, although with a procedural twist that holds merit. The premortem is a forum for airing the project execution concerns of the team. Having always been a fan of going in the trenches to ask the team what's not working, this aligned well with my strategy of discovering the unknown.

What could possibly go wrong? Answering this requires an understanding of the possible "what-if" situations while in the planning phase of a new project. It's about risk management and the ability to uncover a comprehensive set of possible negative scenarios and prioritizing them, dismissing some and mitigating others. Assessing technical risk is common; assessing project execution risk is far less likely to be addressed.

An unknown risk to a project will lead to an element of unpredictability, if it becomes a reality. There would not be any forethought of the possibility; therefore there would obviously not be a mitigation plan in place. The team runs into a brick wall and then regroups to find a way to navigate around the wall. A well conceived plan is suddenly thrown off track because a risk was not identified during the planning stages.

Now back to the project premortem. The idea is to establish an environment that allows the team ferret out all the possible risk areas. The premortem concept enables the successful identification of risk via the following principals:

Establish a mechanism for soliciting inputs from a broad cross section of the team.
Seek out the worker bees in addition to those in the management hierarchy.
Create a non-threatening environment that is comfortable for the team's voice to be heard.
Listen with an open mind, saving judgment for later.

Consider hosting a premortem activity while in the planning phase of projects to provide a regular opportunity to seek out risks and get them on the table. Through a routine emphasis on this risk assessment process the team becomes confident there will be a place for concerns to be aired and addressed, thus enabling them the opportunity to optimize their project contribution. For your next project utilize a premortem to find the answer to "What could possibly go wrong?" and realize a new level of predictability in project flow.

Uncovering Project Execution Risk Areas

2009-10-01T12:51:00.002-07:00

Risk free - never. Risk conscious - absolutely essential. The ability to determine, assess and mitigate risk is a requirement of projects that must display a higher level of predictability. The challenge is in revealing the risk areas that need further attention, the unknown hazards that transition to reality and disrupt the project flow like hitting a block wall.

Technical and business risks are typically addressed to a reasonable degree; project execution risks by and large lack the attention they need. A good definition of execution risk would be areas related to the people aspects of a project such as information needs, expectations of each other, deliverable requirements and so on. I would also include the thoroughness of the plan and resource availability in the category of execution risk, since these are also people related.

So how does one go about finding the execution risks? Since they are predominantly people related a good place to start would be to ask the team members. Some of the execution risk will be related to a specific project while the majority will likely be systemic risks that span multiple projects. People related risks tend to hide well; therefore good detective and people skills will be required to uncover them. A formalized discovery activity will provide a thorough assessment of the risk areas, particularly those related to project execution.

Where are all the project risks? The team has valuable input on this; it is in the projects best interest to make sure their concerns are aired. Hold a project Premortem to provide a venue that grants the team a voice. Sift through the information that is gathered to find the golden nuggets of information that will make it well worth the time spent. Discover the unknown execution risks that quietly disrupt project flow and remove a large source of project unpredictability.

Guiding the Team Through Surprise Free Execution

2009-09-17T06:29:00.004-07:00

When effort is put into finding the reason for a project surprise it is essential to make sure that future projects do not repeat the same mistake. Work through solutions with the team, gain consensus and add them to the library of actions to be used for future projects. Some would call this library best practices. I choose to call it same practices to signify that things are done the same way, project after project. Many may argue about something being the best but no one will argue the benefit to predictability when projects do things the same way, with the same expectations and deliverable requirements.

In simple terms the same practices library objective is in reaching absolute clarity of the who, what, when, where and how of every activity. To be clear - this is not the tasks in a project plan, it is the nuts and bolts details of activities and deliverables for every project action. Think of same practices as the source of information necessary to enable full clarity of tasks, objectives and deliverables for everyone working on the project.

Where are these same practices kept and how do you make them available to the team without becoming a burden to the users? The least effective implementations tend to be those that have a best practices document on a shared project drive on the network. It's far better than nothing but it's not optimal for the team. The best implementations are those that are web 2.0 based and contain the process sequence, the people, the plan, the schedule and the documentation all in one simple point and click user interface.

Where there is an ineffective atmosphere in place to guide the development process and same practices, project surprises should be expected. The magnitude of surprises will be reduced with an emphasis on a comprehensive process sequence and deliverable expectations along with a simple environment used to relay this information to users. When full clarity of individual objectives and deliverables are met, surprises will fade. This is not rocket science; it's people science!

Understand the Source of Project Surprises and Eliminate Them

2009-09-08T13:30:00.003-07:00

What would enable every member of a new product development team to produce at such a level that projects flowed forward with negligible backtracking? You know, the backtracking that comes from failing to do it "right" the first time. The backtracking that silently eats into project efficiency, increasing costs and delaying revenue. Look back at those project surprises that caused a frenzied attempt to recoup what was lost. Why did they happen? Was it destiny, possibly fate, or was it because of a flawed assumption that should have never been made?

The last time a negative impact surprise made it's way into a project, what was the source? In most cases we will immediately conclude "something that was not planned, should have been". Although that possibility is certainly valid, it should not be assumed to be the end of the investigation. A project surprise usually means there will be backtracking to a previous task to rework something. It is essential that the root cause is uncovered whenever the project sequence is rewound to an already completed task.

More often then not when a task needs to be revisited it is due to a flawed objective of the task, the output or deliverable did not meet downstream expectations. That's not a timeline estimate issue; it's a task clarity issue that impacted the timeline! As dates for a project are developed, clarity is assumed, although often not ensured. Clarity of expectations will only result when two people (task deliverer and receiver) have consensus on when, what, how and where something will be provided. Reaching this agreement is a people thing, one where we can't depend on technology to make it happen.

In addition to a thorough project plan there are two crucial items that must routinely be addressed to keep surprises under control. The first one is to always consider the people aspect of a project's dynamics. Avoid a pure reliance on technology and methodology as the only guidance mechanism for a project. People know their function and are clearly capable of identifying an issue that impacts their productivity, if they are asked. The second one is related to investigation. If a project surprise occurs that causes negative impact to a project, it must be investigated to the root cause. Once uncovered, changes in the process must be made to ensure it will never be repeated on a future project.

The simple formula for eliminating negative project surprises is this - when something breaks the planned project flow, find out why by talking to the people involved and then do something about it. Technical tools and methodologies will be no help here, so put them away for this assignment. This one depends purely on people skills, so brush up on the one on one investigative skills that enable discovery of root cause. Do this well and enjoy a "Freedom from Project Surprises" that will lead to predictable and streamlined new product releases.

Management of Projects - Is it really working?

2009-08-25T12:54:00.001-07:00

There is no question we have come a long way in the art of developing chips in the semiconductor business. The number of transistors we are managing to hook up and verify has swelled. The arsenal of tools at our disposal has made substantial advances in the complexity of chips we are able to take to production. Technically we are doing miracles! From a project management perspective we have highly developed approaches to the administration of projects, both in the tools we use and the methodologies we apply.

With all of these advances at our disposal we may assume that we have maximized our abilities to managing chip projects. One question we must ask ourselves - is it working? Are we able to meet commitments and produce revenue per the plan? On the surface we want to say yes, with the addition of some qualifications. In our gut we know the answer is no. How can this possibly be the case with all this technology at our disposal? When a commitment is missed our first instinct is to ensure the reason for missing the bulls eye rests somewhere outside of our control – a perfectly human response.

A project team is a group of individual contributor’s, all with differing sets of requirements that will enable them to contribute optimally to the project. Our advances in chip development are great in the technical arena. The missing link in the ability to deliver is commonly related to the non-technical aspects of managing a technical community towards a common goal. We are engineers and everything in our world is about science, about black and white, about everything reacting the same way to the same set of circumstances. That mindset is just plain ineffective in aligning technical individual contributors towards the achievement of a common goal. When dealing with people, nothing is black and white.

Here’s an interesting concept – individual team members know what is not working for them on a project and they have known this for a while. Create a candid environment where this information can be gathered one on one and learn what keeps projects from flowing optimally; understand the reasons for project surprises. Take action to address each item found and remember that they all matter to someone. A project is not merely a system to be managed; it is a collection of very individual contributors with naturally human traits. Believe in this by addressing the personal region of a project and reap the benefits of a new found freedom from project surprises.

Development Process First - Organization Second

2009-08-07T11:10:00.003-07:00

Is your development process supporting the needs of the business or the needs of the organization? If there are many success stories, celebrations and goal achievements in organizational silos while the product misses on revenue objectives, the development process is supporting the organizational needs, not the business. Ouch!

An ideal development process is one that is derived to fully serve the needs of the business model as the primary objective. Accomplishing this can only be achieved by minimizing the organizational silo influence through a hierarchical top down approach, yielding a top-level process that is independent of any organizational structure influence. Please read on to learn about an approach that will enable a development process that focuses solely on supporting the business strategy.

Start off by identifying a core team that can fully represent all disciplines within the organization. Next I would suggest a establishing a dedicated room with large sheets of paper on one wall and an ample supply of blank sticky notes that will be used to represent the process steps. At the far left is a new opportunity and at the far right is volume production.

Now with the full core team, fill in the steps between opportunity and production using a sticky note for each, leaving any consideration of organization out of the diagram. Place the sticky notes in order from a flow standpoint and once agreement is reached, fill in the flow with lines and arrows.

This activity may span a several week period through multiple sessions. I would suggest others outside the core team to have "read" access to the room. However, any changes proposed from outside the core team must be handled through a core team member during a regular session.

Once this activity is completed and consensus is reached the final top level process can be captured and farmed out into the individual organizational entities for detailed process development, again using the same approach. The next level of the process must fully support the top-level process within each of the silos, paying particular attention to areas where cross-organizational flow is required.

Is your Development Process Targeting the Right Objective?

2009-07-31T07:01:00.005-07:00

Consider the development process you use today and how it was derived. Was it a broad-spectrum view of what needs to happen to generate new product revenue or was it a set of processes derived by each of the organizational entities within your business? Taking an honest, unbiased assessment will most likely yield the latter approach as the most correct answer.

Assuming the processes were created in each of the organizational towers, what do you believe the focus for each process was? Honestly, it depends on the function of each. In design the focus was on a tapeout. In product engineering it was product qualification. In test it was development of characterization and final test programs and hardware. For project management it is the development of a timeline, cost analysis, a business case and the steps to synchronize everyone. Marketing is paying attention to customer requirements and what it takes to secure the socket win. And of course business/operations is paying attention to revenue, margin and the timeline.

Now consider the process deliverables and interactions for each organizational entity. Are they really aligned to the only objective that matters - profitable revenue? So now I would ask - Is the development processes actually focused on the business requirements? In reality a few members of the development team are focused on revenue while the majority are paying attention to their more localized goals and objectives.

Here's a key question to reflect upon for your organization - Is the development process supporting the organizational structure or is the organizational structure supporting the development process? In an organization where the development process is primary, the project decisions, risk analysis, objectives and communications will be based on the big picture - business revenue priorities. Where the organizational silos are foremost, the development processes will be fragmented and disjointed with objective success not consistently supporting and enabling the business revenue goals.

The Big Secret – Costs of Inefficiencies

2009-07-22T06:16:00.003-07:00

We are going to be late! The news kicks off an energy explosion in attempting to regain the slipped time, often leading to some incremental gain with a rare exception that the project is fully back on track. The conclusion of this project saving frenzy typically involves an emphasis on how this slip is not acceptable and things will need to be better next time.

The reality is that specific actions to discover root cause and implement changes for future projects are rarely defined and tracked to conclusion. After the “catch up” flurry diminishes the team goes back to a pure focus on completion of the current project and any prominence on improvement quickly fades. Why? Time and money is the most common reason to “put off” an effort where project execution efficiency is the objective.

During this current economic downturn the emphasis on costs is at an extreme level, although mainly focused on the most visible expenses. How do costs related to project inefficiencies figure into expenditure savings? Probably fairly limited due to a lack of visibility – they remain behind the scenes and are rarely face head on. Here’s an interesting question to consider – What is the cost when a project is delayed due to inefficiencies in the development flow? The price tag of project set backs is best defined as the sum of both the incremental development costs plus the profits from missed revenue.

Consider expenses associated with projects that reach production ready status, only to find the revenue generation capabilities to be far less than the original plan. There is a huge prospect for savings here, considering the full development costs of a new product. The opportunity selection process must have visible financial metrics in place to monitor performance of this key gate to significant expenditures.

Resolution of project waste and inefficiencies can produce a fairly significant savings to an organization that invests in identifying and removing them. For those that ignore them, they still exist, quietly siphoning expenses with little fanfare or traceability. Diminish the impact of this big secret by identifying a visible price tag on project inefficiencies. This financial accent on project waste will provide the essential fuel to justify an emphasis on mitigating them and improving the overall efficiency of the organization.

Maximizing Activities that Matter to the Business

2009-07-09T05:18:00.008-07:00

How would you define activities that matter? I am sure most of us have been involved in projects that did not produce intended revenue, and that is certainly a long list of activities that did not count. Activities that matter will produce the intended results, and in our world, the results must be profitable revenue. At the start of any project (improvement or product development) we generally build a case to convince ourselves that the projects activities will have a financial impact. Somewhere along the way the alignment to profitable revenue may fade, and in many cases this transformation goes unnoticed. Below are some concepts to guide you towards maximizing the activities that matter to your business.

Broad and Diverse Involvement
The only way to ensure your direction is sound is to make sure you have broad and diverse involvement. The shortest path to activities that will not matter is by way of a small team of like disciplined same-thinkers. Stir up the pot and involve those who will make things uncomfortable, the ones that are not members of the same-thinkers camp.

Commit to Continuous Alignment to Revenue
There is only one result that counts - revenue. If your proposed activities can't be successfully aligned to a financial business impact this should be a clear warning. Product development activities are generally always tied to revenue, whereas improvement activities are not. Any improvement activity must have a defined impact on revenue, as in a return on investment (ROI). Monitor the revenue assumptions on a regular basis. Are they still valid as the project progresses? Put a system in place to keep tabs on evolving assumptions and is prepared to kill a project that falls out of favor with revenue impact.

Understand the Past
Why did you put so much effort into activities that did not matter? Project history is extremely important and is the key to a better future. If results of a product development or improvement project were unsatisfactory, it is essential to understand why. Get to the root reasons and make changes in your process to mitigate these reasons for future activities. Failure to understand the past will guarantee a continuation of wasteful activities in the future.

Have a Clear and Engaged Sponsor
Any project needs someone to carry the flag high, keeping the team excited and focused on the benefits of a projects success - a project sponsor. The importance of this is even greater where the activities are related to an improvement project. Only engage sponsors that will ensure the continued reality of business benefits for the project and will be prepared to make a case to bail out if the advantages fade.

Application of these four concepts will definitely improve the impact of project activities, when honestly applied. These are not easy and will push you and your organization into uncomfortable territory - with results that will be noticed.

The Critical Link of Activities to Business Results

2009-06-30T14:14:00.004-07:00

If you were asked to comment on an assessment of the last year's continuous improvement, what might your review look like? Would it be a list of actions and activities completed, or might it be more in terms of impact - as in business results of the activities? Consider that the most important aspect of any improvement initiative is a direct correlation between the activities and a measurable business result. By framing a project in this way there will be alignment of actions, decisions and resources with those intended results.

Here's a deep question for you to consider - "What is the reason a company has groups of employees organized as divisions, operations and departments?" What is their reason for existing? They exist solely for the reason of producing a positive impact on revenue, either directly or indirectly. Every organization, sub-organization or organizational silo must be viewed as an element of the revenue generation machine.

It's easy to fall into a thought pattern where you believe the decisions and actions responsible for profitable revenue reside somewhere else, in fact you may be thinking that right now. When this view occurs within an organizational unit, results become unrelated to the big picture business objective of revenue. Improvement actions and objectives take on a form that produce localized, narrowly focused results. The trouble is any localized positive change may have little or possibly negative impact relative to producing revenue. Without a critical emphasis on business results, any process improvement change can end up being an expensive trip to nowhere.

When starting an initiative that is intended to produce a higher level of efficiency, never loose sight of the fact that the result must always be measured as the impact to producing profitable revenue. Any efficiency change must have an outcome that impacts at least one of these: 1) enable quicker revenue, 2) provide increased revenue, or 3) improve revenue margin. If the initiative can't be measured against some aspect of impacting revenue results, it is not a properly framed improvement project. Make no mistake, the name of the game is "making money" - bottom line.

A highly effective efficiency change will result by developing a strategy, aligning objectives and building a team with an objective of revenue impact as the motivation. And yes, for proper financial emphasis it will always mean project participation outside your organizational silo; it may even be wise to consider outside leadership! Broad participation is essential to dilute the incestuous pool of same thinking that cripples real change. Focus activities only on results that matter to the business!

Soft Skill Development Breeds Solid Leadership Effectiveness

2009-06-23T07:09:00.003-07:00

Personal Skill Assessment – this is an area where we often have a vastly different reality index when considering “Hard skills” vs. “Soft Skills” area. Hard skills fall into the category of specific abilities such as doing calculus, working with a spreadsheet, creating a project plan or designing a new function - the technical attributes. Soft skills are more related to attributes such as leadership, communications, objectivity, decision-making, vision or problem solving – the personality attributes.

Generally, we tend to more realistic in identifying deficiencies in our hard skills than our soft skills. This may be because of an underlying fear of being perceived as broken, from a personality standpoint. Or it may be the product of our pride or ego. Regardless of the specific reason, the ability to become a stronger leader will be based on the suite of soft skills at our disposal. If we are in a leadership position, our ability to retain and grow in that capacity will be directly proportional to our continued soft skill development. The barriers to soft skill assessment and development must be lowered.

As effective leaders of new product development teams we must be “soft skill teachable”. This means that we do not have all the answers, but we will passionately seek them. It means that we are convinced there is always a better way; we are not already there. It means that we will keep our ego, pride and fear in check, remaining ever open to the possibility that we may not be right. Above all, we must continuously pursue possibilities that enable advancement in our core soft skill portfolio.

Soft skill training, coaching and guidance must be a strategic component of our development objectives. I have learned that given enough time in our own heads, the impression of our soft skill competency will become skewed and unrealistic; in time we may approach legendary status in our own minds. External input and guidance is vital for our accurate soft skill assessment and development to guarantee we are balanced towards ego deflating reality. Seek out those personal and professional resources that will provide soft skill authenticity and expansion, thus securing the reality of your leadership vision.

Six Actions to Promote Project Execution Excellence

2009-06-04T16:43:00.001-07:00

Today is just right for taking action to remove some barriers to project execution excellence. If not today, there is a high probability that action will be either significantly delayed or never occur. How long have surprises been disrupting projects already? Below you will find a list of six "today" ideas to pick from. Take action against one of these every day and before long your organization will display a new level of productivity and efficiency, one where improvements will be obvious to all.

Ask a team member
"Is there anything you need that would improve your project contribution?" This is a loaded question and one that can provide a wealth of information about what is not working well. Ask a different team member this question every day and put actions in place to address what you learn.

Face an Issue and take action
You know of something that is a problem and may be hiding behind money, time, or that it's not your problem to be fixed. Take action today to engage on a path towards a solution. If you don't, no one else will either! Time to do this will not last forever, as many companies have already found.

Discover a Problem
Talk to your direct team and talk with other teams to find out what they believe is not working well. Step out of your organizational silo and into another to get a refreshing look at the situation. Consider an outsider as an objective source to uncover roadblocks. There are always unknown barriers to ideal execution and they must be discovered and addressed, or they will continue to silently disrupt your plans.

Issues Brainstorming
Host an informal, no-holds-barred session with your team to uncover the issues. In this case it is extremely important that a non-threatening environment is established to promote the healthy discussion of where the issues reside. Maximize effectiveness by ensuring that everyone leaves his or her healthy egos at the door. Create an actionable plan based on what your learn.

Take a Realistic Look at a Project
Is there a project that has just never felt right to you? Get answers to your concerns and take action, where appropriate. If it has not started elect to table it. If it is in execution consider killing it. Keep in mind that we are not in the business of purely creating cool products; we are in the business of generating profitable revenue. If it's innovative and positively disrupts the market, that's good. If it's an impressive engineering accomplishment that lacks market acceptance, that's bad.

Foster Innovation
Look at the innovation process. Is your organization promoting product, process and work flow ideas or are they being stifled? Create a mechanism to support the generation and resolution of ideas. Ensure there is a reward system for ideas.

Today is Perfect for Making a Positive Change

2009-06-01T06:42:00.003-07:00

Procrastination within an organization is one of the greatest limiters of execution excellence there is. Where your competition is concerned, their postponement in the repair of a broken development process is good for your business. However, if procrastination is your organizations mantra, that's a grave situation for long term viability. The reality is that the competition has reason to cheer on organizations that wallow in a pool of delayed action, the ones that are lost in a non-action dream of one day becoming an ideal new product development machine.

In my business I am barraged with reasons why today is not the right time to make a positive change in the new product development process. Reasons for inaction come down to one of time, money, denial or "not our problem". Faced with the stark reality that there are well known inefficiencies in the development process, many organizations will remain on the course of addressing them later. Tomorrow rarely comes and a year down the road the same issues are still wreaking havoc with development projects.

The media is loaded with companies that had made the choice to delay taking action in finding and fixing business issues. They believed time was on their side and then one day found that time had run out. They believed they were too big to fail and then found them selves face to face with the reality of a chapter 11 filing. How does your organization stack up in the area of action related to product development efficiency concerns?

An organization that displays a "There is no time like the present" attitude will have a belief system in place that drives continuous improvement. These winning businesses will seize a never-ending passion to hunt for issues and solve them today; they will be a force that the competition views with envy.

Today is a perfect day to take actions that will remove the systemic project execution barriers that have been negatively impacting revenue goals. Now is the ideal time to step up to the plate and make a difference, while everyone else is merely waiting for a better time. Display leadership and secure a future by driving solutions to the execution obstacles that you know the development team is facing every day. Do it today!

Finding Root Cause of Project Performance Barriers

2009-05-21T06:02:00.001-07:00

How often do you ask yourself the question - “What could we do to improve the execution of our new product development efforts?” From my experience in working with teams this question is certainly on the minds of management and is usually considered in the context of the ability of a team in meeting project commitments. Most everyone has a quick response to a question such as this and they are usually high level and off the cuff, making an implementation plan difficult. The problem and solution is often identified as just out of reach, in another organizational tower.

When this question is posed to a project manager the solution is with the engineering teams. When asked of the design engineering teams the solution is with marketing, product engineering or the customer. Product engineering identifies the solution as being primarily in design, marketing or project management. This may be overstated, however I am certain you see a hint of this reality within your organization.

My point is that the first response to a problem tends to be the easy one, the one that actually does not lead to any solution; it purely provides an answer. Finding real solutions to improve project execution will require a deep dive to uncover root causes. Consider it an expedition to find what is not known, leaving behind all your preconceived notions about where projects roadblocks may be.

Finding root cause of project execution barriers requires excellent listening skills and an ability to ask the right questions. Talk to each team member and ask them one simple question – “What do you need to maximize your contribution to projects?” Now listen and make sure you understand the answer and the reasons for that answer. You will find that the major barriers to ideal project execution are due to a lack in servicing the requirements of the individual. The team member is the most important ingredient of a projects success, one we tend to ignore with a vigilant focus on the metrics of “the project”.

Why aren't the known Execution Challenges Being Fixed?

2009-05-11T05:45:00.004-07:00

I have just compiled the results of a survey to further refine understanding of the sources of roadblocks that new product teams experience during execution. A second objective of the survey was to identify the reasons that new product teams may be unable to gain the momentum to mitigate these negative sources of project impact. Or more simply - what prevents the known problems from being fixed. This new survey is a follow-up to the original findings from the July 2008 survey. Click on images for a full page view of the data.

Why don't we fix known problems?
This question ranked the primary reasons why known issues with project execution were not fixed. At the top of the list was a lack of motivation for the team to do so; the team was simply not interested in making changes to improve. At the bottom of the list was the lack of a real problem to be fixed.

Sources of Project Challenges
This question was focusing on ranking the barriers to an ideal level of project execution. Making the top of the list as the greatest challenge was the clarity of individual requirements; team members were not clear on the details of their project contribution. At the bottom of the list were design tools, indicating that the tool sets available to the team were not a major obstacle to project execution.

Opinion
You can form you own conclusions from the data. From my perspective the data tells me there is generally a lack of motivational factors to drive an execution improvement environment. This matches well with my findings in working with many teams over the years. Typically there is healthy discussion about changing things for the better, although it is rarely backed up with an actionable plan and the funding necessary for execution of that plan. Simply put - The current state of project execution in an organization is exactly where is was chosen to be.

Maximizing Team Motivation

2009-05-03T05:44:00.002-07:00

Over the last 6 months or so we have all likely experienced challenges in keeping teams motivated to the task at hand. We have been barraged with a continuous stream of deteriorating economic news and widespread announcements of headcount reductions. Now more than ever it's important to pay close attention to the team dynamics and keep teams motivated to maximize productivity, thus ensuring products are ready when the market rebounds.

How would you view the motivation level of your team - more importantly is it at a point that negatively impacts the success of your projects? One of the key differentiators between a highly motivated team and a team in need of an inspirational tune up is in the way they deal with problems. A highly motivated team is continuously seeking solutions to execution barriers while a less effective team tends to identify someone else or another organization as the owner of solutions for the obstacles they are experiencing.

Here's the deal - any team's level of motivation is directly proportional to the leadership's ability to create an environment where motivation prospers. If an organization needs to improve the motivational quotient of a team, the process must begin with a change in the leaderships management and communication style. This begins the positive transformation in the way a team interacts with each other to alleviate the multiple challenges of product development, a key step in increasing a teams drive towards execution excellence.

The renovation of a team's dynamics to produce a heightened enthusiasm requires concentration on three specific management style themes - people, trust and fun. People are the nucleus of any team, trust strengthens the conduit of information transfer between the members and fun is the agent to enable productivity during the tough times.

People
People are the building blocks of a team, where no two of them are the same. The challenge is in understanding the qualities, strengths, weaknesses and objectives of each member and establishing project contributions that are as close a match as possible. The better matched an individual's project personality is to their project contribution, the greater their level of enthusiasm and productivity towards meeting project goals.

Emphasize the people aspects of projects and your team will respond by providing a higher level of support and passion in their contributions. Coaching, nurturing and training may be utilized to expand the individuals project personality to a level that will meet future needs; further strengthening emphasis on the people component of an organization.

Trust
Without first establishing trust there will be no credibility and without credibility the team remains skeptical and unmotivated. Be real and authentic with your team about situations as they arise - telling them how it really is. Honesty will breed credibility. Never use "secret" knowledge as a means to promote motivation within the team, they will easily discern this and credibility will be damaged. Build a solid foundation of trust and your team output will be maximized, they will do whatever it takes for success.

Fun
Have a good time, even in the face of significant challenges. Lighten up and find the humor in unpleasant situations. Celebrate incremental successes often. Play a good rousing game of Laser tag with the team when you hit tapeout! When a team is having fun they will produce to a higher level, always.

Are we Ready for Hosted Solutions for Chip Design?

2009-04-23T13:33:00.006-07:00

Software as a service (Saas), hosted solutions or cloud computing all have a similar meaning; and that is running an external software application on external hardware over the internet. No software to install or maintain and no hardware to buy or maintain. The positives are availability of the application from a web browser anywhere on the planet, simple deployment and a potential wealth of hardware at your fingertips. The negatives tend to be long term costs and the necessity of an internet connection.

This hosted approach for software is widely in use for project management, customer relationship management, brainstorming, collaboration, workflow management, desktop sharing plus many others. I am personally using many of the hosted approaches for my business and have found it a great way to have my data available to me with only a web browser and an Internet connection. I have grown to thoroughly appreciate this approach for the applications I need, although I was reluctant in the beginning. I am now a staunch advocate of this next generation of software delivery.

Now, how about hosted solutions for the chip business? Cadence announced their SaaS chip design offering back in September of 2008. There are also a few others out there with Saas offerings for design work. I am not sure how the adoption of this is going but I personally believe this is the future, once we get beyond the 1st order concern of having our IP “outside” the firewall.

Here’s a few links on the subject to get you thinking:
Cadence blog
Harry the ASIC Guy blog
xuropa

I would really like to hear comments from anyone who has given the hosted solution a try for any IC design activities, good or bad. Has it been a good experience or were there unknown potholes that made it unpleasant experiment?

Eliminating the Systemic Barriers to Meeting NPD Commitments

2009-04-15T06:47:00.005-07:00

What comes to mind if you were asked “What are the systemic barriers to meeting New Product commitments?” These barriers are ingrained in the very fabric of an organization and typically subtle in visibility, yet pervasive in impact; often providing a veiled resistance to improvements in an organizations project execution. Their presence is often characterized by unexpected diversions in a projects course – surprises often believed as something that could have been avoided. Are you and your team tired of being surprised and dealing with the aftermath, project after project?

Understanding and removing these systemic barriers takes an attitude that change is possible and WILL happen. It takes an attitude of ownership to find and remove the roadblocks that are creating project surprises; the issues are right here, right now – not somewhere else in the organization or someone else’s responsibility. It takes an attitude that you will be successful in eliminating execution barriers. It takes an attitude that grasps the value in a proactive and never ending focus on being better.

What have you done in the last year to drive improvements and eliminate the systemic project barriers? How about the last quarter, last month, last week or yesterday? A never ending and relentless attitude on always being better will make you and your teams stand out from the pack by always delivering to the business objectives. Talk about being indispensable – do this well and the wow factor is off the scale!

Addressing the What, Where and How

2009-04-07T12:16:00.003-07:00

For any task, the who and when are generally clear and well known to the entire team; it's in the project plan and visited frequently during project meetings. Whereas the more procedural information that describes the specific what, where and how for tasks is often lacking clarity and left open to interpretation. This gap in clarity often leaves a project open to reworking of deliverables. The following sections provide some considerations for addressing procedural clarity - the what, where and how for task objectives in design.

What
This covers both the deliverer and receiver of any project deliverables. The primary consideration is that everyone has the same expectations.

Test mode handling expectations.
Specific model requirements.
Specific process and any process options.
Area requirements.
Power saving expectations.
Pinout, pin type and loading expectations.
Module level deliverable requirements for the chip.
Layout abstract requirements.
Specific documentation requirements.
Critical node descriptions.
Block diagram expectations.
Documentation requirements.
Routing blockage assumptions.

Where
You never want anyone guessing about where "current and released" project information resides. The worst-case sharing scenario is when email is used to send items around - very dangerous. Define locations for any shared information, identify release mechanisms to those locations and then legislate these repositories as the only way to share project information.

Location(s) of current requirements and specifications.
Location(s) for deliverables.
Location(s) of any non standard reference libraries, custom component models etc.

How

Valid reference libraries, components and tools/versions to use.
Design collateral validation requirements to minimize chip integration surprises.
Validation requirements to guarantee design quality.
Risk mitigation strategies and configuration options in support of them.
Review requirements - specifically what must be completed and what must be presented.
Simulation expectations - analysis types, stimulus, supplies, test benches etc.
Standards for RTL, naming conventions, ECO conventions, etc.
Schematic standards.
Procedure for version control of documents and design libraries.

Addressing the what, where and how completely and concisely will permit your organizations to experience a new level of predictability.

Closing the Individual Objective Clarity Gap

2009-04-01T06:56:00.004-07:00

Are you confident that everyone has had all the information required to perform his or her tasks for projects? If any task deliverable or activity has needed to be reworked or massaged in any way, they definitely did not. Clarity of individual objectives is one of the top three contributors to unexpected diversions and delays in projects. This deficiency is often misunderstood, ignored and "assumed" to be under control. As an example of this misplaced assumption - the existence of ISO 9001 should not imply that the clarity of individual objectives is being addressed to the degree necessary.

Most project teams have a solid grasp of the timing expectations and responsible person for each task - the who and when aspects of the project activities. The primary reason for success here is that the information can be easily conveyed and interpretations of intent are rarely necessary. The expectations can be simply transmitted, captured and tracked in a project plan. It's "easy" information.

Where I see limitations in clarity is the what, where and how aspects of each of the tasks. This is the procedural information that does not easily fit into a single line description. Consider that for any project there are many "right" ways to do a specific task, the challenge is aligning everyone to the same "right" way. Failure to align expectations will lead to rework due to missed expectations between the deliverer and receiver of a task output.

The what, where and how objectives are procedural in nature and can't be easily integrated into a project plan. Detailed procedure descriptions, diagrams and flow charts are necessary to properly convey this type of information; this can't be done in a checklist or a project plan. There is another medium necessary to convey this type of information, one that is easily accessible and available to everyone. The chosen method must integrate into the workflow, not stand outside the workflow as a reference. Suitable communication of this information requires the addition of design guides and/or web workflow management systems.

Frequently there is an assumption that project plans, specifications and checklists cover the needs for communication of individual expectations. This is just plain wrong and will leave your project open to needless rework. Where both a predictable and streamlined path to new product revenue is required, it is essential to make sure each team member is clear on exactly what, where and how everyone is contributing to each project task. How far away is your organization from this ideal objective?

Are you Ready for Changes in the Requirements Process?

2009-03-19T12:20:00.002-07:00

If you are ready for some changes to the requirements gathering process I would like to share a number of possibilities that can be explored. It's best to start out defining a set of objectives to describe what needs to be different. Items such as time, synergy, quality (i.e. less rework) and clarity would probably be the areas where objectives should be established. Also, keep in mind that this is a business level change, not only marketing or engineering.

Focus, focus and focus
The simplest place to start and make a difference is emphasizing management of the entire process. Have one individual responsible for managing the requirements details that spans across the customer, marketing and engineering domains. The domains typically manage their own requirements activities, but there is often nothing in place to drive the technical process through all domains. This leaves the project open to the cross-domain blame game where one domain is locked waiting for inputs from another. A single person that focuses on total requirements actions and manages the cross-domain synergy should make a significant difference. The person tasked with this must be skilled in requirements gathering.

Workshops
This would build upon the focused management aspect to fast track the entire process for a project through a series of concentrated workshops with all the key players. This emphasizes the necessary focus while providing an environment to accentuate closure of specific actions and sub-deliverables. There is an art to facilitating such a process, however, when one does this well the results can be rather impressive. The facilitator of such a workshop must be an individual skilled at focusing a team and enabling synergy while maintaining an unbiased view towards any specific requirements.

Modeling
In my opinion modeling at all levels would be the most advanced form of requirements gathering. This removes the mindless and error prone task of reviewing written documents. Modeling is very common within design but must be advanced into the marketing domain via an industry common language such as UML or more precisely SysML. Other possibilities in modeling platforms exist and the decision on which is best will be left to your organization. The key model platform decision factor should be accessibility outside of design while maintaining the ability to directly interpret the model within the designers world. An emphasis on early modeling over written documentation also yields access to Agile methods, a very successful iterative approach in software product development. The key question to ask yourself is this "Can modeling in the customer domain bring relief to the requirements closure process?". I believe this is easily a yes.

The most important step to a better requirements process is to take an honest look at how the process is working in your organization. If your organization falls in with the majority, you believe the process is broken. Are you going to justify why it is the way it is, or is it time do something about it? Continuing only to talk about the requirements problem is justification; organizing, defining objectives and taking action is doing something about it.

Delivering to the Plan

2009-03-11T14:52:00.001-07:00

What does the statement " Delivering to the Plan" mean to you? To me it means that the right product was developed at the right cost and in the right time frame. Essentially, the project was successful in meeting the revenue and margin goals, as per the business case that launched the project. As you are working on projects what objectives are on your radar screen? If you are like most development organizations the milestone focus is probably on tapeout, first samples, evaluation, characterization and production release. Yes, of course you know you need revenue, but that’s not your responsibility, right?

Who is responsible for revenue generation? Sales and marketing, right? WRONG! Everyone on the New Product Development team is responsible for revenue. One important question to ask is, “Are projects failing to meet revenue objectives while at the same time showing success for milestones such as tapeout, samples, characterizations or production release?” If this is the case, it is time to institute new criteria for measuring the success of a project, one that keeps everyone focused on making money.

Success against revenue/margin goals indicates the team’s project decisions and actions were aligned to produce the right product at the right cost and in the right time frame. Setting the objective on revenue and visibly measuring the project’s ultimate success or failure against that objective will create the proper incentive for everyone on the team to challenge product assumptions. When this occurs, the project objectives and goals will reflect a heightened level of clarity, realism and buy-in; enabling projects that deliver to the plan, and that means meeting revenue and margin objectives.

A Snapshot of Today's Requirements Process

2009-03-04T05:08:00.002-07:00

In the semiconductor industry today the requirements process for the majority of teams is structured into a serial sequence that looks similar to the diagram to the right. Project complexity may drive a different number of hierarchical requirements levels within the engineering domain, however the diagram concept is the same. In the interest of getting projects started there is usually a parallel component (denoted as the red urgency line) that cuts across all levels of requirements. This parallel short cut path allows the detailed engineering requirements to begin, often without a solid understanding of the top-level system or customer application needs.

Requirements details are typically captured in a word processing document for each level. This document has multiple reviews and iterations before being released to the next lower level of detail. Within the engineering domain the written specifications are often complemented with some degree of high level modeling of the IC component or an IC family of components.

The task of keeping the customer requirements aligned with the engineering implementation details is a manual, error prone process. The engineering level requirements details are usually held close to the vest and typically not shared outside of the company. This separation of what is shared vs. what is kept in "secret" further complicates the alignment of engineering and customer requirements.

The ownership of the requirements process changes as the requirements march towards finer engineering level detail. The high-level customer requirements are usually managed within marketing/applications engineering. The engineering level details are managed within the design team and may have different owners for each level of detail. Note - This requirements ownership and management handoff is a major source of confusion, leading to a lack of clarity and focus.

So, how's this process working for you?

Based on inputs from many of you, requirements at both the project level and individual level is a big problem. Couple this with non-ideal scope change control (Feature Creep) and this makes requirements a huge deal for projects. Organizations are not achieving the requirements results they desperately need, so it's fair that the current approach is just not working.

In reality the requirements process is the one item in the development process that has not evolved, while the design flow and tools have seen significant advances. The existing requirements process is an antiquated system that is impacting our projects to a significant degree and the industry continues to accept this, project after project. I believe most will agree that a change in the requirements gathering process is long overdue!

Ready, Set, Change – Well Maybe Not

2009-02-25T05:04:00.001-07:00

This thing about wanting to make positive changes and then never really engaging is a funny thing about human nature, and about change in general. We know that something is broken; we talk about it at great length and how it’s impacting our ability to produce better. Then, that’s as far as it gets. The action to follow through falls apart, usually with some trumped up reason as to why now is not the right time.

I see this happen in organizations all the time. Things are moving along towards a root cause for a known problem. Great discussion is happening, objectives are being put in place, ideas are flowing and then that’s it. Suddenly, it’s not a good time to proceed. The fear of change is now dominating what was once rational thinking. The path to improvement has been cut off by a realization that this change may have an impact on an individual’s daily routine.

It’s OK for you to change, but don’t mess with my world! The reality is that we all must be open to change. From down in the trenches to the CEO we must realize that we are not perfect and be open to changes in the way we operate. The problem is not only over the wall in marketing, design, test, the business unit or product engineering. The problems we are having in new product development begin right here with each of us. If you can honestly arrive at that realization, change will be natural. Remember - It’s not about you; it’s about us.

Assessing NPD Efficiency

2009-02-13T06:20:00.002-07:00

If you were asked to define the efficiency of your New Product Development efforts, how might you respond? It's not an easy question to answer and I am sure the variation of responses would be fairly significant, depending on which organizational disciplines were queried. Typical responses cover a broad range of answers that are primarily discussed in small groups over lunch, in the break room or at happy hour. These low visibility assessments are typically an emotional take of the situation, lack specific metrics and rarely lead to action.

Nevertheless, it is important to be able to present a succinct answer to the efficiency question. Not as a collection of individual answers but an organizational answer, one that is quantifiable and actionable. Without an agreed figure of merit to describe efficiency of NPD efforts it is impractical to expect anything will change. This is not about blame; it is about leading an organization down a managed path of change, culminating in measurable improvements. Accomplishing this requires the establishment of a baseline that describes current execution effectiveness. This figure of merit can then be utilized to identify a new target for efficiency.

This key metric must describe NPD efficiency by providing a fact-based judgment to define an organizations effectiveness at producing new product revenue. Consider that the primary objective for any project is realized revenue that meets a specified timing, figure and margin. Revenue is the only motivation for starting a project, therefor it must figure substantially into the measurement of success. A successful project is not a tapeout, first samples, a completed characterization or production release; it is sales that meet a planned date, margin and value. Any project success metric that is not tied to a revenue target is really of little value and may actually hinder improvements by providing a false passing grade.

Revenue generation as planned means that a proper market need has been defined and a product has been produced that fills that need. That's what will keep the stockholders happy and the paychecks coming. Many times the metrics are far too short sighted and everyone along the NPD path has small sub-organizational successes to report, however the big picture result is missed revenue; and that is unquestionably a failure, pure and simple. Emphasis on a big picture revenue metric makes everyone accountable and empowers each individual to challenge project assumptions. Now the question is this - how has your organization been doing on enabling project revenue and where deficiencies are noted, what is the game plan for mitigating them?

Now is the Time for Emphasis on Organizational Effectiveness

2009-02-02T13:30:00.003-07:00

The business climate we are facing today is unquestionably a painful one for the semiconductor industry, as well as most others. Energized by the cost sensitive nature of this climate, a focus on efficiency provides the benefit of organizational growth. The growth I am referring to is best characterized as an improvement in efficiency that results in financial growth through reduced development costs and earlier new product revenue.

Organizations that will grow stronger during this depressed economic period share a common vision that efficiency of operations carries significant importance. They believe now more than ever that there is something to be improved upon, something that could be done different, or a possibility of newly discovered opportunities for organizational success. This accent on change for these groups will yield positive results through specific improvement actions. Growth organizations will be motivated by a passion to seize this current emphasis on cost reduction as a motivation for creating a new level of operational effectiveness. Stronger organizations will evolve from a belief in doing things differently, that sustainable change is achievable, that the status quo is just not acceptable. They will take positive steps to jettison the project execution baggage that has long been accepted and tolerated through the more prosperous periods.

Organizations that bolster efficiency during this period share a vision that has no room for waste in their development processes or their portfolio management. They will have the right product ready to generate revenue when the demand floodgates open. An achievement that will be enabled through focused actions today, during a period when many organizations will fall prey to an emphasis purely on cost reduction. The winners out of this downturn will have emphasized NPD efficiency improvements as a complement to the routine cost reductions.

Prospering organizations during this challenging business period will display many of the attributes in the figure below.

Lean and mean must be the mantra in this battle for survival. This is not a time for accepting less than the best out of people, decisions, strategies, workflows, product portfolios, suppliers and customers. An emphasis on organizational effectiveness in the current cost conscious climate will ensure organizations are well prepared for long term financial success. Unbeatable organizations will be highly efficient in their execution and brilliant in creating products that exceed market expectations.

Project Performance – It’s time to Step out of the PM Cockpit

2009-01-20T05:26:00.001-07:00

In our industry today we have a broad range of methods and processes to help us manage projects, and there is no question we have seen significant advantages through their implementation. Yet most everyone will agree that project performance is lower than we need and/or expect. There is something missing and I confident it has little to do with our formal project management processes.

It’s time to get back to basics, back down to the projects individual contributor level and see how project execution is doing there. I believe the individual level interactions have been unintentionally ignored and left behind due to a focus on the higher-level project. Consider the possibility that the project management emphasis may not be providing full value to the individual contributors needs for success on their project contributions. Could it be that all the team participants are not clear on their specific contribution to a project? Based on my work with a variety of teams over the years, the clarity of individual requirements is definitely an issue with most.

Are we truly addressing the individual participants needs in our formal project management practices? Project management methods tend to place emphasis on managing projects as a system, allowing individual interactions to remain out of view. This can leave the project open to individuals being self guided as to how they need to deliver the specific details of their tasks, a strategy that is fraught with task rework. A question that must be answered honestly is who is minding the individual expectations for a project? Technical leads, project managers or the individuals themselves?

Bear in mind that at any point in time during a projects execution an individual is either creating or receiving something for a specific project task. Optimal project performance will result only where there is perfect alignment between what is being delivered and what is required for each task, at the individual contributor level. Such an important alignment can’t possibly be left to chance.

If a new level of project performance is an objective it may be time for us to step out of the project management cockpit and gain the individuals perspective on what may not be working well. We must talk to project contributors and consider each individuals requirements for optimal performance of their activities. Are they clear on their specific project contribution? Do they see a deficiency that generates waste or confusion? Is there some additional information that would help them execute? If a heightened level of project performance is the objective, team members will have solutions; we must provide a forum where they can be heard and be prepared to act upon what we learn.

Removing the Requirements Closure Barrier

2009-01-12T19:01:00.005-07:00

One of the most often mentioned challenges faced by NPD teams is the accurate and timely closure of project requirements. A deficiency in the quality of the requirements closure process is commonly accepted as it is, justified by a belief that it can't be improved upon. Left unchecked, weaknesses in requirements quality will quietly continue disrupting plans and causing activity rework due to inadequate information.

It's time for a change - time to stop accepting the status quo. Proclaim that requirements closure is not going OK, that it is not acceptable. Openly affirming this enables positive actions to commence in mitigating requirements limitations as a source of project impact. These actions will engage the process of removing what is most likely one of the top three barriers to ideal project execution in your organization. Avoid the temptation to believe ownership of "fixing requirements closure" should be elsewhere, since this type of justification has kept this project barrier cloaked by misguided acceptance. If it's impacting you or your team then take the ball and remove the problem. If you don't, nobody else will either.

Start by quantifying impact. What has been the negative influence to projects due to limitations in requirements? State the impact in terms of lost revenue opportunity and inflated development cost, the baseline criteria that should be used for measuring project execution. This must be answered before proceeding, thus setting a solid foundation upon which to construct genuine improvements. Skimping here will allow negative influences to crush the effort and diminish effectiveness.

The next step is to identify participants and objectives. Make no mistake - this must be a cross-functional activity that minimally includes design, marketing, sales, the business and project management. Assign a tenacious leader/facilitator that believes in the cause and will not be viewed as a threat to any one discipline. Consider the following questions to help define objectives:

What specifically needs to be different? ?
How will you measure progress and success?
What will success look like?
What will be the typical objections to this activity, who will display them and why?

And now it is time for the solution. Having done all the proper background work the solution(s) should be fairly straightforward, with proper guidance. I suggest a workshop type format with a facilitator in charge of the process, not the decisions. Have the workshop participants define their own rules of engagement, finalize objectives, define the decision process and track activities.

As with solutions to all project execution challenges, success will result only from a formally sanctioned project that has proper leadership in place. It must have a budget, sponsor(s), a leader, a plan, objectives, ROI expectations and a cross functional team. Solutions to project execution issues are not rocket science; they materialize out of a dedicated and well-managed effort. Anything less than full commitment will be wasting your organizations valuable time. It's all or nothing, and a choice of nothing should create a bona fide uneasiness regarding the requirements closure process.

Our New Product Delivery is OK

2009-01-05T07:20:00.003-07:00

Has the dilemma that the US auto industry is facing stirred up any thoughts about the future of your business? Has confidence in your business wavered at all through any of this? News such as what the auto industry is facing should be a wake up call to all of us involved in product development. If we are not diligent in being the absolute best at delivering products, our business may be headed for trouble at some point down the road.

When querying organizations about project performance a common response I receive is that they are releasing products at an OK or acceptable level. We consider our project execution as being OK, while most projects in our industry are delayed in reaching a production level by somewhere in the 1-3 month range. Essentially it is accepted that projects will be late, supported with a surprisingly common list of reasons why it is the way it is. I have to wonder how long this type of "OK" thinking went on in the big 3 auto industry, while their business was quietly shrinking as their competitors was growing?

Consider that delivering products solely at an acceptable level of productivity may be paving a silent path to diminished business results. During the current business climate there certainly is no room for waste. If projects you are dealing with are plagued by an unpredictable element of any kind, it is essential to deal with the root causes and remove them. If you don't, your competition may be quietly gaining market share because they are. Many organizations have already identified the major issues with project execution, however, are failing to take the next steps by getting to root cause and final resolution. Reasons for a lack of action include a belief that project execution is OK or that it is already as good as it gets, a dangerous assumption that feeds complacency.

A false satisfaction with project performance fosters inaction in seeking root cause and resolution to well-known project challenges. Complacency also bestows a deceptive sense of calm, a quietness that veils the storm of competitive pressures. It is crucial to be able to frankly make a distinction between a misleading sense of contentment and genuinely acceptable project performance. A belief in continuous improvement makes this delineation a simple matter - acceptable project performance is a goal that is never attained and forever sought.

New product delivery must never be considered as "OK". Making a statement to the contrary will allow an organization off the hook for continued improvements to the process of delivering new products. There ought to be an assumption that for every project launch there will be something done differently, with an expectation that it will provide better results than the last project. The alternative to continually planning and expecting improvements will leave your organization to someday face the harsh reality that the big 3 auto is facing today - change immediately or become extinct.

Getting your Top Five Obstacles Behind You

2008-12-14T07:13:00.003-07:00

Back on December 1 I posted and article titled "The Top Five Obstacles to Predictable Project Execution". This posting is a follow up to that article.

What are the next steps after the top five common project execution obstacles have been identified as scope control, individual objective clarity, project planning detail, requirements closure and project leadership skills? Ideally we must improve upon each of the obstacles to the point where they no longer:

Enable the need for rework of already completed tasks.
Enable wait states due to lack of information.
Enable non-value added activities to take place.

These three project performance indicators become the measurement criteria for work flow efficiency and will be invaluable in providing insight into progress. Once they are no longer enabled, predictable project execution will result!

The primary step is to adequately resource an effort to eliminate these top five. It must be a focused effort with someone responsible for delivering a solution, wherever in the organization that solution may need to be. But wait, adequately resource? I have just lost you on costs, haven't I? OK, let me back up a bit. The primary step is to identify how much these top five are costing you in terms of delays to revenue ready products. Now you have a justification for the second step, which is to adequately resource the effort to remove these top five barriers.

Get someone on the hook with the passion to uncover root cause, ability to gain consensus for real solutions and be comfortable working across all organizational silos. Failure to do so will be a grave error and allow a naysayer the opportunity to say, "I told you so". Recovery from a failed attempt will be far more difficult than engaging the ideal resource in the first place. Do not cut corners in putting the right person in place for driving the solutions.

Approach the top five with a strategic approach to problem solution. A tactical attitude would focus on activities within a NPD project workflow whereas a strategic approach will focus on the big picture view of how to plan, resource and engage on projects to eliminate impact from the top five. The mission is a change from what is "believed" the best the team can do - to becoming the best via the elimination of the obstacles that are well known disruptions to projects. Don't focus on why things can't change, evolve thinking to how things can be changed.

Have you started the mental list of why this could never work for your organization? The uniqueness of your particular situation precludes this from being possible, right? Fight the negative thoughts or you will only strengthen the hold of the status quo. Justification of uniqueness will pave a lethal path to non-action. The time is now for a focused attack on the top five sources of unpredictability in project execution. Honestly, why wouldn't you get started today?

The Great Divide – Technical Leadership and Project Management

2008-12-07T09:52:00.001-07:00

Many organizations have superb technical leadership along with excellent project management. Why then are projects routinely failing to meet commitments? I believe it’s a gap between technical leadership and project management. Project management spans across all the organizational silos, typically without a significant technical depth in any one area. Technical leadership knows the ins and outs of their particular silo, however does not tend to have the project management expertise and skills to properly scope, plan, communicate and assess activities for their particular technical area.

This gap leaves projects with a void of planning expertise that is essential to properly plan the lower level execution details that feed into an organizations overall project plan. The simple truth is that if a project did not complete as planned, something that should have been part of the planning process was left out. What’s being left out of the process? Some of the nuts and bolts details, decisions, deliverable expectations and/or risk management within each of the organizational silos were lacking essential depth. The sub-planning that rolls up into the projects master planning was not as thorough as it needed to be, due to skill gaps between project management and technical leadership.

The expertise disparity between project managers and technical leadership can be addressed in one of two ways. Either the project managers develop the technical skills of each organizational silo (unrealistic) or develop a subset of project management skills within each of the silos. The great divide between technical leadership and project management must be bridged, or organizations will continue down a path of missed commitments while laying blame everywhere but where it belongs. While in reality, fault rests on skill gaps that diminish a team’s ability to fully develop a thorough implementation plan that encompasses the entire organization’s contributions from top to bottom.

The Top Five Obstacles to Predictable Project Execution

2008-12-01T13:53:00.002-07:00

Are there some well known obstacles in your NPD work flow that consistently hinder project execution and you would like them resolved and put behind you? Of course you do, just like the majority of organizations in this business. In fact, if you were to create a list of your top five obstacles they are likely to be similar to every other organizations top five items. Why are they still there today, continuing to disrupt your project execution? Only you can honestly answer that question.

Do you believe your NPD organization is unique in the top five issues that are keeping project execution in a state of unpredictability? You may be surprised to find that your organization is not dissimilar to many others, when looking at project execution bottlenecks. I find it truly fascinating that the top five are so common across organizational, company and international boundaries. We are all dealing with very similar project challenges and for the most part tolerating them as a routine part of our business. The ongoing acceptance aspect is what I find most troubling. There are a few exceptions where organizations are actively whittling back the top five, however it is not the norm, often smothered under a guise of resource availability.

Requirements Closure
Completing a product definition that has a depth of detail, in the time frame necessary, so as to prevent rework of any design activity due to a lack of requirements information. That's the objective, one that needs focused emphasis to remove this as a common source of impact to a project.

Project Planning
This is the activity that will lead to reaching commitment, one that your NPD team believes in and will be able to hit. The problem is it's not happening and the reasons tend to be generalized into a few different bins. Root cause for failing to meet planned commitments must be understood and addressed, whatever or wherever the source may be.

Individual Objectives
On this one each team member may not always know what is expected of them, to the level of detail that will prevent them from reworking already completed activities. Team members may be guessing or making assumptions about deliverables. This type of uncertainty is commonly due to information lacking in the area's of how, what or where. Not a good situation where being predictable is an objective.

Scope Control
A lack of product scope control leads to confusion on requirements. The team often does not know what changes should be made and which ones should be left behind. The engineering team typically will assume if a feature is being discussed, it is a requirement, without regard to schedule or cost impact implications. This one quietly steals away your team's productivity, often without a trace.

Project Leadership Skills
This item involves a deficit in the skills necessary to recognize and effectively deal with the other four items in this list of top five. This is bright technical talent leading a project without the proper skills to manage project details such as requirements closure, detailed planning, establishing detailed individual objectives or managing scope change.

Note: I will be posting a follow up to this post in mid-December on the subject of resolving these top five obstacles.

It’s not our Fault

2008-11-25T13:58:00.000-07:00

When describing the reasons for a project being late have you ever heard the reasons come around to “It’s not our Fault, if only so and so would have...”? Oh come on now, I am sure that has occurred a time or two or more. Have you ever used the reasons yourself? I certainly have in my career. Why is this done? Its just good old human nature, the way we tend to be wired. It let’s me justify continuing on in a problem filled environment and not have to take responsibility for it. Can it be changed, or better yet should it be changed. Yes to both questions, without a doubt.

Without an emphasis on execution issue resolution nothing will ever change. And that means stepping up and taking ownership. You want somebody else to step up and own it don’t you? Of course! What happens when nobody steps up, keeping the blame game alive and well? Things stay exactly as they are and you wake up some day wondering where your business went and then sometime further down the road you wonder where your job went?

If you want to protect your business and your job it’s time to take ownership for problems that you are facing in project execution. The truth is everyone plays a role in non-ideal project execution. The true leaders will step out front and take ownership. Come on, go ahead and stand out from the crowd and get the common, systemic issues put to rest first and then dig deeper. Never stop digging. Get out of your design silo and look at the big picture. Drive changes that will promote agreement and communication of each task what, where and how; the essential ingredient for predictable project execution. Make a difference!

Revving up your Lessons Learned Methodology

2008-11-14T04:53:00.000-07:00

If your lessons learned process is not making a visible impact on future projects it might be time to make some changes to your process. The most common forum for project learning's is post project meetings or postmortems. Enriching the effectiveness of lessons learned should include formal project audits, project diaries, team member interviews, checklists/travelers or the use of an external facilitator. I will expand on a few of these additions below.

Project Audits
Project audits are merely a formalized approach at evaluating a projects execution. Where things did not go as planned, root cause analysis is critical to identify the remedy for future projects. Audits are much more time intensive that the standard postmortem approach, providing a commensurate improvement to the exposure potential of project challenges. A 3rd part audit will provide the greatest benefit due to the lack of any preconceived notions about how the project went.

Project Diaries or Journals
In this case everyone on the project would maintain their own journal of thoughts, ideas and problems throughout the project. This increases the effectiveness of lessons learned since no ones memory plays a role in the quality of the assessment. I don't know about you, but for me anything that removes a dependence on memory is a good thing. This one is pretty simple and effective, assuming you can influence your team to write things down in a nearly real time fashion.

Team Member Interviews
I would merge this in with a formal project audit to improve the depth of the assessments. During the interview you need to craft questions that would enable project challenges to bubble up during the discussion. Most of the effort here is the preparation of the high quality, challenge uncovering questions to pose. There is a lot to learn from the members involved in a project.

External Facilitator
Having someone unbiased by the project will always provide a much clearer vision of how the project went. For this reason I would suggest using someone outside the project to facilitate postmortems, audits as well as interviews. This also brings a fresh perspective to the analysis, always a good thing.

One aspect of lessons learned that is extremely important is this. Any item identified out of lessons learned must generate a specific action that will be tracked to closure. A lesson learned will have little value if it does not lead to a decision and plan for incorporating it for future projects. The objective is not that a lesson has been captured; it is how you have changed your development process based on the learning. Lessons learned must be an action-enabling activity!

Gathering Statistics for Project Execution Improvements

2008-11-13T06:36:00.005-07:00

Below is a link to a short two question survey to gather information about improving project execution in the semiconductor industry. The survey specifically is querying for reasons why organizations may not be improving project execution and also ranks the key sources of project delays or failures. It should take less than 5 minutes and upon completion you will receive a link to monitor the survey results.

PLEASE - Only take this survey if you are in the semiconductor industry.

>>Off to the Survey

An Agent for Change

2008-11-09T09:10:00.002-07:00

Many IC design teams know where the major bottlenecks are in getting a project completed, yet pretty much continue as they have. There are usually some ongoing activities happening but they are typically back burner projects that are easily derailed for “real” revenue producing project. I see this happening all the time, with the primary reason being a lack of time and/or resources. The message spoken is that “improvement is mandatory” while the message supported is “not now”.

It would seem that the only way for real progress is to have a dedicated resource responsible for bringing about improvements in the development process. This resource is hands off for revenue projects; their only mission is driving a continuous, never ending path to improvements. They are the “Agent for Change” or “Change Agent” and their mission is purely in driving and leading change for the better.

The Lessons Learned Lie

2008-10-31T07:28:00.007-07:00

It is likely that every organization has some type of lessons learned methodology in place to assess previous projects. Output of this process is assumed to be positive changes in the way future projects are handled. Some may call this activity project postmortems, however the objective is the same; to identify areas for improvement and to take note of what worked well. Do keep in mind that a postmortem should only be considered a subset activity in an ideal lesson's learned framework.

Most organizations will minimally capture the most obvious project challenge areas via a lessons assessment. Some will implement changes to those challenges and others purely retain a learning for future reference. The more in depth challenges tend to remain elusive to most organizations lesson's learned process, remaining undiscovered because the process to uncover them was not comprehensive enough. In the majority of cases either the lessons learned depth is not sufficient to expose low level systemic issues, or many of the learning's never lead to a positive change in future projects. Where does your organization stand on the quality of lessons learned?

The practice of lessons learned in a New Product Development process is not an indicator that an organization's development process is optimized or even close to optimized; believing otherwise is one aspect of the "lessons learned lie".

The overall effectiveness of the learning's process varies greatly, with most agreeing that there is a large gap between what is being done and what could be done. A lack of time is the primary reason that I hear for limited quality of lessons learned. This is really more of an excuse than a reason. The fact is if there is time for unknown challenges to impact projects in ways that can't even be fathomed, there is certainly time to learn about and fix them. Not enough time to properly assess a project and make changes is another facet of the "lessons learned lie".

Effective top down support of a lessons learned strategy comes down to an unreserved sponsorship of a continuous improvement culture and mindset. Either an organization is doing it, or they are talking about doing it. One provides visible results Lessons and the other is a smoke screen promising better results tomorrow, a tomorrow that never comes. Management support of a high quality continuous improvement environment will be rewarded with a never-ending stream of incremental improvements in project execution.

Toyota has set the standard for making lessons learned work in auto manufacturing. Consider setting a new standard for lessons learned in your organization by means of this clear-cut leadership attitude: positive emphasis on the value of thorough learning's and their application to continuous improvement. If competition is whittling away an organizations future, it's time to come to terms with the "lessons learned lie". Is your organization up for the challenge in revving up lessons learned to become a major player in continuous improvement?

Case Study: Discovery & Solution

2008-10-15T19:10:00.003-07:00

The following describes a case study where formal discovery was utilized to identify the unknown challenge areas within a NPD team.

Situation Appraisal
A product development organization of a large US based semiconductor company was interested in opportunities to provide improved project predictability, a higher throughput and improved first time success. The expectation was that Test, Product Engineering, packaging, project management and design must reach a higher level of alignment to objectives in order to achieve this heightened productivity and the minimization of silicon spins. The business motivation was purely a reduction in time to revenue.

Potential deliverable/receivable disconnects within design, as well as to their product development partners were identified as the primary focus for improving the efficiency of the overall NPD team execution. Projects were progressing at a generally acceptable level; however, there was a desire to identify opportunities to step up the productivity of the team. There were well known issues to be resolved in addition to an emphasis upon finding unknown challenge areas that needed to be understood and resolved. Indications of unknowns were displayed as expectation disconnects between individuals as well as recurrent project redirection that would divert the team from the mainstream execution plan.

Download Full Case Study from the White Paper page at Jorvig Consulting's website.

Managing Towards Change - the Basics of Addressing an Issue

2008-10-13T14:28:00.005-07:00

Making a change to address an workflow issue can be a fairly straightforward process, assuming some basic concepts are followed. A change activity must start off with a clear objective; be careful to keep any bias towards solution out of the objective. An objective must be purely results oriented such as "reduce requirements closure time by 30%" or "implement a scope change process that formally addresses any change in requirements and provides continuous clarity of requirements to the team".

People will be the most challenging aspect of a change because of their emotions, notions, passions, fears, opinions and motivations. Additionally each person is a firm believer that they have the right solution to what's ailing the organization. Your mission is to align the majority of them to a common solution, one that they believe in. Failure in achieving this and any change is destined for the change graveyard. Inclusion over exclusion of individuals must be a priority, no matter how painful that may be. The pain of dealing with those excluded will be far worse later on than it will be by engaging them from the start.

Another major step is clearly identifying what it is that you are doing now; that is what is the current process of today. One of the greatest errors in implementing a change is to make any assumptions about how things are currently being done. You must investigate it, map it out and gain consensus that you have captured the "as-is process". This exercise in itself will likely be enlightening, with a lot of "I did not know you did that" or "I did not know you needed that" along the way. A success here will make a smooth transition to solutions. I always suggest formal discovery as a predecessor to defining the as-is process, thereby ensuring that no activities, decisions or deliverable expectations are buried and left behind.

The final step is to make the necessary changes and finalize consensus. The problem areas to be resolved should be fairly obvious; assuming some quality work was completed in defining the "as-is" process. Work out the solution possibilities in a brainstorming type fashion and then whittle them down to a largely agreed upon solution. Odds of 100% agreement are slim, although if you practice inclusion over exclusion of members, everyone will understand the behind the scenes reason for a decision. Those that participate will be apt to respect the decision, even though they may not fully agree with it. Document your changes, update any process guides and rollout the change. Follow this simple formula and you will successfully change something for the better, even when many believe it could not be done. Now do this again and again to become a practitioner of continuous improvement. Even better, let the ideas for change flow from the bottom up and then facilitate the details, decisions and implementations. Become an agent for change in everything you do, every day.

Breaking Down Barriers to Enable Positive Change

2008-09-30T07:00:00.003-07:00

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

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

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

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

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

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

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

2008-09-25T10:29:00.006-07:00

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

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

Any thoughts on this?

The Role of the Three Silicon Testing Categories

2008-09-15T10:40:00.003-07:00

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

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

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

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

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

What Motivates us to Look at Things Differently?

2008-09-05T15:05:00.005-07:00

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

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

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

Testing - From Product Concept to Production

2008-09-02T07:33:00.005-07:00

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

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

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

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

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

Mitigating the Major Sources of Project Impact

2008-08-15T05:00:00.004-07:00

I want to expand upon what was found to be the major sources of project impact from our survey results published at the end of July, 2008. These items were found to play a substantial role in the overall project execution success. A focus on these chief contributors should provide a visible and positive impact to a projects execution flow towards early revenue.

Requirements Closure
The primary reason that requirements closure is an issue is because this key step is likely not being managed to meet the teams expectations, it just happens. This is a major milestone in a project and someone must own it, identify expectations, track actions, track deliverables, manage risks and drive it to the agreed closure or it will drag on for months. This significant milestone is the source feeder for the entire planning process and will therefore be your largest contributor to project unpredictability. For information on a formalized process for requirements closure please see the Quality Function Deployment organization.

Individual Objectives
This one has to do with the crispness of individuals deliverable expectations. Is a designer just delivering a schematic or are they delivering a design that includes a package of specific deliverables, analysis activities, test modes and verification steps to meet a specific set of requirements? The team must agree to the detailed deliverables from all activities and then manage towards meeting them. This includes deliverables to and from product engineering, test, project management, marketing and the business as well as each designer. You never want anyone guessing about what they are delivering, where they are delivering it, who they are delivering it to and when they will be delivering it. Ignore the deliverable details and the team will be quietly reworking things to make them right for themselves, further contributing to project unpredictability.

Feature Control
Known as scope expansion, scope control or feature creep; this is the ever-evolving feature set of the project. Change is not necessarily good or bad. However, changes must be visible, have any project impact identified, have a benefit identified and be agreed upon by key stakeholders. The source of a change can be both external and internal; in either case the monitoring and approval must be the same. A change is rarely ever free, although it may be appear that way through a limited view of project impact scope. Be sure to have a process in place to monitor and approve all changes to prevent them from quietly stealing away your time to revenue.

Project Planning
Project planning is not solely the tasks, dates, and resource definitions rolled into a planning tool. A thorough plan must include the deliverable expectations to improve upon the clarity of individual objectives, another large contributor to project success or failure. Design guides can provide an ideal source for this type of information and can be a simple word document or an elaborate online system. Of great importance is that something exists to manage the details of individual deliverable requirements. An individuals deliverable contributions must be part of the planning process and be completed prior to commencement of significant project activity.

Survey Results - IC NPD Project Challenges

2008-07-30T12:00:00.011-07:00

Interested to know what project execution challenges New Product Development (NPD) teams in the semiconductor industry are experiencing? Back in June I initiated a survey to research semiconductor development project execution and I will be sharing the results with you in this blog post. Thanks to those who spent the time to respond. The survey is still open here if you wish to participate with only 7-10 minutes of your time. Those who complete the survey receive a link, allowing the monitoring of real time results.

This survey targeted three specific areas for new product development projects in the semiconductor industry. The information collected related to project overruns, scope change and the positive or negative sources of impact to project execution. Click on the images for a full size view of the data.

Project Overruns
Estimating a figure for percentage of average overruns is not a simple task, considering that projects will have different levels of difficulty and risk. Given this complexity I was surprised to find a fairly consistent response for schedule overruns to be in the 10-30% range with a good average of 20%. There were a few outside the normal distribution, however the average was well distributed around 20%.

For cost overruns, I clearly did not have enough resolution in the 20-50% range. Most of the responses landed on the 20-50% figure, which should have been further broken down into two or three ranges. The distribution was again fairly consistent with a few inputs outside of the standard deviation.

Positive and Negative Impact Sources
These questions were ranking a list of 10 sources of impact to project execution. The largest contributor to project impact was the overall requirements. The surprise for me was the project impact due to customer involvement. That was one of lowest contributors to project performance, indicating the customers involvement plays a minimal role in project performance relative to other factors.

Also noteworthy was where tool issues showed up on the list. The lower ranking relative to other contributors confirms that improving tools will not provide a significant benefit to design execution, relative to other more dominant factors. The individual objectives/deliverables, overall requirements, planning and project leadership will provide a more significant impact to a design teams productivity than the tool flow.

Scope Change
These two questions intended to identify the level of feature creep that occurs on projects. Feature growth appears to average around 20% and feature shrinkage comes in at just under 10%. Again, this question was probably difficult to pin a number on, however the data was surprisingly consistent.

Around middle of this month there will be a continuation of this post with discussion on mitigating the negative sources of impact noted in this survey. Keep an eye out for that topic.

Do you Know Where the Roadblocks to NPD Revenue are?

2008-07-17T21:25:00.006-07:00

Do you know the quiet, behind the scenes roadblocks that are delaying your New Product Development (NPD) revenue plans?
How much time are your engineers spending quietly fighting with tools or reworking information they received to get it into a form they can use? Maybe there is some specific type of information someone needs that would significantly improve the timing or quality of their contribution. Awareness of project execution barriers such as these is critical in developing solutions that enable a predictable and streamlined path to new product revenue. Uncovering the hidden execution roadblocks will prove elusive for most organizations, unless a focused effort and a proper set of detective skills are applied.

Learn more about finding
the elusive roadblocks here.

Commencing on a Path to Continuous Improvement

2008-07-13T09:30:00.001-07:00

Let's assume we are ready to break out from the pack and shift our efforts to include a real sustained, continuous focus on improving for each and every project. How would we do that? Many car manufacturers have attempted this mind set shift with varying levels of success. It's not an easy overnight change. It's top to bottom change in the way we approach projects and will take multiple projects to migrate the culture of the organization in this new direction.

The absolute first step is to define what continuous improvement is to be for your organization. What's the mission for continuous improvement? Write it down and share it, review it, and gain a majority consensus from your team as to the mission. When you say continuous improvement, what do you want that to mean to each member of your organization. Is it an unenthusiastic "yeah, we are working to improve" or is it a wholehearted "yes, for every project we engage upon we have three improvement actions we do. We can't start a project without these in place". It's a culture change and it requires routine nourishment from the top to thrive. Consider how you could inspire a passion that will propel continuous improvement from project to project.

Continuous Improvement defined: Uninterrupted, without time boundaries, without content boundaries, without intermission. It's not just deciding to look at how your last project was done or how you are doing a specific task. If at some point in time you decide to look at how you're doing things; that is not continuous improvement. Continuous improvement is not a snapshot look at your situation; it's a never-ending pursuit of removing the barriers to NPD execution excellence.
Continuous improvement is:

Postmortems with actions and tracking of action closure for every project.
An environment that seeks out and generates actions for doing things different.
An open door policy on the subject of project waste and always taking action for mitigation of that waste.
An emphasis on "why not" instead of "why" when looking at doing things differently.
Iterative experimentation for project improvements. This is real trials of ideas, not paper exercises.
An always, never ending search for procedural improvements that benefit time to revenue.

If you are not a believer in continuous improvement your team will sense this and any potential benefit will be lost at the starting gate. You must become a believer yourself. Develop your continuous improvement passion within, before engaging your team. Best of luck and do let me know how you are doing on your quest to stand out from the crowd on NPD execution.

Why or Why Not?

2008-06-30T16:53:00.004-07:00

If you were to hear a proposal for a different path or direction in approaching a project would your initial response be more of a “why” or a “why not”? One response is indicative of an attitude towards continuous improvement while the other signals a belief that things are OK. If we find ourselves routinely asking “why” to change we are sending a message to our team that things are OK, or at least good enough, thereby minimizing valuable opportunities for improvements. A continuous improvement culture is an essential ingredient of continued, long-term success and is the subject for this posting.

Why would we decide to try something different? The path to different is peppered with unknowns, is an uncomfortable journey and has an outcome that is difficult to predict. Staying the same is fairly comfortable and is reasonably easy to predict, at least for now. So again, "why" would we want to change anything? Only if we reach the conclusion that staying the same is going to somehow negatively impact our future. I would think the possibility of losing something important (jobs, revenue, customers, market share etc.) is a great motivator for change, forcing our line of thinking more towards "why not" when considering alternative tactics for managing NPD projects.

How has the semiconductor industries approach to new product development changed over the last 15 years? I would surely think there has been plenty of motivation to improve during this period with all the outsourcing, off shoring and head count reductions that have occurred. Although I am not sure the industry has hit the pain threshold yet. Other than new tools/flows, I do not see the majority of design organizations making any significant changes in the way they have approached design projects. Multiple spins and schedule slips are still accepted as the norm, with reasons usually attributed to tools. "It's just the way it is" thinking lives strong. Through this quiet acceptance there is a continuous message that we we must improve. Interestingly, specific actions for perking up execution tend to be largely downplayed, or given some superficial hand waving attention because we don't have time for such indirect activities. We are caught up in the "why" of change.

Let's step back for a moment and take a look at the US auto industry. Was it tooling capabilities that have eroded their market share year after year or was it the culture? No question the answer is culture. Take a look at Toyota's approach to both development and production. There is a lot to learn from them, if and when we are ready to do so. The employees on the floor are encouraged to continually be challenging the way things are done through real experimentation. The execution focus is always on ideal, a goal that is never reached, although continuously strived for. No one will dispute the fact that their approach has brought them great success. A culture that embraces "why not try something different" has driven Toyota to become a standard for execution excellence. Consider the Prius. A few years back I am sure there was plenty of "why" type thinking going on at manufacturers considering a hybrid type concept, and today those same manufacturers are all playing catch up to Toyota.

Now back to the semiconductor business. Based on my research the majority of design organizations believe they are executing on projects OK, or at least good enough. In fact, the bulk of teams do not regard a concentrated effort on continuous improvement strategies as a practical use of their limited resources. In our industry "why" is a common response to any activity related to changing the approach to projects. For Toyota I would expect the typical response to a question about trying something different to be "why not". How much will we need to lose before we get rattled enough to convert our mind set to one of "why not" when considering changes to the way we execute our NPD projects?

Improving or Reengineering your NPD Process

2008-06-17T12:35:00.002-07:00

Once you have decided that your NPD execution will benefit from a focused effort to modify or reengineer your process, there is rewarding work to be done. I have several ideas to get you started. Engaging in a process renewal effort must be broad in scope and include participation of the entire development team. Engaging upon a NPD process renewal with a limited scope of discipline participation is guaranteed to provide limited success. Don't seek justification to limit participation, seek a means to expand it.

Thoughts on Managing Change
The most important concept to address when engaging change (new processes) is that the team will be skeptical of this activity simply because it will be different. Change will always create anxiety among the team member's, an uneasiness that must not be written off or it will definitely impair your plans. The most common reasons your team will be uneasy about change are as follows:

They may lose a capability that is important to them.
They do not understand why this process change is necessary.
They disagree with the risk/benefit of a process change.
They fear not having the relevant skills necessary to work in the new process environment.

These concerns must be mitigated to produce and enable a successfully deployed process change. Address these items well and your team is certain to be energized about the possibilities to improve his or her productivity.

Start with creating "As Is" NPD Process (What you are doing today)

Brown Paper Session - Hang a large sheet of paper on the wall and use post-it notes to define each step in the process. Involve a cross broad section of your NPD team in this process with the objective of mapping out the flow of a project from concept to production release using the post-it notes (tasks/activities) and arrows (flow). The completeness and understanding of the existing process will become evident during this exercise, a very enlightening experience.

Discovery - This activity is essential to uncover the roadblocks (unknowns) that may exist in the current NPD process. Individual team members know how roadblocks are impacting their productivity, although they may not be able to see that there is or could be a solution. Formal discovery is best handled as one on one discussion using questions specifically tailored to uncovering roadblocks and/or deliverable issues. Share the discovery learning's with your team. More on Discovery

Project Post Mortems - Use project post mortems as a forum to expand learning's about any deficiencies in your process.

Finish with "To Be" NPD Process (Your updated or reengineered process)

Brown paper session - Once you have gathered all your inputs about the existing process I would suggest once again visiting the brown paper process that was created during the development of your as is process. Again pull the key team members together and plan out what your new process needs to be. This is best concluded over a period of several days, making liberal use of timeouts for members to reflect. Once this process is completed capture your process in a tool such as Visio for final documentation.

Process Containers - The medium to be used for your new process is an extremely important step for your successful deployment. It must be something that is easily used by the team, all of the team. The worst thing you could do with your new NPD process is capture it in a form that is not highly accessible by the team, thus leaving your well developed process to gather dust instead of providing the intended benefit. Process containers that I have seen as fairly effective for this purpose include design guides, design travelers, PIEmatrix and possibly schedule templates, although that's a stretch due to limited accessibility.

We are doing Okay - Why Should we Rework our NPD Process?

2008-06-05T10:39:00.002-07:00

Statements such as "We are doing okay, so why should we need to rework our NPD process?" are all too common across the semiconductor industry, yet many organizations are challenged in completing projects as planned. How can this be? In the majority of cases design teams will place the reasons for project execution difficulties on design tools with explanations such as they did not work right, had bugs causing delays, did not have the necessary capabilities or failed completely. From a designer's perspective, tools are commonly identified as the reason for project slips.

There is no question as to the tremendous value of design tools in the completion of a chip project; however, tagging all the project execution issues on them leaves significant improvement possibilities out of reach. A belief that project issues are principally tool related minimizes a localized problem focus, purely because they typically can't be fully resolved within an NPD organization. Hence things stay as they are, project after project due to a belief that the source of the problem is out of reach. An unsubstantiated assumption that all issues stem from tools breeds a belief that project execution is doing okay or "good enough", merely because tools are out of the NPD teams jurisdiction.

If you require real improvements, it's critical to look beyond the tools for answers. Below are the major execution issues I have seen from working with many design teams over the years:

No scope change control in place - Feature Creep runs free to silently steal away your team's productivity.
Unmanaged requirements closure - The process of deciding what to do drags on and on, eating away development time.
Deliverable disconnects between deliverer and receiver for a given task - team members are not getting what they need to be successful.
Plans that are based on imaginary resources/capabilities that did not materialize - fictional expectations created surprises in the midst of project execution.
Sense of urgency that falsely justifies corners to be cut and allows project launch without a proper roadmap (the plan) to successful production. No risk/benefit analysis completed to justify these decisions.

Tool problems are not even on this list! Why not? Because tool issues would be covered under plans that assume imaginary capabilities, item four of the list. Why would a project be approved if the tools could not produce the required results? There must be action around tools expectations and validation as part of the project planning practices and that's a really a process related issue, not a tool issue.

Now back to the original question: Are things really okay or are there some process related activities that will bring positive results? Heroic efforts to make tools work mid-stream in a project will never match the results that can be achieved through a well-developed process; one that is communicated, includes tool/flow expectations, is easily followed, is agreed upon and is believed in.

Invest Time in Discovery to Realize Compressed Time to Revenue

2008-05-14T06:09:00.003-07:00

Having been successful in making the tradeoff between what's important and what's urgent from my previous posting you now you have allocated time to invest in a better tomorrow. How will you be investing this reclaimed time? I am certain you have a list of items in mind that you have wanted to do for a while; a list comprised of the known issues that impact productivity.

There are changes we know that will bring improvement and then there are the deficiencies that are silently stealing away cycle time, the unknowns. If an improvement effort is to realize expected results, both the known and the unknown roadblocks must be addressed. For those that have been reading my newsletters for while, or have attended one of my workshops the concept of an unknown is not new to you, although the definition may still be a bit baffling.

The simplest definition for unknowns in the NPD process is that they are essential activities or deliverables that are largely unknown to the vast majority of the team. By definition they are unplanned and untraceable, even though they are essential to a products success. Essentially they are hidden and unmanaged roadblocks to your NPD flow that will manifest themselves as unexpected surprises, spawning a flurry of activities to "make things right". Interestingly, unknowns also tend to be systemic issues that are repeated project after project; therefore keen detective work is in order to bring them to the surface, where they can be managed.

Investing time on important activities that improve your NPD time to revenue must include time spent on finding the unknown roadblocks in your development process. A formal discovery activity is the best course of action and should be the beginning of any renewal or reengineering effort for your NPD process. The following three links will provide additional insight into the discovery of unknown and unmanaged activities:
Discovery & Solution Newsletter
Improving Project Predictability (Chip Design Magazine)
Enable Predictable Design Execution by Looking Beyond Tools and Flows (Embedded Intel Design Magazine)

Any NPD process re-engineering must begin with formal discovery. Failure to do so will leave your shiny new process with holes in it, leading to continued surprises on your projects and the flurry of activity to "make things right".

Getting a Handle on Urgent Matters that Run Wild

2008-05-01T07:23:00.001-07:00

Here is an example of misplaced urgency I am sure we can all relate to. You are at the store waiting in line to pay and the phone rings. The clerk answers the phone, talks for a bit and then heads off to go find some information for the caller. Here we are, wallets in hand and waiting to improve the stores immediate revenue numbers and the urgency was transferred from taking our money to chasing a possible future opportunity. Was that urgency transfer proper? What was more important here? This is a great example assumed urgency.

How many times in a day are you redirected to something urgent, something that was not on the list when you awoke in the morning? I will place an educated guess that it is easily in the 1-5 range. As soon as an urgent matter comes up we will typically drop what we are doing and tend to it immediately, leaving what we wanted to do drifting off into the land of unimportant stuff. This is repeated each an every day.

At the end of the day we have this nice list of fires that were extinguished, tasks that we had no intention of dealing with when we popped out of bed. The tasks that were on our planned list, the things that mattered most, took a back seat yet again. Items that we were working on to make things better tomorrow, once again did not move forward today. We are drained, yet still lacking a sense of solid accomplishment for the day. Is this a reality for you?

None of us like to operate this way; we all want to do our best job and that means dealing with the unexpected urgent matters as expeditiously as possible. As managers, we take ownership of the urgent matters and drive them to closure. It's our job to make sure these things are dealt with. Let me pose a couple of questions:

Is it our sole responsibility to own the urgent matter or would the organization better served by delegating the responsibility, empowering another individual to resolve the urgent matter, freeing you up to work on what matters?
Is the urgent matter really more important than the task we were working on, the one that matters most to the organization and ourselves?
Should someone else's sense of urgency directly translate to us without any thought as to it's validity?

The truth is we always have a choice to make when an urgent matter comes up. However, we are programmed to react to a sense of urgency by dropping everything and take care of the matter immediately, leaving ourselves with little time to do what's important to the organization; the plans for a better tomorrow that never seem to get completed. It is a choice between feeding a fire-fighting environment or nurturing an empowered environment of continuous improvement. Upon waking tomorrow resolve yourself to working on what's important, not just what's urgent and see how this impacts your effectiveness.

Example ROI Calculations for Productivity Projects

2008-04-08T10:37:00.009-07:00

I wanted to share you with some examples of ROI calculations I have completed to get you started down the path of planning your improvements as and investment that will positively impact to your revenue stream. This post is a follow on posting to a previous posting on the subject of "Investing in NPD Excellence" dated 3/31/08.

The main components of an ROI analysis for a semiconductor productivity improvement project can be seen below:

Net investment in the improvement ($)
Expected timeline impact to a NPI (weeks)
Expected revenue from the new product ($/week)
Product margin (%)
NPD Burn Rate ($/week)

With the above figures on hand you have everything needed to calculate ROI for a given process improvement effort. As an example I have created a set of curves below that assume an investment of $75K and 40% margin revenues ranging from $25K/wk ($1.3M annual) to $200K/wk ($10.4M annual). With the lowest revenue product a three-week improvement is the point where the $75K investment pays off and begins positively impacting the revenue stream, it becomes profitable.
The next set of curves is the same as the previous one except that the improvement investment is $150K. In this case the lowest revenue product requires a six-week improvement to yield a net positive, a time easily recovered if the improvements implemented removed a silicon spin from the path to production release. The higher revenue producing projects easily show net positive with as little as three and a half weeks or less in cycle time improvements.
In both of the examples above the curves are representative of the first product development after an improvement implementation. Assuming the improvements stay around for future products the ROI increases considerably, since there are no new improvement investments while follow up projects reap the full time-line improvement benefits of the initial project.

Investing in NPD Excellence

2008-03-31T10:43:00.002-07:00

Frequently when an organization identifies the possibility of an improvement to their process the very next concept is one of cost. This then leads to an inability to afford it, or a limited ability in being able to "sell" management on the idea. Almost immediately the improvement concept becomes relegated to the fact that it is solely an expense item and any possibility of a quantifiable net positive is lost. Return on Investment (ROI) analysis is routine for any product related project being considered by an organization. Why does this not typically hold true for an improvement project?

Any improvement project should only be considered if it is expected to bring value, a value that is minimally characterized as a reduction in development time. Compression of the timeline to production release creates two fiscal components that positively impact profits. The first is a decrease in the expense for product development and the second is the additional revenue associated with an earlier production ramp. The total additional income due to a realized improvement becomes the sum of saved development costs plus the early production income. There are also expenses associated with any improvement and these subtract from the saved development costs and early revenue to provide a net additional income that can be described as a ROI.

Obviously to generate an ROI figure there must be a well thought out analysis of the improvement effort to produce an expected timeline savings. This is a complicated endeavor, however I maintain this is essential to properly frame any productivity effort where realization of specific results is the objective. This is the beauty of an ROI driven initiative given that it will inhibit an easy path to fictional end results. There must be quality homework completed to scope both the intended improvements and the expected NPD time reduction, effort that is essential to properly establish objectives and measurement criteria to be utilized for a believable ROI.

Any improvement effort that fails to identify an ROI will be perceived as a pure expense, have weakly framed objectives and be easy prey to cancellation or delays. Tie the effort to a realistic ROI and enable the healthy emphasis, visibility and direction that will result from a project that is defined to positively impact business financial objectives. Include this information in a fully developed business case and you will have created a compelling case for a your productivity improvement, one that gets noticed, funded and supported to completion.

Process Improvement = Cycle time improvement = Increased Revenue

It's worth investing in!

Sampling of PM Practices in use for IT Projects

2008-03-16T14:23:00.003-07:00

For your reference I am providing some information about the formal Project Management practices and methodologies being utilized today in IT. I believe there is much to be learned about this industries approach to PM and there is definitely a level of applicability to the projects we support in the semiconductor world. Your takeaway from the information below will be a better understanding of the meanings behind the most common Project Management buzzwords you will find in the literature today.

PMBOK (Project Management Body of Knowledge)
This is the standard implementation of structural project management in the US as developed by the Project Management Institute. There is a certification process for a PMP, PgMP and CAPM levels of project managers. Please see http://pmi.org for more information about this methodology for managing projects.

Prince2 (Projects in Controlled Environment)
Prince2 is the 2nd generation of a structured methodology for managing a project that was developed in the UK. Essentially it mandates that any project must have a controlled start, a controlled middle and a controlled end. There is training and exams much like those of the program management institute. More about prince2 may be found at http://www.prince2.org.uk. Wikipedia also has some good information at http://en.wikipedia.org/wiki/PRINCE2. For literature on this methodology please see http://www.apmg-businessbooks.com/bookshop/bookshop.aspx?catID=3.

Agile
This was primarily developed for software development teams and the premise is rapid spins and delivery of the software throughout the development process. It focuses on multiple deliveries of smaller, fully tested subsets of the final product. This produces end customer sub-set deliverables early while the team continues iterating and expanding functionality until the final product is realized. One key concept of an Agile approach is that the project details are planned out incrementally as the project progresses, allowing a system that is much more capable of adapting to scope change. When in an environment of high innovation this approach may produce benefits over classical Prince2 or PMBOK structured approaches. For more information please see wikipedia at http://en.wikipedia.org/wiki/Agile_software_development.

Scrum
Scrum is a methodology that is typically associated with Agile software development although there is no hard requirement that I can see. It's really more of a PM methodology that employs a scrum master in place of a project manager. The premise of this approach is a series of short 2-4 week sprints to complete a predefined set of tasks. The teams focus purely on the sprint items during the sprint period and have daily meetings that cover what was done yesterday, what you will do today and what obstacles are in your way. There is also an emphasis on risk assessment and mitigation throughout the project cycle. A nice quick guide on this process can be found at http://www.softhouse.se/Uploades/Scrum_eng_webb.pdf.

Contrasting the PM Practices of IT and Semiconductor Businesses

2008-03-03T13:06:00.005-07:00

We all have a moderately good knowledge of formal Project Management and most of us will answer positively if asked about the use of a formalized management process on projects in our organizations. My observation is that most mature semiconductor business units have embraced formal Project Management at the business level but it is much less practiced, or even acknowledged in the engineering teams themselves. This is a key difference between the semiconductor and Information Technology worlds. IT businesses largely embrace all aspects of formal Project Management for New Product Development while the semiconductor businesses typically have a PM system in place, although the level of implementation is usually far less. In fact most of the new project management philosophies have their roots in the IT industry, further strengthening their position as a PM driver and innovator.

Why would there be such a gap in the level of formal Project Management commitment between these two industries? Is it the size and complexity of the projects? Is it management's commitment to Project Management? Is it that engineering team resistance is greater in the semiconductor business? Good questions, although the answers are of little relevance. Of major importance is that IT teams believe in fully engaging formal Project Management techniques as the best path for their projects success. This fact is something that those of us in the semiconductor business should take note of, as the demands for faster and better product releases (revenue generation) drives us down a path of continuous improvement.

We must candidly assess the effectiveness of formal Project Management for our businesses. If projects are honestly exceeding the needs of the business then it is a safe assumption that the PM implementation in place is working well. However, if projects exhibit a level of unpredictability and delays I suggest a serious look at the depth of Project Management practices in your organization. By depth I mean how far the formal Project Management reach is into each of your NPD team disciplines. If an organization has formal Project Management in place at the business level while the planning and tracking of projects for product engineering, design, test and so on does not fully embrace formal PM practices, then it is improbable that a business level Project Management implementation will be successful. Garbage in, garbage out type of analogy would best describe this scenario.

Ideally there must be an individual that understands formal Project Management practices within each of your disciplines; someone who is experienced in the principals and knows both the technical activity flow and the technical tradeoffs. This individual would ask the tough questions and can visualize the sequence of tasks along with the required deliverables/receivables for each. Essentially you are looking for a project manager type mind set within each discipline that can properly identify and frame the project activities for that group. Either there is a project manager that has the exceptional background to properly assess and plan the activities for all disciplines, or that talent must be developed within each discipline to deliver accurate project planning and tracking data to the project manager.

Six Obstacles to Design Team Victory

2008-02-13T19:05:00.003-07:00

Here's my list of items that are sure to ruin a victory for a design teams project, even with a harrowing effort by the team. These are the biggies and if you conquer them, your team is sure to enjoy repeat project victories.

Lack of Best (Same) Practices - Enough said on this subject from the previous posting on practices dated Jan 31, 2008.
Lack of Scope Control - Things change and they always will. The big question is "are you in control of when something is changing or even if something might be changing?" Keep a watchful eye on your internal team also. Things come up on a project and are declared a no-brainer thus grandfathered in with minimal fanfare, if any at all. I have yet to see a no-brainer change that does not end up causing some problem downstream due to lack of proper assessment and communication. On a project, a change is never free!
Lack of Requirements Closure Management - Requirements closure can take longer than the design project itself and I have seen this happen more than once! Project execution may get kicked off early due to a sense of urgency, allowing the team to go down a dead end, return and then go down another path or two wasting precious time. If you want that project in the shortest amount of time you need an early focus on the requirements, not on getting your designers busy. Capturing schematics, doing layout and running simulations feels like progress but it's only real progress if it is not redone later.
Lack of Design Breakdown Requirements - The chip level requirements must be broken down into engineering requirements at the sub-block level. The design is a system that must formally spawn the lower level block requirements. Lower level engineering requirements include electricals, functional, verification and test plans/modes. Design Guides work well as the engineering information containers for the lower level requirements breakdown.
Lack of a Plan - Statements such as "it will take us about 6 months", or "we need it in 6 months" do not constitute a plan and it will never work for you. Plan out how you will get there, what are the risks and their mitigation strategies, what each of the tasks are and who is going to do what. Follow this by identifying the task lengths and build up the plan in a project plan tool (see our Plan template). Once you have it in the planning tool you can then do what-if tradeoffs to see how resources or de-featuring can improve things. Do your homework and then commit to the plan only when there is a means to get there. This becomes the Plan of Record for the project. Change anything about requirements or resources and the plan must be updated. Remember, nothing is ever free.
Lack of Full NPD Team Participation - CAD, TE, PE, packaging, customer, PM, Biz Ops, Marketing are all part of the New Product Development team and must be assigned at project kickoff. Don't pull in your product and test people a month before tapeout; engage them at the project start for their input on design requirements for test and production worthiness. Leave them out and you are likely to have a silicon spin purely to support production issues; again several months delay and lost revenue that did not need to happen! Include a program manager that knows design and can manage the design related details and ask the tough questions; the ones that pull the design team into the planning process. Include CAD resources as part of the project. If you have holes in your tool flow you must plan the fixes as part of the project and track them just like any other project task.

Design Team (Best) Same Practices

2008-01-31T18:51:00.000-07:00

Design team practices are the "how" of a team's path to production release of a product; key emphasis on production release. Creating product samples has never been a cash machine for the business that a design team supports. A project objective must always be revenue; as a result our vision must always be on production release along with costs that meet the business case. Focus on anything less and any decisions, plans, scope or product requirements will be crippled from the beginning; culminating in an unplanned spin costing several months and lost revenue, just when production was within reach.

OK, off my soap box now and back to practices. Practices are typically called Best Practices because we want the "how" to be our absolute best. Of far more importance than being "best" is that they are the same. Everyone on the team does the same things, delivers the same items in the same format, captures the design the same way, uses the same verification strategies and so on. If the "same practices" are done well, no work will ever need to be redone. That's the litmus test for your practices. If the team is being surprised and reworking deliverables for a given project, they were not doing things the same. The degree of surprises is an excellent measurement of the quality and communication of your practices.

So what needs to be done the same? I guarantee most of the practices problems will be related to the specific deliverable out of a task. If there is a surprise on a project it is because a given task deliverable was not in sync with downstream expectations. The concept of Same Practices means alignment of all of the project deliverables to a consistent and agreed format, content and location. For a list of some common practices note the visual to the right.

If everyone is to deliver to a common practice the team needs to know what they are and they must have participated in the practices development or you have failed at the starting gate. Think Knowledge Management (KM) as the means for aligning your team to Same Practices. There is a plethora of suppliers out there that can make this easy for you. Wiki's, web collaboration tools, web project management tools and so on. If you want a list of suppliers send me an email and I will send you the links I have. One interesting point about surprises is that you may never know they happened. The engineers generally just take what they get and make it right while quietly slipping behind on their task. Implement Same Practices or endure a continuing rash of surprises that will quietly steal away the timeline to product revenue.

Managing Excellence in Design Team Execution

2008-01-23T15:15:00.000-07:00

In these highly competitive times everyone is extremely busy, making it difficult to find time to step back and look at how things are being done. At the same time a team that is to approach execution excellence must devote the critical time necessary to define a roadmap and strategy for improving their design processes. We have a workshop solution to kick start the thought process and generate immediate concepts that a design team can implement on their projects thus enabling predictable and productive project execution.

Please follow this link to learn about an 8 hour team investment that will yield a newfound understanding of the path to execution excellence - A one day workshop at your site, with your actual team, specifically developing enhancements to the teams development processes.

"Change nothing and nothing changes"

This workshop makes an excellent kickoff to a process renewal effort.

Seven Leadership Actions to Execution Excellence in 2008

2008-01-02T13:35:00.000-07:00

What are your plans for 2008 that will make this a better year for project execution? Are you writing them down, making plans and taking actions to move them from your wish list to a realistic and achievable goal list? Without a clear set of written improvement objectives and concrete plans to make them a reality, I would not expect 2008 to be much different than 2007. Written plans will make the difference between the status quo for 2008 and improvements that will be noticed. To get your goals started I have created a list of seven sure-fire actions that WILL improve your project execution in 2008.

Leading your Team To Execution Excellence in 2008
Producing a notable positive shift in project execution for 2008 will take work; hard work and at times it will be painful. If this is your 2008 objective it will take an honest, thorough assessment of what has not been working well; I suggest you suit up in your best armor and send your ego on a vacation for a while. Going through a thorough assessment of how things are really working and implementing obvious improvements will require you to hone your leadership characteristics and put them into action. Note the diagram below that identifies the different attributes for managing vs. leading a team. Displaying a higher degree of the leadership attributes will provide the essential guidance to developing execution excellence for your team.

Are you planning for simple incremental changes in 2008 or are you ready to make changes that will be easily noticed due to the improvements being on a scale that can't be missed? Ready to break some rules and operate in a mode that is uncharacteristic of the old? Ready to ask the tough questions? Ready to learn from your team? Ready for taking some risk? What is holding you back? Understand the answers to these questions and begin the journey from managing team execution to leading team execution.

For 2008 will you be managing the team or leading the team down a path to new levels of productivity? One path logs an acceptable rating while the other is a path that logs a striking score.

Seven Actions that will bring Execution Excellence in 2008
Below are seven activities that will bring your team visible differences in their product development execution. Do these well; really do these well and your team can't help but show a visible, higher level of execution efficiency. Lead your team to a noticeably higher level of execution excellence.

1) Listen - Spend some time with each member of the new product development team (design as well as non-design) and listen to what they believe is impacting their ability to perform better. Act on what you learn.

2) Break some Rules - Question, challenge, and stir things up. Being comfortable has no place in an organization that is going to display project execution leadership. Why are you doing things the way your are? The status quo will have no place in an organization that is living and breathing excellence in project execution.

3) Map your Process - Involve the team, learn how your doing things and map them out. Identify changes to the process; break some rules. Think outside the box; brainstorm with the team. Involve everyone on the NPD team, not just design. The final deliverable out of this activity must be a process that everyone believes will bring a new level of project success to the organization.

4) Don't over commit - Commit only after doing your homework. Be creative, be aggressive, keep your vision broad and commit only when you have a means to get there. Due diligence on plans and schedules will reinforce predictability for your project. A misplaced commitment will never benefit the team or the business; it will only erode confidence in the teams ability to execute.

5) Manage Scope - You must have something in place to manage the inevitable changes to project scope. Scope change is a reality that will exist for every project. Setting your team apart from the norm will be a process that manages the scope decisions well. That process must include changes from within the team as well as changes from the customer. Keep the Feature Creep Wildfire in control.

6) Learn what you don't know - "Those that know, know they know. Those that don't know, don't know they don't know." You must always assume there is something to be learned about roadblocks to your project execution and to find them; you need to listen to your team to uncover them. Keep a keen eye out for the unknown. It is always there, waiting to disrupt your plan. More about Finding what you don't know.

7) And Finally Seek Outside Input - This is essential to prevent a stale, incestuous view of your organizations best practices. We are too close to our situation to see the possible errors in our ways. An outsider can be someone from a different organization within your company, another company or a consultant. Most importantly it must be someone that your team believes has no loyalty to anyone in management and/or the business operation itself. The team must view this individual as unbiased and non-threatening, to be able to accurately assess the situation.

Complete Survey and Get a Chance to Win 5 Hours of Virtual Design Manager

2007-12-23T06:43:00.000-07:00

Completion of this survey will allow your entry into a drawing to receive free 5 hours of our Virtual Design Manager Service. The information you provide will help us better position our services to meet the needs of New Product Development teams. Please respond by the end of 2007 to be entered into the drawing. Be sure to follow the instructions at the end of the survey to enter the drawing!

Off to the Survey

The Essence of Collaborative Teams

2007-12-17T12:23:00.000-07:00

Let's begin with a definition for collaboration. Taken right out of the dictionary the word collaborate means "to work with another person or group in order to achieve something". It's a simple explanation and looks suspiciously like the definition of a team that is working towards a common goal. Something we are doing every day, assuming we are clear about the common goal(s).

It's a matter of degree in the success of collaboration that is more of interest. Collaboration appears to be much more utilized in reference to development teams spread out across the globe. I find it interesting that collaboration and multiple physical location design teams have equivalent meaning. Don't we collaborate over cubicle walls? I contend that the very same requirements for collaboration exist for teams in the same building as those that are 10 time zones apart. We tend to deceive ourselves that we will collaborate to a higher degree if a team shares the same space. The hypothesis is better collaboration through collocation.

Do you believe collaboration can only be improved by collocating the team? A positive response tends to indicate a trust in an osmosis type process to convey project information, requirements, deliverable expectations and plans among the team members. To clarify further, an assumption that collocation would be a fix confirms that the team is lacking in skills to formally communicate expectations and requirements of each other. Team member discussion as noted on the slide to left exemplifies collaborative inefficiencies. Team meetings that are peppered with conversations such as these should send up a warning flag that there are communication challenges impacting the teams ability to effectively collaborate.

Hint: Collaboration and communication are one in the same. You can't do one without the other. Registering a high reading on the collaboration meter means a high read on the communications meter. If verbal, one on one, on the fly communication is the dominant mode of operation, I would expect a failing grade in the area of collaboration. Focus on formal, crisp, clear and concise visual communication and collaboration will be a breeze. Given that the meaning of collaboration is "to work with another person or group in order to achieve something" it makes sense that everyone must have the proper forum/environment to participate in the definition of "achieving something" and defining what it takes to get there.

Roadmap to Superior Design Execution

2007-12-05T03:38:00.000-07:00

Design Process Improvement Overview
Both the Business Process Improvement and the Business Process Reengineering tend to focus on the business and it's interfaces into the other sub-processes, rarely getting into much detail on the design team processes and their interfaces. For significant improvements to be identified and realized within design, a focused effort must be completed specifically for product design that includes the interfaces into and out of product design.

There are two phases to design process improvements. The first is the assessment phase to learn, discover, understand and align the team to the current process. The second phase activities are to identify required process changes to meet the end objectives, as defined during the assessment phase. Depending on the magnitude of objectives the process is either targeting incremental improvements or a full reengineering effort, which clears the slate and starts from scratch. The diagram below represents the flow for both phases of design process renewal. Design Process Improvement (DPI) provides incremental improvements while Design Process Reengineering (DPR) is a major overhaul of how the design team operates.

To read full article follow this link.

Finding what we Don't Know

2007-11-17T04:02:00.000-07:00

I came across the following phrase years ago and it always stuck with me as being the core concept in an organization that is focused on continuous improvement. "Those that know, know they know. Those that don't know, don't know they don't know." In essence, if we are not looking then we are assuming that we already understand where the challenges are in our product design process. If we are not on a vigilant and unending quest to find what we don't know, then we are headed for stagnation in improvements to our project execution.

For your reference here's a link to a service that is the beginning of finding what is unknown.

Is your Design Process as Good as it Gets?

2007-11-05T14:17:00.000-07:00

In many organizations a team is aware of some problems in execution, however they are not deemed a significant disruption and there is a sense that the issues are at an acceptable level. When this is the attitude of the team I would not expect much in the way of improvements. The team has essentially stagnated in their productivity and has become comfortable with the status quo. Reasons for accepting current status range from not having time to elicit change to not having the motivation to improve.

I am aware of one highly successful semiconductor company that makes project kickoff a point of process renewal for each and every project. The team gets trained together, renews their process and best practices together, maps out their plans together and only then do they start the project. This is an excellent exhibit of continuous improvement in action. That organization knows that they do not know what they need to know and believes there is always improvements to be found. It's the culture.

There are three possibilities for your organizations position on the continuous improvement spectrum. Either you are OK with your project execution flow as it is today, you would like to see improvements in specific areas or you believe there are improvements to be found that include known issues and as well as challenge areas you may not be aware of. Where you fall on that continuum will directly impact the emphasis placed on improving.

A belief that it's as good as it gets or that you know everything you need to know about your process breeds a plateau in productivity and very limited improvements should be expected. Try shaking things up and continuously look for what you don't know and you can expect an environment of constant, incremental improvements. Excellence will be the product of an unremitting focus on improvement. Are you wishing for improvements or planning and taking action for improvements?

Parallels and Dichotomies of IC design and Software Development

2007-10-15T10:12:00.000-07:00

I have noted on many occasions that the development of a software project has many parallels to the efforts of an IC design project. Both have modularized activities that must be broken down from a big picture view, the system level and architectural work if you will. Smaller tasks must be defined and architected to match up with the high level requirements. If the lower level tasks come in and do not meet the high level interface requirements rework is necessary. Collaboration is an essential ingredient in both environments.

What I do find interesting with IC design teams is that there is far less adoption of formalized program management (PM) methods than I see in the software/IT product development world. In the IC design world there is more reliance on the technical design tools as the main ingredient of a projects success in lieu of a form of PM methodology. This seems to be taking place while the semiconductor business units are making reasonable investments in formalizing PM. Does anyone else see a similar dichotomy between these two product development philosophies? Any comments as to why this me be an accepted practice in IC Design?

Taming the Feature Creep WIldfire

2007-09-08T04:57:00.000-07:00

Any IC design project will have many changes come to the table during the term from spec closure to tapeout. How those changes are handled is what separates a project that flows smoothly from one that is riddled with unexplained diversions, surprises and delays. Teams that do not drive their business towards a formal process that includes assessment and approval of feature changes will be left to defend unexplained delays on projects with limited evidence as to why things are behind. Either design makes "feature creep" a visible process that leaves a decision paper trail behind or the design team becomes identified as a team that displays poor design execution. It's that simple.

Read more about Taming the Feature Creep Wildfire

If that article was of interest you can sign-up for our monthly newsletter here to get similar articles related to driving excellence in IC design Team execution. See our Past Newsletters.

Online Collaboration Tools

2007-08-26T06:17:00.000-07:00

There are a number of online collaboration tools out there today and I am curious if anyone has used them in IC design projects. If you have been using collaborative tools I would like to hear what you used, how you used it and how it improved your projects. Below is my list of web based collaboration tools that I am aware of.

http://www.basecamphq.com/
http://www.near-time.net/
http://huddle.net/
http://www.jointcontact.com/
http://www.mindquarry.com/
http://www.xplanner.org/
http://www.mindmeister.com/

Six Simple Rules of Managing IC Design

2007-06-04T14:10:00.000-07:00

Here are six simple rules to consider when managing IC design projects:

Commit only after doing your homework. Be creative, be aggressive, keep your vision broad and commit only when you have a means to get there.
Keep a keen eye out for the unknown. It is always there, waiting to disrupt your plan.
Are things progressing as planned, or is a correction to the plan and/or deliverables in order?
Verbalized plans, instructions and decisions should never be considered communicating. Write it down to keep it crisp, concise, thorough and communicated.
Leave no room for ambiguity or interpretation in your requirements for success. Say what you need.
Due diligence on plans and schedules will reinforce predictability for your design project.

If you want to learn more about managing IC design teams check out the PDF download for a "Managing Excellence in Design Team Execution" seminar.