By Marty Davis
Every project has its stories. The ones we usually want to tell are the outright success stories — but the ones we also need to hear are the “things we did wrong and should have known better.”
The Compton Gamma-Ray Observatory (CGRO) was the heaviest astrophysical payload ever flown at the time of its launch in April 1991. Working on CGRO, we accumulated our fair share of that second breed of story. I’ll share a few of them here:
The one-person syndrome
The Energetic Gamma Ray Experiment Telescope used light pipes to measure time-of-flight. These were simple pieces of plastic, bent and glued together, and this appeared to be an easy task to accomplish. The catch here is that the task appeared easy.
It was known to the engineers that only one person had been able to complete this task successfully so that the light pipes worked optimally. Unfortunately, this man was about to retire, and an attempt to procure the light pipes from another source failed. Only by appealing to the man to save the project and the Center’s reputation did he agree to hold off his retirement to finish the work and to train a replacement.
It was much the same way when it came to a contractor who made the photomultiplier tubes for the science instruments and who used only one of their assemblers to make the tubes. The specifications were quite rigid, and the one assembler who knew how to make the tubes had a success rate of just 40 percent.
CGRO needed more tubes and this one man was on vacation. The project office put pressure on the contractor to keep the production line working. The contractor reluctantly agreed.
Ten tubes were pushed through the manufacturing process and the yield was zero. What the one man did working at an identical station with identical parts is not known, but CGRO lost time and the contractor lost money. They informed us that from then on we should wait until their one man was available. We agreed.
What do these cases say to a manager? Project life is rarely as simple as it seems. Make sure you find out how difficult the work is — and if told only one person can do the job, no matter how “trivial” that work might appear to be, pay careful attention to the situation so that you know that one person will be there when you need him or her most.
One-person depth
One-person depth is not the same as “only one person can do it.” The problem here is the assignment of complex systems to only one team member — a situation often necessitated by budget constraints, but one that adds risk to a project.
For example, on CGRO the design of the digital electronics for the COMPTEL instrument was a one-person effort. The system was ahead of schedule. The prototype was finished and had undergone preliminary tests ahead of schedule. Everything sounds wonderful, right?
But then the engineer was offered a better job. He gave notice, and left the project. No one else was familiar with the system and how the changes identified from testing should be made. This led to six months of long days and weekend work for team members who had to fill in.
The mechanical design of the Energetic Gamma Ray Experiment Telescope (EGRET) was another one-person job. Sadly, the design engineer died during the build of the mechanical engineering test model. The engineer we hired to replace him had to hit the ground running; he had to finish the build, and move right on to testing.
The Energetic Gamma Ray Experiment Telescope (EGRET) captures an image of Earth’s moon.
Though the documentation was in good order, the new design engineer never got the chance to study the design in detail and get familiar with the work that had been completed by the first engineer. Tests indicated that changes had to be made. This resulted in a series of change and test, change and test. In the meantime, the replacement engineer decided to retire. The EGRET instrument was finished but there was an uncomfortable, lingering feeling that no one knew the design in depth.
One-of-a-kind solutions
What can we learn from these stories? In cases like these, a manager should estimate how many of the systems on a project are one-person affairs. He or she should then try to keep some reserve resources to cover lost personnel. A team member lost late during system development may require that two to three people come on board to pick up the work, which normally means that one of the experienced persons on the project must be one of those chosen to do part of the work. Filling one void may require shifting a lot of responsibilities.
There may be no way out of this situation since having two people from the start adds too much cost. What to do is simple, albeit no guarantee of a solution: Make certain there is adequate paperwork for someone to see what has been done, what is left to do, and how and what to do next.
Despite these problems, CGRO was graced by having a project manager who believed in the abilities of his people, who projected a “can do” attitude, and who generated enthusiasm for the project. In that sense, no effort was truly a “one-person” effort. Because we believed in what we were doing, we pitched in when the time came and, in the end, the project was generally regarded as a resounding success.
Lessons
- Project managers need to identify in advance those critical tasks for which they don’t have sufficient overlap or redundancy in their work force.
- In positions that are “one-person” jobs, the project manager copes through a combination of documenting as much as possible, providing opportunities for team members to share their knowledge, and fostering a sense of shared responsibility on the team.
Question
As a project manager how do you allow individuals the satisfaction that comes from making unique contributions to the team at the same time that you protect the team against being too dependent on any one individual?
Read more by Marty Davis:
Scheduling in the Real World
Pulling stories out of the trunk
Making the front page of The New York Times is every program’s dream, right? Except we were, oh, 300 percent over budget, and without a prayer of reaching our technical goals. Nobody was working on solutions; everybody was pointing fingers and taking cover. Into one of our meetings one morning walks a new manager on the program who says, “I just saw in the paper this morning that somebody has brought an elephant into town, and they’re offering rides.”
Everybody else looks around the room, thinking, “Well, what has this got to do with anything?” And then the manager says to the other senior managers around the table, “Okay, you, you, you, and I are going to go over there, and we’re going to ride this elephant.”
And there was great protesting. It seemed crazy. But, in the end, they went down the street a couple of blocks and rode this elephant. Believe it or not, from that point on, they started to cooperate a lot better. It’s hard to argue with somebody that you’ve just been hanging onto on the back of an elephant — especially when there are pictures.
That came straight from the playbook of none other than Mr. Marty Davis. It was brilliant. What that little story reminds me is that you’ve got to do goofy things sometimes to get people to start working together. And, as we’ve all learned, people working together is the only way to get out of a mess.
— Larry Goshorn, former Vice President of ITT Industries
About the Author
 |
Marty Davis is the program manager of the Geostationary Operational Environmental Satellite (GOES) at the NASA Goddard Space Flight Center in Greenbelt, Maryland. The recipient of many honors, he received NASA’s highest award, the Distinguished Service Medal, in 1995. He has worked at NASA since 1962. |
