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

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

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

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

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

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

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

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

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

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

Mixed Signal Success Requires the Voice of Analog Designers

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

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

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

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

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

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

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

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

Solution Strategies for Solving Systemic Issues

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

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

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

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

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

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

Enabling the Decision to Invest in a Solution

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

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

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

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

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

The NIH Factor may be Putting your Business in Peril

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

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

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

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

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

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

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

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

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?

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

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?

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

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

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

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

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

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

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

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?

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

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?

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

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

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

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?

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

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

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

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

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

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

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.