Back to Top
The One Thing You Need to Know

By Dougal Maclise

A Mission Defined
At the flight readiness review the day before we were scheduled to fly, I had to stand up and say, “We need a flight to know if we’re ready.”

It was a sensor payload project. The payload, a digital camera and a computer, total weight 17 lbs., was flying aboard the Pathfinder solar-powered airplane, an Unmanned Aerial Vehicle (UAV).

Steve Wegener, who was in charge of sensor technology in the Environmental Research and Sensor Technology (ERAST) Program, had come to me about a year earlier and said he needed a project manager. Steve had a subset of projects under ERAST, and what he had in mind for mine was to take colored infrared images of the ground from the UAV and get “whatever” information we could from them. The “whatever” we would fill in later.

There was just one requirement: Take high-resolution images from the UAV and put them on the Internet in real time.

“One requirement?” I asked incredulously. To me this was impossible. I’d never had a project with only one requirement. Normally, they came in volumes.

But when projects are rife with uncertainty, especially technological uncertainty, formulating requirements too early in too much detail can be a major mistake.

Why do you accept a project? There are hundreds of reasons. Every project manager has his own. This one I took because it seemed liberating when compared to what I was used to as a project manager. What I heard Steve saying was this: ” How you do it is up to you and your team.”

I remember the reaction of the team. They were incredulous too. “Here it is — this is all we’re doing,” I said when we were all together at the first team meeting. Everyone’s eyes were trained on that one sentence. I put it on a slide and pointed to it.

There were 15 of us in the room, it was completely quiet, and then someone asked, just like I had, “One requirement?”

Like Steve, I pretended to be matter-of-fact about it. “Yeah.”

Most of the time the people generating requirements tend to work down to the design level. Early on in the project this costs a team expensive amounts of time and doesn’t allow them much flexibility. When it is possible to formulate requirements early and they stay the same throughout the project, then it probably pays to formulate them early. But when projects are rife with uncertainty, especially technological uncertainty, formulating requirements too early in too much detail can be a major mistake.

We had countless problems to overcome, and each time we solved one, we always seemed to find more.

You cope with uncertainty by not giving yourself too many requirements up front. One requirement for me distilled the project down to what it was really all about, and such simplicity made it so much easier to stay focused and trained on the goal — despite the many difficulties we had.

It sounds simple, just one requirement, but trying to pull it off was anything but that. We had countless problems to overcome, and each time we solved one, we always seemed to find more. The reality is there was more than one requirement, many more, but these were the ones we gave ourselves.

Trusting Your Team
As a Project Manager, you want to give your team as much flexibility as possible, but the problem with a project like this where there is so much uncertainty, you surely are going to lose sleep wondering how much you should be on top of every little thing. This was a project whose true name should have been UNCERTAINTY because there was so much of it. One way we allowed ourselves to be flexible was to build a competent, robust team. I had a deep trust in and respect for everyone who was on my team; I had to because I took great pains in selecting them, and I let them do what they needed to do to get the job done.

The One Thing You Need to Know 2a

Pathfinder aircraft liftoff on altitude record-setting flight of 71,500 feet over Hawaii.

The greatest challenge of the project was the data network from the plane to the Internet. First, I checked to see what radio links we could use from the plane to the ground. There were two modems available at 9600 baud, one for each payload. For an 18-megabyte image, it was going to take 4 1/2 hours to download. I probably had 6-8 hours of flight time. I could then only download 1 or 2 images per flight. That wouldn’t work. We needed a much faster connection.

The plane also had a video link. Maybe we could use that somehow. Stan Ault from HyperSpectral Imaging, Inc. volunteered to take on that challenge. He had a concept for converting the digital image data into a sort of barcode that he could encode into a video signal that could be captured and de-converted on the ground. I told him I would gladly leave the details to him.

At the other end of the network, we would need a server that the public could connect to from the World Wide Web. Flight tests took place in Hawaii at the Pacific Missile Range Facility (PMRF) on the island of Kauai. PMRF had a strong firewall, and they weren’t going to allow anyone from outside to get through, so we didn’t have an option of putting a website on a computer there at the base.

I gave this problem to Don Sullivan to figure out. Don was an expert in networking and computer applications. Don researched the Internet connections and found they were extremely complicated and fragile, but he was able to deal with PMRF and got them to set up a connection for us through their firewall that we routed back to a server at Ames Research Center in California. The route was to go from Kauai to Maui via Honolulu and then to the mainland by an underwater cable. It was all quite complicated, and thank God Don was on top of this. It was one of those situations where keeping me blissfully ignorant was probably in the best interest of the project, simply because it was in the best interest of my health.

We also worried about the video link we were using; it was the only visual link that the flight crew had to the plane during most of the flight. For us to download an image the flight team had to switch that video transmitter over to our payload and take it off the video camera they were watching. During that time they had no visual way of monitoring the plane. It was sort of like asking the pilot to close his eyes for about 5 minutes.

