Product Platform Maintenance in Industrialized Housebuilding: Insights from a Swedish Case Study

Abstract

Industrialized housebuilding (IHB) integrates various constructs to meet customer demands through adaptable product solutions and efficient production processes. Although product platforms are increasingly common in IHB, research addressing platform maintenance remains limited. This study explored the maintenance of strategic product platforms within IHB, focusing on a Swedish company. The study applied the Design Research Methodology (DRM) framework, where this study is positioned in Descriptive Study I. Three data sets were collected to describe the current state, through analysis of design assets, platform maintenance practices, and two development projects. One case, from production, concerned roof hatches, and one case, originating in market demand, investigated window blocks. Data collection included semi-structured interviews and a series of workshops in collaboration with the design department. The results indicate key issues in platform maintenance, including the impact of new requirements on existing systems. Three central platform maintenance challenges were identified: fragmented knowledge management, poor traceability and reuse of special solutions, and difficulties transferring solutions across product lines. The findings from the development projects further demonstrate that alignment between design and production is a critical capability for platform maintenance in IHB.

1. Introduction

Industrialized housebuilding (IHB) is a multifaceted field that requires the integration and continuous development of various constructs [1]. Customer demands are met through the adaptation of product solutions and the rapid implementation of novel technologies combined with efficient production processes, where product design is carried out in collaboration with clients [2]. Over the past decades, product platforms have emerged as a strategic approach to balance the demands of clients and the market with those of production [3,4,5]. Construction is categorized as an engineer-to-order (ETO) sector [6], with each project carrying unique features. Lessing et al. [1] emphasize that IHB needs to be managed strategically rather than on a project-by-project basis.

In mechanical manufacturing, modularization and platform strategies have long been crucial for enabling efficient resource utilization through economies of scale [7]. Advantages advocated in the literature are to manage complexity, enable parallel design, and to use standardized modules across a product or product family [8], which enables a faster creation of new product variants by reusing component and interfaces [9], as well as their corresponding manufacturing system [10].

However, the housing market is characterized by client adaptations. Consequently, for IHB, the design phase is critical in balancing commonality and distinctiveness [11]. Solutions developed for specific projects often have an integral product architecture, which hinders reuse and continuous improvement [12]. Solutions developed for individual building projects often become highly integrated with project-specific requirements and constraints, limiting the reuse of platform assets and making systematic improvement across projects more difficult [3], while the strategy’s value diminishes when robustness is compromised.

Further, in the mechanical industry, platform preparation is typically done concurrently with new product development. However, in IHB, product platform development is often triggered or carried out on existing products, models or components, which must align with the conditions and prerequisites of the production system. This makes larger product/production revisions cumbersome. The immediate risk with the current setup arises when strict demands, such as updated enforced rules or laws, impact the product architecture. To remain competitive, the first criterion is to have attractive products in a market segment, followed by efficiency in production.

1.1. Product Platforms in Industrialized Housebuilding

The concept of a product platform is both ubiquitous and ambiguous. In this paper, a product platform is viewed as a strategic approach that creates a shared foundation for developing multiple products, promoting efficiency, flexibility, and cost-effectiveness in the overall product realization process.

Past research on platforms offered various conceptualizations [13]. A commonly accepted view is physically oriented, defining a platform as a set of common components or parts [14,15]. Another perspective is that platforms encompass the assets required to support a company’s market offerings [16,17], covering a specific range of current and potential requirements [18].

Over the past decade, product platforms have influenced IHB as a management strategy. Through product platforms, companies achieve high levels of product variety, reduced time to market, improved operational efficiency, and responsiveness to market needs [19,20], but the description is more applicable to market segments where lifecycles are shorter, and product characteristics are important. For IHB, the platform approach starts with manufacturing and the production facility, which typically have defined properties in terms of equipment sequences and processes. Previous research highlighted the challenge of making changes in product definitions without severely impacting production efficiency. Jansson [11] studied the design phase and emphasized that when an ETO strategy is applied, balancing distinctiveness and commonality is crucial, with much responsibility placed on the design. Poor management can lead to a company’s downfall by leaning too much towards one side or the other. Lessing and Brege [21] showed that industrialized building companies depend on a carefully balanced relationship between customer offerings and operational platforms; when customer adaptation exceeds the capabilities of the platform, efficiency and business performance may be negatively affected. Conversely, previous research showed that tightly controlled platforms improve production efficiency and standardization but may reduce the ability to respond to evolving customer preferences and market requirements if customization opportunities are too restricted [1].

Research in product development in IHB has been reported in greenfield projects with outcomes such as an information modelling method and the configuration of flexible volumetric elements [22]. Attempts have also been made to gain control over the platform by introducing product lifecycle management (PLM) systems, by utilizing the design platform [23]. Early initiatives in IHB have focused on the commonality aspect of the platform concept, especially for production conditions. However, it is challenging for ETO companies to implement a complete platform built from predefined modules. Different components may require different levels of engineering effort and customization, resulting in the coexistence of multiple production strategies within the same product architecture and increasing managerial complexity [24]. Challenges arise when technical managers and platform engineers define products from a modular perspective without a formalized development process. In such situations, customer-specific adaptations may drive the introduction of novel solutions through individual projects rather than through a controlled platform development process, limiting traceability, reuse, and continuous improvement of the platform [23].

1.2. Design Assets

An early and well-established definition [17] defined a product platform as a collection of four categories of assets—Components, Processes, Knowledge, People and relationships. Analogously, Jansson et al. [3] emphasized that platforms consist not only of physical components but also of process, knowledge, and relational assets that support product development and platform evolution. André et al. [16] proposes the design platform, a “toolbox” for development teams. Here, eight classes of objects form the backbone of a platform: Process, Product, Synthesis Resources, Analysis Resources, Geometry Resources, Constraints, Solutions and Projects. Raudberget et al. [25] clarify how the design platform can serve as an explicit, shared and clearly defined overall model to organize design assets, which can be incrementally added to support an evolving platform. The study also emphasizes that to retain their value, assets must be properly managed and maintained, including non-physical resources. Lennartsson et al. [23] demonstrate how the design platform is utilized to identify and organize a company’s design assets with the idea of initiating a product lifecycle management (PLM) system.

Examples of typical assets used in mechanical design departments are given by André et al. [16], who notes that important engineering resources, tools, methods, and practices may remain informal and person-dependent unless they are explicitly identified and formalized. Such resources are characterized as informal assets, and the author highlights the importance of identifying and formalizing reusable assets. An example of a non-physical informal asset is uncodified, personally developed knowledge.

Information, knowledge, and learning are prerequisites for synthesizing new products [26], and should therefore be managed as important assets. One challenge regarding assets is their dependency on context, which determines their usage. The context is critical for knowledge assets [27] and André et al. [16] argues that important engineering knowledge is often embedded in design assets such as methods, rules, analyses, and guidelines, which must be formalized to become accessible and reusable across the organization.

1.3. Platform Maintenance

Naturally, platforms will evolve over time, and an industrial study identified three fundamental platform life cycles [28]: preparation, execution, and maintenance. While there is extensive literature on the first two phases, there is a lack of research on platform maintenance [29]. Here, a methodology for release management, i.e., planned changes to an established product platform, is presented. Further, other scholars stress the distinction between platform life cycle management [30] and the established approach product lifecycle management (PLM), suggesting that the different lifecycle phases of product platforms require more attention from the research community.

Maintenance aims to preserve the function and performance of an object. Within a product platform context, this means maintaining the competitiveness of a product family. Schuh et al. [29] stress that it is mandatory to plan for the introduction of changes and most companies are missing a systematic way of working for the introduction of technical changes, which may jeopardize competitiveness over time. Further, Alblas and Wortmann [31] report on the risk of uncontrolled growth of variety, i.e., product modifications without updating the platform leading to platform inconsistency. Still, the corresponding production platform and its competitiveness are often overlooked.

Johannesson [32] presents the concept development platform, an integrated product and production system family platform. It consists of a platform for emerging technology and a system family platform from which product variants can be adapted within a defined bandwidth. However, there is no support for producing product variants that fall outside this initially defined bandwidth. To assess and define which modules should be updated in the next platform release, Schuh et al. [29] suggest a method based on the difficulty of redesigning specific modules. However, this method does not consider potential production difficulties. Similarly, Wortmann and Alblas [30] do not include production issues in their reasoning, but Michaelis et al. [33] presents a method for the co-development of products and manufacturing systems based on the configurable components platform [18]. These approaches, however, focus on the early phases of platform development. Kedir et al. [34] have looked into product platforms in IHB as an enabler to material passports to promote circular economy and report on both the lack of information but also how the information is managed.

1.4. Research Gap and Aim

Previous research on platform maintenance is slightly dated and has primarily focused on manufacturing industries and technical change management. Thus, little is known about how product platforms are maintained in IHB, where engineer-to-order practices, extensive customization, and strong dependencies between design and production create challenges. There is insufficient understanding of how IHB companies maintain design assets, capture and reuse knowledge, manage project-specific solutions, and align design and production when implementing platform changes.

This research aims to explore challenges related to IHB platforms by describing the current way of working and maintaining the platform in an IHB company. Previous research indicated challenges in organizing and utilizing platform assets, such as poor documentation and a dependency on individual knowledge and experience. This paper presents the challenges faced by the company’s work with a platform strategy, when new requirements from either production or the market are suggested. The empirical data come from two development projects, covering development initiatives originating from both production and product specifications.

2. Materials and Methods

