WASTE: CAUSES AND ROOT CAUSES

Transcription

1 WASTE: CAUSES AND ROOT CAUSES A case study on the Customer Requirement Specification process of construction projects in the Netherlands Janiek Baarends Faculty of Technology, Policy and Management Delft University of Technology Delft, the Netherlands janiek_baarends@hotmail.com Abstract The Customer Requirement Specification (process) is a core part of Systems Engineering and often burdened with waste, but what are the (root) causes? In this paper, the results from a case study about the causes and root causes of waste in the Customer Requirement Specification process are presented and discussed. During two preliminary studies these (root) causes have been identified. A brainstorm session revealed five causes and an A3 Process method has been applied to identify its accompanying root causes and a case study was used to validate these (root) causes. During the case study different root causes were observed in contrast to the pre-assumed root causes. Inexperience and the lack of knowledge with regard to the process contributed to a large extent to the generation of waste during the project. This difference may be due to the fact that each project and its context are unique. This research provides an increased understanding of (root) causes for waste in the Customer Requirement Specification process. Keywords Systems Engineering, Customer Requirement Specification, causes, root causes, waste, case study I. INTRODUCTION Systems Engineering is regarded as a technically sound process for creating complex systems but is often burdened with waste and inefficiencies [9, pp.3)]. However, waste is present in all sorts of projects. It is evident that failed projects represent the most waste, but even successful projects suffer from lots of waste [9]. A study in the aerospace industry observed waste in 27 (different) aerospace projects that were executed using the Systems Engineering approach [11]. Said study [11] shows that the most contributing category of waste is waiting (is the time spend waiting), which is striking since the second most contributing category is over processing. This means that when one is waiting for some input to continue his/her job, another is over processing output, revealing that activities are not always planned properly. Another study illustrated the amount of waste produced by people (wasted effort) and waste produced by work packages (wasted time) [8] showing that 29% of all activities were required non-value adding (RNVA) activities and 40% nonvalue adding (NVA) activities. Above that, activity owners were idle during 62% of the time. This raises the next question: what are causes and root causes to such types of waste? In literature two reasons can be distinguished: 1) Most processes and procedures are not designed at all. In fact, they just happen [2]. Often, Systems Engineering is not incorporated into the planning as such; only particular Systems Engineering activities are planned for, but lack coherence. Often these ineffective ways-of-working emerge as a consequence of uncoordinated incremental change or the inability to take advantage of new design enablers. [7, pp.34)]; 2) [H]ow [Systems Engineering] processes should ideally work is rarely specified clearly [3, pp.249)]. When new processes are designed in general, there is no accessible documentation for employees in most cases [3]. It is argued that these poorly designed processes result in inefficiencies such as higher costs, wasted effort, and wasted time, with an increased potential for errors [3]. All together may lead to project failure. The Systems Engineering approach states that a project is a success if all (relevant) customers requirements are met within socially accepted costs. However, this objective is constrained by physical boundaries, standards, time, resources, and budget. From the Systems Engineering s perspective, customer is king. Therefore the Customer Requirement Specification, where customer demand is established by collecting needs, expectations, and wishes of all stakeholders with respect to the system to be realized, is a vital part of Systems Engineering. Up till now virtually no research has been done with regard to the Customer Requirement Specification process, but a large consultancy and engineering firm in the Netherlands indicated that they experience inefficiencies when they draw up Customer Requirement Specifications. In their opinion, the current Customer Requirement Specification process, as applied to the Dutch Civil Engineering sector and adduced by Rijkswaterstaat, shows to be inadequate to prevent, reduce, or eliminate waste [4]. Therefore, an interesting question to pose here is what causes inefficiencies or waste? Thus, the objective of this paper is to identify reasons for inefficiencies and/or waste and to check whether these actually occur in the 1

