Open Journal of Business and Management
Vol.2 No.1(2014), Article ID:42090,13 pages DOI:10.4236/ojbm.2014.21007

A Framework for Stakeholder Identification and Classification in Construction Projects

Aki Aapaoja, Harri Haapasalo

Department of Industrial Engineering and Management, University of Oulu, Oulu, Finland

Email: aki.aapaoja@oulu.fi

Copyright © 2014 Aki Aapaoja, Harri Haapasalo. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. In accordance of the Creative Commons Attribution License all Copyrights © 2014 are reserved for SCIRP and the owner of the intellectual property Aki Aapaoja, Harri Haapasalo. All Copyright © 2014 are guarded by law and by SCIRP as a guardian.

Received November 19, 2013; revised December 21, 2013; accepted January 6, 2014

KEYWORDS

Stakeholder Management; Identification; Classification; Framework; Integrated Teams; Requirements; Construction

ABSTRACT

Current construction is implemented in highly demanding and complex built environments where projects are executed by coalitions of multiple stakeholders that have divergent interests, objectives, and socio-cultural backgrounds. These projects face challenges in not only identifying and managing stakeholders but also satisfying their requirements. This paper introduces a framework that is developed to assist project managers in facilitating stakeholder management and requirement engineering, especially in the project initiation phase. The framework optimizes the value creation of the project through stakeholder identification, classification, and requirement engineering. The framework is also applied in two construction projects.

1. Introduction

Because it takes place in highly complex and uncertain built environments, contemporary construction project management is an art. The project manager’s primary challenge is that a project needs both to consider and satisfy a variety of stakeholders, which include the endusers, the customers, the designers, the contractors, and the maintenance team [1,2]. Moreover, each stakeholder has specific requirements with respect to the project, which create fundamental conflicts with others (e.g., many functions versus a low budget and no overruns). Conflicts are at the root of most project management difficulties—at both the strategic level (e.g., setting project objectives) and at the tactical level (e.g. change management) [3,4].

Operating in built environments has also changed the focus of construction. The contemporary focus is on delivering integrated solutions that meet the customers’ business activities (e.g., build an education facility) instead of only on construction activities (e.g., build a school). In delivering integrated solutions, customer needs are met by combining products and systems with services in order to specify, design, build, maintain, support, and operate throughout the construction life cycle [3]. Front-end activities have become highly important when operating in complex environments, particularly in revealing the conflicts between customers’ and other stakeholders’ requirements and purposes [4,5]. The ability to understand and manage the roles and requirements of various stakeholders is a critical task for project managers [6] because their primary role is that of facilitator among various constituencies, as well as collector and packer of project requirements to ensure satisfactory conditions for all parties [3].

The central argument is that there are no systematic processes for the stakeholder identification and management [2,5,7] as well as requirements engineering (RE) [8-10] in the construction industry which is causing huge problems, like delays and budget overruns, in the several projects [1,4]. The systematic process may help project management to identify, classify, and manage stakeholders more comprehensively. For example, traditionally the Finnish construction industry has strictly followed the national building code, in which stakeholders are presented as one and fixed group. This simple management approach cannot be used anymore in complex and dynamic environments [11]. In addition, the need for research is growing because relational project delivery methods and integrated project teams are becoming increasingly popular [12-14].

The objective of this study is to introduce a structured framework that identifies, classifies and manages project stakeholders. The framework facilitates the value creation and project outcome by identifying and consolidating the different roles and responsibilities of stakeholders. To create the framework, the following research questions are posed:

RQ1. What are the cornerstones of stakeholder management in construction projects?

RQ2. How can construction project stakeholders be identified and classified?

RQ3. What were the benefits of stakeholder identification and classification in the case projects?

The paper starts with a review of previous studies in project stakeholder management and identification and then considers aspects of requirement engineering in present projects. The second section ends with a synthesis that emphasizes the significance and cornerstones of systematic stakeholder analysis and management in the construction industry. The synthesis is followed by a framework that identifies the functional roles of project stakeholders, and assesses stakeholders’ salience and probability to impact on and ability contribute to projects in order to facilitate the identification and contribution of stakeholders in a construction project. The framework is tested in one renovation and one new construction project. The procedures, potential benefits, and limitations of the approach are also discussed. Figure 1 illustrates the research process.

2. Project Stakeholder Management and Identification

Contemporary projects are implemented in highly demanding and complex built environments. They are executed by coalitions of multiple stakeholders that have divergent interests, objectives, and socio-cultural backgrounds [1] Bourne [15, p. 31] defined project stakeholder as an “individual or group who have an interest or some aspect of rights or ownership in the project, can contribute in the form of knowledge or support, or can impact or be impacted by, the project”. Moreover, projects always interrelate with their location and environment, which may necessitate the consideration of special features (e.g., specific rules, norms, or stakeholders) [16]. Project management needs to balance competing claims on resources between the project and project stakeholders. Uncertainty and complexity in an environment, increase the difficulty of achieving this balance. Therefore, the ability to navigate through this environment defines

Figure 1. The research process.

successful project management and hence project success [15,17].

Project stakeholder management is the systematic identification, analysis, and planning of actions to communicate with and impact stakeholders [18]. Stakeholder analysis and identification aims to facilitate the understanding of how to manage stakeholders in invariably changing and unpredictable environments [19]. Because the primary focus of stakeholder management is on project managerial decision making [20], thus the perspective has typically been predominantly that of the key company. However, taking into account the stakeholders’ point of view can ultimately enhance understanding about the stakeholders and their management [19]. For example, barriers to collaboration and the adversarial nature of construction are usually because of differences in culture and habits between team members and stakeholders (e.g., designers and contractors). Such conflict causes disrespect, mistrust, and rivalry among stakeholders, which must be overcome by developing and maintaining teamwork and stakeholder management throughout the entire project [5,21].

