My Oar Keeps Breaking – How to Move Your Part of the Program Forward

To print a PDF copy of this article, click here.

Author: Chad Millette

As an instructor for the Air Force Institute of Technology’s Intermediate Project Management class (IPM 301), I sometimes hear students express deep frustration with their seeming inability to make any positive progress on their programs. In a recent presentation, retired Air Force Lt. Col. Dan Ward fielded several questions from junior program managers (PMs) about what they could do to make a difference in their programs. Ward’s responses echoed good advice I received during my career, which I was inspired to share.

As PMs in the Department of Defense (DoD), we often struggle with how much control we feel we have (or don’t have) over our programs. Although we are project managers, we don’t really manage the projects day to day; we hire defense contractors and rely on them to manage their projects. We often come into very large programs somewhere in mid-execution and, depending on our tenure in the program office, we often leave somewhere in mid-execution—with the program hopefully closer to completion than when we arrived. It can prove frustrating not to have been in at the beginning and to have to live with the results of decisions made earlier. The contractor often seems unresponsive. The budget is in peril continuously. And no matter what we do, the program doesn’t seem to improve. How is a PM to remain positive, upbeat and engaged?

I experienced just this type of frustration when I was a major assigned as a PM on a multibillion-dollar satellite system development program. This program could be considered both a Death March and a Death Star program. Edward Yourdon defines a Death March program as “one for which an unbiased, objective risk assessment determines that the likelihood of failure is > [greater than] 50 percent.” Success, in this case, is defined by the traditional constraints of cost, schedule, and performance and quality—delivering the user’s required capability on time and on cost. Ward says a Death Star program is “any enormous project that is brain-meltingly complex, ravenously consumes resources, and aims to deliver an Undefeatable Ultimate Weapon.” (See Ward’s article “Don’t Come to the Dark Side,” Defense AT&L, September–October 2011.) The program I was working on fit both of those definitions. And let me tell you, when the two most apt characterizations of your program include the word “death,” it can make for a very frustrating experience.

Shortly after I arrived, the program experienced its second Nunn-McCurdy breach. (A Nunn-McCurdy breach occurs when an acquisition program experiences a 25 percent or greater increase over the current Acquisition Program Baseline (APB) objective and/or a 50 percent or greater increase over the original APB objective.) Several years behind schedule and millions of dollars over budget, the program seemed doomed to fail. The program originally was awarded as a total system performance responsibility (TSPR) contract, and the program office and contractor had what could best be described as a tense relationship. At one point, the government zeroed out the award fee on the contract.

I was not the program director (i.e., the overall PM); I was assigned subsystem management responsibilities (database, flight software and ultimately the spacecraft subsystem). However, as a junior, still-motivated PM, I desperately wanted to make a difference in turning the ship around. At one of my lowest points in terms of motivation, I expanded upon the idea of the ship analogy.

The support contractor was telling me that worrying about things over which I had no control will result in frustration and that I needed to focus my energies on the part of the program I could control.

I had a whiteboard in my office. One day, I drew a large sailing ship with two masts and labeled the ship the S.S. Program. I drew water underneath the ship with a big arrow that showed the direction the water was taking us and I labeled the water as the contractor. I drew clouds in the sky above the ship with arrows indicating the wind and labeled this as Congress. I added a rudder to the back of the ship and labeled it the program director. Finally, I drew a porthole in the side of the ship with an oar sticking out of it, and I labeled that as me.

I would explain to visitors that the cartoon depicted how I felt about the program. The contractor takes the program along a strong current and seems to be the greatest determinant of where the program is going. Sometimes the political winds would change our direction or our speed. The program director can make programmatic course corrections and influence the direction we take (i.e., acts as the rudder). And finally, I’m the guy sticking his oar out into the water to influence the program’s speed or direction. I would tell people that I felt like every time I stuck my oar in the water, it would break. I would then go back and get another one and stick it in the water, only to have it break again.

I was pretty proud of myself for coming up with such a powerful analogy that represented not only my frustrations, but apparently those of many colleagues as well. As people would stop by to hear my explanation of the drawing, I found that the analogy resonated with them. In fact, some even added to it. One of my co-workers drew the water ending at a steep waterfall and labeled it the “Cliffs of Insanity.” Another drew rocks at the bottom of the waterfall showing how perilous would be the journey over the edge. Finally, another drew a little boat popping up out of the water and labeled it the alternative to our program that the Air Force was considering.

This kind of dark humor is common in many program offices—and that is one reason “Dilbert” cartoons are featured prominently on so many cubicle walls. Wallowing in misery, however, isn’t healthy. A telltale sign of a Death March project is when the humor gets to the depths of the graphic I drew on my whiteboard. I found I was retelling the narrative and adding to it frequently over the course of a month or so. I wasn’t getting any closer to fixing the program or reducing my frustration, but explaining the graphic gave me an outlet and an ability to commiserate with my teammates. Ultimately, I was confronted by someone who didn’t want to share my analogy but to put me on the right track.

