Tuesday, June 14, 2016

Trust Your Judgment




Colonel Jeanne C. Sutton of the U.S. Air Force, a former chief of International Programs in the Acquisition/Theater Defense Deputate of the Ballistic Missile Defense Organization, had been appointed as a project manager three weeks earlier and only three weeks remained for her team to release a bid for a very complex project.

As she recalls, management mandated the simplifying and streamlining of solicitations but her staff was totally unable to put those requirements into practice. They could not free themselves from their usual way of doing things. They prepared a huge document written in mumbo-jumbo, telling bidders how to dot their i’s and cross their t’s. Sutton knew that it would be impossible for her to go through the entire document in the little amount of time that was available.

A good friend from outside her organization agreed to help. He quickly created a small team of “independent experts” to review the solicitation and to offer constructive suggestions. Despite the turgid text, they developed a list of critical areas that would significantly make the text more understandable and enable contractors to respond more intelligently and submit more attractive bids.

Sutton describes how she helped her team move forward given a formidable schedule:

“Of all the issues, I decided to take a stand on the program schedule. My staff established 17 firm deadlines over a 6-year period. I insisted that there be only two firm dates: project start and project completion. After all, any contractor worth his salt would know how best to go from start to finish.

They were stunned. I gave them a full two hours to rehash their argument that the only way to do the job was the way it had always been done. That was the tried and proven method. At the end of the two hours, I made my decision — there would be only two dates.”

During the following three days Sutton’s staff made more changes that reflected the ideas of the independent experts. She then gave them an additional day to incorporate the changes and to meet with her again for finalization and release.

On that day, they all assembled around the conference table with copies of the revised solicitation. Sutton asked if they felt that the new document  met her guidelines. One man, Tom, proudly gave her a copy for review and said, “Yes ma’am, the changes were made and we are ready.”

This was the test. She could have allowed them to release it and thereby show that she trusted them fully, but something still didn’t feel right. Sutton asked everyone to leave the room, except for Tom.

The first page she turned to in the revised solicitation was the schedule page. The multiple deadlines stood out like a sore thumb. Not saying a word, Sutton took her pen and crossed out every date between project start and finish, while looking sternly at Tom. She then asked if she had to go through the entire document to make sure all the changes had been made. Tom apologized profusely and assured her that no other changes had to be made. Sutton rose and walked out of the room and never mentioned the incident to anyone.

Sutton’s professional interactions with Tom didn’t stop here. As she says:

“Several months later, we were faced with another issue that demanded an immediate response. It was extremely critical and needed the most careful planning. Some of my best people, who would have done a great job, volunteered to lead the project — but not Tom. Since that embarrassing incident, he had studiously avoided me.

I deliberately picked Tom for the project. He was happy she did, because this gave him a chance to prove himself. And he sure did. Tom did an extraordinary job. Today he is one of the best people on my staff and my most ardent admirer.”

Through her story Sutton shares a few key lessons about that interwoven fabric of trust and judgment.

·       Trust does not recognize organizational boundaries. You may trust your contractor, you may distrust your employees, and you may be right in both cases.

·       There are situations, however, where the most important element to trust, is your own judgment.

·       After a key team member has failed you, give him or her a quick opportunity to rebound. This gives the person the chance to reestablish his or her capability and relationship with you. 

Laufer, A. and Hoffman, E.J., 2000. Project management success stories: Lessons of project leaders. Wiley, 109-110.


Tuesday, May 17, 2016

The project manager must be the team maintainer


In the previous blog, Terry Little, former director of the Air Force Acquisition Center of Excellence — considered by many to be the best project manager at the US Defense Department in recent history — highlighted the importance of adhering to the rule: “People are not your most important asset, the right people are.” In this blog, Terry provides a painful example of what could happen when the project manager fails to maintain teamwork throughout the life of a project.

As I look back at my long career managing major projects, I see a trail littered with mistakes — lots of them — but, thankfully, fewer as my career progressed. I saw many mistakes almost immediately and quickly corrected course. Others took longer — weeks or months — for me to recognize. These I fixed the best that I could. There were a few that I did not fix either because I was too late to recognize the problem or I chose not to fix it. This blog is about my second worst mistake. It troubles me still. That mistake was how I dealt with Joe.

Joe was a government contracting officer whom I picked as a member of my first project office. I did not know him beforehand, but someone had recommended him as a person who was innovative and who would do whatever was necessary to get the job done. I was impressed during our interview with his enthusiasm and attitude. The only slight negative was that his answers to my questions during the interview were rambling and long-winded. He was probably talking 80-90% of the interview time.