Cleland [22] emphasized the importance of stakeholder identification, classification, analysis, and management approaches. The most typical approach is to divide stakeholders into internal and external stakeholders. Internal stakeholders (aka primary stakeholders) are formal members of the project coalition and they control resources. External stakeholders (aka secondary stakeholders) can be considered informal members of the project and have no direct control over a resource. However, they have the potential to influence the project positively or negatively [16,22-23].

The main purpose of project stakeholder management is to manage the relationship between the project and its stakeholders [19]. An important issue is identifying and analyzing stakeholders that can affect project outcomes and decisions [24]. This study applies stakeholder Salience framework [25] and Olander’s [4] impact/probability matrix to development a framework for stakeholder management, analysis, and identification.

2.1. Stakeholder Salience and Positioning in the Project

Stakeholder salience is “the degree to which managers give priority to competing stakeholder claims” [25, p. 869]. In other words, the model identifies the stakeholders to which managers should pay attention. Stakeholder salience is divided into three attributes: power, legitimacy, and urgency. Salience depends mostly on the number of attributes that a stakeholder possesses. It also refers to the degree to which managers give priority to competing stakeholder claims [23]. Salience can vary during a project, which means that some stakeholders may try to shape their salience attributes in order to make their voices heard [25].

The first attribute, power, is defined as the probability that one stakeholder within a social relationship would be in a position to carry out his or her own will despite resistance. In other words, some stakeholder X can get another stakeholder Y to do something that Y would not otherwise have done [25]. The power of stakeholders may arise from their ability to mobilize social and political forces or to withdraw resources from the project. Although they usually do not initiate action, government agencies and courts have a special kind of formal power [4].

Legitimacy is the perception or assumption that the actions of an entity are desirable, proper, or appropriate within a socially constructed system of norms, values, beliefs, and definitions [25]. Project managers are usually more willing to pay attention to stakeholders whose claims they perceive as legitimate [23]. Legitimacy can be held by individuals, organizations, and society. However, it should be noted that although a stakeholder has a legitimate claim, if he or she does not the power to enforce it, it will not be salient in the eyes of the project manager [25]. For example, contractual relationships with the project increase the power of the stakeholder; therefore, external stakeholders that do not have a contractual relationship can be neglected [23].

The last attribute is the urgency of the stakeholder’s request. Urgency is “the degree to which stakeholder claims call for immediate attention” [25, p. 869]. It is based on two features: time sensitivity and criticality. Time sensitivity is the degree to which a managerial delay in attending to the claim or relationship is unacceptable to the stakeholder. Criticality refers to the importance of the claim to the stakeholder [19,25]. Urgency can be understood as an interest of the stakeholder. In the construction industry, the possibility negative consequences of the project objective and implementation increase the urgency of the claim [24]. Although urgency is not as compelling an attribute as power and legitimacy are, its importance is not diminished. Urgency determines both the dynamics of stakeholder salience and the interactions between stakeholders [25]. Mitchell, Agle and Wood [25] divided stakeholders into eight classes, depending on the attributes of power, legitimacy, and urgency:

0) If the stakeholder does not possess any of the three attributes, they cannot be counted as a project stakeholder.

1) Demanding stakeholders have an urgent claim, but have no power or legitimate relationship. They can be irksome but not dangerous, so management can disregard them.

2) Discretionary stakeholders possess the attribute of legitimacy, but they do not have power or urgent claims. Although there is no pressure on managers to engage in an active relationship with such stakeholders, they can choose to do so.

3) Dormant stakeholders possess the power to impose their will, but they do not have any legitimate relationship or urgent claim, and thus their power remains unused.

4) Dependent stakeholders possess urgent and legitimate claims, but no power. These stakeholders depend upon others for the power to carry out their will.

5) Dominant stakeholders are both powerful and legitimate. Their influence is assured, and it is clear that the expectations of any dominant stakeholders will matter.

6) Dangerous stakeholders are not legitimate, but they possess power and urgency. They can be coercive and possibly violent; hence, they can be “dangerous”.

7) Definitive stakeholders possess all the attributes. They will already be members of an organization’s dominant coalition. When their claims are urgent, managers have a clear and immediate mandate to consider and give priority to that claim.

It is not enough to identify stakeholders [26] and assess their salience. The salience framework defines stakeholders’ level of impact on a project only if they decide to act. Thus, managers also need to assess stakeholders’ probability to act and express their interest in project decisions [4]. Olander [4] created the impact/ probability matrix, where the project stakeholders are categorized depending on their level of impact and probability of impact on the project (Figure 2). The matrix is used to analyze the following questions:

•       How interested (probability to impact) is each stakeholder group in expressing their interest, expectations, or contributions to the project?

•       Do they have sufficient leverage (level of impact) to do so?

The matrix indicates the types of relationship that

Figure 2. The stakeholder impact/probability-matrix (Olander, 2007).

project management might typically establish with stakeholders in the different quadrants [26]:

1) The “key players” are usually those with responsibilities for the project.

2) The “keep informed” stakeholders consists different interest groups, such as local residents, non-governmental organizations or organizations with low impact.

3) The “keep satisfied” stakeholders are often national governments, authorities or other similar organizations that have requirements and even the power to stop the project, but do not usually have a personal interest in it.

4) “Minimal effort” does not mean ignoring the stakeholders; however, the project management does not regard them as salient and focal. However, these stakeholders can try to gain salience through other stakeholders if they have some requirements of the project.

2.2. Requirements Engineering

Construction was formally perceived as a project team industry that principally dealt with construction firms. However, the new approach is based on the fact that the construction industry is no longer focused on providing a single product but a variety of services to the built environment around the project [2,27]. The extension of the aspect has increased the complexity and uncertainty of project management, which has underlined the importance of systematic collecting, managing, and reconciling the different requirements of stakeholders. Theory W [3] states that the primary job of project management is to make “winners” of each stakeholder involved in the project. This theory involves two principles: 1) identify and manage requirements; 2) plan the flight and flight the plan.

