Wednesday, September 01, 2010

Delivering Lean and Mean New Product Development

Most are familiar with Lean Manufacturing today, a concept brought into the limelight through the Toyota Production System (TPS). Henry Ford was actually one of the earliest "Lean thinkers" with the notion of an assembly line. In it's early form this waste elimination concept was considered only applicable to manufacturing. Today it has expanded into areas that include healthcare, government, construction and services to name a few. The application in New Product Development (NPD) is a relatively new area that has significant opportunity for improving development time, quality and predictability while reducing developments costs. It is easy to say Lean cannot apply to the non-repetitive engineering and invention aspects of NPD; that's not right, it's just easy to say.

Let's start off with defining what lean is; put simply, it is about improving efficiency by eliminating waste. The inefficiencies can be in the form of the use of people's time, inadequate tools, rework, overdone requirements, non-value steps/activities/meetings and so on. Waste can be found in many areas, mostly buried and out of sight. Consider Lean as nothing more than creating a culture to drive higher levels of efficiency on a continuing basis.

There is plenty of opportunity for leaning up in new product efforts. The scope of any Lean effort must cover the entire development process from initial customer contact to a volume revenue stream with that customer. A localized view of any subset of the total NPD process is actually anti-lean due to an obvious disconnection from the value stream, an error for many improvement initiatives. Lean must be a big picture view that includes all functional areas, both deliverers and receivers of a common value stream.

The diagram to the right represents the typical components of a lean approach. The cycle is one of continuous learning and an ever-evolving process based on that learning. It never ends; an organization is never done. As soon as there is a belief of doneness, the lean train is derailed. Begin a Lean journey by looking for areas where the principals can be applied to NPD.

Value
The focus of any new product must always be on the customer value. For any new product you must be able to clearly identify where the customer value is. That is what matters, in fact that's all that matters. Be in the customers shoes, feel the problem to be solved. Think beyond requirements to include interactions, information exchanges, trust, communication and the needs for development of their product. You must be absolutely certain of what the customer values in a relationship with you on new product. Delivering all aspects of customer value is a distinct competitive advantage.

Identify Value Stream
Anything that does not add to the customer value is a waste; it is outside the value stream. This is a tough one for those that believe everything they do is important, essentially the majority of organizations today. Meetings, documentation, decision processes, procedures, reviews, sign-offs; they are all suspect of being off the value stream in their current form! The value stream is only the activities, information and deliverables that clearly promote the customer value. Can you identify the value stream for new products in your organization?

Create Value Flow
Now, knowing what the value stream is, build a NPD flow that supports that value stream. Get rid if the wasted activities, meetings and deliverables that do not directly enhance the customer value for new products. What are you doing because you have always done it? This is a great place to engage some good solid discovery, beginning at the bottom and working up. Creation of the value flow will not be for the faint of heart; every activity today is already assumed to be valuable and there are people and bruised ego's to deal with. The output of this phase should be a development flow that is highly efficient in bringing value to the customer at the quickest pace and the lowest cost.

Establish Pull
This one is a little tricky for NPD. Establishing pull means that deliverables are completed at the latest time possible, where the greatest amount of information is available. Today most are focused on getting everything done ASAP and queued up before it's needed, essentially creating inventory and a push forward. A pull is more like JIT (Just in Time), where tasks and deliverables are completed as needed, at the maximum point of knowledge for the task. Think of pull as tasks that are demand driven. For NPD a pull mindset will have a significant impact on quality and rework. How much is being redone because of not knowing what was needed the first time? Pushing tasks creates rework!

Seek perfection
To seek perfection is a course of continuous improvement. The lean process is never done and ever evolving, always improving upon knowledge from previous projects. Perfection does not just happen; it is asymptotically being approached with every new project. Lean NPD is a journey, not a destination.

Thursday, July 29, 2010

New Product Execution - It's Just not Good Enough

New Product Execution is never quite good enough, although there is certainly a continual business emphasis demanding better. There may be small pockets where new products efforts scream success, although the overall effort frequently comes in with a "C" grade or worse. How's your organizations new product execution grade? No, you can't grade yourself; the only grade that matters is the one from the business GM or the customer.

