 |
 |
 |
 |
Poor or no documentation system.
IP management, compliance activities, product testing, manufacturing, product maintenance and many other PD activities will suffer if the pertinent documentation is lacking.
|
 |
 |
|
 |
What to do about it!
Like it or not, testing activities, compliance testing and production (among other PD activities) 'live by documentation'. Documentation is absolutely required, unless the product is to be produced and maintained by the design engineers. A simple, but effective documentation system and change control system (for both process and product) can be set up and maintained quite easily. A bureaucracy can be avoided if the documentation and control system are structured to efficiently handle only what is absolutely necessary.
PD anecdotal-wisdom suggests that 15% to 40% of the cost of a PD program is in the documentation, depending on product type and complexity. Preservation and institutionalization of this investment is in everyone's best interest. Some companies actually capitalize their documentation since it can be classified and used as a corporate asset.
Any document control system needs to have embedded in its intent 'the prevention' of changes instead of the 'abject generation and acceptance' of changes along with a bureaucracy to manage them.
As best as possible in the planning stage eliminate those tendencies that will encourage changes to happen.
Changes usually occur from:
- Errors-of-risk and Errors-of-change in implementation, design, judgment.
- Intentional improvements or changes to product or process.
- Changes in product development or market environment.
- Changes in manufacturing technology or availability of skills and processes.
- Regulatory changes.
For more on this see Product Development Through the Eyes of Documentation, by Dick Haney
Following are other tips for enhancing the PD processes:
- Prototype as Often as Possible - Fail Early and Fail Often (FEFO). This allows all of the product development stakeholders to be intimately involved with the product as soon as feasible for the benefit of learning about and discovering the realities and deficiencies of the product. That is, the prototype puts the concept into the hands of stakeholders very early in the process, which this allows many problems to be solved concurrently and early on when it is much less costly. Specifications and requirements really imply that someone 'has all the answers up front'… Prototyping verifies this, or not (many times - NOT). FEFO can actually be considered as an implementation of the Kaizen philosophy (incremental and continuous improvement) during development to 'fail' your way to a better product.
For more on this see The Business and Hidden Values of Prototyping During Product development by Dick Haney
- Institutionalize in some 'hard and permanent' manner the intellectual capital gained during PD - a person's head is the wrong place for this. New and useful knowledge applicable for other projects should be retained and spread around so that 're-inventing the wheel' is neutralized.
- In addition to the useful techniques of DFM, DFA, DFT (Design for Manufacturing, -Assembly, -Test) also consider 'Design for Minimal Overhead' (DFMO). This concept helps to limit the complexity and labor involved in the eventual production and testing of a product. It's a good goal for considering domestic manufacturing.
- Overlap or run concurrent (parallel) efforts if possible - part of up-front planning allows one to determine where this can be done.
|
|
JUMP TO PAGE 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46
©2003, Richard M. (Dick) Haney
|