This research presents a descriptive analysis of an IHB company selected for its efforts to enhance its platform strategies. The choice aligns with the views of Eckert et al. [35] (p. 3), who emphasizes the importance of balancing well-founded research findings with opportunities for empirical investigations that align with a company’s goals. Given the scope of this study and the existing research in IHB, an explorative case study approach is deemed appropriate for gaining in-depth knowledge [36]. The focus of this case study is the IHB operational platform, including its structure, functionality, and the impact of external factors on its development.

2.1. Research Design and Data Analysis

The study applied the Design Research Methodology (DRM) framework [37]. There are four stages in DRM where this study is mainly positioned in Descriptive Study I (DSI). The presented theoretical framework helps to frame the research clarification (RC). The literature revealed that for IHB, product platforms have become a common strategy within the trade. Together with ten initial interviews (Data Set 1), the exploration clarified that platform maintenance is a territory worth investigating, both from a theoretical and practical perspective.

The study observes a single company in an unchartered domain (platform maintenance). Consequently, the study becomes explorative and therefore an extensive number of interviews and multiple data sets were gathered [38], which are presented in Table 1.

Table 1. Overview of the Five Collected Datasets.

Data Set	Study	Interviews	Workshops	Documents
D1	Orientation	10		Yes
D2	Design Process		3	Yes
D3	Interviews, Designers	6	1
DP1	Roof Hatches	5	1	Yes
DP2	Window Blocks	2	2

The collected interview data, workshop observations, project documentation, and cdevelopment project materials were analyzed using an iterative thematic analysis approach. Initial coding was performed on each dataset according to its primary purpose. As additional datasets were collected, the codes were continuously refined and compared across datasets. Findings were triangulated between interviews, workshops, documents, and development projects to identify recurring patterns and inconsistencies. Emerging interpretations were subsequently validated with company representatives through workshops. In the following sections, the prerequisites for the data collections as well as the data analysis are presented.

2.2. Data Set Descriptions

2.2.1. Data Set 1 (D1)

The purpose of Data Set 1 (D1) was to gain an understanding of the current operations regarding product platforms and product development at the company. The interviews were semi-structured, where an interview guide had been developed, with questions categorized into the following themes: Product Realization, Product Development, Production Development, and Product Platforms. The respondents included in the data set covered key roles and areas of the company: Product Manager, Structural Engineer, Technical Manager, Platform Development Engineer, Development Engineer CAD, Production Preparation Manager, Production Technician, Production Manager, Project Leader Building Site, Process Owner, and Business Area Manager. The interviews were conducted online by two researchers, each lasting approximately 90 min. Additionally, the company shared the following documents: Company Descriptions, Process Map for New House Development, and Product Component Descriptions. At this stage, the collected data were coded with regard to the four themes in the interview guide. Since the same set of questions was used for all respondents, the results could be validated across answers from the different participants.

2.2.2. Data Set 2 (D2)

Evidently, both from literature regarding IHB operations and the design platform, but also findings extracted from D1, the purpose for Data Set 2 (D2) was to further scrutinize the design process, the use of design assets, but also to analyse how the designers were working with design issues in customer projects. The strategy for D2 was more practical and consisted of a repetitive series of workshops and document analyses engaging two designers. The company provided documents to the researchers, originating from real customer projects. The documents were scrutinized, platform characteristics and possible design assets were noted, and questions were formulated to discuss at the associated workshop. In the workshops, the designers answered the different questions that were raised, which also included descriptions on how they work, e.g., design assets and documents within the platform and what will happen if special solutions outside the platform are requested. This way of working was iterated three times and allowed the researchers to gain more understanding of the design process, enabling them to dig deeper into the project documents in the next cycle.

2.2.3. Data Set 3 (D3)

The results from D2 indicated that design experience was significant, and Data Set 3 (D3) investigates this further by interviewing designers with different levels of experience. A senior designer and a corresponding junior designer were interviewed to allow the gap in experience to be catalysed. The strategy was to present a scenario (roof structures) to the respondents to catalyse the utilization of design assets. In conjunction a standard interview guide was developed to be used for all interviews to allow comparisons and facilitate identification of gaps regarding way of working. Three different roles were targeted: Building Permit Design, Design Support, and Lead Design, which resulted in three pairs and a total of six interviews. The results were then presented at a joint workshop where all six respondents participated to validate and discuss the findings.

2.2.4. Development Project 1 (DP1)

Two development projects were followed to understand how the platform is used in practice. The researchers did not take any active part in these projects, but with the gained knowledge from D1–D3, observations were captured and analysed towards both scientific and practical perspectives regarding product platforms, design assets, and maintenance. Development Project 1 (DP1) with roof hatches originated from production demands while Development Project 2 (DP2) centred on window blocks and was driven by the marketing department. The data for DP1 were primarily gathered when most of the project was completed. Thus, the aim was to reconstruct the process and the implications within the project. Access to documents was granted, including product descriptions, floor plans, and roof and hatch drawings. Five people were involved in the project. The project leader was employed as a platform development engineer. The other participants included a structural engineer, a production technician, and technicians for two of the brands, B1 and B2. The strategy was to first interview the project leader to obtain an overview of the project’s progress. Subsequent interviews provided additional information to supplement the initial description. The questions were formulated to both capture the responsibilities within the project and also to ask about the results emerging in D1–D3. The combined analysis of the data resulted in a map with the main events and their associated resources within the project. The subsequent workshop had the purpose of validating the map and also to identify concerns and lessons learned from the project.

2.2.5. Development Project 2 (DP2)

The project directive for DP2 was decided in connection with the closure of DP1. For DP2, the researchers were allowed to observe and participate in the project from the launch. This allows the researchers to observe how a development project is carried out in practice compared to the other data sets where the interview situation is more formal and constricted. There were seven project participants, who were engaged by the product manager: product manager (project leader), technical manager, concept developer, head architect, production technician, structural engineer, and a designer. The team was compiled by the product manager. Two workshops were held, and two interviews were conducted with the product manager and the technical manager in the aftermath after the project was shut down.

3. Results

3.1. Current State of Operations

This section presents the collected results from D1–D3. References were added to support and contextualize the results. The case company is a manufacturer operating throughout Sweden, with its main market being residential buildings. Annually, the company produces approximately 1300 units and employs around 800 people. The company offers both single-family and multi-family houses through design-build contracts. The products are categorized into three separate brands (B1–B3).

• B1—Single-family houses based on a panel element system. Base models are presented in an assortment catalog but serve merely as inspiration for clients.
• B2—Single-family houses based on a volumetric element system. Twenty base models are offered. An online configurator generates a complete product and production model.
• B3—Multi-family houses based on volumetric elements. This product can be seen as an extension of B2 to include taller buildings (certified up to six floors) with apartments. The floor plans are configured from thirteen base modules.

The preferred business model is well established for IHB and includes three primary components: market, offer, and operational platform [39]. Therefore, the offer must align with both market demands and the capacity of the operational platform. The logic can be further detailed: Jensen et al. [4] investigated the operational platform specifically and formalized different views of the operational platform; product view, engineering view, and production view. Popovic et al. [40] suggested five different alignment modes, describing the interplay and identifying the challenges in the interfaces.

According to the technical manager, “The product platform is the entire process, everything from sales, meeting the client, the ERP, what is allowed to be included in the order, what parts, components, and elements can be built in the factory and on the building site”. Thus, the results have been categorized into the domains; Sales (S); Design (D); and Production (P) (see Table 2).

Table 2. Platform characteristics and their applicability to the sales, design, and production processes.

Platform Characteristic	Sales	Design	Production
The three brands (B1–B3)	x	x
Building system		x	x
Modular conception		x	x
Common templates between projects		x	x
Standardized measurements/distances		x	x
Component configurability	x	x

For the Sales (S) department, the brands and configurability are important in order to allow the potential clients to tailor their demands to the house. All platform characteristics are attached to the Design (D), following the logic and core of the business model. Thus, the design function is decisive for the competitiveness. Furthermore, there are four characteristics associated with the production domain, which originates from the conceptual idea of a building system. This is further emphasized when examining where reuse is applied within the company. A core principle is to reuse earlier solutions as much as possible, following the maxim, “if it isn’t broken, don’t fix it.” There is a resistance to change, as the consequences can be severe if errors are introduced into the design.

The three brands are all produced on the same production line, aiming for an 80% prefabrication level when delivered to the assembly site. Given the level of automation, several constraints and rules from production impact the solution space for the design department. Common templates, in the form of guideline documents, describe the product architecture and the technical solutions used, including floor plans, choice of materials, building codes, and sustainability protocols.

The volumetric building systems B2 and B3 are simpler compared to the panel system used in B1, as they offer less variation. Both support product differentiation by allowing scalability and adaptation of modules providing the same function. Some measurements are standardized and fixed (e.g., height to ceiling), while others are scalable (e.g., wall width). Furthermore, a governing generational platform is provided by the company’s IT system, combining the building system and the scalable platform. This enables the instantiation and configuration of specific customized modules and the documents needed to manufacture a complete house. The resulting design consists of both drawings and numeric control files that control the manufacturing system.

3.2. The Design Process

The general design work process starts with the solutions available in the product solutions folder. Product variants are designed through the configuration of prepared base modules, such as panel elements or corners. These are complemented by relevant support files from the detail library. The main content of this library includes descriptions and instructions for connecting the elements, components, and parts. For example, drawings and descriptions of the actual panel elements are not included, with only three heights allowed.

In production, various groups are responsible for ensuring that products can be efficiently produced before they are released. Models are created to validate solutions. However, much of the work is still done in silos, which risks both effectiveness and efficiency. Additionally, there is a lack of understanding of production conditions, as the company is primarily sales oriented.

3.3. The Use of Design Assets

Through the data collection (esp. D2), the researchers identified several resources and sources of information that supported the design process. Components are reused for the prefabricated elements, and the building system is presented in a uniform way. The detail library is crucial, where the main contents are the variants of connections/interfaces between larger elements, but also containing all components and parts needed to design a complete house. In addition, there are design supports such as a design handbook, CAD-model library, and a guide on snow load zones. There are also online sources for the designers to utilize such as OneNote (product solutions, rules, methods, and application), monthly newsletters with technical updates on new products, solutions, and regulations; and an initiative to a Wiki-page with previous projects available to reuse technical solutions—this is not yet fully functional. Evidently, there is a wide range of resources available to support designers. However, to classify an object as an asset, it needs to be reuseable, i.e., formalized, structured, and updated. Consequently, some of the resources mentioned above may not be regarded as platform assets.

3.4. Challenges in the Current Design Process

The panel building system B1 offers more variability and is therefore more complex than the volumetric systems B2 and B3. This difference illustrates one of the core issues within IHB: mastering the balance between commonality and distinctiveness. A more open system allows for more customized solutions, requiring greater competence and resources within design, whereas a closed system can only deliver a limited set of solutions with correspondingly less time spent in design. The panel system also allows for detailed customization, where existing solutions in the detail library are modified. These customizations are filed as “Special Solutions,” and documents are labelled with an ‘S’ and stored in the specific customer project. All adaptations should be labelled with an ‘S,’ but designers admit that this rule is used arbitrarily. The variants are not traceable since there is no effective search function available. An associated risk is that building site staff lack experience with the building system, leading to unnecessary errors. Since the company operates over a large geographical area, it is necessary to contract local teams, making the customized assembly of elements a liability.

From an asset management perspective, the handling of ‘S’ solutions makes them difficult to reuse. Documents are scattered across different locations, and designers are reluctant to use them because they are unsure whether the solutions are valid. The full responsibility for the different solutions lies within the design department; the solutions are not disputed by production staff or assembly teams at the building site. Feedback on the quality of a Special Solution does not reach the designers, making it hard to develop these into standard solutions, i.e., assets in the design platform.

Moreover, the varying quality of available design assets has led designers to develop personal work procedures and utilize assets according to their own convenience. The design information in the OneNote resource is updated by the design department but the content in the information folder has not been updated for years, and its structure follows traditional folder principles rather than digital logic.

As the design process follows predefined steps, it requires designers to be “inaugurated” into the building system and the company’s way of working. Interviews with senior designers concluded that this is generally not a significant problem as long as standard measurements are followed. For junior designers, there is a lot of unspoken knowledge needed. Comparative interviews between junior and senior designers confirmed that their ways of working differed and that more assets were needed.

3.5. Catalysing Platform Maintenance: Experiences from Two Development Projects

3.5.1. Development Project 1 (DP1): Roof Hatches from a Production Perspective

Development Project 1 (DP1) started with brand B3. The current roof is constructed using small hatch elements, which together form the entire roof. Figure 1 both illustrates a typical solution consisting of 70 elements (Figure 1a) and the developed solution with 12 elements (Figure 1b). The project aimed to improve the product, production, and building site assembly, focusing on the following effects:

• Reducing the risk of moisture entering the structure by speeding up the assembly process (product and assembly).
• Improving the work environment at the building site by reducing the number of heavy lifts required for the elements (assembly).

Figure 1. (a) Original solution (70 elements), (b) Developed solution (12 elements).

Figure 1. (a) Original solution (70 elements), (b) Developed solution (12 elements).

The investigated solution would reduce the number of hatches from 70 to 12. The larger hatches would also increase the prefabrication level in the factory, as the elements could be coated with cardboard, laths, and valves. Currently, the hatches are manually produced in a side process that is not part of ordinary production. Notably, the suggested solution does not change the appearance or outer geometry. As the development project leader stated, “Changing those sizing dimensions would rapidly increase the complexity of the project.”

Since the desired effect was already agreed upon, a bottom-up strategy was chosen, and the project progressed incrementally. The project leader, a senior development engineer with more than 30 years of experience, oversaw the following steps:

• Finding a solution for the elements: The solution needed to satisfy specifications for structural strength, both for lifting and site assembly. A structural engineer performed calculations to obtain valid solutions.
• Selecting a current project: A project from the order stock was chosen to test the solution.
• Producing test elements: A technician from production was assigned to produce specimens. These elements were then tested for load-bearing capacity, including lifting, while ensuring the overall weight was not too heavy.
• Measuring on-site assembly: The desired effects of the new solution were scrutinized at the building site.

Up to this point, the project was successful in achieving the initially identified effects. However, these effects were only valid for B3. The company’s steering group decided that the solution should also be applicable to B1 and B2. Technicians representing B1 and B2 were allocated. B1 allows more customization, and the investigation showed that the different kinds of elements could be produced, but it would be challenging to maintain production efficiency with additional element variants. This is especially true since the hatches were previously manually produced, while the new solutions were intended for incorporation into ordinary production.

