Ads
  

Working Together Requires a Framework

Working Together Requires a Framework

A team can sing at the same time but not talk at the same time. The difference is a common sheet of music. This is the framework provided by project management competencies.

The project leader must read the team's collective personality, select an appropriate infrastructure suitable for it, and maintain its rhythm throughout the project. It should become part of the group's standard. Following the methodology becomes a group rule that spans cultures and personalities, and serves as a foundation for regrouping if (or when) the team falls back to the storming stage and some of the jell melts.

Communication and Team Size

Most of the causes of teamicide are under the control of a project leader. Team size in relation to the project size (see Table 1), if unsuitable for the task, may contribute to teamicide. This is a result of the mythical man-month phenomenon explained in Fred Brooks 1975 classic The Mythical Man-Month. Note that a staff month is generally explained as 40 hours of effort, which may be spread over a period of time that is less than or, more frequently, more than a calendar month.

Project Team Sizes

What works for a small project with a small team may not scale to a medium or large project. Certain economies and characteristics of team personality are mainly dependent on team size. Two of the most important are communication and dispersion.

Team Communication

Communication among the team members is essential to the accomplishment of the project's tasks. To avoid teamicide, everyone, managers and team members alike, must attempt to use the preferred channel of communication to transmit information so that the receiver can truly hear the message. Preferred communications channels for Kahler's PCM are shown in Table 2. You maybe don't want to say to a reactor, "I don't care how you feel about it, you must take the lead to improve the bottom line".

Preferred Channel for Communication

Other communication issues within a project leader's control are bureaucracy and clique repression. Bureaucracy involves too much overhead for the communications channel. Cliques are "clubby" groups of people who create exclusive subgroups within a team. Cliques cause information separation.

As the team size grows, the number of two-way communications paths increases rapidly according to the formula,



where n is the number of participating team members, producing the rapidly rising curve in Figure (a).

Communications Paths Growth

This creates overhead in the form of bureaucracy and increases the potential for error and misunderstanding (particularly when the team members native languages are not the same).

For instance, the number of communication paths in various-size projects that we looked at previously gets complicated very quickly (see Table 3). For illustration, very large projects of 50 people or more (typically a program) are also shown.

Example Communications Paths

As team size grows, the trend for cliques to form goes up, frequently around geographic centers. This phenomenon is why the leader must provide a strong framework for the team to operate within. Even simple things such as providing a common team glossary help greatly. The project leader must decide how much communication is enough and when it is too much.

Those personalities in the project team that need structure, ritual, and direction (e.g., PCM: dreamers, promoters; MBTI: SPs; Keirsey: guardian SJs) will want them more than the independents and rebels of the group. The People Capability Maturity Model (P-CMM), from the Software Engineering Institute is a framework to start with, but the project leader must sensibly adopt only the procedures that fit the team and project size, to minimize communication errors.

A useful tool from the P-CMM set is the Functional Responsibility Matrix, shown in Figure (b).

Functional Responsibility Matrix

The Functional Responsibility Matrix defines the boundaries between members responsibilities for different project tasks. Almost all personality models comprehend boundary infractions because humans are, by nature, territorial. Territorial issues are a basic cause for team disharmony as they touch deep-rooted personality traits in many of the models.

The leader must also collect and present information in a way that is compatible with the members and the team's personality. This is where understanding group dynamics and personality type is very important. If there is too much bureaucracy and too many cliques, then even the most patient of teams will rebel.

Team Dispersion

The management of a project team is much more difficult when it is geographically dispersed. Both distance apart and time zones around the globe affect the dynamics of team interactions.

Geography Issues

Communication and dispersion are the limiting realities for any work team spread over a wide physical area, where the team members will not likely interact face-to-face. This is because most of the team interaction models think that team members are physically close and can use all their senses to detect the useful individual personality clues of other team members. Telecommunications technologies such as conference calls, videoconferencing, and email help but are not good substitutes for face-to-face interaction and full-body communication. The project manager must create a team environment with whatever is available.

If at all possible, at least one face-to-face team meeting should take place at the beginning, and another one should take place at the end of a project. The preliminary meeting sets the style and form for future interpersonal interactions that will span the middle part of the project's life cycle. This is critical in the early stages of a project, when understanding of the project's requirements is growing. The last meeting will provide the closure necessary to minimize personal emotional baggage moving to the next project (as well as considerably enhance the post-project metrics collection activities).

Time Considerations

Time shifts are an important issue as well. All teams require both asynchronous (done alone without coordination with other team members) and synchronous (done together in time and place) tasks.

When team members are geographically scattered, a mutually agreeable time and place for synchronous tasks must be chosen. Most often, this is the project leader's home location and time zone, but there is great advantage to rotating this parameter of a project's infrastructure. If moved to other team members locations or times, cross-cultural sharing is increased, burdens of travel or inconvenience are shared, and everyone reaches a deeper level of team personality understanding.

Structure and Ritual

This is the engine of a project. It is the framework to which the team personalities will react and anchor. Without it, misinterpretations and confusion begin to spread like wildfire.

Provide a Strong Framework

One of the most important things a leader can do is to set up a project office as a hub of information about the project. This is where the P-CMM project documents can reside, along with the working documents of the team. A project office is a concept, not necessarily a physical place. A decentralized project office is most common, but not best. It means that documents and tools are geographically scattered into different team members control. It is generally characterized by much emailing of documents and files, with not all team members sharing common platforms and software. This leads to territoriality and configuration management issues. A decentralized project office is represented in Figure (c).

Decentralized Project Office

A centralized project office is a concept of commonality and colocation. It may involve only one geographic location under one team member's control; be a physical space such as a project lab, conference room, or office; or be a virtual space on a remote system. Figure (d) shows the centralized project office concept.

Centralized Project Office

At a minimum, the project office should include the charter and statement of work for the team. A schedule for work tasks is generally required, but the level of detail varies with the size and scope of the project. The functional responsibility matrix is also a good tool to keep centralized when the project and team size is medium to large, or if the small team has serious personality issues (territoriality).

Practice Rituals

Our lives are ruled by small rituals that we've learned since birth, such as our eating and sleeping habits, our home and work processes, and our social interactions. These provide a "comfort zone" for us in which to deal with the uncertainties that we encounter every day. Abraham Maslow said that without the basics under control, we find it harder to realize our full potential and work on team problems.

For project teams, this means that a regular schedule of exchanges (the synchronous part of projects) and "free" time (the unstructured part set aside for individual task accomplishment) is required. The leader must define this pattern and communicate it to the team as early in the project as possible. Daily expectations must be set for each individual to follow, or they will begin to drift apart as a team.

Peoplework, Not Paperwork

The amount of framework to provide for a given project is a matter of judgment for the team leader. Too much becomes stifling, but not enough encourages out-of-control behavior. The best guidance for this is to leverage the experience of practicing project professionals.



Tags

teamicide, cliques, project manager, life cycle, project lab
The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.
Copyright 2017 SPMInfoBlog.
Designed by TechPlus