Big Facilities, Hard Lessons
Three years after a catastrophic accident at the National Full-Scale Aerodynamic Facility, the large wind tunnel at Ames Research Center, it was time for a second unplanned shutdown. John Perry and I had watched the facility’s dynamic pressure during testing for several minutes. At less than two-thirds of the required pressure, the structure was already close to redlining. We needed to stop the integrated system test for two months and spend several hundred thousand dollars to reach design speed. That was the first time I wanted to quit my job, and it wouldn’t be the last. But for every tough challenge I’ve faced during my thirty-four years at NASA, I’ve gained some important lessons. In this case, taking responsibility for a problem can be as rewarding as it is challenging.
Getting Our Feet Wet
Five years after that shutdown, I was working on the 12-Foot Pressure Wind Tunnel (PWT) Restoration Project. At the time it was the largest American Society of Mechanical Engineers Division 2 pressure vessel ever constructed in the country. We needed to fill it with water for three separate hydrotests—a total of more than five million gallons of water. We presented the review committee with a probabilistic calculation concluding that the magnitude 5.1 earthquake required to fail the columns would not occur during our testing. The numbers showed it was beyond reasonable expectation for such an event occur during the ten-day period we had planned for tests. However, once we had five million gallons of water in the primary vessel, we realized that we didn’t wish to experience an earthquake of any magnitude. Statistics are useful when considering other people or other times. When it’s you and now, statistics don’t matter. Following a suggestion from our project manager, Harry Gobler, we stayed the weekend to complete all three hydrotests before Monday morning.
During the course of the 12-Foot PWT project, we needed to create control screens for the first fully automated wind-tunnel facility within NASA. The controls contractor had run into a cash-flow problem because he had underestimated the necessary design time. Again following Harry’s advice, I flew to the contractor’s facility for an off-the-record Saturday meeting to discuss the issues face to face. I learned the contractor’s funding issue on my job would bring unneeded and unwanted attention from his corporate headquarters. With great struggle, I managed to get a change order approved to cover the fully justifiable costs. Once the contractor believed that I needed his expertise and didn’t want him to lose money, we came to trust each other fully. This single incident reversed all my cultural training about contractors and partnering. I learned that the majority of contractors, apart from a few gold-diggers, are hardworking people trying to make a profit. When treated fairly, they produce excellent results.
During the earlier design effort on the same project, we needed to make important decisions about how to split our twelve construction-work packages for procurement. Two of these packages were so technically complex that our previous project manager, Nancy Bingham, decided to try a relatively unused procurement strategy that would result in a short list of technically qualified bidders, who could then bid against each other. When the Acquisition Division told us that Ames never did business this way, Nancy brought in a copy of the Federal Acquisition Regulations and put it on a stand in the middle of the project office. When anyone made a definitive statement in a meeting about acquisition, we would simply go to the project office and look it up, chapter and verse.
What we found was that many objections to our unconventional ideas were personal and subjective, but not prohibited by the Federal Acquisition Regulations. The boxes we had been confined to because of our lack of experience with large procurements began to melt away. At the end of the 12-Foot PWT project, we had successfully acted as the prime contractor, issuing and managing twenty separate contracts that totaled more than $101 million. Our group of relatively young engineers became a group of seasoned contracting officer’s technical representatives (or COTRs) in just a few short years. With constant encouragement to think for ourselves and take responsibility, we were able to gain significant experience in a short amount of time. Having the courage to push boundaries and ask questions allowed us to find strengths we didn’t know we had.
Rewinding the Coils
Before long, I faced impending failure on another project. As part of the Unitary Modernization project to upgrade the Unitary Plan Wind-Tunnel Facility, we were rewinding four large alternating-current motors, each one capable of 65,000 horsepower. Two years into the rewind, several coils began to fail at the contractor’s plant during a high-potential test at 10,000 volts. They kept splicing the failed coil strands, assuring me of the high quality and robust nature of the repair. We use this repair in industry all the time, declared the contractor.
Our team had an experienced motor designer, Andy Spisak, who told us the splices would not work and that we needed to make design changes. After more than twenty coil failures, I walked into Harry’s office and said I didn’t know what to do. I’ve been waiting for you to admit the failure, because I need your expertise to solve the problem, Harry said. Here’s the plan.
We flew to Houston a few weeks later and asked the contractor to conduct one last winner-take-all high-potential test on each of the motor stators in the presence of the contracting officer. If any of them passed, we would pay for newly designed coils for that particular stator rewind. If any of them failed, the contractor would have to pay. Harry was betting every dollar of his project’s contingency fund that the other stators would fail.
After some negotiation, we set the test parameters. Within two hours, every stator failed. Although we lost a year and a half, the contractor paid the majority of costs for correctly redesigned coils. When I asked Harry how he knew that the motor stators would fail the high-potential test, he said, I didn’t. But it seemed like a good bet, considering the technical expertise of the team. If it didn’t work out, I was willing to deal with the consequences.
I learned that sometimes you don’t know the answer, but you may have to make a very important decision with incomplete data. The key is to surround yourself with competent people and listen to them.
As we were getting ready to start the facility in 1998, the contractor warned us that the proprietary control software for the main drive system was not designed with Y2K in mind. Since the four main drive motors had a capability of 180 megawatts at full power, a software glitch was potentially catastrophic.
The best part was it could be done in eight weeks. Although Harry was skeptical, he asked me, Do you believe them? Can they do it? Without enough money to pay the contractor, or any other plan to deal with the problem, it didn’t seem like we had any alternative. I learned one of the most valuable people lessons from what happened next.
Peter and Mark rewrote the software. They installed and tested it in eight weeks, exceeding my expectations but not their own. I learned that passionate people are easy to manage. All you have to do is give them responsibility and tools, trust them to do their jobs, and get out of their way.
Many Stories, Many Lessons
There are dozens of untold stories, but the real value is in the lessons I have learned. The best lessons seem almost obvious now that the struggle of learning them is far behind. My personal short list includes the following:
- The project is always more important than any individual desires. Everyone can be replaced, and that includes me.
- A project lives or dies with its people. You must surround yourself with trustworthy people who want to be part of a team.
- People want to be trusted. Trust them until they have twice shown themselves untrustworthy. And always be willing to take the first hit.
- Make hard decisions in the quickest, fairest manner possible and explain your rationale. People want a decision and will respect one made out of fairness if it is explained to them.
- People need to be informed. If not informed, they will assume the worst. Communicate freely and often, and empower others with your information, rather than empowering yourself. Never allow gatekeepers to manage the flow of information.
- Teach people to give and take criticism on a non-personal level. Most technical issues can be sorted out in candid, informal sessions.
- People want and need to be heard. Listen to everyone, on their terms, when they are ready to share.
- Good enough is always better than optimum. Meet the requirements and move on, because you will need the resources in other places.
- Most roadblocks are unnecessary. Never let someone without responsibility for cost or schedule try to influence yours.
- Test your authority and encourage others to do the same, which means they will be testing you.
- Give people your blessing when they think for themselves, even if it causes you some personal pain.
- Find a way to include everybody. People work much harder when they have some responsibility. Make their failures your problem and try again.
- Keep meetings small. Hardworking people don’t want to meet. Non-workers love to meet.
- Find a mentor and pick his or her brain. Make sure it is someone who is not impressed with you, so they can be honest.
These lessons were learned on the job in painful circumstances over a long period of time. Some of them were the outcome of direct personal failures, which leads to perhaps the best lesson of all: having our worst perceived scenario happen sometimes results in a pearl of great value.