Control in the Construction Industry
4.2 Product Development Process 1 Defi nition
Th e PDP has been a key topic of study within industrial and manufacturing engineering, and has more recently been considered in construction [e.g., Koskela 2000; Kagioglou et al. 1998]. Most studies examine the management of new product introduction, as well as the processes used for developing an idea or need into a fi nished product, with the associated support and services [Reinertsen 1997].
Ulrich and Eppinger (2000) defi ne the PDP as “the set of activities beginning with the perception of a market opportunity and ending in the production, sale and delivery of a product.” Th e authors stress that it is necessary to bring together the main functions of the enterprise; that is, marketing, design, manufacturing, and aft er sales, in order to achieve
47450_C004.indd 2
Supply Chain Management in Product Development 4-3
successful product development. Smith and Morrow (1999) and Hales (1993) defi ne prod- uct development as the process of converting an idea, market needs, or client require- ments into the information from which a product or technical system can be produced.
Similarly, the PDP in construction is conceptualized in this chapter as “the set of activities needed for the conception and design of a built product, from the identifi ca- tion of a market opportunity to its delivery to the client.”
Clark, Chew, and Fujimoto (1992) contend that design produces a product much as any other process produces a product, and the design product diff ers mainly in the sense that it is information rather than a physical asset. Th ese authors also argue that both design and production have outputs of two types, physical and information, but the physical outputs diff er in their use (e.g., prototypes are used to refi ne design). However, design is an intellectual, nonrepetitive activity, closely related to the customers, as it focuses on translating requirements into design solutions, thus creating value and innovation.
Koskela (2000) points out that product development and design have two key charac- teristics: uncertainty and interdependency. Uncertainty is related to the lack of informa- tion or to instability of information. Th is means that not all information necessary to conduct a design task is available when needed; and requirements change throughout design development. Th us, uncertainty is a consequence of the lack of information on matters under development. Interdependency happens due to tight links between activi- ties; that is, the information produced in one activity is interactively needed in the devel- opment of other activities [Austin, Baldwin, and Newton 1994]. Koskela (2000) further states that iterations may also occur due to constraints of downstream stages being over- looked in upstream stages, which is a problem that could be avoided by considering all life-cycle phases simultaneously. In practice, teamwork strategies and early involvement of stakeholders are strategies used to allow for such whole life-cycle considerations.
Excessive changes in requirements and the project scope cause disruptions in the PDP. Th erefore, it is important that the project vision and scope are defi ned carefully at early product development stages, in order to eliminate avoidable changes at later stages [Sebastian 2005; Koskela 2000; Barrett and Stanley 1999; Cooper and Press 1995]. Th is is one of the reasons why the process front end1 has been recognized as being critical for the PDP success.
At the front end of product development, new product ideas gain shape, plans, and support, leading to their approval and execution [Khurana and Rosenthal 2002]. In this chapter, we adopt the term “front end” with reference to the preliminary, preproject stages of the design and construction process. Requirements management is considered to be an on-going activity throughout the PDP.
In the new product development literature, front-end activities are oft en divided into stages, for instance: (a) prephase zero (opportunity identifi cation and idea generation); (b) phase zero (product concept and defi nition, including market and technology assess- ment); and (c) phase one (product defi nition, justifi cation, and planning) [Cooper 1998; 1 Th e preliminary stages of a project have been labeled fuzzy front-end of the PDP by Smith and
Reinertsen (1991), and this term has since been adopted by several authors. Reinertsen (1997) and Zhang and Doll (2001) propose that the front-end activities represent the fi nal gate before the team decides to invest in designing and building products.
47450_C004.indd 3
4-4 Construction Supply Chain Management Handbook
Zhang and Doll 2001; Khurana and Rosenthal 2002; Van Aken and Nagel 2004]. In the construction literature, the initial phases of construction projects are oft en referred to as front end. Kagioglou et al. (1998), for instance, defi nes the construction process front end as follows:
(a) Phase 0 (demonstrating the need for the project), including the outline business case
(b) Phase 1 (conception of need), including the brief
(c) Phase 2 (outline feasibility), including feasibility studies for diff erent design options
(d) Phase 3 (substantive feasibility study), which is the building product defi nition, and includes the conceptual project brief
Th e literature stresses that front-end success depends on the existence of foundation elements; that is, a clear product strategy and a product development organization [Khurana and Rosenthal 2002]. Product strategy elements include the formulation and communication of a strategic vision for the product, as well as its high-level require- ments. Th e product development organization should be clearly defi ned in terms of structure, stakeholders, communication networks, roles, and norms. In construction, foundation elements heavily depend upon clients, since the product strategy should be defi ned by clients, and the project organization will be greatly determined by the pro- curement and contractual arrangements selected by clients. Moreover, providing prod- ucts and services of value to customers is facilitated through the integration of supply chain members within the product development organization [Tan and Tracey 2007].
It has been widely acknowledged in the literature that benefi ts resulting from improve- ments in the front end are likely to exceed those that result from improving subsequent design stages [Cooper and Kleinschmidt 1996; CRISP 2001; Khurana and Rosenthal 2002]. Appropriate decisions and decision-making mechanisms at the front end may therefore help reduce uncertainty throughout the PDP [Reinertsen 1997; Van Aken and Nagel 2004].
4.2.2 Generic PDP Models
Early research on new product development has produced descriptive models and frameworks that model this process as mainly linear, and divided it into sequential and discrete stages. Generic, phased, or “high-level” models aim to provide an overview of the whole process, describing the main stages and activities [Kagioglou et al. 1998; Austin et al. 2000]. Th ese models were usually built to be used as templates containing generic processes and a set of tools, working as checklists for the key steps in the product development activity. Such maps focused upon organizing the work to be developed and the main fl ows of information within an organization, and between diff erent actors and organizations in a broad perspective.
Phase reviews, or stage-gate processes, are oft en included in product development models [Cooper 1998]. Th ese defi ne steps that require input from clients, including the evaluation of ideas early in the process, the identifi cation of important features as the
47450_C004.indd 4
Supply Chain Management in Product Development 4-5
product concept is defi ned, measures of the importance of customer needs as the prod- uct is engineered, and accurate evaluation when the product is delivered [Dahan and Hauser 2002]. Diff erent actors become involved at diff erent process stages in order to support client involvement and the production of appropriate design information. Th is creates a network of internal client–supplier relationships.
However, in construction, relationships between stakeholders are mostly implicit [Oakland and Marossezkey 2006]. Th ere is a long chain of events throughout the project and each stakeholder may have diff erent internal customers at diff erent process stages. Moreover, such relationships are not made clear through contractual arrangements—for instance, a subcontractor may perceive the contractor as the only customer, neglecting the requirements of other subcontractors or the fi nal user of the facility. Th is may gener- ate further uncertainty and increase the interdependency between tasks, and may also result in the lack of consideration of interdependencies, causing waste during design.
Such implicit relationships between supply chain members have led to the recogni- tion that product development is not a linear process. Recently, recursive and somehow complex frameworks of the PDP have been developed, acknowledging that the PDP progresses through a series of stages, but with overlaps, feedback loops, and resulting behaviors that may not fi t reductionism or linear analysis [McCarthy et al. 2006].
Similarly, recent research has shown that the design and implementation of PDP mod- els within diff erent organizational contexts is very complex. Empirical research results have demonstrated that the expected benefi ts of a PDP model can only be accomplished and enhanced if there is an appropriate strategy. Th is strategy should provide an overall driving force for implementation, and allow the adaptation of the model to the company and to specifi c projects [Tzortzopoulos 2004]. Gann and Salter (2000) and Koskela and Vrijhoef (2001) support this argument, stating that tackling the relationship between business processes (at the company level) and project processes (at the project level) is a major challenge both in practice and theory. Th erefore, identifying and understanding the role of supply chain members in the PDP is challenging.
4.2.3 Complexity of the Client Organizations
Diff erent conceptual approaches have been adopted to understand the characteristics of the construction client. Early views generally assumed that the term “client” implies a person or a well-defi ned group of people that act as a single entity [Newcombe 2003; Bertelsen and Emmitt 2005]. However, issues such as the separation of ownership and occupation, and the rise of corporate clients have led to confusion about the clients’ identity and their interaction with the industry [Newcombe 2003].
Past research identifi ed diff erent types of clients. Higgin and Jessop (1965), for instance, made a distinction between sophisticated and naïve clients on the basis of their previous experience with construction. Masterman and Gameson (1994) argued that clients cannot be classifi ed solely on the grounds that they possess previous experience; they must have experience of the particular building type in question.
Darlington and Culley (2004) described two customer types that can also be used to classify construction clients. Th e fi rst type, the identifi able customer, represents the individual who has a specifi c design problem, such as a family needing a new house. Th e
47450_C004.indd 5
4-6 Construction Supply Chain Management Handbook
identifi able customer usually has a fairly clear view of the problem and the context in which it occurs, which can be discussed directly with designers. By contrast, the “virtual” customer represents a group or class of individuals. Th e customer’s requirement manage- ment process is quite diff erent for each type of client.
In summary, there are diff erent approaches to describe the construction client’s iden- tity; some focus on the level of experience the client has with construction, and others on the level of complexity of the client (organization). Public sector organizations like the UK National Health System (NHS) may be classifi ed as virtual, complex clients. Th is type of client must appropriately represent various stakeholder groups as well as the needs of wider society. In the primary healthcare context, Primary Care Trusts (PCTs) are newly established organizations operating against a background of change in pri- mary care, whose employees have little or no experience with design and construction. Th erefore, they can be considered as naïve or novice clients. Th e challenge for virtual, novice, and complex clients is, therefore, to provide appropriate information for design and construction even though they possess poor understanding of the PDP.