Requirements engineering (RE) is a systematic and iterative process of understanding, capturing, and documenting the requirements of stakeholders with regard to a project [e.g., 28,29]. The purpose of RE is to create understandable, complete, and consistent requirements that all stakeholders can accept [29]. An effectively performed RE process plays a major role in the success of a project. If the requirements are not well-defined, it is almost impossible to achieve a successful project [30].

RE consists of two major phases: requirement development and requirement management. The requirement development phase can be further divided into four interwoven sub-phases: elicitation, analysis, documentation, and validation. Requirement elicitation is the process of discovering requirements from various sources and stakeholders. Analysis aims at reviewing requirements priority and feasibility, resolving conflicts, and negotiating alternatives among different stakeholders. In the documentation phase the requirements are saved and concretized in order to enable communication. The documentation should be conducted in a standard way; otherwise, the information about requirements may change during the development process. The purpose of validation is to ensure that the requirements are accurate, complete and meet the customer’s needs and intentions. Requirement management focuses on managing the changes in organizing, tracking, and maintaining requirements (Distanont, 2013).

2.3. Stakeholder Management in Construction Projects

The possibilities of influencing project success and value creation are perceived as the best during the early phases of the project. Early decisions reduce unnecessary changes during later development phases and even the total costs of the life-cycle [31-33]. However, influencing demands that the project management identify and involve the projects’ key stakeholders immediately at beginning of the project [12,34]. In addition, Yliherva [35] pointed out that the interfaces between organizations are significant sources of innovations. Hence, the involvement not only concerns internal stakeholders but also external stakeholders that may have both requirements and contributions to the project [36].

This methodology has been applied for years in the manufacturing industry, especially in the context of product development. In this context, the methodology is called Design for X (DfX). It is a structured approach to addressing systematically early product development and functional integration, as well as enabling capability creation. In the DfX, the X stands for an aspect or a stakeholder under consideration, such as manufacturing, environment, maintenance, supply chain, cost, and so on [31,32,37]. The same Xs exist in the construction industry, but the names can be different. Therefore, the analogy of DfX remains the same, and it is essential to consider stakeholders and their requirements in the construction industry, as in product development. Effective requirement engineering (RE) requires that the stakeholders’ needs are systematically documented because this is the only way to make sure that the requirements are undisputable and can also be discussed, analyzed, and referred [29]. Moreover, documentation leads to the traceability of design decisions to original requirements throughout the life-cycle of the facility [9].

Because of their different roles and responsibilities, all project stakeholders are not equal. Therefore, because stakeholders cannot be handled similarly, they should be divided into groups that better reflect stakeholders’ roles. Hence, requirements and stakeholders can be managed efficiently and systematically. However, in the construction industry, stakeholder management has been proven challenging. For example, in the Finnish construction industry, traditional approaches to project delivery have strictly followed national norms, regulations, and building codes (e.g., the national building code) [11], where the stakeholders are presented as a fixed group of five (end-user, developer, engineer, contractor, and public authority) and their roles are assigned in detail [38]. Codes and norms themself are not bad, but are applied in complex projects and environments that must take into account various different project stakeholders. Therefore, it cannot be assumed that all the projects include only five different stakeholders that always play the same role [39]. Furthermore, stakeholder involvement is generally project-specific, that is what works in one situation may not be appropriate in another [40]. The more complex the project is, the greater number and responsibilities of the stakeholders. Therefore it is crucial to analyze the stakeholders according to the project in which they are involved.

One way to analyze the project stakeholders is to consider the salience of the identified stakeholders relative to the project’s purposes, requirements, and constraints [25]. In addition to assessing stakeholder salience, it is vital to discuss the stakeholders’ roles within the project and how to ensure that different disciplines (stakeholders) work concurrently in collaboration. Specifically, the purpose is to involve disciplines in the same process and consider of all life-cycle issues affecting the facility [9, 10]. However, there is usually a tendency to rush into the details of the design without a proper understanding of the premises [3]. Hence the purpose of different project phases and the kind of stakeholder contribution that is adequate in each phase must be clarified.

A systematic approach covers stakeholder identification, classification and management. It requires that the process is controlled by a project management team or project core group that has a comprehensive understanding about the project, as well as the power to steer and manage the project. The team cannot be too big; however, team coordination and management becomes more difficult as the number of team members increases [41]. There is no optimal team size [42], but the team size and composition is always specific to the project. Nonetheless, effective teams include three to nine members, and the most effective teams have three to six members [42].

3. Constructed Framework

The constructed framework is developed to assist the project management in facilitating stakeholder identification, classification, and requirements engineering, particularly at the beginning of the project. The framework aims to enable the creation of integrated project teams by identifying and involving stakeholders that may significantly contribute to the project. Hence, the ultimate purpose of the framework is to optimize the project’s value creation.

The framework merges project stakeholder management, salience and classification, and requirement engineering. The constructed framework includes four main phases (Figure 3):

•       Defining the project purpose and customer constraints

•       Identifying project stakeholders according to their functional role;

•       Assessing the stakeholder salience and the probability of their impact/ability to contribute;

•       Classifying and prioritizing stakeholders according to four groups.

Moreover, the framework includes the requirements engineering process. Although stakeholder requirements are gathered, systematic requirements engineering does not start until the last phase, in which the stakeholders are classified. Only then can the requirements be systematically collected and managed.

Figure 3. Framework for stakeholder identification and classification.

The framework focuses particularly on the beginning of the project, when it crucial to identify both certain and uncertain (participation inconclusive) stakeholders. The framework is therefore limited in that it does not consider potential changes in the stakeholder network. Stakeholder dynamics warrant a separate study. Hence, to analyze changes among stakeholders and their salience, the same framework needs to be applied in all phases of the project The framework does not take into account stakeholders’ attitude (e.g., proponent or an opponent). Stakeholder requirements must always be considered, whether they support or oppose the project. Moreover, in the eyes of project management, the proponents are usually perceived to have higher salience and probability of impact and contribute than the opponents have.

