Companies that develop new products increasingly outsource design, a trend that has prompted much concern but little prescription on how best to manage such projects. One challenge is the lack of understanding of what constitutes success in outsourced design. To provide clarity, this paper identifies academic and practical perspectives on success from the literature as well as our own interviews with design consultants and consulting clients, organizes the perspectives into a typology featuring seven distinct dimensions of success, and then prioritizes the key success measures using a survey of 194 additional practitioners. The results suggest that past research has generally focused on the wrong success measures, overstating the impact of problems during development and the relative importance of return on investment, and omitting key measures such as working relationship quality, project value, and client satisfaction. Not all success measures are well correlated; a project may do very well on some but poorly on others. While each measure has it merits, client satisfaction appears to be a promising summary measure.

Diversification is the preferred hedge to supply chain risks, but many companies use sole sources anyway for long-term strategic benefits. The enormous damage caused by the March 2011 magnitude 9.0 earthquake in Japan to industrial supply chains warns again that sole sourcing is risky, as many companies or industries around the world were halted due to the loss of their sole suppliers in Eastern Japan. In the literature on contingency actions, temporary diversification has been seen as a feasible response, especially for rare-but-long disruptions. However, little is known about the limits of this approach and the situations where it is applicable. This paper describes and compares two disaster recoveries: the well-known Aisin Seiki fire and the less wellknown Riken earthquake, first systematically documented in this paper. Numerous suppliers and competitors volunteered to make parts for Aisin Seiki whereas no such response occurred in the Riken case, despite important similarities in day-to-day operations strategy: sole or nearly sole sourcing, deep supplier relations, low inventory, and severe disruption. Our comparative analysis suggests that characteristics of the affected product and/or its production methods (i.e. generic or asset-specific) limit the recovery alternatives. Temporary diversification was and remains impossible at Riken due to the high degree of specificity required in the design and production methods of the disrupted item. Unawareness of such limits to temporary diversification may result in over-optimism regarding its availability and insufficient disaster preparedness. We also briefly describe two other European cases.

Purpose The purpose of this paper is to present the methodology and the results on the design and development of an autonomous, golf ball picking robot, for driving ranges. Design/methodology/approach The strategy followed to develop a commercial product is presented, based on prior identification requirements, which consist of picking up golf balls on a driving range in a safe and efficient way. Findings A fully working prototype robot has been developed. It uses two driving wheels and a third cast wheel, and pushes a standard gang which collects the balls from the ground. A hybrid information system was implemented in order to provide a statistically relevant prediction of golf balls location, to optimize the path the robot has to follow in order to reduce time and cost. Autonomous navigation was developed and tested on a simulation environment. Research limitations/implications Preliminary results showed that the new path planning algorithm Twin‐RRT* is able to form closed loop trajectories and improve the result over time. Kinematic constraints were already taken into account on the algorithm. This sampling based algorithm has potential usage in solving other TPP (Travelling Purchaser Problem) related problems. Practical implications The prototype feasibility is being tested in real driving ranges. It has autonomy of up to 8 h per day. It is capable of collecting up to 1,200 balls in one single journey. It weighs 130 kg and is capable of climbing slopes of up to 22°. The maximum speed is 8 km/h and the robot takes 140 min to completely sweep a 25,000 m 2 field at 7.2 km/h (2 m/s) average speed. Social implications There are about 30,000 golf practice fields, of which 18,000 are located in the USA and Canada. In some countries the golf industry represents more than 15 per cent of tourism GNP. In a typical practice field, about 10,000 balls have to be picked up every day. Originality/value An important contribution of this paper is the algorithm for path planning in order to optimize the ball pick up task, reducing time and cost. There are two patents are pending concerning the technological novelties of this work.

Although the risks and rewards of outsourcing product design have been argued extensively in the literature, little hard data on project outcomes exist to inform the discussion, and even these are methodologically suspect. To address this gap, this paper uses novel random sampling techniques to locate projects and measure the distribution of project outcomes in one particular type of design outsourcing, domestic design consulting. The results suggest that design consulting outcomes are generally good but vary significantly between projects and consultancies. Overall rates of product commercialization and market success compare favorably to results previously reported for in-house product design, and client satisfaction levels are comparable to those of other service industries.

