Select Page


Passing the Baton: Project Management Lessons In Regret
By Terry Little, National Aeronautics and Space Administration (NASA)

I have led six major defense acquisition programs during my civil service career. For most of those, I was the first leader the program had and did not have to adjust to someone else’s legacy. This was both good and bad.

The obvious good was that I was able, for the most part, to fashion things as I wanted them. These included patterns of interaction inside and outside the project office. I chose who would be in leadership positions. I developed the managerial philosophy and leadership vision. I decided my role vis-a-vis others in the office. I created the expectations and goals. The bad part was that all the while I was doing this I never considered what I might be leaving my successor to deal with. My reasoning was simple: I never intended to leave. I should have known better.

Every time I left a program, it invariably went into a nosedive that lasted anywhere from a few months to, in one instance, more than two years. I could blame my successors for failing to pick up where I left off, but that would ignore the obvious. I was the common element in every case. I had failed miserably in preparing the way for my inevitable successor — failed five times! What had I done or not done?

For one thing, I had adopted many non-standard practices which suited me, but would likely be unsuitable for my successor. Consider earned value and metrics as an example. Because I did not agree with earned value and metrics, I simply did away with them. I worked on a face-to-face basis getting my information first hand and verbally. My way involved an amount of travel that any reasonable successor would simply not tolerate. Additionally, the DoD’s “best program management practices” places a lot of emphasis on using earned value and metrics as tools. Anyone replacing me would probably be adhering to these.

The second thing I did was to make many manager-to-manager agreements that we never formalized in writing. They were just good faith understandings between two people. What happened when my successor arrived? There were no more understandings. My successors honored the written agreements, but had no allegiance to the unwritten ones I had made. The result was sometimes major turmoil.

Third, I unconsciously fostered a tailored mentality among both the people who worked for me and the contractors’ project personnel. For instance, everyone knew that I was impatient with detail and wanted to get quickly to a bottom line that I could measure against my intuition for making decisions. Good for me, but bad for my successor — likely to be a more typical program manager who would expect detailed analysis.

I also developed a somewhat deserved reputation as a bridge-burner. If one of my peers from outside the project office didn’t agree with what I was doing, I simply went around or ignored him or her. It worked for me, but my successors had to rebuild lots of bridges, which took time, energy, and focus away from executing the project.

I cared more for people’s passion, loyalty, and their ability to get results than I did for how they did things. In that way, I put some real “odd-balls” in responsible positions. I was more than willing to sweep up any broken glass — a willingness that my successors did not share.

Perhaps my worst fault was that I never groomed anyone to be my successor. I could have done that easily, but since I didn’t intend to leave, it never occurred to me that I should do that. Some people take longer to learn from their mistakes. It has taken me failing to do this five times before I finally learned to begin a succession planning process in earnest starting from Day 1.

In a perfect world, a program or project would have one manager from birth to death. But we don’t live in a perfect world. What should you take from all this? You decide. My conviction is that leading a project in a way that best allows a seamless transition to another leader at some uncertain time in the future is fundamental to project success

Reprinted with permission from NASA. This article first appeared in NASA’s ASK Magazine, the NASA source for Project Management and Engineering Excellence.

Recommended PM App

Recommended PM App