ASK Talks with Al Diaz

 

Since being tapped by NASA Administrator Sean O’Keefe to head the team analyzing the findings of the Columbia Accident Investigation Board (CAIB), your name has been associated with the agency’s efforts to make needed changes. What was the charter of the “Diaz Team” in addressing the CAIB report?

Following the release of the Columbia Accident Investigation Board (CAIB) Report, Alphonso (Al) Diaz, Goddard Center Director, was asked by NASA Administrator Sean O’Keefe to head up the agency’s response. The Diaz Team, as it came to be known, was charged with making sure the CAIB Report did not become another dusty volume on a shelf of old Agency Reviews.Al Diaz was appointed Goddard Center Director in January of 1998. Before that, he served as Goddard’s Deputy Director, beginning in 1996. Mr. Diaz began his career at NASA’s Langley Research Center in 1964, where he worked in a variety of technical management positions, principally on the Viking Program as the lead for the Gas Chromatograph Mass Spectrometer. This scientific instrument was the first to analyze the surface material on Mars in 1976.In 1979, Mr. Diaz began his work at NASA Headquarters, where he served in a variety of leadership positions, including program manager on the International Solar-Polar Mission (now known as the Ulysses Mission) and Galileo. Mr. Diaz has been awarded three Presidential rank awards, two as Meritorious Executive and one for Distinguished Service. He was also awarded a NASA Outstanding Leadership Medal in 1994 for his work on the Hubble Space Telescope First Servicing Mission and an Exceptional Scientific Achievement Medal for his work on Viking. Mr. Diaz has a Master of Science in management from the Massachusetts Institute of Technology (MIT).

In looking at the Columbia accident, the CAIB report focused on two different sets of causes: the physical cause of the accident as well as the organizational causes. Physical causes tend, by nature, to be local to a particular project or program. But the assertion by the CAIB was that organizational flaws had as much to do with the accident as did any of the physical causes.

The agency wanted to know if behaviors like the ones cited in the CAIB report existed on a broader scale than simply the Space Flight Program.

How did you go about collecting information?
The team recognized that we needed input from other people, in terms of what they thought about the CAIB report and what they extracted from it. We engaged Headquarters. We engaged field center directors and their staffs. We talked with individual managers. Then we held a Safety and Mission Success Week, which got everyone at NASA focused on safety and mission success, at the same time it provided us with an opportunity to hear their thoughts about the relevance of the CAIB report.

I think we’ve got to be clear about what the team was asked to do: Find out what, if any, of the CAIB recommendations had broader applicability. Then, to the extent they did, what should we do about it as an agency?

Our charter ends with the identification of a set of recommendations we extracted from the CAIB report that could be applied agency-wide. Subsequent implementation planning will have to determine how best to execute those recommendations. It is my expectation that there will be differences in the way things are applied, but that there will be some standards set across the agency.

So then, a five-person project shouldn’t necessarily expect to be addressing the same concerns as say a 500-person program?
There is always this concern that we’re going to come out with an overly constraining set of recommendations that will squeeze out all of the creativity and flexibility on a project. We have no intention of doing that.

Did identifying those “widely applicable” CAIB recommendations come down to a judgment call based on the collective experience of your team?
It’s safe to say that we had a good deal of directly applicable experience among us. The example I like to use for that is the RCC [reinforced carbon carbon] panels. As one of the recommendations to address the physical cause of the accident, the CAIB report suggested that the Shuttle program make certain in the future that there are sufficient RCC panels available that meet all of the specifications, so that program people don’t have to make decisions about using hardware that has lower integrity than required.

Well, we don’t have RCC panels any place other than the Space Shuttle Program, but we do run into situations where the perception that a program is resource constrained influences us to put ourselves in the position where we have less hardware than we ought to have when making decisions about selecting detectors or other flight parts.

I don’t know how many times we’ve been through this process of asking, “Well, can we use a non-flight part in this application because it would take 26 months to order a new part?” You put yourself in a position where you have to make those compromises sometimes.

So, we observed that the recommendation has broader applicability than the Human Space Flight Program — not because the RCC panels are used everywhere, but because of the implications: People shouldn’t be put in positions where they need to compromise on critical components. We relied on our own experiences to reach this conclusion.

