How an aerospace engineering team transformed a complex 700+ feature challenge into a focused, repeatable approach to achieving higher process capability.

When the Quality Target Is Clear but the Path Isn’t

A Cpk of 2 sounds like a straightforward quality target. In complex aerospace and aeronautical engineering environments, however, reaching that level of process capability can involve hundreds of variables, multiple components, tight specifications, and teams working across different functions.

A recent improvement initiative with an aeronautical engineering client demonstrated an important lesson: sometimes the biggest barrier to quality improvement is not technical complexity. It is organizational paralysis.

The client had set an ambitious goal of improving Cpk from approximately 1 to 2 across three parts. The challenge was that more than 700 features required attention…

The scale of the problem made it difficult for teams to determine where to begin.

When Too Many Actions Stop Progress

The engineering teams were working in silos, with numerous improvement actions being discussed simultaneously. Instead of creating momentum, the sheer volume of actions created confusion and stalled execution.

The project remained largely inactive for three to four months.

This is a common challenge in complex engineering environments. When every issue appears important, teams can struggle to distinguish between critical actions, quick wins, and longer-term improvements.

The solution was not to add more analysis.

It was to simplify the problem.

Step 1: Rescope the Problem

Rather than attempting to improve three parts simultaneously, the project was rescoped to a single part.

This created a focused improvement environment where the team could establish a baseline, prioritize the relevant features, implement improvements, demonstrate results, and build a repeatable method before expanding the approach.

Reducing the scope did not reduce the ambition. It created a practical path toward achieving it.

In complex engineering environments, this distinction matters. When every feature appears important, trying to address everything at once can dilute ownership and slow execution. Focusing on one part gave the team a defined problem to solve and a measurable outcome to pursue.

Step 2: Create Daily Execution Discipline

With the scope narrowed, the next challenge was execution.

To restore momentum, the team introduced a strict daily YTT — Yesterday, Today, Tomorrow — meeting. The format was simple: What was completed yesterday? What needs to be done today? What needs to happen tomorrow?

The value was not in the meeting itself. It was in creating a daily operating rhythm around the improvement effort.

Progress became visible. Ownership became clearer. Roadblocks could be addressed earlier, and improvement actions were no longer dependent on periodic reviews.

Instead of asking, “What is the status of the project?”, the team began focusing on what needed to move forward every day.

Step 3: Turn Hundreds of Actions into Priorities

The team then reviewed the existing action items and mapped approximately 90% of them into a simple part-feature matrix.

This created a visual connection between the selected part, its features, and the associated improvement actions. Instead of looking at hundreds of actions as one large problem, the team could see where actions were concentrated, which features required attention, and where opportunities for quick implementation existed.

The exercise resulted in approximately 60 quick wins being identified.

More importantly, the team could finally see a manageable path forward.

The conversation shifted from “There are too many things to fix” to “We can see where to start.”

That change in perspective was critical. Once the problem became visible and prioritized, execution became much easier.

Step 4: Build the Improvement Flow

The next objective was to make sure the learning did not remain limited to a single improvement project.

The team developed and handed over an improvement flow playbook that captured the approach used to identify capability gaps, connect them to specific features, prioritize actions, establish ownership, drive execution, and measure results.

This transformed the initiative from a one-time improvement effort into a repeatable method.

The value of such a playbook is not simply that it documents what happened. It gives teams a structured way to approach the next part, the next feature, and eventually the next set of parts without having to start from zero each time.

The Result: Cpk 2 Was Achieved

The most important outcome was measurable.

The team achieved the targeted Cpk improvement, moving the selected part from an approximate Cpk baseline of 1 toward the Cpk 2 objective.

This demonstrated that the problem was not simply the number of features involved. Once the challenge was narrowed, visualized, prioritized, and supported by disciplined execution, the team was able to convert complexity into measurable process capability improvement.

And the achievement provided something equally valuable: proof that the improvement approach worked.

From One Part to 30+ Parts

The next opportunity is scale.

The improvement flow playbook can potentially be cross-deployed across 30-plus parts, creating a common framework for future Cpk improvement initiatives.

The objective is not to create 30 separate improvement projects, each requiring a completely different approach. It is to establish a repeatable improvement system that teams can adapt to different parts while maintaining the same fundamental logic.

That means identifying capability gaps, prioritizing the features that matter most, executing improvements with clear ownership, measuring the outcome, and carrying the learning forward. This is where an individual improvement project starts becoming an organizational capability.

The Bigger Transformation

The most important outcome was therefore not simply the improvement achieved on one part. The project changed how the engineering team approached quality improvement.

Instead of seeing Cpk as a metric that needs to be corrected when production performance falls short, the organization can begin treating process capability as an engineering consideration much earlier in the product lifecycle.

This creates an opportunity to bring Cpk thinking upstream into engineering and design. Rather than discovering during production that a characteristic is difficult to manufacture consistently, engineering teams can ask earlier: Can the intended tolerance be achieved reliably? Which characteristics are likely to create capability risk? Where should engineering attention be concentrated? What can existing production data tell us about future designs?

That creates a shift from correcting capability problems after production begins to designing with capability in mind before production starts.

The Takeaway

Complexity does not always require a more complicated solution.

When improvement projects become overwhelmed by hundreds of features and actions, the answer may be to reduce the scope, create execution discipline, visualize the problem, and prioritize what can move the needle.

In this case, the progression was clear: 700+ features were brought into focus, approximately 90% of actions were mapped, around 60 quick wins were identified, the Cpk 2 target was achieved, and a repeatable improvement flow was created with the potential to scale across 30-plus parts.

But the bigger achievement was not the number itself.

It was creating a way of working that allows engineering teams to move from complexity to clarity, from isolated actions to structured execution, and from reactive quality improvement to designing for process capability before production begins.

The goal was to improve one part. The bigger achievement was creating an engineering approach capable of delivering Cpk 2—and making that approach repeatable.

Is your engineering team struggling with complex quality targets? SKIL Global can help simplify the problem, prioritize improvement opportunities, and build a scalable path toward higher process capability.

FAQs