3.1. Defining the Project’s Purpose and Customer Constraints

At the beginning of any project, the main task is to define the project’s purpose and what the business and the customers want to achieve [39]. Moreover, in order to complete the project in a reasonable way, the customers’ constraints must be considered. Although these are mainly connected to the project’s budget and schedule, the resources and competence of the customers also impact project completion. Customer constraints define the degree of freedom within the project in relation to its purpose.

The documentation of project purpose and customer constraints can be considered one of the most essential aspects. As previously emphasized, systematic and standardized documentation is the only way to ensure the traceability of requirements. Hence, these can be also discussed, analyzed, and revised later in the project.

3.2. Stakeholder Identification

Defining the customers’ purpose and constraints can sometimes be difficult. Because the stakeholders define the characteristics of the proposed project, most challenges stem from the requirements that the project stakeholders and project environment place on the project. The definitions lead to the recognition of which types of stakeholder are going to be part of the project [39]. There are no rules regarding whom to involve and how to involve them, but some questions can be used to guide project managers to identify stakeholders [43]:

•       Who might be affected by the development concern to be addressed?

•       Who are the “voiceless” for whom special efforts may have to be made?

•       Who are the representatives of those likely to be affected?

•       Who is responsible for what is intended?

•       Who is likely to mobilize for or against what is intended?

•       Who can make what is intended more effective through their participation or less effective by their non-participation or outright opposition?

•       Who can contribute financial and technical resources?

•       Whose behavior has to change for the effort to succeed?

To maximize the value creation of the project, the project management must be aware of the different roles of stakeholders. Traditionally, stakeholders are divided into internal and external stakeholders. However, this division is often vague. Therefore, stakeholders should be determined according to their functional role in a project, such as customer, contractor, end-user, sponsor, resident in the vicinity, non-governmental organization (NGO), media, lobbying organization, and government [16].

3.3. Assessing Stakeholder Salience and Probability to Impact/Ability to Contribute

Because the stakeholders in a project are very rarely equal, their probability to impact or contribute to the project varies. Ultimately, however, they influence the validity of requirements, which aims to ensure that requirements are consistent, complete, and correct for the project [30]. Therefore, it is essential that the project management assess the salience of stakeholders and their probability of impacting the project.

The assessment can be done using the matrix shown in Figure 4, which is an adaptation of the impact/probability matrix modified by Olander [4]. In this matrix, the level of impact is changed to salience (Y-axel) because the more salient the stakeholder is, the higher the level of impact. Therefore, these two concepts can be considered parallel. The Y-axis describes the stakeholder groups in

Figure 4. Stakeholder assessment matrix.

order of importance [4,25,44] and the X-axis describes stakeholder’s probability to impact/ability to contribute to the project.

Compared to Olander’s [4] matrix, the order of stakeholder positions is changed to improve the reflection of stakeholder salience. The stakeholder cannot be a “key player” if it does not possess at least two attributes. Due to the high salience, “key players” can be also regarded as “primary team members” of the project.

The difference between “keep satisfied” and “keep informed” is volatile, but usually the probability that “keep informed” has (or wants to) impact or contribute to a project’s outcome is higher than “keep satisfied”. Thus “keep informed” are more like “key supporting participants” and “keep satisfied” like “tertiary stakeholders” who usually have no personal interest on the project. Finally, the stakeholder possessing one attribute can be considered “minimal effort” or “extended stakeholders”. Moreover, the matrix takes into account that the active impact and contribution of a stakeholder may affect that stakeholder’s position.

3.4. Stakeholder Classification, Prioritization and Team Formation

The constraints on a project prevent project management from involving all possible stakeholders equally. Therefore, the classification and prioritization process has to be established, in which certain aspects of the stakeholders enable them to be at the top of the list [39]. To classify and prioritize stakeholders effectively, the project management must comprehensively utilize the information gained from all the previous phases. Because of the unique nature of projects, some project-specific features could emphasize or reduce the importance of some stakeholders, which should be determined when they are classified.

According to the literature on stakeholder management [e.g., 24,26,40] and relational project delivery [14,45], the classification and prioritization is as follows (classes are in order of importance):

•       Primary team members (forms also the project core group)

•       Key supporting participants

•       Tertiary stakeholders

Extended stakeholders

Primary team members (PTM) and key supporting participants (KSP) represent internal stakeholders while the external stakeholders include tertiary and extended stakeholders. The interests of PTMs, key supporting participants, and tertiary stakeholders “must be dealt with” so that the project may achieve its goals. Project management seeks to balance some interests [40] of extended stakeholders. It should particularly strive to integrate internal stakeholders, thus taking advantage of their expertise.

Primary team members have substantial involvement and responsibilities throughout the project. PTMs usually include the customer, architect, and the main contractor but can include other stakeholders as well. PTMs usually form a core group within the project, which makes unanimous decisions and resolves conflicts. The core group consists of representatives from all the PTMs [14, 46]. Because its role is the most essential in the project, the core group is responsible for the management of project requirements throughout the project.

Key supporting participants have a vital role, but they perform functions that are more discrete than those of than PTMs. KSPs usually include the consultants, subcontractors and designers—excluding the main designer). PTMs must collaborate closely with key supporting participants because their knowledge strongly affects the design and helps the project to proceed smoothly [14,45]. Therefore, the line between the PTMs and the KSPs is fine. For example, on a majority of projects, the structural engineer is not a primary participant because they normally perform discrete functions and are rarely substantially involved in the duration of the project. However, if structural engineering plays a central role, and the structural engineer has substantial responsibilities throughout the project, he or she can be a primary participant [14].

