When To Say No

By David Collins

Early in my career, I was asked to finish instrumenting the Hubble Space Telescope as it traveled from California to Kennedy Space Center. I worked at Kennedy and was inheriting the job from a research lab at the Marshall Space Flight Center, and I would be getting $85,000.

Because of the size of the telescope, and the cost to transport by air, it was decided (by whom, I’m not sure) to move the telescope to Kennedy by boat. The folks at Marshall told me everything was fine, they’ve got it all set up for me, and all I needed to do was finish it up, just a little polish really, and we were golden.

“Okay, but I’d still like to go over the system and the requirements and analyze them,” I said.

I did an analysis, and what I found was a bear trap. I learned the system was running on something far less than a state-of-the-art computer, had skimpy instrumentation, and had some serious limitations. How serious are we talking? Well, every 90 minutes we had to shut down for 15 minutes. “This is the Agency’s premiere mission,” I said to myself, “and I’m supposed to instrument it to make sure it gets to Kennedy from California safely, and I’m losing 15 minutes of data every 90 minutes.” This didn’t sound too good to me.

To make matters worse, the boat they selected to get it to Kennedy went by the nickname of the “Rusty Scow.” Conditions inside the hold of the ship were far less than favorable for the transport of hardware as sensitive as this. The hold of course was where the telescope was going to be stored. I told my management I thought air transport was the way to go.

I could just see it. Hubble gets to Kennedy and it doesn’t work. They analyze the data and say you’re missing 15 minutes of data every 90 minutes. What’s going on? How can we tell what went wrong?

I didn’t want to be responsible for losing data. I also didn’t want anyone to think I was less than equal to a challenging project. I was still a young project manager, and in the NASA that I came up in project managers were not supposed to turn down jobs. Good project managers accept all jobs. All jobs are good jobs. Refuse a job and you jeopardize your future.

I had accepted many “bad” jobs in the past, but this one was over the top. How could I turn this job down and live to tell the tale? I’d better do some homework. How did the situation get this way? I put out feelers and learned that the lab had accepted the job with too little budget because Hubble had had some financial difficulties. They had been given $250,000, the vast majority of which had been used to purchase a research-grade instrument for the job, and one that naturally they could use later at their lab. I learned that Marshall was responsible for Hubble in all phases of the program, but that responsibility would be transferred to KSC for its transportation from California to Florida when we accepted this job.

After thinking a while, it came to me. My issue was not the job or being responsible for Hubble; it was the constraints I was saddled with. The project was budgeted for $250,000, but I was not satisfied that this was an honest figure. I talked with colleagues, more experienced project managers whom I trusted. I talked to contractors. I got the best information I could get my hands on and sat down and did an estimate of what I believed it would take to do the job right. It came to $1.5 million. A little bit different than the $250,000, and a far cry from the $85,000 they were offering me.

So now I had a good estimate, some background information and a bit of a story as to how things had gotten this way. Now I needed an approach. Just because the job was impossible didn’t mean that I wouldn’t end up with it. I needed management to feel some direct ownership in the outcome. I needed either the funding to do the job right or to have management turn it down. I finally came up with an approach.

I went to my Director’s office and said, “Sir, you’re about to be responsible for the Hubble Space Telescope, and I think there are a few things you need to know.” I went through the scenario with him, I laid out the pros and the cons, what budget was needed to do it right, and at the end of it he picked up the phone and called Marshall. “You give us $1.5 million to do this or you can have it back.”

End of story: Marshall took it back. Fine with me. Just by the way — the telescope never traveled by ship. An aircraft brought it to KSC.

Hubble Space Telescope during preflight processing at Kennedy Space Center.

There are a couple lessons here. One is you can say “no,” but do your homework. When it is important to learn the pedigree of a project, especially when you are not satisfied with the information you are given, then don’t be lazy. Get to the bottom of things. Had I not done my homework so that I could lay it all out before my Director, the results could have been drastically different. Imagine that the Hubble telescope got to Kennedy and didn’t work. My career certainly would have been stunted.

Two, it can even be good for a project manager to have a reputation for not accepting every job. After this people started saying about me, “He won’t accept a job unless he knows it can be done.” As a result, people wanted to work for me. If I took a job, my team believed it was doable — a great starting point. I see a lot of jobs handed out where the team thinks, ‘Dear God, this is not possible.’ Not a good way to begin. It also helped because management thought, “He’s going to give us the straight scoop. He’s not going to hold back on us.”

Contrary to what I originally thought — saying “no” would end my career — in this case it probably helped me.

Lessons:

• Do your homework. It may save you at the least from an embarrassment and at worst from making a career-damaging mistake.
• Doing what you believe is right and maintaining your integrity can enhance your career, even if it means saying “No” to a project.

Question
What do you believe are the consequences of turning down a project as a young project manager? Would you have said “No”?

About the Author

David Collins is currently on a detail assignment in the new X-Flight Division at NASA Headquarters. He has worked for NASA at Kennedy Space Center for over 19 years in a number of capacities, including Researcher, Lead Designer, Chief of the Instrumentation Section, Project Manager, Deputy Associate Director for Technology Development, and most recently as KSC’s Senior Systems Engineer. He has been a member of numerous teams influencing the changes both within KSC as well as the Agency, including two reorganization teams and the “Faster, Better, Cheaper” Team.