Team Organization

Team Organization

Over the years, Perry has seen the symptoms of poor team organization. Some projects have too many leaders, leaving only a few people to do the work and making coordination difficult. Other projects have too many layers of management, impeding effective communication; team members become frustrated, waiting for all the leaders to reach agreement or gain approvals. To augment frustration levels, tasks frequently are unclear, lacking definitions of roles and responsibilities.

Good organization makes sense; yet project managers often give too little attention to organizing their group. Frequently, teams are an assembly of people and nothing more. Some project managers fear alienating people by setting up a project organization. Others lack an appreciation for its contribution to project success. Still others have a preference for an unofficial organizational structure.

Through the function of organization, Perry can realize many advantages. His team can operate more efficiently, since responsibilities and reporting relationships will be clearly defined. It can operate more effectively, because each person will know what is expected of him or her. The team has higher morale, because roles and reporting relationships will be clear which in turn reduces the opportunities for conflict.

Ten Prerequisites for Effective Organization

Perry must satisfy some preliminary requirements to build a formal organization, especially one that handles medium to large projects like his:

He must know the project goals. This knowledge will help to determine how to best arrange his resources.

He must know all the players. This knowledge will help him to determine who will support him directly and who will provide ad hoc support.

He must understand the political climate. Although the team may be temporary, the project may be around for a long time.

He must receive preliminary concurrence on the project organization from all the major players (e.g., senior management, customers).

He must determine the appropriate span of control. This means determining how many people he can effectively manage before establishing an additional layer of management (e.g., appointing team leaders).

He must publish the organization chart as early as possible. This action will clarify roles early and reduce the opportunity for conflict. It will also make assigning responsibilities easier.

He must consider how much autonomy to grant people on the project. This will depend on how much control he wants to maintain. If he wants tight control, he will limit the autonomy he grants to project participants.

He must consider issues of authority, responsibility, and accountability. How much authority will he have and how much can he grant? How much responsibility can he relinquish and still be accountable for the results?

He must consider how to group the functions of the project team. Should he mix them or segregate them? If the latter, how will he encourage information sharing, communication, and teaming?

He must identify the line and staff functions. The goal of the project will help determine the positions. Line functions contribute directly to the results; these are typically people on the core team. Staff functions do not contribute directly to the results and ordinarily they are not part of the core team.

Types of Organizational Structure

There are two basic types of organizational structures for a project: task force and matrix. The task force structure is shown in Exhibit 10-1.

The task force is a group of people assembled to complete a specific goal. The team is completely focused on that goal and, consequently, devotes its entire energies to its accomplishment. By its very nature, task forces are temporary; the team is disassembled once the goal is accomplished. It also usually operates autonomously, with its own budget and authority.

The task force has the advantage of giving visibility to a project. It isolates team members from organizational myopia and frees them from daily administrivia. It enables creativity and experimentation within the confines of the goal and scope of the project.

Despite these advantages, Perry does not like the task force structure, at least for the Smythe Project. Since a task force would last for only a fixed duration, theres a danger that few people would have loyalty to the project and stay the course. As the project experiences difficulties, some people might depart early, leaving it vulnerable to schedule slippages and lapses in quality.

Exhibit 10-1. Task force structure.

As the project grows, too, it can become too independent, stealing people from other projects. Other organizations and projects are robbed of badly needed expertise. As a project ends, the task force may experience severe morale problems, as people scramble for new jobs before completing their responsibilities. It is not uncommon for a project to experience lapses in quality as a result.

Keeping these shortcomings in mind, Perry agrees with his boss that a matrix structure is best for the Smythe Project. A matrix structure obtains resources from functional organizations and also shares those people with other projects. For command and control purposes, people report to their functional managers but support one or more project managers. A generic matrix structure is shown in Exhibit 10-2 and the one for the Smythe wedding is shown in Exhibit 10-3.

The matrix structure offers several advantages. It allows for sharing people with heavy expertise among several projects. People dont need to look for a new job as the project concludes. The project manager can acquire people with the right skills at the right time, thereby reducing the need to keep people on when they are not needed; this helps keep the cost lower. The matrix structure also gives senior management flexibility in changing the scope or stopping the project owing to different market conditions.

Perry realizes, though, that a matrix structure presents challenges. It makes planning difficult, especially if projects are sharing resources. Often, he must negotiate with functional and other managers to obtain peoples help.

Exhibit 10-2. Matrix structure.

A matrix structure can wreak havoc on morale, too. Team members on multiple projects may be forced to determine which project to give attention to. Sometimes the competition is so keen that individuals become pawns in a power struggle among functional and project managers. That struggle can last a long time, adding to team angst. Finally, the matrix structure often violates the unity-of-command principle (a single superior to whom subordinates report).

