A knowledge-based measure of product complexity

Accepted Manuscript A knowledge-based measure of product complexity Xiaoqi Zhang, Vince Thomson PII: DOI: Reference:

S0360-8352(17)30526-0 https://doi.org/10.1016/j.cie.2017.11.005 CAIE 4976

To appear in:

Computers & Industrial Engineering

Received Date: Revised Date: Accepted Date:

20 November 2016 22 September 2017 2 November 2017

Please cite this article as: Zhang, X., Thomson, V., A knowledge-based measure of product complexity, Computers & Industrial Engineering (2017), doi: https://doi.org/10.1016/j.cie.2017.11.005

This is a PDF file of an unedited manuscript that has been accepted for publication. As a service to our customers we are providing this early version of the manuscript. The manuscript will undergo copyediting, typesetting, and review of the resulting proof before it is published in its final form. Please note that during the production process errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain.

A knowledge-based complexity

measure

of

product

Xiaoqi Zhang, Vince Thomson Department of Mechanical Engineering, McGill University Macdonald Engineering Building, Room 270 817 Sherbrooke Street West, Montreal, Quebec H3A 0C3 Canada

Corresponding author: Xiaoqi Zhang Email: [email protected] Tel: +1-514-963-8219 Address: Macdonald Engineering Building, Room 270, 817 Sherbrooke Street West, Montreal, Quebec H3A 0C3 Canada

A

knowledge-based

measure

of

product

complexity Abstract: This paper introduces a measure of product complexity from a knowledge perspective. A product is considered to be the result of integrating functions; so, the measure considers the complexity of individual functions as well as integration tasks. Disciplinary knowledge required in product design is classified and quantified. The complexity of each individual function is a measure of the intensity of knowledge requirements. The complexity of integrating two functions is a measure of the product of knowledge difference and interdependency. The application of the new method for the estimation of design effort and project duration is illustrated with an example of a hydroelectric generator. Keywords: measure; product design; complexity 1

In product design, as companies respond to increasing customer demands by improving product functions, introducing new technology, and accelerating innovation, they are generally faced with continuously increasing complexity characterized by intense knowledge requirements. Budget overruns, schedule slippage, and flawed quality have been observed as complexity rises (Braun & Lindemann, 2008; Lewis, 2012).

Inaccurate estimation of complexity has been

identified as one of the major causes, as it leads to improper resource allocation and scheduling (Bashir & Thomson, 1999b; Lederer & Prasad, 1995). Therefore, it is necessary to develop a measure of complexity that reasonably quantifies complexity and provides insight into the management of complexity. This paper develops a measure of complexity from a knowledge perspective. The concept of knowledge has been studied in a wide range of topics, such as problem solving, artificial intelligence and psychology. Instead of being concerned with the detailed cognitive process employed during design, this paper uses the concept of knowledge at a high level of abstraction. The definition of knowledge used in this paper is about the types of disciplinary expertise applied during product design. We argue that the proposed measure is accurate, and connects product and designers through a knowledge perspective, which enables managers to evaluate if designers’ abilities match both product and project (schedule, cost) requirements. Since we built the measure based on the work by Bashir and Thomson (1999a), the proposed measure is named the BZT (Bashir-Zhang-Thomson) complexity measure. The paper is organized as follows: section 1 reviews related work; section 2 describes the measure; section 3 demonstrates how to apply the measure to estimate design effort and project duration through an example from GE Hydro; section 4 gives suggestions about how managers can use the measure; and section 5 gives conclusions.

1. Background A complex system contains a large number of parts that interact in a non-simple and uncertain manner. To study the complexity of product design, products are often represented as networks consisting of physical components (Sinha & de Weck, 2016; Tamaskar, Neema, & DeLaurentis, 2014), processes (Singh et al., 2012), functions (Ameri, Summers, Mocko, & Porter, 2008;

2

Bashir & Thomson, 1999a) or technologies (Meyer & Utterback, 1995). It is intuitive to use the number of elements in the network as an indicator of complexity. For example, Griffin (1993) calculates complexity as the number of functions and technologies. However, it is arbitrary to solely consider the number of elements in complexity measurement, especially for systems where elements are standard and highly repetitive, such as memory chips. From a systematic view, the complexity of connecting multiple elements into a whole system needs to be taken into account. Sinha and de Weck (2016) propose to map a complex product as a network of physical components; so, the complexity of the underlying architecture can be measured from the point of view of topology. Besides topological complexity, their metric also includes component complexity and interface complexity, which is estimated from historical data. Instead of a sole physical view, Tamaskar et al. (2014) integrate a functional view by mapping functions to the physical components and their connections in aerospace structures. Weights of nodes and links in the physical network are defined based on the number of associated functions, the frequency of link occurrence in all possible paths, and the size of feedback loops. Product complexity is calculated as the summation of weights. In practice, constructing valid physical structures can be challenging, especially during the conceptual design phase or for the cases where no similar products have been designed. Among the various complexity metrics, very few have been validated with real world data (Shah & Runger, 2013). Most approaches are detached from the designer viewpoint; so, management implications cannot be obtained directly from examples of using the metrics. To improve complexity measurement, we adopted a knowledge perspective for the following reasons. 

