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). |
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?
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.
| Managing or leading
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. |
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.
| People shouldn't
be put in positions where they need to compromise on critical
components. |
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.
 |
| Technicians at the
Johnson Space Center in Houston team up to assemble a
test article to simulate the inboard leading edge of a
Space Shuttle wing as part of the Columbia Accident Investigation
Board's testing. |
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.
 |
| CAIB board members
Major General Kenneth W. Hess and Rear Admiral Turcotte
examine debris at Kennedy Space Center. |
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?
 |
| The STS-114 crewmembers
look at the reinforced carbon-carbon panels for one of
the wings of the Space Shuttle Atlantis in the Orbiter
Processing Facility at Kennedy Space Center. |
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." |