top of page

Cultural Alignment between Prime Contractors and Suppliers in Engineering

  • Gian Giacomo Ermacora
  • Sep 12
  • 10 min read

Ontology, Processes, Milestones, and a Harmonized Culture between Prime Contractors and Suppliers as Enablers of Success in Complex Programs


How the concept of multiple V models (multi-Vee) can support processes in the development of complex systems.


Today, the engineering, development, and production phase of complex systems is no longer the prerogative of a single company. No matter how large—or even enormous—a company may be, it will always rely on multiple suppliers who collaborate by providing components, subsystems, semi-finished goods, or highly specialized activities, up to supplying personnel to support projects.


Inevitably, it is common to encounter terminology derived from company-specific practices and habits which may sometimes be improperly assigned, or even fragmented, by these suppliers. The result is the introduction of ambiguities which, through subjective interpretations, translate into delays, misunderstandings, and additional costs. In fact, the first step toward true cultural alignment between prime contractors and suppliers should be the adoption of a shared language. This is not mere rhetoric, but the concrete need to adopt a common terminological dictionary, defined by Systems Engineering practices and, in particular, by INCOSE international standards.


A supplier capable of rigorously adopting the languages and processes defined by INCOSE standards—together with practices promoted by OMG and IREB—gains a tangible competitive advantage in the bidding phase. The customer immediately recognizes a well-aligned partner, capable of integrating seamlessly into the prime contractor’s processes without friction.


The presence of professionals certified according to these standards therefore constitutes a clear signal of competence, credibility, and reliability. The approach we outline below stems from the analysis of international experiences, in which different strategies for collaboration between customers and suppliers were tested. From these experiences came the formalization of the multi-Vee concept, increasingly adopted today as a reference model to govern complexity in multilayered systems.


The Multi-Vee model

For many years, the "V" model, commonly known as the Vee Model, has been used as a graphical representation of the cyclical nature of the systems lifecycle, which begins with the identification of user needs and culminates in the delivery of a validated system. The SEBoK defines the Vee Model as a predefined, sequential model [1] that organizes the fundamental activities of systems engineering into clearly aligned and balanced phases.

 

In particular, the "V" represents:

 

  • on the left side, the disaggregation of the system: from requirements analysis, through architecture structuring and specification definition;

  • on the right side, the reverse process: component integration, verification and validation, up to the delivery of the complete system.

 

This model facilitates a clear articulation of responsibilities and rigorous control of deliverables, improving requirements traceability, project quality, and risk management [2].

In recent years, the concept of a multiple V-model (multi-Vee) has emerged, which can in fact assume a central role, especially in the presence of subsystems entrusted to different suppliers. Each subsystem follows its own V-life cycle, divided into the phases of requirements definition, design, implementation and verification. These cycles, although developing autonomously, are not independent: they are progressively integrated into the main life cycle, represented by the overall V of the system [3].


Image 1 - An example of Vee-Model
Image 1 - An example of Vee-Model

This multi-Vee approach proves particularly effective in technology-intensive fields, such as aerospace, automotive, or defense, where the complexity of systems and organizational chains requires the coordination of a large number of stakeholders.


For example, consider the development of an aircraft: the avionics, propulsion, and structural subsystems are designed and verified according to "V" processes, which are effectively distinct, and which then flow into the "V" of the prime contractor's overall program, which will govern their integration and functional coherence.


A similar situation is observed in the automotive industry, where propulsion systems (electric and otherwise), infotainment, and active safety systems follow independent development paths—sometimes they are actual "catalog" products—developed by the supplier company almost like "black boxes," and which are then destined to converge into a single integration and validation framework at the vehicle level. This convergence phase often requires small modifications to the product, activities that are governed by "non-formal" and non-standard de facto processes, such as those of the OPL (Open Point List), which perfectly denote the misalignment between the main "V" and that of the product in question.


The multi-Vee model is fully aligned with international Systems Engineering standards, from a methodological standpoint. In particular, ISO/IEC/IEEE 15288, which defines, among others, the life cycle processes of a complex system and the INCOSE guidelines, as well as most standards in the SE field, underline the need to ensure traceability between requirements, architectures and verification activities, without forgetting the rigorous management of interfaces between subsystems: elements that constitute the cornerstones of the multi-Vee logic.


Image 2 – Schematic representation of Multi-Vee
Image 2 – Schematic representation of Multi-Vee

In this multi-Vee representation, the V-shaped cycle of each subsystem is “nested” within the life cycle of the higher-level system, giving rise to a multi-level structure known as layered Vee. This symbolic configuration precisely and systematically represents the design complexity and allows for the traceability of requirements and verification activities of each level, furthermore ensuring coherent integration with heterogeneous subsystems in the main system.


