Project Organization

Project Organization

If your project is any larger than three or four people, you will need some kind of formal organization. As soon as you begin to plan how your project will be organized, you will be faced with two general approaches: organizing by technical function or organizing by business area.

Exhibit 4.6 illustrates a project organization by technical function, in which business analysts, systems analysts, and programmers are in separate teams.

The problem with this type of organization is that it requires numerous handoffs of material from one team to the next. When the business analysts finish a business function, they hand their specifications over to the systems analysts for design. Once the design is done, the analysts give it to the programmers to code. There are, therefore, two boundaries over which material must pass, and potentially at least one gap between groups when issues need to be resolved. This type of organization becomes even worse if the culture of the organization requires that all communication take place among the leaders of the teams. If a programmer has a question on a specification, it will be extremely hard to get it answered because of the number of people involved.

A better form of organization combines development roles into one or more teams. Exhibit 4.7 shows such a structure based on the technology differences in the project.

With this organization, all responsibility for a given technology typeon-line, batch, or interfacesresides within a single team that contains all the skills needed to develop that aspect of the system. Communication becomes easier, handoffs of material are minimized, and teams can take pride of ownership in their separate pieces of the system.

It is important to note that this structure does not restrict team assignments. People can and should be moved across teams as the

project requires. Furthermore, the integration and implementation team will probably not be assembled until late in the project, and it will consist of team members coming free from the other teams.

This type of team structure is valuable in minimizing handoffs and enhancing communication. However, when you create such a structure, you will face two potential problems: the nature of the project and the culture of the organization.

The Nature of the Project

In the above example, the project was divided into three main technology areas: on-line, batch, and interfaces. (The fourth area, integration and implementation, is a project requirement, not a specific technology.) For this particular structure, these three areas must actually exist within the project, each must be significant enough to warrant its own project team, and the boundaries between them must be clear. To illustrate the last point, suppose the project will produce a nightly batch run that produces an interface file to another system. Which group, batch or interfaces, will be responsible for this component? You will need to be prepared to make decisions that at times seem arbitrary.

There are many ways to divide up a project so that relatively independent teams can work on different pieces. Some examples:

A division by technology, as described above, assigns complete teams to various technology aspects of the project.

A division by operations splits the project into operational areas, such as file maintenance, data entry and authentication, and reporting.

A division by function separates the project into functional areas, such as accounting, inventory, and sales analysis.

The particular type of division you select is not as important as the fact that you select one and that you organize your project in a manner that provides a mix of different technical and business resources to each team.

The Culture of the Organization

Normally, clients and corporate management do not care much about the structure of projects. As long as the work gets done, the  project organization is your responsibility. However, in some companies, hierarchy is a potent force, and you may encounter resistance to combining typically junior staff, such as programmers, with more senior people, such as business or systems analysts. If you meet this resistance, recognize that it is doubly important that you create your team structure. Any negative attitudes toward groups will be exacerbated if you succumb to pressure and allow all the ''senior" people to have their own team, handing off material to other teams that they hold in some degree of contempt.

In these situations, you will need all the team-building skills (see "Building the Team" in Chapter 5) that you can muster. You will also need to be insistent that on your projects, you will decide the type of organization that will prevail.

What If?

You Take Over a Project in Progress That is Poorly Organized.

The consequences of poor organization are poor communication, distrust among teams, and errors and rework arising from mistakes in handoffs between teams.

Actions

If the project is in its early stages, reorganize it appropriately. You will probably encounter objections. Ignore them. It is your project.

If the project is well advanced, whether or not you reorganize will depend upon how well the project is performing. If it is generally on track, thank your good fortune and keep the structure intact, but be alert for problems arising from the structure.

If the project is not on track, you have probably been brought in to rescue it, in which case you have a free hand to do whatever is necessary. Reorganize the project.

When you reorganize an existing project, you are disrupting a solidly established project hierarchy. You may find that you must balance the needs of the project with the individual personalities. For example, Fred and Mary should be on the same team, but on this project, they

have come to hate each other. If you have any flexibility, there is no need to add to your problems by pairing such opponents, but if it is necessary, you have the right to say, "Resolve, bury, or repress your animosities. I do not care which, but I do expect you to work together for the benefit of this project. If you don't, I will seek to have you replaced."

The Client Expects an Organiztional Atructure That You do Not Want.

If the client seeks to impose a project structure, you face two consequences: having to operate with an inefficient structure and, more serious, having the client dictate how you will manage.

Actions

Determine the reason for the requested structure. If it is required by the client's methodology, you may have no choice, but if it is simply a matter of preference, the decision must be yours.

Discuss with the client how you want to organize the project and the advantages of your approach. Initially, you want to get the client's understanding and approval. However, if you have to insist on your structure, you will at least have reassured the client that you are acting from experience and concern for the success of the project.