Long ago, I worked as a process manager for the development department of a vehicle manufacturer. The company had many processes, but our department’s understanding of those processes—who needed what, and when—were largely unknown.

As a vehicle manufacturer, we had a specific workflow for product development: Define the system; define the components of the system; deliver an iteration of the product; learn from those iterations; adjust the documentation; and add heretofore unknown systems and components.

This exercise allowed the refinement of specific department processes (for example, wire harness engineering) and artifacts. We then set about refining the process descriptions.

Since we didn’t necessarily know everything about a particular process, we had to be careful in making changes, and I was reminded of the concept of Chesterton’s Fence.

Chesterton’s Fence

Named after the prolific English writer and philosopher G.K. Chesterton, Chesterton’s Fence is an intellectual exercise in humility and prudence. Chesterton articulated this principle in his 1929 book, The Thing: Why I Am a Catholic. Chesterton’s Fence is a metaphorical fence that represents any existing system, tradition or structure. Chesterton’s argument is simple but profound: “In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle…which will probably be called a paradox. There exists, in such a case, a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, ‘I don’t see the use of this; let us clear it away.’”

Chesterton’s Fence urges us to inquire about a structure’s origin, purpose and function before dismantling or modifying it. The fence serves as a symbolic reminder that what may appear unnecessary or obsolete at first glance may have a purpose integral to the system.

I was reminded of that concept as we modified processes at the vehicle manufacturer. For each process, we created documentation. Those familiar with processes may recognize the format:

Input: the prerequisites that enable the process to be executed.

Process: how we intend to accomplish the goals.

Output: the output form in documentation or other attributes.

In a repeatable environment like manufacturing, this is pretty straightforward. You have parts, and you put them together, checking each step along the way. Product development is less straightforward. There is much more variation.

There are times when some aspects of the development process may not be strictly applied. For example, consider a product modification that adapts software without impacting the hardware. This eliminates the need for early prototype versions, so those specific processes will not be required. There will also be times when the inputs are not ideal, and we must adapt to the situation. Since these circumstances exist, we need to know the reason for undertaking the specific process. So, we list an objective for each process document. The purpose describes why we are doing the action.

At the beginning of these product development process documents, we added an element to account for these variations, specifically an objective statement. Why are we executing this process? The factual statement defines the attributes of good and what we should achieve in as specific language as possible. Our team members should know why we are doing this; this statement clarifies why. For those events when we cannot apply the ideal process, we can think of alternative approaches.

Total Quality Management

I am a big fan of using TQM to improve quality; these tools can be applied to any product or process. I was introduced to TQM decades ago through the works of W. Edwards Deming. Through these processes and techniques, I have saved companies millions of dollars annually. Before learning about TQM, I worked as an engineer to understand what was happening and why before changing things. Because this is how I typically perform my engineering work, this might be the reason I find the TQM approach so satisfying. Then again, it could be the millions of dollars saved!

The Shewhart Cycle, also known as the plan-do-check-act (PDCA) cycle, is a four-step management method used to improve processes, products or services continuously. This cycle, developed by Walter A. Shewhart and popularized by W. Edwards Deming, provides a systematic problem-solving and quality improvement approach.

• Plan: In this phase, you identify and plan for the improvement. This involves understanding the current situation, defining goals, and developing plans for change. It’s about setting objectives and figuring out how to achieve them. The plan will set the exploratory actions, the experimentation on things that may improve production quality and outcomes.

• Do: Once the plan is developed, it’s time to run the experiment. This phase involves executing the plan or experiment on a small scale. This could mean implementing a new process, system, or change in a controlled environment. This running of the experiment will generate data, which will be fodder for the next step.

• Check: After implementation, you assess the results and gather data to compare them against your objectives and predictions. This is the evaluation phase, where you determine if the changes had the desired effect and if they were implemented effectively. If the outcome is as you want and matches your predictions, then we move to the act step. If our predictions do not match the outcome, we have more experimentation and learning to do.

• Act: Based on the results of the check phase, you take action. If the changes are successful, you implement them on a larger scale. If issues or areas for improvement are identified, you go back to the planning phase and make necessary adjustments.

In the fast-paced world of project management and manufacturing, the allure of innovation and change can be irresistible. However, the wisdom encapsulated in Chesterton’s Fence reminds us to approach change cautiously and clearly. Before dismantling existing structures, it is crucial to comprehend their purpose and history, ensuring that the changes made contribute positively to the overall system.

By incorporating the lessons of Chesterton’s Fence into the agile landscape, organizations can navigate the complex maze of project management and manufacturing changes with a thoughtful and informed approach. In the pursuit of continuous improvement, let us not forget the timeless wisdom that history and purpose provide—guiding us toward a future that builds upon the strengths of the past.