Joe quickly adapted to the project office and, true to the recommendation, he was a creative and willing worker. However, over time I began to notice that others in the project office were avoiding Joe. When he came into their cubicles, they quickly got up and went to get coffee, have a smoke break or went to the restroom. At first I found this rather amusing. After all, Joe was not a problem for me. When he would come into my office, I would listen to him for a few minutes and then put my hand up to indicate that I wanted to get back to work; Joe would then leave. Most of what Joe had to say was rambling, repetitive and, often irrelevant.

When we had group meetings Joe monopolized the meeting and when he started talking he would not stop. Sometimes I had to end the meeting just to free everyone from Joe’s jabbering.  A couple of times after meetings I called Joe into my office to counsel him. One time I told him that he talked too much and that he needed to curb his talking. Another time I suggested that he should do less talking and more listening. Nothing changed. I was reluctant to be harsher with him because he was so good at what he did. Too, I reasoned that he was unlikely to change because he was pretty old or that he would just get angry and leave. So, I tolerated his behavior, albeit reluctantly.

After about six months we had a design review at the contractor’s plant; it was to last two and one half days. When we arrived, Joe asked me to not attend the design review because he had a critical issue to negotiate with the contractor. I assented. At the end of the first half day, I sought Joe out and asked him how the negotiation was going. “Fine,” he said. “We are making progress.” Good, I thought.

The second day of the design review was stressful for me. I had to make a host of decisions, some of which I knew would disappoint our customer. When I saw Joe, he was talking with a group of about five people whereas before it had been only two. Again, I asked Joe for a report and he assured me that things were progressing. Very tired, I did not ask him to elaborate.

The final day of the review was even more stressful than the second. I was trying to hide my discouragement when the contractor project manager tapped me on the shoulder and said “We need to talk.” I followed him out the door and he proceeded to tell me that his company could no longer deal with Joe.  He went on to tell me that the “negotiation” with Joe had gradually escalated until Joe was negotiating with the CEO of the company. After about an hour the CEO left the negotiation and directed his people to stop trying to reason with Joe.

As I began looking for Joe, my mind was racing, trying to figure out what to say. I decided to ask him what outcome he wanted from the negotiation and then to act as an intermediary between him and the contractor to resolve the issue.

I found Joe alone sitting in the room where he had been negotiating. He was clearly dejected.  “Joe,” I said, “what do you want from these people?”  Shaking his head he looked up at me and, after a moment, replied “I don’t know.” I snapped. “Joe, go back to the hotel, pack your things and go home.  When you get there clean out your desk and I will talk with you when I return tomorrow afternoon. You are fired.”

Joe was waiting for me when I returned to the project office. He began by telling me that he did not think he had done anything wrong; he had just been negotiating, he said. I told him that his incessant talking had disrupted the team to the point that he had to go. Then he shocked me by getting down on his knees and begging me to give him a chance to change. He was sobbing uncontrollably. I considered giving him a chance, but rejected it. Then, through his tears he said to me, “This isn’t fair. You never told me.” I started to defend myself, but decided that he was right; it wasn’t fair. However, I did not tell him that. Instead, I walked away and never saw Joe again.

So, for those of you who have read to this point and are thinking this has nothing to do with me because I have never had anyone working for me who talked too much, I offer the following: This parable, though true, is not simply about a person who talks too much. It is about anyone on the project team whose habitual or continuing behavior disrupts the team. This behavior could be disrespecting other team members, missing deadlines, shirking work, excessive absences, finger-pointing, constant complaining, revisiting past decisions, being always argumentative, showing a hot temper and a host of other behaviors. I could easily name a hundred and, given time, maybe a thousand. Anyone I have known who managed a project has had to deal with one or more of these behaviors.

The project manager must be the team maintainer. No one else can do it. It is his or her responsibility to recognize when an individual’s behavior is negatively affecting the team and, then to deal with that person’s behavior. Ignoring the behavior will have consequences. For, no team can function effectively when team member behaviors are at odds with team norms and objectives.

In this situation I failed miserably to both recognize the impact of the behavior and to swiftly deal with it. The best I can say is that I learned from this experience. In a future blog I will describe a situation where I put my learning to use and had a more positive outcome.

We selected this story because of its direct and important message: it is the responsibility of the project manager to maintain teamwork. This story is also relevant because of its two crucial but indirect massages:

1)  Even successful project managers make awful mistakes, and,

2)  Successful project managers are willing to share their mistakes, hoping that everyone will learn from them, and will be able to avoid them.
 


Tuesday, April 19, 2016

First Who...Then What




Jim Collins’s book, Good to Great, has sold over 2.5 million hardcover copies, and has been translated into 32 languages. According to Collins, one of the principles practiced by the most successful companies is: “First who… then what.”  Collins explains: “The executives who ignited the transformation from good to great did not first figure out where to drive the bus and then get the people to get them there. No, they first got the right people on the bus (and the wrong people off the bus) and then figured out where to drive it.… The old adage ‘People are your most important asset’ turns out to be wrong. People are not your most important asset. The right people are.”1