There was also a challenge because the new solution was developed for B3, which consists of larger buildings with apartments, whereas B1 (and B2) are single-family houses. Consequently, the geometrical limitations made it difficult to reuse the elements. Furthermore, the general development of the B1 platform aims at increasing design automation, and there was a risk that the project would increase design efforts. There were also concerns about the impact on the B2 platform. Once the project encountered these challenges, it was shut down and was not reconsidered for B3.

Thus, even though the project was successful in finding a solution that met technical specifications and achieved the initially identified effects of faster assembly and improved work environment, there were problems in scaling the solution to other product lines and finding a production solution that allowed the new elements to be incorporated. In the post-project evaluation, the following points were extracted:

• Development projects that are not carried out are saved but are not easily accessible, especially after some time has passed.
• The senior project leader’s extensive experience with the company’s entire operations (products, production, platform, etc.) is crucial for development.
• There is no structured way of working with platform development, but the project leader’s experience serves as quality control both in developing solutions and navigating the development project, including when to call for resources.

A developed solution may be valid for parts (B3) of the platform driven by commonality goals (both for product and production), but when attempts are made to transfer the solution to other parts of the platform (B1 and B2), problems with production efficiency and variant management emerge.

3.5.2. Development Project 2 (DP2): Window Blocks from a Market Perspective

The project was initiated for B1 and focused on the wall elements and the window block subcomponent, which are produced separately from the wall element production process. The block is subsequently fitted into the wall element. Since the wall elements of B1 also form the volumetric elements of B2 and B3, this development would significantly impact one of the base modules in the overall building system. However, the intention was for the solution to be optional for the client.

The project was picked up by the head architect, who was monitoring the market. The aim was to insert multiple consecutive window blocks into the walls. By assembling the blocks side-by-side, the view angles and light admission from the outside would be improved, removing the disruption that occurs between the windows and offering a uniform set of windows. Figure 2 displays the current solution with the stud location marked between the windows.

Figure 2. Current solution with stud location marked.

However, to achieve the desired effects, the supporting studs in the window block had to be made slenderer. The window block is designed so that the side studs carry the load from the ceiling. Consequently, narrower studs will reduce the load-bearing capacity. The project was led by the product concept manager, and a project team was formed, including a concept developer, head architect, product technician, structural engineer, designer, and technical manager. Similar to the roof hatches project, this project aimed to work bottom-up towards a solution that met the specifications.

At the project launch meeting, the production technician raised concerns about lifting the blocks during assembly and the lack of necessary equipment. Figure 3a illustrates the horizontal beam, for a single window block, carrying the load from the roof truss. When multiple consecutive window blocks are used, issues will occur regarding varying dimensions on that beam. Consecutive window blocks require one horizontal beam that spans across all the window blocks (Figure 3b). This problem was also raised by the structural engineer. The starting point had to be in the statics, using the structurally weaker solutions. Given the multitude of variants, it was decided to begin with the “worst case” scenario and work upwards.

Figure 3. (a) Drawing of a window block with the reinforcing and stabilizing beam indicated. (b) Conceptual idea of adding consecutive window blocks indicating load, the location of the horizontal beam, and pinpointing the challenge of weaker studs.

The structural engineer conducted calculations on a single-floor house with openings in the wall elements to accommodate two or three window blocks and different standard angles of the roof trusses. The results showed that when using standard material beams, acceptable deflections were only achieved for the two-block width and roof trusses with the largest angles. When using a stronger beam (glulam), better results were obtained, with deflections within the allowed tolerances for all the roof trusses. However, in the evaluation of adding a third block, the deflection was too large for low roof truss angles. Therefore, to achieve acceptable deflections, a significant amount of additional timber would be needed to reinforce the element, which would risk creating a thermal bridge when insulation is replaced with extra beams and studs.

The report from the production team emphasized several risks related to production efficiency, including increased lead times for some operations, the risk of the window blocks becoming a bottleneck, internal logistics issues, inventory management challenges, and additional items to handle in the ERP system. Other concerns included the work environment and operator safety. Additionally, the new studs would be too weak to attach the block to the wall element. If glulam beams were used, the walls could either budge in or out depending on the amount of material. The current solution utilized the stud next to the window block in the wall element to attach slings for lifting the elements. With consecutive blocks, there would not be any stud strong enough to handle the lifting. Similarly, making composite window blocks with multiple windows would create problems due to the lack of appropriate lifting equipment.

After summarizing all the initial analyses, the project leader decided to shut down the project. The identified problems from the initial investigation posed a risk of quickly propagating into other parts of the building system. Additionally, since the project’s motive was not driven by strict demands but rather targeted as an add-on to the product offering based on market trends, it was argued that the possible solutions would be too cumbersome to implement.