2 Customer Requirement Specification processes of construction projects in the Netherlands. In order to achieve this objective, two preliminary studies have been performed to identify causes and root causes, subsequently a case has been studied to validate these causes and root causes. The results are reported in this paper. The structure of this paper is as follows: section two presents the background of the case that has been studied and the Customer Requirement Specification process as applied to the drawbridge to be designed in the case. Section three describes the research methodology. Section four presents the results of this study. Section five gives an interpretation of the results and a discussion. Finally, section six concludes this paper by providing a conclusion and suggestions for future research. II. THE CASE All results of this research are based on empirical data from infrastructure projects at a large consultancy and engineering firm in the Netherlands. The company has over a thousand employees and offers consultancy and designs for water, infrastructure, spatial development, environment, and construction projects [13]. The case that has been analysed during this study was the renovation of a drawbridge in the Netherlands. This project is executed using Systems Engineering and uses an adapted approach as stated by the problem owner. This study focuses on a specific phase of said approach; the Customer Requirement Specification process. The Customer Requirement Specification process as applied to the renovation project consists of the following activities as depicted by figure 1: analysing the problem and defining project objectives (A1), performing a stakeholder analysis (A2), gathering and assessing customer requirements (A3), defining a validation strategy for those requirements (A4), drawing up a Customer Requirement Specification (A5), and validating this Customer Requirement Specification (A6). These activities are performed by the project team, which consists of different people: The project leader who leads, checks work done, and organizes meetings with the problem owner; Team members of the CRS who perform all activities as described in the preceding; Designers who design the new drawbridge. In detail, the activities consist of the following steps: A1. At the beginning of each project, the problem is defined first. Consequently, a problem definition document is drafted. When there is a clear understanding of the problem, project objectives are set, which subsequently are incorporated into a project plan. A2. The stakeholder analysis starts with identifying all stakeholders. Next, their interests, power, and resources are determined. Finally, a stakeholder overview is established. A3. First, the needs, requirements, and constraints are identified. After drawing up a preliminary list of customer requirements, these requirements are assessed based on usefulness (i.e. are the requirements clear and is it possible to assess them during a granting session?). If requirements are useful, they are assessed and the problem owner will be advised accordingly to either grant them or not (i.e. decided to incorporate a specific requirement of a stakeholder into the design). Ultimately, the problem owner decides whether to grant these requirements or not. A4. This activity consists of two steps: making agreements about how requirements will be validated and specifying those (agreed) validation steps. A5. The fifth activity is drafting the actual Customer Requirement Specification document. A6. Finally, the requirements from the Customer Requirement Specification are validated using the validation strategy as specified in A4. The validated customer requirements and how it is translated into system requirements are reported to the relevant stakeholder(s). If the stakeholder does not agree with the translation, requirements need to be reformulated and checked with the stakeholder yet again. III. RESEARCH METHODOLOGY The research was conducted using a three-phase research approach. During the first phase, the current situation is analysed within the company and a set of hypotheses have been derived that describe the causes for waste when using the Systems Engineering approach. In the second phase, hypotheses for root causes are identified for the causes defined in the previous phase. The third and final phase consists of a case study. The hypotheses are validated in this case study. Figure 2: Research methodology Figure 1: Customer Requirement Specification 2 process