Product design is essentially a knowledge-intensive process. Knowledge is embedded in design team members, tools, tasks and networks formed by these elements (McGrath & Argote, 2008). Product design proceeds with the dynamics of knowledge creation, transfer and exploitation (Davis, Subrahmanian, & Westerberg, 2005; Madhavan & Grover, 1998; Nissen, 2002).



Knowledge intensity and diversity drives product complexity. With the rapid growth of technology and increasing customer demands, the knowledge base of products has been expanding to an ever broader range (Granstrand, Bohlin,

3

Oskarsson, & Sjöberg, 1992). The multidisciplinary nature of products requires an extensive integration of different knowledge domains through collaboration (Kleinsmann, Buijs, & Valkenburg, 2010). This increases design complexity since designers are highly specialized in different disciplines (Barclay & Dann, 2000; Tomiyama, D’Amelio, Urbanic, & ElMaraghy, 2007). Evidence has shown that the development time of a product increases with greater knowledge requirements (Lucke, Mickelson, & Anderson, 2009). 

Knowledge connects product to designers. Managing complexity relies on designers’ knowledge, experience and learning ability (Crespo-Varela, Kremer, Tucker, & Medina, 2012). Managers need to evaluate designers’ qualifications for design tasks in order to gain an appreciation of their ability to handle complexity and to make decisions concerning resource allocation. Knowledge provides a link connecting product complexity and designers’ ability, since knowledge is embedded into product functions, which requires designers with corresponding knowledge to realize them.

We incorporated knowledge into the Bashir-Thomson complexity measure PC (Bashir & Thomson, 1999a). Their approach decomposes product functions into hierarchies and computes product complexity as

, where Fj is the number of functions at level j and l is the

number of levels. An example of calculating the complexity of a modulator is shown in Figure 1. Since subfunctions contribute to the make up of parent functions, i.e., from Figure 1, subfunctions at level 3 (Divide output, Control input, Send signals) are integrated in the parent function at level 2 (Modulate transmitted signals), it appears that the complexity of the subfunctions are counted twice. This is not the case. The functional diagram captures the topological complexity of the product. PC calculates this complexity. One could organize the same functions in a different topology and obtain a different amount of complexity. Several researchers (Sinha & de Weck, 2016, Tamaskar et al., 2014, Shafiei-Monfared & Jenab, 2012) have measured complexity using different types of networks that reflect product topology. In this paper, a functional diagram is used.

PC has proven to be valid, as it has been shown to positively correlate with design effort at many companies. We believe there is room for improvement by incorporating knowledge into the

4

measure. Using a knowledge perspective, the BZT measure is the sum of functional complexity where functions are weighted according to their knowledge intensity, and integration complexity where interfaces are weighted according to their knowledge difference.

Figure 1 The functional diagram of a modulator where PC = 3X3 + 6X2 + 1X1 = 22 (Bashir, 2000)

2. Measuring product complexity from a knowledge perspective The essence of product design is integrating multiple knowledge domains to achieve the desired functions. Since knowledge is embedded into product functions, a functional diagram is used to show the mapping of knowledge into product functions. A scale is used to evaluate the required knowledge in designing a product function. Based on the required knowledge, measuring complexity is accomplished by both the complexity of individual functions as well as the complexity of integrating functions. Steps used in this approach, summarized in Figure 2, are explained in the following subsections.

Figure 2 The relationship of product, functions and knowledge in the BZT complexity method

2.1. Functional decomposition Functional decomposition is a technique to develop a graphical representation of functions to be achieved by project, product or process. One starts with the primary function and expands the functions into subfunctions by asking, “how is this function achieved?”. Subfunctions can be 5