Clark [6] introduced the concept of layered multi-Vee models, in which the “V”s of the subsystems are aligned and interconnected with the “V” of the overall system, which is then taken up in a similar approach by NASA, which through the Layered Vee Diagram represents parallel systems engineering activities organized hierarchically in a system-of-systems context [4].


The main advantage of this approach is that each supplier can independently conduct its own development cycle, from requirements definition to verification and validation, while maintaining a connection to the overall system objectives and traceability, which thus becomes virtually "navigable" not only within the main system but also towards its constituent systems (subsystems).


As you might imagine, even subsystem-level verification activities can be planned to meet the main system's criteria, ensuring that, during the final integration phase, the components are consistent and compliant with global requirements.


In this sense, the multi-Vee model establishes a structured link between the suppliers' and prime contractor's development processes, ensuring consistency in interfaces and expected performance.


Process Integration Between Customer and Supplier

Therefore, by first working on cultural alignment between customer and supplier, and building this understanding on a solid foundation (INCOSE), it goes without saying that some processes, until now siloed and separated between companies, can gradually become more integrated.


International standards such as ISO/IEC/IEEE 15288 emphasize the need to establish buyer-supplier agreements that clearly define activities, deliverables, and acceptance criteria for both parties in a complex project. This could translate into aligning several key areas, which we will highlight below as an example for potential process improvement.  


Shared requirements management


Today, customer system requirements are allocated and transformed into subsystem requirements; suppliers must accept them, fully understand them, and maintain traceability. But too often, suppliers are not made aware of the full complexity of the system or of certain required features, which can become unclear and sometimes even cause for discussion and misunderstanding between the parties. Essentially, it is in the interest of both parties to adopt effective requirements engineering processes, as this reduces risks and misunderstandings during development. For example, the supplier and the customer can use the same tool or format for requirements tracking, establish common baselines, and share change control processes, so that every change to the requirements is visible and mutually agreed upon.


Integrated planning and milestones


The supplier's development plan must be synchronized with that of the prime contractor. To ensure the effectiveness of smooth and seamless development, it would be advisable to define and maintain shared plans that contain integrated planning and milestones between the client and the supplier.


An example could be the use of Integrated Master Plans (IMP) and Integrated Master Schedules (IMS)[5], where:


  • Integrated Master Plan (IMP) is an event-centric plan that lists key project events (e.g., milestones, reviews) with the related completion criteria.


  • Integrated Master Schedule (IMS) is the detailed timeline of all activities (both prime and subcontractor) required to achieve those events.


A shared IMS ensures that subsystem delivery dates, testing phases, and progress meetings are aligned between the client and suppliers.


In this way, the client and suppliers jointly set contractual milestones and represent common objectives: both know what to expect at each stage, to avoid, for example, situations where the supplier delivers late compared to the integrated system's needs, or uses intermediate stages unrecognized by the client. An integrated plan mitigates these risks by making each party's dependencies and responsibilities transparent.


Joint Verification and Review


Process integration should also include verification, validation, and quality control activities, so that prime contractors and suppliers can conduct joint technical reviews at key stages. A joint Preliminary Design Review, for example, can allow the client to gain visibility into the supplier's preliminary design, ensuring it meets the allocated requirements before proceeding. In this case, the entry and exit criteria for each review must clearly be part of the buyer-supplier contractual agreement, which means that, culturally, both organizations should agree to subject their work to cross-evaluations, according to shared standards. By introducing this significant aspect, we can eliminate, or at least reduce, the "us versus them" attitude that unfortunately often occurs, replacing it with a collaborative approach geared toward mutual and program success.


In practice, the supplier adopts the prime contractor's quality mindset, and the prime contractor actively involves the supplier in its system verification activities.


Shared Practices: MBSE, Common Ontologies, and Synchronized Milestones


Beyond processes, true cultural alignment relies on the adoption of shared practices and tools. Three aspects in particular emerge as facilitators:


  • Shared Model-Based Systems Engineering (MBSE): The use of MBSE methodologies by all parties involved creates common ground for collaboration. We covered this topic extensively in an article some time ago, which you can find here: From Model to Mindset: The Real Challenge of Model-Based Systems Engineering. MBSE involves forming teams, agreeing on modeling conventions, and investing in compatible tools. But once the initial curve is overcome, the collaborative benefits are evident. As INCOSE also emphasized, MBSE represents a cultural as well as technical shift, requiring sponsorship and organizational coaching, but enabling new and more integrated ways of working.


  • Shared ontologies and terminologies: Using a common model also requires speaking the same language. This is where the importance of shared ontologies comes into play.


Note: An ontology, in SE, is a formal definition of concepts and relationships in the specific domain.


If the customer and supplier agree on the same ontology, underlying ambiguities are avoided.

