September 15, 2023, ©. Leeham News: Last week, we described the beginning of the Detailed design phase of an airliner development program. We discussed the importance of a good information set from Preliminary design, ideally as a collection of digital models forming a Preliminary level digital twin.
We now discuss how the work is managed in the Detailed design phase and how to speed up the work and make it more efficient.
The traditional management of large aircraft programs has followed a structured and controlled method called the Waterfall method. It means the design engineer gets his job to-do through a hierarchical breakdown process where his manager takes part of the Preliminary design information that touches the designer’s task, clusters it, and complements it for him to have as input for his design job.
The designer makes a 3D design of the part and adds information about material, treatments, tolerances, etc., into the Product Data Management system, where it forms a complete design information for the part.
The production engineer then takes the 3D model with information and morphs the data into a production specification that includes what methods and work steps shall be used to manufacture the part.
The OEM or a contracted machine shop then produces the part. The OEM’s Quality Assurance (QA) department measures the part when exiting the own shop or when it arrives from the external shop. Any QA deviations are recorded and reported to the production engineer and the designer.
Is the part acceptable, it’s built into the assembled portion of the aircraft where it belongs. Any problems or findings at the assembly process are noted and, if grave (fit or access problems, part not optimally designed), reported to the production and design engineers.
The part in its context is then tested for its function in the aircraft by the test department, which writes test reports that go to the designer of the part, among others.
The whole sequential process of breakdown, design, manufacturing adaptation, manufacture, and assembly into a test rig or prototype, where a test report is the final feedback on whether the part is correctly designed, constitutes a very long feedback cycle. It can take a year or more before the designer has full feedback on his work. The after-sales service aspects (can the part be easily removed to give access to maintenance behind the part, etc.) are only received when the maintenance department starts working on prototypes to check if the aircraft is maintainable.
The fundamental problem of the classical method is the long feedback loops, where design changes are made very late based on how it shall function in the aircraft and during maintenance.
The strength of the procedure is a strict step-by-step transfer of responsibilities and information. Project and Configuration management is straightforward.
The above describes hardware development, where the final product is physical. It’s relatively easy to define how it shall look and fit (dimensions, materials, tolerances, mass, surface treatment, etc.).
Functions realized in software are harder to define to 100%. It made the waterfall method less suitable as the end result was often suboptimal (This is not what I expected or need! Yes, but it was what you specified (six months ago)!).
As a reaction, Agile methods appeared for software development. In essence, these break down the software functional specification into small blocks that can be specified, programmed, and tested with the customer within a week or two. Now the feedback time was weeks, not months or years.
The Agline method allows cross-functional teams where the customer of the function (let’s say it’s the cabin team with lead customer representatives as the software is controlling the air conditioning) can be part of the team, as can the maintenance department so it can look at BITE (Built In Test) functionality for the functions from the Get go.
The success of Agile in software development, its increased development speed and customer satisfaction made program management for other disciplines wanting to test it as well. Initially, it was thought, “Finally, we have found the medicine against the sequential and long loops of the waterfall method.”
In practice, the results have been mixed. As we described last week, the projects now span many thousands of people inside the OEM, further thousands from external consultancies supporting the OEM, and even more people in the supply chain working on the project.
Once the work spans several organizations, forming short-loop Aigle teams gets complicated. Expected work results versus money paid is part of contracts with the external organizations. Such contracts have specified deliverables with attached costs.
But Agile is about seamless cooperation in small self-governing cross-functional teams where teamwork rules over organizational belonging and contract terms. Agile teams are thus less defined in their outputs (it’s the point of Agile; it follows the customer’s need), making Project and Configuration management difficult.
The overall result is that Agile is now part of airliner projects but hasn’t replaced the more traditional sequential methods. These are used for overall Project and Configuration management.
As more and more functions in an aircraft are realized in Software, Agile methods are used for a larger and larger part of the aircraft project. It’s also used in other areas where short feedback loops are needed and effective.
And in general, the strict hierarchical “over the wall “ transfer of development process steps has changed. Cross-functional teams are formed much earlier in the development, and feedback loops are as short as possible.
Has Agile made the development of aircraft more efficient? Yes, but not to the extent once thought. As the importance of software increases, the effects of Agile increase.