expanded into sub-subfunctions until the end-function is too simple to be further broken down. The advantage of using functional decomposition is that functionality is independent of the embodiment of a product, i.e., the shape, materials, and organization of functions as well as the methodology used to design a product (Otto & Wood, 2001). A functional diagram can be used to represent the essence of a product before the embodiment of a design concept is achieved; so, it allows one to get an estimate of the complexity earlier in the design process. Bashir and Thomson’s product complexity method used a functional diagram as an analytical tool (Bashir & Thomson, 1999a). The successful application of the method in many companies has proved that functional decomposition is a promising technique to study product complexity (Bashir & Thomson, 2004).

2.2. Knowledge mapping Mapping functions into a knowledge space requires the development of a knowledge scale as a reference for users to evaluate functions. A knowledge scale is a matrix that classifies and quantifies the knowledge required in design projects. Knowledge items in the scale should be as mutually exclusive as possible. ‘Geometry’ and ‘Weight’ are good examples, whereas ‘Geometry’ and ‘Shape’ are not. Levels, such as low, medium and high, are defined to assess the severity of the knowledge requirement. A numerical value is used for each level, where a higher value indicates a severer requirement. To avoid favouritism towards any knowledge item, all knowledge items should have the same scale range [0, r] (r>1), where users can determine the value of r. For example, if we take r as 2, a weighting can be 0 (None) – 1 (Simple) – 2 (Difficult). Since knowledge items are independent, K knowledge items can form a Kdimensional space. For a function

in the function diagram, its involved knowledge can be

represented as a vector in knowledge space: of knowledge item n for the function

where

is the value

.

2.3. Complexity measure Product is the result of integrating knowledge intensive functions; so, the proposed measure gauges complexity from two aspects: the technical complexity of each individual function and the complexity of integrating functions.

6

2.3.1. Technical complexity Technical complexity is defined for each individual function. Function denoted

’s technical complexity,

, is measured as the root mean square of the elements in its knowledge vector as

shown in equation (1), where

is the value of knowledge item n for the function

, and N is

the number of knowledge items. The assumption for the equation is that functions with more severe knowledge requirements are more complex to design (Bashir & Thomson, 1999a, 1999b).

(1) It was mentioned in section 2.1 that one of the advantages of a functional view of a product is that it can be created before the embodiment of the product. If this is done, how can designers know which knowledge needs to be assigned to a function? Usually, new products are not absolutely new to the world, but extensions of existing products where the extension can be minor or major. In either case, experienced designers have a very good idea of the types of knowledge and interfaces that are required to create a product. So, a functional diagram and a list of interfaces with knowledge requirements can be developed, and the BZT measure calculated. If, in some cases, some types of knowledge are not identified, they can be added later. For the GE example described in section 3, there are 56 functions and a total of about 170 knowledge assignments to the functions. Therefore, if one or two knowledge requirements were not identified correctly at the beginning, the difference in the calculation of complexity would be small. The same reasoning goes for identification of the interfaces; a small difference in the number makes a small difference in complexity. In fact, this discussion shows one of the benefits of the BZT method, i.e., that it can be used continuously in a project to recalculate complexity as functions, knowledge or interfaces change.

2.3.2. Integration complexity Integration complexity is defined for each pair of functions. Integration of functions or components in a product can be decomposed into a set of interfaces where each interface is between two functions (Rahmani and Thomson 2012). One factor contributing to integration complexity is the number of interfaces, as more interfaces usually put more constraints on the design of functions. Common interfaces include spatial alignment, energy exchange, information 7

transformation and material exchange (Pimmler & Eppinger, 1994). Another driver for integration complexity is knowledge difference. Integrating functions that require different knowledge needs more coordination of designers from different fields, who often have diverse perspectives and use different languages for describing product functions (Bond & Ricci, 1992). Their mutual understanding decreases with knowledge difference (Hage, Jordan, Mote, & Whitestone, 2008), which makes integration more complex. Therefore, the complexity integrating functions

and

is calculated as equation (2), where

between the two functions and

of

is the number of interfaces

is their knowledge difference. Integration complexity is due to

the number of interfaces; however,

is defined in terms of functions. Since there are two

functions for each interface, the constant, 0.5, is added to equation (2) because both functions and

are counted when calculating

. (2)

Each of the two functions making up an interface have knowledge vectors in knowledge space, where the angle of intersection,

