Aaron Cohen served as NASA Acting Deputy Administrator from February 19, 1992 to November 1, 1992. Mr. Cohen started at NASA's Johnson Space Center in 1962 working on the Apollo program. After Apollo he served as Manager of the Space Shuttle orbiter, directing the development and testing of the orbiter. In 1986 he assumed the position of Johnson Space Center Director. Photo Credit: NASA
July 20, 2011 Vol. 4, Issue 5
A pioneer of human spaceflight projects offered five rules for avoiding project management pitfalls.
[Editor’s note: As the space shuttle moves from the launch pad into the history books, it seems appropriate to revisit the wisdom of Aaron Cohen about successful project management. Cohen joined NASA in 1962 and served in key leadership roles critical to the success of the flights and lunar landings of the Apollo Program. From 1969 to 1972, Cohen was the manager for the Apollo Command and Service Modules. He oversaw the design, development, production, and test flights of the space shuttles as manager of NASA’s Space Shuttle Orbiter Project Office from 1972 to 1982. After serving as Director of Engineering at Johnson for several years, he was named director of the center in 1986, serving in that post until 1993.The text below is an excerpt from “Project Management: JSC’s Heritage and Challenge,” which was originally published in 1988 in the anthology “Issues in NASA Program and Project Management” (NASA SP-6101).]
Whatever priorities are dictated by the environment, a project manager can never equally satisfy all elements of project management. There is no exact project management formula or equation for making performance-cost-schedule trades. But the lessons I have learned from people like Robert Gilruth, Max Faget, Chris Kraft and George Low—and from my own experience—tell me that there are several important principles in maximizing the probability of success. Those factors sometimes contradict one another and they must be applied on a case-by-case basis, but they are nonetheless valuable.
First, you must fearlessly base your decisions on the best information available. As a project manager you will have many different considerations with regard to each programmatic issue. Simply by making a decision, you ensure that you probably will be right more than half the time.
Aaron Cohen served as NASA Acting Deputy Administrator from February 19, 1992 to November 1, 1992. Mr. Cohen started at NASA’s Johnson Space Center in 1962 working on the Apollo program. After Apollo he served as Manager of the Space Shuttle orbiter, directing the development and testing of the orbiter. In 1986 he assumed the position of Johnson Space Center Director.
Photo Credit: NASAMany times during the life of a project, a project manager will be faced with decisions that need to be made in a timely fashion, and either all the data is not available or it will not become available in time. In other words, the time and effort spent in trying to obtain additional information may not be worthwhile. A specific example of this occurred during the early design phase of the Orbiter. The avionics system was being formulated and a microwave scanning beam landing system (MSBLS) was being considered as a navigation aid. At the time, the MSBLS was pushing the state-of-the-art. The question before me: Should I use current, proven technology or should I try to push the state of the art and wait for such an advancement in the technology? I based my decision to push for the new technology on the data I had and the desire of my team to use the system. We made a decision, and it proved to be correct.
Second, you must make decisions in a timely manner. If you are decisive early and are wrong, you can still correct your error. During the Orbiter design, development, test and evaluation phase, I was forced to make many trades in terms of performance, cost and schedule. On one particular occasion, I was reviewing thermal system structural test requirements that contained a number of articles such as parts of wings, parts of the mid and forward fuselage and their thermal protection systems. The technical team needed to test all of the articles, but they were too large to test all at once, and I had a limited budget. After spending a full Saturday in review of all the test articles, I eliminated several despite the extreme concern of several of the technical experts I had supporting me. Weeks later they came back and argued their point of concern again. This time, their point struck home and I reversed myself and put the test articles back into the program. By making a timely decision, I had given myself a chance to correct a potential error.
Third, if you can fix a problem by making a decision, do it. During the checkout of Apollo 11, the Inertial Measurement Unit (IMU) of the lunar module was slightly out of specifications in gyro drift. The analysis showed that you could accept a little more degradation and still perform the mission. The questions before management: Do we understand the reason for the gyro drift, and could this lead to a greater degradation and threaten the success of the mission? Changing an IMU out of the lunar module on the pad was not an easy task, and we would be risking major damage to the fragile structure of the lunar module if one of the heavy instruments were dropped during a pad change-out. A group of us discussed this problem with George Low, then Apollo program manager. We strongly recommended to him that we should not change out the IMU. His comment was: “If you can fix a problem by making a timely decision, do it.” We replaced the IMU.
Fourth, always remember that better is the enemy of the good. You can never solve all of the problems. If you have obtained an acceptable level of system performance, any “improvements” run the risk of becoming detriments. Right now, we are struggling with this very situation [in the Shuttle program] as we try to improve the design of the solid rocket motors and add emergency egress systems to the Orbiter. Each improvement brings with it a price in terms of weight. Each additional pound reduces the margin we have in the amount of thrust available to reach orbit. We have had to ask ourselves, “At what point do these new safety features become liabilities?”
Fifth, don’t forget how important good business and contract management are to the successful operation of a contract. Project managers must realize that when they manage a contract they should do their best to be fair to both the government and the contractor. In order to do this, they need strong project controls on budget, schedule and configuration. The project manager must be sure the changes that are made are negotiated promptly and equitably for the government and contractor. Fairness in dealing with the contractor is the most productive way to do business. You want to penalize when appropriate, but you also want to reward when appropriate. To establish what is appropriate, you must set the ground rules early. The first signs of project management failure are budget overruns and schedule slips. This can be understood and potentially avoided or minimized by good project control and contract management.
Major General J.A. Abrahamson, right, talks to JSC Director Christopher C. Kraft, Jr., (seated left) and Space Shuttle Program Manager Glynn S. Lunney on the back row of consoles in the mission operations control room (MOCR) in the Johnson Space Center mission control center. Abrahamson, second right, talks to JSC’s Aaron Cohen, right, as Kraft (seated left) and Lunney listen in mission control.
Photo Credit: NASALast, and most important, you must be people-oriented. It is through people that projects get done. Dealing with people is extremely difficult for many project managers who have an engineering background and more comfortable working with an algorithm than explaining how to use one. Good project managers surround themselves with talented people who will speak up when they believe they are right. They make themselves available to their bosses and to the people who support them. They listen when people express their concerns, and make people want to express their concerns by explaining decisions that contradict the advice given. They accept criticism without being defensive and are able to reverse their decisions when they are wrong.
One of the most vivid and memorable experiences I’ve had in this regard happened during the preparation for Apollo 8 in early December 1968. The preparations had been going very smoothly without any big issues needing to be worked for several weeks. Then it happened. About two weeks before the flight I was told by the contractor, North American Aviation, and JSC propulsion subsystem managers that we had a potentially serious problem with the service propulsion system (SPS). We had just finished some tests in the configuration that we were going to use for lunar orbit insertion.
Apollo 8 was going to place the CSM on a free-return trajectory, which meant that if we did not perform an SPS burn behind the Moon the spacecraft would automatically return to Earth. The SPS fuel injector was fed by a pair of redundant systems. We wanted both of them to be active during the lunar orbit insertion burn so that if one feeder line malfunctioned, the other would get propellant to the SPS. The tests we had just finished were in this configuration, but it was the first time they had been used and both lines had been dry before the test. The tests showed that if we started the burn with both lines dry, a pressure spike occurred that could cause a catastrophic failure in the SPS. If both lines were wetted, however, the pressure spike would not occur.
I got very upset when I was told this, but the test engineers stood their ground. They told me very firmly that the problem had to be addressed, and they presented a good solution. By firing the SPS on a single system out-of-plane burn during coast—which would not disturb the translunar free-return trajectory—we would have both systems wetted by the time we needed to use them together and, hence, avert the high-pressure spike.
Now it was my job to call my boss and let him know what I knew and how to fix the problem. I had no qualms about doing this because my boss, George Low, had taught me several important things by his actions and words: get out and touch the real hardware; when things go wrong, look for innovations, the unusual solutions, or try to meet your commitments no matter what; and have great respect for your fellow human beings.