3 A. Phase one identifying causes for waste A brainstorm session was used to identify waste in the Customer Requirement Specification process. Hypotheses are identified and presented below. This served as an input for phase three where these will be validated using a case study. The possible causes that were identified during the brainstorm session are the following: 1) The process of granting requirements (C1). During the process of granting requirements multiple people are needed to assess the requirements, time is lost because of mandatory steps in the process and accountability, requirements also go through the process multiple times when they cannot be assessed due to indecisiveness of the problem owner or the ambiguity of those requirements. 2) Irrelevant requirements are included in the Customer Requirement Specification (C2). During the Customer Requirement Specification process a lot of irrelevant requirements are included, which are those that are too detailed for a specific design phase, requirements that are outside the scope of the project, and those that are unrealistic. Including these types of requirements asks for a lot of extra work since they have to go trough the whole Customer Requirement Specification process as well. 3) Continuous inflow of requirements (C3). At the start of a project, a large amount of requirements come in, however during the project (i.e. when the new system is designed) and at the end of the project, the same amount of requirements come in. This asks for changes to the initial design (additional work and rework) and it jeopardises completing the project on schedule. 4) The Customer Requirements Specification is highly underestimated (C4). Often project teams delve into the design stage of a project right away, without considering the customer s needs and requirements. Underestimation can cause a lot of rework when the project team recognizes that the customer wanted something different. 5) There is a constant aim for SMART requirements (C5). Very often there is a tension between the design team and the problem owner with regard to the desired level of SMARTness of requirements. The problem owner rather does not have SMART requirements, so he retains room for negotiation. Designers prefer SMART requirements in the process since that makes it easier to design a system. Therefore requirements need to be reformulated over and over again. The top 5 causes for waste are based on how many people recognized it in their daily way-of-working and whether they thought it was impressionable. It should be noted that the problem owner does not necessarily recognize these causes for waste as well. Some contribute to creating stakeholder support and are therefore not considered waste by the problem owner. B. Phase two identifying possible root causes The A3 Process method was used to reveal root causes of the previous identified causes for waste. Most companies try to solve their problems in superficial ways, but do not solve the root causes. By not addressing these causes, the same problems will appear again and again. Based on the results from the A3 Process method, the hypothesis is that the five causes have the following root causes: 1) The process of granting requirements (C1) a) The company demarcates what should be documented, but the problem owner wants full accountability (RC1.1) b) The Customer Requirement Specification team and area management intermingle without having any agreements with respect to who will be preforming which tasks (RC1.2) c) There is a lack of managerial understanding by too many people (in particular area manager and problem owner) (RC1.3) 2) Irrelevant requirements are included in the Customer Requirement Specification (C2) a) The Customer Requirement Specification team talks with the wrong interlocutors to retrieve requirements (RC2.1) b) The Customer Requirement Specification team uses the wrong framing/ introduction of the problem when they talk to stakeholders (RC2.2) c) The strategic behaviour of stakeholders (sometimes stakeholders use the Customer Requirement Specification process as a means to accomplish other goals outside the project scope) (RC2.3) 3) Continuous inflow of requirements (C3) a) Project control: time and budget (RC3.1) b) Problem owner with changing insights with regard to the problem and accompanying requirements (RC3.2) c) The Customer Requirement Specification is never complete; changes keep coming (RC3.3) 4) The Customer Requirement Specification is underestimated (C4) a) Planning of the Customer Requirements Specification is imposed by the problem owner (RC4.1) b) Project team lacks the knowledge with respect to the Customer Requirement Specification (RC4.2) c) The focus is too introvert regarding the problem owner (RC4.3) 5) There is a constant aim for SMART requirements (C5) a) Area manager initiates the interview to retrieve requirements, but does not involve the technical manager, which results in too little time to match the required level of SMARTness (RC5.1) 3

