A planning - design interaction model to improve customer satisfaction Massimo Lemma, Università Politecnica delle Marche, Italy (email: m.lemma@univpm.it) Alberto Giretti, Università Politecnica delle Marche, Italy (email: a.giretti@univpm.it ) Roberta Ansuini Università Politecnica delle Marche, Italy (email: r.ansuini@univpm.it ) Abstract Quality concerns satisfying clients needs, and designing is aimed at translating clients needs into building requirements. In the first programming phase of a design development, customers are required to draw master-plans (needs, budget, etc.) which could either support, if well focused, or hinder, if too much detailed, the creative freedom of architectural design. That could cause negative repercussion to customers themselves. The analysis of several real cases shows that on one hand best designs are developed only when customers master-plans are focused on their high priority needs, and, on the other hand, that customers become aware of the priority of their needs only when a number of real alternatives have been proposed. Consequently we can argue that the requirement definition and the design phase cannot run but concurrently. In this paper we analyze current trends in requirement elicitation methodologies that regulates the interaction between customers master-plans and designs, and propose new methodologies for supporting requirement tracking and scenario analysis based on Bayesian Decision Networks. Keywords: Requirement Engineering, Bayesian Networks, Building Construction Management 1. Introduction The need for a clear understanding of the clients requirements has always been associated with the project success. It has been widely acknowledged in both manufacturing and construction literature that the client front-end is critical, and benefits resulting from improvements in the front-end are likely to exceed those that result from improving subsequent design stages [4]. In construction, building requirements are described in the brief. Early approaches regulating project specifications considered the brief as a static document produced at a specific point in time as a results of an fairly structured process of client requirement capture. The RIBA Plan of Work links the client brief to stages of the construction process. It was intended that the project brief should be developed between Stage A (inception) and Stage D (sketch design) and should not be altered after this point [15]. On the same line the Italian legislation establishes a three stage project development that is interleaved with contractual or validation steps that practically hinder any attempt to feedback the previous stages with project revisions. The Netherlands Building Research Board published a new Client s Brief Model that foresaw a strong connection between the development of the client s brief and the development of the plan. This 381
approach acknowledged that the brief and the plan are fundamentally different things and that the client s brief develops as the project progresses [14]. The briefing process described subsequently in the RIBA Architect s Job Book is divided into four stages: the initial brief, project brief, design brief and consolidated brief as the design is developed. These are developed concurrently with the Plan of Work Stages A E and interact with these [4]. Recent works on the design studies area further analyzed the clients brief from a procedural viewpoint, identifying roles, activities, information need, scope and goals. It was realized the challenges to achieve an agreed composite view of all stakeholders, as in many instances stakeholders needs and interests are conflicting [12][5][18]. Furthermore these research shows that requirement definition is essentially a wicked process. In fact it frequently starts without a completely clear awareness of the customers need and of the technical possibilities. It then proceeds as in an iterative way through a negotiating process that involves both social, strategic, financial and technical decisions. Frequently agreements are achieved without a complete awareness of the their actual implications on quality, costs etc. On the other hand established project values are often vanished by side effects of decisions taken within diverse scopes. Attempts have been made to mitigate this complex interactions by applying the methodology of value engineering to manage the user requirements throughout the design and construction life-cycle [13]. The intertwining of the social processes affecting client briefing and the technical design processes has been emphasized in [2], where personal representation of ideas and the social processes of the briefing process are considered to be part of the design process, and where it has been shown that there is an unknown area of knowledge that the client or the designers are not aware of at the project outset. It is this unknown knowledge which feedback and discussions amongst the project team open up through the dynamics of the project. Finally in the manufacturing domain the Quality Function Deployment (QFD) methodology is a well established practice for eliciting, prioritizing and tracking requirements throughout the project development [1]. It has been shown effective in many production cases [6][7][11][12][17] and could have a potential positive impact even in the more unstructured construction area. Summarizing the clients requirement definition is a critical process that involves to the whole design process and all the critical stakeholders with conflicting goals, that it is twisted with many design phases. Furthermore requirement definition is a wicked process as much as design is. In this paper we will adopt a QFD conceptualization, further enhanced with Bayesian Network technology, to sketch a methodological background for new approaches to customer need and design requirement tracking, as well as for scenario analysis in the construction domain. 2. Requirement co-design The understanding of the requirement definition within the framework of design processes requires the introduction of a suitable conceptualization for characterizing wicked problems. We will use one of the most widely shared meta-model for design process description that is based on the conception of underdetermined or wicked design problems [8]. 382
According to this meta-model requirements definition problems are only partly determined by initial statements about customer needs, resources and intentions. In fact the initial set of requirements does not usually contain enough information to build a complete design space. Rather, requirement definition and designing flow concurrently, through the exploration of the possibilities explicitly emerged during the client - designer interactions and/or through their reinterpretation in case of unsatisfied constraints. This process is usually called co-evolution, its goal is to arrive at a matching need-requirement-design triplet (figure 1). As a consequence, the requirement and the design spaces are not stable but evolve through a set of stages. Each step is characterized by the set of relevant issues, the ones that emerge during customer - designer interaction, and may be contradicted, justified and/or further developed in subsequent steps. Requirement R(t) R(t+1) Specification Revision Specification Design Space D(t) D(t+1) Time Figure 1 A simple conceptual schema of the co-evolution of the requirement definition design processes. Both requirements and design can evolve autonomously through logical and technological implications. Requirements produce design specifications and design solutions can imply requirement revisions. Further complexities emerge if we represent the internal process dynamics of requirement definition and design. At this level of analysis (see figure 2) requirements are the result of a specification of customer needs, desires, visions etc. while designing evolves concurrently from specifications to solutions in many different design spaces (e.g. conceptual, technological, financial, etc.). The interaction among requirements and design solutions is therefore much more fragmented, since it can occur among different domains and at different points in time. The fundamental dynamicity and, in principle, the unpredictable nature of the interaction between requirement definition and design clearly emerge. The evolution of customer s need along the design development as well as the revision of design specifications are the rule not the exception. Consequently the management of the dependencies among requirements and specification as well as tracking of design alternatives for each decision point is necessary. 383
Requirement Definition N(t) Specification Revision N(t+1) Specification Revision N(t+2) Specification R.(t) R.(t+1) R.( t+2) Conceptual Design S(t) S(t+1) S(t) Technological Design S(t+1) Developmen Revision Developmen Revision D(t) D(t+1) D(t) D(t+1) Figure 2 A more complex conceptual schema of the co-evolution of the requirement definition and design processes. Requirement definition involves the specification of needs N(t) and their mapping to requirements R(t). Requirements are translated into design specifications S(t) in different design domains (e.g. conceptual, technological etc.). Design specification are developed into design solutions D(t). Revisions (dashed lines) may occur at every step. At present the current methodologies for requirements management are not able to completely capture and manage the dynamic aspect of requirement evolution and to keep the customer aware of the real possibilities. For example, the advanced QFD framework (figure 3 and figure 4) is able to trace dependencies among requirements and design specifications at different stages of the design development, to state requirements priorities, to capture alternatives but it s not able to effectively support the backtracking among different project alternatives, nor it is able to express fuzziness and uncertainty in requirements formulation. Figure 3 The Quality Factor Deployment project roadmap. The Four-Phase approach uses a QFD Matrix to translate Customer Wants into Product Characteristics. The Product Characteristics are then translated through another QFD Matrix into Part Characteristics. Part Characteristics are translated into Process Characteristics. Finally, Process Characteristics are translated into Production Controls. 384
Figure 4 The QFD House of Quality, a detailed view of each step of the process represented in figure 3. (1)A list identifying the customer expectations, (2) a list containing the set of design features contributing to customer expectation, (3) a matrix relating customer requirements to design features (4) A list containing the implementation aspects, (5) a cross reference matrix identifying the synergistic or detrimental impact of changes among design features, (6) a planning of requirement implementation. In the construction domain, where different stakeholders spread along the design and construction timeline take decisions concurrently concerning different parts of the project with strong relationships the rigid subdivision in phases, that suits a more structure manufacturing process, is rather inadequate. This is particularly true when the legislation or the sub-contractual economics obligate to break the project into self contained pieces regulated by different contractual constraints. In the following section we introduce an evolution of the QFD methodology grounding its requirement definition conceptualization on the well defined formalism of Bayesian Networks [10], which provides a more flexible way of specifying requirement and a well funded support for the customer decisions. 3. Bayesian Quality Factor Deployment The core mechanism of the QFD inference relies on a set of maps that are made of 2 basic components: Lists, and Matrices. Lists are used to define the inputs and outputs of a decision making process. Matrices are used to relate two, or more, lists to each other. Example Lists include User Benefits, Measures, Basic Expectations, Functions, and Alternative Concepts. Priority and performance rating values, obtained from Market Research, can be associated with each of these lists. Relationships among lists can be weighted according to a predefined scale. A common QFD Matrix relates Measures to User Benefits or to both User Benefits and Basic Expectations. A Project Roadmap is a graphical definition of the lists, and matrices included in a project. For each step, one or more calculations (i.e. rooms) can be performed aside the core relationship matrix to deduce some performance or summary factors. The basic idea of the proposed approach is to enhance the QFD core relationship mechanism, that is essentially based on a spreadsheet calculation engine, with a more flexible Bayesian Network (BN) formalisms in order to provide support for forward and backward inference, for 385
probabilistic reasoning and in general for scenario analysis. A Bayesian Network (or belief network) is a probabilistic graphical model that represents a set of variables and their probabilistic independencies. Formally, Bayesian networks are directed acyclic graphs whose nodes represent variables, and whose arcs encode conditional independencies between the variables. Nodes can represent any kind of variable, a measured numeric parameter, a qualitative requirement, a project performance factor or technological feature. Efficient algorithms exist that perform inference and learning in Bayesian Networks with mixed qualitative and numeric domains. The available technology offers BN packages that can be easily embedded in any programming language or application (e.g. spreadsheet), letting development of Bayesian Quality factor deployment straightforward. Influence diagrams (ID) are a special kind of BN for explicitly modelling decision processes. An influence diagram is simply a BN, extended with utility nodes and decision nodes and can perform utility and probabilistic inferences in parallel (figure 5). Figure 5 An example of a Bayesian Decision Network. Diamonds represent the customer s utility functions; rectangles represent decisions that should be taken by the customer or designers; ovals represent domain models that are used to evaluate the utilities coming from one or more decisions. 4. An Example For example we consider the following case: a private investor is planning to build a three storey building with possible different destinations of use, that could eventually change during the building life-cycle. Initial brief with designers pointed out two main strategic objectives: having an outstanding visual impact and being quite flexible in use destination. The initial Decision Net contains four utility nodes, two customer specific, two concerning minimum requirements from the EU norms and one concerning costs, as shown in figure 6. Figure 6 The start-up network contains only utility modes capturing the main expected performance. 386
Preliminary sketches of the building maximized the visual impact and its technological mood, adopting a totally transparent solution with a glass facade and a steel frame. In the meantime the investor financial analysis predicts three different ROI and run time revenues levels depending on three ranges of building maintenance costs, precisely in the range of 100.000, of 200.000, or more than 300.000 per year, personnel excluded. A preliminary estimation of maintenance costs pointed out that a considerable part of these expenditures concerns cleaning, heating, cooling and the lighting systems. Consequently the requirement model was further developed as show in figure 7. The cost structure has been introduced and the utility functions were updated to represent customer trade-off between financial cost and eventual budget saving. The relationships among chance nodes where calculate using simple mathematical formulas. The Bayesian network will use the utility functions to calculate preferences for each entry of the decision nodes. Figure 7 The network after the maintenance concerns; a new utility node representing maintenance costs as well a simple cost structure has been introduced. The new information on maintenance costs raised a new issue concerning the increase of the thermal efficiency of the building envelope, let s say moving its transmittance in the range of 0.5 W/m K. Nevertheless external lighting should still be used as much as possible since it generally implies better marketing chances. Consequently the initial choice to use a totally transparent envelope was reconsidered, and a whole range of solutions were evaluated: whole glass facades, mixed opaque and transparent solutions, etc. The network was consequently updated to reflect the new technological insights. Figure 8 shows the details. New decision nodes concerning the type of facade (i.e. totally transparent, mixed, opaque) and the type of glass (i.e. insulating, single layer, etc.) were introduced and referenced to performance nodes concerning the thermal loss or the level natural lighting used. The evaluation of the impact of the facades and of glass types on the costs required some estimation and simple calculations. At this point the customer requirement model was completed enough to start taking initial decision through a scenario analysis. 387
Figure 8 The network after the issue concerning thermal efficiency of the envelop; the linear path among decision nodes stands for decision priority. After running the network without any observations, the budget node show positive utilities for budgets larger than 1.5M. This is due to the averaging of the utility functions which have been calculated according to the network setup. Figure 9 The utility distribution of the budget node without any observation. Selecting a budget range between 1.5 and 2.0M and forcing to have financial costs in the range of 125000 250000 give an utility distribution of the facade decision node that promotes a totally opaque solution. The utility distribution depends on how the utility functions have been defined for each utility node. In this case the customer put great priority on the financial aspects, weighting the project cost utility one order of magnitude more that the others utilities. Therefore constraining the budget and financial costs deeply affects the technological solutions. Nevertheless the model shows also the possibility to explore a mixed transparent opaque solution (Figure 10) allowing for a lower but still largely positive utility (e.g. 125 instead of 281). Figure 10 The utility distributions after the selection of 1.5M budget 388
Selecting the mixed facade solution the network calculates the utility function for the next node in the decision chain, the type of glass. The resulting figures propose to save money using single layer glass (Figure 11) since the budget driven approach. Nevertheless a possible trade-off still exists by choosing insulating glass, which still has a barely positive utility value. In fact, given the customer s system of preferences this choice would balance the negative impact of a greater financial effort with better performances in term of thermal and acoustic comfort. Figure 11 The utility distributions of the GLASS node after the selection of Mixed FACADE. Therefore the increase of the initial investment produced by the more expensive type of glass had potential benefits in two other design aspect. The evaluation of this alternative let the customer be well informed about the possible scenarios and to eventually modulate the budget distribution and/or its total amount. This is a very important point. In construction, the design complexity and the consequent difficulty to evaluate alternatives often hinder the possibility of thinking strategically and to optimize the investment to get to the original goals. Tools that make management of the complex relationships among needs, requirements and specification rise the perceived quality of the projects and in principle the overall design effectiveness. A model like the one discussed in this section has two main roles: first of all it rationalizes the customers requirement elicitation and relates them explicitly to the performance factor increasing the awareness of the investment and the perceived quality; secondly it makes easier to manage the overall complexity of the constructed model evaluating scenarios and driving decisions. As we have already mentioned the construction of requirement model is a critical part of the design itself and requires effort and should find a well established place in every project workplan. 5. Conclusions In conclusion in this paper we have discussed some relevant issues concerning the requirement analysis and their tracking in the construction process. We have pointed out the fragmented nature of the building design and of the construction processes as they involve many actors and competences, working in unique design and very often in changing environments. We have shown that requirement develops throughout the whole design course and that it is essentially a wicked process. Consequently in order to get high level of construction quality it is necessary to trace the requirement development in a very flexible way along all the design phases. Finally we have shown that the QFD conceptualization further enhanced with Bayesian Network technology can be the background for new software tool that allows for customer need and requirement tracking as well as for scenario analysis. 389
References [1] Akao, Y., ed. 1990, Quality Function Deployment, Productivity Press, Cambridge MA; [2] Bejder, E 1991, From client s brief to end use: the pursuit of quality in P S Barrett and A R Males (eds) Practice Management: new perspectives for the construction professional, E and F N Spon, London [3] Clausing, D., 1994, Total Quality Development, ASME Press, New York, NY; [4] Cooper, R and Kleinschmidt, E 1997, Winning businesses in new product development: the critical success factors, The Journal of Product Innovation Management Vol 14 No 2 pp 132 [5] Darlington, M and Culley, S 2004, A model of factors influencing the design requirement, Design Studies Vol 25 pp 329e350 [6] Day, R. G. 1993, Quality Function Deployment: Linking a Company with Its Customers, ASQC Quality Press, Milwaukee WI; [7] Dean, E. B. 1998, Quality Function Deployment from the Perspective of Competitive Advantage, http://akao.larc.nasa.gov/dfc/qfd.html; [8] DORST K. 2003, Understanding Design, 150 reflections on being Designer, Gingko Press, May, 2003 [9] Grady O. J. 2006, System Requirements Analysis, Academic Press, London. [10] Korb K.B., Nicholson A. E. 2003, Bayesian Artificial Intelligence, Chapman&Hall, London [11] Lockamy, A., Khurana A.,1995,. Quality Function Deployment: Total Quality Management for New Product Design, International Journal Quality and Reliability Management, Universal Press Ltd. UK. [12] Luck, R, Haenlein, H and Bright, K 2001, Project briefing for accessible design, Design Studies Vol 22 No 3 pp 297,315 [13] Male S. Kelly J. Gronqvist M. Graham D. 2007. Managing value as a management style for projects, International Journal of Project Management 25 Elsevier pg. 107 114 [14] Stichting B. 1993, The Client s Brief: more than a questionnaire in Proceedings of CIB W96 Architectural Management Workshop 15 16 April 1993, Eindhoven University of Technology. [15] RIBA 1967, Plan of work RIBA, London [16] RIBA 1995, Architect s Job Book, sixth edition RIBA Publications, London. [17] Terninko, J., 1996,. Quality Function Deployment (QFD), http://www.dnh.mv.net/ipusers/rm/qfd.htm. [18] Tzortzopoulos P, Cooper R, Chan P, Kagioglou,M 2006, Clients activities at the design front-end, Design Studies 27, 657e683 Elsevier [19] Young R. R.. 2004. The Requirements Engineering Handbook, ARTECH HOUSE, INC, Norwood, MA 390