(Featured image from the  Bureaucracy game, by Douglas Adams)

Deming’s complete statement of Point 9 is as follows:

“Break down barriers between departments. People in research, design, sales, and production must work as a team, to foresee problems in production and in use that may be encountered with the product or service.”

Within a large organization, it is common for departments to work at cross purposes. Each department is a functional silo, working towards goals that may be inconsistent with the interests of the whole. Deming gives many examples of disasters that occur as a consequence, and exhorts his readers to break down the barriers to keep them from happening. As with his other points, he makes no recommendation on how to accomplish this.

Let us examine several approaches that have been tried, and the issues that organizations encountered when they did:

• Eliminating silos in the organization
• Making functional departments work
• Obstacles to organization by process or value stream
• Skills maintenance, continuing education and career planning
• Project transitions

Eliminating silos in the organization

This is not a problem for small companies. As long as the entire management team fits within a small conference room, there are few opportunities to erect barriers. In a large company where it is a problem, the most obvious solution is to organize by what is variously called business teams, business processes, value streams, or focused factories.

You dissolve the functional departments and organize multifunction teams that bring all the required talent to bear on the core activities. In a manufacturing company, for example, all the resources needed to make a family of products from start to finish — including engineers, maintenance and quality technicians, schedulers, etc. — report to one “value stream manager,” and there cannot be barriers between silos because there are no silos.

It’s like the Mission Impossible TV series, with the disguise specialist and the explosives expert working together towards a common goal, as opposed to being in separate facilities and exchanging service requests in triplicate. This is a popular picture in the US and the approach is often used in a variety of contexts, such as emergency response, as in Apollo 13, or product development, for Data General’s MV-8000 computer in 1980 in Tracy Kidder’s The Soul of a New Machine, or the 1996 Taurus at Ford in Mary Walton’s Car.

The movie Apollo 13 shows a seemingly too-good-to-be-true team that is thrown together to find a way to fit the square connector of the command module air scrubber to the round hole used on the lunar module, using nothing but the odds and ends available to the astronauts on the crippled spacecraft. But the story is true, and we have a picture of the actual device the astronauts built.

This was the philosophy of Business Process Reengineering (BPR). Each business was to be broken down into processes turning some input into an externally visible output. Manufacturing, in BPR, did not qualify as a process. Instead, it was subsumed into the order-fulfillment process.

Making functional departments work

But it is not a panacea. The development of the 1996 Taurus took 30 months, and it was a major improvement over previous products at Ford, but still not down to the 24 months used at Toyota for the Rav4, and Toyota uses a traditional structure with functional departments communicating through memos.

In addition, according to Mary Walton, Ford’s integrated, collocated team made design decisions that made manufacturing more difficult. She explains in particular that the sculptured shape of the side panels made them more difficult to stamp, and this happened even though manufacturing was represented in the team. As a work of art, the 1996 Taurus was stunning. As a commercial product, however, it was lackluster, losing the previous versions’ bestseller status in the US market to the more “boring” Honda Accord and Toyota Camry in 1997.

The reality is that organization structure does not determine outcomes. The caliber of the individuals, their motivations for the roles they are playing, and their interaction protocols are at least as important. In their July, 1998 Harvard Business Review article , D.K.Sobek, J. Liker, and A.C. Ward listed the following practices as key to Toyota’s performance in product development:

1. Written communication with single-sheet A3 reports in standard formats.
2. Engineering supervision by practicing, hands-on engineers.
3. A chief engineer (shusa, or 主査) for each project who is an experienced designer with a proven ability to integrate different technologies into a product. The shusa has a team of 5 to 15 members coordinating the work of hundreds who remain in functional departments.
4. Engineers who develop their skills through on-the-job training, mentoring, and rotation within their functional department, with senior managers rotating between departments.
5. High-level project plans with a small number of milestones, giving each department flexibility on detailed tasks.
6. Checklists of design standards embodying the lessons learned in previous projects.

Obstacles to organization by process or value stream

The Toyota example is about product development. But what about other activities like operations? When you attempt to organize everything by business process, or by value stream, in most cases you encounter some functional departments that you technically cannot or should not break up.

Most machine shops have a central heat treatment facility. Induction hardening can, for some work, distribute heat treatment among different production lines and break down the “heat treat silo,” but a given shop may make products to which it is not applicable, its customers may not approve the process, or it may not have the skills or resources to implement it. Electroplating and painting commonly are similar challenges. As a result, the plant ends up with a few common services organized as functional departments along with lines that take a family of products through a sequence of operations.

Among support functions, the picture is also mixed. Production scheduling at the detailed level, for example, works better when the schedulers work directly for the manager of a production line than in a central department, because local scheduling is a simpler problem and the relevant specifics of machine behaviors are more accessible. On the other hand, breaking down a maintenance department and making the technicians report to production managers may not enhance their responsiveness when, for example, the group assigned to a line is short of the critical mass needed to have at least one technician standing by for the next emergency.

Other departments remain organized centrally because of the information they have access to, like Human Resources, Accounting, or Technical Data Management; others, because of external entities they deal with, like Shipping and Receiving.

Skills maintenance, continuing education and career planning

When breaking down a functional department and reassigning its members to teams organized around processes, we also need to consider how it affects the people to whom we do it. Professionals like medical doctors or lawyers work for clients who have little or no knowledge of their specialties, but it is then up to them to decide how much of their revenue to spend or maintaining their skills. They choose which magazines tp subscribe to and which conferences to attend, without asking anybody’s permission.

An engineer reporting to a production manager also works for one “client” who does not have the same expertise, but as an employee. If this engineer wants to attend a conference, the first step is to get approval for the time and money it will consume, from a manager with no knowledge of whether it is a good idea.

In the long term, what career does this engineer have to look forward to? The manager needs the engineer’s skills here and now but is ill equipped to provide guidance, compared to an engineering manager whose background and experience are in the same field.

For this reason, some companies have adopted matrix organizations, in which specialists report “solid-line” to a process owner who needs their skills in operations or on projects, and “dotted-line” to a functional manager for skills maintenance and career development. In a diagram, as follows, this structure looks simple and attractive:In reality, of course, it is a more complex form of organization than a simple hierarchy, and conducive to all sorts of tensions regarding authority and responsibility.

Project transitions

Project work — like product development, new product introduction, or new plant setup — differs from operations in that it ends when a goal is reached, which may be a working prototype, a target takt time in production for the new product, or for the new plant. At that point, the teams are disbanded and their members move on.

This is a particularly sensitive transition to manage when you collocate a multifunction project team in one big room, because its members bond both with the project and with each other, and receive the ending like a psychological blow on the scale of the loss of a family member. This is another reason why they need to retain a connection with their functional peers.

Conclusions

Breaking down barriers between departments for the greater good of the organization as a whole is a worthy goal, that high-level managers have been pursuing since, at least, the Roman empire. There is no simple recipe. The approaches followed by successful organizations have been subtle, nuanced, and fitted to their purposes.