, between functions

similarity or difference regarding knowledge content.

and

can be used to indicate the measures similarity and

difference. To keep the order of magnitude consistent with technical complexity, we use equation (3) to measure the knowledge difference between functions

and

, where r is the

upper limit of scale range of knowledge items.

(3)

2.3.3. Total complexity After decomposing a product into a functional diagram, the technical complexity for each function is determined along with the integration complexities for each pair of interacting functions. Then, the total product complexity C is calculated as equation (4), where Ii,j is the integration complexity between functions and Li is the level of function

and

, Wi is the technical complexity of function

in the functional diagram.

8

(4) The proposed complexity measure captures complexity for the aspects of connection, element and topology. Connection is measured by integration complexity driven by knowledge difference and the number of interfaces. Element is measured by technical complexity determined by knowledge intensity. Topology distinguishes functional diagrams that have the same number of functions, but different connectivity. By multiplying elements with their levels in the diagram, the measure takes into account topological complexity explicitly.

3. Applying the BZT complexity measure to estimate project effort and duration Product complexity has been acknowledged as a key driver of design effort (Boehm, 1981; Griffin, 1993; Jacome & Lapinskii, 1997); so, a parametric model can be developed to establish a mathematical relationship between design effort and product complexity. Using this approach and measuring complexity using the Bashir-Thomson complexity measure, GE Hydro reduced the estimation error for design projects by more than 50% (Bashir & Thomson, 2004). We applied the BZT method to the same set of projects and showed that the knowledge-based measure gave a slightly more accurate estimation model for GE Hydro design projects.

9

Figure 3 Functional tree of a hydroelectric generator adapted from (Bashir & Thomson, 2004). Functions are numbered as their indices for easy reference.

3.1. Calculating complexity

10

The calculation of the BZT complexity measure needs data about the functional diagram, knowledge requirement of functions, knowledge scale, and the interdependency among functions as given by design specifications. We used the data from GE hydroelectric generators as reported by Bashir and Thomson (Bashir & Thomson, 2004). The functional diagram is shown in Figure 3. The functions’ knowledge requirements (Table 1), information about the knowledge scale (Table 2), and the interdependency among functions (Figure 4) were gathered by consulting the personnel who worked on the projects.

Air circulation

Water circulation

Heat transfer

Electric-heat generation

Control

Mechanical engineering

Sensor technology

Physics

Electrical engineering

Provide electric power Control environment Provide housing Provide monitoring Provide safety ……

1 1 0 0 0 …

1 1 0 0 0 …

1 1 0 0 0 …

1 1 1 0 0 …

1 1 0 0 0 …

1 1 1 1 1 …

1 0 1 0 1 …

1 0 0 1 1 …

1 0 0 1 0 …

1 0 0 0 0 …

_________

Knowledge

Function

HVAC

Table 1 Some of the functions knowledge requirements

Table 2 Knowledge scale for the design of a hydroelectric generator at GE Hydro

Levels Knowledge 1 HVAC (heating, ventilating and air conditioning) 2 Air circulation 3 Water circulation 4 Heat transfer 5 Electric-heat generation 6 Control 7 Mechanical engineering 8 Sensor technology 9 Physics 10 Electrical engineering

Minimum 0 0 0 0 0 0 0 0 0 0

General 1 1 1 1 1 1 1 1 1 1

Advanced 2 2 2 2 2 2 2 2 2 2

11

Figure 4 The number of interfaces of interdependent functions were documented through a Design Structure Matrix (DSM) of the specified design functions. The first row and first column contain the indices of the functions. In the DSM, 1 means interdependency and 0 means independency between the function in the first row and the function in the first column. Interdependence between functions at the same function tree level is shown by a black outline.

The knowledge information provided input to the calculation of technical complexity for each function. For example, the function “remove heat”, a subfunction of “environment control”, required general knowledge of six knowledge items including HVAC, air circulation, water circulation, heat transfer, electric-heat generation, and control as well as minimal knowledge of the other four types of knowledge. Thus, the technical complexity of the function “remove heat” was calculated as

The interdependency information, together with the knowledge information, provided input for the calculation of integration complexity. For example, it was known that the function “cool air”

12

and the function “circulate air” were to be integrated. “Cool air” required general knowledge of electric-heat generation, control, mechanical engineering and sensor technology as well as minimum knowledge of the other types of knowledge. “Circulate air” required general knowledge of heat transfer, control, mechanical engineering and sensor technology as well as minimum knowledge of the other types of knowledge. The upper limit of the knowledge scale was 2, i.e., r = 2. Thus, using formula (2), the knowledge difference was calculated as

