The A3 Report – Part 3: Limitations and Common Mistakes | Christoph Roser 

Even if the A3 report is sometimes paraded around like a sacred relic, it is in my view only a minor tool. The main work is still identifying and solving the problem. If I have the choice between a sloppy root cause analysis on an A3 report and a good one on the back of an used envelope, I would go with the envelope any time. Using an A3 report will offer no advantage at all if the content is garbage!

Sourced through from:

Michel Baudin‘s comments:

This is the 3rd post by Christoph Roser about A3. I only wrote two, What is an A3? and Beyond A3s. I agree with him that it is a minor tool, but our perspectives differ on details. Christoph sees A3 as primarily for problem-solving; I see them as a communication tool with many more applications, in particular work instructions. And Pascal Dennis likes to use them in Hoshin Planning/Strategy Deployment.

Continue reading

Beyond A3s: Options for Shopfloor and Management Communication

A3s are still being touted as nothing short of a management revolution, but few organizations actually use them for operator work instructions, problem-solving, or hoshin planning. This raises the question of whether the objectives pursued with a paper format may not be easier to achieve with more recent technology. In this post, we consider options for operator work instructions. The other applications of A3s deserve separate treatment.

Continue reading

Deming’s Point 9 of 14 – Break down barriers between departments

(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

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.


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.

Did Citroen Use Too Many Phone Calls and Emails in Developing the C5?

Wiegand’s Watch is a monthly letter from Dr. Bodo Wiegand, who runs the Lean Management Institut, the German affiliate of the Lean Enterprise Institute. This month, he focuses on what he perceives to be a wasted use of email and cell phones in the development of the Citroen C5 car. Following is a translation of his letter, followed by my comments:

€ 16 million wasted in the development of the C5 car
Today I was at the airport and saw a billboard.
The development of the C5 at Citroen used 1,410,475 cell phone calls and 3,155,546 e-mails. This is madness. If  a phone conversation lasts an average of 2.5 minutes, it works out to 14 670 man-days or 73 man-years.
Assuming  writing a  technical e-mail on average takes four minutes and that it is read six-times, then these emails took up  65,741 man-days or 321 man-years. Assuming that 50% of these cell phone calls and 50% of e-mails were necessary but non value-added, this adds up to 40,000 man-days or 200 man-years, or € 16 million were needed to do the following:

  • Fix processes that are out of control.
  • Define nterfaces that were not specified.
  • Rethink procedures with qualitative gaps.
  • To answer questions.
  • To solve problems.

What a huge waste!
What a potential for improvement!
And Citroen boasts about it.

My first reaction is to wonder what is wrong with >1,000 people involved in a multi-year project like the development of a new car communicating extensively? It brings to mind Frederick Brooks’s famous audit of the Tower of Babel project in The Mythical Man-Month. The goal was clear and its lack of feasibility played no part in the failure. Human and material resources were plentiful in Mesopotamia, and were not a problem either. What caused the project to fail was that team members could not communicate. 

Product development generates many documents that need to be reviewed, discussed, annotated, updated, revised, and organized. These documents must also be available easily to all those with a need to know, and kept secret from all others. I don’t know on what basis Dr. Wiegand concludes that a large part of Citroen’s communications by phone and email were waste. For all I know, they may have been meaty technical exchanges that improved the design of the C5…

Of course, you don’t need electronic means of communication if everybody is in one big room, but that only works for teams that are small enough. You would need a convention hall for a team in the latter stages of car development, and some activities, like testing in a hot desert or snow, or ramping up production, take place at multiple locations. While always desirable, face-to-face communication is not feasible for everything at all times.

Just based on the statements from Citroen, if I would fault them for anything, it would be for relying on nothing more sophisticated than phones and emails, which is so 20th century.  There are now collaboration and on-line meeting tools that combine much richer exchanges with better data security and revision control. For example, engineers at different locations can view the same drawing on their screens, annotate it while discussing through an audio conference, and read each other’s body language through webcams.

Instead of having multiple copies of documents floating around in individual mailboxes, you can keep them in a library on a server to ensure that all participants in a discussion are looking at the same version, and to prevent these documents from leaking out.

You can also fault emails for lacking the kind of structure you find in A3 reports, which discipline authors in providing particular data items while helping readers find them. But again, more advanced communication tools can provide that structure through on-line forms .

For voice communication, there are also alternatives to cell phones. For people whose work causes them to move around within the range of WIFI network, for example, there are wearable devices that allow them to call each other by name and communicate by voice instantly, as if they were side by side.

So maybe the issue is not that Citroen C5 development used to many engineer-years communicating, but that, next time, they should use the state of the art to do it.