Having a reference ontology means that the tools speak the stakeholders' language, defined by the ontology itself [7]. Modern initiatives (such as the development of a Space System Ontology by ESA and industrial partners) aim precisely to create common vocabularies to improve co-engineering between different industries.


Similarly, SySML, thanks to the v2.0 revision, will be able to introduce a common meta-model and more rigorous semantics, enabling shared domain libraries that are understandable (as well as non-misleading) to all, improving multi-company collaboration [8].


An effective quote from a survey on MBSE states: “a common metamodel and a shared ontology in domain libraries enable collaboration” [8], in fact once there is agreement on the meaning of key terms and on the data structure, the integration of work becomes much more fluid.


  • Synchronized Milestones and Common Stage-Gate Approaches: We've already mentioned the importance of an integrated plan; here we return to the concept of synchronized milestones as a cultural practice.

Synchronizing development timelines is undoubtedly essential for consistently managing the engineering and production of complex systems, but defining quality criteria is equally fundamental.

Strong alignment may require the prime contractor and suppliers to adopt the same lifecycle checkpoints: for example, they agree not to move from the detailed design phase to the integration phase without passing some defined unit tests, or more commonly, internal reviews.


This alignment eliminates situations in which the supplier might declare work completed that the customer does not, precisely because of the difference in identified and valid quality criteria.


In an aligned cultural context, everyone recognizes the same "Definitions of Done" at the various phases, just as it would be desirable to understand the concept of customer "value" [9].


Cultural alignment between prime contractors and suppliers in complex systems engineering programs does not happen by chance but is the result of deliberate process and tool choices. By adopting uniform cultural foundations (INCOSE and ISO 15288), compatible lifecycle models, and finally introducing practices like MBSE with shared ontologies and aligned milestones, organizations can operate as one extended team.


Official sources—from ISO/IEEE standards to INCOSE handbooks and DoD/NASA guidelines—all converge on this point: an integrated, systemic approach is essential to the success of complex projects.


This alignment requires slightly changing the common approach we are accustomed to; it doesn't just involve investing in contracts and procedures or supporting software tools, but rather building trust, mutual understanding, and a unified vision of technical objectives as much as possible.


When true cultural alignment is achieved between supplier and customer and a shared culture, methods, and vision are achieved, the result is a drastic reduction in delays, as well as rework and misunderstandings. On the other hand, you will have a drastic increase in the probability of delivering a system that complies with the requirements and within the expected time and cost!


ONE-SYS – your evolutionary companion 

In an increasingly complex and competitive environment, where multi-stakeholder programs require systemic vision, technical expertise, and, above all, cultural integration, ONE-SYS is the ideal partner for anyone working in the world of Systems Engineering.


ONE-SYS – your evolutionary companion – is an independent company that has been working alongside major international players in the aerospace, defense, automotive, naval, and medical sectors for years. Our mission is clear: to support organizations in the evolution of their engineering and production processes, making them leaner, more traceable, integrated, and value-driven.


We stand out for our approach that combines methodological rigor and operational flexibility. Thanks to ongoing investment in research, development, and training, we support our clients in the transition from traditional document management to more advanced paradigms, such as MBSE, template management, the adoption of interoperable tools, and alignment with major international standards (INCOSE, ISO/IEC 15288, OMG, IREB).


Our team is made up of certified and highly qualified professionals, capable of supporting organizations in the design and implementation of new processes, as well as in the optimization of existing ones. We don't limit ourselves to theory: we co-engineer solutions with the client, bringing tangible innovation and continuous improvement to fruition.


Whether it's defining a requirements traceability framework, implementing a consistent multi-Vee lifecycle, or facilitating cultural alignment between prime contractors and suppliers, ONE-SYS can transform complexity into competitive value.


We support our clients throughout all phases of the project, from the initial proposal to delivery, all the way to the application management of fully operational systems. And we do so by speaking the language of our stakeholders: technical yet clear; systemic yet operational; structured yet adaptable.


In an era where integration is no longer an option but a fundamental requirement, choosing ONE-SYS means choosing a partner capable of harmonizing people, processes, and technologies throughout the entire system lifecycle.


Contacting us today can make a difference tomorrow. Because in a complex world, evolving isn't just an opportunity. It's a necessity.


And we're here to support you, every step of the way.


Resources

[1] - Vee Life Cycle Model 

[2] - The System Engineering Vee - is it Still Relevant in the Digital Age? 

[4]  - Layered Systems Engineering Engines - NASA Technical Reports Server (NTRS) 

[5] – ndia.org  

 

[6] – John O.Clark - System of Systems Engineering and Family of Systems Engineering From a Standards, V-Model, and Dual-V Model Perspective 

[9] Create Value for the Customer - https://shingo.org/create-value-for-the-customer/  

 
 
bottom of page