Saturday, March 31, 2007

Rodan the Destroyer and Getting Things Right

The other evening, my friend, George P. Burdell (a man known for his sense of nostalgia), and I were sitting around reminiscing and remiserating our days at Ma Tech. Suddenly, George slapped his knee and whooped.

“Do you remember when you got that B in your aerospace design class for turning in a paper airplane? That took Big Kahunas!”

George just had to bring this up. I turned away, crestfallen, to the setting sun. Nineteen years later, I am still mad about the B.

I began my enginerding career as an Aerospace major (I transferred to Mechanical in my junior year). In the spring quarter or 1987, I took “Introduction to Aerospace” from Rodan the Destroyer.

He was known to fly at supersonic speeds, even at low altitudes.

For the final class project, Prof. Rodan assigned a design project in which we were to use the principles we had learned in his class to develop an airplane that could perform three flight functions:

  • fly “straight” across the length of the classroom

  • turn a vertical loop in flight

  • turn a horizontal loop in flight

The only restriction placed on the design parameters was that to perform the maneuvers, we could only add/remove mass or change the control surfaces of the plane. Those were the only instructions he gave us.

Since this was an introductory class, I didn't know much yet about airplane design. I thought the best way to proceed was to copy the designs of aerobatic planes and scale them to a hand-held size. I used balsa wood and card board. Nothing worked. I considered stealing the Tech Tower “T” just to vent my frustration.

Then I remembered a delta wing paper airplane I was fond of making as a kid. It would do all kinds of aerobatics just by modifying the wing surface with flaps cut into the trailing edge of the wings. If the flaps were both turned up, the plane would do a vertical loop. If the flaps were turned in opposite directions, it would turn in a horizontal loop when thrust with a quick flick to the left. I was just about there. All I needed was to get the plane to fly straight for about 50 feet. But the plane was too unstable. It seemed unwilling to respond to any control surface modifications I made to achieve the final requirement.

George P. Burdell, a man known for his flights of fancy, offered brilliant advice. “Why don't you add mass to it. Maybe the added momentum will overcome the slight pressure changes that force the light plane to turn.” By taping a penny in the forward section of the airplane, the plane flew with stability in a straight path of just about the length I needed. A little practice got this right. Now all design criteria were met. The plane that did exactly what Prof. Rodan had ordered.

The due date of the project finally arrived. Everyone else showed up in class with the kind of things you would expect NASA engineers to design. Balsa wood monstrosities. Gleaming shellac. Rubber band powered motors. I swear, one student's plane had jet engines made from small aerosol cans. I felt like the one Cub Scout at the Pinewood Derby whose dad didn't make his car. Did these kids' parents work for JPL?

But then the test came. No one's plane could perform according to the design criteria. They were just too big and too bulky to fly within the confines of the Guggenheim classroom on Cherry Street. No one's plane, except mine, that is, would perform as specified. I felt victorious. My little paper airplane ruled the roost.

But then a cry went up from the masses. “We have to fly our planes outside!” The class teetered on the verge of mutiny. Rodan gave in. We went outside. Paper airplanes don't fly well in the brisk spring winds of Georgia.

When I received my grade for the project, Prof. Rodan had assigned me a D.

A D! I went to argue my case. “You said our airplanes had to perform the three flight function in the classroom. My airplane was the only one that would do that.”

“Yes, but I wanted something more substantial than a paper airplane.” Prof. Rodan expelled his uranium ignited nuclear breath.

“But you didn't say that. Your only criteria was that the plane fly the three functions in the classroom. My airplane alone did that. Everyone else deserves a D.”

My atomic shield had worked. Rodan again gave in and moved my grade to a B. I was nonplussed, though, because I believed then, as I do now, that I deserved an A.

Now, I don't usually assume to know people's motivations, but the cynical side of me suggests that Prof. Rodan wanted his students to reflect his brilliance as a teacher. When I'm less cynical, I think he just wanted to see something snazzy. But he certainly couldn't state either preference, likely for several reasons.

“It sounds like you learned a valuable lesson about design, especially design for clients,” quipped George.

By now you have probably guessed the problem: Prof. Rodan had a hidden, unstated preference. Simple requirements analysis won't uncover those. Often times, clients haven't even considered what is motivating them to seek a solution or satisfy a desire in the first place. They are simply responding to a burr in their saddle or a bee in their bonnet with a limited set of easily accessible alternatives. Such ambiguity is the bugaboo of planning, design, or problem solving opportunities. Even if one satisfies every client-specified design criteria, the client may still express disappointment and frustration that the real problem hasn't been addressed according to the underlying preferences. And if you have ever been the consultant or engineer trying to help in such a situation, you were likely completely caught off guard. After all, you did exactly what the client asked. The problem is, you brilliantly solved precisely the wrong problem. [Editor's note: In a recent client engagement, I was told that another consultant was released, in part, because he provided what the client asked for, just not what the client wanted. I felt very bad for this fellow.]

And things were likely worse if you went beyond the client's expectations by providing more bells and whistles. Design scope creep simply solves the wrong problem with greater flourish.

What do you do? Shouldn't you solve the problem as the client asks? Shouldn't you always do more than the client expects?

The answer requires two things from you. First, you have to give up any notion that you are the expert. You may be the expert in your design field, but you are not the expert in your clients' preferences. Only the client has such expertise, but it may take some clever facilitation to draw it out. Second, you must help transform your client into a values-based decision making organization. What this entails is digging and prodding to find out what really matters most, to uncover the primary objective and all its supporting means objectives. Once this hierarchy of values has been resolved, you can work with your client to be much more creative about the alternatives that can be exercised to achieve the real goal.

A few other benefits arise as well from this process. Once the primary objective has been clarified, you can know exactly how to measure success with little or no ambiguity. Also, once you understand how the means objectives relate to support the primary objective, you can begin to gain insights into how trade-offs may have to be managed. But most importantly, your client will begin to see you as a trusted advisor who does much more than simply react to requests for proposals. You will be seen as a person who has a vested interest in the client's success. And that makes everyone happy in the end.

I eventually left aerospace engineering for the highly lucrative career of secondary education (which I eventually left for med school, then engineering again, and finally the exciting field of hot dog sales). But Prof. Rodan taught me a valuable lesson about serving my clients even if I learned nothing about airplane design. Today, my clients are happier for it, especially when they fly.

Editor's Note: to learn more about values-focused thinking, read Ralph Keeney's book,

Value-Focused Thinking: A Path to Creative Decisionmaking.

I highly recommend it.

No comments: