Opportunity discovery in initiated and emergent change requests

Abstract

When a change request is raised in an engineering project an ad hoc team often forms to manage the request. Prior research shows that practitioners often view engineering changes in a risk-averse manner. As a project progresses the cost of changes increases. Therefore, avoiding changes is reasonable. However, a risk-averse perspective fails to recognize that changes might harbor discoverable and exploitable opportunities. In this research, we investigated how practitioners of ad hoc teams used practices and praxes aimed at discovering and exploiting opportunities in engineering change requests. A single case study design was employed using change request records and practitioner interviews from an engineering project. 87 engineering change requests were analyzed with regards to change triggers, time-to-decision and rejection rate. In total, 25 opportunities were discovered and then 17 exploited. Three practices and six praxes were identified, used by practitioners to discover and exploit opportunities. Our findings emphasize the importance of the informal structure of ad hoc teams, to aid in opportunity discovery. The informal structure enables cross-hierarchal discussions and draws on the proven experience of the team members. Thus, this research guides project managers and presumptive ad hoc teams in turning engineering changes into successful opportunities.

1 Introduction

Changes occur in all areas of engineering projects, and their appropriate anticipation, detection, follow-up, and resolution is paramount to project success (Riley, Diller & Kerr 2005; Deubzer, Kreimeyer & Lindemann 2006). However, entirely avoiding change is impossible; as such, reactive treatment options must be explored (Wright 1997; Jarratt et al. 2011; Hamraz, Caldwell & Clarkson 2013). Emergent engineering changes can be described as a realization of risk, unexpected as well as anticipated. Conversely, an initiated change seeks to improve an existing design (Eckert, Clarkson, and Zanker 2004). For this category of changes an opportunity has already been discovered, and so opportunity exploitation is now needed. Moreover, an emergent change may harbor a positive risk (i.e., an opportunity). To that end, well-managed engineering change processes can act as the driver of continuous product improvement and increase the innovative performance of an organization (Acar, Benedetto-Neto & Wright 1998). In this, seizing opportunities is what is missing from risk-averse project management practice (Ward and Chapman 2003; Lechler, Edington & Gao 2012; Eskerod, Ang & Andersen 2018). In the context of engineering change management, companies have commonly viewed engineering changes as problems rather than a process that encompasses opportunities (Acar et al. 1998). With a risk-averse outlook on engineering changes, only the negative half of the possibility spectrum is being considered, what Krane, Johansen & Alstad (2014) call “the blind spot” of positive uncertainty.

When a change request is raised in a project, it is common that an ad hoc cross-functional team forms to handle the given change (Devine et al. 1999; Engwall and Svensson 2004; Ball and Lewis 2018). This formation is an informal temporal organizational structure that enables management of a particular change request; thus, the purpose of the team is ad hoc.

For small companies and startups, developed engineering change management tools are either too customized or too advanced (Becerril et al. 2017). In those situations, the strategic and organizational aspects of engineering change management are highly relevant and might represent the first hurdle for an organization in implementing a structured engineering change process (Becerril et al. 2017). Likewise, the project of this case study was executed by a new project organization, within a new business unit to tackle a new market. In the context of engineering change management, a critique is that the research field has focused more on how things ought to be rather than how they are (Wickel et al. 2015; Becerril et al. 2017). In this, Acar et al. (1998) found that companies see potential in engineering changes as a carrier of opportunity. However, few companies actively seek opportunities associated with engineering changes based on established methods or tools (Acar et al. 1998). Although the topic is highly relevant in flipping the situation on risk, Acar et al. (1998) study was a survey with its inherent limitations. The key question remains of “how” opportunity is seized in a reactive practice of handling engineering changes. To that end, the purpose of this paper is to explore the practices of ad hoc teams, the team members they are composed of and how opportunity discovery is connected to the practices and praxes of the project, by posing the research question:

How do ad hoc teams discover and exploit opportunities associated with emergent and initiated change requests?

This research extends the focus on opportunities in engineering changes, a topic recently identified by a review in the field of engineering change management as a research opportunity of its own (Ullah, Tang & Yin 2016). Furthermore, this research consolidates the findings from engineering change management (e.g., Hamraz et al. (2013)) with principles that are less digital and more skill based project management practices (e.g., Hällgren and Maaninen-Olsson 2005, Munthe et al. 2014) and project management change practices (e.g., Dvir and Lechler 2004) in the engineering practitioner environment of ad hoc teams (e.g., Hällgren and Maaninen-Olsson 2009).

2 Theoretical background

In essence, the treatment of a change request with design consequences is based on a small design loop, that follows the generic engineering change management process proposed by Jarratt, Clarkson & Eckert (2005). Engineering change management has been well documented since Wright (1997) published a literature review of the field. The associated evolution as a research field can be studied through the more recent and extensive reviews of Ahmad, Wynn & Clarkson (2011), Hamraz et al. (2013) and Ullah et al. (2016).

For engineering changes, as opposed to an original design, the design obstacles are largely known compared to when the design was first conceived (Hutanu et al. 2016). Conversely, the implementation of the redesign is limited and often requires the removal of some part of the previous physical design (Pena-Mora and Park 2001). Perhaps most daunting is the propagation of a change in a design following an engineering change (Jarratt et al. 2005).

2.1 Opportunities in initiated versus emergent engineering changes

Opportunity management is part of the broader field of uncertainty management and involves the exploration of opportunities as part of the risk assessment process (c.f. Ward and Chapman 2003; Olsson 2007; Krane et al. 2014). In this research, the definition of an opportunity by Krane et al. (2014, p. 617) is used: “opportunities are factors, variations, and events that may lead to changes that make the project able to deliver the same quality in less time or to lower price than was agreed upon in the beginning of the project.” However, in the product-development domain, Ulrich and Eppinger (2012, p. 34) define opportunity differently as “an opportunity is an idea for a new product”, “A hypothesis about how value might be created.” And “A product description in embryonic form, a newly sensed need, a newly discovered technology, or a rough match between a need and a possible solution.”

In engineering projects, change requests are a way of both controlling project content and record changes made to the contract (Hao et al. 2008). In the studied project, change requests, in general, stemmed from deviations from the contract. This research views engineering changes (at the change request scale) as a subcategory of deviations where Hällgren and Söderholm (2010, p. 352) define deviations as “…unexpected events that require attention from the project team because they interfere with cost, time or scope goals; this is the so-called ‘iron-triangle’.” In this definition, the design, organizational, regulatory and purely contractual aspects can all both trigger and be affected by a change request. In our analysis, we limit ourselves to change requests that had a design consequence, even though the trigger might have been stemmed from another aspect of the project.

As opportunity detection in engineering changes is concerned, Acar et al. (1998) conducted a survey study of opportunities in engineering changes into 24 engineering companies. Sadly they found that a majority of them treated their engineering changes as a necessary evil. However, seven companies indicated that their engineering change management contributed to their innovative performance. Those companies, also adopted cross-functional teams, to a high degree (Acar et al. 1998). Furthermore, Hutanu et al. (2016), suggest that change request opportunity be evaluated based on cost, risk, divided by market significance, where the latter two are evaluated in a system similar to a failure modes and effects analysis (FMEA). However, this approach has not been shown in practice and as discussed in the introduction, it focuses on how opportunity ought to be handled not how it is handled.

Changes requests often represent materialized unknown unknowns, and it is, therefore, possible that they represent opportunities that can be discovered and exploited. Also, known unknowns (discovered risks) might materialize as engineering changes. Furthermore, a third alternative is the emergence of a change following an unknown known (i.e., something that could have been known based on additional investigation) (Kim 2012). Initiated changes often have an optional property, whereas emergent changes are responses to acute deficiencies in the design (Eckert et al. 2004). In an initiated change, a potential opportunity has already been discovered; therefore, a change request is issued (Figure 1). However, emergent changes are directly related to a discovered weakness in the design (Eckert et al. 2004). Despite their differences, initiated changes and emergent changes are handled by the same process (Eckert et al. 2004). Other engineering change categorizations have been proposed, e.g., optional vs mandatory (Deubzer et al. 2006).

In conclusion, unknown unknowns, known unknowns, and unknown knowns can all spawn engineering changes, and opportunity can be discovered in those changes. However, unless a discovered opportunity is exploited, there can be no significant increase in project value (Lechler et al. 2012). Regarding practitioner practices, opportunity discovery (Hutanu et al. 2016) can be considered a subset of effective change practices (Fricke et al. 2000). This practice of discovering and exploiting opportunities associated with initiated changes has received little attention despite its potential to raise the innovative performance of organizations (Acar et al. 1998).

Figure 1. Our understanding of how change sources lead to exploited opportunities.

2.2 Strategic and organizational issues in engineering change management

Due to the temporary nature and the interconnectedness of projects their processes and procedures commonly breakdown in the practice of handling changes (Hällgren and Maaninen-Olsson 2009). To hinder breakdown, engineering change management has become an increasingly important tool in controlling the project scope (Jarratt et al. 2005; Tavvčar and Duhovnik 2005). Despite this need for active approaches, the research field has largely focused on proactive rather than reactive approaches in handling engineering change (Huang and Mak 1999).

