Refining Procedures: Calling All Stakeholders

By Ray Morgan

Background
For the longest time, we were not procedures oriented at AeroVironment. One guy at the top typically wrote flight procedures, and often that guy would leave out a whole bunch of stuff because, after all, he’s just one guy… there were things he didn’t think about.

Another problem that stemmed from having just one guy write the procedures was that not everyone used the same nomenclature. The guy who writes a procedure gets used to calling something by a nickname and that’s how he identifies it in the procedure. But if other people who have to use the procedure aren’t familiar with that nomenclature, you can imagine their frustration in trying to understand what the author of the procedure is talking about — not to mention the potential for disaster that exists because of this.

But the most significant problem we found with autocratically handing down procedures was that people were far less likely to follow procedures that they neither created nor could change. Procedures are tools. Like tools, they need to be sharpened and honed. Any good craftsman wants to sharpen his (her) own tools. What’s more, people feel less stress when they can control how they perform their tasks.

When developing small, quick-and-dirty prototypes, it is often most economical to just “fly it” and see what kind of problems there are. Sloppiness is intolerable when you work with expensive and essentially irreplaceable, sophisticated airplanes like the unmanned, solar-powered vehicles that we specialized in at AeroVironment. With unmanned airplanes, what the pilot does is just a tiny fraction of what the airplane is trying to do. To fix a problem, you usually need to get a grasp of an entire system. If you’ve got a bunch of people who understand parts of the system, you bring them together to make intelligent decisions using each of their areas of expertise.

Hence, we realized a couple of commonsense things to help refine our methods of writing procedures: (1) one person is not as smart as a group, and (2) a person at the top may not understand things the same way as does someone looking at it from a different perspective, such as a technician who is actually performing the task.

Creating the Procedures
Our first rule was always to “put the person closest to the problem closest to the solution.” Whenever possible, the person(s) who actually performs the task creates the procedure for it. Providing this type of ownership is invaluable. It is also the most efficient way to create the procedure. Certainly, we had people crosscheck their procedures with co-workers, but we recognized that we had to provide a way for handling the inevitable mistakes. This process of continuous improvement by the “owner” of the procedure accelerated the rate of development of the procedure, and allowed us to both rapidly refine a procedure and also allow for a quick response to changes in the system during the flight test program.

Refining the Procedures

1. We read through the procedure with a group of people who are involved. We also invite other people who are not directly involved with the procedure to provide some objectivity. We’ll get a bunch of changes from that — that’s generally where we catch the inconsistencies in nomenclature. On the next iteration the labeling is usually very close to being error free.
2. We then get everyone together for another read through. This time we have the actual hardware in front of us, and we’ll practice just as we would if we were going through a flight — a prototype of sorts. This time we catch, for example, that the pilot has turned the damping switch off before he started another test that required the damping switch to be on. The guy who owns that process — it may be the pilot, it may be a stability and control engineer — will take note of that and be responsible for correcting the current version of the procedure.
3. The next time we will sit at the ground control stations — we have a stationary one and a mobile one (that follows the aircraft during takeoff and landing). We’ll go through the whole process again with the same people, using the latest rewrite. This is the last run-through before the actual flight.
4. After the flight, we get a group together to look at whether there were any abnormalities that could be attributed to a procedure or discuss any “red-marked” changes to a procedure made during the flight. The person who is the owner of a procedure captures any issues that came up and corrects the procedure before the next practice.

Tips
This process allowed us to come up with a procedure that everyone understood and could follow to the letter. You must see it as a continuous improvement process. With a group of people working together you can probably turn out a perfect procedure in no more than 2 to 3 iterations, depending on how complicated a procedure it is, of course. Another benefit is that more people feel ownership for the procedure. Not every project may require such a rigorous approach for developing procedures as we used at AeroVironment for developing flight procedures, but certainly all projects benefit from this sort of attention to detail.
Example: Surf/Beach/Shallow Water Crash of Aircraft

Symptom:

• Aircraft crashes in or near surf. Aircraft is close enough to shore that it could migrate onto beach with wind and wave action.
• Aircraft crashes on sand, but is exposed to surf spray that wets surface.

Rules:

• If Aircraft crashes in deep water, the aircraft will be allowed to sink, or be scuttled and not recovered.
• If Aircraft crashes in the surf, where it is evident it will be moved on shore by the winds and currents, it must be recovered.

SHOCK HAZARD (120VDC)

• It is possible to receive a lethal shock from the aircraft whenever it is in the sunlight, if surfaces/components have been exposed to salt water. The solar array will continue to produce power in the daylight, and the saltwater could provide conduction of lethal voltages and currents in an unpredictable fashion. Unless fuses are blown, Li batteries also provide shock hazard, even at night.

Pilot Tasks:

1. Turn all motor switches off.
2. Contact Aircraft Pilot, if airborne, and request visual assessment of crash site and relay to Mission Director.

Engineer Tasks:

1. Provide GPS location to Mission Director.

Mobile 1 Tasks:

1. Drive Mobile GCS to within visual range of Aircraft, if near runway, to get best signal path from Mobile 1 to Aircraft, and allow Mission Director to assess situation.

Mission Director Tasks:

1. Proceed with MISHAP PLAN

General Comments:

About the Author

Ray Morgan has recently retired as Vice President of AeroVironment, Inc., where he established the Design Development Center in 1980, the division of AeroVironment that develops and produces its aircraft, serving as Director until April 2000. Mr. Morgan has overseen more than 75 projects and the development of over 50 unique vehicles, including over 35 Unmanned Aerial Vehicles in his tenure at AeroVironment Inc. AeroVironment has been globally recognized as a pioneer in solar powered and electric aircraft, and has placed 5 of its vehicles in the Smithsonian Museums.