NASA STS Recordation
Oral History Project
Edited Oral History Transcript
Interviewed by Jennifer Ross-Nazzal
Downey, California – 26 August 2010
Today is August 26th, 2010. This interview is being conducted with
Bill Roberts in Downey, California as part of the NASA STS Recordation
Oral History Project. The interviewer is Jennifer Ross-Nazzal, assisted
by Rebecca Wright. We are also joined by Bob [Robert] Sechrist who
is videotaping. Thanks again for taking time this morning to meet
I thought this morning we’d talk about the return to flight
certification. Would you talk to us about the state of the Shuttle
Program when you first came back in 2004 after the [Space Shuttle
Columbia] accident [STS 51-L, February 1, 2003]?
Shuttle Program was in a rebuilding state obviously. There were a
lot of emotions involved, especially since the Columbia Accident Investigation
Board was pulling a lot of emails which surfaced a lot of miscommunication
between engineering and NASA. I think there was some technical opinions
of the situation at the time of the Columbia flight that were not
passed up the chain, and it was obvious during the investigation that
they found this type of either miscommunication or lack of communication
throughout the whole workforce. One of the main things coming out
of the big investigation was to improve our communication ability
throughout the program, not just in the engineering community but
also program management and NASA program office down to the engineer’s
That was one of the things during my task as project manager in charge
of the orbiter return to flight DCR (design certification review),
to try to identify new processes. How we could have more horizontal
integration throughout the project versus just isolated pockets, relying
on point-to-point communication. I was off the program for four years
on that missile program, and when I came back I definitely noticed
that there was a new spirit in communication. When I had my initial
trips back to Houston [Texas, Johnson Space Center (JSC)] after being
off the program, I noticed that the program management down there
at NASA was really really working hard to communicate and almost befriend
the contractors, much more than before I left the program.
Was this under [N.] Wayne Hale [Jr.] at this point?
Bill [William W.] Parsons was the Space Shuttle Program Manager at
It was definitely a different environment. Everybody was working together
with this goal to get flying again. We had to recertify not just the
orbiter vehicle, but the processes around the whole Space Shuttle
Program from ground operations to orbiter turnaround processing and
also on-orbit processes and in-flight anomaly resolution processes.
When I said on-orbit processes, that’s inspection and repair
if possible processes. That was all part of the return to flight design
certification review process that I was involved with.
You mentioned more horizontal integration versus point-to-point communication.
Can you elaborate what you meant by that?
the early years when I started in the working levels of engineering,
if we found something that didn’t seem right to us, it was not
our charter to go through [for example] structural design to assembly
and integration. We had to report to our supervisor and then once
we reported to our supervisor, it was up to him to take it forward.
The way it is now, anybody in the program can bring up an issue and
call a meeting and report the problem horizontally, meaning through
design and production and project and up to program. It definitely
improved the communication capability from a program point of view.
It was a whole new way of thinking for us.
Back in the ’80s when I first started working, we were operating
the way aerospace companies operated from the ’30s, ’40s,
’50s and ’60s. It was something that worked at that time.
I think the NASA program recognized that one of the reasons why the
Columbia accident occurred was there was a lot of information down
in the lower levels in engineering that never got up to the higher
levels. They made a point that that had to change, and it did change
in response to that accident. So all our mission support and leading
up to the flights, we operate in a completely different mode compared
to 25 years ago, from a communication standpoint.
Do you think technology contributed to that with emails?
we had emails at the Columbia accident. Yes it helped, but it was
a different mindset. It is a different mindset today compared to pre-Columbia
accident. It started from the top. It started from the NASA Administrator
down that we will do business differently. We are doing business today
differently than we did ten years ago.
Who was on the design recertification team? Was it primarily [The]
Boeing [Company] folks or did it also include NASA?
were heading it and spearheading it. Like I mentioned yesterday, I
was asked to assemble a team of subsystem experts, along with flight
operations folks and USA ground ops [operations] folks. We had a variety
of areas that we had to address in direct response to the Columbia
Accident Investigation Board.
Obviously the first thing that I worked on was putting together the
subsystem list of experts, my first wave of requests going to our
Boeing subsystem managers. Then also the USA [United Space Alliance]
site area managers, (SAMs), and then the NASA subsystem engineers,
(NSEs). We worked together as a collaborative group, meaning an integrated
group. I was at the project level and I had the subsystem PRTs [problem
resolution teams] involved in addressing their specific area in response
to the accident investigation.
We had to address every point brought forward in the investigation
as part of the recertification. Obviously we brought into the recertification
process other things that they may not have thought of during the
investigation, which were improvements on inspection—in-flight
inspections and postflight inspections—and turnaround assessments.
Can you give us an overview of some of the changes that were made
to the orbiter as a result of the investigation?
primary physical changes to the orbiter in response to the investigation—we
had improved dramatically the photodocumentation in ascent, because
the Columbia accident occurred as a result of debris coming off the
external tank [ET] that impacted the wing leading edge. We all saw
that, but we saw it from afar. If you remember that video, there was
really only one good view that you could actually see the foam coming
off the ET and impacting the wing leading edge. Once we saw that,
there was no other capability to look at that area of the wing.
The investigation resulted in much more photodocumentation capability
during ascent. Not only by putting cameras on the external tank looking
at the underside of the orbiter during ascent, but also airborne aircraft
videoing the vehicle while it’s in its launch phase from many
different angles. On the launch pad we could see debris coming off
the ET [external tank] or the SRBs [solid rocket boosters]. We set
up the debris assessment team out of JSC, which was a group of NASA
engineers, Boeing engineers and some USA folks also. Set new size
criteria for debris liberation based on velocities.
If they saw something that was larger than this acceptable criteria
of debris, then it kicked in new processes on orbit for inspection.
So now when we fly, all of this video and photographic data is collected,
and the debris assessment team reviews all that launch video and looks
for certain debris liberation that does not meet their acceptable
criteria. If they find some debris during the review of that video,
then it kicks into effect some new inspection criteria on orbit before
you actually get to the [International] Space Station [ISS] dock.
We also put some instrumentation in the wing leading edge that is
sensitive to debris impacts, and they can tell by the acoustic data
that they’re getting off the wing leading edge just how big
the debris was or if it may have done some damage. That data is all
available quite soon after launch, so whatever they hear or see from
that data kicks into some more on-orbit inspection criteria.
They’ve also put the boom on the starboard sill of the payload
bay, which allows the RMS [remote manipulator system] to extend itself.
The RMS meets with the boom and allows the video inspection of the
underside of the orbiter along with some detailed look at the wing
leading edge, looking for debris impacts. That all takes place prior
to rendezvous and docking with the Station. All that video gathering
data during ascent and then the on-orbit inspections for the first
couple days prior to ISS rendezvous puts in place a whole other series
of requirements when you’re actually docked to the Station.
The return to flight DCR team monitored these new design hardware,
and folded them into our new processes. Therefore, because we had
this new hardware and we had these new processes, we had the ability
to recertify the vehicle to fly within these new hardware and processes.
That was all folded into our DCR package.
When you’re docked to the Station, depending on what the results
are of the data that you found, not only from the launch video but
also the on-orbit inspection prior to docking, that kicks in some
possible repair processes. During STS-114 return to flight, we had
a filler bar that came out from tile up very near the nose cap. One
of the crew got out there in RMS and actually pulled the filler bar,
because during reentry it would put some adverse heating on the underside
of the orbiter because of the outer mold line being not per design.
They just pulled that thing out, and everything was fine. We had documented
that into our DCR package as a new process, to go out there and pull
these liberated filler material in between tile.
There were a lot of things going on during that whole recertification
process. Like I said there were modifications done, and those modifications
were basically to enable the vehicle and the flight crew and the ground
crew down in Houston to get a better feel as to the condition of the
vehicle while it’s still flying. When all this data comes together,
we come to a point during a mission where we give a go for landing.
There is a point in time while we’re still docked to the Station
that the Space Shuttle program manager polls the community saying,
“Are you go for undocking and reentry?” Depending on what
data we found, what repairs have been done, we give a thumbs up. That
was never done pre-Columbia.
Oh, it wasn’t?
was never done. We did give a go for undocking based on the orbiter
condition, but we didn’t have the data on any kind of ascent
debris damage or underside.
Another one of the process changes was prior to docking when we rendezvous
we do the RPM [R-bar Pitch Maneuver], the revolution maneuver, and
the crew on the Station photodocument the underside. That’s
just supplemental data to our boom inspection that occurred the day
before. If they see something that we missed by the boom inspection
then that kicks off more assessment from our debris assessment team.
Before the Columbia accident we did have TPS [thermal protection system]
engineers in the MER [Mission Evaluation Room] and supporting Mission
Control [Center]. It was a handful, because it was a handful of data
that we had. Now we have a lot of data, and we send down to Houston
from both KSC [NASA Kennedy Space Center, Florida] and from Huntington
Beach [Boeing location in California] and our Boeing offices in Houston—there’s
probably well over 100 folks supporting each mission from a debris
assessment point of view, and that was never what it was pre-Columbia.
It’s definitely a different process.
That’s amazing. Was that just because everyone thought that
the system was so robust before Columbia that it had proven itself?
the issue of debris—all elements in the Space Shuttle program—the
SRB project, the orbiter project, the ET project and even the SSME
[Space Shuttle main engine] project—has an integrated spec [specification]
requirement that you are not allowed to have any ascent debris. So
all that hardware, those SRBs and the ETs, were designed and built
with the requirement that they will not liberate debris. From day
one the orbiter project had taken a lot of ET foam debris hits. Every
landing, early on when we landed out at Edwards [Air Force Base, California],
we sent a TPS inspection team out there and inspected the damage.
Yes, the ET project definitely responded, and tried to improve their
processes so that their foam would not liberate, and they have made
great improvements, but the bottom line is they never met their integrated
spec requirement over the life of the program. That’s one of
the reasons they’re shutting down the Space Shuttle Program,
because they don’t like the idea that this side-mounted manned
spaceflight vehicle continually gets hit by debris. One of the reasons
they went to the [Constellation Program] Ares [launch rocket] and
the Orion [crew vehicle] is because your return vehicle is up on top
away from any debris.
There’s a lot of different philosophies out there, a lot of
different requirements that weren’t met early on in the program.
The vehicle demonstrated robust design, meaning it demonstrated that
TPS impact was something we could live with, up until the Columbia
accident. We always did do the inspections and we did repair tile,
but it never got to the point where such a large debris impact did
the type of damage that it did on the left wing on Columbia. As a
result there were a lot of new processes put in place, and the end
of the program was set at that time too. As soon as we got through
that DCR process, I was given the task to put together a retirement
Tell me how the President’s [George W. Bush’s] Vision
for Space Exploration  impacted the recertification effort,
if at all.
don’t think it did, I really don’t think it did. We, on
this program, continued to work to fly these vehicles the way they
were designed. There were some technical experts, especially NASA
employees down at Johnson Space Center that left the program and went
to the Ares Program. But because the program was so mature, we had
a lot of experts that came up through the ranks. Even though some
of the more experienced managers went over to Ares when that project
began, we still had plenty of depth in our technical expertise.
That’s something right now we’re concerned with as we
approach the end of this program. We have two, maybe three flights
left, and there’s a lot of Boeing experts that are going off
to other programs. Our wing leading edge subsystem manager Mike [Michael
P.] Gordon was heavily involved in the recertification process. He
was the expert on RCC [reaction control system] and he was one of
a kind. He left our company and went to Piper Aircraft [Inc.] about
six months ago. He’s a young guy too, probably in his early
40s. That was a big loss for this company and also the program.
Dan [Daniel R.] Bell, who’s our TPS SSM [subsystem manager],
left the company and went to NASA down at Johnson Space Center. He’s
still a resource in the program but he’s not a Boeing employee
anymore. There’s a lot of that going on right now as this program
comes to an end. It’s something that we in the transition and
retirement team have addressed to the program office as a concern.
It’s definitely a challenge to fly out these last three flights
when you’re losing a lot of system experts. You can’t
order them to stay on the program to the end. They’ve got to
find jobs out there while they can.
Yes, absolutely. Were you working at all with the Return to Flight
Task Group as they were doing their summary for NASA?
we were. We were all working as one large team. The NASA team, that
task group you’re referring to, actually were chartered to give
us information so we could fold it into the return to flight design
certification. They were a group that was reporting up to the recertification
team. We all came together a few weeks prior to the flight readiness
review of STS-114 and presented our final package, which was a three-day
meeting down at Johnson. It wasn’t just orbiter, it was everybody.
All elements, all projects within the elements. It was quite extensive,
but we had a long time to work on it too.
It was definitely challenging to integrate all that into one presentation,
because there were so many different projects out there that were
a part of the Shuttle Program recertification. I was working specific
to the orbiter. When we had our orbiter package ready to go we delivered
that to the program office and it was all integrated at the program
office. All elements did their presentation over that three-day period,
and that task group’s material was embedded within our package.
The document just for the orbiter was 2,400 pages. It was quite a
lot. When we first started, it took us several weeks just to organize
our thoughts, how we were going to bring all this together. But once
we got it organized and built a tree, it all came together quite good.
As we came down to the last weeks prior to STS-114, there were obvious
areas where there were problems and then there were obvious areas
where it was easy to fold into the package. Those last several weeks
we definitely put our manpower towards those problem areas. Those
problem areas were associated with certain mods [modifications] that
the hardware was a little slow coming out, and you had to certify
that hardware for flight.
It all came together. It was a little bit of pressure, because we
were the first ones up to make sure we could go fly. That means we
had to present our recertification package to the program before the
program would allow a flight readiness review. That was one hurdle
that we had to be successful at before we could go refly. Everybody
was in a proactive mode. We all knew we wanted to get through this,
but we all also knew that the data had to be presented and understood
and concurred with. There were a lot of people involved, and it was
refreshing to see that everybody was thinking the same, all elements
within the program.
When you gave this presentation did you have to go over all the subsystems
in the orbiter or just the ones that were modified for the return
Certain subsystems might have taken a half a page, but other subsystems
probably took 200 pages. I presented the overview, but we had our
subsystem managers go into the details of the significant changes.
Myself and my counterpart from USA and NASA worked as a project team,
and we went through this orbiter presentation and managed it from
that way. We had picked certain areas where we would overview these
sections of the presentation and then introduce our subsystem experts
and go over the details with the program office. It was a long meeting,
it was three days. Those days weren’t eight-hour days either.
They were twelve, thirteen hours.
Were there any changes that you had to go back and make?
We had certain actions coming out of that that we had to readdress.
We readdressed them at the flight readiness review and closed those
actions, but they weren’t constraints to moving forward for
the flight readiness review.
Were you at the Cape [Canaveral, Florida] for the launch?
was there. I’ve been at probably 30 or 40 launches.
Were you on console or you were just there to witness the launch?
no, I was just there.
Did you go to the Mission Evaluation Room for the mission?
I came back since I wasn’t vehicle manager. I’ve done
my time in that MER.
You mentioned that you started working on transition and retirement.
When did transition officially begin?
officially began about six months after return to flight. I had to
close out the DCR project, meaning get the package formalized, make
sure that distributions were out. The first thing we had to do was
understand what display requirements were for space aircraft, because
you can display a B-52 [aircraft] pretty easily, but an orbiter is
a little bit different. To do that we took trips to Wright-Patterson
Air Force [Base] Museum [Ohio]. We also went down to AMARG [309th
Aerospace Maintenance and Regeneration Group, David-Monthan Air Force
Base] down in Tucson [Arizona], which is basically a boneyard for
We had many plans to go to Smithsonian [Institution National Air and
Space Museum, Washington, DC], but some of the KSC folks in the project
went. They wanted to talk to them mainly from a handling point of
view, because they do have Enterprise [OV-101] there. They didn’t
really have the package that we’re putting together with these
vehicles. The way they safed that vehicle—because it did have
an APU [auxiliary power unit] system in it, which has hydrazine fuel,
and other hazardous commodities—minimal compared to a flight
orbiter that we plan to safe now.
Dr. Valerie Neal is the curator for the space division there at Smithsonian.
I’ve spoken to her many times about the documentation that came
with Enterprise when she received it back in 1985—she doesn’t
have any documentation. Basically they handed over that vehicle in
’85, and it was left outside for many years. They didn’t
have a facility to park it. It got snowed on, rained on. They cleaned
it up and brought it inside to the new facility there at [Washington]
Dulles [International] Airport.
It looks good from the outside, but over the last four, five months
we’ve sent teams down to inspect Enterprise, and they found
some significant corrosion in the lower forward fuselage. The reason
we’re inspecting it is that there may be a potential to ferry
Enterprise away from Smithsonian if and when Smithsonian gets [Space
Shuttle] Discovery. There’s a lot of politics though in that
Will you have to reprocess Enterprise as well?
we will have to conduct a ferry flight readiness review. We had a
team there three weeks ago and did their second set of inspections
on that lower forward and body flap areas where we noted some corrosion
and some landing gear area. The forward attach had some corrosion,
but the significant area that we’re really focusing on is the
lower forward fuselage. The orbiter is not a watertight vehicle. When
it gets rained on, water goes inside that vehicle, and it collects
in certain structural cavities. It did on OV-101 Enterprise, and sat
there for years and years and years, and there was significant corrosion
in that lower area.
The problem that we’re having right now is we don’t have
loads analysis specific to
OV-101 and ferrying. When we were asked to do in the late ’70s
the ALT [Approach and Landing Test] flights that Enterprise participated
in off the SCA [Shuttle carrier aircraft], we obviously had to come
forward that this vehicle is safe to do these ALTs. The analysis that
we used was actually our ascent loads analysis, so if our ascent loads
and descent loads enveloped those ferry flight loads, we were covered.
The problem with this 101 analysis is that it is specific to a ferry
flight, and there is specific corrosion in the load path of that forward
fuselage. Our folks down at Huntington Beach are actively looking
into that to see what if any repairs can be done to bring back the
loads capability of that forward fuselage so that it can be enveloped
in our ascent and descent loads that we previously [used] for the
last 30 years.
In fact when I was driving over here I was on a conference call with
those guys on that very subject, estimating how many hours they’re
going to need to conduct this. It’s probably going to be a lot
of hours to do this analysis. We’re coming to the end of the
fiscal year, so we need to understand just how many hours so that
if they don’t do it at the end of this fiscal year, which ends
in a month, we’ll bring new budget into fiscal year 2011.
We talked yesterday, and you said that the extra flight is looking
like it’s going to be a go. So [Space Shuttle] Atlantis [OV-104]
right now is in the OPF [Orbiter Processing Facility] being readied
for that final flight?
There are no T&R [transition and retirement] activities being
conducted on any of the vehicles. [OV-]103 [Discovery STS-133] is
getting ready to fly in November, so it’s scheduled to roll
out I believe the 8th of September. [OV-]105 [Endeavour STS-134] is
in February . Then the [OV-]104 [Atlantis] flight, STS-135,
would be in June. That’s going to be the first flight vehicle
that won’t have an LON [launch on need] vehicle backing it up
since the Columbia accident.
There was another return to flight process team—we had to have
the LON vehicle ready to fly no more than 30 days after the launch,
which fits nicely when you’re flying regularly. You can label
the next flight vehicle an LON up until a certain point, and once
that vehicle that’s on orbit gets the go to undock and land,
then that vehicle loses the label as an LON and becomes the next STS
vehicle. With 104 launching in June, meaning the absolute last Space
Shuttle launch, those other two vehicles, Endeavour and Discovery,
won’t be labeled as LON vehicles. We don’t know when we’re
going to be given the go-ahead to implement the safing requirements.
That’s all yet to be decided.
We’re probably going to have the end state requirements review
[ESRR]. Yesterday I was talking about how we were involved in the
launch site requirements review [LSRR]. The ESRR is equivalent to
the LSRR, but instead of turnaround requirements, it’s basically
safing requirements. Those requirements get briefed and approved by
the program to get implemented at the end state requirements review,
which is coming up in September for [OV-]103. At that meeting the
program will tell the elements, ground ops and all of us involved
when the date will be to start implementing. Like I mentioned yesterday,
implementation of end state requirements is actually cutting metal
from the vehicle, which there’s no turning around from that.
That’ll be a sad day I’m sure for everyone. Tell me about
working with the JSC and KSC orbiter offices on this effort. What
does that entail?
work as a team, just like we did when I was in vehicle management.
We discuss the requirements, we agree on the requirements, and we
document the requirements. That’s what we’ve been doing
over the last three, four years. The requirements are driven by criteria,
and criteria is defined in that fleet safing document.
My Boeing team we were working with—we brought together ex-subsystem-managers
that still work here at Huntington Beach, and we call them TTMs, transition
technical managers. They were the guys that I was working with in
defining the safing criteria and then later writing the safing requirements
in the ESSRD. They were ex-subsystem-managers because all the subsystem
managers were in Houston. We were asked at the beginning of this project
to start working on the safing criteria and requirements but do it
in such a way that you don’t interfere with flight operations,
meaning don’t call the current subsystem managers while they’re
working turnaround and flight operations.
It actually worked real well. We got to the point where both documents,
the fleet safing document and the ESSRD, became very very mature.
It was November of 2008 when we actually distributed the two documents
to all subsystem PRTs. We asked them to review our documentation and
come back with either concurrence or suggestions or nonconcurrence,
and they did that over a period of about 90 days—more like 45
days because of the holidays.
We got good feedback. We incorporated certain recommendations and
changes to our documentation, and we continued on. Last June is when
we had our formal approval from the Orbiter Project Office [OPO].
After we had our formal approval with the OPO we went to the program
in July and presented the two documents and got them approved as NSTS
[National Space Transportation System] documents; they’re NASA
Once that happened, KSC ground ops were authorized to start writing
their work authorization documents [WADs] for implementation of these
requirements. That has been happening over the last month. As all
the WADs come through from USA ground ops, they get passed on to our
Boeing engineers that were part of writing the requirements, and they
either agree with the WADs or recommend changes.
We have to have all of our WAD documentation for safing implementation
approved and canned and ready to go by the end of this fiscal year.
That’s the way it was planned at the beginning of this fiscal
year, but because of the continuation of the flights we’re pushing
that into next fiscal year. The safing requirement document WADs are
about 50 percent through right now. They haven’t even started
on the ferry flight requirements yet, which is okay because the ferry
flights after implementation are down the road.
Even if the program says you can go ahead and start implementation
on [OV-] 103—if 103 flies in November and it’s a two-and-a-half-week
mission, it comes down just prior to Thanksgiving. KSC still does
their postlanding 30-day OMRSD work, so that means that at the earliest
you’re going to have an opportunity to get into end state implementation
would be right around Christmas. They’re not going to do that,
so the reality is the earliest you’re going to actually get
into safing work is probably January of next year. And that’s
if the program agrees with that schedule, meaning trying to get it
started as soon as possible. They may choose to just pause until all
three vehicles have flown out.
We don’t know when the implementation is going to start, but
once it does start, each vehicle—for safing and getting it ready
for ferry—is about an eight-to-nine-month process. Then who
knows what they’re going to do with those vehicles when they
ferry it from KSC to whatever display location it is. They might parade
it around the country, we just don’t know.
Do you know where the vehicles are going to stay till they’re
ferried to their final location? Will they just stay at KSC at the
that’s where all the safing operations are going to occur. We’re
going to be doing business as usual, meaning once we get to the point
that vehicle is safed and all the requirements have been bought off,
then we get into the ferry flight readiness review mode. Once we get
past that then we roll up the SCA and get it ready and go to wherever
it’s been destined to go.
Then when it arrives at those sites, I think I mentioned yesterday
it’s going to require crane ops. That’s going to be significant.
The cranes required for those demate operations are not all over the
country. They’re going to have to be transported to these locations.
I believe that’s coming out of the display site bill; they’re
going to have to pay for those operations. I think that’s one
of the reasons why NASA put a price tag of about $40 million on each
Well, I think those were all the questions that I had this morning,
unless there’s anything you can think of that we hadn’t
talked about transition and retirement.
I said, this T&R project is pretty mature. The documentation is
ready to go, the WADs are coming out.
How do you come up with [potential contingency plans for T&R]?
you have many people in these meetings, there’s many thoughts
that come out. We’ve all been in the program long enough that
there are certain things that probably will happen. Especially in
this T&R project, we also recognize that when we get to implementation
that workforce that’s at KSC and at JSC and here, which is say
10,000 people—the workforce that’s going to be around
during T&R or fleet end state implementation is probably going
to be at the most 500 people.
You’re not going to have this pool of smart people to pool on,
so while we still have them—that was part of our charter during
this last three years. We got to try to think about every contingency
issue and ask the question that I can’t answer or my counterpart
can’t answer while these resources are still in place working
on this project. We’ve really got to try to ask every potential
question because if there’s an issue that happens when we’re
in implementation and we don’t have people to pool on, then
there’s risk there.
One part of me, I’m really looking forward to implementation,
because there’s going to be so few people working on the project,
and I’m going to be one of them. It’s a neat thing to
be around at the very very end. But the other side of me thinks I’m
not going to have all these people to ask questions. So I think I
got to think of any and all questions now while I have people that
can answer those questions available. It’s something I’m
not looking forward to, to see the end of the program, but it will
be something interesting when we do implementation. As far as where
they’re going I have no idea.