In this month’s story, Terry Little, a former US Air Force project manager, highlights the importance and the difficulties in adhering to Collins’ rule: “People are not your most important asset, the right people are.”2

“Uh-oh, this can’t be good,” I remember thinking as my boss’s boss opened the door and walked quickly to my desk, his face unsmiling. “Come with me,” he said.  I got up, my head down, as I followed him out the door. His name was Colonel L.

It has been almost 40 years since that day and I remember it like it was yesterday.  As I walked behind him down the hall, my mind was racing.  What have I done now?  I was pretty accustomed to being in some sort of trouble since I was a cofounder and president of the local professional employees’ union.  It would be fair to say that a lot of the senior civilian and military supervisors were wary of me and considered me a trouble-maker.  I was a very vigorous and assertive employee representative and I figured some higher-up had complained to Colonel L. about my disrespectful behavior; it had happened several times before.

I was surprised to see him head downstairs instead of to his office on the same floor.  When we got downstairs, he headed to our high-security vault.  We entered and went to a room inside where he invited me to sit down.  I had no idea what was coming.  Colonel L. started off by telling me that he and the general (his boss) had decided that they wanted me to head up a highly classified new program to develop and field a new capability as quickly as we could possibly do it. The estimate to complete the program was well over $1 billion.  He went on to say that I could select whomever I wanted to work with me and that I would have the freedom to ignore all rules and regulations; the only stipulations were that I had to obey the law and keep the team very small. 

“Can I ask questions?” I said.  Colonel L. replied: “No, not until you tell me that you will do it.”  After pondering a minute or so, and warning him I had absolutely no project management experience or training, I agreed to do it.  Little did I know the learning, heartbreak and exhilaration the next five years would bring.  I cannot write about the thrills and heartbreak because of security, but I can write about what I learned and unlearned.  This blog and those to follow will highlight those learnings that I think are pretty universal and can help other project leaders.

(I should say as an aside that the project was wildly successful, exceeding everyone’s expectations.  Otherwise, why would I be writing this blog?)

My first task was to pick the people who would be on the team. I had people work for me before in the military, but I never had the luxury of picking them. I immediately began interviewing candidates whom I thought might be suitable for the project office.  About half were civilian and half military. I was able to eliminate some interviewees immediately. They were the ones most interested in whether or not they would get promoted and those who were eager to tell me how bad their current boss was. I also eliminated anyone whose primary concern was how hard they would have to work.

After passing my initial screen, my major criteria were to pick people who: were very experienced in project offices, understood the complicated acquisition processes in the Department of Defense, and were skillful in their respective function.  That turned out to be a critical mistake.  Many of those I picked using these criteria were very poor performers. Most left voluntarily (this was easy because I had a policy that anyone on the team could leave anytime for any reason; too, I made sure poor performers knew they were not doing well and why).  Why they were poor performers is informative.

One of the most salient reasons was that some cared more about following the processes and avoiding risks than they did about achieving the project’s objectives.  I am not sure why this was.  My hypothesis is that some people need clear rules and are hypersensitive to the potential of making mistakes.  It was as if the limit of their accountability was process accountability and not project outcome accountability.  I concluded that some people are simply unable to adapt to an ambiguous, rapidly changing project environment.

Another key, related reason was that some poor performers were simply not team players.  A couple spent enormous energy criticizing the contractor and bloviating, but did very little work.  They became anchors.  A few, very experienced team members seemed to have been unable to apply that experience to a different situation. They appeared to be handicapped by their experience rather than helped by it.

In retrospect, the most successful team members shared some common traits.  They were mostly younger.  They remained positive and enthusiastic even during project travails. They were very agile, willing to change direction whenever the situation dictated.  They were able to subordinate their personal and functional goals to the project’s goal.  They treated others on the project with respect and were not into blaming others when something went wrong.  They were constantly learning and adapting their behavior as a result. They were willing to do anything to make the project successful, including working outside their functional area and working long days when necessary.

I do not know how to identify people who will not work out with an interview; perhaps others are better at that than I am.  What I do know is that poor performers disrupt team function and are intolerable over anything longer than a very short term.  One of the project manager’s most critical jobs is quelling those disruptive influences. In the next blog I will describe how I did that.


1 Collins, James Charles. Good to great: Why some companies make the leap... and others don't. Random House, 2001.

2 Terry Little is one of the co-authors of an upcoming book, Becoming A Project Leader: Blending planning, agility, resilience and collaboration to control and deliver projects in the real world, to be published in early 2017 by Palgrave Macmillan. The other co-authors are Alex Laufer, Jeff Russell and Bruce Maas. Little was the Department of Defense’s most seasoned manager of major programs, with more than 25 years’ experience leading major weapons acquisitions. Little served as executive director of the Missile Defense Agency—the senior civilian in an organization of approximately 8,000 employees—while also directing the $14 billion Kinetic Energy Interceptor Program. Previous to that, he was the first director of the Air Force Acquisition Center of Excellence. An honorary professor at the Defense Systems Management College, Little has presented case studies to every program manager class at the college for the past 15 years.

