How Do You Escape Pilot Purgatory in the World of Aerospace Manufacturing?
Even at a company as well-established as Airbus, with 50 years of history and a successful product line and development process, it can sometimes prove challenging to introduce innovations and useful changes to the way we work.
This week, I spoke at the Connected Manufacturing Conference about some of the challenges of running innovative pilots that end up getting stuck in a kind of “pilot purgatory”—a phenomenon that so often plagues improvement projects in large manufacturing organizations—and I outlined some of the strategies our team at Acubed has found to overcome them.
While our innovation center was purposefully set up to be geographically distant from Airbus in Europe to allow for more freedom of innovation, that same distance can sometimes turn against us as we begin the process of implementing our tools across the wider organization, leading to stalls as we move from implementing a pilot to turning that demo into a real tool that can be used more widely in the company.
Many forces at play
As we all know, delivering an improvement in a large organization is never easy. In our experience, it’s all too common to run into:
- Politics: Competing projects, vendor relationships and strategies
- Endless Additions: Features get added, and the scope creep never allows you to finish
- Working with the Wrong Stakeholders: While they may be well intentioned, it’s more productive to work with the group who will inevitably push your project forward and use the tools you’re developing
- Fear of Acceptance: Questioning as to whether the rest of the business will like the new tools
- Fatigue: Starting off with great progress and great support, then losing it if development isn’t fast enough
- Similar Pilots: For almost any initiative, someone has done something similar in the past and has a story about how it won’t work or won’t be accepted
- Long-Term Support Strategy: Concern over support in the event the pilot moves on to being a full-fledged tool before the pilot ever gets off the ground.
Our early development approach
When we first started out on the ADAM project almost four years ago, we were constantly falling into these traps. And, accordingly, our software and digital tools would be packaged up very nicely with their documentation and metaphorically put on a shelf.
We got out of this cycle through applying effective stakeholder management. We began to work with people who would truly push our work forward and champion it in the organization. However, this wasn’t enough, as we had assumed everyone outside the core group would come along for the ride. Yet a number of our pilot activities stalled because our team and our stakeholders were still running into the same pitfalls mentioned above.
To really drive stakeholder interest, involvement, and continued support, we’ve brought up our timeline on User Interface design and User Experience development (UX & UI). We work up front to have a common understanding with our stakeholders of the end tool. Delivering, then expanding the product gives your stakeholders something they can see, use, and review even as new features are developed.
We can then take this stakeholder list, application definition, and development timeline and start meeting with more senior management to build support at the top. This gives us some mindshare with the management team and allows us to push for the formal support we need from them, via a signature from them to formally kick off full-scale development.
From there, we can drive stakeholder engagement by pulling in members of the team that will be using the end application. While the members of the stakeholder team may or may not have much development experience, this builds ownership within the receiving organization and familiarity with the new tools. This relationship can work out as a give and take: we may not end up developing the exact tool we set out to develop but will end up with a tool better suited to the team’s needs.
As a case in point, we once worked on a piece of software to optimize the movement between stations on a production line. We received repeated requests to customize the software to a specific use case involving final aircraft assembly, but had to reject the requests as they prevented the tool’s use on detail part production lines due to the way we use stations in each line. It did lead to us finding an optimal way to incorporate our stakeholder’s request that worked equally well. Over time, we’ve built up the awareness to know and identify which types of changes we should and should not entertain to avoid over-customization.
As we’re working every day with our stakeholders at the user level and continually pushing updates for them to test, it’s tempting to forget to update up the chain. We have started to build small update presentations and emails into our process to make sure we don’t lose that ever-important support from higher levels of management.
Implementation approach
As we move towards implementation, there are three main questions we systematically ask ourselves:
- Are we increasing user satisfaction? Usability improvements will generally come alongside feature upgrades so we can evaluate how it works, whether it’s usable, and whether the improvements are tangible to the end user.
- Did we meet the original need? We set out to solve a particular problem, so have we met the needs of the users? If we have, we might consider a general roll-out.
- Can we fit the roll-out into a development timeline? Basically, this comes down to whether we can meet the needs of the business before the next product design or update cycle starts.
These criteria may seem minimal, but continually asking these three questions increases the likelihood of the development staying on track, and ensuring an industrialized application can be rolled out when the business needs it.
Takeaways
Over the past several years, we’ve learned:
- To recognize the value of UX & UI in keeping our stakeholders involved - we have an expert embedded in our team
- To strike the right balance of customizations, keeping our software reusable for the next engagement
- To monitor how we increase customer satisfaction
- To know our true stakeholders in the rest of the business, and how to identify who will push projects forward in new engagements
- And finally, to remember we’re part of something bigger: we need to sync up with the larger organization to make an impactful change.
Following this strategy, the ADAM team has built tools to enable new aerospace manufacturing analyses that weren’t possible with traditional methods. We’ve cut process times in both manufacturing and engineering by more than 50% in the areas we’ve worked on, while continuously providing tools that solve issues in the rest of the business. And that gives me the energy and momentum to continue my work to help digitize Airbus’ aerospace manufacturing organization and processes and make my Airbus colleagues’ lives a little bit easier.