There is a broad belief that if new product execution is failing it's because the development team does not have enough passion to get the job done. I strongly disagree with this narrow-minded perception. My long-term observation is that if execution is failing, it's because leadership has failed the team. Leaderships role is minimally to guide the team to a better tomorrow through the seeking and addressing of systemic issues that are routinely impacting execution. I firmly believe that a key role of leadership is the enablement of an environment that spawns continuous improvement.

The picture to the right is a list of common objectives and challenges that will pave a path to execution excellence, as each item is addressed. Click on it, print it and hang it on the wall as guide to attaining an "A" grade in new product execution. Utilize the concepts below to further hone a strategy for leaving average execution performance in the dust.

An Execution Strategy is Missing
News flash - new product execution is lacking a strategy simply because of a misplaced belief that there is one. That ghost strategy is actually a rigid tactical approach masquerading as an execution strategy. An authentic strategic approach will minimally include:

  • Regular questioning of why things are done as they are.
  • The regular application of learning from past products.
  • A participant scope that includes all functional areas.
  • Embraces dynamic planning.
  • A shared vision of what ideal execution looks like.
  • Cover all activities from concept through revenue.
If you are really looking for improvement, challenge the age-old tactical sequencing of who, what and when by routinely throwing a "why" in the mix of planning. This questioning nature could mark the beginning of a solid strategy for grade "A" execution.

Execution Scope is far too Narrow
At what point does new product execution begin? Most would be apt to identify the phase where significant design activity commences. I disagree; execution begins when that first twinkle of an idea begins to glow, where a product concept is born. A misguided assumption that execution begins with later activities allows the critical early tasks to flounder, avoiding the crisp management required to drive efficient closure. The "let's think about it" queue must be considered as execution, with all the sense of urgency and accountability that is expected for any project phase. The deliverables, time line and objectives must be managed from the very beginning.

Unacceptable New Product Success Ratio
How many products fail at meeting business case profit? Those losers will certainly eat up the ability to execute well on the successful products. Any product that is not a financial success must be scrutinized. The root cause for allowing such products to continue marching forward in the face of eventual failure must be well understood. There is gold in the analysis of failed products and significant mining will be required to gain access to it. Throw on your miner hat, turn the light on extra bright and go about finding the golden nuggets of information that will enable an improved strategy for approving and monitoring new products.

Failing to find what is Unknown
I have been talking about unknowns since the first day I opened the doors for business and it still baffles people when I talk about them. An unknown is a masked barrier to smooth, orderly and predictable execution in a new product effort. If you are not specifically looking for unknowns and removing them, your new product execution will have an element of time-wasting rework. If you want a higher level of predictability, go out and find what you don't know, and do it regularly. "Those that know, know they know. Those that don't know, don't know they don't know"

Wednesday, June 30, 2010

Tools for Enabling Collaborative Environments

What comes to mind when you hear the term collaboration or collaborate? My definition is enablement of an environment that minimizes disconnects and misunderstandings between individuals on a team. A collaboration strategy should also foster sharing of ideas, concepts and visions of the individual contributors while keeping the team current of the status of the project. Attaining a truly successful collaborative environment will always eliminate any team execution issues related to geographic boundaries.

The word collaborate or collaboration is overused, in fact it is safe to say that it's meaning has been minimized to the point where any team is in fact identified as a collaborating machine. Here's the dictionary definition of collaborate: To work together, especially in a joint intellectual effort. "Working together" - that means more than just working on the same project. It means synchronization, communicating, shared visions, gaining consensus, sharing ideas, informed decisions, understanding contribution and always knowing status. The sharing of files as a collaborative mechanism for projects is archaic and has no place in a high tech industry! Technology has brought us much, much better ways, if we choose to explore them.

There are an abundance of tool solutions available today that foster collaboration and I wanted to share three specific types with you; planning, group chat and brainstorming. I heavily favor hosted SaaS (Software as a Services) solutions due to their cross platform availability and the collaborative enabling aspect of centralized data for all to see. Hosted "cloud" solutions are all web-based interfaces and require nothing to be installed on your computer.