The next problem with this link was that we could not test it completely on the ground. When we ran a flight simulation, we found that there was reflection of the signal off the ground that created too much interference in the video signal to be able to capture the digital data out of the images. We figured that once the plane was in the air, this problem SHOULD be eliminated.

Then there was the “real time” issue. The requirement was to take high-resolution images from the unmanned plane and put them on the Internet in real time. The term seemed a bit nebulous to everyone. NASA has only a few web-operated payloads, and no one was quite sure what our benchmarks were. When I asked Steve Wegener, he said nothing more than “Do the best you can.”

Do or Die
The day of the flight the morning sky broke clear and beautiful. We were committed to a full day of flying whether the payload worked or not, and I knew it would be a long day if things didn’t go our way; it would be several hours wallowing in our failure. We had tried mimicking the system on the ground in several ways and could not do it. Apparently only a flight would prove the system and, by this time, we would only get one flight, one chance.

The day before the flight there was a fire under the streets of Honolulu and it burned up part of our Internet link. Fortunately, Don had it under control, but it was another close shave that I really didn’t need to know about. When he told me, I said, “What happened to our plan about not telling me what I don’t need to know?” I gladly stayed ignorant of a lot of things, but to be honest, I rarely felt anything remotely close to blissful.

One of the problems we could not solve up till the end involved some glitches with the software on the payload computer. The only solution we had for it was what we called a therapeutic reboot, basically the same thing you do on your home computer when a software application causes the system to crash: you turn off the machine.

On the runway, as the plane was being rolled out, we tried to take a picture and the system crashed. We rebooted — and prayed. Finally, just after take off, we managed to get a picture and were able to put it on the Internet in about 24 minutes. Everyone — and I mean everyone — breathed a sigh of relief, although I still kept my fingers crossed.

Now and then the payload would hang and all we could do was tell the pilot to do the therapeutic reboot.

The purpose of our mission was to look at the health of vegetation on Kauai. By the brightness of the infrared bands in the images we captured scientists could see how healthy the plant life was, and, while we were in the air, instruct us to fly over different areas and take more pictures. We learned from the scientists where to go to get a shot of a broken irrigation line, where they thought there was an outbreak of something, where there appeared to be an immature crop, and anything else they wanted to see.

Things seemed to be going fine once we were in the air. Still, my stomach was in knots. Now and then the payload would hang and all we could do was tell the pilot to do the therapeutic reboot. Once the pilot got used to flying without his video link, he seemed okay with this. We were flying at 30,000-40,000 feet mostly, much lower than the high altitudes Pathfinder had reached when it set the world altitude record. A 17-lb. payload doesn’t sound like much, but the plane itself without the payload weighed a grand total of 500 lbs. It’s like the mountain climbers say, ‘Every ounce counts.’

We managed to get 16 pictures altogether. On the website we used to display them they showed up as dots on a map. You clicked on the dot and this brought up the picture. We were able to get the image up on the Internet in just under 20 minutes. Not bad. No one was complaining we were too slow.

I thought the high drama was ended for the day, but that was a bit premature.

As night fell it looked like the mission was over, and quite a success it appeared to be. I thought the high drama was ended for the day, but that was a bit premature. On the way back to PMRF the winds weren’t dying down. The plane was operating on batteries now, and the sun having long set, it couldn’t stay up indefinitely. The plane actually had to approach the landing strip flying backwards. The pilot did one last swing out over the breakers and there was very little wing space between the water and the wing tip. In the last 50 feet the winds died down enough for him to turn the plane around and land it coming in forward. How close we’d come to losing the plane I don’t think anyone cared to contemplate.

We were all wrung out emotionally from this long day. Everyone just wanted it to be over with. Yet there was one requirement still to be met — the celebration! Again, we had a clear objective and almost any plan to get there would suffice.

Lessons

  • On projects with a great deal of uncertainty it is best not to specify requirements too early in the life of the project and thus limit the team’s ability to be flexible in addressing the uncertainties.
  • A project manager must trust his team. As the overall team leader you must allow team members to take the lead on issues in which they clearly have an expertise you do not.

Question
In most projects, requirements are formulated early and in great detail. Is this because most projects actually have to cope with low uncertainty, or because upper management does not tolerate high uncertainty (and therefore expects the project team to behave as if there is low uncertainty)?

Search by lesson to find more on:

  • Requirements
  • Prototyping / Innovation
  • Risk

 

About the Author

 Dougal Maclise Dougal Maclise has been a member of the management team on several projects at NASA’s Ames Research Center during the last five years. He is currently the Team Manager of the Systems Engineering Team for the Integrated Vehicle Health Management (IVHM) Project. Before joining the IVHM team, he served as Engineering Manager for the Vertical Motion Simulator Modernization project and was Project Manager of the ARTIS payload project for the ERAST program.

About the Author

Share With Your Colleagues