Instructions

Analyze the case and submit a written brief summarizing the results of your analysis. Your brief should be two to four pages in length and cover the following four areas:

1. Problem
2. Solution
3. Actions
4. Evaluation

As technical manager of NASAs Odyssey Spec Analyzer project, Joe Irons has battled schedule slippage, cost overruns, and low quality all attributable to the work of the network of contractors charged with completing the Odyssey project. Although Irons has succeeded in getting Odyssey built and onto the launch pad, NASA must learn from the Odyssey project in order to avoid similar problems in the future. Very early in the game we realized that building a system was the most important thing, and we had Epsilon incentivized to get their subcontractors to deliver hardware so they could put a system together at the earliest possible time, recognizing that the performance of that system was going to be less than perfect. What we were determined to get away from was the endless engineering approach that had characterized the program previouslyoptimizing every component until it was exactly what they wanted it to be before they tried tying that component to another one. As it turned out, the first system that was put together was totally inadequate; it just didnt work. But the objective was reached, which was to put one together as soon as possible and find out what the deficiencies were. We were able to get our arms around every deficiency that system had. You can spend months and months in engineering, while one test will tell you the answer. Organizational Changes Organizational changes of two kinds occurred after April 2004. One was a change in the organization structure for the program at Epsilon. The second was a more gradual, but significant change in the roles played by certain key individuals who worked for both the government and Epsilon. The organizational change at Epsilon removed the Spec Analyzer from under the control of the line engineering organization. A project office was created for the instrument under the direction of Epsilons program vide-president. Members of the NASA Spec Analyzer team felt this change helped increase Epsilons responsiveness to the needs of the project. According to Al Diamond, "When they went from the line to the matrix, it made all the difference in the world. We now had many more of the resources we needed without the constraints." An important feature of the Epsilon project office was that its organizational structure closely paralleled that of the governments team. This made for clearly visible channels of communication between counterpart individuals in the two organizations. According to Diamond, the most important feature of Epsilons project organization was that it included the sun-contracts management function within then project office: We insisted that sub-contracts be shown in the project organization as a staff function to the program manager. We wanted the freedom for the project manager to direct activities without having to go up through their contracts office and then back down again. We wanted them to be doing business the same way we did at NASA, and it worked out well.

In Irons view, the more important organizational changes were ones that occurred more gradually, involving increasing visibility and influence of certain key individuals. One such individual was Doug Usher, an independent consulting engineer who had worked on the instrument during its development period and was on retainer at Epsilon in April 2004. Iron described Ushers role and how it evolved in the following terms: I found in Usher the key guy who was going to get this instrument built, who knew all the problems and had enough of a background in organic chemistry to relate to the science team. My goal was to get this guy involved in the project in a more active way. He was just working a few days at a time on a daily rate of pay whenever they called him in on a problem. I thought our problem was sustained and continuous and I insisted that he become a full member of the team. Through Al Diamond, I tried to give him status as our eyes and ears by building his image up; letting him be the spokesman for us; giving out action items that said, I want Doug Usher to represent us on this. I was trying to get this guy out of a role where everyone saw him as someone who should only respond when they asked him a question, to become almost an overview role. We did that. The first time I went out to Epsilon, I said, "Why isnt Usher here at this meeting; the meeting is suspended until you go and get him." It was a matter of putting him in the right position, and not letting things like< "But he doesn't work for us, or "Hes got a funny kind of contract get in the way. Iron explained that he employed a similar type of strategy with two other individuals, one being the system engineer, Al Diamond, and another being Charlie Wingfield, the sub-contracts manager at Epsilon: It was similar with Al Diamond. I couldnt promote him; the civil service structure didnt allow it; but he got more status and power under me than his grade or salary indicated. I let Al chair the Change Board. I said, "Here, you make the decisions. Youve got full responsibility; dont make any mistakes. People a grade higher up had to sit with him in the Change Board meetings, and Al was the one asking the questions. The same with Design Reviews; I had to chair them but I became a member and made Al the chairman. I allowed him to participate very strongly in the award fee meetings. So he took on an image of more power, more clout. There was another guy and Epsilon who was an obscure dynamo, Charlie Wingfield. Hes not a technical giant, but man, he knows how to get things done. He was a sub-contract manager at Epsilon and his job was to get Beta and Pi-Gamma to perform. I gave him the same treatment that I gave Usher and Diamond, forcing him to sit on the Change Board and so forth, to the point where

