From a Whiteboard to a System of Systems: Executing Across a Network of Moving Parts

“We can’t impose our will on a system. We can listen to what the system tells us, and discover how its properties and our values can work together to bring forth something much better than could ever be produced by our will alone.” — Donella Meadows, 

Project Overview

A former boss entrusted me with one of the most significant challenges of my project management career: developing the plan for and overseeing the Functional Tests of a new airplane model. It was a complex effort that required rigorous project leadership, systems thinking, and the ability to coordinate an unusually large and interconnected environment.

The Program Director made clear from the beginning that this was not a routine assignment. The project involved high-level integration requirements and a vast network of engineering and support functions, all of which had to work together with precision. Planning had to be meticulous.

Although I was not a subject matter expert (SME) in aircraft Functional Tests at the time, I was asked to lead the effort because of my experience managing large-scale, complex projects. That trust marked the beginning of a deep discovery process and one of the most demanding programs I have ever managed.

The Challenge

The scale of the challenge was extraordinary. More than 300 engineering functions had to be tested, not to determine whether the designs themselves worked, but to verify that airplane systems and components had been installed as designed and that the installation planning instructions were accurately reflected.

The execution team extended far beyond engineering leads. More than a thousand people were involved across engineering, technicians, wiring, procurement, installation, safety, quality, and other supporting functions, with representatives working across three shifts.

The core challenge was not simply technical testing. It was mapping a system of systems, establishing clear communication across the thousand of team members, including the customer, and maintaining hour-by-hour understanding of work in motion. The planning phase brought clarity to the roles of the many partners involved, but maintaining that plan during execution proved extremely difficult.

A further complication emerged early in execution. Although the full scope was understood from the start, leadership initially intended to manage only the critical scope. That approach did not hold. The product was not yet ready, and the plan had to expand to cover the entire project. In practice, teams had to work each day based on the systems elements that were available, making traditional sequence execution increasingly difficult to sustain.

The Strategy

My first step was to sit down with the Program Director and understand the project at its core. Standing in front of a wall-to-wall whiteboard, I asked every question that came to mind while he answered by writing words, circles, and lines across the board.

My first question was simple: What is a Functional Test? I initially assumed it was meant to determine whether a design functioned properly. Not quite. It also verified that the airplane systems had been installed as planned, that when a particular function was tested the wiring and all required elements performed as expected in the actual aircraft, and that the step-by-step test instructions written on paper could be effectively translated into execution on the airplane.

By the end of that first session, the whiteboard was covered in markings that would not have made sense to anyone else. I took a picture of it, and that picture became my first planning document. I still carry it because of what it represents. It was the starting point for the deeper discovery process that followed.

From there, I mapped the project’s high-level scope and requirements. With the Director’s guidance on who the SMEs were, I met with each of them to ask more detailed questions and drill down into the scope. Using the structured approach I had developed and applied for two decades—the Spaghetti & Meatballs methodology, today our Bridge&Map™ —I worked to bring order to a system that was still largely conceptual.

Two SMEs became especially important to the work and to my learning. They remain among the most knowledgeable people I have known in aerospace.

As I gathered more information, I mapped the Functional Test system first from a 40,000-foot view and then gradually lowered the altitude. The effort involved hundreds of people across many organizations, spanning requirements, design, installation planning, parts procurement, safety, manufacturing, quality, testing, and certification. A true complex system of systems.

At that stage, everything was still on paper, and translating that system into execution proved extremely difficult. The airplane itself was not yet fully assembled. The wings were in one area, the nose in Wichita, and sections of the fuselage were in different work areas of the factory. Functional Tests could not begin until the airplane was fully joined and had entered Final Assembly.

That waiting period gave me an opportunity to go deeper. I immersed myself in the functional testing of other airplanes to understand what “Oil On” and “Power On” really meant in practice. I had heard those terms before from work on other models, but only at a high level. Their full operational meaning was still unknown to me: “Oil-On” meant putting hydraulic fluid into the system and confirming there were no leaks. “Power On” was like turning a key in a car’s ignition: the airplane was powered up.

Because I am an engineer, I was able to go deep into those concepts. I observed these initial tests on sibling airplanes, a 747 and a cargo 767. I climbed into the aircrafts, followed the step-by-step procedures, and wore headphones connected to the flight deck while the technicians ran the tests. That firsthand exposure gave me a practical understanding that no briefing alone could have provided.

