For successful completion of a project, an efficient and effective team is a must. Even though the individual engineers and programmers are excellent technical people, if the team formation is not correct, it may lead to many difficulties. We will discuss the various team structures and their pros and cons.
Requirements of a Team Structure
The project manager, to start with, has to identify the individuals who will work on a project. Selection of technically competent individuals is not enough. All of them should have the aptitude to work as a team. Lack of team spirit amongst the team members would lead to many hardships and the progress is jeopardized. The project manager has to form the team in such a way that
• There will be no communication gap between the team members.
• Technical/administrative issues can be resolved through effective and
fast decision-making.
• Monitoring of the progress will be effective and
• If the personnel leave the project mid-way, there will be minimal
impact on the project.
The team structures are:
> Democratic team or ego-less team
> Hierarchical team
> Controlled decentralized team
> Single person ‘army’
Democratic Team or Ego-less Team
• All major decisions are arrived at by discussion amongst all the
members and through consensus.
• Regular communication amongst the members.
• The senior-most person can act as the coordinator who will interface
with the client for all administrative and managerial work.
This team structure appears deceptively attractive. Since all the team members will have equal say on any issue, generally issues do not get resolved if there are divergent views. Consider a simple example: for a project, which programming language has to be used? Invariably, it is very difficult to make two persons agree on a programming language (a programming language is like a religion!). In such cases, there should be one person who has the authority to take a decision (may be controversial) so that time is not wasted arguing technical merits and demerits. Another problem with this team structure is that as the number of persons in the team increases, the communication paths also increase and lack of communication amongst some members may lead to problems. In large or complex projects, priorities need to be set, and if there is no single person with responsibility and authority, then it would become a very difficult exercise.
This structure is good for research projects without time constraints, but not for projects which involve strict deadlines. It would be suicidal if this type of team structure is followed for commercial projects involving strict deadlines.
In this team, the structure will be hierarchical as shown in Fig. 2. The characteristics of this structure are:
• There will be a Project Manager who is responsible for all the project
activities.
• There will be a number of Project Leaders who will report to the
Project Manager.
• There will be a number of engineers/programmers who will report to
different Project Leaders.
• The Project Manager will co-ordinate with all the Project Leaders so
that the inter-group issues can be resolved.
For large development projects, this will be the most suitable team structure. Similar to the way the software is divided into modules, and each module into units, the team can be structured. Each project leader can be made responsible for one module and the Project Manager will coordinate the system integration.
This team structure has the disadvantage that a very dynamic and dedicated senior person is required to manage the project. If he/she leaves the organization in the middle of a project, the project is doomed. It is difficult to keep a backup person at that level even.
• Each project leader will have a number of engineers (or programmers)
and this team acts as an ego-less team. All decisions related to this
group are taken collectively.
• All project leaders report to the Project Manager.
• The Project Manager is responsible for decision-making.
• One senior project leader acts as a backup Project Manager.
This team structure is a combination of ego-less team and the hierarchical team (with one level hierarchy). This structure is good for large projects with well-knit small teams of engineers to work on specific modules.
One Person Army
The management sometimes needs to consider seriously putting just a one-man team to work on a project. To work on leading edge technologies and create a good prototype of a product, it would be ideal to assign that job to one person and provide him/her all the infrastructure, support and freedom to give vent to his/her creativity to deliver the product.
This ‘team structure’ (Fig. 4) would be ideal for creating new innovative products. Many programming languages, operating systems, application software packages were developed by single persons.
The one-person armies would do wonders to create very high-end prototypes of products. After the product concept is proven, a team of considerable size can be put in place to make the production version of the product.
Such one-person teams may not follow any regular software engineering standards, and the freedom should be given to him/her on the approach to be followed for the development. The manager has to do an informal review to know the status of the project periodically.
The Rules of the Team Game
The project team has to carry on with their development work with a focus. Surprisingly, it does not happen. Particularly in small organizations, which do not follow any
processes, the people are shuffled from one project to another; new persons are inducted in the middle and so on. There are no formal meetings to review and monitor the progress and productivity. The project manager and the team members have to follow the ‘rules’ given below to ensure that the project is executed smoothly:
• During the planning stage, the team has to be formed and the team
structure has to be decided.
• Once the team is formed, the team members need to be trained on the
necessary software tools, application domain, quality standards to be
followed etc.
• Each team member has to be given a defined responsibility with clear
goals and time frames.
• The project manager has to discuss the total project plan with the team
members, on both technical and managerial aspects.
• The team members have to be informed of the deliverables of the
project, the development life cycle model, the execution model and the
details of the client.
• The project manager has to make it very clear regarding his/her
authorities in decision-making, and also inform the team members
about the mechanism to be followed for interaction with the client.
• The project manager should not assign any other work to the team
members and should make them stay focused on the job assigned to
them.
• The project manager has to make the team members carry out peer
reviews periodically. The team members should review the
specifications, design, source code, test results etc. amongst
themselves and report the results to the project manager.
• The project manager has to conduct periodic reviews and ensure that
the decisions taken in the review meetings are implemented.
• In addition to the formal planned review meetings, event-driven
reviews need to be conducted. The team members should be informed
that in case any issue needs immediate attention, it should be brought
to the notice of the project manager.
• The team members must communicate to the project managers all the
issues related to the implementation—risk items foreseen, difficulties
encountered, commitments that cannot be fulfilled etc.
• The team members must follow the professional code of ethics (which
will be discussed later).
The project manager has to create a team which works in unison, enjoys the work and delivers a quality product on time. In the software industry, the software projects are highly demanding and people have to work long hours under pressure. It is the project manager’s responsibility to keep the team members in high spirits and get the best out of them to ensure that the project is a success.
