Exploring the Client–AEC Interface in Building Lifecycle Integration

Abstract

The creation and management of buildings over their lifecycle involves the cooperation of many organizations, which broadly fall into a client domain and AEC (architecture, engineering, construction) domain. While this mix of expertise is essential, the ineffective management of the boundaries between these organizations can undermine building lifecycle performance. This paper explores client–AEC interactions at the project development and handover stages, with a view to discovering insights into client–AEC interface management for effective building lifecycle integration (BLI). The concept of boundary objects provided the theoretical framework to discuss findings from two case studies on the project development phase of a private finance initiative project, and the asset development process in a repeat client organization. The findings suggest that there are different emphases in boundary crossing activities at different stages, with boundary roles that relate to decision-making and authority to commit resources being more relevant at the project development stage, whereas the need to explain meanings appear to be more relevant at the handover stage. AEC professionals in client organizations play a crucial role in bridging knowledge boundaries about buildings, but this professional/functional strand to BLI needs to be effectively managed alongside the organizational boundaries, since the authority to resource BLI efforts resides within organizations.

1. Introduction

The design, construction and management of a building involve the cooperation of many organizations and individuals. These can be broadly categorized into two main domains: the client and Architecture, Engineering and Construction (AEC) domains (the role of regulatory and financial bodies which affect both domains is excluded here for simplicity). Figure 1 shows the different stages in the lifecycle of a building and the activities that usually fall within the client and AEC domains.

Figure 1. Simplified model of building lifecycle stages and interface between client and Architecture, Engineering and Construction (AEC) industries [1].

Figure 1. Simplified model of building lifecycle stages and interface between client and Architecture, Engineering and Construction (AEC) industries [1].

The client domain usually incorporates the owner/purchaser, operator, manager and user functions of buildings. These functions might be performed by one organization, but this is not always the case (e.g., in retail facilities, where users are usually different from owners) [2]. Buildings are a means to meeting a “business need” (e.g., for shelter, commerce, etc.) and may therefore be secondary to a client’s core business, with the possibility that all (or most aspects) of their design, construction, operation and management can be outsourced to external provides to create efficiencies [3]. Indeed, it has long been the convention that design and construction functions are outsourced to the AEC (or construction) industry, with the client retaining responsibility for operation and management; but other models have evolved over time. For example, the outsourcing of facilities management (FM) services (Figure 1) in part or in whole is now commonplace [4]. The development of alternative forms for procurement (e.g., Design Build Finance Operate and Transfer—DBFOT, and Private Finance Initiative—PFI) has also shifted the responsibility for different lifecycle stages of a building, with AEC and other firms being responsible for stages/activities (e.g., financing within project development, and FM) that were traditionally within the client’s domain. In theory, depending on the nature of a client’s business, every aspect in the creation and management of buildings can be outsourced to other firms. However, while outsourcing can be seen as a key strategy for organizations to be competitive [3], it nonetheless often creates fragmentation in the overall management of a product or building.

The AEC domain includes all professions and firms engaged in the design and construction of buildings. The involvement of a wide range of professionals and firms in this process is a unique feature that allows for flexibility and the scope to put together the best mix of skills to deliver any project; but this fragmented structure leads to many problems, which include: the loss of information through lack of adequate coordination between the functional disciplines involved in a project; delays in the flow of information between project team members across stages in the project life-cycle; and an inefficient process that does not deliver best value to clients [5,6]. The integration of the AEC process, and the need to ensure that construction activities provide optimum benefits to clients and other stakeholders in the process, are now widely acknowledged in the construction industry. Since the 1990s, much effort has been devoted to understanding and developing various integration solutions, some of which (e.g., integrated procurement systems, project extranets, building information modeling—BIM) are now (or are becoming) well established in the industry. However, the focus of much of these efforts has been on the design and construction stages of a building’s lifecycle. This is understandable, given the fragmented nature of the AEC industry when compared to client/promoter organizations. However the need for building lifecycle considerations has also been recognized in AEC integration research and development. Whilst the emphasis has been on the incorporation of lifecycle issues in project development (e.g., [7,8,9,10]), other efforts have sought to bridge the AEC-FM divide through for example: the development of FM schemas in IFCs (Industry Foundation Classes) to facilitate interoperability and better information exchange between AEC and FM applications [11]; the use of Web and BIM technology to support FM activities [12,13,14]; requirements management to support building product models [15]; and the Soft Landings process, which facilitates a graduated handover of buildings through an aftercare service by the project team, for up to three years after completion [16]. The vision and strategy for Integrated Design and Delivery Solutions (IDDS) by the CIB (International Council for Research and Innovation in Building and Construction) also emphasizes the need for collaboration and integration throughout the lifecycle of a building [17].

This paper is set within the context of these efforts to connect the different phases in the lifecycle of a building, but with a focus on developing an understanding of the interface between the two main domains involved. The objective is therefore to explore client–AEC interactions at the project development and handover stages of a building’s lifecycle, with a view to discovering insights into client–AEC interface management for effective building lifecycle integration (BLI). Following a review of the concept of building lifecycle integration and the theoretical foundations for managing the interfaces between organizations, the research from two case studies is presented and discussed. The findings from these studies are discussed against the principles of inter-organizational interface management to provide insights into various considerations and recommendations for achieving BLI.