The engineering change research that actually has investigated reactive measures have found conflicting results. Deubzer et al. (2006) investigated the strategies employed by 50 companies in the manufacturing industry in handling engineering design changes. They found that the most promising future strategy of the surveyed companies was “increased synchronization of employees and teams,” while the “use of checklists and methods” received the least praise. This finding is, in part, contradictory to what Langer et al. (2012) found: that both “human errors in process execution” and “inadequate processes, methods, and tool support” were the most common causes in faulty handling of engineering changes. The strategy of increased employee synchronization is in line with the learning strategy by Fricke et al. (2000) that, among other things, proposes using previous engineering change data to build a “lessons learned” knowledge database of strategies. These findings all sprung from surveys, not case studies, something that Ahmad et al. (2011) have wished for more of in this field. This study contributes to that cause through a case study of change requests in an engineering project.

2.2.1 The formation of ad hoc teams

The activity of resolving emergent change requests is sometimes referred to as “firefighting” (Engwall and Svensson 2004; Hällgren and Wilson 2008; Eckert et al. 2017) or “troubleshooting” (Pinto and Covin 1989). In this, practitioners are the agents of practice and praxis. The formation of ad hoc teams is relevant because the process allows the management of engineering changes across organizational levels (Sjögren et al. 2018). The ad hoc team plans and implements the change according to the new requirements that provoked the change (Engwall and Svensson 2004). However, in engineering projects, given their custom nature, formal processes are seldom advanced or even available; thus, ad hoc team members must improvise ways of solving encountered change problems (Hällgren and Wilson 2008).

Eckert et al. (2004) categorized change-handling processes into formal and informal change processes. Formal processes are established working methods (e.g., traditional process management and meetings). Informal handling refers to undocumented communication and tacit routines. Furthermore, Acar et al. (1998) linked sound engineering change strategies to the formal deployment and development of cross-functional teams. Cross-functional teams have been studied in the realm of engineering changes in the past where traditional forms of project management with a hierarchical and centralized form of management are unable to take advantage of the dynamic and agile ability of autonomous engineering teams (Lindemann, Kleedörfer & Gerst 1998).

Ad hoc teams in projects are “loosely coupled” (Eriksson and Brannemo 2011) with regular project teams, and team members are often but not always parts of regular teams (Engwall and Svensson 2004). The ad hoc team usually consists of engineers, planners, project managers and on-site personnel from the project in what Hällgren and Wilson (2008) call a “dual structure” involving engineering versus on-site personnel. The organization of a project in a dual structure is an efficient way of increasing communication pathways in projects without increasing bureaucracy (Hällgren and Maaninen-Olsson 2009). The dual structure is common in engineering projects but also relevant to other project forms, e.g., development projects where a development team might progressively hand over their work to a sales, testing or project execution team, working in parallel. Furthermore, Hällgren (2009) studied the praxes of deviation handling in projects using a case study and identified 29 praxes amounting to eight practice patterns; specifically, interpret the goal in an advantageous way is similar to the discovery and exploitation of opportunities. However, to our knowledge, ad hoc teams practice and praxes of resolving engineering changes has yet to have been studied as a phenomena in its own right.

3 Method

This research applies a single case study design with an inductive and explorative approach, combining qualitative data and quantitative content analysis. The interview results, as well as change request information, were analyzed from a projects-as-practice perspective. Practitioner interviews were conducted with 16 interviewees over the course of three years. Additionally, data was collected from the project database and coupled email correspondences, contract documents and meeting minutes. The interviews are critical in answering how (Kvale and Brinkmann 2009), and the quantified change request data can supplement these findings regarding what/which (Schreier 2012).

Full access was granted to all documentation and systems discussed in this article for the duration of the study, which spanned from December 2013 to December 2017. The first author (employed by the case company) acted as an observer of the project and responsible for the general data analysis. The second author was the project manager for the offshore converter platform and aided in interviews as well as supporting the conceptualization and conveying contacts within the project. The third and fourth authors collaborated on the conceptualization of the research project, data analysis and writing process.

3.1 Case description

To study how opportunities are discovered and exploited in change requests, we selected an engineering project at a multinational company in the power and automation industry. Engineering projects, as opposed to e.g., product-development projects, often have the following characteristics (Pinto and Covin 1989):

• ∙ They treat the realization and construction of more significant, often one-off, engineering-to-order-type products (e.g., plants, heavy transport kinds, infrastructural).

• ∙ Their content is mainly physical in delivery and is traditionally managed by EPC contractors (engineering, procurements, and commissioning).

• ∙ They require many subsuppliers and their coordination to reach completion.

• ∙ They usually answer to an order placed by an immediate customer in a business-to-business industry relationship. The business-to-business contracts associated with engineering projects leads to challenging deadlines due to fines that can, contractually, be imposed by the customer.