The complexity of designing products such as gas turbine components leads to enormous difficulties in understanding where the main design process inefficiencies are. It is extremely difficult to decide which improvements will have the most significant impact for a company or for a specific project. Another common issue found in the Aerospace industry is a consequence of basing a new gas turbine design on a previous concept which means that people generally don't question the overall design process. These issues, alongside a company's matrix organization, create difficulties in managing and improving the design processes. In order to overcome the mentioned problems, a framework has been developed and used in Rolls-Royce, aiming to assess and improve, in a systematic way, complex product development processes at component or system level. The framework involves the use of Value Stream Mapping (VSM) analysis to identify sources of waste in the design process, the use of Design Structure Matrix (DSM) to manage design iterations and complex interfaces, and process simulation to deal with its stochastic behavior and estimate and assess the benefit of potential developments.

Cascade dynamics on networks are usually analyzed statically to determine existence criteria for cascades. Here, the Watts model of threshold dynamics on random Erdos-Rényi networks is analyzed to determine the dynamic time evolution of cascades. The network is assumed to have a specific finite number of nodes n and is not assumed to be treelike. All combinations of threshold ϕ, network average nodal degree z, and seed sizes |S| from a single node up are included. The analysis permits study of network size effects and increased clustering coefficient. Several size effects not found by infinite network theory are predicted by the analysis and confirmed by simulations. In the region of ϕ and z where a single node can start a cascade, cascades are expanding, in the sense that each step flips a larger group than the previous step did. We show that this region extends to larger values of z than predicted by infinite network analyses. In the region where larger seeds are needed (size proportional to n), cascades begin by contracting: at the outset, each step flips fewer nodes than the previous step, but eventually the process reverses and becomes expanding. A critical mass that grows during the cascade beyond an easily-calculated threshold is identified as the cause of this reversal.

Research on outsourced product development has focused primarily on the motives behind firms' decisions to outsource, with less attention paid to the outcomes of those decisions. The few existing academic studies have reported high failure rates, but there is little consensus as to what is meant by "project success" and "failure" and some do not define success at all. Such ambiguity makes comparisons difficult and hinders explanation of observed variation in project outcomes. This paper explores the many meanings of project success in outsourced product development, based on in-depth interviews of thirty design consultants and clients. After reviewing the merits and limitations of each metric, we propose that the client's willingness to recommend the consultant may be a suitable outcome variable for assessing project outcomes and comparing success rates across diverse projects, companies, and industries. We present preliminary data that suggests client willingness to recommend varies widely and is multimodal in distribution. Finally, we identify several commonly encountered failure modes, i.e., sequences of events that generate discrepancies between client expectations and project deliverables, thereby producing client dissatisfaction.

This research is based on observations made over a two year period of the Closures Systems Integrators (CSIs) at a North American automobile manufacturer. CSIs coordinate attribute balance and system decisions for conflicting car door attributes. The attribute delivery process is very tightly coupled with many interactions and conflicts between the attributes, and careful system integration and interface management are essential to satisfy customer needs. Programs with dedicated CSIs have fewer design-related problems during launch. Our study also reveals the need for more support and clearer roles and responsibilities for CSIs.

The use of the Pearson coefficient (denoted r) to characterize graph assortativity has been applied to networks from a variety of domains. Often, the graphs being compared are vastly different, as measured by their size (i.e., number of nodes and arcs) as well as their aggregate connectivity (i.e., degree sequence D). Although the hypothetical range for the Pearson coefficient is [−1,+1], we show by systematically rewiring 38 example networks while preserving simplicity and connectedness that the actual lower limit may be far from −1 and also that when restricting attention to graphs that are connected and simple, the upper limit is often very far from +1. As a result, when interpreting the r-values of two different graphs it is important to consider not just their direct comparison but their values relative to the possible ranges for each respectively. Furthermore, network domain (“social” or “technological”) is not a reliable predictor of the sign of r. Finally, we show that networks with observed r<0 are constrained by their D to have a range of possible r which is mostly <0, whereas networks with observed rτ;0 suffer no such constraint. Combined, these findings say that the most minimal network structural constraint, D, can explain observed r<0 but that network circumstances and context are necessary to explain observed rτ;0.