There was one interface between the two functions; so, the integration complexity was . After calculating the technical complexity of each function and the integration complexity between each pair of functions, we were able to determine the total complexity of the product using formula (4). The total complexity of each of the 15 GE Hydro projects is shown in Table 3.

3.2. A parametric model for effort estimation The relationship between complexity and design effort is shown in Figure 5. Each point represents a previously completed project at GE Hydro. The x-coordinate is the calculated BZT complexity (denoted C) and the y-coordinate is the project effort data. A logarithmic scale is used to show an approximately linear relationship. The solid line shows the regression equation with R2 equal to 75.4%. The dashed lines indicate the 95% confidence limits for log10 Effort.

13

Figure 5 Relationship between complexity and design effort using logarithmic scales

To better explain the variation in Figure 5, more effort drivers needed to be investigated. Candidate effort drivers included technical difficulty (denoted T), the type of drawings submitted to customers (denoted G) and the involvement of partners (denoted P), based on Bashir and Thomson’s study at GE Hydro (Bashir & Thomson, 2004). In order to identify useful predictors without overfitting the model, we conducted a best subset regression procedure with Minitab® Statistical Software on the response log10 Effort and four predictors log10 C, log10 T, log10 G and log10 P. The result showed that the common logarithms of complexity, type of drawings and involvement of partners made the best subset, as the model involving these predictors had the highest predicted 1 R2. The elimination of technical difficulty is reasonable as the BZT complexity measure already takes technical knowledge into account.

1

Predicted R2 measures the predictive ability of a regression model. The calculation of predicted R2 is an iterative process that omits the i-th observation ( ), estimates a regression model from the remaining observations, then uses the model to obtain the predicted value for the i-th observation ( ). Predicted R2 is computed as

.

2

Predicted R prevents overfitting as it is calculated using observations not included in model estimation. Greater predicted R2 means a better predictive ability.

14

Table 3 Data for the development of a parametric estimation model

Project

Response Historical effort (person-hours) 20392 8192 13544 11880 8384 27200 20800 30400 19824 16944 20112 26816 10704 10856 8760

#1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 #12 #13 #14 #15

C 517.1 338.3 389.6 374.7 315.7 458.8 381.8 463.3 421.1 434.7 438.6 470.8 357.2 403.0 326.6

Predictors G 1 1 1 1 1 2 2 2 2 2 3 2 1 1 1

P 1 1 1 1 1 1 1 2 1 1 1 2 1 1 1

C: BZT complexity. G: Type of drawings submitted to customers. G=1 if basic drawings were submitted; G=2 if assembly drawings were submitted; G=3 if manufacturing level drawings were submitted. P: involvement of partners. P=1 if no design partner was involved; P=2 if design partners were involved.

The linear relationship between design effort and the selected predictors on the logarithmic scale determined the form of the parametric model as . The original data of historical effort and the selected predictors are summarized in Table 3, which was transformed to its common logarithmic value to estimate the parameters

,

,

and

. The jackknife technique2 was applied in order to reduce the risk of

biased estimates caused by the small sample size of the projects. Changing the dropped subsample one by one gave us 15 sets of pseudo-values, whose average was used as the estimates for the parameters. Performing the jackknife technique and using the least squares method

generated

the

parametric

model:

, with R2 equal to 90.83%. Transforming the linear equation back to the original domain gives the power relationship as shown in equation (5). 2

The first step of the jackknife technique is to use the whole sample to estimate the parameters (denoted A). Second, a partial estimate (denoted A-n) is calculated from a smaller sample obtained by dropping the n-th subsample. A pseudo-value (denoted An*) is then computed as An* = A - A-n. The subtraction eliminates possible bias.

15

(5) The mean magnitude of relative error (MMRE) was used to test the performance of the model. MMRE calculates the difference between actual and estimated effort relative to the actual effort. It is the most common evaluation criterion for assessing the performance of prediction models in the software industry. MMRE is computed using equation (6), where project i,

is the estimated effort of

is the actual effort of project i, and N is the total number of projects. As shown in

