Less of Me

By Tim Owen

Let’s be frank, things just weren’t working out. The project was a microgravity experiment that was supposed to be ready for launch in August 2000. Right from the get-go the hardware development team was behind schedule and over budget.

The Principal Investigator (PI) and his science team had been responsible for not only the science but also the hardware development. This was one of the first projects coming out of the Microgravity office at NASA’s Marshall Space Flight Center to use the PI mode for the bulk of the project management. “Thank you very much for the money. Please leave us alone.” That about summed up their relationship with NASA.

My management asked me to step in and get a handle on the project. On the NASA end of things, we’d been relatively hands off until now. The culture at Marshall is steeped in systems engineering, and what we had set off to do on this project was 180 degrees opposite of that. Now we were trying to get back in the picture. The way my management put it to me was like this: “You’ve got to — you know — roll up your sleeves and get down in there. Take back control. You’re our guy.”

Sometimes described as “weightlessness,” microgravity is a condition in which the effects of gravity are greatly reduced. In microgravity, researchers can isolate and study the influence of gravity on physical processes, such as this flame.

I came on as the project manager for NASA in the fall of 1999. In the winter of 2000 initial verification testing began. Right off the bat one of the key technologies was failing. The PI needed to capture digital snapshots of the crystal growth process in order to understand and determine the physics of crystal growth as it occurs in a microgravity environment. Clarity of resolution was required at two different points on the crystal growth chambers: one for capturing the digital images, and the other for measuring the laser light scattering ratio. In the case of the latter, the resolution of the laser light scattering ratio was not meeting the science requirements.

Such were the kinds of technical problems I was expected to get a handle on. There were other problems beyond the hardware developer’s control. Defining hardware requirements, in particular hardware interfaces, was complicated by the fact that the development of the vehicle (Space Station) and carrier (EXPRESS rack) was taking place concurrently with the development of this experiment.

If all this doesn’t sound like enough high drama, it was my first assignment as a project manager. Naturally, I wanted to prove myself and be successful. I also wanted to do right by NASA and live up to the example set for me by the best project managers I had worked for during my twelve years at Marshall Space Flight Center.

Bull in the China Shop
It’s a precarious situation to be in when you start off riding one horse across a river and decide in the middle to get on another. The hardware development team was confused at first, and not exactly amenable to this new arrangement. They felt like they had been empowered to go do this job and now NASA was telling them, “Look, you’re not meeting your cost and schedule commitments. We’re going to have to step up our involvement.”

Suddenly their relationship with NASA, including our level of technical involvement, had changed in quite a dramatic way, in part because we were entering the testing and verification phase but primarily because of their poor performance. There’s no way you can change from one way of working together to another without somebody on their side wondering, “What’s going on here? Am I doing something wrong?”

Part of the problem was me, too. When I see that something is not going well, I have a tendency to push everyone out of the way and take charge. Maybe that’s why my management thought I was the person to step in and take hold of the reins on this project. I had been through enough project management training to know the value of consensus building and the need to establish good communication across the team. Funny how natural tendencies, despite training to the contrary, can undo our best intentions. Given the state of the project, the pressure I felt under, it was hard not to succumb to the urge to over control.

My objective was to stay focused on results. Schedules, deliverables. Did we pass that verification item, or did we fail? If we failed, what do we have to do to get back in line? We had some very long meetings, and there were painful discussions. In order to focus them on cost and schedule performance, we started each meeting with a schedule review. The schedule was generally about six pages long with maybe a dozen items on each page. As we worked through that, it became obvious to me that the hardware development team did not have a solid understanding of what was on their schedule and how it impacted other parts of the project. A lot of my questions started to sound the same: “Tell me what you mean by this activity.”

It was rough on them because they were seeing that they really didn’t know what their drivers were. Not surprisingly, they developed something of a defensive posture to me. I asked hard questions. A lot of these folks on the hardware development team had been going along and never been held accountable. I came in and one of the first things I did was say, “Let’s look at who the people are on the project, what their responsibilities are, and hold each person accountable for what they’re supposed to be doing.”

Was it wrong to ask hard questions? Certainly not. But just like the impact of a joke depends so much on its delivery, so does the ability of a leader to effectively communicate where the team is going. My approach rubbed some people the wrong way. Feelings were hurt. The tone I was conveying, and none too subtly, was that you all are screw-ups and I’m here to fix things.

