Coaching Excellence in IC Design Teams

Concepts for Improving New Product Transparency

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

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

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

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

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

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

How Limited Transparency Impacts New Product Efforts

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

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

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

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

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

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

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

Organizational Silos - The Enemy of Project Execution

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

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

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

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

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

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

Short Project Execution Survey - See Results Upon Completion

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

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

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

Off to the survey

Using the Project Premortem to Identify Risk Areas

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

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

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

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

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

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

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

Uncovering Project Execution Risk Areas

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

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

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

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

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

Guiding the Team Through Surprise Free Execution

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

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

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

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

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

Understand the Source of Project Surprises and Eliminate Them

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

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

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

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

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

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

Management of Projects - Is it really working?

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

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

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

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

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

Development Process First - Organization Second

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

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

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

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

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

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

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

Is your Development Process Targeting the Right Objective?

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

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

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

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

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

The Big Secret – Costs of Inefficiencies

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

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

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

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

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

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

Maximizing Activities that Matter to the Business

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

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

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

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

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

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

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

The Critical Link of Activities to Business Results

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

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

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

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

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

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

Soft Skill Development Breeds Solid Leadership Effectiveness

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

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

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

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

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

Six Actions to Promote Project Execution Excellence

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

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

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

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

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

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

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

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

Today is Perfect for Making a Positive Change

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

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

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

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

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

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

Finding Root Cause of Project Performance Barriers

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

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

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

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

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

Why aren't the known Execution Challenges Being Fixed?

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

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

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

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

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

Maximizing Team Motivation

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

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

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

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

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

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

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

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

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

Are we Ready for Hosted Solutions for Chip Design?

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

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

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

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

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

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

Eliminating the Systemic Barriers to Meeting NPD Commitments

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

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

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

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

Addressing the What, Where and How

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

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

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

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

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

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

How

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

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

Closing the Individual Objective Clarity Gap

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

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

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

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

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

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

Are you Ready for Changes in the Requirements Process?

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

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

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

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

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

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