By Bjorn Fehrm and Henry Tam
February 20, 2026, ©. Leeham News: We have, since August 2025, gone through an FAA CFR 14 Part 25 development project of an airliner in the 200-seat class. The aim was to identify the activities required for such a project and the regulatory actions needed to achieve Type Certification (TC) and Production Certification (OC) for the aircraft.
The program followed the time plan in Figure 1, which indicated that it would take about seven years from the start of conceptual design to deliver the first aircraft and enter service (EIS). At each phase, we assessed whether modern support techniques, such as AI, could help with development and certification and whether they would accelerate the program plan.
Figure 1. A typical Program Plan for a smooth-running Part 25 airliner development. Source: Leeham Co.
We now summarize the findings and incorporate additional modern support, such as Digital Twin support, to assess the overall impact of today’s technologies on the program plan timeline in Figure 1.
Airliner Development Times
As mentioned in the previous article, the scope of development for a commercial airliner has changed over the years. Some of these changes are due to software functions. Others came from lessons learned from incidents and accidents. To illustrate the change in the development timeline, we plotted the launch-to-EIS timelines for a few past programs in Figure 2 below.
Figure 2. The evolution of the Part 25 Type Certificate calendar times of recent airliners. Source: Leeham Co.
From the chart, we can observe that the timeline has almost doubled since the 1960s (i.e., from the 737 to the 747). If we ignore AI for the time being (we save this for the next article), were there any improvements in tools over time? Did they help?
We would argue, YES, they helped. For example, 3D CAD/CAM enables designers to create and iterate on designs quickly. It also helps reduce the workload on parts with similar characteristics by enabling copy-and-paste. The invention probably saves quite a few hours of work.
Similarly, configuration management tools also help streamline processes. Engineers can easily refer to the right dataset for their work. This helps save time and reduce rework. In modern PLM tools, users can also link requirements to design, enabling designers to document compliance quickly. Sometimes, they can even link schedules, changes, analyses, test data, and related items to create a seamless thread to support development activities. Again, they should help reduce work hours by eliminating some of the middlemen who previously had to manually link these datasets.
Furthermore, Digital Twin is being used to link many datasets from concepts to production. It is a virtual representation of the aircraft’s geometry and systems, enabling visualization and simulation of the product. What this meant is that not only can the development be done in 3D with different parts of the aircraft on large screens. The design could be shown to groups of designers using virtual reality, and other means to check if production and maintenance have ample access to the different system items that are buried in the aircraft’s innards, with only a hatch as access means.
Digital Twin also enables simulation of the flow in the Final Assembly Line (FAL), with 3D sections and wings running on virtual transporters, and the optimization of these simulations. The concept could also be used downstream with Tier 1 and deeper suppliers in the development and manufacturing of aircraft parts. In theory, you could run the complete development and manufacturing planning of the aircraft using only a 3D digital model of the aircraft, called the Digital Twin. The idea was to speed up the process and to cut the number of workyears required to develop the aircraft.
A More Complex Environment
But the complexity and scope of development programs have expanded. To improve aircraft efficiency, engineers now need to find new ways to reduce weight, drag, and propulsion inefficiencies. Other stakeholders, on the other hand, may want lower cabin altitude, more luxurious business-class seats, and so on to increase the product’s competitiveness, but this would be counter to some of the efficiency improvement work. To meet these objectives, analyses and tests become more sophisticated over time. In some cases, systems or structures may need to be more advanced to push performance to the limit, which can require longer design and testing times.
This leads to two interesting questions. First, are these tools helping to eliminate bottlenecks or speed up the work on the critical path? If they are, then an observer can certainly see some reduction in timeline (at least on paper). However, if these tools do not eliminate bottlenecks or address the critical path, then they help reduce work hours but not necessarily the program timeline. Cost savings in this scenario are also debatable, depending on the circumstances.
Second, are risks properly understood and mitigated? Obviously, there are unknown unknowns and known unknowns. For instance, an accident compelled regulatory authorities to review details of a new aircraft’s design. This is likely to increase the timeline and will be difficult to mitigate, especially when there was an established way to collaborate.
On the other hand, if the management team decides to use a battery that is only available in the lab later this year for our hybrid airliner, there is a better chance of developing a mitigation plan (if we acknowledge that this is a risk) that could protect the program by sacrificing some time, performance, or profit. Having a major risk turn into an issue, especially an unmitigated one, can significantly delay a program. Keep in mind, some of these risks are not technical.
Speeding up a program is a multi-disciplinary effort that requires input from many stakeholders to develop a holistic solution. Many tools have evolved the way we work by improving workflows and efficiencies across various domains. Conversely, having many best individual solutions does not necessarily mean that the program-level solution is optimal. Sometimes, a few suboptimal solutions can actually improve overall performance by enabling other teams with bottlenecks complete their work faster.
This is where trade-off analyses and stakeholder input are needed to find the best solution for the overall program, not just for one team. Blindly relying on tools is unlikely to achieve a compressed timeline. A mix of good planning, pragmatic risk management, appropriate processes, relevant tools, and robust governance is needed to create an opportunity to compress the timeline.
Conclusion
When looking at the development times for today’s more complex airliners, several integrated toolchains from major vendors contribute to aircraft development, helping keep the development calendar time and workyears from increasing.
This leaves the AI side as the one that can improve the situation. We do our sum-up of the AI side in the series wrap-up Corner next week.
Related
