Project Management Structures

The way a project team is structured can play a major role in how it functions. Different styles of teams will have different characteristics. For example, do we wish to encourage discussion with the business representatives or to keep them at arm's length, so the developers can make good progress? Careful consideration of team composition and reporting relationships can make a big difference in the results.

The various roles in the team will depend on the nature of the project. As well as the main team roles, consider the other participants and how they fit into the picture.

Project roles and resources will have been identified as part of the planning, estimating and resourcing process. Note that the resources and optimum way of working will normally change during the project. Often an initial high-powered team will define the business solution, followed by a much broader team to deliver it, and then a line management and operational team to operate it. The will be a core team who remains fully involved throughout the project, but others will need to be brought in as required.

The team structure will probably be adjusted at each stage to meet the evolving nature of the project. The right structure for a small, high-powered, business-design team is unlikely to work for a large applications development team.

Styles of Team

There are two main structural dimensions of the project team:

• What type of resource?
• What are they delivering?

For example, a website designer might be working with business managers and network specialists to create a storefront whilst another website designer is working with different business managers but maybe the same network specialist on an Intranet application for presenting internal management information on sales - both as part of the same project. So, does it make sense to have a team of developers, a team of managers and a team of network specialists, or should we have a team for the storefront and a team for the management information system?

Rather than seeing this as an "either-or" choice, we could think of the project team as a matrix. Members of the various resource-type teams will need to work together to share knowledge and ensure a consistent solution. People working together on the various processes or functional aspects of the solution will equally need to work together.

Each of these sub-teams, whether horizontal or vertical, will need a recognised leader. Team members will need to understand their individual roles.

The question then becomes how to structure this in terms of reporting and control.

Here are some basic rules that may help you decide how to structure the teams:

People working together in a team usually see their teammates as "being on their side". They will normally work together and help each other to achieve their collective goals.

Placing people in the same team generates collaboration, knowledge sharing and skills transfer - for example, between the specialists in a software package and the key future users of that package.

Building a good, effective team is vital - team structure will influence the way the team behaves. Aim to create a collaborative team, where individuals share knowledge, cooperate, support each other and are motivated to achieve the team's goals.

Interaction between team members is the best way to get a balanced view of all perspectives, e.g. business needs, practicality, technical feasibility, efficiency, and performance.

The understanding, knowledge, and capabilities of people working in other teams are rarely exploited to the full.

People working in other teams are often viewed as a nuisance - they interfere with our team's progress.

According to the complexity theory, putting a large number of people into a single team creates more interplay than progress.