SUPPLIER INTEGRATION IN PRODUCT DEVELOPMENT: A MATTER OF DESIGNING THE PROJECT STRUCTURE

In product development close collaboration between systems integrators and suppliers is important. The purpose of this article is to investigate the impact of the work breakdown structure (WBS) and work packages (WPs) in product development on the possibility of carrying through the strategy of supplier involvement into collaborative practice and to investigate how supplier involvement can be improved by altering the design of collaborative WBS and WP structures. Dependence Structure Matrix (DSM) is introduced in order to analyse, visualise and manage interdependencies, in terms of information exchange between the systems integrator and supplier. This article shows how DSM can support the alternative design of integrated and collaborative WBS and integrated WPs following the logic of dependencies and the flow of information in order to support a strategy focusing on integration of suppliers on project and team level.


INTRODUCTION
The increased internalisation and globalisation of businesses has increased the focus on integration of suppliers.Global supply chains, rather than individual companies, are increasingly competing against each other.These global conditions demand flexibility and responsiveness in the supply chain in order to communicate between customers and suppliers and to respond to changing demands and product and service delivery.This is a situation that many companies are facing all over the world, and also in the South African context.Supply Chain Foresight 2005 (an annual report on supply chain trends in South Africa by Barloworld Logistics) stressed that in 2005, compared to 2004, corporations needed to increase their effort to collaborate, particularly with their suppliers.As many as 69% of respondents to the Supply Chain Foresight 2005 survey stated that global competition presents a challenge to achieving a high level of integration with suppliers.This challenge to integrate involves the integration of internal processes and information among organisations in the entire supply chain.Lack of integration could represent a major obstacle to the achievement of supply chain efficiency in terms of supply chain flexibility, responsiveness and cost reduction.Supply Chain Foresight 2005 indicated important attitudes, with over 80% of respondents indicating collaboration as a key objective to meeting strategic objectives, compared to 40% in 2004.Supply chain strategies in 2004 favoured internal, silo-based improvements such as inventory, transportation, procurement etc.
"In 2004's report, there was a strategic awareness of supply chain importance but there was an operational disconnect from the strategy (Supply Chain Foresight, 2005: 4)." In the 2005 investigation companies stressed that a high degree of integrated planning and execution across functions and corporations, customers and suppliers in the entire supply chain, and greater alignment between strategy and operations, was important for achieving strategic goals.Over 90% of respondents claimed that the supply chain is a key part of their company strategy and that much more effort must be put into developing collaboration and particularly exchange of information with their customers and suppliers.This focus on collaboration with suppliers in the South African context can be compared to the Japanese attitude to and relationship with suppliers.A major reason for the success of Japanese companies in general is their competence in collaborating with suppliers.The Japanese lean production system uses a small number of suppliers (Womack, Jones & Ross, 1990;Womack & Jones, 1994), who have responsibility for larger modules and who join the product development work at an earlier stage.Some empirical evidence suggests that Japanese suppliers perform four times more engineering work for a specific project than US suppliers, while Europeans are somewhere in-between (Clark & Fujimoto, 1991).The incorporation of suppliers into a firm's development process is considered a major factor in a shorter development cycle and better products (Clark & Fujimoto, 1991;Backhouse & Brooks, 1996).The Japanese way of working with suppliers requires a high level of integration between the supplier and the systems integrator (Lamming, 1993).For this reason, the potential benefits of strategic alliances with suppliers have received considerable attention (Bonaccorsi & Lipparini, 1994;Fruin, 1992;Lamming, 1989;Lamming, 1987;Lyons, Krachenherg & Henke, 1990;Quinn, 1992).
On the strategic level the arguments for close supplier involvement sounds reasonable.
However it is unclear how this can be achieved on the operational and team levels incorporating engineers from both the systems integrator and suppliers' companies, particularly if such collaboration is performed in the global international environment.It is obvious that the strategic approach emphasises close collaboration but this strategically important ambition needs to be clarified as to how it can be carried out through the organisational levels, departments, cross-functional teams and the individual engineering level.Otherwise the strategy of a high level of supplier involvement is still only strategy and the practice is the same old way of running development work.
The need for close collaboration between functions and corporations is of course related to the complexity of products that has been increasing over the years.The more complex the products, the more technologies are involved in the process of product development; and the higher complexity and uncertainty needs to be handled by managers as well as by engineers.Integrated product development implies breaking down product architecture into components.Division of work into activities requires integration of components into modules and activities into packages.In industry, decomposition of the product architecture or task structure is named work breakdown structure (WBS).The combination, or integration, of components into chunks is named work package (WP).
The purpose of this article is to investigate the impact of the WBS and WPs in product development on the possibility of carrying through a strategy of supplier involvement into collaborative practice and to investigate how supplier involvement can be improved by altering the design of collaborative WBS and WP structures.The hypothesis underlying this investigation is that the design of the WBS and WPs is an important issue in understanding why suppliers were not involved in product development as expected.To approach this problem, I have chosen to study one of the most advanced and complex contemporary products, namely the military aircraft JAS 39 Gripen, developed and manufactured by Saab Aerospace in Sweden.The South African Air Force has recently bought a large numbers of JAS 39 Gripen and many South African suppliers are involved in the manufacturing and development of the aircraft both for the South African Air Force and for joint export with Sweden to other countries.The issue of integrating suppliers with systems integrators is therefore relevant in general and in particular to this industry in South Africa.