Table 4, the MMRE of the company’s original estimations was 27%; Bashir and Thomson’s model reduced the MMRE to 13% (Bashir & Thomson, 2004); the BZT model further reduced the error to 10%, and thus, provided a slightly more accurate estimation model. In addition, the low value of the MMRE shows that functional analysis along with knowledge requirements takes into account a very large proportion of the factors that add complexity to a product. Although the improvement of the BZT method in effort estimation compared to the BashirThomson method is small, a benefit of the use of a knowledge perspective in the BZT method is that it allows the comparison of the needed effort versus the planned effort on a skill/expertise basis. Functions can then be divided among the design team based on each individual’s capability versus requirements. In addition, the BZT method considers complexity due to knowledge and interface requirements, where interface requirements result in greater complexity compared to knowledge requirements (Zhang, 2017). The GE data for a generator that is used in this paper has limited interfaces between functions, and thus, does not show this feature well.

(6)

16

Table 4 Comparing the accuracy of models

Project #1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 #12 #13 #14 #15

Actual effort 20392 8192 13544 11880 8384 27200 20800 30400 19824 16944 20112 26816 10704 10856 8760

Company Estimate Error (hours) (%) 16900 17 11600 42 10088 26 14000 18 11200 34 15400 43 16600 20 20000 34 17400 12 17400 3 16000 20 24000 11 13600 27 16000 47 13200 51 MMRE=27

Bashir-Thomson Estimate Error (hours) (%) 18969 7 10091 23 11916 12 10902 8 9191 10 20713 24 15385 26 31791 5 17267 13 17530 3 21593 7 33623 25 11018 3 12898 19 8524 3 MMRE=13

BZT Estimate Error (hours) (%) 20079 2 9412 15 12113 11 11295 5 8319 1 22201 18 15988 23 28084 8 19048 4 20163 19 24619 22 28898 8 10374 3 12867 19 8841 1 MMRE=10

3.3. A parametric model for duration estimation Norden (1964) found out that all development projects had the same profile of effort versus time, and he developed a model to represent this as shown in equation (7), where utilized at time t,

is the total effort, and

is the effort

is a shape parameter. The shape of Norden’s model

is a skewed normal distribution as shown in Figure 6. The formula calculates the instantaneous design effort at any point of time during a project. Based on the model, Bashir and Thomson (2001) derived a formula to estimate project duration, as shown in equation (8), where

is the

total effort, x is the ratio of design effort spent on the last month to the total design effort, and is the ratio of total design effort to time-to-peak. Substituting equation (5) into formula (8) gives the parametric model for project duration for the GE Hydro projects as shown in equation (9).

(7)

17

Person-months

14 12 10 8 6 4 2 0 0

5

10

15 Months

20

Figure 6 Norden’s model, with =150 person-months and

25

30

= 0.01

(8)

(9)

4. Applying the BZT measure to monitor schedule A critical path is "the sequence of schedule activities that determines the duration of the project." (Project Management Institute, 2013) The critical path method has been used routinely in project management. Project managers monitor the progress of activities on the critical path and make resource decisions to avert any delays. By clearly defining the knowledge requirements of each function, the BZT method can assist decision-making with regards to resource allocation. The BZT method can calculate a complexity index for each function, which includes a function component and an integration component. As shown in equation (10), the complexity of function i is the sum of its integration complexity with all the other functions and its technical complexity. So, the complexity and knowledge requirements of critical functions can be labeled along the critical path. Evaluating designers’ ability with the same knowledge scale, managers are able to identify a mismatch between a function’s knowledge requirements and the knowledge level of the assigned designer.

18

(10) For project managers, then, the question is: what is the impact of the knowledge mismatch on the finish time of an activity that is on the critical path? If an organization repeatedly uses a process, then, an experienced manager should know the functions on the critical path and should understand how a knowledge mismatch can affect the timeliness of activities on the critical path. Based on experience, managers should also have a good idea of how long designers with different knowledge should take to do an activity. Thus, an experienced manager should be able to adjust task assignments and resources in order to manage project performance, viz., schedule and cost.

