Team Model vs. Hierarchical Model

Most developers fondly remember the first time they saw "Hello World" displayed on their screen—an indication that their first programming effort was successful. Although many of us relish the memory of that rather simplistic achievement, the fact is that the complexities of enterprise applications and systems make them nearly unmanageable. In addition, the deployment of those applications and systems to hundreds of desktops at many different sites has significantly expanded the scope of the development process.

As we noted in Chapter 1, today's enterprise applications are too complex for any one person to grasp completely. No one can hold all the requirements, options, and design choices in mind at one time. Several people, and several minds, need to work together to hold them all. In today's enterprise environments, responsibility for application development must be assigned to a team rather than a single person.

People sometimes have difficulty adjusting to working in teams. They are expecting to know "Who's in charge?" A hierarchical model, such as an organization chart, describes who is in charge and who reports to whom. However, in today's enterprise environments, assigning a single project manager to oversee all aspects of a development project and make all critical decisions creates many points where the project could fail. The challenges of a single manager approach can include:

  • An information bottleneck.
  • Insufficient perspective to address all the project's needs.
  • Increases in miscommunication as information is filtered up the management hierarchy.
  • Difficulty in grasping the vast technical knowledge required of multiple-application platforms.
  • The overwhelming breadth of knowledge required to integrate the project with current internal systems.
  • Difficulty in prioritizing business requirements against technical requirements.
  • A single experience, which limits the ability to quickly solve problems based on historical, more broad-based experience.

In addition, communication is more difficult in organizations that adhere to strict hierarchies, which by definition imply indirect communications. A hierarchical group's communications may be "filtered" by three or four managers, thus significantly increasing the likelihood that the true message and intent will be lost. Often the greatest miscommunication occurs between upper management's vision and the actual practical work on a project, four managers removed. This miscommunication can lead to the disengagement of individuals from the project, decreased productivity, and increased likelihood of project failure.

To combat many of the difficulties with a single manager approach, a team model describes the key roles and responsibilities of a project team. No single person is in charge of the overall project. Instead, each team member is in charge of a specific role that must be performed in order for the project to be successful.

The team model does not define the management structure of the team from a personnel-administration perspective. A multi-disciplined team acquires project resources from many departments within the organization and from the organization's vendors. Project teams are specifically designed to address project goals and assign project responsibilities to different roles. The leaders of each role are responsible for executing their role's activities given the resources assigned to their part of the team. The daily management tasks they perform within the roles are specifically related to project activities, not to particular human-resource (HR) activities. The HR management of the organization's employees continues to be handled by each individual's current manager. Such activities can include compensation plans, benefits, vacations, and performance reviews. The team provides performance information about individuals to their managers but doesn't oversee the individual's adherence to employment policies.

The team approach has its challenges. Potential pitfalls that need to be understood and continually mitigated include:

  • Lack of a single point of contact for external communication.
  • An inconsistent vision applied to different aspects of the project.
  • Team members with different agendas for the project.
  • Inexperience that prevents an effective team implementation.

In this chapter, we'll look at ways to avoid these pitfalls.

Microsoft Corporation - Analyzing Requirements and Defining Solutions Architecture. MCSD Training Kit
Microsoft Corporation - Analyzing Requirements and Defining Solutions Architecture. MCSD Training Kit
Year: 1999
Pages: 182 © 2008-2017.
If you may any questions please contact us: