The engineering cycle roughly consists of requirements capture, conceptual design, detailed design, prototyping and refinement, design approval, production- process design, production, and deployment and support. This linear list is neat, but reality is not. Actual product design keeps looping back to earlier steps, with lots of corrections and retracing.
Why is design so messy? Because it is not deterministic. That is, not a single optimal design emerges from a given set of initial requirements. Rather, design is a trial-and-error process. A lot of learning happens along the way. Project teams later make discoveries that turn out to affect the design. These might include, for example, properties of materials, how parts work together, customer needs, development of other products, and many other pieces of information.
The world moves on. You can’t step into a river twice and expect it to be the same both times. Novelty is inevitable, but it is unlikely that the fundamental process of engineering will change.
That said, there are aspects that need improving. In particular, although interoperability tools are available, teams seldom communicate information from one stage to subsequent stages, except in the form of a final result. For example, the early list of requirements seldom remains intact, let alone examined, by the time the project reaches the prototype phase. Thus, important information — such as decisions made, and the rationale for them — gets lost.
This situation leads to a host of inefficiencies. For instance, when a team doesn’t know why something was done, it might inadvertently make changes that could adversely affect the product or its performance. Also, the further along the design cycle, the greater the number of resources that become involved. When teams lose track of requirements, problems might remain hidden until later when they are more expensive to fix.
Another consideration: Good ideas pop up at various times during the design cycle. But unless a team can gauge the ideas’ impact, it’s difficult to tell if they are worth implementing. What’s more, when a team does not maintain information in a given project, it surely won’t do so from project to project. This leads to a continual “reinventing of the wheel” — at best. If personnel who worked on one project are no longer available, their knowledge disappears with them because the decisions and the reasoning behind them were not recorded.
In fact, very little thought goes into preserving the integrity of all the knowledge that goes into engineering projects today. Information is preserved moreor- less piecewise and without integrity. Ultimately, a BOM is stored in a PDM system — without history, without rationale, as though it appeared out of nowhere.
Avoiding these problems is a matter of staying organized and preserving information throughout the engineering process. Practice this and, as time goes by, your company will get better and better at design because it has access to everything that went into earlier projects. Soon your company will find itself meeting or even exceeding original project requirements, even when the same people are not available.
So, think about ways to track information in engineering projects, starting with requirements and extending through to manufacturing. Search for software tools that might help with this challenge. Implementation costs might be lower than expected while potential rewards are huge. The upshot: Find a way to connect the “prose” of documentation with the “passion” of design.
— Joel Orr
Joel Orr is Chief Visionary at Cyon Research Corp. in Bethesda, Md. If you have a question or a comment, e-mail Joel at [email protected]
Edited by Leslie Gordon