It is amazing how much and in how subtle ways cross-disciplinary approach can enhance quality, efficiency, safety... in any given faculty or field of human creation. Learning from each other, and not necessarily within the same science, is the way we progress as humankind. Although I am not saying much new here, in my view, these are important things to underline, and am thankful to a philosopher-engineer-designer who captured this importance in his article. For my part, I am in particular sensitive to one huge "check-list item" in design process: safety of those who are using, operating, or simply get exposed to a final result of design process.
I have found it quite useful and valuable to use checklists both in quoting projects, so that we can be sure that we are pricing all of the steps between concept and completion, and also in the final installation of projects at a customers site, located someplace where forgotten items are unavailable.
In addition, the checlist, particularly the installation list, serves as a notification of what subset of skills will need to be on hand for the various stages of installation. That is not only a handy way to keep things moving, it is also a good way to limit the time that we need to have expensive specialists on site, such as pipline welders.
So checklists are quite a good value, although they require care to assure that nothing gets left off.
It's amazing how much better a process gets when more lives are at stake. Multi-story buildings must be safe -- there are hundreds or thousands of lives inside -- and somehow the process improves. Same for big aircraft. When I worked in the nuclear power industry 30 years ago, all our engineering calculations were checked and signed by three engineers, and then by the utility, and then, presumably, by more people (who I was unfamiliar with) along the way. Somehow, processes get short-cutted when the consequences are less obvious. Surgery should be one of those areas where the consequences are obvious, but I suspect that mistakes are frequently made in the operating room that never come to light, and have no consequences at all.
To quickly and accurately create the best designs, I've found it best to use design checklists (written design guidelines) as I am designing. These guidelines are baseed upon previously learned best practices (and also on making sure a previous error is not repeated again). Some of these guidelines are more well-known like DFM (Design for Manufacturing), and some are more specific to the particular industry the product is being designed for. All in all, written checklists/guidelines not only help our team get to market faster with a better product, they also teach and mentor less-experienced engineers and designs on how to quickly get up the design learning curve.
In addition to practicing engineering, I have also been a licensed pilot for more than 20 years. There are three elements safety: Checklists, logical work-flows, and cross checks.
Yes, have a checklist, BUT KEEP IT SHORT AND TO THE POINT! If it gets too long or too pedantic, people will ignore them, particularly under stress. When I first learned to fly, I used the official Pilot's Operating Handbook checklist for the aircraft. This is a legal document, often created with the assistance of hordes of nosy lawyers who probably didn't know a damned thing about aviation. There were some things that were checked two and three times and other things that could have been deadly to ignore, but weren't even on the list.
As I grew more comfortable with my aircraft, I developed my own checklist. The pre-flight checklist is a biggie. To make it more intuitive and less cumbersome, I set it up to follow the path I would typically walk around the airplane. I didn't leave anything off, but I did add a few nusiance-if-they-break items at the appropriate places.
Next, my pre-taxi and pre-takeoff lists were relatively shorter, but still very performance based. These are verbal lists I hand the printed lists to my passenger/co-pilot to call out and I would respond in kind. Yes, I would memorize those lists. As soon as I was in the air, the lists would be stowed with the red-striped emergency pages on top. I had my navigation work all laid out with multiple resources to confirm where I was. Some of my waypoints might have been visual, some might use a beacon from an airport I was passing over, some might use GPS, and others an intersection of two VOR radials. The key is that I have a diversity of methods, so that I not get fixated on any one instrument. I also keep a list of alternate airports at each stage of flight, just in case something goes wrong.
And finally, when it came time to land, I once again memorized the infamous GUMPF check-list: Gas, Undercarriage, Mixture, Prop, Flaps. It is simple, stupid, and it works. I use it several times during various phases of landing.
Airline pilots have developed what they call work-flows through the cockpit Each task has a routine feel to it, each work-flow item follows the panel of the aircraft in some direction. Both pilot and co-pilot do this and confirm each other's work.
What you see here is the use of SIMPLE checklists, logical work-flows, and lots of planning for likely contingencies.
All this training and practice came together several years ago. I was flying as a safety pilot with a friend practicing instrument approaches. We discovered an engine problem at 4000 feet over a VOR west of Philadelphia at night. Training took over. We landed safely with little fanfare. Later investigation showed a cracked cylinder on the engine. Checklists do work, even under stress, but they have to be terse, simple, and to the point.
I suspect that every engineer worthy of the name has a huge mental database of design checklists for the variety of components, systems, products, and processes he has encountered in his career. DFMEAs and PFMEAs are the checklists we use to check our checklists to make sure we haven't missed something that should have been foreseen. If done properly, they are valuable tools. However, we are always aware that "We don't know what we don't know.", and expect some unexpected surprises will occur before we are done. That is how the checklists grow.
I would offer that a naturally inherent "checklist" is a basic thought process of any reasonable skilled designer. And for anyone who has had the responsibility of being a product architect over numerous lengthy projects, that checklist gets honed and refined, after every project. It improves with age and experience. Thinking back several decades to one of my earliest efforts, I can honestly say, (now) that I ran into situations I would never had even imagined could have happened – which today are a routine part of the design effort. Yes, a Checklist. I use one. And even if an engineer doesn't have one printed out, they certainly have one framed mentally. But I strongly contend that a literal, written, bulleted list of cautions is needed. I wouldn't really be successful without one.
It can go both ways. I've seen cost reductions that improved the design by cleaning out attributes that were in the original design but no longer specified or used, and I've seen where something got changed that should not have because the new engineers were unaware of why something was done a particular way. Whenever possible I dig for the old notebooks to find why a design decision was made, just to make certain I'm not creating a problem that somebody already solved.
In an age of globalization and rapid changes through scientific progress, two of our societies' (and economies') main concerns are to satisfy the needs and wishes of the individual and to save precious resources. Cloud computing caters to both of these.
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.