A set of long-term changes were identified, including updated rules, laws, or requirements related to energy and outer dimensions; keeping pace with new technology for both products and production; and balancing market fluctuations with manufacturing capacity. The remedies suggested in the interviews were broad, such as “being up to date,” improving collaboration and communication, and strategically securing competence. However, there were no specific answers on how to achieve these solutions. Securing competence is linked to short-term challenges, as high staff turnover creates problems in daily operations, leading to decreased efficiency in both design and production. The suggested solutions here were also broad: making information accessible, improving communication, and enhancing the ability to predict changes.

For manufacturability in product development, various initiatives have been launched, such as structured decision-making, review of drawings and documents by production staff, and the use of production “messengers” (the most experienced staff in production acting as information distributors). Support from the cross-functional group TPU (Technology and Product Development) has also been sought. There is a desire for increased automation and digitalization in production, including the ability to simulate factory flows. However, the responses also highlighted that cooperation between design and production is not flawless, changes take a long time to implement, and knowledge about production decreases among product managers, project developers, and the market. Communication silos are also present in this context, which is a significant problem according to the interviews.

4. Discussion

The current state analysis revealed that, for IHB, production ability controls the potential to generate new product solutions. Meyer and Lehnerd [7] concluded that a strong production impact implies that the product platform is essentially the production process. However, IHB is characterized as an engineer-to-order (ETO) trade [6], where designers and their customization are pivotal. This is corroborated by designers’ reports, which indicate that product variants and solutions are the sole responsibility of the design department. Consequently, if production defines the platform, and that design is central to the production strategy and to the ETO business model, designers must thoroughly understand production to ensure efficiency, develop valid variants and solutions, and respond effectively to market demands.

The examination of the design process, the use of design assets, and the outcomes from the two development projects revealed an ineffective document structure and knowledge repository within the platform in several ways:

• Extensive knowledge, experience, and understanding of the platform are exclusive to a small group of senior staff, as evidenced by the premature launch (DP2) and termination (DP1 and DP2) of the two development projects.
• Platform documentation management is poor, characterized by missing, faulty, or outdated information, or a combination thereof.
• A structured historical archive is absent.
• The high impact of production, combined with the prevailing ETO business model and production strategy, underscores the critical importance of understanding and managing the interface between design and production.

DP1 demonstrates how a technically successful solution can nevertheless fail to achieve platform-wide applicability. The new roof hatch concept improved prefabrication, assembly efficiency, and working conditions within the B3 product line. However, attempts to transfer the solution to the B1 and B2 product lines encountered substantial challenges due to differences in product architecture, customization requirements, and production conditions. This highlights a misalignment among platform elements and illustrates that a solution developed for one part of a product platform cannot be assumed to be directly transferable to other areas. This is related to the beachhead strategy [7], where the platform should be flexible enough to cater to multiple brands and market segments. DP1 identified a gap between the company’s conception of their brands and difficulties arising from the platforms for the brands. The case further revealed a strong reliance on senior employees’ tacit knowledge and a limited formalization of lessons learned, constraining effective platform maintenance, organizational learning, and knowledge reuse.

DP2 demonstrates how market-driven development can reveal limitations within an existing product platform. The project aimed to enhance customer offering by introducing more attractive window solutions. However, the proposed changes had far-reaching implications for structural performance, production processes, logistics, lifting operations, and assembly methods. Although the concept delivered clear customer value, it could not be efficiently accommodated within the existing building and manufacturing systems. As a result, the project exposed a misalignment between market requirements, product offerings, and the operational capabilities of the platform. Its early termination underscores the importance of cross-functional evaluation in identifying platform constraints and assessing implementation feasibility before substantial development resources are committed.

Taken together, DP1 and DP2 illustrate that product platform maintenance involves more than developing technically viable solutions. Long-term platform success depends on maintaining alignment among market needs, product architecture, production systems, and organizational knowledge. In DP1, the lack of alignment limited the transferability of a technically successful solution across product lines, while DP2 showed how customer-driven innovation can be constrained by existing platform capabilities. Both cases demonstrate that misalignment between platform elements can prevent otherwise promising solutions from being successfully integrated into and sustained within the product platform.

Further, the outdated and insufficient documentation stresses the necessity for structured, continuous platform maintenance, a situation exacerbated by the development of new variants by designers [31]. Additionally, existing research on platform maintenance primarily focuses on product design, whereas for IHB, production is paramount. Given the explicit ETO platform strategy, these findings are concerning and render the company vulnerable to market shifts. The advantages of product variety and time savings can be compromised, particularly if production responsiveness is slow to introduce new solutions. For example, with sustainability high on the agenda, decisions regarding materials, equipment, and IT systems are crucial for survival, as changing the chosen path takes considerable time. Therefore, flexibility in manufacturing solutions and investments is essential to accommodate possible future market demands.