2. Building Lifecycle Integration

Building Lifecycle Integration (BLI) is defined here as: “the integration of all facets (e.g., information, processes, etc.) related to the various stages of a building, which include: design, construction, use/operation, maintenance/refurbishment, and demolition” [1]. Like AEC integration, which is intended to enhance effective collaborative working and an efficient project process, the goal of building lifecycle integration is to optimize the performance of a building over its lifecycle (i.e., with respect to how the building supports the immediate and changing business need of the client and other actors that interact with it, and the way its impact on the environment is minimized). Table 1 summarizes the similarities and differences between AEC integration and building lifecycle integration with respect to the need, goal, object, content/nature, and strategies for integration. The need for building lifecycle integration stems from the importance of building lifecycle issues, given that buildings constitute the largest component of the built environment and make a significant contribution (and impact) to the economic, social, cultural, and environmental fabric of a society [18]; effective lifecycle management therefore ensures that buildings continue to meet the needs of users, add value to owners and society at large, and minimize their (negative) impact on the environment.

Table 1. Comparison between Construction and Building Lifecycle Integration.

Integration areas	Construction (AEC) integration	Building lifecycle integration
Need for integration	Fragmentation of the project process	Fragmentation of the organizations responsible for lifecycle activities
Goal of integration	Collaborative working, efficient project process, best value to client	Optimum building lifecycle performance
Object of integration	The project organization	The building (over its lifecycle)
Content and nature of integration	“Integration of various aspects to provide a unified solution to the [client’s] problem” [1]	Integration of information and knowledge about the building to optimize lifecycle performance
Strategies for integration	Management of project interfaces through the use of information and communication technologies (ICTs) and procurement strategies	Similar strategies can be adopted to manage lifecycle interfaces, but no known unified process over the lifecycle of a building

Table 1. Comparison between Construction and Building Lifecycle Integration.

Integration areas	Construction (AEC) integration	Building lifecycle integration
Need for integration	Fragmentation of the project process	Fragmentation of the organizations responsible for lifecycle activities
Goal of integration	Collaborative working, efficient project process, best value to client	Optimum building lifecycle performance
Object of integration	The project organization	The building (over its lifecycle)
Content and nature of integration	“Integration of various aspects to provide a unified solution to the [client’s] problem” [1]	Integration of information and knowledge about the building to optimize lifecycle performance
Strategies for integration	Management of project interfaces through the use of information and communication technologies (ICTs) and procurement strategies	Similar strategies can be adopted to manage lifecycle interfaces, but no known unified process over the lifecycle of a building

Building lifecycle integration is also needed because of a number of factors. Firstly, the reality that the client is not a single entity [19], and the outsourcing of FM functions [4] suggests that many more players are responsible for “client domain activities” (Figure 1), thereby creating fragmentation that might undermine building performance. Secondly, the emerging models for financing and procuring buildings (e.g., PFI) are creating new definitions and responsibilities for clients and AEC organizations in building lifecycle management, which can lead to further fragmentation in the project delivery process [20]. There is therefore the need for more proactive integration over the lifecycle of a building, not just in the sense of incorporation of lifecycle issues in the design/construction stage, but in a manner similar to various integration efforts in the AEC industry (e.g., exchange and sharing of information, interoperability of systems, etc.). Drawing from considerations about outsourcing, Croteau et al. [3] suggest that this requires: (a) aligning of different information processing needs of the various organizations involved over the lifecycle of a building; (b) the need for efficient and collaborative information flows; and (c) on-going, continual alignment of product lifecycle and business relationships. Building lifecycle integration also involves the effective management of the interfaces between the different entities involved to ensure the seamless capture and exchange of information and knowledge about a building over its lifecycle [21]. These interfaces include: those between the different components and systems in a building (building integration); those between the building and users and other actors that interact with it (building-user integration); those between organizations/people involved in its creation, management and decommissioning (external actors’ integration). The design and construction process ensures building integration (as defined above) and creates the template for building-user integration, and external actors integration. However, while the processes for building integration are well established, this is not necessarily the case for other lifecycle interfaces.

This paper focuses on the client–AEC interface, which is usually at the project development phase, and the handover (commissioning) stage at the end of construction, although there are frequent interactions between the client and the project team during design and construction (Figure 1). Project development involves the articulation, justification and translation of the client’s business need (for a building) into a set of requirements that will allow the client to make a firm commitment through the award of a contract for the construction of that building [1]. Various professionals within the client and AEC domains are involved in this process, for example, in using FM information to inform the briefing process, and in translating the brief into design proposals which further clarifies the client’s needs. The improvement of the briefing and pre-project phases of a building’s lifecycle has been the subject of several research and development efforts (e.g., by [2,22,23,24,25]).

