Another reason in my opinion it's a good idea to have an engineer who is in charge of the whole system. Often when the project is broken down into little systems the system as a whole does not satisfy the required specifications. As I read this article it appears the simpliest of blocking and tackling was missed as well. Designing to Poke-Yoke so it can't be assembled backwards. Or maybe I'm not reading it right. That's generally design engineering 101.
Very interesting. It sounds like the manual was written by the guy from Seattle who later became our tech writer in Livonia, Michigan.
My observation of overly complex systems that don't work very well is that they are often created by folks who are unable to visualize the whole process at once, and can only relate to one function at a time, thus the system has a bunch of individual blocks, each for a separate portion of the overall function, and usually not able to work well with each other. THat happens more often than we can imagine, and causes all sorts of problems, such as were described here.
Great example of the zillions of design glitches and idiocyncracies that engineers address on a day-to-day basis. I'm wondering if the fix that Wayne came up with (I designed a little device that would both plug in the orifice and interface the device to our test equipment) was added to the field manual and if the IP around the problem and the fix was codified so it was readily accessible to other engineers.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.