specification

The Monkey Wrench: A Lesson in Developing Specifications

November 12, 2014 by Adept Engineering 1 Comment

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 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!

You have a wild idea. Will it actually work?

September 24, 2014 by Adept Engineering 1 Comment

As an engineer, I’ve been involved with my share of wild ideas, visions and desires. I’ve listened to and entertained, against my better judgment, some many of a wild idea. Some ideas I regret not to have taken more seriously, several I was retained to prove or disprove their validity, and many that developed into some really exciting devices. Along the way it became evident that there were some basic and necessary guidelines, a few of the key ones were: don’t be too quick to judge, focus on the details and always keep the goals in sight.

In this post, we revisit the engineering process. In an earlier post I was a bit premature launching immediately into physical prototypes. As designers and engineers we well know that building a prototype has a powerful lure – everyone wants to witness their visions and ideas enter reality. However, a poorly executed prototype does only one thing, sends you back to the drawing board. Prototypes have one basic purpose, risk reduction. Previously discussed in an earlier post was the specification, but for now, let’s set that topic aside. Before the specification, there must be a sound idea and vision in which the engineers can apply their wares. The idea needs to be sound and tirelessly driven with a clear understanding of the desired end result.

WildIdea-300x198 — What makes a sound idea?

What makes a sound idea? There are a dozen adjectives that immediately come to mind. But foremost, it must satisfy a need and offer a perceived value. Whether the need is imaginary or real, the need must be well defined and understood. Understanding and defining the need is your charter, how to satisfy and develop it, is not. You must resist the temptation to begin to conceptualize a solution, that, although you may think this may help clarify your thinking, it will do nothing more then defer you from your primary charter. It is essential to focus on the “why”, “where” and “what for”, not the “how to” — leave this up to the engineer.

I can’t begin to tell you the countless number of concepts and prototypes that have been brought to Adept with the simple request to “make it work”. Conversations often begin with, “we have a design that is 90% complete, but we need some engineering help to…blah, blah, blah…..(make it work!)”. Thankfully, they realized they needed engineering help. Although, when it comes to new designs, making it work must begin from the ground up. It must be grounded in solid engineering principles targeted at meeting each and every; why, where and what for. My intention is not to insult anyone, to be honest, several of the concepts and prototypes I’ve been brought were well conceived and cleverly constructed. But generally lacked the necessary attention to detail and adherence to engineering principles.

By now, you’ve put two and two together and realized where this post is leading us. If an idea is well understood and established the next step is a specification. The specification is merely a document that defines:

What is available?
Where will your idea operate?
Who or what will operate your idea?
What must the end result be?

This holds true for devices, products and processes. A colleague of mine once put it quite clearly, “without a specification you (the engineer) will never know when you are done.” I’ve gotten a lot of mileage from that statement. Not only does the specification provide a clear delineation of the need to be satisfied or problem to be solved, it also serves as a reminder of the requirements and target, so they are not forgotten. The specification does not need to be complicated or cast in stone and can be in the form of a working document. If you are not an engineer, it can merely be a list of requirements and subjective wants. IT is part of an engineers job to take that list and compile is into the necessary technical guidelines that will define your vision.

success — Engineering ideas requires commitment !

Throughout the engineering process, it becomes evident requirements may oppose one and other and/or place an excessive burden on the overall design which may be damn near impossible…and the engineer’s nemesis! Trade-offs must be made in order to find the ideal balance of performance, cost and risk. These trade offs will lead to decisions made early on in the process while the concept and specification are being fine-tuned. These decisions will either make or break a project. They are not to be taken lightly or made in haste. Again, keeping the end-game can not be mentioned enough. But a well formulated idea (from a wild idea) with a proper specification will lead you to that result. Obviously, further discussion is required about this extremely important point in the design process and will be left to later blogs, stay tuned.

Making Wise Prototype Decisions, Don’t Drink from a Fire Hose

July 10, 2014 by Adept Engineering Leave a Comment

In my previous post, I mentioned the responsibility of deciding when to transform a virtual prototype into a physical prototype. I may have been a bit premature having this discussion with my readers. As you may be aware, there is a great deal of hype – surrounding “desktop printing” and I may have jumped on that bandwagon a bit hastily. This technology has been around for decades. True, some very industrious individuals brought this technology main stream by offering desktop printers within a price point of a personal computer. However, before you get to play with this new toy, you must have a “solid model”. While there are many tools to create solid models, engineering or designing a solid model is a very different undertaking.

Before you consider going to a physical prototype, a clear understanding of the problem at hand is critical. For the engineer, this understanding is in the form of a specification document. Preparing and formulating a thorough specification requires capturing a client’s ideas, requirements and desires into a set of boundary conditions describing a system to satisfy their needs. It is up to the engineer to truly listen to an innovator’s visions and resolve them into a specification document..

The image above is the prototype of the Sigelock Systems vandalism proof fire hydrant.

Developing a specification document can be daunting. Do you think I am overstating this effort? I am immediately reminded of a client Adept helped several years ago. This client is an excellent example of a consultant’s worse nightmare and dream client all wrapped up in one package.

It was early in the morning, my phone rang and a gentleman introduced himself as George Sigelakis, a retired firefighter. He proceeded to passionately explain his idea for a revolutionary fire hydrant. The invention sounded like it might have merit. With genuine interest, I sat up in my chair and began to listen. He explained he worked with several other engineers and began making prototypes. While the prototypes were really close to what they needed, there was one problem, they don’t work!?

An installed Sigelock Fire Hydrant.

At that point, I began to explain my methods and what I think needed to be done. I was very direct and perhaps ended the phone call a bit prematurely. Fortunately, a week or so later, the phone rang and it was the same gentleman. He also felt our discussion was too short and called back to set up an in-person meeting to further discuss options together with his investor. This meeting revealed hand drawn prints, and miscellaneous parts along with a more detailed explanation of the vision at hand. There was no doubt this group was working on this project for several years and determined to bring this product to market. However, it was also immediately obvious the existing design did not meet their requirements. After hours of explanation and discussion, the client seemed assured I knew what I was talking about but still was not clear on why their design wouldn’t work. Concluding the meeting, I said I would analyze their existing design and prepare a report diagnosing the designs possibilities. They agreed. After reading the report they decided to ask Adept to provide a product redesign proposal.

Understanding a client’s needs is paramount to the success of any project. Fortunately George Sigelakis, the inventor of the Sigelock Systems, had a clear and precise vision of what his hydrant needed to be. Armed with clear direction and persistence, Adept was able to help establish the necessary guidelines (specification) to create the Sigelock hydrant.

There are many lessons to be learned from Sigelock Systems. One such lesson is sheer persistence. Staying the course is imperative to the success of any design. All design efforts are a conglomeration of ideas, people and resources. Perfectly coordinating all these elements requires diligence and often some luck. Along with persistence, decisions need to be made. Throughout the design and developement process there are no shortages of decisions. Some of the most important judgments come early on when the desire to “get moving” is very strong. These decisions can tend to be a bit rushed, at times. One of my favorite engineering cliches is, “there is never time to do it right, but there is always time to do it over”. This may be true for the United States government, but not for the product developer.

Did I say that it’s a wonderful time to be an engineer? The tools are nothing more than miraculous. I expect that this appreciation comes from the unique perspective of engineering from an era that went from the drawing board to the computer and beyond. The decision to leave the virtual world and enter the real world is similar to most engineering decisions. It is filled with trade offs, generally weighing the benefits from the risks. And, often the reason to stay virtual or go physical is to mitigate risk. Confused, you should be, because it’s not easy.

specification

Footer