In addition to the internal stakeholders, inter-firm projects include multiple external stakeholders who are not formal project members so their role is not as central as the roles of PTMs or KSPs are. However, because they expect something from the project, they can influence it, particularly if they are ignored [16,40]. It is therefore crucial to identify them as well. Examples of external stakeholders are local community members, NGOs, media, lobbying organizations, public and governmental authorities (mandated by law), and sponsors.

External stakeholders can be further divided into two separate groups: tertiary and extended. Tertiary stakeholders provide inputs (e.g., regulations) and even some resources (e.g. financial and logistically) that have to be considered so that the project can be implemented [47]. Extended stakeholders, such as media, NGOs, and local residents do not have direct control over resources, but they may have an interest in the project [40].

3.5. Applying the Framework to Construction Projects

In order to validate it, the framework was applied to two construction projects in Finland by employing a case study strategy. It is an empirical inquiry that studies a contemporary phenomenon within its real-life context when the boundaries between phenomenon and context are not clearly evident and in which multiple sources of evidence are used [48].

The first case project was a new health center; the second project was the renovation of a four-story building. Different cases were selected in order to reveal characteristics or variables that were specific to renovations and new construction projects, thereby increasing the feasibility of the framework. The diversity of the stakeholders and good access to project managers were the other reasons for the selection of these projects. In addition, the project managers were personally interested in applying the framework to their project and thereby get an opportunity to the better stakeholder management in their projects.

Because the framework was primarily created for project managers, one face-to-face interview for each project manager (1 manager/project) was conducted, lasting 1 - 2 hours. The interviews were recorded and transcribed to increase the reliability of data collection and to facilitate the analysis. In addition, the other purpose of interviews was to validate the framework by performing a weak market test to determine whether the method is good enough for someone to employ [49].

3.5.1. Case Health Center

The project is an ongoing public project that will produce a new health center with an area of 4570 square meters. The project was started in April 2013 and should be finalized by the end of March 2014. The project budget is 10 million euros, and the project delivery method is design-build (the design and construction services are contracted by a single entity).

The project manager identified 11 stakeholder groups in the project. Figure 5 shows the project stakeholders’ positioning based on their salience and probability to impact/ability to contribute. The identified stakeholders’ functional roles are as follows:

1) Customer: Local municipality responsible for the project’s follow through and success. The municipality defines the project’s purpose and the customers’ constraints.

2) End user: Doctors, nurses, patients.

3) Main contractor: The main responsibility for the construction activities.

4) Sub-contractors: Contract the main contractor. Perform small, straightforward and discrete functions, such as painting, ceiling contracting, wallpapering, and floor tiling.

5) Side-contractors: Contract with the customers. Responsible for larger and more complex functions (than subcontractors), such as HVAC (heating, ventilation, and air conditioning), automation, electricity, and plumbing.

6) Main designer (architect): Has main responsibilities for the design and the consolidation of designs by other designers.

Figure 5. Stakeholder positioning in the health center project.

7) Other designers: Design discrete and technical subsystems, such as HVAC, structural, electricity, and automation.

8) Public authorities: Representatives of local and public authorities. Supervises and may set constraints for the project execution of the following: supervision of construction, planning division, fire authority, and health authority.

9) Material suppliers: Supply material and equipment, such as concrete, windows, furnishings, and research instruments.

10) Local residents and neighbors: May express some requirements or requests for the project.

11) The council and board of the municipality: The final decision maker, who ultimately approves the project and the grant funding.

According to the project manager, this case project is a traditional project with only a few specific features. However, because health care is a specialized environment and field, this project needs expertise and knowledge in several areas, such as research instruments and facilities. Moreover, all end-user requirements are impossible to satisfy. Therefore, the project manager viewed their representation in the project core group as essential and particularly stressed their salience and the importance of their contribution and involvement in the project. Figure 6 illustrates the stakeholder classification and team formation in the case project.

3.5.2. Case Renovation

The second case project is a joint-stock property company that encompasses two interconnected four-story buildings (19,600 cubic meters) that were built in 1971. One building serves as business premises (39 offices), and the other one is an apartment building (19 apartments). The project’s purpose is not only to renovate the buildings but also to build one to two additional floors. The project delivery method is design-bid-build (e.g., design and construction are carried out by separate entities, and the builder is chosen through a bidding process based on the finished designs).

Final and binding decisions have not yet been made (e.g., a budget or a schedule), because the project is in the outlining and conceptual design phase. However, most end-users and shareholders support the purpose of the project. In addition, because the local city is striving to develop the city center, they have supported initiatives such as the case project.

The project manager identified 12 stakeholder groups in the project. Figure 7 illustrates the project stakeholders’ positions in the project. The functional roles of the identified stakeholders are as follows:

1) Customer: The joint-stock property company is the customer and hence the final decision maker in the project.

2) End-customers: Residents and shareholders.

3) Main contractor: Responsible for the implementation of the designs.

4) Subcontractors: Work for the main contractor and are responsible for discrete and independent functions, such as HVAC (heating, ventilation, and air conditioning), automation, electricity, plumbing, and painting.

5) Property management: Operating the property, information management, and coordination of the stakeholders, as well as the preparation of topical matters.

Figure 6. Stakeholder classification in the health center project.

Figure 7. Stakeholder positioning in the renovation project.

6) Main designer (architect): Responsible for the design and consolidation of designs by other designers.

7) Other designers: Responsible for the design of small and discrete functions, such as structure, HVAC, electricity, automation and geological.

8) Public authorities: Representatives of local and public authorities supervise the project and may set constraints on its execution of the following: supervision of construction, planning division, fire authority, and health authority.

9) Material suppliers: Supply material and equipment, such as concrete, windows, furnishings, and modules/ elements.

10) Local residents and neighbors: May express some requirements or requests regarding the project.

11) Construction consultant: The customer does not have sufficient expertise in construction, so a consultant is needed.

