This blog is produced by the Consortium for Project Leadership at the University of Wisconsin-Madison, for anyone interested in the practical application of leadership to project management. We aim to publish meaningful articles by various authors on a monthly basis focused on stories about lessons learned in leading and managing projects.

Tuesday, April 19, 2016

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 hadcomplained 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.

Co-Authors

Follow by Email

Translate

What is "Living Order"?

Embracing the "living order" concept is the first practice of project leadership. Leaders must be comfortable leading in today's environment of constant change. Bergson (1907) identified two types of order: the traditional concept of perfect geometric order, and living order -- which can be messy, even chaotic, with project problems and surprises in an evolving organization.