NASA STS Recordation Oral History Project
Edited Oral History Transcript

William J. Roberts
Interviewed by Jennifer Ross-Nazzal
Downey, California – 26 August 2010

Ross-Nazzal: 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 with us.

Roberts: You’re welcome.

Ross-Nazzal: 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]?

Roberts: The 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 detail desk.

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.

Ross-Nazzal: Was this under [N.] Wayne Hale [Jr.] at this point?

Roberts: Actually Bill [William W.] Parsons was the Space Shuttle Program Manager at that time.

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.

Ross-Nazzal: You mentioned more horizontal integration versus point-to-point communication. Can you elaborate what you meant by that?

Roberts: In 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.

Ross-Nazzal: Do you think technology contributed to that with emails?

Roberts: Well, 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.

Ross-Nazzal: Who was on the design recertification team? Was it primarily [The] Boeing [Company] folks or did it also include NASA?

Roberts: We 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.

Ross-Nazzal: Can you give us an overview of some of the changes that were made to the orbiter as a result of the investigation?

Roberts: The 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.

Ross-Nazzal: Oh, it wasn’t?

Roberts: It 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.

Ross-Nazzal: That’s amazing. Was that just because everyone thought that the system was so robust before Columbia that it had proven itself?

Roberts: Well, 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 plan.

Ross-Nazzal: Tell me how the President’s [George W. Bush’s] Vision for Space Exploration [2004] impacted the recertification effort, if at all.

Roberts: I 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.

Ross-Nazzal: Yes, absolutely. Were you working at all with the Return to Flight Task Group as they were doing their summary for NASA?

Roberts: Yes, 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.

Ross-Nazzal: 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 to flight?

Roberts: All. 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.

Ross-Nazzal: Were there any changes that you had to go back and make?

Roberts: Yes. 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.

Ross-Nazzal: Were you at the Cape [Canaveral, Florida] for the launch?

Roberts: I was there. I’ve been at probably 30 or 40 launches.

Ross-Nazzal: Were you on console or you were just there to witness the launch?

Roberts: No, no, I was just there.

Ross-Nazzal: Did you go to the Mission Evaluation Room for the mission?

Roberts: No, I came back since I wasn’t vehicle manager. I’ve done my time in that MER.

Ross-Nazzal: You mentioned that you started working on transition and retirement. When did transition officially begin?

Roberts: It 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 aircraft.

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 whole process.

Ross-Nazzal: Will you have to reprocess Enterprise as well?

Roberts: Yes, 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.

Ross-Nazzal: 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?

Roberts: Yes. 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 [2011]. 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.

Ross-Nazzal: 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?

Roberts: We 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 documents now.

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.

Ross-Nazzal: 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 OPF?

Roberts: Yes, 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 orbiter.

Ross-Nazzal: 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.

Roberts: Like I said, this T&R project is pretty mature. The documentation is ready to go, the WADs are coming out.

Ross-Nazzal: How do you come up with [potential contingency plans for T&R]?

Roberts: When 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.

[End of interview]