To tackle these challenges, Perry recognizes the stress a matrix structure places on team members. He will coordinate closely with functional and other project managers to facilitate availability and try to integrate his project with other projects. He will encourage greater communication, information sharing, and bonding. Finally, he will stress flexibility; change is a way of life in the matrix environment, since priorities and resource availabilities constantly change.

Virtual Teams

Recent advances in information systems have brought unparalleled changes to business, not just technically but also in managing projects. These changes include e-mail, the Internet, groupware, and client-server technology. Technologies such as these have enabled team members to work autonomously at remote locations during all time periods (e.g., mornings, evenings). But a project team may never meet face-to-face with some people and will only interact electronically. That is the nature of virtual teams.

There are many advantages to a virtual team. It reduces the need for expensive facilities. Team members feel greater freedom, working with less supervision. A side benefit is a flatter organization chart, too.

Exhibit 10-3. Organization chart reflecting matrix structure of Smythe Project.

While sounding like a dream come true, reality may provide a different picture. Virtual teams can pose tough challenges. The first is how to provide support for these virtual team members. There are issues concerning hardware and software, plus administrative matters such as accessibility to the project library and ways of collecting information nonelectronically.

Second is how to overcome the purported loneliness that affects some virtual team members. Many work alone, in remote geographical locations. Their opportunities for social interaction and camaraderie are limited.

Third is the challenge of coordinating the activities of team members. With members geographically dispersed and in different time zones, coordination can be a nightmare. Since oversight is difficult, project managers cannot closely monitor work. Similarly, communication usually involves more than e-mail. There must be a way to discuss major project activities.

Some ways to handle these challenges include:

Conducting frequent face-to-face meetings and holding social gatherings

Developing objective ways to measure performance and completion criteria

Empowering people to assume responsibility and accountability for results

Establishing time commitments for team members to respond to each other

Providing a standard suite of hardware and software tools

SWAT Teams

Special Weapons and Tactics (SWAT) teams are a growing presence in project management. These are small groups of individuals who are experts not just in project management but also in other subjects. In the sense that their objective is to move quickly to complete their mission and pull out, these groups are like the police SWAT teams from which they get their name. Specifically, a project SWAT team must quickly set up the appropriate project management and technical disciplines at the beginning of a project. Once the disciplines have been established, the team relinquishes control to a project manager and his group, who are responsible for completing the project.

SWAT team work is intense. By the time its work is completed, it will have developed and implemented a complete project plan, from estimates to schedules.

Although hard skills (e.g., expertise with software and hardware) are important, soft skills are important, too. For example, SWAT team members must solicit buy-in for their work. Active listening, facilitation, communication, and teaming skills are extremely important. Also important is the ability to keep calm under pressure and a willingness to share equipment, expertise, or information.

To use SWAT teams effectively:

Obtain support for the work of a SWAT team by follow-on teleconferencing sessions; otherwise, the teams effort will be wasted.

Be aware that working on a SWAT team can cause burnout. Morale and energy levels can plummet.

Provide constant training for SWAT team members. They must keep abreast of technologies in order to provide state-of-the-art expertise. Cross-training can help, but only so far.

Select people for the SWAT team who can handle ambiguity. Members must be willing to tackle projects when goals and deliverables are ill defined.

Self-Directed Work Teams

In recent years, a different approach to building teams has emerged, called a Self-Directed Work Team (SDWT).

SDWTs are teams that have considerable autonomy while building a product or delivering a service. It is a group of professionals sharing responsibility for results.

These teams are cross-functional, meaning that people with different disciplines and backgrounds work together to achieve a common goal. The team decides everything, from setting priorities to allocating resources. Other actions include selecting people, evaluating performance, and improving processes. The key characteristic is the autonomy to make decisions without supervisory approval.

Several trends are pushing toward the SDWT concept because these teams:

Create flatter organizations

Empower employees

Encourage greater teaming

Encourage people to have a more general background

Enlarge spans of control

SDWTs are excellent candidates for applying project management ideas. Since the entire team is responsible for the results, all members must help lead, define, plan, organize, control, and close the project. The tools and techniques of project management enable teams to do that.

Questions for Getting Started

Did you determine whether your project organization has or should have a task force or matrix structure?

Regardless of the type, did you consider the following when organizing the team:

Accountability issues?

Authority issues?

Basis for grouping functions?

Concurrence from the right people?

Level of autonomy for team members?

Players?

Political climate?

Project goals?

Responsibility issues?

Span of control?

When to publish the organization chart?

Which are the line and which are the staff functions?

If a task force structure, what can you do to deal with its shortcomings (e.g., decline in loyalty)?

If a matrix structure, what can you do to deal with its shortcomings (e.g., competition among projects for key people)?

If you have a virtual team, even partially, how will you deal with the challenges (e.g., ongoing technical support) often associated with such teams?

If you have a SWAT team, how will you overcome the challenges (e.g., burnout) often associated with such teams?