Number: 015-0985 Measuring and Understanding Hierarchy as an Architectural Element in Industry Sectors Jianxi Luo* Massachusetts Institute of Technology 77 Massachusetts Avenue E38-448, Cambridge, MA 02139 Email: luo@mit.edu Phone: +1 (617) 642-1652 Daniel E. Whitney Massachusetts Institute of Technology 77 Massachusetts Avenue E40-243, Cambridge, MA 02139 Email: dwhitney@mit.edu Phone: +1 (617) 253-6045 Carliss Y. Baldwin Harvard Business School Soldiers Field, Boston, MA 02163 Email: cbaldwin@hbs.edu Phone: +1 (617) 495-6673 Christopher L. Magee Massachusetts Institute of Technology 77 Massachusetts Avenue E38-450, Cambridge, MA 02139 Email: cmagee@mit.edu Phone: +1 (617) 252-1077 * Corresponding author POMS 21st Annual Conference Vancouver, Canada May 7 to May 10, 2010

Purpose - This paper's objective is to explain the concept of proper kinematic constraint to guide requirements-driven design of mechanical assemblies and to connects proper constraint to the datum flow chain (DFC) and key characteristics (KCs).Design/methodology/approach - The paper presents proper constraint as a way to support the goal of placing key parts in particular geometric relationships with respect to one another so that a DFC can deliver KCs unambiguously. Such a DFC is said to be competent. Additionally, a competent DFC is robust in the sense that the constraint relationships between parts retain their definition and effect under all allowed variations in parts.Findings - Failure to provide proper constraint can lead to undesired consequences including locked-in stresses and difficult or inconsistent assembly. Some designs need to be over-constrained, and this requires very careful control and tight tolerances on the over-constrained degrees of freedom in order to avoid or at least understand the consequences listed above.Research limitations/implications - Mathematical methods exist to test designs for proper constraint. The simplest, and occasionally unsuccessful, is the Kutzbach criterion. Screw theory is the most reliable method but its application requires extra knowledge and mathematical tools.Practical implications - Most CAD software and tolerance analysis software do not test designs for their state of constraint. The engineer needs to take account of this independently and be aware of the limitations of software as a guide. Tolerance analysis software that does not take account of constraint may yield incorrect answers.Originality/value - The paper reinvigorates a once-well-known principle and makes engineers aware of it. it also links this concept to the concepts of DFC and KCs and supports a mathematically-based method for designing assemblies.

This paper shows how shape grammar can be used to derive cellular automata (CA) rules. Searching the potentially astronomical space of CA rules for relevance to a particular context has frustrated the wider application of CA as powerful computing systems. An approach is offered using shape grammar to visually depict the desired conditional rules of a behavior or system architecture (a form-function) under investigation, followed by a transcription of these rules as patterns into CA. The combination of shape grammar for managing the input and CA for managing the output brings together the human intuitive approach (visualization of the abstract) with a computational system that can generate large design solution spaces in a tractable manner.

This paper addresses the problem of determining the instantaneous state of mobility and constraint of a general mechanism or assembly using screw theory. This problem has been attacked before by different methods with varying success. The method presented here is very simple and applies to many types of mechanisms, with one interesting exception. This exception also eludes the Griibler/Kutzbach criterion. The method presented here also improves the accuracy and scope of a method presented by Konkar and Cutkosky. Note to Practitioners - This paper permits an engineer to analyze the state of constraint of an assembly, mechanism, or fixture in order to see if it is properly constrained or whether it contains unwanted overconstraints. Overconstraint can lead to locked-in stress, incorrect tolerance analysis, and lack of robustness in a design. Very small changes in the sizes of parts or positions of locators in fixtures can have large effects on locations of parts, deformation, or internal stresses. Proper constraint is desirable because it provides for only one way to assemble parts. Operator dependency is eliminated, assembly is quick and repeatable, and special skin is not needed.