Tuesday, March 15, 2016

Clearing the Air (Part 2): Overcoming a Crisis through Trust, Agility, and Learning by Doing


(continued from Clearing the Air, part 1)

For the pilots of the Israeli Defense Force’s 109 Squadron, the early days of the 1973 Yom Kippur War did not go as planned. The invasion by Egypt and Syria was hardly a surprise attack, but the orders that were coming down from Israel's Air Force (IAF) headquarters—having the pilots fly into zones heavily defended by anti-aircraft missiles just to take out a pontoon bridge, for example—didn’t seem to make a lot of sense. No one was going to disobey those orders, but it was clear that the squadron’s leaders would have to come up with their own solutions to many of their problems.

A major problem was the Douglas A-4 Skyhawk’s tailpipe, which the enemy’s heat-seeking surface-to-air missiles were zeroing in on, thereby damaging the nearby elevator (pitch-control) cylinder, which often caused the aircraft to crash. Captain Giora Ben Dov, looking around for solutions, thought of his friend Ben Z. Bezalel, who was deputy CEO at RAFAL Advance Defense Systems, a leading defense technology company. “They have smart people over there,” Giora thought to himself at the time. “Together, we should [be able to] come up with something.”

Ben got right on it, organizing a task force that analyzed the problem as described by Giora. And one of the solutions the task force came up with was a radar countermeasure element called chaff, which, when ejected from an aircraft, forms the electromagnetic equivalent of a smoke screen, temporarily rendering an aircraft invisible to radar. Attached to the aircraft’s exterior, it was deployed from inside the cockpit using a knob on the takeoff handle that was originally designed for takeoffs from aircraft carriers. Given that the Israeli Defense Force didn’t have any aircraft carriers, the knob was available for use.

There being nothing like a war to speed up the delivery process, RAFAL had 60 units fully operational within 10 days, and these had a significant impact on the conflict’s outcome. In fact, it became standard operating procedure to deploy chaff right before ascending to assault position, when an aircraft, no longer flying low to avoid radar, was suddenly more vulnerable to enemy fire.

Problem solved? Like any leader worth his salt, Giora kept looking for more solutions. “On the downtime between missions, I went to the repair shed to check on an aircraft that had gotten hit by a Strela (anti-aircraft missile),” he says. “I remember thinking that we suffered from missiles on our tailpipes because they were hot, so why not extend the exhaust pipe and clear out the elevator cylinder so the aircraft could withstand a hit without crashing?”

Why not indeed? Giora pitched the idea to his squadron leader, Lt.-Col. Yitzhak David, who approved it right way, trusting that his team knew what it was doing. And so the first-ever modification was done in the wing itself, with local technicians and metalworkers. They used the aircraft that had been hit by a Strela, and when the modification was completed, Giora volunteered to be the test pilot to see if the aircraft could still fly. It couldn’t. During the first test—taxiing down the runway at full throttle—the external piece failed to remain attached. “I looked back,” Giora says, “and it seemed as if the aircraft had gotten hit by another Strela.” 

The test was nevertheless an incremental step in a process that continued to improve the Skyhawk’s missile resiliency even after the Yom Kippur War. And the modification to the tailpipe remains the standard for all Skyhawk aircraft to this day. It so happens that chaff is also still operational—modified from what RAFAL first came up with and not necessarily made by RAFAL these days. But the solutions that Giora and the rest of the 109 Squadron came up with changed the whole way the IAF looks at these kinds of assault maneuvers. Today’s pilots still employ the sequence developed during the early days of the Yom Kippur War.

Perhaps none of this would have happened had there not been such a strong collaborative ethos within the 109 Squadron, an ethos built on trust, not to mention friendship. Remarkably, the squadron leader, Yitzhak, so trusted Giora that Giora was allowed to pursue his project with RAFAL without any involvement from David. “I had Giora,” RAFAL’s Ben, who never met David, would later say, “and my objective was to do anything in my power to help him as a friend. If I was the deputy CEO of Osem (an Israeli food-processing company), I would have supplied the squadron with cookies.”

Gil Wang conducted the study leading to the current blog post and the previous one. Gil, a Naval Architect, is a former yacht designer and project manager at Dykstra Naval Architects, an Amsterdam-based superyachts design office. From 2006 to 2014, Gil led numerous cutting-edge projects from concept to completion. Today, he is pursuing his PhD, examining the feasibility of expanding costal cities to their adjacent maritime environment.