Skip to main content

A structured approach to predicting and managing technical interactions in software development


One of the most difficult challenges of managing product development is identifying the individuals who need to coordinate closely their interdependencies during the design process. “Who should talk to whom?” and “Which interfaces should they talk about?” are key questions that engineering managers must address when planning and executing product development efforts. In this paper, I introduce the notion of the affiliation matrix to map the product architecture onto the organizational structure and predict potential technical communication patterns. By comparing potential interactions with actual communications, engineering managers can uncover product interfaces and organizational interactions that may require special managerial action during the design phase of development processes. This provides an integrated view of how process, product, and organizational structures align themselves when developing new products. I illustrate the implementation of this approach in a software development organization, which offers relevant insights about the challenges associated with managing new software development.

This is a preview of subscription content, access via your institution.

Fig. 1
Fig. 2
Fig. 3
Fig. 4
Fig. 5
Fig. 6
Fig. 7
Fig. 8
Fig. 9
Fig. 10
Fig. 11
Fig. 12
Fig. 13
Fig. 14
Fig. 15
Fig. 16
Fig. 17
Fig. 18
Fig. 19
Fig. 20
Fig. 21


  1. 1.

    I refer to product development in a broad sense to include the development of hardware or software products, or both. However, when referring to software development exclusively, I will make the distinction explicit.

  2. 2.

    I reserve the use of the word “interfaces” to refer to linkages between product components while “interactions” refer to actual or potential communications between development actors.

  3. 3.

    Note that Fig. 1 distinguishes unintended feedback interdependencies that could occur from the “design and integration” phase to either “release planning”, “software architecture definition”, or “software feature definition” phases. Because these interdependencies are unintended (or unplanned) they are not considered when identifying planned design iterations. This DSM also distinguishes the feedback interdependencies associated with process improvement because they are not part of planned design iterations either.

  4. 4.

    The process illustrated in Figs. 1 and 2 was used for developing both legacy and novel software applications.

  5. 5.

    When using block diagrams to represent the structure of software products, components that serve others as platforms to build upon are typically placed at the bottom of the diagram.

  6. 6.

    If we were to determine the truly potential unattended “common-component” interactions, we could do so by comparing the T pure-common-component matrix and the actual communication matrix (C), where the entry T pure-common-component (i,j) = 1 if T common-component (i,j) > 0 and T architectural (i,j) =0. Such a comparison would yield the common-component potential interactions that were unattended by actual interactions.

  7. 7.

    To test statistically the significance of the difference between the proportions of matched interactions (within technical and managers group versus non-related group), I carried out a chi-square test over the 440 matched interactions. The expected values were determined by the probability that a matched interaction would randomly occur between technical and manager actors instead of with non-related actors. Such probabilities were defined by the available set of possible interactions in these two categories. The test resulted in a χ2 of 136.9, which is clearly greater than the critical value of χ2(0.99, 1) = 6.63.

  8. 8.

    To test the significance of this result, a chi-square test was carried out over the 71 unpredicted interactions. This test resulted in a χ2 of 13.2, which is greater than the critical value of χ2(0.99, 1) = 6.63.


  1. Allen TJ (1977) Managing the flow of technology. MIT Press, Cambridge

    Google Scholar 

  2. Baldwin CY, Clark KB (2000) Design rules: volume 1: the power of modularity. MIT Press, Cambridge

    Google Scholar 

  3. Breiger RL (1991) Explorations in structural analysis: dual and multiple networks of social structure. Garland Press, New York

    Google Scholar 

  4. Browning TR (2001) Applying the design structure matrix to system decomposition and integration problems: a review and new directions. IEEE Trans Eng Manage 48(3):292–306

    Article  Google Scholar 

  5. Browning TR, Ramasesh RV (2007) A survey of activity network-based process models for managing product development projects. Prod Oper Manage 16(2):217–240

    Google Scholar 

  6. Carley KM (2002) Smart agents and organizations of the future. In: Lievrouw L, Livingstone S (eds) The handbook of new media. Chap. 12. Sage, Thousand Oaks, pp 206–220

  7. Cataldo M, Wagstrom P, Herbsleb JD, Carley KM (2006) Identification of coordination requirements: implications for the design of collaboration and awareness tools. In: Proceedings of ACM conference on computer-supported cooperative work, Banff Canada, pp 353–362

  8. Chen L, Ding Z, Li S (2005) A formal two-phase method for decomposition of complex design problems. ASME J Mech Des 127:184–195

    Article  Google Scholar 

  9. Chen L, Macwan A, Li S (2007) Model-based rapid redesign using decomposition patterns. ASME J Mech Des 129:283–294

    Article  Google Scholar 

  10. Clarkson PJ, Simons CS, Eckert CM (2004) Predicting change propagation in complex design. ASME J Mech Des 126(5):765–797

    Article  Google Scholar 

  11. Eckert CM, Clarkson PJ, Zanker W (2004) Change and customization in complex engineering domains. Res Eng Des 15(1):1–21

    Article  Google Scholar 

  12. Eppinger SD, Salminen VK (2001) Patterns of product development interactions. In: International conference on engineering design, ICED ’01, vol 1, pp 283–290

  13. Eppinger SD, Whitney DE, Smith RP, Gebala DA (1994) A model-based method for organizing tasks in product development. Res Eng Des 6(1):1–13

    Article  Google Scholar 

  14. Henderson R, Clark K (1990) Architectural innovation: the reconfiguration of existing product technologies and the failure of established firms. Adm Sci Q 35(1):9–30

    Article  Google Scholar 

  15. Jarratt T, Clarkson J, Eckert C (2005) Engineering change. In: Design process improvement––a review of current practices, pp 266–285

  16. Lai X, Gershenson JK (2006) Representation of similarity and dependency for assembly modularity. In: Proceedings of the ASME design engineering technical conferences––18th iternational conference on design theory and methodology, Philadelphia

  17. MacCormack A, Verganti R, Iansiti M (2001) Developing products on internet time: the anatomy of a flexible product development process. Manage Sci 47(1):133–150

    Article  Google Scholar 

  18. MacCormack A, Rusnack J, Baldwin C (2006) Exploring the structure of complex software designs: an empirical study of open source and proprietary code. Manage Sci 52(7):1015–1030

    Article  Google Scholar 

  19. Michelena N, Papalambros PY (1995) A network reliability approach to optimal decomposition of design problems. ASME J Mech Des 117(3):433–440

    Google Scholar 

  20. Michelena N, Papalambros PY (1997) A hypergraph framework for optimal model-based decomposition of design problems. Comput Optim Appl 8(2):173–196

    MATH  Article  MathSciNet  Google Scholar 

  21. Mihm J, Loch C, Huchzermeier A (2003) Problem-solving oscillations in complex engineering projects. Manage Sci 46(6):733–750

    Article  Google Scholar 

  22. Morelli MD, Eppinger SD, Gulati RK (1995) Predicting technical communication in product development organizations. IEEE Trans Eng Manage 42(3):215–222

    Article  Google Scholar 

  23. Olson J, Cagan J, Kotovsky K (2006) Unlocking organizational potential: a computational platform for investigating structural interdependence in design. In: Proceedings of ASME conference on design theory and methodology

  24. Pimmler TU, Eppinger SD (1994) Integration analysis of product decompositions. ASME conference on design theory and methodology, Minneapolis, pp 343–351

  25. Sanchez R, Mahoney JT (1996) Modularity, Flexibility, and Knowledge Management in Product and Organization Design. Strateg Manage J 17:63–76

    Google Scholar 

  26. Sangal N, Jordan E, Sinha V, Jackson D (2005) Using dependency models to manage complex software architecture. In: Proceedings of the 20th annual ACM SIGPLAN conference on object oriented programming, systems, languages, and applications, San Diego

  27. Seidman S (1981) Structures induced by collections of subsets: a hypergraph approach. Math Soc Sci 1:381–396

    MATH  Article  MathSciNet  Google Scholar 

  28. Sharman D, Yassine A (2004) Characterizing complex products architectures. Syst Eng 7(1):35–60

    Article  Google Scholar 

  29. Simmel G (1955) Conflict and the web of group affiliations. Free Press, Glencoe

    Google Scholar 

  30. Sosa ME, Eppinger SD, Rowles CM (2003) Identifying modular and integrative systems and their impact on design team interactions. J Mech Des 125(2):240–252

    Article  Google Scholar 

  31. Sosa ME, Eppinger SD, Rowles CM (2004) The misalignment of product architecture and organizational structure in complex product development. Manage Sci 50(12):1674–1689

    Article  Google Scholar 

  32. Sosa ME, Browning T, Mihm J (2007a) Studying the dynamics of the architecture of software products. In: Proceedings of the ASME design theory and methodology conference

  33. Sosa ME, Eppinger SD, Rowles CM (2007b) A network approach to define modularity of components in complex products. ASME J Mech Des 129(11):1118–1129

    Article  Google Scholar 

  34. Sosa ME, Gargiulo M, Rowles CM (2007c) Component connectivity, team network structure, and attention to technical interfaces in complex product development. INSEAD working paper 2007/68/TOM/OB

  35. Steward D (1981) The design structure matrix: a method for managing the design of complex systems. IEEE Trans Eng Manage EM 28(3):71–74

    Google Scholar 

  36. Terwiesch C, Loch CH, De Meyer A (2002) Exchanging preliminary information in concurrent engineering: alternative coordination strategies. Org Sci 13(4):402–419

    Article  Google Scholar 

  37. Wasserman S, Faust K (1994) Social network analysis. Cambridge University Press, NY

    Google Scholar 

Download references


I appreciate the active participation of the executive team and members of the development organization of the firm where the empirical study was conducted. I thank Jürgen Mihm for his insightful feedback on an earlier version of this article. Portion of this manuscript was presented at the 14 th International Conference in Engineering Design (ICED ‘07 Paris, France). Finally, I appreciate the comments and suggestions of three anonymous reviewers which helped significantly in improving the final version of this article.

Author information



Corresponding author

Correspondence to Manuel E. Sosa.

Rights and permissions

Reprints and Permissions

About this article

Cite this article

Sosa, M.E. A structured approach to predicting and managing technical interactions in software development. Res Eng Design 19, 47–70 (2008).

Download citation


  • Software development
  • Product architecture
  • Design iterations
  • Project management