The project involved the EPC activities of building an offshore platform for high voltage direct current conversion from offshore wind farms to be supplied via sea cables to shore. The project’s fabrication phase was initiated in 2010 and handed over to the customer in 2015. At its peak, the project involved over 500 individuals working for the customer, case company, and involved subsuppliers.

The studied department, from which practitioners were interviewed, acted as the project management organization for the case company and was responsible for the project delivery to the customer. The department was also responsible for quality control toward of the offshore converter platform designer and fabricator (both subsuppliers). The case company in general was responsible for system engineering, including the design, supply, and installation of the offshore converter, as well as the platform, sea- and land-cable systems and onshore converter station. For the studied project, the company entered a new technological field (offshore wind converter platforms), managed by a recently established organizational branch. In this, few formal processes had yet to been established. This makes the current project selection viable study site for change requests and their management.

3.2 Methodology: projects-as-practice approach

The projects-as-practice approach to research in the project management field argues that contemporary management research has difficulties in making sense of current management practices and produces irrelevant research that cannot guide actual management practices (Blomquist et al. 2010). The projects-as-practice method aims to evaluate work that is performed and determine why it was performed in a given manner. Projects-as-practice research focuses on what people do in projects (praxis) rather than on the confirmation of best practice models of project management (Blomquist et al. 2010). According to Blomquist et al. (2010), praxis is defined as the actions taken by a project practitioner, e.g., a project manager, when he or she performs budgeting or other tasks, whereas practices are the norms, traditions, and rules that guide the practitioners. Praxis is the work performed to “get the job done,” and practice is what governs praxis. Moreover, practices are built from praxes (Hällgren and Söderholm 2011). In a projects-as-practice approach, the questions posed are generally suitably answered by focused qualitative datasets (Blomquist et al. 2010). In this context, the ad hoc team practices, or subordinate praxes, are the unit of analysis (Yin 2011).

3.3 Qualitative data collection and analysis

In total, 30 interviews (with 16 interviewees) were conducted in three rounds over the course of three years, with roughly ten interviews each year (see Table 1). All interviews were semistructured and performed by the guidelines proposed by Kvale and Brinkmann (2009). In general, each interview opened with a research introduction, which was followed by open-ended questions. Mid-interview, a discussion was initiated about project-specific documents and processes to achieve a shared understanding of the material. Interviews lasted between 45 and 70 minutes. Interviews were recorded, transcribed (or annotated) and sent back to interviewees for comments.

The 1st round of interviews (see Table 1) presented interviewees with questions on the early phases of design and how requirements of fabrication were considered in these early design stages. Some questions pounced on experience with subsequent rework following early designs, how information within project phases (i.e., early design, engineering, and fabrication) overlapping to the next was performed. The 2nd round of interviews revolved around the process of managing change requests as the interviewees perceived it, questions focused on hierarchies, phases, documentation and planning of change request implementation as well as formal and informal practices used to control changes. The 3rd and final interview round focused on the practitioner’s perceptions of the generation of solutions and the basis of decisions for individual change requests.

The interview transcriptions where analyzed based on deductive codes that were supplemented with in vivo codes in the processes of analysis. Building themes and cross-referencing between fragmented data. Interviews were analyzed based on the methods described by Miles, Huberman & Saldana (2013): to identify units of meaning relevant to research questions and annotated by coding. In this, coded transcripts were used to search for commonalities between interviews. For this task, separate spreadsheets were used so that coded data could be captured for similar phenomena and themes. Discarding “loose ends” and aggregating keywords into themes and ideas. The encountered phenomena were categorized into practices and praxes of opportunity discovery. Last, the fragmented data were revisited to enrich the ideas if observations had been lost early in the process.

Table 1. Number of interviews and interviewee roles.

In the table, “○” indicates engineering (in-house) and “●” indicates the on-site roles of the interviewees, related to the dual structure.

3.4 Quantitative data collection and analysis

In all, 207 change requests were collected from the project management database. Change requests in the context of the studied project were not only concerned with engineering changes to the design requirements but also with other categories of changes. Those changes were often project-specific, concerned with scheduling, organizational or contractual issues not impacting design. 118 change requests of this kind were identified, and omitted from further analysis. Another two requests (with actual design impacts) were omitted due to inadequate documentation. In total, 87 change requests with design impact were analyzed raised from December 2010 through July 2014 (Figure 2). Based on the analyzed change requests, it was not possible to quantify the total number of changed components of subsystems that were explicitly and implicitly affected for each change request. In addition to change requests, engineering changes were also treated individually in the project by engineers. Those engineering changes, in the form of design reviews and drawing revisions, were handled on a day-to-day basis, at a lower hierarchical level from the product domain perspective (Figure 2).

Figure 2. Deriving the unit of analysis, i.e., change requests with a design consequence (area affected).

