TEAM BUILDING AND TEAM INTERACTIONS
6.3 BUILDING THE PROJECT TEAM
Team building and being part of a team are critical issues in project and systems engineering management. Teams, however, do not spontaneously appear; they must be built. As suggested before, a prerequisite to team building is to follow the communication “rules” identified in Exhibit 6.1. These are necessary but not sufficient conditions for building an effective team.
We see, in various parts of our lives, numerous real-world examples of team building and lack thereof. Perhaps three examples stand out and are visible, at least in part, to the population at large. One has to do with the President of this country. We can track, through impressions obtained in the newspapers, how the President has built a team and the extent to which bridges have, or have not, been built to the Congress. This is a massive team-building undertaking and context, and the more successful Presidents have been broad and inclusive in their interpretation of the team that must be built. Another example is that of a coach of a football team. Some coaches appear, year after year, to get the best out of the talents present in the members of the team. Indeed, one measure of the success of a team is precisely whether all team members are doing the best they can do. When this is achieved, even if the team does not win every game, there is a strong and positive sense of team effort and achievement along with strong ties and camaraderie between team members as well as the coach. Thus, team building and coaching are very similar. The effective team builder must be a good coach. Finally, most of us are part of some type of team in our work environments. We thus can observe team interactions in that context, whether we are teachers, engineers, administrators, middle managers, or members of the board of directors of a corporation.
We now identify ten specific suggestions for building a project team, as listed in Exhibit 6.2 and discussed in what follows. Following these sugges- tions, together with those provided in the previous chapter, will likely lead to a strong and effective team operation.
Exhibit 6.2: Suggestions for Building a Project Team
1. Develop and maintain a personal plan for team building and operation.
2. Hold both periodic and special team meetings.
3. Clarify missions, goals, and roles.
4. Run the team in a participative, possibly consensual, manner.
5. Involve the team in situation analysis and problem solving.
6. Give credit to active, positive team members and contributions.
7. Assure team efficiency and productivity.
8. Obtain feedback from team members.
9. Integrate, coordinate, facilitate, and assure information flow.
10. Maintain effective communication.
6.3.1 Personal Plan
The team leader (PM, CSE, PC, and others) must always maintain an explicit level of consciousness about the team and how it is performing. This can take the form of an informal plan that reflects a continuous assessment of team behavior and operation as well as what might be done to bring about improvements. After each meeting of the team, the leader should evaluate what happened and determine whether some type of fine-tuning is necessary.
Running a team should not be taken for granted. It requires constant adjust- ment to assure that the team, and the leader, have not fallen into bad habits and ineffective operation. The team has to be continuously stimulated to do its best.
6.3.2 Periodic and Special Team Meetings
The usual forum for team operation is a meeting of one type or another.
Ground rules for running a meeting are considered in more detail later in this chapter. Here we simply note the requirement for both periodic as well as special meetings. Periodic meetings are necessary to maintain continuity and, depending on the project, can be held weekly, biweekly or monthly. They should be on the calendars of all participants so that other work pressures do not interfere. They should start on time and respect the fact that team members cannot spend all their time at meetings. Special team meetings are called in response to unique situations that may arise. Usually, they are necessary when an unusual and time-critical problem has unexpectedly surfaced, calling for a problem-solving response by the team.
6.3.3 Missions, Goals, and Roles
The team leader has the responsibility to clarify the overall mission of the team, the specific goals that are to be achieved, and the roles of the various team members. In a project context, these are often well known because, as a minimum, they are articulated implicitly in the project plan. The team may also be a “task force” within the project team, whose job it is to solve a particular problem. For example, such a team may be given the charter to maximize the effectiveness of interactions between the project team and the external interfaces with other entities or departments in the corporate enterprise (accounting, finance, contracts, human resources, graphics, etc.).
Failure to be clear about missions, goals, and roles usually leads to confusion, thrashing, and less than a positive attitude from team members.
6.3.4 Participation and Consensual Operation
As a minimum, the team leader should adopt a style of participative man- agement of a team. This implies full involvement of all team members in the process as well as in the products of the team. Those members who are
laid-back should be encouraged to participate and bring their thoughts and ideas to the forefront. Lack of participation can be a signal of some type of dysfunction in the team; the leader should be particularly sensitive to the non-participating team member, following up with one-on-one conversations to see if there is some type of problem lurking in the background. The full- participation team is very likely to be a high achiever with solid relationships between team members and the leader.
In just about all participative team operations, it should be recognized that although there is strong participation in all processes, the team leader usually takes responsibility for all key decisions. This means that participation does not imply majority rule. In a project situation, the PM does not normally take a literal “note” and then automatically go with the majority. Indeed, the PM may disagree with the majority and therefore may make a decision that is a minority decision. Such are the vagaries of managing a project. In addition, all team members must be aware of and accept the prerogative of management in terms of the final decision, and once it is made, must use their best efforts to implement that decision. There is no room for the team member who undermines the team leader’s decision, whether or not he or she agrees with it. If the team member cannot ultimately support a PM’s decision, the next step is to leave the project team.
Participative operation, however, is not the same as consensual operation.
More precisely, the latter can be interpreted as team agreement on a course of action, but without an explicit vote of the team members [6.1]. Consensual operation of a team is very desirable but not always possible. Most decisions, for a good team, turn out to be consensual. However, the leader should reserve the right, for a particularly contentious situation, to both take a vote (show of hands) and to make a decision that is contrary to the majority viewpoint.
6.3.5 Situation Analysis and Problem Solving
In Chapter 4, we introduced the notion and specific steps of situation analysis.
Its purpose is to examine difficult situations that inevitably arise during the course of a project and, through a team dynamic, develop a solution. The team, in many ways, is the centerpiece of both situation analysis and problem solving. The PM or the CSE may have well-developed ideas as to the nature of a problem as well as its solution, but it is critical to obtain the ideas and inputs from other key team members who may be able to suggest answers that may not have been considered. In short, many people working constructively on a problem usually leads to better problem solving both immediately and over the long run.
6.3.6 Give Credit
Give credit to team members that make a contribution; this is a very important part of team building. This can be achieved in many ways—from a pat on shoulder to a formal acknowledgment at a team meeting. This works wonders
because everyone has a basic need to feel appreciated. If this can be done in public, so much the better.
6.3.7 Assure Efficiency and Productivity
A PM with excellent team-building skills will nonetheless fail unless the team is being productive. This means making progress in accordance with the project plan as well as being efficient in the use of everyone’s time at all team meetings. It also means that the PM must know when it is time to stop beating a problem to death and move on to a solution or to the next issue or, indeed, to call a meeting to a close. Experience suggests that many team members become frustrated with long meetings that drone on and on and would prefer crisp, effective interactions that support a sense of accomplishment for all that are present.
6.3.8 Obtain Feedback
Feedback about the team and its operation should be sought from all team members, preferably through one-on-one sessions. Team members with prob- lems with the team may be wary about expressing their views to all. By means of a supportive private discussion, team members can provide feedback and will understand that their inputs are being valued and serve as a contribution to the team. Some may have an issue with another team member that may be addressed through such private feedback sessions. It is yet another way for the PM to convey the message that this person is valued as an individual and as part of the team.
6.3.9 Integrate, Coordinate, and Facilitate
The PM and CSE do not have all the answers, nor do they possess all of the wisdom on a project. Adopting a position as integrator, coordinator, and fa- cilitator normally pays great dividends in terms of overall team effectiveness.
This may appear to be a passive role, but actually it can be exercised in a rather active manner. It also goes along with the notion of empowerment. The job of the team leader is not to do all the work, but rather to assure that the best efforts of all team members are brought out.
6.3.10 Communicate
The previous section and Exhibit 6.1 summarize a dozen key points with respect to communication. Remember, even if the PM is well-skilled at all the nuts and bolts of project management, the project is likely to fail, and a team not likely to be built, without effective communications. This is perhaps the most important single message in all of the fine art of management.
6.3.11 Additional Points on Team Building
Teams are formed in contexts other than that of a formal project as described here. There are other types of teams, such as quality circle teams, integrated product teams, concurrent engineering teams, task force teams, and others.
The key point is that the earlier discussion applies to all these various types of teams, and that the required skills are more or less the same. Learning the basics of team building, therefore, is worthwhile whether or not you now serve as a PM or CSE. Sooner or later you will be part of a team and perhaps sooner than you think you will be asked to build and run a team effort.
We also note that in the presentation of the subject of leadership in the pre- vious chapter, the third most important attribute of a leader was cooperating, sharing, team building, and team playing. To be a leader, then, is to know how to build a team. Conversely, and categorically, to not know how to build a team is to not be a leader.
There is an endless supply of literature on the critical subject of team building, including entire books, courses, videotapes, and magazine articles.
For the reader interested in pursuing this matter beyond the suggested essential steps cited in Exhibit 6.2, reference is made here to the Harvard Business Review and several additional sources [6.2, 6.3, 6.4, 6.5]. Effort put into building a strong, effective, and productive team will pay large dividends for both the Project Manager and the Chief Systems Engineer.