As execution approached, the system map became more than a planning artifact. It became the operating guide. It captured a complete view of the scope and critical dependencies, including a sub-map showing the specific connectors required for each wire segment. In practical terms, that meant navigating approximately 120 miles of wiring, more than one hundred thousand wire segments, and thousands of connectors. That sub-map proved especially useful when blockages occurred. We posted the visual map on the factory walls like a road map. When one path was blocked by a design, manufacturing, or installation issue, the team could identify alternate routes and keep moving while troubleshooting continued elsewhere.

To make the system easier to understand and communicate and to add a little fun, we gave different functions and paths road names. The critical path became Main Street. That language helped people orient themselves inside a highly complex environment. One function had so many recurring issues that we considered naming it “Dead End,” but decided against it because it would have discouraged the team.

Over time, the planning model evolved further. The original, more traditional approach could not keep pace because the product was not ready in a stable, predictable way. Teams had to do what they could each day based on available inputs. The plan became, in effect, a “rubber plan,” flexible enough to allow different groups to work in shifts while preserving overall direction and control. In retrospect, this is what some Agile principles look like. We just called it differently. It was a more iterative approach that was highly beneficial for detailed ongoing coordination.

Communication also became a central part of the strategy. Functional Tests ran across all three shifts, so a specific and tailored handoff and status process had to be in place. Status was given to the VP of the program on a daily basis at 0600 hours. As managers and technicians changed from shift to shift, everyone needed a clear understanding of what had been done, what had worked, what had failed, and what needed to happen next. Without that continuity, interruptions would have multiplied quickly.

We also built a practical escalation network around the work. Technicians and technical experts running the tests were first in line to identify blockages and troubleshoot issues. That troubleshooting helped determine whether a problem came from installation, design, wiring issues, or parts. Over time, the network became strong enough that we had an emergency response structure in place to reach the right person quickly, with lead engineers and backup engineers available around the clock, supported by functions such as procurement and quality.

The Results

By the time the airplane entered Final Assembly, I had developed a complete system-of-systems view of Functional Testing and a practical understanding of how the tests had to be carried out.

The successful completion of the Functional Tests for the first airplane of this new model marked a major milestone for the program. It was neither smooth nor simple. We were managing a high volume of concurrent issues, many of them significant enough to disrupt progress and require constant reprioritization, workarounds, and close coordination across teams. In an environment this complex, problems rarely appeared one at a time, yet the work continued to move forward. One of the most critical enablers was having the map that showed how each issue affected specific system elements and the teams connected to them. That visibility helped us keep moving forward and prevented us from running in circles.

The planning model proved valuable beyond this first effort. It was later used for three additional airplanes, demonstrating that the structure built for this program had lasting value.

The project also confirmed the importance of planning at full scope. Leadership’s original intention to manage only the critical scope did not work. The product was not ready for that narrower approach, and the effort had to expand to encompass the entire project. That shift was difficult, but it allowed the team to continue making progress in a reality that was changing day by day.

Perhaps most importantly, the planning phase created clarity around the roles and interdependencies of all partners. That visibility made coordinated execution possible in an environment that otherwise could have become unmanageable.

By the end of the program, I had moved from being unfamiliar with Functional Testing to becoming a recognized source of expertise, later sought out by other programs within the enterprise for advice in this area.

This program, without a doubt, remains the most complex project I have ever managed.

The Project in Numbers

This project moved from concept to execution over a substantial timeline:

– Planning duration: 52 working days

– Execution duration: 472 days

– Total duration including planning: 524 days

– Planning-to-execution ratio: 9.92%

– More than 300 engineering functions involved in testing

– More than a thousand partners involved across product and support functions

– Coverage across 3 shifts

– Planning model later reused for 4 additional airplanes 

– Mileage of wiring involved in functional testing: 120 miles

– Wire segments: >100,000

Key Takeaways

This project reinforced that in highly complex environments, mapping the system is foundational. Progress depended not only on understanding individual tests, but on understanding how all tests, people, dependencies, and decisions connected.

It also showed that full-scope visibility matters. Even when leadership initially hoped to manage only the critical scope, the reality and complexity of the product required a broader view. Without that broader system understanding, execution would have stalled.

The experience also highlighted the limits of a traditional planning approach in an environment where readiness was evolving day by day. In retrospect, a more iterative approach would have supported ongoing detailed planning more effectively. What ultimately worked was building enough structure to guide the effort, while keeping the plan flexible enough to absorb changing conditions.

Not every part of a complex project is reusable in the same way. In this case, the planning was a one-time effort, and the execution process, network, statusing, and communication structure created lasting value across later airplanes and the broader program.