Upon successful completion of a four-hour exam, I received my PMI certification. But that was just the start. I then completed another, larger package of information on my project management experience. I documented several successful projects including leading the ISO 9000 qualification of IBM Printing Systems and several large software development projects. You had to provide details like management recommendations and project statistics. Finally, after obtaining approval for the package from my senior management, I was scheduled for a personal interview by a board of Project Managers. With their approval and leaping all those hurdles, I obtained my IBM Certified Project Manager certificate in May 2002.
Part of my experience came from when I was on the faculty at IBM’s Global Services Institute in Armonk, New York, and acted as a troubleshooter for IBM projects that were in difficulty. The work involved a lot of travel, and would focus my time in getting a misguided project back on track.
IBM provided many resources to assist project teams, project managers, and other assistance to get the job done for IBM and its clients. I attended special training at Harvard Business School and found the lessons key to the success of my teams and teams I consulted with and assisted.
Teamwork and collaboration are critical to achieving the mission in any organization that has to respond to changing circumstances quickly. My time as a Senior Project Manager and team leader has affirmed that idea. When I was asked to assist on a troubled project, I would look for the primary problem that the team was dealing with and suggest alternatives.
Following are a number of issues I encountered and my response to the team to produce productive collaboration. When assisting teams, I did have the dubious advantage of “I’m from Corporate, I’m here to help.” (Most will recognize that statement as one of the three biggest lies. The other two are “The check is in the mail” and “I’ll love you forever.”) They, at least, considered my input as useful advice. Didn’t always follow it, but they did listen. Here is some of what I would suggest.
In the first place, some seem to think that teamwork is magical. All you had to do to harvest its many benefits is to gather up some really talented people and tell them in general terms what is needed — the team will work out the details.
This is rarely the case. It takes careful thought and no small amount of preparation to achieve success. The best leaders I know provide a clear statement of just what the team is to accomplish, and they make sure that the team has all the resources and supports it will need to succeed. Although it may take some political maneuvering to get what is needed for effective collaboration from the larger organization, it is well worth the effort.
A mistake often made at IBM was to think that bigger is better. We used to tell our customers that, if there were a problem, we would “darken the sky with three piece suits.” (That’s a reference to the IBM uniform of long ago.) After all, don’t larger groups have more resources to apply to the problem? Plus, including representatives of all relevant stakeholders increases the chances that whatever is done will be accepted and used. Right?
Well, actually, not right! I learned that excessive team size is one of the most common — and also one of the worst — impediments to effective collaboration for the larger the group, the higher the likelihood of social loafing or free loading.
This lesson was taught to me early in my career when I was a member of a large project team. There was one engineer that did nothing for almost a year. (Projects were long in those days.) It was not obvious to the team leader because there were so many on the team. The larger the team, the more effort it takes to keep members' activities coordinated. Small teams are much more efficient — and far less frustrating to everyone involved. I operated by the guidance of “The magic number seven — give or take two.” That little phrase will have to be the subject of another note at another time.
A project manager on one team sought for the ultimate in harmony. Smooth interaction among collaborators avoids time-wasting debates about how best to proceed. Meetings are all “happy talk” and the PM would bring cookies … I’m not kidding.
Now snacks at a meeting are not wrong in and of itself, but my experience is the opposite. The team needs a dynamic where decisions are discussed and groupthink is avoided. Conflict, when well managed and focused on a team's objectives, can generate more creative solutions than one sees in conflict-free groups. So long as it is about the work itself, disagreements can be good for a team. Of course, too much conflict can be a problem too, but the willingness of the team to listen to conflicting voices is really the best. Some degree of “storming” is essential to good team dynamics.
In this modern, Internet connected, video-filled world, face-to-face interaction is unnecessary. Now that we have powerful electronic technologies for communication and coordination, teams, and especially management, think they can do their work much more efficiently … and a lot more inexpensively … at a distance.
No, no, no. This was my biggest argument with management. Teams working remotely are at a considerable disadvantage. There really are benefits to meeting up with your teammates face-to-face. If an organizations must rely heavily on distributed teams, it is best to spend the time and expense to get members together, at a minimum, when the team is launched, again around the midpoint of the team's work, and again when the work has been completed. The human and informal contact at even this limited number of meetings and get-togethers will aid the interaction that occurs at a distance.
One long project that I assisted had a constant turnover of personnel. No one seemed concerned about this and thought that new members bring energy and fresh ideas to a team. They assumed that otherwise the members would become complacent, inattentive to changes in the environment, and too forgiving of fellow members’ misbehavior.
The truth is that the longer members stay together as an intact group, the better they do. This is a lesson I’ve observed all my life; whether it is a football team or a rock band, teams that stay together longer operate more efficiently. An experienced team … experienced with each other … is the classical “well oiled machine.”
Often the Project Manager was blamed for all the issues. Management would tell me that, “If they only had a better leader,” or “Couldn’t I just take over the team and complete the project.” Even the members of the team often told me that it all depends on the leader.
But that was not my experience. Certainly the activities of group leaders do make a difference. But the most powerful thing a leader can do to foster effective collaboration is to create conditions that help members competently manage themselves. One of the best project managers I worked for spent a lot of time making sure the tasks were assigned to the correct team members and that each knew his or her responsibility. After that he spent most of his time in his office making sure our work was backed up regularly. That allowed us the freedom to try different approaches and truly solve problems creatively. We knew that, if we made a mistake, we could always go back to a previous version of our work and try again. His careful and frequent backup of the work progress served as permission for us to follow our own direction without fear of recrimination.
The key is to launch the team well. Make sure everyone knows their assignments and how their part of the work fits with the overall project. This will automatically cause the team to focus on delivery schedules and how their part of the work fits with other team member’s effort and how it all has to fit together.
Finally, a good leader provides teaching and coaching after the work is underway. Research at Harvard Business School suggests that initial condition setting accounts for about 60% of the variation in how well a team eventually performs; that the quality of the team launch accounts for another 30%; and that coaching accounts for only about 10%. Leaders are indeed important in collaborative work, but not in the ways we usually think.
I was at a serious disadvantage when I visited troubled projects because I had missed the first 90% of the most important part of the team building. All that was left to me was the 10% of real-time coaching. Still I had a positive effect. I tried to listen a lot more than talk, and that often was the solution. I spent more time suggesting changes in behavior of management and stakeholders than I did suggesting changes in the project team. I often acted as a buffer and a communication channel between the various organizations. I considered myself more like a tow truck driver. I was there to get the car out of the ditch rather than give drivers education or rebuild the road. I just didn’t have time for that. Still I thought I had a positive effect and many projects gave me credit for my assistance and appreciated my efforts … although not everyone was happy to see me. But then, at least, they were happy to see me leave.
It is often said that the School of Hard Knocks has high tuition. I spent a lot of years in the trenches learning the rules of the game (and about mixed metaphors). I was happy to share my knowledge with others … that is probably why I love teaching … and writing … so much. I never came to a troubled project with an attitude that I had all the answers. I was only there for a short time, and they had months if not years of experience with the project at hand. My goal was to help them focus more on the trees … especially the one’s in their path … when all they saw was a forest. I was there to remind them that the goal was to drain the swamp when they became too distracted by fighting the alligators. Most of the people I worked with seemed to acknowledge and appreciate my background and experience and took my advice and input gracefully and with some amount of gratitude.
While I enjoyed my time in the field providing help and advice, I was always hopping the next plane to another trouble spot, and missed the satisfaction of bringing the project to a successful conclusion. Ultimately it was all the travel and issues related to travel that forced my next career change. In 2007, when my IBM Project Manager recertification was due, I was onto a new job as the technical quality leader of an IBM division. This was a very large team and it was often like the job of herding cats, but I did get to see the final results of my efforts … or, more accurately … the final results of the team efforts.
No comments:
Post a Comment