4 b) Often the stakeholder s background is not fathomed when an interview is prepared (RC5.2) C. Phase three testing hypotheses using a case study Considering the preceding two phases, the causes and root causes are validated using a case study. During this study participant observation was applied. In order to keep track of the requirements and possible waste, a requirement monitor was developed (see figure 1 and 2). This monitor is able to identify patterns that indicate waste and categories of requirements that are wasteful, which can confirm the identified causes and root causes. IV. RESULTS The brainstorm session in phase one revealed that there could be five main causes for waste in a consultancy and engineering firm. The A3 Process method identified possible underlying root causes. While analysing the results, it was confirmed that 4 out of 5 causes were present. On the other hand, not a single root cause was confirmed, however some have been confirmed indirectly. Below the results are elaborated on. A. Confirmation of assumed causes for waste (C1-C5) All pre-assumed causes are addressed separately in this paragraph. C1: The process of granting requirements. This part of the Customer Requirement Specification process was new to all involved, even the project leader. This lack of knowledge resulted in a process of granting requirements that is not managed properly. The project leader lacks the knowledge and is not able to control the process. He suggested assessing the requirements based on three criteria instead of seven in order to save time, but problems arise when looking at criteria that were not considered. Since those are neglected, problems will become visible when they already started the design and rework will be unavoidable at that point. C2: Irrelevant requirements are included in the Customer Requirement Specification. In the preliminary Customer Requirement Specification, already eight requirements are included that are outside the scope of the project. This is almost 9%, which can be seen in figure 1. Since it takes at least two hours per requirement from the start of the process till the end [5], and when the project team does not eliminate these requirements, theoretically16 hours could be wasted. C3: Continuous inflow of requirements. This cause could not be identified during the case study. During the process, none of the stakeholders filed in their requirements. The team members of the Customer Requirement Specification had to retrieve the requirements actively. In fact the opposite of a continuous inflow of requirements had taken place. C4: The Customer Requirements Specification is highly underestimated. First of all the Customer Requirement Specification process is underestimated by the project leader. His top priority is to stay within budget and therefore he doesn't want to spend more on the CRS-process even though it might result in more efficiency and a (more) satisfied problem owner. In addition, they already started designing the drawbridge without considering any customer requirements. This might lead to a frustrated problem owner, who isn t satisfied. Rework seems inevitable if they continue without considering the customer requirements. C5: There is a constant aim for SMART requirements. When the team members of the CRS drafted a preliminary Customer Requirement Specification the project leader wanted to review the document. The project leader assessed all requirements and argued that 14 out of the 93 requirements were not SMART enough, which is 15% (see figure 2). This is a fairly large amount of rework since these requirements need to be reformulated and checked with the relevant stakeholder who brought it in. This observation is a confirmation of this cause for waste. B. Root causes to the causes as seen in the case study In order to provide a deeper understanding of the causes, employees and team members were asked to describe the accompanying root causes presented above. Based on these interviews, the assumed root causes could either be confirmed or rejected. Root causes of the process of granting requirements (C1) in case study: a) Lack of knowledge at both the problem owner as the contractor with regard to the process of granting requirements (RC6.1) b) Underestimation of added value of the process of granting requirements (RC6.2) Root causes of including irrelevant requirements (C2) in case study: a) The project team lacks the experience with respect to retrieving customer requirements and drawing those out (RC7.1) b) Scope of the project is unclear [6] (RC7.2) c) A large amount of the customer requirements is unclear and ambiguous, which could include irrelevant requirements [12] (RC7.3) Root causes of a continuous inflow of requirements (C3) in case study: Not applicable since this cause was not confirmed. Root causes of underestimating the Customer Requirement Specification process (C4) in case study: a) The design process is considered more important than the Customer Requirement Specification process [4] (RC8.1) b) Fundamental choices in the design are not based on the customer requirements [10] (RC8.2) 4

5 Root causes of aiming for SMART requirements (C5) in case study: a) The project leader is a Civil Engineer and prefers to have SMART requirements that can be easily translated into a design (RC9.1) b) Lack of experience of the project team with respect to retrieving customer requirements and drawing those out (RC9.2) V. INTERPRETATION AND DISCUSSION In this section, the achieved results are interpreted and discussed. Above that, the limitations of this research are discussed. In general, the Customer Requirement Specification process is considered to be a challenge to the case company. This research showed that the focus of the process is mainly from a technological point of view instead of a social point of view. It seems a challenge to unite the two points of view. When looking at the causes identified during the brainstorm session, four out of five causes were confirmed by the case study. Only the continuous inflow of requirements was not recognized. A. Interpretation and comparison of the results Now, the following question arises whether these causes have the same root causes as identified during the A3 Process method. When comparing the two lists, it can be seen that the root causes do not completely match for the process of granting requirements. However, the lack of managerial understanding may be interpreted as the lack of knowledge regarding the process. Either way, both result in a project leader who lacks control. When considering the root causes to including irrelevant requirements, it can be concluded that the different root causes do not match, however RC2.1 and RC2.2 can be a result of the lack of experience (RC7.1). Cause 3, the continuous inflow of requirements, was not recognized, thus no root causes could be compared. Looking at the root causes for cause 4, underestimation of the Customer Requirement Specification process, again no match is found, but the lack of knowledge with respect to the Customer Requirements Specification (RC4.2) might be the reason that the design process is considered more important (RC8.1) and that fundamental choices are not based on customer requirements (RC8.2). However, this is not confirmed. Lastly, the root causes for cause 5 are compared, but no match was found. Not even an indirect match. It can be concluded from the above that the identified root causes for the A3 Process method cannot be confirmed in practice. This may be due to the fact that the participants of the A3 Process method experience the waste and its causes in different ways. In addition, no project is the same and therefore root causes can differ from project to project. B. Discussion of the limitations As every research experiences limitations, this research did as well. These will be addressed in the remainder of this paragraph. During this study, a possible cause for unreliability is related to observer biases. It could happen that results from the brainstorm session and/or the A3 Process method have been unconsciously biased by the observer s knowledge with respect to the people, processes, and the experienced waste. This treat to validity was addressed using reviews. During these reviews the findings were discussed with the project director and other experts within the company. Another aspect was the possibility to generalize the results from the case study. Both internal and external generalizability should be kept in mind. Sampling participants from different parts of the company for the pre-studies ensured internal generalizability. The external validity may be questioned due to the fact that only one company was involved in the research. However, one can generalize from one case study [1] and the main focus of this research is not to provide a full theory on causes and root causes for waste in the Customer Requirements Specification process. In addition, it may not even be possible to replicate the results from this study because no project is the same. Despite these limitations, this research still contributes to the understanding of causes and root causes for waste in the Customer Requirements Specification process. VI. CONCLUSION AND FUTURE RESEARCH A. Conclusion The objective of this paper was to identify reasons for inefficiencies and/or waste and to check whether these actually occur in the Customer Requirement Specification processes of construction projects in the Netherlands. Therefore, this paper reports on a case study that tries to understand and validate the causes and root causes for waste in the Customer Requirements Specification process. The case study has been preceded by two pre-studies at the case company: a brainstorm session and an A3 Process method. The findings from these pre-studies were discussed and validated during a case study. The case study confirmed that the process of granting requirements is wasteful. In addition, one of its assumed root causes, the lack of managerial understanding, was validated as well. The case study also confirmed that irrelevant requirements were included. However, none of its root causes could be confirmed. During the case study, the Customer Requirement Specification process was also highly underestimated by the project team, but the underlying root causes could not be confirmed. The same goes for the fifth cause, the constant aim for SMART requirements; the cause itself was confirmed, but the root causes were not. The only cause that was not validated by the case study is a continuous inflow of requirements. Therefore, its root causes could not be confirmed as well. During the case study different root causes were observed in contrast to the pre-assumed root causes. Inexperience and 5