The analyzed change requests for the project were searched to identify opportunities both discovered and exploited according to Krane et al.’s (2014) definition in the theoretical background section. To be detected and reported as an opportunity (discovered and exploited), the request had to explicitly state an opportunity or be implicitly detectable to be included in the analysis. All the initiated changes assume that an opportunity has been discovered but is only considered exploited if the request is accepted. For emergent changes, both discovery and exploitation must be identified in the data. If analyzed change requests contained ambiguous or incomplete information, accompanying documentation and interviewee follow-up briefings were used for further investigation in multiple data point validation.

4 Findings: opportunity discovery and exploitation

The findings are presented in three sections. First, the observed change request process is described together with the change request template used by the case company. Second, the quantitative portion of the collected data is analyzed and presented to compare the differences between initiated and emergent requests. Third, the identified practices and praxes of opportunity discovery and exploitation are described in relation to the generic engineering change management process.

4.1 Change request process and structure of the case company

In the project, several ways of issuing change requests were available. In this article, we treat change requests as issues raised by the customer to the company to alter the product after the engineering phase was completed. In the studied project, the company could also issue change requests to its subsuppliers; this was often done as a consequence of a change order from the customer or due to independent sources of engineering changes emanating from the company itself. Change requests could be issued from any project phase to any other project phase (past, present, and future). Changes were also hierarchically differentiated regarding magnitude. Change requests, as studied in this research, affect the product at the system or subsystem level and across system boundaries (Figure 2).

Change requests could be raised by the company and directed at the customer to establish a change and request payment for the intended change. However, either the company or the customer could initiate the change. When the customer initiated a request, the change was documented in the form of a change request by the company on behalf of the customer.

The change request document that was used in the project followed the structure presented in Table 2. As with the provided example, in none of the analyzed change requests, had the individual raising the request provided an indication of a shift in overall project risk, even though the question was open and could be interpreted either as a shift toward an opportunity or a negative risk.

Table 2. Change request template structure and example request with [author’s notes] and redaction to sensitive information.

4.2 Change request analysis

Of the 87 analyzed change requests, 66 were emergent changes, and 21 were initiated. The rejection rate of the initiated changes was 38%, and the corresponding rejection rate for the emergent changes was 15%. Initiated changes, to a large extent, focused more on added functionality or components (add: 29% / change: 71%), as opposed to changing existing designs, than did emergent changes (18% / 82%). Thirteen opportunities associated with initiated changes were exploited, i.e., not rejected. Thus, eight initiated changes were rejected (i.e., not exploited).

For emergent changes, each opportunity that was discovered in change requests was exploited. However, this was only the case in four of the emergent changes that were identified from the analyzed change requests. These cases are described as part of the presentation of recognized practices and praxes in Section 4.3.

Change trigger categories were identified as design, project, contract, regulatory and unknown. A design trigger could be a change in the dimensions of cables due to issues with fittings, for example. Project changes typically regarded issues with the scheduling of personnel. Contract issues dealt with apparent deviations from the project contract between the case company and the customer. A regulatory trigger was often associated with new or existing and previously ignored regulations. Finally, unknown triggers involved requests for which the trigger could not be established based on the collected data.

Four of the 21 initiated changes were triggered by contractual questions, and the remaining 17 were raised based on the design. The corresponding numbers of emergent changes included 4 for unknown reasons, 44 that was design-driven, 3 that were project-driven, 9 for regulatory reasons and 6 due to issues with the contract (Table 3).

Table 3. Initiated versus emergent changes and their characteristics

Figure 3. Duration from when a change was raised to when a decision was reached for emergent and initiated changes.

The mean and median resolution times from when a change was raised to when a decision was reached for initiated changes were 154 and 104 days, respectively, and the corresponding resolution times for emergent changes were 170 and 96.5 days (Figure 3).

4.3 Practices and praxes of opportunity discovery and exploitation

The practices and praxis that were identified as used by practitioners are used to discover and exploit opportunities given a raised change request. Detailed explanation of each identified practice and praxis is provided in Table 4. The identified practices and praxes do not present a complete account of possible practices and praxes. Nor are the practices and praxes exclusive in discovering opportunities. They have, however, been associated with the discovery and exploitation of opportunities in the analyzed data. Based on a generic engineering change process, praxes and practices were identified from change request (previous chapter) and interview analyses. Following the logic of the generic engineering change process, the first three stages involved opportunity discovery associated with praxes and practices, and the latter three stages involved exploitation (Figure 4).

Figure 4. Identified praxes and practices of opportunity discovery and exploitation in a generic engineering change management process, adapted from Jarratt et al. (2005).

The second and third stages of the generic engineering change management process were almost exclusively treated as a tight-looping back and forth system, to the point where the stages were difficult to distinguish. Therefore, in Figure 3, the practices and praxes are described in the same bracket.