The field of Engineering Systems is distinguished from traditional engineering design in part by the issues it brings to the top. Engineering Systems focuses on abstractions like architecture and complexity, and defines system boundaries very broadly. It also seeks to apply these concepts to the process of creating systems. This paper summarizes the role and influence of architecture in complex engineering systems. Using the research literature and examples, this paper defines architecture, argues for its importance as a determinant of system behavior, and reviews its ability to help us understand and manage the design, operation, and behaviors of complex engineering systems. A. INTRODUCTION Typical engineering design education focuses on specific aspects of design, such as the technical behavior of a set of elements interconnected in a certain way. By contrast, Engineering Systems focuses on a number of abstract concepts first because they provide a general framework for guiding the development of many diverse kinds of systems, so that these systems will provide the desired functions in the desired ways. Among these abstract concepts is that of system architecture. In this paper, we explore this concept and provide a number of ways of appreciating system architecture’s importance in both the practical aspects of system design and in the intellectual aspects of understanding complex systems from a variety of viewpoints. The paper begins with a definition of architecture and its influence on functional behavior, extra desired properties like flexibility and reliability (collectively called “ilities”), complexity, and emergent behaviors. Architectures are not static but instead evolve over long periods as technologies mature. They also evolve during the normal course of designing an individual system. These evolutionary patterns are useful in understanding architecture’s importance. The paper next provides several examples of architectures and illustrates how architecture affects the way systems are designed, built, and operated. The examples include aircraft, automobiles, infrastructures, and living organisms. The importance of architecture is framed in three domains of importance: as a way to understand complex systems, to design them, to manage them, and to provide long-term rationality by means of standards. The abstract concepts of modularity and integrality are shown to be useful for categorizing systems and illustrating how architectural form can influence important system characteristics. Several contrasts are noted between relatively small, deliberately designed products and evolutionary, less-managed large infrastructures. Architecture’s ability to influence the functions and allied properties of systems is shown to extend to robustness, adaptability, flexibility, safety, and scalability. Examples from recent research are given to show how some of these properties might be measured using network models of particular architectures.

Execution of a complex product development project is facilitated through its decomposition into an interrelated set of localized development tasks. When a local task is completed, its output is integrated through an iterative cycle of system-wide integration activities. Integration is often accompanied by inadvertent information hiding due to the asynchronous information exchanges. We show that information hiding leads to persistent recurrence of problems (termed the design churn effect) such that progress oscillates between being on schedule and falling behind. The oscillatory nature of the PD process confounds progress measurement and makes it difficult to judge whether the project is on schedule or slipping. We develop a dynamic model of work transformation to derive conditions under which churn is observed as an unintended consequence of information hiding due to local and system task decomposition. We illustrate these conditions with a case example from an automotive development project and discuss strategies to mitigate design churn.

Attached are the extended abstracts received to date for the ESD Colloquium to be held on May 29 and 30, 2002. A proceeding of the complete papers are planned to be published in advance of the colloquium. We hope you find these abstracts to be a useful preview. One of the more difficult problems facing developers of complex engineering systems stems from the degree of interdependence among subsystems and components that is inherent in such systems. This interdependence can be the result of physical interdependence, designed into the system architecture, or it can result from the interrelations among the tasks to be performed during development. (This task must be completed before that one is begun; the results of this test will determine how we accomplish that task, etc.). The handling of these interdependencies is one of the major (arguably the major) responsibilities of the project manager for the development. A simple one-sentence definition of a project manager's job is that, " A project manager manages interdependencies. " The difficulty of this assignment is the result of a number of factors. The first, of course, is the degree of interdependence designed into the architecture. Equally important is the way in which the overall development problem has been partitioned. The latter is only partially independent of the former. Project managers have some control over both of these factors but usually more over the second. A problem can often be partitioned in several ways and tasks assigned accordingly. Some partitionings will result in greater interdependence, others in less. Thus, the project manager can make his job easier or more difficult. Experienced project managers learn this and simplify their jobs by assigning tasks to minimize interdependencies among team members. A second factor that affects the difficulty of the project manager's job lies in the nature of the technologies incorporated into or embodied in the system. If the system is based upon mature, stable technologies, the job is easier than when it is based upon dynamic, rapidly building technologies. In the latter case, there is, in addition to the need for coordination to manage interdependencies, a need to stay abreast of technological developments. In the former, the project manager can concentrate on the task of coordination without the distraction of worrying over changes in technology. It is the need to accomplish both coordination and knowledge maintenance that led to the development of the product development …