5. Conclusions During product design, designers apply specialist knowledge and collaborate to solve issues due to product complexity. It is the intensity and diversity of the knowledge required by product functions that drives complexity. Despite the significant role of knowledge in understanding the management of complexity, there has been little to no research done on measuring complexity from a knowledge perspective. To fill the gap, this paper introduced the BZT complexity measure. In the BZT measure, knowledge required to specify a product design is quantified using a knowledge scale. Product functions obtained from functional decomposition are mapped to a knowledge space. The BZT complexity method captures product topology through a functional diagram, the technical complexity of each function through knowledge intensity, and integration complexity through knowledge difference and the number of interfaces for each function. The complexity of each individual function is computed as the intensity of its knowledge requirements, and the complexity of integrating the function to other functions. A parametric model with complexity as the key factor was constructed to successfully estimate the effort for designing hydroelectric generators at GE Hydro. With knowledge connecting product requirements and designer capability, the BZT measure allows managers to evaluate the match between the required product knowledge and the design team’s knowledge. Since the process of applying the BZT method explicitly identifies the

19

knowledge requirement and the knowledge scale, project managers are able to label the knowledge requirement of functions and the knowledge ability of the assigned designers along the project critical path. Thus, a possible issue due to a knowledge mismatch can be diagnosed and adjustments concerning assignments can be made to improve performance. Additional work for applying the BZT method to estimate project effort and duration is underway with different companies. As indicated earlier, interface requirements result in greater complexity compared to knowledge requirements. It is expected that the studied projects will have large amounts of integration and that the BZT method will be more effective than the Bashir-Thomson method for estimating complexity. Future work will focus on perfecting the method and on relating required project knowledge to the knowledge of the project team in order to help manage the assignment of personnel to projects. Although the demonstration of the BZT method in this paper was for product design, the BZT method can be used for any type of project where project content can be represented by a functional diagram and by the required knowledge for creating project functions as well as for any interfaces between functions.

References Ameri, F., Summers, J. D., Mocko, G. M., & Porter, M. (2008). Engineering design complexity: an investigation of methods and measures. Research in Engineering Design, 19(2-3), 161-179. Barclay, I., & Dann, Z. (2000). New-product-development performance evaluation: a productcomplexity-based methodology. Science, Measurement and Technology, IEE Proceedings -, 147(2), 41-55. doi:10.1049/ip-smt:20000077 Bashir, H. A. (2000). Models for estimating design effort. (Doctor of Philosophy), McGill Univeristy. Bashir, H. A., & Thomson, V. (1999a). Estimating Design Complexity. Journal of Engineering Design, 10(3), 247-257. doi:10.1080/095448299261317 Bashir, H. A., & Thomson, V. (1999b). Metrics for design projects: a review. Design Studies, 20(3), 263-277. doi:http://dx.doi.org/10.1016/S0142-694X(98)00024-6 Bashir, H. A., & Thomson, V. (2001). Estimating effort and time for design projects. Paper presented at the Canadian Society of Value Analysis Conference. Bashir, H. A., & Thomson, V. (2004). Estimating design effort for GE hydro projects. Computers & Industrial Engineering, 46(2), 195-204. doi:http://dx.doi.org/10.1016/j.cie.2003.12.005

20