Aside from the process-based aspects of the practices and praxes, the hierarchal structure of the project was a formal barrier to most ad hoc teams in their pursuit of discovering opportunities. The steering committee (STECO) of the project was a mix of managerial roles (e.g., project director, selected line managers and representatives from customer and subsuppliers). The project manager coordinated the project with stakeholders with several part project managers reporting to her on individual work packages. The change resolution focused on the person informally responsible for the change request. The same person often had the most knowledge of the topic and was the informal leader of the ad hoc team. Thus, the ad hoc team might bypass certain hierarchal levels (Figure 5) in their discovery process. To be able to draw on as much proven experience and information as possible, ad hoc teams often crossed hierarchal project boundaries.

Figure 5. Ad hoc team formation based on formal project hierarchy.

A well-established product lifecycle management system that can be used across project disciplines is an essential tool for information retrieval. A chaotic system will reduce the transparency and understanding of the system knowledge in the praxis of revisiting. Additionally, such a system could hinder the communication between the on-site and engineering counterparts (dual structure) of the ad hoc team. In this case, the on-site part of an ad hoc team conveyed the on-site conditions to their engineer counterparts.

The following section presents the recognized practices and praxes and provides examples of their use. Representative quotes from interviewees are included below (Table 4).

Table 4. Description of identified practices and praxis with representative quotes.

5 Discussion

This section discusses this article’s contents from three perspectives, the quantification of change requests, the qualitative analysis of practices and praxes as well as the methodological approach.

5.1 Quantification of change requests

As observed by Deubzer et al. (2006) the ratios of optional and mandatory changes, in their studied project, were 23% to 77%, respectively. This finding can be compared to the ratios observed for initiated and emergent changes in this paper (24% and 76%). However, Sjögren et al. (2018), showed a ratio of 45% to 55% for emergent changes and initiated changes respectively, in that case, they studied a new project-development project which ought to have an impact on this ratio. Additionally, there was a tangent, in the studied project, in which the longer the project progressed, the fewer initiated changes were raised, and more emergent changes occur. Specifically, 86% of initiated changes were raised in the first two years of projects compared to 67% of emergent changes (Figure 3). By this logic, ad hoc teams must strive to discover opportunities rather than focusing on resolving obvious technical toward the end of a project. On the other hand, returning to the new product-development study of Sjögren et al. (2018), the relationship was the reverse, more initiated changes were raised later in the project than emergent changes. Furthermore, the higher rejection rate for initiated changes could be because “wants” have low priority during project execution compared to “musts.” Unless opportunities were sought with those emergent changes in the late project and product phases, no value maximization, as discussed by Lechler et al. (2012) and Eskerod et al. (2018), could be achieved. However, as this article argues that one should investigate the inherent opportunities of emergent changes, the mindset of practitioners seems focused on the perception of emergent changes as a distraction. The following quote from an interviewee addresses this concept.

“Changing a design after it has been fabricated or installed is like pulling a wisdom tooth out from ‘behind’ rather than through the mouth. There is just a lot more stuff in the way.” – Interviewee 14(15A)

Furthermore, we argue that the majority of encountered changes are emergent. However, from the perspective of the customer, these changes may be regarded as initiated, i.e., an improvement, but to the company, and the change is then emergent as defined by Eckert et al. (2004).

5.2 Qualitative analysis of practices and praxes

The best remedy to a risk-averse mindset is to broaden the issue, investigate alternatives and be proactive (Hammond, Keeney & Raiffa 2015). Sadly, as observed in this study, alternatives were generally not assessed in association with change requests. Nor did it seem to be a demand, that the raiser of the request provide alternatives. Peterman (2011) suggested that documentation and recorded communication are often avoided in the name of efficiency and at the cost of effective practice. Without transparency in this respect, this reduces the possibility of making an informed management decision making it impossible to determine to what extent alternative avenues were evaluated or opportunities sought (Peterman 2011). Nevertheless, in a few instances, alternative solutions were discussed in the analyzed change requests and by the interviewees, but it remains a practice that is rare among practitioners: As Eckert, Pulm & Jarratt (2003, p.8) noted “some companies very carefully think through all the implications of a change using their best engineers. While they can come up with accurate estimates, this is rarely done for more than one change alternative.”

Similarly, Sjögren et al. (2018) found that as ad hoc teams work to resolve a change request they often work on one-solution alternative in an iterative way going back and forth between second and third stages of Jarratt et al.’s (2005) generic engineering change process. In Figure 4, as an adaptation of the generic engineering change process of Jarratt et al. (2011), the second and third stages in the process are indicated in an iterative loop. In our representation, however, the loop is indicated as tightly linking the two steps. In practice, the observed process behavior suggests that these steps are not organized in a stepwise fashion; instead, there is continuous assessment and identification of novel solutions at the same time. The praxes and practices in these phases (proven experience, ad hoc meetings, revisiting and floating) all contain elements of assessment and novel solution identification.