Client–AEC interface in the handover (commissioning) stage is usually in the form of the outputs of the AEC process (e.g., as-built drawings, operations and maintenance (O&M) manuals, Health and Safety File—[26,27]) being handed over to the client who usually has responsibility for FM. However, procurement through PFI and similar arrangements now allow AEC firms to be involved in FM operations well into the operational phase of buildings. Even in situations where AEC and FM functions are not provided by one organization, it is expected that since FM would have had an input in the development and delivery of a project, the resulting facility will have fully incorporated all their requirements. The Soft Landings process [16] mentioned above represents more recent initiatives to bridge the client–AEC interface at the handover (commissioning) phase of a building.

While there may not be an explicitly holistic framework for building lifecycle integration, various initiatives to “extend” the role of AEC professionals into the client domain (in both project development and handover) are intended to provide organizational and informational continuity required for BLI. The parallel strategy of client-employed AEC professionals (in a repeat client organization with an on-going building program) being directly or indirectly responsible for design, construction, operation and maintenance of buildings (i.e., client extension into the AEC domain), is also intended to facilitate BLI. Given these approaches, what can we learn about the interactions at the client–AEC interface with respect to building lifecycle integration? To what extent does an integrated procurement framework such as PFI or the context of a repeat client facilitate client–AEC interface management for building lifecycle integration? These questions, which underpin the research presented in this paper, will be explored through the lens of boundary theory, and interface management (IM) between organizations, and the context of two case studies. While other lenses from inter-organizational theories such as outsourcing, supply chain management, etc., might be applicable in investigating the client–AEC interface in building lifecycle integration, boundary theory [28] and IM are more appropriate here because they provide a better framework to explore how the organizational interfaces in BLI can be understood/made to work well. In particular, the “concept of boundary objects can throw useful light on efforts to achieve greater integration in the construction industry context through the use of partnering tools, techniques and processes” ([28], p. 617).

3. Organizational Boundaries and Interface Management

An organization is an entity with a boundary that defines “…the demarcation between the organization and its environment” and the essence of its internal make up [29]. Such boundaries have been conceptualized with respect to the social structure (identity, rules and culture) of the organization, a demarcation of resources owed by the firm, its sphere of influence, or with respect to its efficiency, power, competence and identity [29,30]. Other conceptions also include: an information processing perspective with a focus on the storage and retrieval of knowledge; an interpretative perspective with emphasis on a common understanding between actors as a means for sharing knowledge; and a political perspective with emphasis on the different interests that hinders the sharing of knowledge across boundaries [31].

There are different hierarchies in boundaries, which can be horizontal (with respect to the scope of product/market addressed), vertical (with respect to the scope of activities in the value chain) [29] or functional (with respect expertise and roles performed) [32]. The reality of boundaries also implies that knowledge is embedded within organizations; any collaboration with other organizations therefore requires the crossing of both organizational and knowledge boundaries [31,32,33,34]. Such knowledge boundaries can be syntactic (with respect to the commonality of language within a given boundary), semantic (with respect to meanings of language within the boundary) and pragmatic (with respect to different/divergent interests within and across boundaries) [33]. The “crossing of boundaries” therefore involves, among various actions, the management of the interface between collaborating organizations.