Scheduling & Managing the Process
First off, in an environment that talks of collaboration, it certainly does not make sense that a single person has a view of the status, tasks due, next steps, overall project flow and so on for any project. The days of a singe person maintaining a schedule file should long ago gone the way of the horse and buggy. There should be no secrets and certainly each individual should be responsible for keeping their tasks current... did I hear a gasp?

There are many hosted (web interface) solutions that cover the needs of centralized, multiple platform (even Linux), multiple-site and user-friendly project planning/management tools. Find them via a search string like "SaaS project management tool". My favorite is PIEmatrix due to its slice concept, allowing the establishment of predefined best practices for each NPD role.

If you are concerned about your planning data residing outside the corporate firewall, many of these companies provide internally hosted solutions also. Personally I don't agree with such concern; look at how many large companies have embraced saleforce.com and allowed their sensitive customer relationship data outside the firewall.

Chat
When you think of chat the last area that you may see benefit of this social technology is managing teams and projects. The latest chat technology standards known as XMPP (Extensible Messaging and Presence Protocol) provide much more flexibility in terms of group level chatting (Persistent Group Chat), opening an interesting door for project collaboration.

Consider that specific project group chats could be setup for various chip modules, EDA, verification, requirements, integration, timing analysis, synthesis, test, system verification and so on. Team members can subscribe to only groups of interest to them. This then becomes a real time discussion and communication area for items of importance to that particular chat group. There is even a history capability for documenting the discussion. Via this technology worldwide real time collaboration can become a simple task for projects spanning multiple continents.

Individual chat servers could be setup inside the corporate firewall for each project and then configured to provide specific chat groups of interest for that project. There are also several hosted chat solutions that provide similar features. The technology exists, is supported on multiple platforms, including smart phones, and costs range from free to low. Why not give it a try? Search for "persistent group chat" to find hosted solutions. Check out http://xmpp.org for client/server possibilities.

Brainstorming
There is no better way of collaborative brainstorming than the use of mind maps. Many are hosted and allow real time map sharing for multi-site brainstorm sessions. Review last month's posting for more information on mind mapping.

Collaboration or Extinction
The largest issue I see with project execution is due to a lack in the most fundamental of capabilities, a deficiency in individual communication. If people are not communicating well they are certainly not successfully collaborating. Tools that enable better communication will also facilitate the much-needed collaboration that will bring about change. A cure for "Terminal Sameness" is an incremental choice, one antidote at a time.

Friday, June 18, 2010

Is the Productivity Scorecard Measuring What Matters?

After years of talking with and working with New Product Development (NPD) teams, my productivity report card is in and the grade is not good! Acceptance and tolerance of the current situation scores high; while real, substantial and sustainable productivity improvements for the overall development process clearly gets a failing grade. Sorry people, but our industry is stuck in a mode of “terminal sameness”!

When the subject of productivity comes up in the semiconductor industry the discussion immediately goes to tools, EDA and all the wonderful things going on in that sub-segment of the chip development world. So, how has that focus been working out for the last 15 years? Are chip developments now predictable and smooth? Yes, I know; more integration, more transistors, embedded software, tighter technologies and the like are keeping projects messy and that’s the reason why new product efforts are still behind, over budget and require multiple spins. Really?

My observation is that new product execution is not being properly measured or managed. Project management methods have been in place for years now and they deal superbly with the tactical approach to guiding projects. What is missing is a strategic approach to managing a project and by that I mean really understanding what is not working and fixing it.

I frequently talk to teams that are dealing with highly visible execution problems for years with no solution in sight; and I do not mean tool issues. I am talking about team dynamics, mechanics and cross silo operational issues that siphon off a team’s productivity and are often not included in the productivity scorecard. That kind of short sightedness is just plain anti-success and merits an F in the productivity area.

The sad part in this is that there is large acceptance of non-tool related barriers to productivity, and I just don’t get that. How can leadership turn a blind eye to glaring issues that allow a NPD team to stumble over each other, project after project? From my perspective leadership is all about removing the barriers that keep their teams from being the best they can be, it is their primary role.

If the productivity scorecard is to significantly improve it will require the addition of a dedicated effort to locate and repair new product operational issues, an area that is not receiving the focus it deserves today. It means spending more time looking at people issues. If you’re a leader, I challenge you to prove that I am wrong!