By Bjorn Fehrm and Henry Tam

November 21, 2025, ©. Leeham News: We do a series about ideas on how the long development times for large airliners can be shortened. New projects talk about cutting development time and reaching certification and production faster than previous projects.

The series will discuss the typical development cycles for an FAA Part 25 aircraft, called a transport category aircraft, and what different ideas there are to reduce the development times.

We will use the Gantt plan in Figure 1 as a base for our discussions. We are in the Detailed Design phase, and it’s time to conduct the Critical Design Reviews, CDRs.

Figure 1. A generic new Part 25 airliner development plan. Observe the CDRs. Source: Leeham Co. Click to see better.

Overview of Critical Design Review

The Critical Design Review (CDR) is a key part of the Detailed Design phase. Similar to the Preliminary Design Review (PDR), the Critical Design Review for an aircraft development program is not a single event but a series of reviews that ensure all work packages have reached a sufficient level of maturity before kicking off manufacturing and qualification tests.

According to NASA, the objective of the review: is to demonstrate that the maturity of the design is appropriate to support proceeding with full-scale fabrication, assembly, integration, and test.  CDR determines if the technical effort is on track to complete the system development, meeting mission performance requirements within the identified cost and schedule constraints.

Again, each company or organization has a slightly different CDR checklist tailored to its specific situation.  Here is a sample product/maturity table from the NASA Systems Engineering Handbook:

Figure 2. The NASA System Engineering Handbook list for things to review at the CDR (column after PDR). Source: NASA. Click to see better.

As illustrated in Figure 2, outputs (called products in the NASA sheet) from a CDR are very similar to those of the Preliminary Design Review, PDR, we wrote about in Part 13.

The main difference is the level of maturity. At PDR, the design could have many known risks or challenges with conceptual resolutions only. At the completion of CDR, the design solution for those challenges should be fully implemented and reasonably resolved.

There may still be some risk of the design solution not being sufficient, but those risks should be low.  There are also new items on the list, such as transportation criteria and instructions.  The wing supplier, for instance, works with the logistics team to conduct an analysis to ensure the wing can be shipped to the OEM. Will it go on a plane, boat, train, or truck? How should the supplier package the wing for shipping? Would the truck for the last mile have sufficient clearance when going under a highway overpass? These are only a few examples to consider.  A supplier needs to show that they can get the part to the final assembly line or to the test rigs.

Prior to Critical Design Review, all work packages should have their design completed, down to every nut and bolt.  The majority of datasets and required analyses should have been released.  A complete bill of materials is now available.

Certification plans should be agreed with the authority so that tests can kick off with minimal risk.  Qualification plans and some test plans shall be in good shape.  Some components, particularly those carried over from previous designs or those designed and manufactured to meet universal requirements, may have already started or even completed a great deal of qualification tests.

The aircraft configuration should be frozen, and only mandatory changes should be made after this point. From the certification standpoint, the team is getting ready to transition from the Compliance Planning phase to the Implementation phase. We’ll go into more details about the Implementation phase in a future article.

This is also a good time for the integration team to confirm that the aircraft can comply with requirements, as the design is fully mature, short of having actual parts and test data.  For example, if the battery for the hybrid system falls short of the volumetric density requirement by 30%, it is likely an issue, not a risk.

There is a significant amount of work to do on the business side of the program as well.  Now that the design is complete, it is time to update the business case. The team would revisit the scope, schedule, resources, non-recurring costs, and recurring costs to confirm the return on investment.

The risk database also needs to be updated to reflect the current situation.  Some risks, such as the seat crashworthiness risk mentioned in past articles, may have retired during the Detailed Design phase.  Other risks may have turned into issues, while new risks could have emerged.  For instance, if a new composite material for the fuselage has not been fully qualified by this time, it could be very risky to proceed.

At the end of each CDR, the work package and its supplier usually have a list of actions based on the discussions during the review. The review may take place sometime before the end of the Detailed Design phase, depending on the company and its policies.  As a result, CDR actions could include finishing releasing datasets by a deadline.  Again, if the team has properly prepared for the review, there should not be any major surprises.

Reality versus Plan

In a typical aircraft project, there can be several challenges during this phase.  For instance, a structure supplier used very optimistic assumptions at the beginning of the program.  They discovered that their product is significantly overweight during the Detailed Design phase.

The OEM, in this case, may employ a three-pronged approach:

• First, the team works with the supplier to help meet their weight budget. The supplier needs to optimize the design as much as possible.
• Second, the integration team reviews the design margins available. Squeezing margins at this stage could minimize the number of changes (and hence, potential cost).  However, it would leave the program more exposed to other risks.
• Third, the integration teams collaborate with other work packages to identify weight reduction opportunities, prioritize these ideas, and make appropriate change requests. These are multi-disciplinary efforts requiring support from Supply Chain, Customer Support, Manufacturing, and Program Management.

Pragmatic solutions usually end up with some margin reduction and design changes. This situation can also lead to a schedule challenge.  Would the team need to make these changes available on the static test rig, fatigue rig, or the first flight test aircraft? If not, when is the right time to introduce these changes?

These are important questions because they can impact manufacturing and testing. Furthermore, the supplier may not be able to complete all CDR deliverables on time.  This is when Program Management, Engineering, Supply Chain, and the supplier need to work very closely together to identify the best way forward.

CDRs, just like PDRs, need to take place in an appropriate sequence.  Failing to generate deliverables for CDR by one work package can affect the CDR preparation for other work packages.  As a result, the multidisciplinary team needs to use some creative ways to ensure that there is an acceptable level of maturity for early CDR teams, so that the packages don’t hold up the entire program.  Schedule delays are costly.

Challenges for Startups

Startups face their unique challenges.  Is the team developing a demonstrator or a certifiable product? While design considerations differ between the two, as discussed in the previous article, startups often don’t fully recognize the distinction.

For instance, a system startup wants to complete its system-level CDR in three months’ time.  However, the system startup has not established airborne software and hardware development processes. It is unlikely that this system startup can meet their schedule commitment if the system is intended for a to-be-certified platform. But it may be okay for a demonstrator.

A startup aircraft project needs to be careful. An ill-considered minimum viable system may actually be a non-viable, uncertifiable system, putting the whole project in danger (at the minimum, in a delay).