The concept of “interface” was originally linked to the contact point between solids but has now been extended to the meeting point between people, disciplines, systems and organizations [35,36,37,38]. An interface is defined as “the contact point between relatively autonomous organizations which are interdependent and interacting as they seek to cooperate to achieve some larger system objective” [35]. Like organizational boundaries, there are also different types of interfaces. These include: physical, contractual and organizational interfaces [36]; internal/external (within or external to an organization), time (change from one event to another), geographic (e.g., on-site and off-site work), and technical interfaces [37]. Interface issues arise from a lack of understanding of the different entities (boundaries) involved, poorly defined or inadequate alignment of work packages, poor communication and coordination, and failure to deal with emerging problems [37,38,39]. Interface Management (IM) therefore involves the management of boundaries between the cooperating entities involved “to enable a dynamic and well-coordinated construction system” [38] or to prevent “organizational system failure” [35]. The strategies employed to achieve this (similar to general management strategies but with a focus on interfaces) include: interface definition (to understand the nature of the interface), providing visibility of requirements and responsibilities, improving communication and control, and responding quickly to problems as they arise [37]. Specific techniques and tools in support of these strategies (e.g., the use of Work Breakdown Structure (WBS) matrix—[37]; and IT-oriented interface management—[40] are also being developed in recognition of the importance of IM in construction [36]. However, given that the need for interfaces between organizations only arises because of the boundaries that define organizations, IM in this paper will be explored through boundary theory and boundary objects.

Boundary Objects (BO) are: “…objects that are shared and shareable across different problem solving contexts [and which] work to establish a shared context that ‘sits in the middle’ [of the boundaries]” [33]. They temporarily bridge boundaries by facilitating interconnections [32] through “objects” such as repositories, standardized forms and methods, and objects or models [33]. These “objects” provide the context for establishing a shared language to represent knowledge, learn about differences, and transform knowledge across a boundary [33]. Various activities associated with boundaries include: ambassador (that lobbies for support and resources); task coordinator (aligns groups); scout activities (“inspect the market to ensure that demands are met and competitiveness is achieved”); guard activities (“control information flows to external organizations”) [32]. Bridging roles across boundaries include: boundary spanner (internal to an organization—“provides communication linkages between the organization and its environment by facilitating and filtering information and representing the organization externally”); broker (external boundary spanner—“translating, coordinating and aligning perspectives…”); translator (necessary for brokers—“helps parties to understand each other’s use of language, by acting as a mediator, but does not participate in the process like a broker”) [32].

The use/perspective of boundary objects has been found to bring about innovation (e.g., in the use of boundary spanner—[41], to foster collaboration [28,34]; generate value [42]; and foster productive knowledge exchange in collaborating organizations [32,33]. Carlile [31] (p. 555) further observes that “most innovation happens at the boundaries between disciplines or specializations (suggesting that) working across boundaries is a key ingredient of competitive advantage”. The nature of knowledge at a boundary relates to difference (e.g., in specialized domain knowledge between actors), dependence (between two or more entities to meet their goals), and novelty (e.g., where unfamiliarity or uncertainty in a given situation requires more effort to share/access knowledge across a boundary) [31]. These are all issues related to BLI, given the reality of different firms (with specialized domain knowledge) working together in the creation and management of buildings. However, it is helpful to note that although boundary types can be generic, fit and context are relevant in the application of boundary objects [32]. Bresnen [28] also observes that some boundary objects “helped transform understandings at some boundaries within the team, while simultaneously reinforcing others”. Table 2 summarizes the types of boundary objectives that might be suitable for specific types of knowledge boundaries. “There are important insights to be gained from understanding boundary conditions and the use of boundary objects in very localized settings where more collaborative ways of working across organizational and contractual boundaries are being developed” [28].

Table 2. Types of knowledge boundary, category, and characteristics of boundary objects [33].

Type of knowledge boundary	Categories of boundary objects	Characteristics of boundary objects
Syntactic	Repositories	Representing
Semantic	Standardized forms and methods	Representing and learning
Pragmatic	Objects, models and maps	Representing, learning, transforming

Table 2. Types of knowledge boundary, category, and characteristics of boundary objects [33].

Type of knowledge boundary	Categories of boundary objects	Characteristics of boundary objects
Syntactic	Repositories	Representing
Semantic	Standardized forms and methods	Representing and learning
Pragmatic	Objects, models and maps	Representing, learning, transforming

The concept of BO therefore provides a useful theoretical framework for exploring the client–AEC interface, in examining: the kinds of boundaries, boundary spanning activities and boundary objects used; and the role, relevance and effectiveness of these objects in enhancing BLI.

4. Research Methodology

The aim of the research reported in this paper was to explore current approaches for managing client–AEC interactions at the project development phase and handover stage, with a view to discover insights into client–AEC interface management for building lifecycle integration. The exploratory nature of the research reflects an interpretivist paradigm, wherein understanding is sought from the researcher’s own frame of reference (unlike a positivist view that the world conforms to fixed laws of causation) [43]. The operationalization of interpretivist research at the methodological level usually involves induction, and the use of qualitative methods, which focus on “determining what things exist rather than how many there are” ([43], p. 160) and providing depth of insight [44]. For this research, boundary theory (as described above) is used as the frame of reference to understand client–AEC interactions to enhance building lifecycle integration. A case study approach was therefore adopted, as it is most appropriate for qualitative research [44]. To reflect the two main aspects of the research, two case studies (both in the UK), which focused on the project development phase of a PFI project, and the asset development process of a repeat client organization, were considered.

Case 1 was an investigation into the project development process of a collaborative PFI project (hereinafter referred to as “the project”), which involved three fire and rescue authorities. Fire authorities are organizations that serve areas administered by one or more Local Government Authorities (LGA). Fire authority 1 serves an area represented by five LGAs; fire authority 2 an area represented by one LGA and a county council (CC) (federal LGA); fire authority 3 is a department of a county council. Data collection was carried out between February and May 2010 and involved semi-structured interviews with seven key members of the project development team (project director, internal financial consultant, external technical consultant, architect with the PFI contractor, one representative from each fire authority), examination of project documents (e.g., project plans, minutes, contract document, outline and final business case, correspondence and reports), and participant observation by the author as an external Design Quality Indicator (DQI) [45] facilitator at various stages in the project. Each interview lasted approximately one hour, was recorded on tape (expect 1), transcribed and verified by interviewees. Data analysis involved the identification and categorization of themes identified from interviews and project documents. Several discussions were also held with the project director to provide further information on the project and/or clarify issues from various documents.

Case 2 was an investigation into the asset development and management process within the Estates Department of a Higher Education Institution. The focus was on the integration of FM with other aspects of the asset development process, with particular emphasis on the feed-in of information from AEC outputs into FM operations. Data collection, which was carried out between September and October 2008, involved review of various documents (e.g., Operation and Maintenance—O&M manuals, in-house specifications and guidance for compiling O&M manuals, specific project documents) and semi-structured interviews (lasting approximately one hour) with three senior managers (senior project manager in capital development, head of maintenance and improvements, head of facilities management [46]) in the Estates Department of the organization. Interviews were recorded on tape, transcribed and verified by interviewees. Data analysis (as in Case 1) also involved the identification and categorization of themes identified from interviews and project documents.

The two cases were selected because they provided different perspectives (specific project vs. general processes within a particular organization) and phases (project development vs. AEC–FM interaction) in building lifecycle integration that are relevant in exploring in depth, the client–AEC interface. The researcher had also provided consultancy services to both organizations, and therefore had personal insight and contacts that facilitated the ease of data collection and examination of project/organizational documents. It is acknowledged that a case study approach has limitations with respect to making statistical generalizations. However, analytical generalizations and insights can still be made and applied to other contexts, and inform other studies [44,47]. The appropriateness to answer the research questions, use of multiple sources of evidence (in this instance, two cases representing diverse individuals and multiple organizations), and the repeatability of the operational procedures (e.g., reviewing and confirming case results with key participants/informants) further underscore the validity and reliability of a case study approach for this study [44].

5. Research Findings—Case Study 1

The project was for the construction of six new buildings in the three fire authorities: one community fire station (CFS) in fire authority 1; two fire stations in fire authority 2, two fire stations, and one headquarters building in fire authority 3. Figure 2 shows the project structure of the project and interactions with external organizations during the process.

Figure 2. Project structure and interactions in different project stages [1].

Figure 2. Project structure and interactions in different project stages [1].

In addition to the three fire authorities and their respective constituencies (i.e., LGAs, users of various CFS such as fire-fighters, and the general public), other stakeholders involved in the project were: central government (through the Treasury and department for communities and local government—CLG) who approve and provide PFI credits for the project; external consultants (who have a “hand-holding” role to “advise…on the process of procurement…making sure that due process is followed…in order to get a successful result”—interviewee: external technical consultant); community groups (potential users of fire stations); bidders; and other interest groups (e.g., Fire Brigade Union). The three fire authorities are part of a wider Regional Management Board (RMB), which provides a forum for operational collaboration among fire authorities in the region. Fire authority 1 was the lead fire authority (replaced by fire authority 3 after the project development stage) because they had previously implemented their own PFI project. For the purpose of the project, the three fire authorities entered into a joint working agreement (replaced by a cooperation agreement after financial close), which defined their roles, procedures for dispute resolution, and proportional share of procurement costs including the cost of the Project Director and his staff. A project board, chaired by the project director managed the day-to-day operations of the project and reported to the RMB.

The key stages and interactions in the project illustrated in Figure 2 broadly follow the usual PFI procurement process as outlined in [48,49] (the construction/operation phase was outside the scope of the research but is included in Figure 2 for completeness). The Project Inception (October 2003–March 2004) and the Development of Strategic Brief (April 2004–July 2006) stages were mainly carried out within the client organization with assistance from external consultants (AEC, legal and financial firms). Activities involved were: development and submission of a Formal Indicative Bid to the UK Department of Communities and Local Government (CLG); approval of the indicative bid and award of notional PFI credits; development of an Outline Business Case (OBC) which describe strategic and operational needs and a full justification for the project with respect to business needs; the formal approval of the OBC and award of PFI credits by CLG.

The Development of Project Brief stage (Figure 2) through a Competitive Dialogue Process [50] (August 2006–June 2009) with bidders, represents the main “client–AEC” interaction in the project development phase of the project. Eleven bidders submitted pre-qualification questionnaires following the publication of the OJEU (Official Journal of the European Union) notice inviting bids for the project. Six bidders were invited to participate in dialogue by providing responses to focused questions from the project team. From the assessment of these responses, three bidders were invited to continue in dialogue. Following this, two bidders were invited to submit final tenders, from which the preferred bidder was selected to proceed with negotiations to financial close and signing of the contract. At each stage of the dialogue, bidders progressively submitted more detailed information on the technical, financial and legal aspects of their bid. These were assessed by the project team with the assistance of external consultants. The DQI tool was also used to collate the views of a cross-section of stakeholders into an integrated set of aspirations which informed the assessment of designs and project outcomes. Bidders enhanced the process as they “…could put forward solutions which would not necessarily meet those requirements (set by the project team) if (they) felt they would add something to the project” (interviewee: PFI architect). The key milestones of this phase were: achieving financial close [51], development of the Final Business Case, signing of contract and the formal issue of PFI credits by the government. The framework of the regional management board (and joint working agreement), the leadership of fire authority 1 (and the project director) in sharing their previous experience in the project, and the support of external consultants (who themselves had previous experience of PFI projects), were instrumental in the success of the project. The interviewee from fire authority 2 observed that they were “able to learn from…particularly (fire authority 1) because…the experience that [they] brought primarily through [the project director], allowed (the project team) to have a real strong base on which to (negotiate with contractors)”. Throughout the process there was a strong reliance on face-to-face project team meetings (held fortnightly) and the personality of the project director to keep the project team together. An online data room (project extranet) for the sharing of project information was set up by one of the external consultants. After financial close the winning bidders set up their own extranet system for sharing information (interviewee: PFI architect).

6. Research Findings—Case Study 2

The Estates Department is organized into four divisions: Capital Development (CD), Maintenance and Improvements, Facilities Management, and Customer Services and Administration. The relevant sub-teams of these divisions and their key responsibilities are summarized in Table 3.

Table 3. Main Divisions and Responsibilities of the Estates Department.

Division (and relevant sub teams)		Key responsibilities
Capital Development	Property	Estate management, land/property acquisition and disposal
	Planning	Client liaison, space planning, brief development and outline design of major projects
	Capital Projects	Project management coordination services for projects over a certain cost threshold
Maintenance & Improvements	Improvements	In-house building and engineering design services and major improvements to facilities
	Maintenance	Building/plant maintenance and small improvements (which are part of preventative maintenance)
Facilities Management (“soft” facilities management)	Building facilities	Portering, cleaning, and mail services
	Grounds maintenance	Landscaping, gardening, etc.
	Security	General security of buildings and the estate
	Sustainability	Energy, utilities, and waste disposal
Customer Services & Administration		Provides a customer services function for the department in its interactions with other sections of the University; it also provides administrative services for the department

Table 3. Main Divisions and Responsibilities of the Estates Department.

Division (and relevant sub teams)		Key responsibilities
Capital Development	Property	Estate management, land/property acquisition and disposal
	Planning	Client liaison, space planning, brief development and outline design of major projects
	Capital Projects	Project management coordination services for projects over a certain cost threshold
Maintenance & Improvements	Improvements	In-house building and engineering design services and major improvements to facilities
	Maintenance	Building/plant maintenance and small improvements (which are part of preventative maintenance)
Facilities Management (“soft” facilities management)	Building facilities	Portering, cleaning, and mail services
	Grounds maintenance	Landscaping, gardening, etc.
	Security	General security of buildings and the estate
	Sustainability	Energy, utilities, and waste disposal
Customer Services & Administration		Provides a customer services function for the department in its interactions with other sections of the University; it also provides administrative services for the department

A good proportion of staff in the department have backgrounds in AEC professions and trades. For example the maintenance and improvements division is made up of “multi-discipline teams of engineers and surveyors” (interviewee: head of maintenance and improvements). In the capital development division there are quantity/building surveyors, architectural technologists, mechanical and electrical engineers (interviewee: project manager). The interactions between divisions are illustrated in Figure 3. Formal instructions and approvals go through the hierarchical chain of authority, but informal interactions (e.g., to obtain or clarify information) take place across teams. A senior management team (Director and heads of divisions) provides leadership and coordination of divisional activities within the department.

Figure 3. Interactions within the Estate Department [52].

Figure 3. Interactions within the Estate Department [52].

The role of various divisions in the asset development and management process is illustrated in Figure 4. The framework of the RIBA (Royal Institution of British Architects) Plan of Work [53] is used to map out the involvement of each division according to their roles described in Table 3.

Different teams are responsible for different stages in the process, with varying degrees of involvement by external consultants and contractors. The department follows procedures for project implementation which stipulates the role of different people, sign-off procedures, consultations, and documentation to be provided. Specific actions/guidance for the feed-in of AEC information to FM operations include: consultations with the facilities management and maintenance and improvements divisions to ensure that lifecycle issues are incorporated in the asset development process (e.g., the facilities management division endeavours to be involved at “…an early stage so that [they] can influence things like design,…what materials people use for certain things, because at the end of the day, [they’re] the people who have to maintain [the buildings]”—interviewee: head of facilities management); and provision of guidance to external consultants and contractors on “hand-over” documentation required (e.g., “a user guide for building end users including such information as contact numbers for defect reporting…”—internal guidance document), with a strong emphasis on the presentation of information in “layman’s terms”. An electronic copy of the O&M manual is also required after project completion and should include information on: project directory and list of all contractors, end-user guide, “as-built” and “as-installed” drawings, construction methods and risk assessment, description of all equipment and systems used, and commissioning and test data of all systems.

Figure 4. Responsibility for various stages in asset development and management (Adapted from [52]).

Figure 4. Responsibility for various stages in asset development and management (Adapted from [52]).

The operations of the Estate Department generally ensure the availability of building lifecycle information within the department. Relevant information about buildings is available but different types of information are stored in different formats and locations. Different divisions also use different types of software that are not necessarily interoperable. The head of maintenance and improvements observed that: “one of the biggest issue…we face…is management of buildings information…what’s happened in the past is, records have just been added to, or haven’t been updated, so whenever anybody (undertakes) a project, they would…hand you a manual about it and it would just be for that one small area of that building. It could be one room (or) a whole floor, and over this period of time, we’ve ended up with volumes and volumes of manuals, for the same building”. Cross-divisional consultation is sometimes problematic. The head of facilities management observed that: “quite often…we see notifications for some forthcoming work (but) there isn’t necessarily a consultation process. (When) we get information it’s a very tight deadline in which to respond”.

7. Discussion of Findings

The objective of this paper was to explore client–AEC interactions to discover insights into client–AEC interface management for building lifecycle integration, through the lens of boundary theory. The findings from the case studies will therefore be discussed with reference to the project development phase and the handover (commissioning) stage at the end of construction. The boundaries that exist (and were created) in the process, the types of boundary objects and/or bridging strategies, and their role in enhancing building lifecycle integration will also be examined.

At the project development phase, there is a close and iterative interaction between the client and AEC organizations (and professions). As was acknowledged earlier, the client is not a single entity [19], and both cases highlight the boundaries that exist within the client (e.g., different organizations, different functions/departments, and between users and purchaser/manager of construction services). Since external stakeholders (e.g., central government and community groups in Case 1) also influence client requirements for a project, the boundaries between these groups also need to be bridged. The nature of these boundaries span Carlile’s syntactic, semantic and pragmatic categories [33]. For example, in Case 1, the need to understand language/meanings of PFI procurement (e.g., converting PFI credits to Gross Floor Area or capital/operational costs) involves both syntactic and semantic boundaries, whereas the divergent interests within each fire authority and stakeholder group reflect pragmatic boundaries. In Case 2, consultations between divisions are more at the pragmatic level. Table 2 summarizes the bridging strategies, which involve either one or a combination of transferring, translating and transforming of knowledge, depending on the context [31]. In both cases the use of AEC-based professionals was a key bridging strategy to ensure commonality of knowledge [31,33] with external AEC firms. Other boundary objects/strategies (e.g., joint working agreement and DQI tool in Case 1 and formal procedures in Case 2) were also used. The extensive consultations with various stakeholder groups and emphasis on frequent face-to-face project management team meetings were very successful in bridging pragmatic boundaries in Case 1. For example, a proposal to modify the internal layout of the headquarters building in fire authority 3 from cellular to open-plan offices, and to locate shower rooms on the first floor rather than on the ground (street-level) floor in one of the fire stations, was met with strong opposition from potential users; but through open and honest discussions to identify and address all concerns this was satisfactorily resolved. In Case 2 however, the consultation of the facilities management (FM) division in new projects does not appear to be effectively bridging functional boundaries, creating a perception that the FM section did not have equal status with others.

At the handover (commissioning) stage, Case 2 suggest that boundary activities appear to focus on the use of standardized information formats, suitable for the bridging of syntactic and semantic boundaries. The attempts to brief external consultants to present information in “layman’s terms” and provision of user guides for end-users are attempts to explain “meanings” beyond the formal representations in “as-built”, “as-installed” drawings and O&M manuals (the Soft Landings process mentioned earlier provides this bridging role in a more extensive way). It would appear that pragmatic boundary issues are not crucial at this stage since consultations and decisions affecting the end-product would have been made earlier. However, the handover of building information to different sections of the organization (maintenance and improvements, and facilities management) that were not lead players in its development, creates further boundaries in the management of building lifecycle information. The problems associated with building information management when improvements are made to existing buildings further creates boundaries (or a fragmentation of information) between different kinds of information on a building.

The boundary spanning role(s) (i.e., the individual, department or team responsible for bridging the boundaries within the client, and between the client and external parties) within the client organization with respect to knowledge about the creation and management of buildings, is/are crucial in bridging boundaries. Aldrich and Herker [54] (p. 219) hypothesize that the information processing and external representational functions of this role depend on a number of factors, which include: “the expertise…in selecting, transmitting, and interpreting information originating in the environment”; and the homogeneity of the internal organization and pace of change (with more heterogeneous environments and faster pace of change, requiring more boundary roles). Both cases demonstrate similar and different ways of providing this function. In Case 1, the project management team provided this boundary spanning role (i.e., collating internal perspectives and requirements and liaising with external bodies), although there were certain layers to this: for example, only fire authority 1 (as lead authority) had direct communication links with the government, but with respect to bidders, the interface was with the entire project team. The project management team was also assisted by external consultants to bridge a knowledge boundary about the PFI process and of general AEC, financial and legal matters relating to the project. The project management team was an amalgamation of many boundary-spanning roles (e.g., representatives from each fire authority), suggesting that a unifying boundary spanner is an effective means of managing multiplicity of roles (a similar role is provided by PFI bidders, who integrate AEC/FM perspectives to ensure a unified, lifecycle solution to the client’s building need). However, although the PM team had the expertise to perform the information processing function, they did not have the political or financial authority to make quick decisions—this was left to individual fire authorities and led to delays in the process. In Case 2, the boundary spanning roles were somehow divided between different teams (Table 3 and Figure 4): for projects over a certain threshold, the planning team within the CD division liaises with users (and other internal teams such as facilities management), develops the brief and initiates negotiations with (and most often appoints) external AEC firms; the capital projects team then takes over the detailed implementation of the project. While this “division of labor” makes for efficiency (and supports Aldrich and Herker’s view of multiple roles [54]), it nonetheless creates further boundaries, which can lead to problems in effectively managing building information as Case 2 suggests. While AEC (and other) professionals, irrespective of their employment status (i.e., as full-time employee or engaged consultant) with the client organization, provide a bridging role based on “common knowledge” (and also that of broker and translator), it is not clear how they provide other boundary crossing functions (e.g., that of ambassador, scout, guard—[32]). For example, the external consultants (Case 1) (and even the project management team) did not have the authority to make financial decisions; in Case 2, their influence is varied, but somehow limited since major decisions about investment are made elsewhere in the organization. The bridging of the user/purchaser of construction services boundary also requires bridging strategies other than knowledge of AEC professional disciplines.

Over the lifecycle of a building there are the obvious boundaries between lifecycle stages. In both case studies the client–AEC interaction over a building’s lifecycle has distinct segments (that include one of more traditional lifecycle stages): an initial client-led project development segment, an AEC-led execution segment, and client-led operations and management segment. While the length of each segment can vary depending on the procurement strategy used, it appears that what is crucial for building lifecycle integration is how information is exchanged at change-over points/stages between client and AEC (and back again) and between different lifecycle stages. Of importance also is the extent to which knowledge about (and information requirements for) other stages is incorporated at key decisions points in the process. In Case 1, agreement on all matters (contractual, financial, technical) affecting the unitary charge (i.e., payment to the PFI contractor for the capital and operating costs of the project) are decided at commercial/financial close stage [51], before the start of construction. This requires adequate knowledge of lifecycle issues relatively early in the process. In both cases, there was reliance on historic data (from operations of other buildings in their portfolio) and the involvement of operatives in other lifecycle stages at key decision making points. However, the applicability of information into a different context (building) is questionable, as is the effectiveness of the consultation process (e.g., Case 2). This reflects the “novelty” property of knowledge at this boundary [31], where increasing uncertainties requires more effort to adequately share and access knowledge. Given the importance of lifecycle stages in building lifecycle integration and the changing nature of the roles of the client and AEC in their implementation, it does appear that managing lifecycle stage boundaries is more relevant for building lifecycle integration. The similar challenges of coordination of building/project information in both cases might further underscore the importance of a lifecycle-stages perspective to building lifecycle integration. However the organizational aspects are very crucial not only because of their involvement at each stage in the process, but mainly because authority to commit resources lies within organizational boundaries (e.g., lack of financial powers in the project management team in Case 1).

8. Conclusions

The aim of this paper was to explore interactions at the client–AEC interface to discover any insights that might contribute to building lifecycle integration (BLI). Boundary theory and the role of boundary objects in bridging organizational and knowledge boundaries provided the theoretical foundation to analyze the findings from two case studies: the project development phase of a multi-client PFI project, and the asset development process of a repeat client organization, with particular emphasis on the handover phase from AEC to FM. From the preceding discussions, the following conclusions can be made:

• The client–AEC interface with respect to building lifecycle stages is an on-going interaction that has many possible configurations, depending on the procurement option adopted. This flexibility is good but managing this dynamic relationship requires proactive focus on the interface points and the use of various boundary objects. For example, at the project development stage where key decisions are made and the perspectives of many stakeholders considered, the full spectrum of syntactic, semantic and pragmatic boundaries have to be considered [31]. However, boundary roles relating to decision making and authority to commit resources are therefore very important at this stage. At the handover stage the need to explain meanings of how the building works, rationale for various decisions, etc., (semantic boundary crossing) appears to be more crucial. However, at every stage, it is important to ensure that the key interface points (whether these represent people or not) are adequately reflective of the whole and provide continuity, especially of information and knowledge. These can be achieved through people, but an approach that also includes objects (e.g., a robust information system) is likely to be more helpful. Knowledge of other lifecycle stages and an understanding of the implications of various options/choices on lifecycle performance are also vital.
• The significant role that AEC professionals play in client organizations (whether as full-time staff of retained consultants) is increasingly blurring the client–AEC divide with respect to professional/domain knowledge about the creation and management of buildings. This suggests that there are at least two parallel strands in BLI: the professional/functional boundaries, and the organizational boundaries. These strands are not necessarily in sync with respect to where they sit in the client–AEC categorization, but they are both important for BLI. AEC professionals in a client organization (or the presence of client specialists in the AEC sector) strengthens the “building integration” element of BLI and can also bridge the “building-user” boundary (more specifically with respect to how the building responds to current and changing business need of the client) provided they are in bridging roles with authority to make or influence key decisions. Organizational boundaries relate more to decision making and resource provision, which are necessary to bridge professional/domain boundaries. The effectiveness of the client–AEC interface, it would appear, depends on the effectiveness of how the different perspectives within each sector are integrated to provide a clear unified view of the problem/solution.
• PFI and similar procurement strategies represent a change in the client–AEC relationship because after the contract is signed, the SPV effectively becomes the “client”, with the user organization paying for services (the utility charge) from them [20]. Building-user’ integration is admittedly the role of the FM function, but the outsourcing and combining of this with the AEC function, the building-user boundary is further reinforced. Other unintended boundaries that are likely to be created include: “soft FM” vs. “hard FM”; and between buildings within a client’s asset portfolio.
• It should be emphasized that the findings and conclusions apply specifically to the cases considered in this study. The boundaries and interfaces within the AEC domain were also not explored given their extensive coverage in AEC integration research. While the AEC domain was considered as an entity, it is acknowledged that it is not, and client–AEC interactions are usually not with a single entity, as the client can separately appoint different consultants/contractors depending on the procurement strategy adopted (e.g., the appointment of an architect to develop the client’s brief into a design as the basis for construction tenders). However, the findings are applicable in other project contexts, for example in recognizing that both of the parallel strands of professional/functional boundaries and organizational boundaries that need to be managed for effective building lifecycle integration.