Posts Tagged ‘New Product Development’

Are you working on the right new product development projects?

Wednesday, July 25th, 2012

A common theme we hear from Executives…

“I don’t know if we’re working on the right New Product Development projects, and I keep hearing that projects are late because we don’t have enough resources. The solution to every problem seems to be ‘Give me more people,’ but I’m not going to throw more resources into NPD if we can’t even manage the resources we already have.”

Sounds familiar? This is probably the most common theme we hear from the leaders of our client companies. Some companies already have a portfolio management and resource allocation software system in place, but it’s rarely used or relied upon. Whether the software system is home-grown or the best that money can buy, if it doesn’t clearly identify the most valuable projects, and kill inappropriate projects, and optimize resources without imposing an excessive administrative burden, it’s time for an overhaul.

What do I do about it?

A clear NPD strategy and unwavering leadership and participation from executive management are the first and most important prerequisites. The next step is to build a system for evaluating potential projects against the NPD strategy and against each other. A system for estimating required resources and existing resources is also essential. Armed with these directives, your company can begin to appropriately manage the NPD portfolio.

Prior to integrating a software tool, we recommend that you establish a portfolio management process that aligns to your organization. We have worked in many companies where the software tool is underutilized or not used at all by the team since it did not align with the company’s practices. You ideally want to make your team comfortable with the portfolio management process prior to integrating a software solution. Remember the old adage: don’t let the software drive your process…let the process drive your software. This approach will optimize your team’s performance and software solution.

Share

Medical Devices: Control is Not the Same as Innovation

Thursday, June 21st, 2012

In the design of medical devices, design controls are not necessarily the same as a product development process. A quality management system requires that a process and controls be in place and be documented. Its intent is to guarantee that product development is documented for traceability and that products are made in a consistent manner. For example, a standard such as ISO 13485:2003 requires that a medical device manufacturer establish and maintain a quality system. In addition to other requirements, ISO 13485 puts more focus on risk management and design control activity during product development without actually dictating the exact nature of that system. Additionally, 21 CFR 820.30 outlines the requirements for design controls without describing the exact form they might take.

Standards describe the need for processes but do not lay out a path to innovative new products. A robust, consistent new product development system, such as a phase-gate process, is an important means to the end of design control, including risk reduction, device history, and traceability. It can form the basis for the design history file from the new product’s inception and contribute to the design master file.  And what the NPD system does especially well is addresses business-related issues that the QMS in not concerned with, such as which new products should move forward (based on the most promising market opportunity) and how to improve customer satisfaction.

Share

Putting Manufacturing Experts on Your Early Concept Development Teams

Monday, June 4th, 2012

Designing new products for Manufacturing and Assembly has always been a challenge. Typically, Manufacturing Experts are added to a Project Team AFTER the basic product configuration has been established. The manufacturing people are then charged with building the new product at the target price. This can be very difficult as the product concept configuration often dictates the use of certain manufacturing processes. For example, one product configuration may require the use of precision machined castings that require expensive tooling while another configuration (that serves the same function) may have been built using simple sheet metal weldments. The difference in cost and lead times can be substantial.
Quite often, manufacturing skills and talent are not added to the project development team until it’s time to build the product. At this point, approximately 90% of the product cost is already built in and the manufacturing experts can only influence a small piece of the overall product cost and lead times. The best they can do at this point in the product development cycle is to select qualified suppliers, develop good quality plans and make sure tolerances are suitable for the locked in manufacturing processes. Little can be done to substantially affect the overall cost of the product.
So what can be done? Firstly, include manufacturing expertise from the very beginning of a project. The type of person that will do best in this situation is someone who has broad knowledge of manufacturing processes but also has the ability to conceive and design from a blank sheet or paper (or CAD screen). In addition, they have to be a team player and put the project goals first and avoid being a “manufacturing silo”.
Secondly, Strategy 2 Market has developed a Design for Manufacturing Assessment tool for early stages of development. In addition, there are many computer based tools on the market to help develop early cost models. Using them can provide the team with the data necessary to make quick and well informed selection decisions amongst the various product configurations in the early stages of development. It would be the manufacturing expert’s job to provide the team with this information.
Thirdly, but certainly not last, the manufacturing person can help design in quality from the beginning by selecting the appropriate manufacturing and assembly processes for the desired functionality. This also gives the factory and early heads up as to what’s coming and what they need to prepare for.
Having manufacturing personnel involved from the very beginning of a project can help avoid many issues and headaches down the line.

Share

Mind Mapping for Generating New Product Requirements

Wednesday, May 23rd, 2012

According to Wikipedia, “Mind maps are used to generate, visualize, structure, and classify ideas, and as an aid to studying and organizing information, solving problems, making decisions, and writing. …… Mind maps are, by definition, a graphical method of taking notes.” Mind Maps can be used to organize customer requirements during the conceptual stage of product development when the vision of the product is yet unclear. They help organize brainstorming sessions and document results in an easy to understand manner. Mind Maps usually start with a very simple idea or product description and branch out from there and are a visual representation of everything a product must do or that customers want it to do. They branch out and document a product development team’s trains of thought until the details emerge. (Fishbone diagrams are actually a form of mind map.)

Mind Mapping is not new. It’s been around for centuries. However, it’s been done manually with pen and paper. What is new is the software that allows users to create, modify and utilize mind maps quickly and efficiently. There are many software programs on the market today, both paid a freeware. Mind Maps can usually be exported into Excel and other programs for documentation and tracking.

I used mind mapping techniques to lead a customer team through the initial requirements gathering and development for a large scale factory automation project. There were technical and operations people on the team which lead to a multitude of business and technically related requirements. During the first day, the team generated over 130 separate requirements for the system. Some requirements were at a very high level and some were at the lowest levels of detail. Every suggestion was documented, no matter how trivial it might have seemed at the time. Over the next day and a half, Mind Mapping software was used to lead the team through a series of exercises to group the requirements into major headings and develop subgroups. All requirements were documented in a mind map within the appropriate group or sub-group. The resulting Map gave the team a “picture” of what the system would do.

After examining the map over the following days and weeks, the team added requirements that they hadn’t thought of during the initial sessions. Having the pictorial version of the requirements enabled people to easily “see” interactions between requirements that might not have been as evident with some other product requirements definition techniques. Mind Mapping allows one to draw relationships between requirements and describe out they’re related or perhaps in conflict. Conflicting requirements must be resolved. Identifying the conflict in the first place is a major part of the battle.

Performing Product Requirements Definition using mind mapping techniques in a setting like this achieves several key things:

1.  Generates a uniform picture or vision of what the product should be.

2.  Team building across functional areas

3.  Helps to develop and document a complete set of requirements and specifications for the development team to act upon.

4.  Enables the team to quickly identify holes or omissions in the requirements definition.

5.  Reduces the risk that a key requirement of the product will be left out. Said another way, it ensures that customers will be satisfied (or even elated!) with the product when it hits the market.

Mind mapping techniques and software can help New Product Development teams focus their efforts quickly and easily communicate the results of Product Requirements Definition efforts. It keeps everyone on the same page.

 

 

 

Share