Have your findings made you look at your own center, Goddard, in a new light?
I have seen things at Goddard that I think bear some consideration. The CAIB observed that in the case of Human Space Flight, there was not enough independent technical input. That somehow the relationship between the engineers and the programs colored the input that engineering was making to the programs. I worry about that here at Goddard, and we’ve tried to structure our relationships so that engineering retains an independent voice.

How are you attempting to address that issue?
We went through a major reorganization five years ago. It was one of the first things I did here as the center director. We established a central engineering organization so that we could matrix our engineering, in order to establish quality control over the work that is provided to the projects. We went through the pain of pulling all of engineering out of other organizations and bringing it to that organization. But a few of our larger projects — Hubble, GOES [Geostationary Operational Environmental Satellite], POES [Polar Orbiting Environmental Satellite] — haven’t been pulled into this setup yet. I think it’s time to revisit that decision now.

You know, change has its risks — but not changing has risks, too. We made the determination five years ago that we were better served not to make the change on these projects to the new model. But, as I said, it’s time to take another look at this.

When engineering operates as an independent organization, do you worry that project managers could feel as though they’re being second-guessed?
I don’t think the good managers feel that way. I think the good ones see our engineering organization as an important element of getting the resources that they need to get the job done successfully. It isn’t usually a question of the project wanting to spend less on engineering, and engineering wanting more and more work performed. Our experience hasn’t been that at all. Our experience has been just the opposite in that the project manager wants more engineering support than he or she might actually need.

What happens in this scenario when they don’t agree? Does the project manager still get to say, “Look I respect that you’ve said this, but my decision is that we go the other way”?
Then the engineering organization can elect to take it to the Program Management Council and say, “We’ve got a problem. We think we’ve got to change something on that project because we are worried that we’ve got the wrong mix of people.” Or, “We’ve got too few engineers there.” Or, “Our engineers have concerns that aren’t being addressed.”

Aren’t there times when the project manager has to make a judgment call? Should project managers be concerned that it is now going to be more difficult to make decisions?
If it appears more difficult, then it is probably because we haven’t been doing it right in the first place. I think this whole idea that somehow it is going to be more difficult because people have a legitimate right to question leadership is really part of a dysfunctional mindset.

Leaders need to be accountable. If, as a leader, I can’t tell people why I decided what I’m doing — with the expectation that they will support my decision, given the kind of record that I have — then I have a problem and I’ve got to deal with that problem.

Managing to me is not simply making decisions and moving on. Managing or leading, I do think, entails the responsibility to have a justification for what you’re doing and to be able to articulate that justification in a way that nine times out of ten is not going to be second-guessed. If engineering decides that they are not satisfied with something and they want to bring it to their management, I don’t see that as second-guessing. I think that’s just part of a healthy process.

What are the challenges that you see project managers facing at NASA today?
Project managers work in the margins all the time. They are always working on budgeting what is left. They have a plan. The plan has reserves. The conduct of the project is, in essence, the management of the depletion of those reserves, so that every available resource is used to the maximum extent possible.

The real challenge is how do you know when you have enough? Everybody can’t have as much as they could possibly imagine. So, how do you know when you’ve got enough? Our tools are limited in terms of what we have available to determine what the right cost is.

How can you tell when a project is being managed well?
I think it starts at the top, in terms of the competency and character of the leader. It has a lot to do with whether or not the resources that are being made available are adequate to do the job.

How about communications and teaming?
I think that’s equally important. A team needs to act like a team. I think there needs to be an environment for communication that’s conducive to getting the job done.

That was another observation in the CAIB report. In these complex projects we need to maintain an environment where everyone feels invited to participate, and where what are typically called “minority opinions” are viewed as part of the diversity in the project that we welcome, as opposed to people cringing when somebody has a different idea. I really think the communications piece of a project is critical.

While you were talking with people throughout the agency, interviewing them about the CAIB report, did anything you heard surprise you?
One thing for certain: We can learn a lot more by talking to other people than we sometimes believe. When we went through Safety and Mission Success Week, for instance, many of the issues that people raised were predictable. We could anticipate the categories of things that people would bring up. Where we did our learning was in the feedback process, when we listened to people address those issues.

Here at Goddard, I went to each of our major organizations at the end of the week. I asked a cross section of the population in each organization, “What did you learn this week?” In the case of communications, one of the issues we discussed was the way we wanted to deal with minority opinions. I got an input from a young guy in Human Resources, who said, “You know, even the term ‘minority opinion’ is pejorative. As a consequence you’re not really encouraging people to come up with alternative viewpoints, which would really benefit you.”

