Getting your Top Five Obstacles Behind You

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:

1. Enable the need for rework of already completed tasks.
2. Enable wait states due to lack of information.
3. 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

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

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

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

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

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

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

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

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

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

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?

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

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?

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

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

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

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?

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

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?

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

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?

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:

1. No scope change control in place - Feature Creep runs free to silently steal away your team's productivity.
2. Unmanaged requirements closure - The process of deciding what to do drags on and on, eating away development time.
3. Deliverable disconnects between deliverer and receiver for a given task - team members are not getting what they need to be successful.
4. Plans that are based on imaginary resources/capabilities that did not materialize - fictional expectations created surprises in the midst of project execution.
5. 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

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

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

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

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

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

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

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.

1. Lack of Best (Same) Practices - Enough said on this subject from the previous posting on practices dated Jan 31, 2008.
   
2. 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!
3. 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.
4. 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.
5. 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.
6. 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

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

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

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.