Furthermore, change propagation analysis typically occurs after a solution is reached, as this stage is downstream of the conceptualization phase (Figure 4). Change propagation tools and techniques can be helpful but only if the corresponding solution analysis is sound. Having several options to choose from can only be ensured through a thorough ideation phase. When the risk assessment stage is initiated, ideas and minds become narrowed and focused (Brown 2008). In the survey study of Huang and Mak (1999), over 70% of responding companies identified “overcoming the natural tendency of quick decisions” as a positive key to good engineering change practices. This one-solution, “horse blinders” strategy is a type of firefighting (Eckert et al. 2003) and the opposite of the observed floating praxis. Floating, as defined in our study, is a praxis similar to brainstorming in which the suspension of evaluations is critical to avoiding interruptions (Yilmaz et al. 2015). However, floating represents a longer period than brainstorming, that is often practiced as an event. Furthermore, the identified practice of holding ad hoc meetings and praxis of proven experience ought to mitigate decision resistance (Fricke et al. 2000) as reflective practices in a group setting with competent personnel and promote a transparent process.

The practice of holding ad hoc meetings is common in project settings and is supported as a sound practice if appropriately performed (Hällgren 2009). However, as Hällgren and Maaninen-Olsson (2005) argued, the structure is often missing from group reflections. In this case, entering an ad hoc meeting with a structure, similar to that of the change request template (see Section 4.1), with an indication that opportunity might be associated with the problem, could spark another type of discussion. The change request template seldom included an explanation as to why a change request had been raised (i.e., the root cause). Questions of why are needed to promote experiential learning in future projects related to future projects (Wickel and Lindemann 2014). Furthermore, none of the analyzed change requests indicated a: “shift in risk of the overall project” (Change request template, tabler 2). As this cannot be true, this issue reflects the lack of propagation analysis in the engineering change process. A potential improvement, in this case, would be to emphasize this phase in future projects to discover more opportunities.

Like the initiated changes that were exploited, rejected changes revealed potential in increasing the quality of the end product, e.g., by increasing system reliability, adding functionality or facilitating operability. There were, however, two general differences. The initiated changes that were accepted (i.e., opportunities exploited) were either a definite win–win solution on behalf of the company and the customer or they improved the system safety, which is a quality highly prioritized in projects of this nature. There was little additional work required in win–win initiated changes (rejected initiated changes were present in the project, they often did require additional work or an unacceptable negative risk). Win–win solutions, as success factors, have previously been observed in manufacturing companies regarding their subsuppliers (Gilgeous and Gilgeous 1999). This research expands this practice involving projects and engineering changes. If a “win” solution was observed by a company, a way of easing acceptance is to discover an additional “win” opportunity in the interest of the customer.

Assessing the problem from a broad view is required to discover opportunity, i.e., broadening the issue. The use of proven experience was observed in many of the interviews of the studied project, including from the company project manager and the project management organization of the customer, who often observed synergistic effects in dealing with changes. However, specialist knowledge and skills attributed to engineering practitioners, in this case, are often based on proven experience in the evaluation of a solution. Surveyed companies have previously correlated the aptitude of individuals with proper management of engineering changes (Huang and Mak 1999). Furthermore, proven experience, as a concept to describe non-empirical knowledge, is taken from medicine, as it is used by medical practitioners (Persson et al. 2017).

Design conditions, this approach can be encouraged by having direct ways of communication between engineers and on-site teams, i.e., a dual structure. The dual structure poses problems in cooperation for apparent reasons. Notably, on-site personnel and engineers that are office-bound often have different training and education levels and, therefore, different professional language. Moreover, they perceive and prioritize projects differently. However, the analysis showed that in several instances, there was considerable potential in discovering opportunities that presented themselves on site. In the studied project, the on-site personnel and installation equipment were so costly that opportunity could often be captured in the joint usage and utilization of these resources, knowledge of which only the on-site team could provide.

Retroactive requests were not regarded as an exploited opportunity in the change request analysis; however, among the emergent changes, this practice was noted in 11 of the 66 studied emergent change requests. Nonetheless, this practice has two benefits. The request, if approved, is a documented decision of a preexisting change. Second, the request is used to demand payment for additional services outside the contract. None of the retroactive requests was rejected. A review of the change requests alone yielded a typical sense of consensus and a mutual understanding that fixed designs, according to contract or not, are difficult to change; thus, the customer often accepted the associated change requests.

5.3 Methodological approach

