EN 
DE Practical experience from aviation
Author: Christian Glatzel, Zodiac Cabin Controls GmbH
Contribution – Embedded Software Engineering Congress 2015
This presentation will provide insights into interdisciplinary team structures that have proven successful when a project team collaborates over several years. The practical experience draws on development programs in the aerospace industry, including interactions with aircraft manufacturers such as Airbus, Boeing, and Bombardier. The aim is to clarify which potentially unexpected factors can either advance or derail a project.
This presentation is neither a guide to applied psychology nor a new type of management technique. It offers a perspective beyond one's own area of responsibility, drawing on the daily realities of development within an aerospace engineering company. It will illuminate the understanding of certain behavioral patterns on both the technical and human levels, thereby contributing to a renewed focus on the company's overall success and preventing everyone from being preoccupied with individual risk minimization. The following discussion is based on feedback from 30 software engineers from 8 nations and 135 engineers from 16 nations.
In what kind of environment must the team "survive"?
- What are the customer's interests?
- What are the interests of the in-house management?
- What strategy lies behind this development?
The infamous triangle "Good – Cheap – Fast" (you choose 2 qualities and consequently the 3rd quality will certainly not occur) will be familiar to many (see Fig. 1, PDF).
At this point, however, three perspectives (customer, management, and strategy) must be reconciled, keeping in mind that the same attribute can be valued differently. If in-house management requires "cheap and fast," the customer might see this as "good and cheap," because different expectations regarding the timeframe can arise. A similar situation can occur with the attribute "cheap." If something appears "cheap" from a strategic perspective, it might be "good and fast" from the customer's point of view (see Fig. 2)., PDF).
Now that you have aligned three triangles, you should be aware that this state only reflects a specific point in time! Especially with long project durations, you should be aware of the consequences of a shift in priorities during the project.
It has been shown that "accepting" a characteristic is only possible from among the remaining characteristics. If a project starts "good and inexpensive" (i.e., is not fast) and after a certain time a management decision demands "good and fast" (consequently no longer inexpensive), the result will indeed be "good," but neither "inexpensive" nor "fast" (see Fig. 3)., PDF).
Which people can work together?
- Do you have a poison cabinet?
Imagine you have a large cabinet full of medicinal substances in your office. You can mix these substances however you like on your workbench. Depending on your luck, you'll create something wonderful or disastrous. Now replace the medicine with your employees and the workbench with a specific project. The way you group your employees into teams will determine whether those teams, and therefore you, win or lose.
- Can you moderate?
If team members can tolerate each other but would prefer to avoid one another, you can still forge a successful team through facilitation. Establish clear ground rules that everyone perceives as fair. The team needs to trust its environment and the rules to deliver optimal performance.
- What motivates a person?
Have you ever wondered why some people want to work on a project? Are they interested in the technology, the potential market success of the result, or simply in other team members? In the long term, the interests of the employees should align with the project goals (technology or economic viability).
- What types of people should you bring together?
Attention: In the following section, a supervisor must form an opinion about their employees! To do this, they should know them! And if the opinion they've formed turns out to be wrong, the supervisor should revise it!
If you want to successfully manage projects spanning several years, it's not enough to simply throw people with the necessary knowledge into a team. If a brilliant dreamer is expected to work in a team of passionate, man-hour-counting types, the dreamer will very likely fail. He won't gain the trust of the man-hour-counters while he's still mentally exploring possibilities on his own. Then, he'll be micromanaged so closely that his "perfect solution" never emerges and, consequently, isn't implemented.
If you want to divide the world into dreamers, realists and critics, you should look at the Disney strategy [1].
In our company, in the aerospace industry (long development times, many changes, very small production runs), it has proven beneficial to have a small number of "dreamers" alongside many "doers" and a single point of contact for external communication (interface with program management, customers, etc.). This streamlined communication has allowed the dreamers to operate largely under the radar of external monitoring, thus driving the project forward with perfect solutions.
You should also consider the team dynamics that arise when you bring together several people with the same "personal expertise" (experts) in one team.
Many people have pondered how far someone needs to move within or outside their personal "comfort zone" to be as productive as possible. In my opinion, this statement shouldn't be generalized, because a dreamer needs their comfort zone to develop brilliant ideas, while other people work under pressure to create perfect, effective solutions.
Ultimately, building teams is a matter of trust and distrust. Both can be productive in the short term. In the long run, however, trust is clearly preferable, at least in my experience.
One should remember the "poison cabinet": The chemistry between the employees must be right if one not only wants to complete the project, but also win over the employees for follow-up projects.
Practical examples
- General note
Aircraft manufacturing is a "special" industry. It involves the delivery of very high-priced devices with software in extremely small quantities (often <1000 units/year) over a very long period (20+ years) (e.g., compared to the automotive industry). The requirements for traceability of design decisions as well as the manufactured devices generate a large number of documents of various types. In addition, device development usually requires a high degree of international communication at a technical level.
- European aircraft
Why do we think we know everything before we do anything?
„"We Europeans have hundreds of years of experience and endless shelves of norms and standards, so we know what a subcontractor needs to deliver to us, how, and with what details, even before we commission them."“
When purchasing services, the results delivered should be valued. Nobody likes to hear their work dismissed as trivial. When a supplier delivers something, they consider themselves an expert in their field and believe they've delivered a good result – then to hear the blanket statement that the customer knows better is hardly conducive to building trust. To be clear, however: if someone delivers something poor, it must be addressed and a solution found. If someone delivers something good, that should also be acknowledged. It's important to ensure that, despite all the standards that need to be met, the overall development goal remains intact. For example, it's rarely a good idea to design an airplane toilet to be so safe that the probability of failure is lower than the probability of the entire aircraft crashing…
- North American aircraft
Why do we do everything immediately and only think about it later?
„"Always these Europeans. They talk everything down and create nothing of value... Just paperwork. We (US) Americans want results, products we can hold in our hands. Then we can write down what we've come up with."“
The loss of information that occurs when detailed solutions are implemented solely in the electrical design or source code without proper documentation will inevitably lead to obvious, and sometimes even fatal, deeply hidden errors in subsequent projects. This approach is well-suited for quickly creating prototypes with specific behaviors. However, due to the poor documentation, the prototype should be discarded, and a production device should be developed from scratch. In this type of project, you risk overlooking thorough planning through hasty action, ultimately resulting in significant rework.
- Asian aircraft
Why do we meet the standards and still have problems?
„Something isn’t right here. We’ve met all the standards and thoroughly checked all our subcontractors according to the official questionnaires. But our aircraft still needs to be reworked and isn’t perfect on the first try. Our LEAN management [2] needs to be improved so that we can quickly resolve these problems – we need more meetings and reporting; actual implementation is becoming secondary.“
Such projects are often plagued by mistrust and fear! This mistrust stems from a fear of failure – for example, due to a "first time right" demand coupled with the threat of consequences in case of an error. This mindset often leads to perfect functional descriptions and interface documentation, but the overall interaction of the devices is not guaranteed, as requirements for individual devices always involve a degree of modeling and therefore offer a simplified view of reality. For example: Measure the fill level in a tank. If you overlook the fact that the liquid might slosh around considerably, your measurement is unusable. However, the sensor requirements might neglect to define the environmental influences (e.g., potential G-vectors) on the liquid.
If you have developed a perfect solution according to general standards, but the communication regarding this solution does not meet the social and technical expectations of the customer, it will take a lot of time to sell this solution to the customer.
You need employees who can empathize with this customer mentality because it aligns with your personal working style! In particular, the customer contact person must understand the customer's social background so that the company can deliver a product perfectly tailored to the customer's needs.
Summary
There is no perfect, universal plan for building a team. When planning a project, you should dedicate a significant amount of time to considering social aspects – both between team members and with other people the team interacts with. If you think that in today's world, thanks to digital social networks, most people share the same values and goals, you are sorely mistaken.
List of illustrations
Fig. 1 Fast-Good-Cheap (see PDF)
Fig. 2 Fast-Good-Cheap weighted from different perspectives (see PDF)
Fig. 3 Fast-Good-Cheap with time axis (see PDF)
Bibliography and list of sources
[1] https://de.wikipedia.org/wiki/Walt-Disney-Methode
[2] https://de.wikipedia.org/wiki/Lean_Management
Process, product and project management – our training & coaching
Do you want to bring yourself up to date with the latest technology?
Then find out more here MircoConsult offers training courses/seminars/workshops and individual coaching on the topics of process, project and product management.
Training & coaching on the other topics in our portfolio can be found here. here.
Process, product and project management – expertise
Valuable expertise in process, project and product management is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