When new materials are introduced, which could improve processes and work environments, an expensive tool is often purchased instead, leading to an immediate but suboptimal solution lacking a long-term perspective. Much later, the new material is finally introduced [40]. This example demonstrates the platform’s lack of responsiveness. Another example, extracted from the interviews, was when horizontal façade panels became a market trend, but the production facility was not equipped for that type of solution. Once the demand consolidated and a large share of the overall order stock included that solution, new machinery was purchased to increase production pace. A comparison of the findings with regard to previous literature is presented in Table 3.

Table 3. Comparison of the study findings with previous research.

Theme	Previous Literature	Findings	Contribution
Product-production interaction	Alignment between product and production platforms is important.	DP1 and DP2 showed that feasible solutions may fail because of production implications.	Provides empirical evidence of alignment challenges during platform maintenance.
Design assets and knowledge reuse	Platforms consist of assets, which should support reuse and platform development.	Design assets exist but are fragmented, poorly maintained, and difficult to reuse. Special solutions are stored within projects and have limited traceability.	Demonstrates how poor asset management and reuse mechanisms hinder platform development.
Platform maintenance	Focuses mainly on manufacturing industries and technical change management.	Platform maintenance is affected by knowledge management and production constraints.	Extends platform maintenance research to IHB and highlights the role of knowledge management and production conditions.

The findings in this paper serve as a wake-up call for IHB companies employing a platform strategy. The platform encompasses more than merely presenting products in a modular fashion, especially since product design is influenced by production conditions. Therefore, when initiating development projects, it is crucial to persevere and complete the investigation, even if the results are not immediately integrated into the current platform. Platform characteristics and peculiarities must be documented, even if they pose obstacles in the current development.

This paper reports findings from a single IHB company, which may limit the generalizability to other companies. However, other IHB companies have also faced challenges with platform management spiralling out of control [23], and production efficiency is critical for companies with relatively static production systems. The research design was exploratory, utilizing two development projects as instruments to identify platform characteristics or deficiencies. This approach was motivated by the initial interviews that revealed a lack of a distinct working methodology within the company. The exploratory strategy and the design of the two development projects may affect the reliability of the data collected. Therefore, multiple data sets were gathered to complement each other, and the findings were traced back to common weaknesses in knowledge management.

5. Conclusions

This research aimed to explore challenges related to IHB platforms by describing the current way of working and maintaining the platform in an IHB company. Two development projects highlighted the platform’s characteristics, revealing the risks associated with insufficient knowledge management.

5.1. Scientific Contributions

The study contributes to the literature on product platform maintenance by extending the discussion from traditional manufacturing contexts to industrialized housebuilding (IHB). The findings demonstrate that platform maintenance in IHB is not solely a technical change-management challenge, but is influenced by knowledge management, the reuse of design assets, and the interaction between design and production. Through the analysis of design practices and two development projects, the study identified fragmented knowledge management, poor traceability of special solutions, and difficulties in transferring solutions across product lines as barriers to platform development. Furthermore, the results highlight design–production alignment as a critical capability for maintaining competitive and adaptable product platforms in engineer-to-order environments.

5.2. Practical Implications

There are practical implications for IHB companies seeking to maintain and evolve product platforms effectively. Companies should establish structured processes for capturing, evaluating, and reusing project-specific solutions. In the studied company, special solutions were stored within individual projects, making them difficult to locate, validate, and reuse in future developments.

Further, platform maintenance should be supported by systematic knowledge management practices. The study revealed a dependence on experienced individuals for understanding historical decisions, platform constraints, and development opportunities.

Also, platform maintenance should involve closer collaboration between design and production functions. Both development projects demonstrated that technically feasible solutions may fail because production constraints or operational consequences are identified too late in the process. Cross-functional evaluation and early production involvement are therefore necessary to improve decision-making and reduce implementation risks.

Finally, companies should adopt a long-term perspective on platform development and maintenance. Development projects that do not result in immediate implementation may still generate valuable knowledge regarding platform limitations, interface challenges, and future opportunities. Such knowledge should be systematically retained to support future platform evolution and strategic decision-making.

5.3. Future Research

This study provided an exploratory understanding of platform maintenance in an IHB context through a single case study. Future research should focus on developing and evaluating methods that support the long-term maintenance of product platforms in IHB, i.e., prescriptive study (PS) in DRM. Attention should be given to mechanisms for capturing tacit knowledge, transforming project-specific solutions into reusable design assets, and improving traceability across platform generations. Following the completion of this study, the case company initiated an effort to film production stations and operational procedures as a means of preserving and sharing knowledge. These films have the potential to function as design assets that support competence development and communication between production and design. Future studies should therefore evaluate the effectiveness of such knowledge repositories. Finally, further research is needed to develop governance models and working methods that strengthen design–production alignment and support the continuous evolution of product platforms in engineer-to-order environments.