Opportunity discovery and exploitation may be informal processes of engineering change management that: “make ‘poor’ processes produce ‘good’ designs” (Papalambros (2015), p. 14). In some analyzed instances, the opportunity was discovered given the change request. However, in other cases, the change request could have been avoided with better practices upstream. This begs the question: was an opportunity exploited, or was there a return to baseline? In general and as stated in the introduction of Section 4.3 all the identified practices and praxes are not exhaustive nor do they aim solely at discovering and exploiting opportunities. Rather these are the practices and praxes that has been found to be used in the cases where opportunities have been discovered and exploited. Due to the inherent limitations of this study, we cannot answer these questions from the given perspective.

As with all single case studies, the common critique of replication logic is warranted. However, as Flyvbjerg (2006) noted, the replication of results is not a promise in case study research. Preferably, tests of validity should be used to ensure a transparent scientific approach in developing knowledge. As humans, we learn based on experience. That experience is an aggregate of the cases we encounter. Thus, case studies might not always be appropriate for generalizations, but they serve as building blocks of larger empirical datasets and experiential learning. In the project management research focused on the projects-as-practice approach, such situated, case-specific details are of the most interest (Hällgren and Söderholm 2011).

Last, this research has utilized the projects-as-practice approach. Unfortunately, this research mixed a purely projects-as-practice approach with a more traditional process view of projects. The focus should be less on formal processes and more on the actual day-to-day activities performed (Hällgren and Söderholm 2011). In this research, we used the generic engineering change process from Jarratt et al. (2011) as a framework to describe the identified practices and praxes. Moreover, the way this study was structured did not allow for an effects analysis of each identified practices or praxis, rather the results rest on inductive reasoning. Thus, the authors humbly acknowledge these shortcomings regard this as a lesson learned for future research projects.

6 Conclusions

As argued in the introduction, an engineering change process can be regarded as a miniature design loop. Therefore, some results can be applied to the design process in general. The scientific community concerned with engineering change management was provided a case study example, herein, of how aggregate engineering changes in the form of change requests are handled in an engineering project. The results also show how practice and praxis influence the engineering change management process and that they should be regarded when developing processes, software, and guidelines. Moreover, this research contributes to the understanding of ad hoc teams discussed by Engwall and Svensson (2004) and Hällgren and Wilson (2008).

Like Ward and Chapman (2003); Olsson (2007); Krane et al. (2014) as well as Sjögren et al. (2018), this research shows that opportunities are not discovered as frequently as negative consequences. This similarity is encouraging, as it can be used to improve and refine management. Although it cannot be proven in this study, there are speculative explanations as to why opportunities are not prevalent, human’s tendency to focus attention on the negative being one.

The main takeaway from this article for practitioners is that structured collective reflection regarding root causes, solution alternatives and implementation plan review, both with others and through proven experience, can aid in the discovery of opportunities. Many of the suggested enablers of opportunity discovery stem from a structured and methodological approach to problems. However, other enablers are tied to the innate abilities of the ad hoc teams that can be established through a common-sense approach and later honed by project members, i.e., assuring that the ad hoc member with the most relevant proven experience reviews the change implementation plan. Finally, awareness regarding opportunity discovery and exploitation, as is part of practitioner praxis and practice, can be improved through workshops via structured collective reflection. A workshop of this type would typically consider the current practices and praxes setting future direction based on practitioner feedback – an opportunity for future research. Ultimately, the end user/customer would stand to benefit from emphasizing opportunity discovery and exploitation by practitioners considering engineering changes. More directly, practitioners would experience more satisfaction in their work through increased awareness of the opportunities that lie in engineering changes.

6.1 Further research

This research has identified practices and praxes of opportunity discovery and exploitation in projects. Because this study likely overlooked issues related to engineering change processes, tools, and systems, we welcome further research in this area. Future research should focus on how to encompass these practices and praxes.

In Figure 4, most of the identified praxes and practices occur in the earlier stages of the change request process. In this context, it has previously been claimed that opportunities in decision making are best seized early (Hammond et al. 2015), and this perspective corroborates our results. However, further research could exclusively focus on exploitation practices and praxes to deepen knowledge on this topic.

Ward and Chapman (2003) presented a proposal for transforming risk into uncertainty management that includes a terminology comparison of “what is” to “what ought to be”, e.g., a “problem” becomes an “issue;” an “upside” risk becomes an “opportunity”; and a risk, upside or downside is regarded simply as an uncertainty. This play on words suggests that there is room for nudging (Thaler and Sunstein 1975) ad hoc teams toward opportunity discovery and exploitation with documentation and processes associated with engineering changes. Finally, we hope this article, in general, and these suggestions, in particular, will stimulate further discussion of engineering changes and their relationship to ad hoc teams.