It is management’s job to define the desired product attribute list including assigning a weighted importance to each attribute from costing to FMEA and everything in between. It is then clear to the engineers how to approach a first article or straw man. Efficiency can only be realized if an early focus is placed on the weighting of attributes, not just the desired attributes alone.
Likely constraints and exceptions will start to be discovered early in the process from this point on and without a closed loop to management at this point, things can go wrong quick. Focus on the weighting of each attribute more than the attributes themselves, as this process, done right can elicit new and as of yet unthought of attributes by simple material and process evaluation.
Also, the engineers must keep in mind the end user documentation for the product, as many times attributes can be improved by better documentation and signage on the product in lieu of adding costly physical elements in the mash up (not so much these days with safety attributes IE “keep hand out of blades” doesn’t cut it anymore).
Management will ultimately decide on the weighting and will likely alter the weighting based on engineering’s ability to match the weighted attributes and solve for constraints and exceptions in unique ways.
I usually get to commission my projects, so get feedback from the initial operator. I also frequently get to see the systems after 6 months to a year, and thus get to learn what I did wrong and improve future designs.
As much as I'd like to dream about the "ideal" design process - collaborative and streamlined - some new product projects end up more like a battle between departments and egos. I have managed many projects where no matter how well the plan is conceived, specified, documented, managed, and implemented, it all boils down to how the executive group views the R&D process and nurtures the development team. Most manufacturing companies that I have worked for, treat the development process/team as a luxury, a kind of necessary evil that saps valuable resources away from more interesting, glamorous, and quick-revenue generating opportunities.
On a positive note, I have experienced a few projects where the executive team member clearly stated the general goals for the project and expectations for each team member. Nothing too complex or demanding, just plainly stated, in-writing, and communicated to the team, in-person. Sometimes the exec would leave the team alone and only make an appearance when asked, or for milestone presentations. Again, this is a HUGE topic (or set of topics) and I've experienced a wide array of functional / dysfunctional teams and management groups.
I'd like to hear stories from other readers about how other companies and individuals experience the development process. The good, the bad, and the "what ifs?"!
You raise some interesting points around getting feedback loops earlier in the design process. I know the DFMA Forum was also home to some lively discussion around applying lean and DFMA practices early in design to help drive down the cost of products and level the playing field when it comes to outsourcing. Stay tuned to my story on how these kinds of engineering workflows can accelerate and support the effort to reshore manufacturing back to US soil. Should be up on the new Design News site shortly!
One simple solution that springs to mind is the correct use of FMEA's.
A good FMEA should weed out the unintended consequences of a design, the problem is most engineers see FMEA's as a chore which is boring but has to be done to tick the box, if taken seriously and fully engaged with an FMEA can really help the design process, and has to be done early enough that the solutions can be implemented or the design is not cornered.
So you software people, make FMEA software that interacts with the design process easier and intuitivley and can be worked on in collaboration whilst the design is on-going, rather than making the team lock themselves away in dark room and go through a laborious catch up of all the things they've thought of or done anyway but not recorded.
What's needed for design problems like this is a feedback loop that alerts the design team of the unintended consequences of a design. The problem with the fuel overfill could be easily solved if the design team is aware of the problem.
One simple solution is for the design team to go online and find comments by frustrated users who are pulling their hair out over design problems. Comments on online forums pop up quickly when users run into design SNAFUs.
A new service lets engineers and orthopedic surgeons design and 3D print highly accurate, patient-specific, orthopedic medical implants made of metal -- without owning a 3D printer. Using free, downloadable software, users can import ASCII and binary .STL files, design the implant, and send an encrypted design file to a third-party manufacturer.
For industrial control applications, or even a simple assembly line, that machine can go almost 24/7 without a break. But what happens when the task is a little more complex? That’s where the “smart” machine would come in. The smart machine is one that has some simple (or complex in some cases) processing capability to be able to adapt to changing conditions. Such machines are suited for a host of applications, including automotive, aerospace, defense, medical, computers and electronics, telecommunications, consumer goods, and so on. This discussion will examine what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.