12) Sponsor: Bank funds the project; it usually has no requirements or personal interest on the project.

Although stakeholder positioning is reasonable and straightforward, some factors should be discussed in detail. First, the construction site is a former estuary and therefore very unstable. This factor increases the salience and importance of the structural engineering. According to the project manager, because the structural engineer must work closely with the main designer to create viable designs, he is a key player in this project. Moreover, because the customer is not a construction professional, a consultant must be employed to as an objective advisor.

The role of the property manager is to coordinate the sharing of information concerning the project among the other stakeholders. He or she usually has the most comprehensive knowledge about the property and understanding of the actions to be carried out. He/she plays an essential role, particularly in the project initiation. Hence, the project manager is considered the property manager and part of the core group, even though the positioning does not directly point this out. The final stakeholder classification and prioritization are illustrated in Figure 8.

3.6. Results Analysis

To test its adaptability, the constructed framework was applied in two projects. The results differed slightly, which was expected and even desired. The results were also supported by literature [4,14]. The stakeholders were classified easily and rationally, based on their roles and responsibilities in the projects. Moreover, the results showed that the framework was applicable to different kind of projects, in this case, a new building and a renovated building.

The results of both cases strongly indicated that PTMs were the only stakeholders that were salient and essential, as well as having a high probability of contributing to the project. For example, in the renovation project, the structural engineer is a PTM, which was because of the unstable soil. If the soil had been stable, as in the health center project, the structural engineer would not have been a PTM. Moreover, the results showed that the customer, end-user, and main designer should always be represented in the core group. It has also noticed in the previous researches [14,45].

The role of the main contractor seemed to depend on the project delivery method. The health center project used the design-build method, in which the main contractor’s role and contribution regarding the project outcome is much bigger than in the design-bid-build method, which would be used in the renovation project. Hence, the main contractor was classified differently in the two case projects.

In both cases, the key supporting participants were stakeholders who were personally interested in the project and therefore probably had something to contribute to the project. Typical KSPs were the designers and contractors, who did not have power on project decisions, but who might have had something to contribute.

As expected, the public authorities were typical tertiary stakeholders who had power (based on the law, norms and regulations) but no personal interest in the project if the regulations were followed. The extended stakeholders were the same in both cases. The subcontractors, material suppliers, and the local residents were examples of stakeholders who were not salient and had minor roles in the project. However, in both cases, the project managers pointed out that although they were extended stakeholders, communication and information exchange with them was required in order to ensure their satisfaction.

Figure 8. Stakeholder classification in the renovation project.

The results showed that stakeholders and their classifications are always project specific. Several previous studies [e.g.,1,4,50] have showed that the non-systematic stakeholder management and stakeholder ignoring may cause major problems for the project. Thus, it can be argued that if the project had identified and managed stakeholder systematically, for example by using the framework presented in this paper or similar, most of the problems could have been avoided.

Based on the results, the main implication of this study is that the stakeholders must always be systematically identified and classified separately in each project and be managed according to the situation and stakeholders’ salience. Systematic and project-specific approach is the only way to ensure the effective RE process so that the requirements can be ultimately analyzed, prioritized and managed. Partly because of this, the interviewed project managers supported both the framework and the idea of systematic stakeholder identification and classification as long as the process and framework were logical, compact, and simple to use.

4. Conclusions

Appropriate stakeholder identification, classification, and management are crucial in order to collect and manage the stakeholder requirements, and any misjudgment in this process could lead to project failure. Therefore, the constructed framework was presented in this paper to facilitate the systematic identification, classification and management of project stakeholders in terms of the functional role of project stakeholders, salience and probability to impact/ability to contribute to the project.

The application of the framework focuses particularly on the possibilities of influencing project success and value creation during the early project phases. The framework has the potential to improve the value creation of projects by systematizing stakeholder identification, classification, prioritization, and involvement. The framework may have significant value for not only the customer but also all other stakeholders, particularly in projects that include special features. It is essential that projects be “on the rails” right from the beginning in order to avoid changes and reworking. This framework could also help to prevent conflicts among major stakeholders from involving them in the project and from facilitating the assessment of the project’s purpose, constraints, and means of execution.

This study also contributes to the theoretical understanding of the nature and characteristics of a systematic process for stakeholder prioritization and team formation. It has the potential to assist project management to involve stakeholders and exploit their expertise comprehensively in order to enhance project value creation. The study further emphasizes the view that stakeholders cannot be managed as a homogenous group. The results showed that the approach should be more active and systematically take into account the different roles and responsibilities of stakeholders.

Because the framework presented in this study may not be fully comprehensive, it needs further refinement. However, it provides a practical approach to stakeholder management and provides phases that are necessary to identify and classify the project stakeholders effectively from the initiation of the project to its completion. The framework is simple to use by practitioners because it is straightforward and provides guidelines on the aspects to consider classifying stakeholders. Moreover, it provides ideas about how to involve stakeholders more deeply, which would lead to assessing their requirements more accurately. Thus, the framework presented here may reduce the time required to form a clear understanding about the stakeholders and their contribution, leading to minimizing waste and enhancing the creation of project value. The framework points out to researchers the need for further study of suitable ways to take into account the variations in stakeholder salience during the project.

The systematic identification, classification, and ultimately involvement of stakeholders usually require additional time and resources, which might be a challenge in the application of the framework. Because of the fragmented nature and culture of the construction industry, it will probably take some time for customers and the stakeholders to realize that the benefits of using the framework and systematic stakeholder management outweigh the extra resources, time, and input required.

This study confirmed the feasibility and adaptability of the framework through two different case project and interviews. However, further research is needed to verify the framework in practice and to make further improvements in it. A future study will adapt the framework in later phases of the case projects in order to examine the evolution of stakeholder salience and probability of impact/ability to contribute. In addition, future research could apply the framework throughout an entire project, from the feasibility study to initialization, to focus on the stakeholders. Future findings could contribute to improving the framework to consider changes within the stakeholders during the project’s life-cycle. Finally, the operational aspects of the framework need to be formulated as a simple technical procedure to guide practitioners in its use.

