|
|
www.johnstark.com |
|
|
|
In a cross-functional product development team, product developers from different functions work together and in parallel. Team members come from functions such as marketing, design, service, quality, manufacturing engineering, test and purchasing. Often, key suppliers are included in the team. Sometimes, representatives of the customer are also included in the team, allowing the Voice of the Customer to be heard throughout the development process. Team members work together, sharing information and knowledge, and producing better results faster than they would have done if operating in a traditional product development mode. The end result is that products get to market faster, costs are reduced and quality is improved. If cross-functional product development teams are not used, the product development process is likely to be serial, with each group of specialists working one after the other on successive phases of the development. Once a group has finished its work it passes it on to the next group. For one reason or another this group may not like what it gets, so sends it back with a request for modification. By the time the first group gets the request for modification, it is working on something else, so can't respond immediately. Often the first group doesn't like the requested change, so comes up with another alternative. Although the group does its best to provide a good alternative, it may not understand all the reasons behind the request for change, so the new alternative may still not meet the requirements. This serial, to-and-fro approach to product development tends to be slow, costly and low-quality, leading to a lot of engineering changes and a product that is less competitive than expected. Other problems with the semi-independent groups of specialists arise because each group has its own specialist vocabulary, its own computer systems and applications, and its own data definitions and structures. When groups exchange information there are often misunderstandings in terminology, data conversion errors and incompatible data definitions. As a result, the information each group works with is often incomplete and erroneous. There are many advantages to the cross-functional product development team approach. One is that people with a mix of skills working together are much better at coming up with a solution to an overall problem than individuals with limited specialist knowledge. A cross-functional product development team's composite knowledge of design, processes, materials, manufacturing, quality, and customer requirements can be applied to develop the best definition of the product and its manufacturing, support and disposal processes. Working together, the members of the team will tend to use a common, shared vocabulary and standardized data definitions. Common tools can be used, thereby reducing data exchange problems. In cases where it is not possible to use common tools, use of a limited set of tools can be agreed by the team, and the exchange of information between them can be standardized. Information will be shared, so information access becomes quicker. Understanding of information improves because team members are available to explain the meaning of information. Functional specialists are not allowed to develop unsuitable solutions without being rapidly brought back to reality by the rest of the team. The improved communication resulting from team membership helps reduce changes to specifications. It helps increase downstream awareness early in the development process. Team members from upstream functions get a better understanding of downstream reality, resulting in a reduction in 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 changes also takes the burden off the engineering change system, allowing the remaining changes to be handled more effectively. The amount of formal communication (e.g. official sign-offs) can be reduced because information can be communicated informally within the team. The number of administrative documents can be reduced. Many of the documents previously required during a design phase are no longer needed as all the information is with the team, and there is less need to communicate with other people. The team has a much clearer view of the status of the product's development than a manager of a development in a serial environment in which activity is spread over a number of semi-independent, uncommunicative groups. The team environment provides a very open, visible environment. Whereas in the serial process each group can behave and make modifications that are hard for other groups to identify and understand, in the cross-functional team it's much more difficult for someone to do something, such as make a change, without the rest of the team being immediately aware of it. Within the team, all functions are more or less equal, so there is less chance of one function being completely out of touch with customer requirements yet having the political strength to impose its desires. Another advantage of the team approach is that re-use of existing parts and processes is likely to increase. It's much more likely that one of the team members will remember the existence of a similar part or process than an individual working alone. The result of all these improvements is a reduction in overhead costs, a reduction in the development cycle and an improvement in quality. The reduction in the development cycle usually also results in a reduction in the number of development hours. This has a direct effect on development costs. The team approach also tends to prevent development cost overrun as it focuses attention on the early identification and resolution of problems. The team approach also improves product quality. The early involvement of downstream functions reduces the risk of potential problems. |