SUPPLIER INTEGRATION IN THE AEROSPACE INDUSTRY
In the aerospace industry many aircraft corporations manufacture only 20-40% of the components and systems in an aircraft themselves; suppliers are responsible for the rest.In the Swedish commercial aircrafts Saab 340, Saab 2000, and military aircraft JAS 39 Gripen, approximately 80% of the total manufacturing costs are related to purchasing goods from suppliers (Börjesson, Bodén, Haglund, Nielsen & Åhlgren, 1996;Danilovic, 1997Danilovic, & 1999)).It is obvious that close collaboration with suppliers is important.Research by Weiss, Murman and Ross (1996) indicates that the situation in the aerospace industry is similar to that in many other industries -requires a high degree of supplier involvement in the development process based on long-term relations and early supplier involvement in design and development teams, joint risk identification and risk sharing, as well as joint target costing.Some results indicate progress as follows: • Locating design-build teams at the customer's site reduced engineering changes by 50% and cycle time by 25%.• An enhanced cross-functional character of the workforce led to a decrease in the number of job descriptions for engineers from 103 to 30.
• Integrated product teams, products, and process resulted in significant improvements in quality, cycle time, and change orders.The post-release engineering charge rate decreased by 96%.
• Fifty per cent less labour has been used to procure four times the number of parts, while maintaining high quality.
• 'Action workout' teams were developed internally and with suppliers for root-cause analysis and solutions; a 90% first-time pass rate was achieved on the first article inspection (Weiss et al., 1996).
This empirical observation in the aerospace industry raises important questions.If we know that a supplier's involvement in the process of product development is important and if it leads to substantial outcomes as many researchers claim, why is there a discrepancy between the arguments for increasing supplier involvement and the empirical observations indicating a low level of involvement?What are the obstacles to supplier integration?Further questions can be raised about how suppliers were actually involved in the development process in these teams, indicating a low level of involvement.Were they only observers, guests, or did they work as full team members?We can also ask whether the division of work between suppliers and the systems integrator was mutually beneficial or a contradiction, whether they had the same mission and goal in teams, and how workflow and organisational routines enhanced or obstructed the team-based work.
If organisations are viewed as being social systems, and if emphasis is placed on informationprocessing and decision-making in the process of product development, then one of the most important issues is how to get people together to communicate, collaborate in the process of product development and exchange information in order to reduce uncertainty and solve problems.There are relations and dependencies among people and there are dependencies among tasks which they perform that must be known, considered and handled.
To solve problems and to handle complexity, uncertainty and ambiguity in product development, a great amount of information needs to be processed with the aim of achieving co-ordination of people and integration of their tasks.The more relations there are, the more uncertainty there is, and the more information that needs to be processed (Buckley, 1967;Simon, 1957Simon, , 1962Simon, , 1969;;Galbraith, 1977).As complexity increases, so does the demand to achieve higher levels of co-ordination of people and integration of tasks.