Learning What I Already Knew
Part of establishing accountability, and being a good project manager, is learning to work with your team. Because every project team is only as good as the weakest link.

I realized soon enough that I could not do everyone’s position. Who knows how long I might have kept pushing had I not recalled a similar situation on a project about six years earlier? At the time I was working as a subsystems lead and there were some computer sequences that needed to be completed by a certain time. I had a particular understanding of how I thought it ought to be done, and when I gave the job to the person who was going to do it I said, “Have this ready in three weeks, and this is how I want it done.” To his credit, he said to me, “Look, if you’ve given me the responsibility and you’ve empowered me to go do this, then let me do it the way I think it ought to be done.”

That was a profound realization for me. You could even call it a “Eureka” moment. At that point I recalled working under project managers whom I considered to be the best. The ones who were the best examples, my mentors, gave me the authority to go off and do the job my way. Because they gave me that authority, I felt accountable to them and to the project.

Eventually, the guy assigned to the computer sequences worked out the problem, and I was glad in the end that it was not done in the way I wanted. I was able to see the merits of what that person was doing, and this opened up my eyes to realizing that I was not alone on this project. Help was always there. All I needed to do was reach out to it instead of pushing it away.

Here I was six years later, learning that same lesson all over again. You build your team by building your people. There was no doubt that people on this project were working hard. Clearly, they were not focused on being accountable for their cost and schedule, but there was never any question about whether they were putting in enough hours or doing enough analysis.

Dynamically-Controlled Protein Crystal Growth (DCPCG) is the first space hardware to provide control over protein crystal growth by varying the rate of evaporation of protein samples.

There are ways of getting people to be accountable, and some strike me as far more favorable to the overall good of the project. Just like in any relationship, you have to try to understand each other’s point of view. You can’t say, “Go do this, just because I said it.” It doesn’t work that way. Milestones and accountability are great, but the key is to agree upon goals. Once you do that you must let them work. You don’t have the competencies of all the team members, and you don’t have enough time to learn them all.

A perfect example dealt with the concurrent development of the science instrument with the vehicle and the carrier. This was a tremendously tedious and complicated task. It required an enormous amount of coordination between the hardware development team, vehicle and carrier development organizations and the responsible engineering disciplines at Marshall. By empowering and allowing the lead systems engineers to perform their roles made a big difference in the running smoothly amidst the confusion.

The significance of allowing the hardware development team, science team, and the engineering team and their discipline/element leads to do their jobs and know that I, the project manager, was going to let them to do their jobs, but with the expectation that they would do it in a timely manner and in a cost conscious way was so crucial to the ultimate success of this project.

In the end, we were able to gain back some of our schedule after a major de-scope and launch date slips. More importantly, I learned something about myself, yet again, that is going to make me a better project manager. The bull-in-the-china-shop approach leaves little room for movement. There’s only but two things left on the floor after the bull has had its way in a china shop, and neither one of them is very nice.

When I came onto this project, I was very ambitious and very sure of how I thought things should be handled. This is going be a brand new project, starting my first day. Sorry, but it doesn’t work that way. As much as I wanted to take hold of the reins, grab the bull by the horns, be active, “You do this; you do that,” it’s just not the right way.

You can’t force people to do what you want them to do. Instead, what you really want is to encourage people to take responsibility so that they’re doing something because they want to do it, not because you want them to do it. A little less of me in this case went a long way.

Lessons

• Resist the urge to micromanage. Encourage the team effort. Inclusion and openness work better than exclusion and arrogance.
• Be open to team members who can approach a problem and solve it differently than you because of their expertise.

Question:
What lessons have you had to relearn throughout your career?

About the Author

Tim Owen is currently the Project Manager within the Transportation Directorate at Marshall Space Flight Center for the Expendable Launch Vehicle program. He has worked with NASA at Marshall Space Flight Center for over 12 years in a number of diff e rent positions and organizations. He most recently served as the Project Manager for a space station experiment called the Dynamically Controlled Protein Crystal Growth (DCPCG) within the Microgravity Sciences and Applications Department of the Science Directorate.