6 the lack of knowledge with regard to the process contributed to a large extent to the generation of waste during the project. These were the main root causes, but these did not match the pre-assumed ones. This may be due to the fact that each project and its context are different and unique. B. Future research Of course this is not the end of the research with respect to the topic, future research is needed. It should be investigated whether there could be more and/or different causes and root causes present. In addition, it could be very interesting to investigate how the different causes are interconnected. The same goes for the root causes. Future research also includes the search for methods and tools that could prevent, reduce, or completely eliminate the causes and root causes for waste in the Customer Requirements Specification process. ACKNOWLEDGEMENT I would like to thank all participants who participated in the brainstorm session and the A3 Process method for their contribution to this research. On top of that I would like to thank the project team for giving me the opportunity to validate the results from the pre-studies. This paper is part of a bigger research; a graduation project as part of the Master Systems Engineering, Policy Analysis and Management at the Delft University of Technology. REFERENCES [1] B. Flyvbjerg, 'Five Misunderstandings About Case-Study Research', Qualitative Inquiry, vol. 12, no. 2, pp , [2] M. Hammer, 'Reengineering work: don't automate, obliterate', Harvard business review, vol. 71, no. 6, pp , [3] C. Jimmerson, D. Weber and D. Sobek, 'Reducing waste and errors: piloting lean principles at Intermountain Healthcare', Joint Commission Journal on Quality and Patient Safety, vol. 31, no. 5, pp , [4] L. Kalwij and E. G. Molier, private communication, May 2015 [5] V. Kramer, private communication, May 2015 [6] M. Lagemaat, private communication, May 2015 [7] M. Laguna and J. Marklund, Business Process Modeling, Simulation and Design, Second Edition. Hoboken: CRC Press, [8] H.L. McManus, Product development value stream mapping manual, LAI Release Beta, Massachusetts Institute of Technology, Lean Advancement Initiative, Cambridge, MA, April [9] B. Oppenheim, Lean for systems engineering with lean enablers for systems engineering. Hoboken, N.J.: Wiley, [10] M. Pot, private communication, May 2015 [11] R. Slack, 'Slack, Application of Lean principles to the military aerospace product development process', M.S., Massachusetts Institute of Technology, [12] H. de Waardt, private communication, May 2015 [13] Witteveenbos.com, 'Mission and vision - Ingenieursbureau Witteveen+Bos', [Online]. Available: [Accessed: 13- May- 2015]. 6

7 Figure 3: Requirement Monitor Figure 4: Clarification waste categories requirement monitor 7