THEORETICAL REVIEW ON MANAGING COMPLEXITY
Complexity in product development can be understood in terms of the product, the development process, the development organisation, the technologies applied, and the requirements to be met.Complexity stems from elements with a multitude of relationships and dependencies, such as that between people, their activities, the components of the product, and the organisational and social context in which product development takes place.This implies that complexity increases as the number of different organisations are involved, such as when suppliers are supposed to be involved in product development.
The traditional approach to managing complexity of a product is by systematic decomposition of a product into components and by integrating components into chunks and sub-systems.
The principles of decomposition and integration in product development are shown in Figure 1 (based on Pimmler & Eppinger, 1994;Ulrich & Eppinger, 1994).
In this approach, hierarchical structures refer to the breaking down of a complex system into a structured ordering of sets of subsystems, a partitioning into relationships that collectively define the parts of any whole system.The term 'hierarchy' is used by Simon (1957Simon ( , 1962Simon ( , 1969) ) in a more general manner than is usually invoked in organisational economics and organisational theory, where it typically denotes a relationship based on subordination to authority.This process of decomposition of a product architecture and integration of components into subsystems is comparable to the discussion by Lawrence and Lorsch regarding organisational differentiation and integration (Lawrence & Lorsch, 1967).
One approach in analysing complexity and handling ambiguity and assumptions, in order to reduce uncertainty in decision-making, is based on a systematic analysis of the structure of a system's design.The analysis is based on the system's dependencies, the relations between items and the need for information exchange between people regarding components in the product architecture, and their activities in the development process.Product development therefore requires careful planning of the decomposition and integration of components, and co-ordination of people and integration of tasks within and between organisations such as systems integrators and suppliers.
Both WBS and WP are practices that are generally used in the aerospace and automotive industries.They are well documented in published material from, for example, the Project Management Institute (Project Management Institute, 2000).Both WBS and WP are hierarchical structures; see Figure 1.
The major issue here is related to the logic in the process of the decomposition of a product, from a higher system level to its components and integration of components into subsystems and final product.In every system that contains a hierarchical structure of components, subsystems, people etc. there will be interfaces between these sublevels.The impact of interfaces and boundaries has not been neglected in the literature: Precisely where the boundaries between such tasks are placed can affect project outcome and the efficiency of task performance due to associated changes in the problem-solving interdependence among tasks.The core function of many innovation projects and project tasks is precisely problem-solving and the generation of new information (von Hippel, 1990: 407).
Von Hippel argues that problem-solving relations and dependence among tasks can be predicted and managed by strategies involving adjustment of the task specifications and reduction of the barriers to problem-solving interactions across task boundaries.

RESEARCH DESIGN
The research approach underlying this article is action-based research.The empirical investigation was conducted over a ten-year research period in close collaboration with Saab Aerospace.Formal interviews, informal conversations, participation in the daily life of engineers and participation in management teams were the primary methods in use.The method implies a great deal of what Glaser and Strauss (1967) call grounded theory as well as thoughts from the action frame of reference of Silverman (1970).These ten years have included 68 recorded interviews, series of seminars, observation through participation on a daily basis and participation in internal conferences and seminars, 6 months' employment and the conduct of a large-scale survey study.
The focus in this research was to develop knowledge of the processes used when Saab introduced concurrent engineering in different organisational settings, from small crossfunctional teams to large-scale projects focusing on the integration of suppliers in the product development process.During these years empirical investigations were made of six different concurrent engineering settings, in different product development phases, with small teams of 20-25 people as well as a large team of 400 people.
The specific empirical data in this article were based on 17 interviews, seven seminars, four workshops at Saab and one with a supplier in San Diego, USA, as well as extensive participation on an everyday basis.The methodology suggested here was elaborated during this research project and was carried out in close collaboration with top-level managers, project managers and engineers.
Over the years it has been possible for me to investigate and compare the empirical observations with other companies in the aerospace industry and automotive industry, and so far my observations indicate similar problems in all these empirical situations.I have also had an opportunity to introduce a similar approach at a large truck manufacturing corporation with positive outcome (Danilovic, 2001;Danilovic & Sigemyr, 2003).It is therefore reasonable to generalise from this case study and to state that the results presented here are valid for many other similar corporations.

THE DEPENDENCE STRUCTURE MATRIX -PARTICIPATION IN THE DESIGN OF THE STRUCTURE FOR PRODUCT DEVELOPMENT
As relations between items, components, activities and people are the major characteristics of complex systems, an approach to identifying and modelling complex systems was introduced.The Dependence Structure Matrix (DSM) approach is based on a problemsolving analysis of relations, constraints, dependencies and assumptions in order to define a problem (Steward, 1981).DSM represents and visualises relations and dependencies among tasks and activities, components and subsystems, and among people and teams.DSM has been widely used in many different industries (Browning, 2001).
Figure 2 shows the principles of matrix-based analysis where information is plotted in rows and columns.The intersections between rows and columns contain the identified relation and dependency information.
A DSM analysis shows how the design of tasks can be organised for effective problemsolving in team-based work and the communication required within and between teams (Eppinger, Whitney, Smith & Gebala, 1994).The information captured in a DSM analysis is similar to that in a directed graph or a Programme Evaluation Review Technique (PERT) chart.PERT is a network model that allows for randomness in activity completion times.PERT was developed in the late 1950's for the U.S. Navy's Polaris project which involved thousands of contractors.It has the potential to reduce both the time and cost required to complete a project.However, the DSM representation makes it possible to create a complete model of information flow and dependency analysis in describing and analysing complex projects.DSM allows for tasks to be coupled or independent, unlike the PERT technique.
The DSM analyses presented in this article are based on a dialogue situation between engineers and management from Saab and Sundstrand.The main feature of using a participatory DSM approach is that the engineers and management are the main actors, defining their problems and participating in the creation of the product development process (Garnsey, 1992).The APU consists of a small jet engine turbine installed in the rear airframe, which produces air pressure for engine start, the electronics cooling system, and the emergency electrical and hydraulic power system.The complete system is named APESS -Auxiliary Power Engine Starting System (circled in Figure 3).Initially, the Gripen was designed to carry an APU developed and manufactured by Microturbo in France.However, due to new environmental requirements established by the Swedish government, a new APU had to be developed.After a period of discussions between Saab, Microturbo in France, and Sundstrand in USA, a decision was made at Saab that a new APU should be bought from the US supplier, Sundstrand.Due to a very demanding time schedule, a concurrent engineering approach had to be adopted in the development project.The strategy of Saab was to move towards a long-term oriented partnership collaboration on all corporate levels.
On the strategic level Saab and the supplier agreed to work in an integrated way.Several measures to ensure integration with the supplier were taken.A special liaison engineer was located at the supplier for the duration of the project, numerous meetings took place between people at Saab and at Sundstrand, especially among management, special facsimile lines were introduced to enhance secure communication, and mutual adjustment points were scheduled in order to evaluate the progress of the project.Several Saab engineers were sent over to the supplier in the US to co-ordinate work and occasionally some engineers from the supplier spent time at Saab.The influence of managers in their role of integrating liaison officers was obvious.This tied up management time and resources for conducting integration, to the detriment of other issues.
However, on the engineering level the desired close collaboration was not established.The following description indicates lack of communication and information exchange and shows that formal agreements and very detailed product specifications were not sufficient to avoid misunderstanding and potential delays.
APU is one of the most important subsystems, ensuring the security and flexibility of the aircraft.The APU specification was developed in collaboration by the customer (The Swedish Air Force and the Swedish Defence Material Administration, FMV), the supplier (Sundstrand), and the system integrator (Saab Aerospace).One aspect of functioning of the APESS is that the aircraft must be able to manage quick turns and to operate under severe conditions, thus the aircraft and APU must tolerate the impact of high temporary G loads.The specification requires that the APU must be able to manage + 25 G in a short period of time during qualification tests.
Initially, these requirements were not discussed by management or engineers in Sundstrand.They were taken as granted as specifications were clear on this issue.
When the development process had been going on for some time, the engineers at Sundstrand perceived this requirement as over-dramatisation.They considered the engineers at Saab to be too cautious, requiring something no one else did.Consequently they ignored this aspect in the development work until a meeting took place between engineers from both companies which put the issue on the agenda.
The discussion that followed revealed important aspects of collaboration with suppliers.When engineers at the supplier's company understood, through discussion and information interchange and through visiting the Swedish Air Force, how the aircraft actually operates and the conditions for military operations with JAS 39 Gripen, they agreed that the specification and requirement were acceptable.They fulfilled this requirement on time (Danilovic, 1999: 147-148).
In this description we can see that the contractual forms created a basis for close involvement of suppliers.Everybody wanted this.Top-level managers, as well as project managers, at Saab and at the supplying company wanted it.Engineers in both companies, in different departments and on different levels wanted it.The detailed product specifications clearly stated what the supplier was expected to deliver.Despite that, lack of communication about specifications and the end-customer's usage increased uncertainty and ambiguity.The consequences are obvious.

Organising product development in the APESS project -Design of the WBS
This research indicates that despite the corporate strategy in developing partnership-like relations between Saab and the supplier as well as a well-defined product specification, the desirable high level of involvement of the supplier and the integration of engineers in product development work did not occur.Interestingly, Saab and the supplier used crossfunctional teams at both locations but none of these teams were inter-organisational crossfunctional teams.The level of integration in the product development work was high within each company and at the same time low between the companies.This situation created the basis for the lack of communication and information exchange between people in the development of APESS.
Three aspects of integration in product development can be identified as important.The first is the structural aspects of product development, i.e. the design of the WBS and WPs; the second is the functioning of social and psychological boundaries; and the third the design of workflow, i.e. the prevailing organisational routines influencing the behaviour of people.However, in this article I will only elaborate on the structural aspects of the WBS and WPs and the possibilities to change these in order to create prerequisites for a high level of supplier integration in product development.
The design of the WBS in the APESS project was functionally-oriented, following the logic of the basic functional organisation at Saab and at the supplier.Figure 4 shows the WBS of the APESS project on four product levels.The decomposition process ends up on WBS level 4 containing components.Due to the number of components of the product, Figure 4 shows only some of the components on WBS levels 3 and 4. On the first level the complete product is defined.On the second level the product contains four major subsystems developed at Saab (nos.1-4), one major subsystem developed by the supplier (no.5), and one subsystem (no.6) that contain some time-critical components.On the third WBS level each of the subsystems on the second level is defined on a component level.The third WBS level contains components packaged into WPs.
We can also see in Figure 4 that the functional logic of the basic organisational structure dominates in the decomposition on WBS level 2, following the logic of the basic organisation at Saab according to boxes 1-4, leaving box 5 to the supplier.The same functional, departmental logic dominates at the supplier company.Overall, the processes of decomposition 29  and integration in the APESS project, at Saab and at the supplier, follow the same functional logic.The outcomes of this process are functionally defined WBS and WP, which created a clear separation between Saab and supplier.
What must be considered is that people in all these WPs performed tasks that were dependent on each other instead of being independent.Dependencies across WPs were strong.The main problem in using concurrent engineering in the inter-organisational context is the issue of co-ordinating people in and between different intra-organisational and cross-functional teams within Saab and within Sundstrand, and co-ordinating all these teams with many technical disciplines in the basic organisations at Saab and at the supplier corporation.
When integration with a supplier becomes a strategy, as it was in the APESS project, this functionally and departmentally established WBS and WP logic introduced barriers to communication as engineers did not know who was doing what and when.Few knew what kind of information others needed and who could provide them with the important information they needed.Transparency and situational visibility were low.Those who created the WBS saw it as a highway, but those who had to work with it did not necessarily hold the same view.
One important lesson from the APESS project was that if a higher level of integration was to be implemented between Saab and the supplier, the prevailing WBS and design of WPs had to be altered according to some other logic than the traditional functional logic.

Application of DSM approach in the APESS project
On WBS level 3 DSM analyses were conducted on three levels of the product architecture of the APESS project, WBS levels 2, 3, and 4, as shown in Figure 4. To handle the dynamics of product development, a DSM analysis was conducted in each of the identifiable phases of development from the Concept phase, through the Development phase, Test & Evaluation phase, Production phase, to the Customer Support & Sustain Engineering phase.Due to the scope of this article, only the WBS on level 3 in the Development phase is shown in detail.The comprehensive empirical material from using DSM on WBS levels 2, 3 and 4 and in all other phases is presented in Danilovic (1999).
At each row/column intersection, identified dependencies are presented and the degree of dependence is estimated in the way that engineers and management who participated in workshops perceived them.In Figures 5 and 6, number 1 represents a low level of dependence, 2 a medium level, and 3 a high level.
In this DSM analysis, the focus was only on relations and dependencies related to technical information.Respondents were asked to fill in the DSM matrix in two ways.First, they identified and estimated the impact of technical information-based dependence according to what they needed or required to fulfil a task.Second, they were asked to identify the dependence regarding technical information that they provided to others, i.e. what they believed other people needed in order to perform their tasks.
Figure 5 shows DSM 'as is' before WBS and WPs were modified in order to enable a higher level of inter-organisational integration.In this matrix, certain points of interaction include two and sometimes three digits, because of different perceptions, knowledge or understanding between at least two persons.Finally, this conversation creates a mutual understanding of how such dependence is to be handled.The participatory DSM approach creates situational visibility and thus reduces the perceived uncertainty.This indicates that the DSM tool should be seen as a group process enabling tool rather than a 'fill-in-a-sheet-and-optimise' approach.Boxes that contain at least two different dependence estimations are shaded in dark red to indicate disagreement on the impact in each row/column intersection.Boxes that include dependence on at least level 2 are shaded light blue for clarity.The larger boxes in the matrix that are drawn along the diagonal represent existing work packages.Figure 5 shows clearly that there are many important relations in-between existing WPs.These areas represent interfaces between established work packages.Before this DSM analysis was performed, the interfaces were not identified, visualised or communicated among people.If people are unaware of the relations containing important information, how can we be sure that these unknown points of interaction inbetween WPs will not cause problems, delays, rework, etc.?
The WBS and WPs design (Figures 3 and 5) created a chasm and kept the supplier at arm's length despite the strategy of developing integration between Saab and Sundstrand.The desirable strategy needed to be supported by collaborative WBS and WPs.
Towards integration between systems integrator and supplier -Formation of integrated WBS and collaborative systems teams  when WBS and WPs are defined.Theoretically, there may be a mathematically optimal point, but in practice, different solutions are possible.The systems teams 1 and 2 are more Saab intra-organisationally integrated than before, (see Figure 3), and systems teams 3, 4 and 5 are inter-organisationally integrated between Saab and the supplier.Figure 6 shows that no matter how rows and columns are transformed, interfaces will always be present and will need to be handled.The APESS project is an example of a high degree of dependence among most of the components.In order to handle interfaces between system teams, coordination teams are suggested.
Figure 6 also shows that besides these new systems teams 1-5, three special co-ordination teams are introduced in order to handle interfaces between systems teams.These coordination teams 1 and 2 are rooted in systems teams 1-3 and 3-5 with responsibility for handling interfaces on two levels, where co-ordination team 3 has the total co-ordination responsibility.The same people who perform engineering work in systems teams 1-5 are members of these co-ordination teams.Hierarchy is an organising principle of complex systems that are composed of interrelated subsystems that, in turn, have their own subsystems, and so on.This hierarchical logic of this complex system is visible in Figure 6.

CONCLUSIONS
Although corporations have developed a mutual strategy stressing partnership and integration, it will be difficult to realise this on project and team levels if the structural prerequisites in projects do not support the overall business strategy.
One important reason for the lack of integration of suppliers in product development is the logic in the design of the WBS and the definition of WPs.These are traditionally designed on a functional basis and mirror the prevailing basic organisational structure among systems integrator and supplier.The consequence is low transparency, low situational visibility, lack of integrated tasks and activities, and weak understanding of what the process of product development means to engineers within and between corporations.To achieve the strategy of a high level of supplier integration on project and team levels, alternative logic has to be adopted focusing on dependencies and information flow.DSM methodology is introduced to elaborate the established functionally and departmentally designed WBS and WPs.DSM analysis can identify the points of interaction and the need for information exchange at both the systems integrator and supplier corporation.DSM analysis shows that the formation of collaborative WBS and WPs can support design of collaborative inter-organisational systems teams that supports collaboration in project and cross-functional teams.This DSM analysis shows that no matter how collaborative WBS and WPs are designed there will always be interfaces that need to be handled.Therefore, an overlaid co-ordination team structure might be applied to handle interfaces between systems teams.
DSM is a process-enabling tool.DSM analysis shows that engineers in different departments and organisations have different perceptions of interdependencies of components in a product structure.Through communication of these interdependencies mutual understanding is obtained.The outcome is increased transparency and situational visibility.DSM creates an arena for communication between technical disciplines, between management and engineers, systems integrator and suppliers, which is otherwise missing.DSM enables communication through handshaking and by formalising informal communication and information exchange.DSM provides feedback mechanisms when discussing the past, present and future.This feedback provides information on and knowledge of past projects and experiences, problems and lessons, goal-seeking information on the project, its milestones, and consequences for engineers, systems, and engineering teams and corporations, economic restrictions, the consequences and interpretations of technical specifications and requirements, etc.This approach to DSM focuses on important managerial aspects of creating prerequisites for handling the unpredictable, the unknown, and the uncertain, factors which always characterise complex product development.Management and engineers find an opportunity to analyse a project according to its mission, goals and restrictions.When these aspects are discussed, management and engineers can mutually shape an appropriate strategy for conducting tasks based on a common understanding and acceptance of conditions for the project.This process is labelled by Westley (1990) as strategic conversation and micro dynamics of inclusion.In addition, management and engineers can together design appropriate structures and processes.The subjectivity in the actor approach becomes a line of action (Garnsey, 1992).

Figure 1 :
Figure 1: Managing Complexity -The Processes of Decomposition and Integration

Figure 2 :
Figure 2: Matrix representation of relations and dependencies

Figure 4 :
Figure 4: APESS -Work breakdown structure on four levels

Figure 5
Figure 5 shows that 'technical information' means different things to different people.The figures in boxes show that dependence analysis is a group-oriented process, involving communication, debate and conversation about who does what, why, when and how, and what kind of information they need.This conversation reveals relations and dependence among components and tasks, what kind of dependence can be identified, what impact this dependence has on all the people involved and their tasks, from different points of view.

Figure 6
Figure 6 contains a modified DSM analysis, an alternative to the established WBS design, based on the information in Figure 5.

Figure 6 :
Figure 6: DSM-Analysis on WBS-Level 3, suggested integrated system team solution