How difficult is it to develop a product that meets the needs of customers and/or users and, at the same time, is industrially buildable, has a low environmental impact, and more?
It is very difficult, and even more difficult is to do it in a short time and without major remakes of the product itself.
In fact, once the product has been validated, modifications are made to the product to make it industrially producible and maintainable.
This step is expensive and lengthens the time especially for very innovative products.
The development of new products has always been conditioned by a multiplicity of aspects that consider the customer’s perspective and the company’s perspective.
There are at least 11 such aspects in particular:
-
-
Design for Assembly
-
-
-
Design for After-Sales
-
-
-
Design for Procurement.
-
-
-
Design for Manufacture
-
-
-
Design for Cost
-
-
-
Design for Reliability
-
-
-
Design for the Environment and its Impact.
-
-
-
Design for Recycling
-
-
-
Design for Commonality or Standardization
-
-
-
Design for Disassembly
-
-
-
Design for Safety
-
The approach that takes these 11 perspectives into account is called Design for X.
Concurrent Design or Concurrent Engineering, of which Design for X is one of the tools, has been the recommended way to develop new products for years.
In many years of product development using traditional waterfall methods, I have never been able, with my teams, to fully take all these aspects into account.
The practice of design review meetings (Design Review) is one way that I have employed to involve people who are directly interested in one or more aspects of Design for X.
The success was only partial.
Only with the adoption of the Agile approach, due to the team being cross-functional, was it possible to implement Design for X and Concurrent Engineering
In fact, sprint review meetings have replaced design reviews.
As I described in my article “Who pays for the speed of agile product development?…the Cost of Delay” , the Agile approach has as its goal a substantial overlap and integration of the different stages of development.
If we think about the 11 perspectives of Design for X, it is easy to have teams with more than 15 people.
An optimal team should be limited to no more than 9 people to function best.
It is foolish to always involve, so many people, in all product development events.
It is a great waste of resources and time, producing the meeting rejection syndrome.
Therefore, it is appropriate to break down the Project Team into 2 teams that are integrated with each other:
-
- A Permanent Team or Core Team, composed of people committed full-time to the project
-
- A Partial Time Team or Shell Team, composed of people engaged with precise rules of engagement within the project design.
In my experience, Shell Team functions committed to part-time work are typically:
-
-
Cost estimators and cost consutivators.
-
-
-
Computation and simulation technicians
-
-
-
Industrializers and/or time and method experts
-
-
-
Buyers
-
-
-
Process technologists
-
-
-
Testers/Validators/Experimenters.
-
-
-
People of Marketing
-
In this way, Shell Team people can also be involved in multiple projects.
This becomes a great opportunity for continuous knowledge transfer between different product development teams.
I have seen in recent years an integrated and mutual growth in the skills of “designers” and “industrializers,” who learn how the challenge lies in making buildable components that are not necessarily simple and trivial.