A wise retired senior officer who was a support contractor for the program came in one day, looked at my whiteboard and shut the door. She had heard about the drawing and came to see it herself. She listened intently as I boasted about how closely the situation I had drawn on the board matched the real world in the program office. When I finished, I noticed she was scowling. What she said caught me a little off guard because of both her tone and direct approach. She said, “You moron! Of course you can’t change the direction of this program. This program is huge. Your job is to do the best you can with the part of the program that you are assigned. Worry about the cost, schedule and performance of your piece of the program and let the leadership deal with the bigger picture.” She walked out chuckling and sarcastically muttering, “My oar keeps breaking … give me a break.”

I thought about what she said and realized she was right. Millette couldn’t fix this program—moreover, doing so wasn’t my job! My job was to ensure that my subsystem met the user’s requirements affordably and was ready when the program needed it. The support contractor was telling me that worrying about things over which I had no control will result in frustration and that I needed to focus my energies on the part of the program I could control. I didn’t connect the dots at the time, but I have come to realize that her advice was in concert with what Stephen Covey called the ”Circle of Concern/Circle of Influence” in his seminal book The 7 Habits of Highly Effective People.

Within an acquisition program context, Covey’s paradigm suggests that the broader scope of the entire program would be in our Circle of Concern—i.e., things we have no real control over and can’t do anything about. Many PMs can feel trapped when they focus their energy in the Circle of Concern—things like the weaknesses of other people and problems in the program environment. PMs stuck here are characterized by negative attitudes and language and feelings of victimization. Constantly focusing on these areas increases feelings of helplessness. Such are the feelings expressed in the S.S. Program graphic on my whiteboard and those that my IPM 301 students describe when they bemoan their individual situations.

However, there is a smaller circle inside the Circle of Concern where we can make a difference because we do have the responsibility and authority; this is the Circle of Influence. My sage advisor was suggesting that, instead of being frustrated because of my inability to fix the program as a whole—certainly inside my Circle of Concern, but not in my Circle of Influence—I needed to focus on fixing the part of the program for which I did have responsibility, my own little subsystem.

Covey would suggest that PMs can recognize when they are in the Circle of Concern when they have thoughts such as: “If only I had clearer requirements,” “I could do a better job if I had a more stable budget” or “if I had more time to mature the technology.” Notice the tone; the Circle of Concern is filled with haves. On the other hand, the Circle of Influence is filled with be’s: “I can be more engaged with my user,” “I can be a positive influence on my contractor counterpart,” “I can be the one to craft a flexible acquisition strategy.”

Covey suggests that PMs have problems in one of three areas: direct control (problems involving our own behavior); indirect control (problems involving other people’s behavior); or no control (problems we can do nothing about). PMs can solve the direct control problems by improving their habits—i.e., what they do. PMs don’t solve indirect control problems themselves; rather, they change their methods of influence to work with people to solve the problem. Finally, PMs don’t solve the “no control” problems at all; they resign themselves to “genuinely and peacefully accept these problems and learn to live with them,” even though they don’t like them (think of the Alcoholics Anonymous serenity prayer).

On my program, I dealt with my “direct control” problems through weekly discussions with my contractor counterpart about issues with our subsystem development. Also, I resigned myself to get smarter on earned value management and dig deeper into the earned value reporting we received. To handle “indirect control” problems, I got together with the other majors who were subsystem PMs and, rather than commiserating, we came up with integration forums where we could discuss key aspects of how our subsystem developments interacted with each other.

Having been put on the right course by my sage counselor, I stopped fretting about aspects of the program outside my span of control (the “no control” problems). I kept aware of what was going on—but only as a means of being prepared in the event of an impact to my area.

When I first started on the program, there was talk that the satellite was 3 to 4 years from launch. I spent 4 years assigned to the program in various capacities—a tour I joke ought to make me eligible for the acquisition equivalent of the Purple Heart. When I left the program, it was still about 2 to 3 years from launch. In the end, the satellite did launch 2 years after I left. By all accounts, the satellite system is performing at or above the user’s expectations. Although it was at times a very frustrating assignment, it was also incredibly rewarding. And looking back, my frustration could have been reduced—and ultimately was with the helpful advice of a veteran PM—with some perspective about what was and was not in my circle of control.

During that recent speaking engagement, Ward responded to a young PM’s questions with advice similar to what I tell my students who ask what they can do when they feel increasingly frustrated. Ward reminded the PMs that no matter where in the life cycle their program is and how late or over budget it might be, there are decisions to be made about the future direction of their piece of the program. I tell my students that, with the added tools we provide them in IPM 301, they can now ask better questions and dig a little deeper into the program status and progress. It is the government PM’s job to evaluate the situation and make decisions with the best chance of righting the portion of the ship for which they are responsible. I believe that, if this tack is taken by everyone in the program office, pretty soon, the Death March and Death Star dark humor talk around the program office will subside as all hands are motivated to do their part to help the program succeed.


The author can be contacted at

Millette is a retired U.S. Air Force lieutenant colonel and a project management instructor at the Air Force Institute of Technology’s School of Systems and Logistics, Wright Patterson Air Force Base in Ohio. He has experience as a program manager in software, infrared countermeasures, satellite, intelligence, surveillance, and reconnaissance development efforts.