Andon & Declaring Breakdowns

A breakdown is an event that violates or will violate the principles of the project or organization—or erodes team trust. All team members and employees must be given the authority to declare a breakdown the moment it is identified.

Breakdowns are not inherently bad – they are expected. You’d be hard-pressed to find a project in which all procedures were followed strictly, or in which a worker wasn’t confused about an established process.

However, failing to alert the team when a breakdown has occurred or will occur can lead to difficulties, and over time might lead to massive quantities of waste. It is crucial that team members feel comfortable declaring breakdowns and that they do so as soon as immediately practical.

If you find yourself in a situation where you notice an issue in the workflow or if you personally are confused about a process or procedure, it’s time to declare a breakdown. Breakdowns are declared by pulling an “Andon cord.”

In manufacturing practices, team members can declare a breakdown in the assembly line by pulling a lever, pressing a button, or taking a similar action. You may be most familiar with the notion of a blaring red siren that goes off in the factory when an issue is detected. The assembly line would then stop while the team swarms to the area of concern.

The purpose of pulling the Andon cord as early as possible is to prevent two main types of waste: defects (incorrectly assembled products) and waiting (not being able to proceed with production because of an issue along the assembly line).

Like many Lean principles that got their start in manufacturing, this idea of pulling the metaphorical Andon cord to alert the team to a breakdown applies well to the built environment.

In design and construction, pulling the Andon cord is generally done verbally by alerting the appropriate team member that a breakdown has occurred. Even though there is no physical Andon cord, the action of declaring a breakdown is still referred to as “pulling an Andon cord” in the industry.

A breakdown can be declared by any member of the team, and team members should feel the freedom to declare breakdowns whenever they…

• Foresee an event that will violate the principles of a project, or organization—or will erode trust;
• Experience an event that has violated the principles of a project or organization, or erodes trust;
• Are confused; or
• Get results different from what was expected.

Team leaders should establish breakdown declaration procedures as a part of their processes, and team members should be made aware of this during onboarding. If your workflow does not currently include the infrastructure for declaring breakdowns, ensure that is established.

Similar to what occurs in the manufacturing process, declaring a breakdown in a construction project leads to a discussion on how to solve the problem. All team members to whom the breakdown is relevant should be a part of determining the solution. If the solution can be decided quickly, it should be implemented. If conducting root cause analysis and figuring out a solution will take a longer period of time, it is important that the team also determines what should be done in the interim to limit the amount of waste being produced by the problem.

A discussion regarding the breakdown can either be had immediately (upon hearing about it) or soon after with a smaller group composed only of the necessary team members.

The discussion should revolve around creating a shared understanding of the problem, identifying the root cause, and preventing the situation from recurring. Action plans should be developed using Lean methods such as:

• Retrospectives
• Plus/Delta
• Fishbone Diagrams
• A3

The method used will vary depending on the nature of the breakdown.

Once the breakdown is resolved, the team should alter working processes as needed to prevent the recurrence of the breakdown, and should communicate the process changes to all appropriate parties.