If you’ve been actively following this blog, you’ve read about the importance of developing a sound idea. The development of an idea begins in the form of a compilation of requirements, expectations and overall purpose of your product or device. An engineer works through this compilation to prepare a methodical approach focused on realizing a design’s creation.
The engineer’s first step is to prepare a specification, i.e. a series of requirements which ultimately become the backbone, or in some cases, the achilles heal of the design. All specification entries in part and as a whole must pass a sanity check.
This post tells the tale of the monkey wrench, a lesson in developing specification requirements.
Long ago (in a galaxy far, far, away…) in 1985, I was a junior engineer who experienced a very important lesson in specification development. Cutting my engineering teeth at Sikorsky Aircraft was filled with lessons. After a few years filled with drawing revisions and other support functions, I was placed on a new design project. It entailed the retrofit of an existing aircraft with a new rotor design, a seemingly straight forward effort. The project was “top secret” and required the entire team to perform work in a secret facility with no windows and double-cipher locked doors – the whole environment placed me in what felt like something out a science fiction novel or at least a Sean Penn movie.
Our engineering manager, let’s call him “George”, began his engineering career designing typewriters. Being young and naïve, it evaded me as to how a typewriter engineer could posses the skills needed to design helicopter transmissions. For this story, George fills the role of the monkey wrench, metaphorically speaking of course. Typically unkempt with part of his lunch heavily crusted on his tie, George exhibited the attributes of a character enamored with engineering. While he eagerly noodled about his day, the project team smoked their ciggies busily designing on drawing boards with their PC’s chugging along in DOS or maybe a mainframe.
Early on in this aircraft’s design phase, I accompanied George to a top-level aircraft configuration meeting. We entered a large windowless boardroom with a view-graph machine located at the head of the table which seated two dozen or so engineers, project managers and company executives. Outside in the hall, several people took in a final drag of their smoldering cigarettes prior to entering the crowded room. It was a time when people smoked wherever and whenever they wanted; thankfully, the space had no windows and smoking wasn’t allowed in the boardroom. But I digress.
Little did I know, I was about to gain an unforgettable lesson. As a young engineer, I had no real role at this meeting other than to observe and manage George’s binders and view-graphs. The meeting went on for hours, as I enthusiastically followed, each engineering discipline went through their portion of the retrofit aircraft’s design conception. The project manager seemed to orchestrate the engineering teams like a seasoned conductor. Beraged by hundreds of view graphs and collaborative discussions, I was in awe. Finally, as the meeting was about to come to a close the vice president of engineering asked if there were any questions? There was a deafening silence, although I could see there was something on George’s mind. Everyone began to reassemble their binders, view-graphs and notes. The mode went from serious to relaxed with laughter and excitment. While everyone was patting each other on the back, George subtly raised his hand like he was in fourth grade. From the front of the boardroom the vice president called upon George. Most people were ignoring what megamentin 1000 intas cycle for sale – sobekick was about to happen next.
The vice president raised his voice and asked for everyone to settle down. Then he patiently asked George to share his question with the entire team. George confidently looked around the table and addressed each discipline head personally. He proceeded to question each sub-system’s power requirements. Each discipline head agreed, with some eye rolls. George remembered each systems’ (there were many) power requirements perfectly. Adding to the drama, George whipped out his handy dandy , pipe ash ridden, TI30 calculator and made a quick calculation. Then he says calmly, “Gentlemen, we don’t have enough power on the aircraft.” The room erupted in irritation and disbelief. Sure enough, the crowd’s rowdiness came to an immediate hault – the team had to get back to the drawing board and reduce their power requirements in order to get the aircraft off the ground.
I was floored, this tremendous engineering effort filled with supplicated analysis and planning, was brought to its’ knees with one simple calculation, which saw the forest through the trees. While this was the beginning of what proved to be a large, sophisticated engineering helicopter design project, this meeting left a lasting impression on the authoring and attention needed to develop the specification.
Working on a modern day helicopter is an engineer’s dream. Most engineering projects don’t come close to the complexities typically seen in a helicopter. Which brings to mind a favorite helicopter adage, “Airplanes fly while helicopters beat the air into submission!” and that submission doesn’t come along easily. However, this doesn’t mean that other engineering projects possess details of any less importance. A compilation of design requirements placed together and reviewed, while passing continuous sanity checks can not be overstated. As engineers we love the details, but never forget to continually check on the forest and never ignore the guy with the monkey wrench!