And so I got to thinking about that — and I saw that he is absolutely right. What we need to be doing is not only saying that we are open to minority opinions; we ought to be saying that we encourage the development of alternative opinions so that we can test the prevailing opinion the same way that we do in the scientific method.

Not only that, but we need to be prepared to apply resources to that, not force the people that have these different opinions to provide the resources themselves. If we’re prepared to apply resources to develop those alternative opinions, only then should we feel comfortable that the prevailing opinion is in fact correct.

Is there something that can be done at the centers to make resources available for that? For example, what will you do to change things at Goddard?
I think that part of the independent technical authority ought to be an allocation of resources to engineering that is non-specific to the task they’ve been asked to do, but is available on an unsolicited proposal basis for people to develop alternative options for projects.

Now, it may come out of the same pool that we use for reviews or what have you, but we have to set aside some resources for general engineering review functions, development, and things like that. Typically, it’s not dollars. It’s workforce time. So, we’re trying to think about how we would go about doing that as part of the establishment of what we will call our independent technical authority here.

Let’s say you have five engineers working on a project, and each one of them has a slightly different idea about the best way to do something. Can you run down every idea?
No, you can’t run down every idea, but our engineering people do their own peer reviews. They bring people in and test the prevailing opinion. I think there needs to be a constant testing of the design and the development of the design. If we ever get to the point where everybody has a different idea, then we have a different problem.

The challenge now is to recognize that the prevailing opinion may not always be correct. Why is it that we feel so comfortable when there are no minority opinions, as opposed to feeling good about being in a position where there has been a different opinion voiced?

Why do you think that is?
Perhaps it’s human nature. It’s just more comfortable to feel that way. But in complex environments like ours, we shouldn’t feel that comfortable.

Here’s an example: On the first Hubble Servicing Mission, we all thought we were ready. We all thought that everything was perfect. Then Joe Rothenberg, the project manager, said, “I would feel more comfortable if I could test this plan.” So, we brought in a group of people from Lincoln Labs. We put together a team of around twenty people and said, “We want you to sit down and go through the reviews with the Hubble guys. If you see anything that you think warrants further penetration, we want you to develop that idea and we’re going to give you the resources to support a team to do that.”

And you know what? They did find something that they were worried about and they pursued it. In the end, they concluded that they were wrong and the Hubble guys were right. But it wasn’t a waste of time; we had tested our prevailing opinion.

With the Hubble, there was a mandate that “we have to fix this thing.” Some projects don’t have the kind of resources to create those kinds of checks and balances.
Well, some of them don’t have to do that. For instance, we have experts in a lot of very esoteric kinds of designs and elements of design. I’m thinking about a guy in our engineering organization who knows a certain kind of device better than most people in the world, probably as well as virtually anyone in the world.

In the past, he might have gotten the impression that people cringed when he showed up at reviews because he was always so penetrating and precise about the use of this particular kind of device. But now we make certain to let him know that we feel a lot more comfortable when he walks away from a review than if he hasn’t been at it.

In fact, we try very hard to make sure that if there is a survey done of the use of this kind of device on any particular project, we ask him to take a look at it. I mean it doesn’t have to be a team of people that board a project. It can be just one expert.

Are you worried that the CAIB report paints too broad a picture of the problems in the agency?
Actually, I am less worried about what the CAIB Report says than I am with what some might think it says. I do worry about that. I was pleased to see that Admiral Gehman has said that if he had been asked to do an overall evaluation of NASA and the Human Space Flight Program, there would be a lot more good that he would have to say than there would be bad. The fact of the matter is: That isn’t what he was asked to do. What he was asked to do was focus on our problems.

We’re not talking about abandoning something because it’s beyond hope. That isn’t the case. We’re talking about improving something that’s worth improving. The margins are too slim and the consequences are too great for us to recognize that we can do better and not do it. We need to improve. That’s what we need to be doing all the time.

What would you like to see as the legacy of your work on the “Diaz Report,” let’s say five to ten years from now? What would you like to be able to point to and say, “This is what came out of it”?
I don’t have any specific driving issue that I hope that this report will help fix. On the other hand, I would be satisfied five to ten years from now if I could look at what is going on and say, “We made a difference.”