eventually he became the project manager. I never told Epsilon to change the chief engineer or to change the project manager, it just became the obvious thing to do. The influence I had was in calling meetings and inviting Charlie Wingfield; telling the project manager that I want Charlie to do something, and pretty soon his status and power in the program started to grow. I guess in a sense I don't believe in organization. I believe that if you are careful to classify all parts of an organization you can die of hardening of the categories. I look at my job as being to break down the boxes and get people to do things. The Technical Manager's Interface with Higher Management Immediately prior to his assignment as technical manager for Spec Analyzer, Iron had been a senior member of the immediate staff of the Odyssey project manager. It was widely acknowledged by Odyssey Project personnel that the assignment of the project manager's right-hand man as technical manager gave Spec Analyzer an important increase in priority in the eyes of all concerned, and enabled actions to be taken that otherwise would have been difficult or impossible. As Iron put it, People knew that when I said something I spoke for the project manager. He dug into his own organization and pulled a guy out whom the rest of the project recognized as his alter ego. The reason I got away with what I did in such a short period of time was because of my relationship with the Odyssey project manager. Also, it demonstrated how seriously he took the Spec Analyzer problem in that he went into his own hide. By doing this, he was clearly saying, This is the most important thing on the project; I want this thing solved, and to get it solved I am giving up a resource I have been counting upon to do a number of other things. I took advantage of that clout. Al Diamond, when asked if he made use of Iron's seniority and influence to get things done, replied, You bet. He went on to describe action that was taken to solve a serious technical problem involving corona arching in the high voltage circuitry required for the instrument. It was a problem that I personally didn't feel the Spec Analyzer program had the capacity to cope with. We were very far along, in fact well into the prototype when we discovered the problem. It was only because Joe Iron was able to go to the project manager and say, We've got to solve this now, that we were able to hold off the Odyssey Prima Contractor and tell them that they weren't going to get a

prototype delivered to them until we fixed this problem. Then he turned the money spigot on and tapped every available resource. We tapped resources that I didnt think were available to us. We got Boeing under contract directly to NASA as consultants. We got Rockwell to do all out high voltage potting. What Iron did was just to tell the whole free world that we had a problem, and soon we had everybody trying to fix our problem. Rockwell tried it and ultimately solved it. Boeing tried it and ultimately redesigned the whole electronic packaging designreally detailed stuff. We couldnt have solved that problem otherwise. I think if you ask people in this program what Iron did for Spec Analyzer, most would relate it to technical problems. I wouldnt, personally, because it was really the resources that he was able to bring to bear on problems that really solved it for us. Iron saw another aspect of his approach to working with his superiors as being an effort to get them to devote less energy to investigating past problems and give more attention to immediate and future action. He felt this effort resulted in more effective performance by his subordinates and freed the flow of needed information between bosses and subordinates on the program. He felt an important key to this process had to do with the way in which higher management responded to bad news: I had to get management to stop slaying the messenger. I told them that at times when I have to stand up and say, I had a bad week at the sub-contractors plant last week; were short fifty parts, that I didnt want to hear a speech about how I shouldnt let that happen. If it happened, it happened. Now the thing to do was to address the decision of what to do to fix it. When people started finding out that when they brought bad news they didnt get fired or demoted, the information started to come out. I did more cage rattling at the top than at the bottom. Key members of the Spec Analyzer team felt that one of the favorable aspects of the program was the absence of heavy-handed constraint from above. Diamond attributed this partly to the fact that the instrument was built as the government furnished equipment rather than as a sub-contract to the prime contract for the Odyssey Spacecraft. In his opinion, the right discipline and uniformity of specification imposed by the Odyssey prime contractor on other components of the spacecraft was not experienced on the Spec Analyzer. He felt this was appropriate, since the higher degrees of state-of-the-art advancement and risk involved in the instrument did not lend themselves to the same style of management as was employed on the other components of the spacecraft. Diamond further expressed the view that the Spec Analyzer

required an intensity of day-to-day decision making involving the Government and Epsilon that could have been extremely difficult to accomplish if it had to be done "second hand through another prime contractor. As Diamond put it, "We had the freedom to take the shortcuts we had to take to make the necessary decisions on a day-to-day basis. Doug Usher, the outside consultant who served as the science team's representative at Epsilon, described his own work style in a way which implied freedom from the usual documentation and approval processes required in government work. He felt that NASAs usual practice was to work out on paper solutions to any technical problems before applying them to the hardware, while his own approach on the Spec Analyzer was to fix the hardware itself and let the paperwork catch up later. He noted that by the time the program reached its later stages, the personnel at Epsilon knew the instrument so well that they could simply go in and physically fix any problem that needed fixing through an iterative process of working the hardware repeatedly until it was right.