Boehm, B. W. (1981). Software engineering economics (Vol. 197): Prentice-hall Englewood Cliffs (NJ). Bond, A. H., & Ricci, R. J. (1992). Cooperation in aircraft design. Research in Engineering Design, 4(2), 115-130. doi:10.1007/bf01580149 Braun, S. C., & Lindemann, U. (2008, 8-11 Dec. 2008). The influence of structural complexity on product costs. Paper presented at the 2008 IEEE International Conference on Industrial Engineering and Engineering Management. Crespo-Varela, J. R., Kremer, G. E. O., Tucker, C. S., & Medina, L. A. (2012). An analysis of complexity measures for product design and development. Paper presented at the ASME 2012 International Design Engineering Technical Conferences and Computers and Information in Engineering Conference. Davis, J., Subrahmanian, E., & Westerberg, A. (2005). Knowledge Management: Organizational and Technological Dimensions: Physica-Verlag HD. Granstrand, O., Bohlin, E., Oskarsson, C., & Sjöberg, N. (1992). External technology acquisition in large multi‐technology corporations. R&D Management, 22(2), 111-134. Griffin, A. (1993). Metrics for measuring product development cycle time. Journal of Product Innovation Management, 10(2), 112-125. doi:http://dx.doi.org/10.1016/07376782(93)90003-9 Hage, J., Jordan, G., Mote, J., & Whitestone, Y. (2008). Designing and facilitating collaboration in R&D: A case study. Journal of Engineering and Technology Management, 25(4), 256268. doi:http://dx.doi.org/10.1016/j.jengtecman.2008.10.005 Hölttä, K. M. M., & Otto, K. N. (2005). Incorporating design effort complexity measures in product architectural design and assessment. Design Studies, 26(5), 463-485. doi:http://dx.doi.org/10.1016/j.destud.2004.10.001 Jacome, M. F., & Lapinskii, V. (1997). NREC: risk assessment and planning of complex designs. IEEE Design & Test of Computers, 14(1), 42-49. doi:10.1109/54.573364 Kleinsmann, M., Buijs, J., & Valkenburg, R. (2010). Understanding the complexity of knowledge integration in collaborative new product development teams: A case study. Journal of Engineering and Technology Management, 27(1–2), 20-32. doi:http://dx.doi.org/10.1016/j.jengtecman.2010.03.003 Lederer, A. L., & Prasad, J. (1995). Causes of inaccurate software development cost estimates. Journal of Systems and Software, 31(2), 125-134. doi:http://dx.doi.org/10.1016/01641212(94)00092-2 Lewis, K. (2012). Making Sense of Elegant Complexity in Design. Journal of Mechanical Design, 134(12), 120801-120801. doi:10.1115/1.4023002 Lucke, L. E., Mickelson, A., & Anderson, D. (2009). Proving experience speeds medical device time to market. Paper presented at the 2009 Annual International Conference of the IEEE Engineering in Medicine and Biology Society. Madhavan, R., & Grover, R. (1998). From Embedded Knowledge to Embodied Knowledge: New Product Development as Knowledge Management. Journal of Marketing, 62(4), 112. doi:10.2307/1252283 McGrath, J. E., & Argote, L. (2008). Group Processes in Organizational Contexts Blackwell Handbook of Social Psychology: Group Processes (pp. 603-627): Blackwell Publishers Ltd.

21

Meyer, M. H., & Utterback, J. M. (1995). Product development cycle time and commercial success. IEEE Transactions on Engineering Management, 42(4), 297-304. doi:10.1109/17.482080 Nissen, M. E. (2002). An extended model of knowledge-flow dynamics. Communications of the Association for Information Systems, 8, 251-266. Norden, P. V. (1964). Manpower Utilization Patterns in Research and Development Projects. (Doctor of philosophy), Columbia University. Otto, K. N., & Wood, K. L. (2001). Product design: techniques in reverse engineering and new product development: Prentice Hall. Pimmler, T. U., & Eppinger, S. D. (1994). Integration analysis of product decompositions. Project Management Institute. (2013). A Guide to the Project Management Body of Knowledge: PMBOK Guide: Project Management Institute. Rahmani, K., & Thomson, V. (2012). Ontology based interface design and control for collaborative product development. Journal of Computer-Aided Design, 44, 432-444. Shafiei-Monfared, S., & Jenab, K. ( 2012). A novel approach for complexity measure analysis in design projects. Journal of Engineering Design, 23(3), 185-194, DOI: 10.1080/09544828.2011.554389

Shah, J. J., & Runger, G. (2013). What is in a name? On the misuse of information theoretic dispersion measures as design complexity metrics. Journal of Engineering Design, 24(9), 662-680. Singh, G., Balaji, S., Shah, J. J., Corman, D., Howard, R., Mattikalli, R., & Stuart, D. (2012). Evaluation of network measures as complexity metrics. Paper presented at the ASME 2012 International Design Engineering Technical Conferences and Computers and Information in Engineering Conference. Sinha, K., & de Weck, O. L. (2016). Empirical Validation of Structural Complexity Metric and Complexity Management for Engineering Systems. Systems Engineering, 19(3), 193-206. doi:10.1002/sys.21356 Tamaskar, S., Neema, K., & DeLaurentis, D. (2014). Framework for measuring complexity of aerospace systems. Research in Engineering Design, 25(2), 125-137. doi:10.1007/s00163-014-0169-5 Tomiyama, T., D’Amelio, V., Urbanic, J., & ElMaraghy, W. (2007). Complexity of MultiDisciplinary Design. CIRP Annals - Manufacturing Technology, 56(1), 185-188. doi:http://dx.doi.org/10.1016/j.cirp.2007.05.044 Zhang, X. (2017). Measures and Mitigation of Complexity during Product Development. PhD Thesis, McGill University, Montreal

22

Research highlights 

A complexity measure is developed from the knowledge perspective.



Technical complexity, integration complexity and product topology are captured.



The measure is applied to improve the estimation of project effort and duration.



The measure allows managers to identify knowledge mismatch.

23