Honeywell Building Controls Division

INTRODUCTION

Honeywell Building Controls Division (BCD) was split after the Residential and Building Controls Division lost money in 1981. The new BCD was created with a hope for a profitable business. In order to get more market share, in 1984 the BCD started to build Mod IV; the great promised product with better quality of its motor and cost reduction. The BCD built the cross-functional Mod IV team combined from manufacturing, marketing/sales, and engineering. In addition, to be more competitive, the BCD dropped sequential development in favor of the parallel development with a desire for faster and better products. The skate was high but the BCD had an inferior Product Development that slowed them down. The inferior product development delayed both the design schedule and production schedule.

In this paper, we will exam the problems of the BCD Mod IV product development. The inferior product development of the Mod IV might link to the project team, the project leader, and the suppliers and customers.

DIAGNOSIS/ANALYSIS

We begin by looking at project team in team of internal communication, external communication, and problem-solving strategy. In the case of internal communications (e.g., Dougherty, 1990; Keller, 1986), frequent communication increase the amount of information directly in that more communication usually yields more information (e.g., Brown & Eisenhardt, 1995). It cuts misunderstanding and barriers to interchange so that the amount of information conveyed is increased (e.g., Brown & Eisenhardt, 1995). This, in turn, improves the speed and productivity of the entire development process (Doughherty, 1992). Internal communication at the BCD was not good. One instance, the project team invited general manager John Bailey to attend a team meeting. John came to the meeting to show his support to learn that the meeting was postponed. The incident was not only cost the project time but also potentially disturbed production schedule since John was a very high rank officer. The project team should communicate with all members in the meeting about for any changes in the schedule so it would avoid wasting people time.

Next, we look at the external communication. In the case of external communication, frequent communication with outsiders such as customers, suppliers, and other organization personnel opens the project team up to new information (e.g., Clark &Fujimoto, 1991; Imai et al., 1985; Katz, 1982; Katz & Tushman, 1981). When this external communication is task oriented, team members gain information from diverse viewpoints beyond those of the team (e.g., Brown & Eisenhardt, 1995). Taken together and consistent with previous research, internal and external communication both increase the amount and variety of information and the resource available to the project team (e.g., Brown & Eisenhardt, 1995). These, in turn, improve process performance (e.g., Brown & Eisenhardt, 1995). The information that BCD project team received sometimes was a disaster (e.g., Brown & Eisenhardt, 1995). For example, engineers took the information from the distributors that they would stock single-shaft motors for the project development. Engineers went ahead working on the Mod IV based on single-shaft motor. Later, the project team found out that all they had were double-shaft motors. This error information could cost the project many problems with the motor later. The engineering design was not based double-shaft motor. Later on, incorporated of the double-shaft motor might generate a lot of noise in the motor. This incident showed that the external communication between project team still broke somewhere along the product development process. Along with external communication, project team needed a good problem-solving strategy (e.g., Brown & Eisenhardt, 1995).

The problem-solving strategy assumes a certain but often complex problem-solving task that can be rationalized (e.g., Brown & Eisenhardt, 1995). For example, consistent with the rational and problem-solving perspectives, planning (e.g., Cooper & Kleinschmidt, 1987; Hayes et al, 1988; Iansiti, 1992; Zirger & Maidique, 1990) improves the speed and productivity of the development process by eliminating extra work, rationalizing and properly ordering the steps of the process, and avoiding errors (e.g., Brown & Eisenhardt, 1995). In effect, the development process is squeezed together (e.g., Clark & Fujimoto, 1991). For the Mod IV team, there was not a problem-solving strategy. The project team did not have a plan or discussed about the problem-solving strategy in their team meeting. For example, when project team had a lot of semantic issues, they did not even know about it (e.g., Brown & Eisenhardt, 1995). Without problem-solving strategy, project team could not avoid errors later in the product development process. Hence, Mod IV was having problem meeting schedule for both design and production. In conclusion, the unaffected project team wasted resources, caused delay, and could not avoid errors. In addition, a weak project leader could spell problem for Mod IV product development.

In this paper, we will take a look at two characteristics of the project leader. One central characteristic is the power of the project leader (e.g., Brown & Eisenhardt, 1995). By powerful leaders we mean those project leaders with significant decision-making responsibility, organization wide authority, and high hierarchical level (e.g., Brown & Eisenhardt, 1995). Those leaders are highly effective in obtaining resources such as more personnel and larger budgets for the project team (e.g., Brown & Eisenhardt, 1995). In case of the Mod IV project, when project leader represented a plan, the direction from the above was "do it" without additional resources. With no power to get more resources, the Mod IV project team would get a lot more pressure if the team wanted to speed up the product development. Furthermore, because the project team lacked some skills in technology, they had to work so hard. People might stress out that led to decrease in performance and increase in errors.

A second, important characteristic of the project leader is vision (e.g., Brown & Eisenhardt, 1995). Vision involves the cognitive ability to mesh a variety of factors together to create an effective, holistic view and to communicate it to others (e.g., Brown & Eisenhardt, 1995). Specifically, in the case of product development, this means meshing together firm competencies (e.g., particular technical, marketing, or other skills) and strategies with the needs of the market (e.g., consumer preferences for style and cost) to create an effective product concept (e.g., Brown & Eisenhardt, 1995). The vision in the Mod IV product development was to improve its