REFERENCES

  1. K. Aaltonen, “Stakeholder Management in International Projects,” Ph.D. Thesis, Aalto University, Espoo, 2010.
  2. T. Brady, A. Davies and D. M. Gann, “Creating Value by Delivering Integrated Solutions,” International Journal of Project Management, Vol. 23, No. 5, 2005, pp. 360-365. http://dx.doi.org/10.1016/j.ijproman.2005.01.001
  3. B. Boehm and R. Ross, “Theory-W Software Project Management: Principles and Examples,” IEEE Transactions on Software Engineering, Vol. 15, No. 7, 1989, pp. 902-916. http://dx.doi.org/10.1109/32.29489
  4. S. Olander, “Stakeholder Impact Analysis in Construction Project Management,” Construction Management and Economics, Vol. 25, No. 3, 2007, pp. 277-287. http://dx.doi.org/10.1080/01446190600879125
  5. P. Dietrich, P. Eskerod, D. Dalcher and B. Sandhawalia, “The Dynamics of Collaboration in Multipartner Projects,” Project Management Journal, Vol. 41, No. 4, 2010, pp. 59-78. http://dx.doi.org/10.1002/pmj.20194
  6. L. Bourne and D. H. T. Walker “Visualizing Stakeholder Influence—Two Australian Examples,” Project Management Journal, Vol. 37, No. 1, 2006, pp. 5-21. http://dx.doi.org/10.1108/00251740510597680
  7. J. Yang, P. Q. Shen, L. Bourne, C. M. F. Ho and X. Xue, “A Typology of Operational Approaches for Stakeholder Analysis and Engagement: Findings from Hong Kong and Australia,” Construction Management and Economics, Vol. 29, No. 2, 2011, pp. 145-162. http://dx.doi.org/10.1080/01446193.2010.521759
  8. M. Latham, “Constructing the Team: Final Report on Joint Review of Procurement and Contractual Arrangements in the UK Construction Industry,” Her Majesty’s Stationery Office, London, 1994.
  9. J. M. Kamara, C. J. Anumba and N. F. O. Evbuomwan, “Establishing and Processing Client Requirements—A Key Aspect of Concurrent Engineering in Construction,” Engineering, Construction and Architectural Management, Vol. 7, No. 1, 2000, pp. 15-28. http://dx.doi.org/10.1108/eb021129
  10. C. J. Anumba, C. Baugh and M. M. A. Khalfan, “Organizational Structures to Support Concurrent Engineering in Construction,” Industrial Management and Data Systems, Vol. 102, No. 5, 2002, pp. 260-270. http://dx.doi.org/10.1108/02635570210428294
  11. E. Saarenpää, ”Rakentamisen hyvä laatu: Rakentamisen hyvän Laadun Toteutuminen Suomen Rakentamismääräyksissä,” Ph.D. Thesis, University of Oulu, Oulu, 2010.
  12. P. Lahdenperä, “Making Sense of the Multi-Party Contractual Arrangements of Project Partnering, Project Alliancing and Integrated Project Delivery,” Construction Management and Economics, Vol. 30, No. 1, 2012, pp. 57-79. http://dx.doi.org/10.1080/01446193.2011.648947
  13. R. E. Smith, A. Mossman and S. Emmitt, “Editorial: Lean and Integrated Project Delivery. Lean Construction Journal,” Lean and Integrated Project Delivery Special Issue, 2011, pp. 1-16.
  14. AIA—The American Institute of Architects, “Integrated Project Delivery A Guide,” The American Institute of Architects, Washington, DC, 2008. http://www.aia.org/contractdocs/aias077630
  15. L. Bourne, “Project Relationship Management and the Stakeholder Circle,” Ph.D. Thesis, Graduate School of Business, RMIT University, Melbourne, 2005.
  16. B. Cova and R. Salle, “Six Key Points to Merge Project Marketing into Project Marketing,” International Journal of Project Management, Vol. 23, 2005, pp. 354-359. http://dx.doi.org/10.1016/j.ijproman.2005.01.006
  17. J.R. Turner and R. Muller, “On the Nature of the Project as a Temporary Organization,” International Journal of Project Management, Vol. 21, No. 1, 2003, pp. 1-8. http://dx.doi.org/ S0263786302000200
  18. Project Management Institute, “A Guide to the Project Management Body of Knowledge,” Sylva, NC, 2004.
  19. K. Aaltonen, J. Kujala and T. Oijala, “Stakeholder Salience in Global Projects,” International Journal of Project Management, Vol. 26, No. 5, 2008, pp. 509-516. http://dx.doi.org/10.1016/j.ijproman.2008.05.004
  20. T. Donaldson and L. E. Preston, “The Stakeholder Theory of the Corporation: Concepts, Evidence, and Implications,” Academy of Management Review, Vol. 20, 1995, pp. 65- 91.
  21. T. E. Uher and M. Loosemoore, “Essentials of Construction Project Management,” A UNSW Pressbook, Sydney, 2004.
  22. D. I. Cleland, “Project Stakeholder Management,” Project Management Journal, Vol. 17, No. 4, 1986, pp. 36-44.
  23. K. Aaltonen and J. Kujala, “A Project Lifecycle Perspective on Stakeholder Influence Strategies in Global Projects,” Scandinavian Journal of Management, Vol. 26, No. 4, 2010, pp. 381-397. http://dx.doi.org/10.1016/j.scaman.2010.09.001
  24. S. Olander and A. Landin, “Evaluation of Stakeholder Influence in the Implementation of Construction Projects,” International Journal of Project Management, Vol. 23, No. 4, 2005, pp. 321-328. http://dx.doi.org/10.1016/j.ijproman.2005.02.002
  25. R. K. Mitchell, B. R. Agle and D. J. Wood, “Towards a Theory of Stakeholder Identification and Salience: Defining the Principle of Who and What Really Counts,” The Academy of Management Review, Vol. 22, No. 4, 1997, pp. 853-886.
  26. G. Johnson, K. Scholes and R. Whittington, “Exploring Corporate Strategy,” 8th Edition, Pearson Education Limited, Harlow, 2008.
  27. J. Carassus, N. Andersson, A. Kaklauskas, J. Lopes, A. Manseau, L. Ruddock and G. de Valence, “Moving from Production to Services: A Built Environment Cluster Framework,” International Journal of Strategic Property Management, Vol. 10, No. 3, 2006, pp. 169-184. http://dx.doi.org/ 10.1080/1648715X.2006.9637551
  28. G. Kotonya and I. Sommerville, “Requirements Engineering: Processes and Techniques,” John Wiley & Sons, Chichester, 1998.
  29. S. Asghar and M. Umar, “Requirement Engineering Challenges in Development of Software Applications and Selection of Customer-off-the-Shelf (COTS) Components,” International Journal of Software Engineering, Vol. 1, No. 1, 2010, pp. 32-50.
  30. A. Distanont, “Knowledge Transfer in Requirements Engineering in Collaborative Product Development,” Ph.D. Thesis, Dissertation, University of Oulu, Oulu, 2013.
  31. M. Möttönen, J. Härkönen, P. Belt, H. Haapasalo and J. Similä,” Managerial View on Design for Manufacturing,” Industrial Management & Data Systems, Vol. 109, No. 6, 2009, pp. 859-872. http://dx.doi.org/10.1108/02635570910968081
  32. J. Lehto, J. Härkönen, H. Haapasalo, P. Belt, M. Möttö- nen and P. Kuvaja, “Benefits of DfX in Requirements Engineering,” Technology and Investment, Vol. 2, No. 1, 2011, pp. 27-37. http://dx.doi.org/10.4236/ti.2011.21004
  33. A. Aapaoja, M. Herrala, A. Pekuri and H. Haapasalo, “Characteristics of and Cornerstones for Creating Integrated Teams,” International Journal of Managing Projects in Business, Vol. 6, No. 4, 2013, pp. 695-713. http://dx.doi.org/10.1108/IJMPB-09-2012-0056
  34. B. K. Baiden, A. D. F. Price and A. R. J. Dainty, “The Extent of Team Integration within Construction Projects,” International Journal of Project Management, Vol. 24, No. 1, 2006, pp. 13-23. http://dx.doi.org/10.1016/j.ijproman.2005.05.001
  35. J. Yliherva, “Organisaation Innovaatiokyvyn Johtamismalli: Innovaatiokyvyn Kehittäminen osana Johtamisjärjestelmää,” Ph.D. thesis, University of Oulu, Oulu, 2004.
  36. C. Beringer, D. Jonas and H. G. Gemünden, “Establishing Project Portfolio Management: An Exploratory Analysis of the Influence of Internal Stakeholders’ Interactions,” Project Management Journal, Vol. 43, No. 6, 2012, pp. 16-32. http://dx.doi.org/10.1002/pmj.21307
  37. J. G. Bralla, “Design for Excellence,” 1st Edition, McGrawHill, New York, 1996.
  38. Building Information Ltd, “RT 10-10387: Talonrakennushankkeen kulku,” Rakennustieto, Helsinki, 1989.
  39. R. Razali and F. Anwar, “Selecting the Right Stakeholder for Requirements Elicitation: A Systematic Approach,” Journal of Theoretical and Applied Information Technology, Vol. 33, No. 2, 2011, pp. 250-257.
  40. J. McManus, “A Stakeholder Perspective within Software Engineering Projects,” Proceedings of the International Engineering Management Conference, Singapore, 18-24 October 2004, pp. 880-884.
  41. T. R. Zenger and B. S. Lawrence, “Organizational Demography: The Differential Effects of Age and Tenure Distributions on Technical Communication,” Academy of Management Journal, Vol. 32, No. 2, 1989, pp. 353-376. http://dx.doi.org/10.2307/256366
  42. M. Hoegl, “Smaller Teams-Better Teamwork: How to Keep Project Teams Small,” Business Horizons, Vol. 48, No. 3, 2005, pp. 209-214. http://dx.doi.org/10.1016/j.bushor.2004.10.013
  43. The World Bank, “The World Bonk Participation Sourcebook,” The World Bank, Washington, D.C., 1996.
  44. B. R. Agle, R. K. Mitchell and J. A. Sonnenfeld, “Who Matters to CEOs? An Investigation of Stakeholder Attributes and Salience, Corporate Performance, and CEO Values,” Academy of Management Journal, Vol. 42, No. 5, 1999, pp. 507-525. http://dx.doi.org/10.2307/256973
  45. H. W. Ashcraft, “Negotiating an Integrated Project Delivery Agreement,” Hanson Bridgett, San Francisco, 2010.
  46. W. Lichtig, “The Integrated Agreement for Lean Project Delivery,” Construction Lawyer, Vol. 26, No. 3, 2006, pp. 1-8.
  47. J. W. Altschuld and B. R. Witkin, “From Needs Assessment to Action: Transforming Needs into Solution Strategies,” Sage Publications, Thousand Oaks, 2000.
  48. R. K. Yin, “Case study research—Design and Methods,” Sage Publications, Newbury Park, 1989.
  49. E. Kasanen, K. Lukka and A. Siitonen, “The Constructive Approach in Management Accounting Research,” Journal of Management Accounting Research, Vol. 5, 1993, pp. 243-264.
  50. A. Aapaoja, T. Kinnunen and H. Haapasalo, “Stakeholder Salience Assessment for Construction Project Initiation,” International Journal of Performance Measurement, in press.