A FEW WORDS ABOUT TEAMWORK

The underlying reasons for the increasing emphasis on teamwork in product development are:

• to get products to market faster
• to reduce costs
• to improve quality

In the traditional serial product development process, people in different departments would work one after the other on successive phases of the development. Usually this was a slow, costly and low-quality approach, leading to large numbers of engineering changes and a product that was less competitive than desired.

Today, many companies use a Concurrent (or Simultaneous) Engineering approach in which product developers from different functions work in parallel. In this context a team is made up of a group of representatives from several functions who work together, sharing information and knowledge, and producing better results faster than they would have done if operating in serial mode.

By using multi-functional development teams, a wider range of design and process knowledge from throughout the organization can be focused on the product development objectives. Team members may come from many functions such as marketing, design, service, manufacturing engineering, test, quality and purchasing. Often key suppliers are included in the team.

The team involved in the early development of a product has a great influence on the product's costs and quality. When multi-functional teams are used in the early stage of a product's development, their composite knowledge of design, materials, manufacturing, quality, and customer requirements can be applied to develop the best definition of the product and its manufacturing, support and disposal processes.

Teamwork is a new concept for many companies. It is a step in the unknown, requiring people to think differently, to behave differently, take decisions differently, and be measured differently. Although such change can be difficult to implement, the potential benefits are great. If teamwork can be made to work, it can lead to much better and faster product development.

The improved communication resulting from team membership helps reduce changes to specifications. Cross-training has the same effect. As people understand better how other functions work, they are less likely to create problems for downstream functions. The reduction in changes results in less rework and in a reduction in the overall product development cycle. The reduction in the development cycle usually also results in a reduction in the number of development hours. This has a direct effect in reducing development costs. The team approach also tends to prevent development cost overrun as it focuses attention on the early identification and resolution of problems. Teams are hierarchically almost flat. Removal of layers of middle managers from the development process will also reduce development costs. The team approach can also improve product quality. The early involvement of downstream functions reduces the risk of potential problems. Within the team, all functions are supposed to be equal, so there is less chance of one function being completely out of touch with customer requirements yet having the political strength to force its views on the other functions.

As with all attempts to change the existing environment, teamwork can be difficult to implement. Representatives of some departments will not want to see themselves at the same hierarchical level in the team as representatives of other departments. Some managers will not want to lose their titles. Some people work best as individuals and not as members of a team. Some people can not adapt to playing different roles as the development process progresses. The procedures used for the serial product development process can not be used by the team, so new procedures must be developed. Some people may have spent many years making themselves as invisible as possible within the organization, and may not appreciate being expected to play a visible role within a team. Some people within the team may see no benefit for themselves from team participation, and may try to destroy the team. Many people in the team will fear the unknown -teamwork is unfamiliar to most organizations. People will fear that they could be punished, or that their remuneration could be reduced, because of poor performance by other team members. Some people outside the team may also try to destroy it if they see teamwork as a threat to their job, position, hierarchical position, power or remuneration.

A lot of effort will have to be put into making teamwork succeed. Suitable training is essential. Team members will need to learn the techniques that teams use for team-building, problem-solving, decision-making, resolving conflicts, meeting productively, and encouraging and helping each other. The team needs to share a vision of what it is trying, as a group, to achieve. Within this vision, the aspirations of individuals must be respected. People who have always worked as individuals or with other specialists from their own department may find it very difficult to learn how to behave as a team member.

In addition to the team's own efforts, there must be strong support from management. In practice this may not be enough. Management resources are not unlimited. Only a certain amount of management time can be allocated to each activity. Often it appears that management will support a team through its first project and then assume that no more support is needed. Unfortunately, the team generally finds that the second project is the most difficult. Much of the initial enthusiasm will have disappeared, not all the extra efforts that were made for the first project will be made for its successor. The enemies of teamwork will have had time to identify its weaknesses and position themselves for the next attack.

To ensure that these forces of destruction do not triumph, management must institutionalize the team concept - it must adapt the company's organizational structures and procedures so that the team, rather than the functional department becomes the primary organizational entity. If management does not do this it is implicitly admitting that teamwork is not important, and that teamwork does not respond effectively to business requirements.

The real judge of teamwork is business performance. It is always difficult to know just what conclusions should be drawn from published articles and case studies. Few companies are prepared to publish anything that might adversely affect the price of their stock. Often the case studies are used as the practical demonstration of a particular theory - in which case they can only be expected to support the theory. The relationship between a particular approach or project and overall business performance can be very unclear. Many companies are trying to introduce numerous initiatives at any given time, so it is difficult to separate out the effect of a particular initiative. From our experience we believe that teamwork can have a very positive effect on development performance. However, for this to be more than a short-term phenomenon, teamwork has to be institutionalized - it must not be seen as a new technique to be used on special projects, but as the technique to be used on all projects.

Copyright 1998 by John Stark