Since 1963, Donald Margolies has served in a number of management positions at the NASA Goddard Space Flight Center, and in 1998 received NASA’s Outstanding Leadership Medal.
Margolies received the award in recognition for his innovative leadership of the highly successful Advanced Composition Explorer (ACE) mission. ACE launched in August 1997, and has been providing scientists with information about space matter and near-real-time advance warning of geomagnetic storms. ACE is one of several missions run in the NASA Explorer Program, which is characterized by relatively low to moderate cost and small- to medium-sized satellites capable of being built, tested, and launched in a short time.
Most recently, he served as observatory manager on another Explorer Program mission, the Microwave Anisotropy Probe. Prior positions at Goddard include project manager for the Total Ozone Mapping Spectrometer mission, deputy project manager for the Explorers and Attached Payloads Project, observatory manager for the Solar Optical Telescope Project, observatory manager for the Active Magnetospheric Particle Tracer Explorers Project, and spacecraft manager for the Magnetic Field Satellite.
As he approaches retirement, Margolies has been active in the APPL Knowledge Sharing Initiative, including serving as a member of the ASK Review Board. His other awards include NASA’s Exceptional Service Medal and the Goddard Space Flight Center Outstanding Service Award.
You wrote a story about your work on the Advanced Composition Explorer (ACE) project for ASK (Issue 9). I remember that you said that your “primary objective was to launch on schedule.” How do you get a project team to make that happen?
I have approached it in a number of ways. For example, on one project I have gone so far as to take my team away from our normal business site for a week. Everybody sat down and developed their schedules, and then using such high tech tools as pencils, paper, and rulers, we put together a networking diagram. People could look at that and say, “No, no, this isn’t right, we need to do this first.” That was one way I got people together to agree on a schedule.
On some projects, schedule slips have been blamed on tension between the science team and the project management team. Did you do anything specific to try to mitigate that sort of tension on ACE?
I worked closely with both the principal investigator, Dr. Edward Stone, and the payload manager, Allan Frandsen. My relationship with Al took on much greater significance as the project evolved, because fairly early on Dr. Stone also became the director of the Jet Propulsion Laboratory. At any one time, there were always several things competing for his time and attention. Still, we communicated regularly.
Did you two have some kind of system set up for that?
Only in that we made it a practice not to ignore communication. Dr. Stone and I set up a schedule to talk with each other on the phone every week. Even if it was to say that the weather was nice in California and there was nothing much happening here at Goddard, we always kept the appointment.
What are some of the common pitfalls you’ve seen on projects in terms of how scheduling is treated?
Well, I’ll give you an example. On one project, I went to visit my contractor, and I met with their scheduler and project manager. We went into their war room, and there were schedules all over the wall. They were wonderful, as detailed as can be, and so I had to ask: “Who developed the schedule?” The scheduler said, “I did.” And so I asked another question, “Did the people doing the work have input?” He said, “No.”
The next day I notified the contractor that I wanted the project manager and his scheduler removed from the project, and I told him to start building schedules that were representative of what work really needed to be done. As a project manager, there are certain things you can dictate: the end date, maybe certain review period dates; but in terms of what else has to be done, you’ve got to ask the people who are doing the job.
So you felt that schedules they had shown you had no basis in reality?
None. Here were these wonderful schedules, detailing every single thing you ever wanted to know about the project — and it was totally irrelevant. Now, understand, I am not against using schedulers. I have worked with several good ones. But you need to talk to the people doing the work. You need to find out what they have to do and how long it’s going to take. Even if you do it that way, your schedules can still be fallible, but at least you have something that everybody has bought into because they helped to develop it.
Were there any unique scheduling challenges you faced on ACE?
The scheduling challenge on ACE was working with twenty science institutions. It was a big team, spread out widely across the U.S. and parts of Europe. They were all experts in their own scientific and technical domains, but creating and adhering to schedules wasn’t their forte. So the real challenge was making sure all of the schedules converged on the same launch date.
In what way, for example by looking at a decision you made at some stage of the project, were you able to address that challenge?
At the start of the project, I had the choice of spreading the limited amount of money I had among all the players, or looking at and mitigating the greatest risks on the project. I responded by putting the bulk of the money into trying to identify the key risks in the development of the science instruments and mitigating these to the best extent that we could. I wanted to enter the development phase with the least amount of technical, schedule, and cost risk as possible. To do this, I had to limit spacecraft development funding at the Johns Hopkins Applied Physics Laboratory (APL).
What were the risks involved in doing this?
In holding APL back by three months, or six months, I knew I could be shooting myself in the foot if they were not able to recover. But I believed, even with a slow start, APL would be able to catch up.
Why? This was my third mission with APL, and I thought I understood the culture there. Mary Chiu, the APL Program Manger, was new to me, but I knew many of the other key people on the project. APL had built spacecraft many, many times before. My concerns about APL being able to do the job actually were quite minimal.
On the other hand, no one was certain how effectively we could mitigate the risks with those problem instruments. The greatest uncertainty on a science mission is in the development of the instruments. There were nine on ACE, five of which were new. Because I was limited as to how much money I could get in the early stages of the project, the question was: What was the best way to use it?
How did things turn out?
Once we got more funding, I told APL to start ramping up on the spacecraft development. As it turned out, they were able to catch up.
You’re never right a hundred percent of the time. Still, you have to go with your judgment. Experience counts for a lot.
At one of APPL’s Masters Forums, you told a story about how you worked with Mary Chiu to address a schedule concern you had about APL. What struck me about that was you said you learned something about people’s motivations on projects.
Yes, I remember. The story was that APL had fallen behind schedule as we were approaching our integration and test phase. We not only had to integrate the spacecraft and test it, we had the nine instruments coming in. It looked to me like there was only one of two ways to make up the difference: either put some people on double shifts, or work on the weekends. Neither was an attractive alternative, but we had a lot to do and the work had to get done.
I asked Mary to go ahead and tell her people to do one or the other. She told me that she couldn’t do that. Her people were salaried and she couldn’t direct them to put in overtime, where they wouldn’t be paid for their work. I have to admit that took me aback. For one thing, I wasn’t asking for a lot of time — perhaps seven days at most.
But I have to give Mary credit. She pointed out something that was a no-brainer, really. Technically, she couldn’t require her people to work the extra hours, but she also knew that she didn’t have to tell them to do anything. Professionals don’t have to be reminded that they have a job to do. It was so obvious that I was astonished and embarrassed that I hadn’t realized it myself.
These were people at APL that you’d worked with before?
Yes, that’s true. I knew a number of people on the APL team because I’d worked with them before, and I recognized that what she was saying was true. These people would come in and work the extra hours; they would work Saturdays, Sundays, nighttime, whatever it took to do the job. All we had to do was put it out there that we were behind schedule, and they would rise to the challenge on their own. And they did. Ultimately they recovered all of the time.
So what was the important piece of learning about people’s motivations on projects?
Well, it is much better to let people come up with a solution and implement it than for you to force it down their throats. Isn’t that preferable to mandating that they do the work? Think about it from APL’s standpoint, if they heard NASA telling them to work harder than they already were — with NASA knowing full well these people weren’t going to get paid for this — it would be like NASA was trying to get something out of them for nothing.
The mission launched, and it has been very successful in terms of the science collected. But are you satisfied in how you met the challenges you identified?
Let me put it this way, we picked a target launch date three and a half years in advance of launch, and if there had not been a launch vehicle problem on a different mission we would have launched on that day. As it was, we launched four days late.
That’s incredible when you think about how common launch slips are. Six months, or a year is hardly unprecedented. So are there any rules of thumb that you would encourage project managers to follow when building schedules?
Just this. There is this tendency to think there’s only one way to get from A to B. It turns out there are an infinite number of ways to get from point A to point B. What may work on one project may not work very well on another project for a variety of reasons. The lesson I’ve learned is that while it’s good to have a road map, you have to realize the map is good for today, but it may change tomorrow, and it may change again the next day. Use the schedule as a tool and be flexible, if you can. Cultivate a great team, take advantage of their experience, and pray for good luck.
