Balancing hard and soft: A practical perspective on how project management methods are balanced in practice
Master Thesis Change Management Repair version
FEB University of Groningen
Douwe Sjoerd Sijbrandij S3114112
d.s.sijbrandij@student.rug.nl
Supervisor Thesis: Cees Reezigt Co-assessor: Hille Bruns
Date: 19-08-2019
1 _____________________________________________________________________________________ Abstract
Context: There is limited knowledge on how and why project teams balance different project management approaches in practice
Objective: This article aims to explore the processes the project teams go through when developing a project management method for a project. Additionally, this article aimed at exploring factors that may influence this process and thus the balance between hard and soft aspects.
Method: An explorative case study was conducted. Members of three project teams at three different organizations were interviewed on how they developed a PM method for their projects, and differing project management methods were combined in this PM method.
Results: This study revealed that projects are very often combining hard and soft PM methods in a project. When developing their PM method, project teams start by analyzing for hard aspects of the project, which set the frame for the project. Soft aspects are then fitted into this frame. Additionally, the incorporation of hard and soft aspects can be affected by factors apparent in the project context. For example, a commercial business environment may force the project team to integrate more hard aspects in the PM method.
Conclusion: Projects often do have hard and soft aspects, and project teams in turn do incorporate both hard and soft aspects in their PM method. During the preparation phase of a project, the focus is more on hard aspects of PM methods. Later, the attention shifts to soft aspects. Lastly, contingency factors may affect how project teams deal with certain project aspects. For example, if monitoring costs is important for the organization, the project team incorporates more hard aspects in their PM method to comply with this need.
2
Contents
Introduction 3
Theory 5
Project management & Project management approaches 5
Hard approach examples: Traditional methods 8
Soft approach example: Agile 9
Balancing Hard and Soft aspects 10
Methods 12
Research approach 12
Case site selection 13
Case description 13
Data collection 14
Interviews 14
Data analysis 15
Interview analysis 15
Case study analysis 16
Results 16
Within case analysis 17
Case 1 17
Case 2 21
Case 3 25
Cross-case analysis 26
Discussion 30
Hard and soft balance 30
Hard and soft aspects balancing 30
Contingencies influencing hard and soft 31
Managerial implications 32
Limitations 33
References 35
3
Introduction
Since the 1950s, projects have increasingly been used as a method for approaching work and achieving strategic goals in organizations (Bredillet, 2010). Projects are often used when organizations have a task that is unique and finite, meaning a type of work with a beginning and an end, and which is ¨one of a kind¨ (Munns & Bjeirmi, 1996). The idea behind the use of projects is to change organizational aspects, which in turn should lead to competitive advantage (Bredillet, 2010). However, it has been estimated that 70% of all projects fail to succeed, indicating that the project approach as such is not a guarantee for success (Burnes, 2005:2014). A possible explanation for this failure rate might be found in the project management (PM) methods that are used. PM methods are any form of structure, tools, or techniques that are used during the process of project completion (Cockburn, 2003). Examples of PM methods are the Waterfall model and Agile, which emphasize different aspects in terms of planning, room for change, and project leader´s role (Cockburn, 2003). Dependent on the aspects of a project, the PM method should incorporate hard or soft aspects, or a mix of both, to successfully manage a project (Crawford & Pollack, 2004). Selecting the wrong (mix of) PM methods for a project may result in a higher chance of project failure.
To determine what type of PM method best fits with a project, Crawford and Pollack (2004) developed a framework that consists of a hard and a soft paradigm. Projects’ aspects are qualified in either one of the paradigms. The hard paradigm is characterized by clearly defined goals, an emphasis on efficiency, and team members having a practitioner role in the project (Crawford & Pollack, 2004). Projects that fit into the soft paradigm are characterized by ambiguously defined goals, many different solutions for project issues, and team members participating in decision making throughout the project. Additionally, project goals, and how they are achieved may change throughout the project (Crawford & Pollack, 2004). Thus, the paradigms have different characteristics that indicate the use of different practices to manage a project.
However, Crawford and Pollack (2004) found that project aspects are rarely fitting all in the same paradigm, and additionally, that a single project aspect can have both hard and soft
4 PM approaches. Several other authors have emphasized the importance of balancing hard and soft project approaches as well (Boonstra, 2013; Beer & Nohria, 2000; Cristobal, 2016). Boonstra (2013) states that hard and soft interventions are usually combined, which leads to more effective project interventions. Similarly, Beer and Nohria (2000) found that combining project approaches from different paradigms is possible and effective, despite the tension that may arise from combining approaches, as long as this tension is managed well. Lastly, Cristobal (2016) advocates a multimethod approach for combining paradigms in a project approach. By analyzing project aspects from multiple theoretical perspectives, project team members are challenged to take a broader perspective on the project. This dual perspective allows to switch between the hard and soft paradigm and helps analyze in which paradigm the project aspect fits best, which possibly results in a mixed PM method for the project. Thus, a project seldom consists of just hard or soft aspects.
A limitation of the current literature on PM is that it lacks a description of how project teams arrive at their PM methods in practice. It remains unclear how project teams approach the analysis of project aspects. Additionally, despite some brief notices, there is little knowledge of what other factors may influence the balance between hard and soft aspects, and how these factors influence this balance. This thesis, therefore, will explore the following research question: Why and how do project teams balance hard and soft PM methods in their projects?
The aim of this thesis is to help explain the mechanisms that contribute to the 70% failure rate of projects (Burnes, 2004). By more in-depth investigation of this concept investigating this concept, there may be mechanisms explored that help explain the failure rate of projects, resulting in practical
implications for project teams and project managers to increase the chance of project success. Additionally, as described earlier in this section, the knowledge of how project teams balance hard and soft aspects in a PM method is very limited. There lacks a detailed description of the processes project teams go through when balancing hard and soft aspects. By studying how project teams analyze projects and design their PM method accordingly, the results of this thesis will add more detailed and relevant theoretical knowledge to the academic literature.
5
Theory
In this section, the most important theoretical concepts of this study will be reviewed and defined, so as to set out the theoretical framework for this paper. First, the concepts of projects and project
management will be defined and addressed, after which PM methodologies fitting in either the hard or soft paradigm will be discussed. The last paragraph will address what is currently known for balancing different project approaches.
Project management & Project management approaches
There is a wide variety of definitions of the term “project” in the academic literature (Packendorff, 1995; Lundin & Soderholm, 1994). In this study, the definition of Packendorff (1995) will be used. Who defines a project as “a plannable, unique task, which has to be completed in a limited timeframe, is complex in nature and subject to evaluation." Meaning that a project is a one-off, unique event that a team is doing in a certain timeframe, after which the project team may disband or start a new project.
6 Figure 1: The seven dimensions of projects (According to Crawford & Pollack, 2004)
Looking at the framework of Crawford and Pollack in Figure 1, one can recognize two
paradigms, the hard paradigm on the left-hand side, and the soft paradigm on the right-hand side. The hard paradigm of project management is regarded as more objective, using more deductive reasoning and quantitative techniques (Crawford & Pollack, 2004). Its practices emphasize efficiency and achieving pre-established goals. The process is guided by an expert, who controls for the goals to be achieved (Pollack, 2007). The soft side of the framework constitutes the soft paradigm, which is more
interpretative and inductive in nature. Techniques used are of a qualitative, explorative kind, and take the context of a phenomenon into account. The practices in the soft side are about learning,
participation, and are interested in the underlying social mechanisms of a process (Pollack, 2007). A soft approach to a project fits better when there is no clear-cut agreement as to what the end product should be. Due to the different views of stakeholders, it is a struggle to get stakeholders on the same page. The soft side of the framework allows these stakeholders to engage in discussion for the best possible solution (Atkinson, Crawford & Ward, 2006).
The framework contains seven dimensions that were identified by Crawford and Pollack as key aspects of every project (Crawford & Pollack, 2004). Based on the information available about these dimensions, projects can be analyzed in terms of hard or soft, or a combination of those.
7 analyzed based on the degree of clarity: the degree to which the goals are specified determines whether it is more of a hard or a soft project. In soft projects, goals are not completely specified and need more exploration at the start of the project. Where for hard projects the specifications are that detailed that no further exploration is needed at the start of the project.
The second dimension is “goal tangibility”. Tangible goals are a hard aspect, as they are easily measured and straightforward as to whether the goal is reached. For example, measuring the height of a building. When the goals in a project are intangible, they are classified as soft. An intangible goal is less measurable as it is often evaluated subjectively. For example, a new strategy for an organization.
The third dimension of the framework is the dimension of “success measures”. The way in which projects are evaluated is key to this dimension. For soft projects, it is hard to develop clear and
unambiguous success measures, as the evaluation is often done qualitatively. Qualitative evaluation is often done with people, who are trying to understand a phenomenon in-depth, which is done through social interaction between people who may hold a different subjective interpretation of the
phenomenon. Hard aspects of a project are characterized by the possibility of using quantitative success measures. For example, monitoring of the costs and investment of time during a project.
The fourth dimension is “project permeability”, indicating the degree to which external influences affect the project. A project is hard when the environment in which it is done is stable, has clear boundaries, and is isolated from external influences. A project tends to be soft when boundaries are vague, and the project is part of a bigger picture. For example, when it concerns multiple
departments of an organization, in which case the project is part of a bigger web of relations that all may affect the project in different ways.
The fifth dimension is the “number of solutions”. A project is hard when there are only a few options available and one solution gets chosen, which then has to be implemented accordingly. In a soft project, there is a wide variety of solutions possible, and more exploration is needed in order to find a solution that fits best with the project at hand. A soft project utilizes more participation of team members and open discussion to find a solution, whereas for a hard project the solution that is to be implemented is dictated to the project team.
8 to gather multiple perspectives on a solution. Project team members are more seen as facilitators of stakeholders, as their input is needed to deliver project objectives.
The last dimension of the framework concerns stakeholder expectations. In a soft project, gathering input and interaction with stakeholders is of higher necessity and more valued than in soft projects. There is more input required from stakeholders in a soft project, as stakeholder groups may hold different perspectives on project problems. To integrate these perspectives to achieve project success, stakeholder interaction is valued. In projects of a hard nature, stakeholder input is deemed less necessary and is valued less, people are seen as predictable and interchangeable.
Dimensions do not act in isolation of each other; all the dimensions of the framework interact with one another. For example, the dimension “Goal Clarity ” interacts with the dimensions “Success measures” and “Goal Tangibility”. If a soft approach is needed for this dimension, it is likely that the other two dimensions will be managed in a similar, soft, way. This also applies to the dimensions “Degree of participation and practitioner role”, and “Number of solutions”. If there is a single solution for the project, it is likely that project team members are expected to take on a practitioner role.
Hard approach examples: Traditional methods
In this paragraph, an example of a PM method fitting in the hard paradigm of project management will be described. This in order to create an understanding of PM methods and why these can be qualified in the hard paradigm of PM, and to link the theoretical concept of the hard paradigm with an example in practice.
Examples of PM methods that fit into the hard paradigm of project management are the
Waterfall method and the V-Model (Leau, Loo, Tham & Tan, 2012). The Waterfall model was introduced by Royce (1987) in the software development industry. It is characterized by a need for the
9 both developing and testing has to be done again. Therefore, making changes in later stages results in a very time and resource-consuming effort to get the project back on track. Both models emphasize planning, a structured approach, and control for outcomes. Additionally, they share common ground in their linear approach and focus they have on defining requirements at the beginning of a project, and following predetermined steps during the project (Nikiforova, Sukovskis & Ņikuļšins, 2008). It is these characteristics that make the Waterfall and V-model fitting into the hard side of the framework of Crawford and Pollack (2004), as the hard paradigm emphasizes efficiency, achieving pre-established goals, and an expert guiding the process (Pollack, 2007).
A downside of these approaches for project management, however, is that implementing change during the project is problematic. There is not accounted for changes during the project in terms of time and resources, and as a consequence, making changes results in delay or the need to invest extra resources (Leau, Loo, Tham & Tan, 2012). This downside was highlighted starting from the early 2000s. Changing customer demand and a more turbulent environment created a situation for the traditional, hard PM methods which they could not cope with (Fowler & Highsmith, 2001; Cohen, Lindvall & Costa, 2004; Williams & Cockburn, 2003). Due to an environment with unforeseen events that would arise, and customers changing their demands during a project, it was impossible to plan out every step of the project process (Boehm, 2002). As a consequence, hard PM methods were too rigid and inflexible to be effective in project management in that situation.
Soft approach example: Agile
In response to the more turbulent environment and changing customer demand, Agile project methods were developed in order to deal with these circumstances. Examples of Agile methods are Scrum, Lean, Extreme Programming, Feature Driven Development and Dynamic Systems Development (Cohen, Lindvall & Costa, 2003). All these approaches, in their own way, are characterized by their adaptability to changing project circumstances (Spundak, 2014).
The Agile PM methods allowed to cope with these aspects by incorporating several practices. First, Agile methods allowed project teams to be more responsive to changing circumstances by putting teams physically together and reducing the amount of documentation needed during a project
10 (Cockburn & Highsmith, 2001). Additionally, the self-steering nature of Agile project teams helps them to deal with ambiguity and speeds up the decision-making process, as teams have more freedom and responsibility to make their own decisions. The expert role of the team members in combination with the freedom to make decisions during the process allows for adaptation to changing circumstances. The project is an iterative process in which the customers are highly involved, meaning that there is a lot of interaction between project teams and their stakeholders (Cockburn & Highsmith, 2001; Hornstein, 2015).
It is due to the focus on aspects like human interaction, situational action, and collaboration during a project, that the Agile PM methods are qualified in the “soft” paradigm of project management (Crawford & Pollack, 2004; Gustavsson & Hallin, 2014; Howell, Windahl & Seidel, 2010). It are similar characteristics that are central to both the soft paradigm of Crawford and Pollack and the Agile methods described in this paragraph. For example, Crawford and Pollack (2004) describe aspects such as
participation of team members in discussion, team members taking on a facilitative role in the project, and projects emphasizing social processes (Crawford & Pollack, 2004; Pollack, 2007). Thus, Agile methods can be qualified as soft PM methods.
Balancing Hard and Soft aspects
As projects may have both hard and soft aspects that need to be managed, the PM method that is designed by a project team needs to incorporate both hard and soft aspects as well. This requires a project team to put effort into balancing different approaches, stemming from different paradigms, in the same project. However, Crawford and Pollack do not describe how project teams balance
approaches in practice. Several authors have similar findings of the use of different approaches in a single project. To provide an overview of the current state of the academic world in this respect, the theories of these authors will be discussed next.
11 interventions.
On the other hand, Beer and Nohria (2000) have developed two theories about how projects can be approached, namely Theory E and Theory O. Both theories fit within the framework of Crawford and Pollack. Theory E is the approach that matches with the hard paradigm of the framework. This theory focuses on economic aspects like maximizing shareholder value, using plans and programs for change processes and using a more top-down approach in managing the change project. The other approach, Theory O, is fitting with the soft paradigm of the framework. This approach is characterized by encouraging experimentation and the involvement of people throughout the process of the project. Additionally, people are facilitated to help them solve problems themselves during the process. Theory O is more focusing on the cultural, human aspects of change than Theory E. Beer and Nohria (2000) describe the possibility to use Theory E and O simultaneously in a project. The most straightforward approach to use both theories in one project is to sequence them. When sequencing the theories, projects usually start with Theory E rather than Theory O. This means that more hard, structural
interventions would be used first in the process, and after this, soft interventions later on in the project. The reason to start with Theory E is that people may feel betrayed when they are first involved in the project (Theory O), and later on, laid off following the hard interventions of Theory E. Another option is to use both strategies at the same time. This approach has a higher potential of achieving a sustainable competitive advantage as an organization. However, balancing the strategies in a project is risky. A bad attempt to balance them may result in bringing above the worst of both strategies, showing that there is severe tension when using both theories at the same time (Beer & Nohria, 2000). Therefore, project teams that incorporate both strategies in a project, are expected to manage this tension.
12 A critical note has to be placed when analyzing the current academic knowledge of the concept studied. Even though, the theories of Crawford and Pollack, Cristobal, Boonstra, and Beer and Nohria all do state that hard and soft can be combined in a PM method, they do not provide guidance on how the process of balancing hard and soft aspects should be approached. Thus, this research aimes to gain a more detailed understanding of the process of balancing hard and soft aspects in a PM method.
Methods
This section will describe the methodological choices made regarding this research. This will be done in four paragraphs. First, the research approach will be described. Second, the criteria for case site selection will be described, and why these criteria were chosen. Third, the approach for data collection will be shared. The section will be concluded with a description of the steps in data analysis.
Research approach
In order to answer the RQ of this paper, a qualitative research approach was adopted. Qualitative research is appropriate when a phenomenon is explored in-depth (Hancock & Algozzine, 2006). This fitted with the research question, as the nature of the research question was exploratory. There was consequently chosen for a case study as the research design, as this type of research focuses on understanding the dynamics in settings (Eisenhardt, 1989). The specific type of case study conducted was a multicase design. By studying the same phenomenon in multiple cases, the stronger internal validity of data was guaranteed for the data. This results in developing a stronger theory about the concept, which in turn contributes to more valuable theory provided for the academic world (Yin, 2009; Gustafsson, 2017). A holistic case study design was chosen, using a more general approach for analysis of concepts as a whole (Bengtsson, 1999). This fits with the purpose of this study, as the aim is to develop a theory about the concept. As there is little prior knowledge about this concept in the academic world, developing a general theory is a starting point for more in-depth research on this concept.
13 The reliability of the research was increased by developing an interview protocol for the
interviews. This protocol was followed during every interview in order to avoid problems with the attribution of the data. Using the same steps and order of questions to avoid problems with attribution of differences that were found in the data. If such a protocol was not followed, it would be unclear whether differences should be attributed to the respondent, case or the different order of questions (Golafshani, 2003).
Construct validity was ensured by documenting the chain of evidence throughout the research process. This helps to determine the level of construct validity, showing how the data led to the outcomes (Yin, 2009).
Case site selection
All the cases were found through the network of the researcher. The criteria used for selecting the cases were threefold. The replication logic used in this study impacted the criteria for selecting cases. In order to find similar cases, the criteria were aimed at selecting cases with similar characteristics.
First, the organizations needed to have a project team available for interviews. As project teams are the unit of analysis of this case study. Second, the project team needed to perform a project at the time or just had finished a project shortly before. This to ensure that the project and choices made regarding the PM methods were still "fresh" in the minds of the team members. At the start of a project, it is likely that a project team is still making choices regarding the PM method. Therefore, a project that is in the middle is more relevant to provide data for this research. Third, the subjects of the projects of the cases needed to be in the same area. Meaning that all cases should be for example about Information
Technology (IT) change. Therefore creating more similar conditions for the research, in line with the replication logic described earlier.
Case description
Using the aforementioned criteria, three cases were found in three different industries. The organizations were situated in different cities in the Netherlands.
14 overall organization employed 1500 people, the specific case site had around 300 employees. The project team studied was concerned with an ERP implementation at a housing corporation.
The second organization was an online webshop, having over 2.000.000 customers in the Netherlands. Their core business is online retailing in, amongst others, clothes, furniture, and
electronics. The project team, in this case, was supposed to complete a large internal IT change, in their warehouse, affecting several departments of the organization.
The third and last organization is a municipality situated in the north of the Netherlands. It is one of the biggest municipalities in the Netherlands, having over 3000 employees. The municipality’s tasks ranged from housing to infrastructure. The project team used from this organization was
concerned with an internal IT change, relating to purchasing goods for the office. This implementation affected several departments in the organization.
Data collection
The sources of data collection used in this study were interviews. In this paragraph will be explained how the interviews were used to gather data.
Interviews
In total, 12 interviews were conducted, four per case. The team members that were interviewed were selected through a snowball effect. This meant that the initial contact in the organization would ask project team members if they were willing to participate. General information on the interviews can be found in Appendix A, the interview protocol can be found in Appendix B.
The interviews consisted of two parts, both of a semi-structured nature. The first part of the interview was more open in nature, three open questions were asked, and probed by the interviewer. An example question is “How do you approach projects in this organization?”. The aim of this approach was to encourage the team members to share their perspectives about the concept. Prior to the interview, no specific information about the research purpose was shared, to avoid directing the answers of the participants. The first part of the interview was an unstructured type of interview, being open-ended and aimed at letting the participants share as much as possible about their experiences (Stuckey, 2013). Its focus is on understanding how the participant experienced events.
For the second part of the interviews, the questions were directed at the specific project the team members participated in. The questions for this part were derived from the framework of
15 at getting information about the project context and if, how and why project teams adapted the PM method to these aspects. An example question for the second part of the interview is “What was the goal of project X?”. The answers were probed so that the perspective of the participants could be explored in detail. Lastly, the controllability of the interviews was ensured through keeping a track of all activities regarding data collection. This included saving all different versions of the thesis, changes in the interview topics, changes in the codebook et cetera. Every version of a certain product also highlighted what was changed, and why.
Data analysis
The rest of this section will explain how data analysis of both the interviews was approached. Additionally, there will be described how the case analysis and cross-case analysis were conducted.
Interview analysis
All interviews were recorded and transcribed. To analyze the interviews, the method of the thematic analysis of Braun and Clarke was used (2006). This analysis contains six steps. The first step is to transcribe all the interviews and read the text in order to get a general impression of the data. Second, the coding process of the data starts. In this step, all data is carefully analyzed and organized in codes that represent the meaning of the data. Both inductive and deductive codes were found, see Appendix C for the codebook. The deductive codes were derived from the seven dimensions of the Framework of Crawford and Pollack (2004). Examples of these dimensions are ¨Goal clarity¨ and ¨Number of
16
Case study analysis
Both a within-case analysis and a cross-case synthesis was conducted in order to answer the research question of this study. Due to the exploratory nature of the case study, there were no theoretical propositions that the cases could be analyzed against. A cross-case analysis was conducted in order to increase the generalizability of the separate cases. The patterns that are found to be similar in multiple cases create a stronger basis to generalize the findings of this research (Yin, 2009).
Within case analysis
Conducting the within-case analysis was done by integrating all the information of the cases. Pattern matching was used to integrate the interviews and analyze data for patterns. If the patterns of the interviews would coincide, internal validity would be strengthened (Yin, 2009). In turn, this would lead to a stronger theory for the academic world. The focus was to see what patterns are identifiable of how project teams analyzed the project context and appropriated their PM method accordingly, and why teams made these choices. And how this resulted in a particular balance of PM method.
Cross-case analysis
In order to answer the RQ of this paper, the separate cases were integrated through a cross-case synthesis. A cross-case synthesis is a technique that is proposed by Yin (2009) in order to aggregate the findings of the cases. The technique used to synthesize the cases was pattern matching. By conducting a cross-case synthesis, the findings that coincide between the cases, are more robust findings. Which makes generalizing theory developed in this study easier.
Results
17 used, there is a unique code given to distinguish which case and interviewee the quote was gathered from. For example the code (2_4), of which the first number indicates the case, and the second number the interviewee.
Within case analysis
Case 1
The first project, situated at a housing corporation, was a large IT implementation of an ERP system. This project used a rapid start method, meaning that 80% of the system was standard implementation and 20% was developed tailoring the needs of the customer organization. The implementation of this sizable project, a new ERP system, lasted1,5 years.
Balancing hard and soft aspects in PM
During the preparation phase of the project, the project team started by analyzing the hard aspects of the project. After this, the project team shifted to the soft aspects and integrate aspects of both hard and soft nature in the PM method. The project team analyzed the whole project in order to make an estimation of the resources needed to complete the separate functionalities. After the analysis, the project team divided the whole project into phases. Within these phases, the project parts were divided into separate chunks that fit into two-week sprints. All of this was done in order to get an overview of the project and meet the demands of the customer, and the preferences of their own organization. The result was a detailed planning of the whole project, specifying what functionalities were to be
developed in the two-weeks sprints, eventually aiming to finish the project before the deadline.
Hard aspects
The project team developed a concrete plan for the project, including deadlines, a time path, and the specifications that developments should meet to be acceptable. Thus, there were clear parameters included for evaluating project results.
18 agreements with the customer, the reserved capacity for the project, and the level specifications of the system that the team needed to meet when delivering their project.
The project team started planning by looking at the goal of the project, and the deadline they were supposed to meet with the project, which was agreed upon between the supplying organization and the customer organization. The goal was to get a new ERP system live at the deadline that was agreed upon between the supplying organization and their customer. The project team needed a plan in order to comply with the deadlines. One of the project team members, (1_2), described the goal as follows: “Haha, yes erm: get the customer live”. This goal description can be qualified as a hard aspect, as eventually, the goal is to get the customer “live” on an agreed deadline. It is easily evaluated whether the project met this goal or not, at the set deadline there was supposed to be a working system or not. Thus, the deadline that was set for the project team served as a clear parameter for project success, creating a specific beginning and end of the project.
Next, to the goal and the deadline, the project team was supposed to deliver a system of an acceptable level of quality. Before the project, the organizations had agreed upon the level of specifications that the new system should meet to be of an acceptable level. (1_4). “Organization “Y” has, in collaboration with us, specified the minimal level of quality that the functions of the ERP system should have in order for them to accept the system”. The project team had to meet these specifications within the set time frame of the project, causing the project team to create an overview of how to develop all the desired
functionalities within the given time frame for the project.
Moreover, the project team had to deliver project results within a given cost frame, as an analysis of costs in terms of time and money is done and integrated into a contract between the organizations. (1_4) “Before the project, we have used our calculation model, which is ‘peppered’ with experience. So we know per client, per size, per process how many days we need.” The estimations of costs formed the frame for the project team to deliver project results in, thus the use of resources was constantly monitored.
Thus, these factors together caused the project team to develop a detailed planning for the project, with a clear beginning and end, specified for every part of the project when there was supposed to be
19 Soft aspects
After the project team set the frame by focusing on the hard aspects of the project, soft aspects were also integrated into the PM method.
The potential users of the customer organization were highly involved during the project to gather input for developments and give feedback on the developed functionalities. There were several options in which the ERP system could be customized for the customer organization. (1_1): “For a single question, you can give a 100 answers. But most of the time, there is a single solution that is most
efficient. That has to do with the knowledge you have about the system, you need to know the consequences it has for the follow-up process.” Thus, the project team decided to invite the potential users during the project to gather the input needed and help to choose the best solution for the part of the functionality that was developed during that sprint. In order to check whether the developments were of an acceptable level, the users were also invited to test the newly developed functionality. When the users agreed, the project team would go on to develop other parts of the functionality.
Another reason to involve users throughout the process was to avoid, or reduce, possible resistance towards the new ERP system. (1_1) “You often see that the obstacles you encounter are easy to solve. If you can remove these obstacles, you get a lot more support for your product. (……..) Because there is a lot of resistance, “I have been working this way for the past ten years, why do I have to start working in a different way?”. That is the situation you often encounter. So, by involving them, you create support.
20 Contingencies
In case 1, there were two contingencies found to be affecting the balance between hard and soft
aspects, namely, customer demands, and the internal demands of the supplying organization. These two contingencies will be explained, and there will be described how these affected the balance between hard and soft aspects.
Customer Demands
The project team had to comply with some customer demands that affected the balance between hard and soft aspects of the PM method. Examples of these demands are agreements like deadlines and investments, and the demand to work with an Agile Scrum PM method.
The customer made a large investment in terms of money and time to realize this new ERP system. Additionally, the customer organization had expiry dates for their current system. Consequently, the customer organization wanted clear-cut agreements on delivery dates while simultaneously ensuring the quality of delivered functionalities. “If you were a client, and you have a big custom project, and you invest a few tons, what would your view be? “Guys, take your time and see what you can do? Or: “I really want to know what I will get as a result in the end? What do I have in a month? What are the
functionalities I will get then”….” (1_2). This resulted in a contract, specifying the agreements between the organizations, which was highly detailed. As a consequence, the project team had to incorporate hard aspects like deadlines and resource planning to meet these agreements.
Another demand made by the customer organization was that the project team should manage the project using an Agile Scrum PM method. “In 2017 project we came into our sight, and they made the hard demand to work Agile, with Scrum as work form during the implementation”. (1_4). The project team, therefore, was pressured to incorporate soft aspects, by which Scrum was characterized, into the PM method.
21 Internal demands
The need to meet capacity and the working style of the organization were factors from the internal organization that impacted the integration of hard and soft aspects in the PM method.
For the supplying organization, it was important to plan capacity carefully throughout the project, in order to deliver results in time and within the cost frame. “In order to align development and implementation, you need a development plan, even though you use Agile. Because at some point you need to start planning and reserve capacity to deliver to software"(1_4). The project team had to comply with both a cost frame and the pressure to plan the resources of the project, causing them to plan the project in more detail beforehand. In order to meet the specified agreements, more hard aspects were incorporated in the PM method.
Additionally, the project team in this project was not dedicated to this single project. Project teams and team members also participate in other projects in other organizations. This forced the supplying organization to plan the project more carefully, to keep the day to day business smooth as well. A consequence of the set timeframe was that the project was completed by working with 20 to 25 project teams at the same time. All aspects were needed to ensure that the project finished on time. This means that the style of work of the supplying organization forced the project team to focus more on hard aspects in their PM method.
To summarize, the project team had to comply with a lot of demands from both their own organization and the customer organization. The demands were contradictory, forcing the PM method into a balance of hard and soft. The hard aspects were dominant, as the Agile Scrum PM method was adapted to fit within this frame.
Case 2
22 Balancing of hard and soft aspects in a PM method
As the project team started to determine how to manage the project, when analyzing the process the project team went through, it appears that the team started by analyzing the hard aspects of the project.
Hard aspects
The project team made a planning with a beginning and end, ensuring a firm grip on delivering project results. “From here to here is a very big chunk, so we divided it into steps, statements of work. And every statement of work is a part with a head and a tail, within the whole trajectory.” (2_4). Thus, the project team created some kind of planning for the project, specifying in which sprint which piece of the system should be developed.
However, the initial planning was without a deadline, compliant with the Agile PM method the project team used. Initially, there was no exact deadline set for the project to finish. (2_2) “We set a global goal and time path, we want to finish this by then. We continuously measure if that is achievable for us. But that is not definite.” Rather, the aim was to go live somewhere in a period of time. An exact deadline was set once the project team had confidence in setting an accurate deadline, that was communicated to the organization. Meaning that there were a clear beginning and end for the project, but the timeframe in which the project had to be completed was not set in exact. With this approach, the project was not pressured to be finished for a certain date. Rather, the content of the developments was leading over the timeframe in this case.
The goal of the project was very clear at the beginning of the project. (2_2) “The goal is: It has to be operating, so that is a very clear goal to me.” And (2_3) “I think it is a tangible goal. There has to come a new WMS system, when it is there and it works, then it is okay. Then the goal is achieved. So that is quite tangible.” The goal for the project team was to deliver a working system, which can be qualified as a hard aspect of the project, as this creates a clear point of evaluation whether the project is finished or not.
23 was a part of project success. Exceeding these costs is easily measured, creating a clear parameter for success.
Soft aspects
In order to explore the best design options for the system, there was chosen to involve the users during the project. Even though the end goal of the project was clear- getting a new working system live - there are multiple ways to design such a system, fitting users’ preferences. “The main goal is tangible, namely we have implemented the system or not. You can see that. Beneath that are choices, scope like issues, technical issues, where we are still wondering what is achievable technically and budgetary. The end state is clear, but beneath that are a 100.000 details. And how the scope is in that respect, so what is or what is not included in the scope, is what we are still finding out every day. “(2_4). Thus, the project used a softer approach by highly involving stakeholders during the process. By involving them, the users were able to deliver input to make the most informed choices regarding the design of the system.
Another reason mentioned to involve stakeholders throughout the process is to create support for the new system. “From a change management perspective, you really want to involve the users, because they will need to work with it. Therefore, you need to highly involve them” (2_2). Showing that the involvement of stakeholders was more of a choice in order to get the best result, fitting with project purposes. Therefore, the soft aspects are represented by the participation of stakeholders throughout the project.
In sum, hard aspects were more prevalent during the preparation phase of the project. There was an overview made to get a grip on when to develop what, and to ensure that the estimated costs of the project were not exceeded. After integrating these aspects, soft aspects were added to the PM method, by choosing to involve stakeholders. As there were no hard deadlines set at the start of the project, there was more freedom and time to experiment, and deliver products of the desired quality.
Contingencies Size
24 very long trajectory were in. So you do start with dividing the project into big chunks, in order to be able to plan it. And deliver these small parts, so that you can show something to your end users” (2_2). Thus, the size affects the PM method in such a way that more hard aspects are incorporated to manage the project.
Internal demands
There were two forces of the organization that the project team had to comply with, the use of an Agile PM method, and the business case that was made before the project.
PM method
The Agile PM method was supposed to be used by all project teams in the organization. Thus for this project, the project team had to work with this method wherever possible. (2_3) “We try to work Agile here, as we like to name it.” Starting from 2013, several departments have made the transition to a more flexible, agile culture, resulting in the desire from the organization to work with the Scrum method wherever possible. This culture in the organization forces the project team to use soft aspects in the PM method wherever possible.
Business case
The estimated costs of the project were, however, a factor that was impacting the integration of hard aspects in the PM method. Project costs were monitored throughout the project, as the project should not exceed the estimation. “During the project we are constantly monitoring the costs. Because we did not work with a fixed price, we have made an estimation of hours and consultancy. We constantly monitor that.” (2_2). Thus, the need to monitor costs causes the PM method to incorporate more hard aspects.
25
Case 3
The third case concerned a project team of a municipality. Their goal was to implement a new module for purchasing products using an ERP system. The goal of the ERP system was to integrate all purchases of every department into a single process, resulting in a 100% of all purchasing activities should be done using this new system. The Agile Scrum PM method was found most appropriate to manage the project, which was chosen after project aspects were analyzed.
Hard aspects
Project planning was done globally before the start of the project. There was a planning made containing what functionalities of the new module should be developed during the sprint to come. There was also no exact deadline set for the go live of the system. “When we started we had a north star, our goal. At the time we did not set an exact deadline. Eventually you come to the point that you can set a date and that is what we are striving for now.”(3_3). Thus, the project team created an overview of the project, dividing the project into chunks that fit in two week periods. There was a beginning and end, however, no exact deadline was set.
The goal of the project was to develop a new IT module that would centralize all purchasing activities of the municipality into a single process. This was a hard and tangible goal at the end of the project period. “In October, everybody will start to use it (the module). Meaning that, everyone that is concerned with purchasing, from pencils to complete bridges, does that via the new module. So in short, that goal is clear”. (3_1) The goal was given to the project team when they started to design their PM method, so the team had to adjust their PM method in concordance with this goal.
Soft aspects
In order to deliver the best result, there was chosen to involve the users of the new module during the development process. The reasons for this were twofold. First, user involvement was needed to gather unique information from them to design the system in the most effective way. “Yes, we build for them. So they will need to tell us whether we have done a good job, half way and in the end. So they are very important.”(3_2). During the process, users were asked to give input for developments and were asked to give feedback on these developments. Thus, involving users was aimed at choosing the best options during development and deliver the best project result.
26 during the process. “Well, the purchasers and contract- and category managers, you need their
involvement because you want them to be able to purchase in a good way. With less problems than at the moment. And that you are able to create support. For example, coming to a training, and that they invest energy and time in the project. That you involve them, and do not throw it over the fence when it is done.” (3_4). The project team chose to involve users in order to manage possible resistance up-front. This choice thus led to integrate this soft aspect in the PM method.
It was decided that the Agile Scrum PM method was suitable for the project, before the project team started the project. Therefore, it could have been expected that during the preparation phase of the project, the team would start with integrating soft aspects in the PM method. It was the opposite that happened, as the project team started focusing on hard aspects. The goal of the project was of hard nature, thus the project team had to comply with this. Additionally, the team started to develop a project plan to ensure an efficient approach of the project.
Contingencies Size & Duration
Size and duration of the project created the need for the project team to incorporate hard aspects in the PM method. “The impact of the project in the organization was big according to the project team. “But this project is that big and unclear that we needed to get a grip on it, for ourselves. Look: When you work “Agile” you often work in two week periods. But we could not oversee that in terms of time, what is going to happen? So we put thought into it ourselves, how much time would we need for this? And we put that into a planning, which we currently use.”(3_3). Thus, the contingency size of the project caused the project team to focus more on efficient delivery of results. In turn, that results in the integration of more hard aspects in the PM method.
Cross-case analysis
27 Similarities
Project goal, another similarity that was found between the cases was the hardness of the project goals. All project teams worked on a project that had a similar goal: getting an IT system or part of a new IT system live. For all project teams, this was a tangible and clear goal to strive for. However, how to get the best qualitative system was unclear. There was no solution that was clear as being the “best”
solution in the project. Therefore, possible solutions were explored by all project teams in their projects.
Stakeholder involvement, in all cases, the project teams chose to highly involve the users of the project. In all projects, the teams decided to invite potential users of the new functionalities during the process to gather input for the design of that part of the system. After development, the users were asked to deliver feedback on the developments, to get approval or input for improvement.
In this way, the project teams all aimed to develop the best qualitative system. High involvement was also done from a change management perspective, as by involving the users early on, the new system was expected to meet less resistance in this way.
So far, all project teams used a similar approach to manage the project, despite the projects all being unique to their organizations. In the next part of this section, the focus will be on differences between the cases and what caused these differences.
Differences
28 Agile PM method – All the project teams were using an Agile Scrum PM method for the project,
however, the motivation to use this PM method differed per case. In case 1, the customer organization had demanded during negotiations that the project was done using an Agile Scrum method. “In 2017 project we came into our sight, and they made the hard demand to work Agile, with Scrum as work form during the implementation”. (1_4). Thus, in this case, the project team was forced to incorporate as much soft aspects from the Agile method in the PM as possible.
In case 2, the Agile PM method was the standard PM method that was used for projects in the
organization. (2_1) “In 2014 our organization, just like half of the other organizations in the Netherlands, got the idea to switch to an Agile work form for projects.” Consequently the project team in this case was using this soft PM method as a starting point for the project. Thus, the culture of the organization imposed the use of this PM method on the project team.
For case 3, the project team was told to use the Agile Scrum method for the project. There was an analysis done by an internal project bureau of their organization, who found that the Agile Scrum method was fitting best with the project characteristics. “You are developing something, a week later everything could be different. Left and right is more dynamic, so Agile is more fitting. Then you’re Scrumming with each other during the project.” (3_2). Meaning that for this project, the project team was supposed to work Agile, as this was deemed fitting best with the project.
It can thus be concluded that, that influences besides project aspects, like customer demands and organizational culture. These are factors that impact the balance between hard and soft, as in the above cases, limited the freedom of the project team to analyze what is fitting for the project.
Project planning - The level of detail to which the projects were planned varied per case. In case 1, the planning was highly detailed due to deadlines that were agreed upon between the organizations, this caused the project team to plan the project in detail, in terms of delivery dates and specifications the products should then meet. In the second case, the project planning contained no hard deadlines. Rather, there was aimed for a broader period in which the project had to be finished, the deadlines were set once the project teams had more certainty to set a realistic deadline. The project team in case 3, used a general planning. The project team did make a planning, but this was basically the division of the project into workable parts during the two week sprints used during the project. Initially, there were no deadlines set before the project. It was only during the project that the project team made a
29 some extent planned the project, however, the extent of detail in terms of deadlines and resource planning varied per case.
Pressure for results – The pressure for results caused the differences in success measures, the Agile PM method, and the level of details in the project planning that were apparent in the cases. The pressure on project teams to deliver results within cost frames and timeframes created more hard aspects for project teams to comply to.
In case 1, the project team had to comply with a lot of agreements that were made before the project. For example, they were demanded to meet cost estimations, deadlines and agreed
specifications of the developments, results were evaluated based on these agreements throughout the project. Therefore, cost limits and time limits set a frame of hard aspects for the project, which caused the project team to make a very detailed planning to deliver within the given frame.
In the second case, the project team had to use an Agile Scrum PM method as well, as this was the PM method that was standard to use for projects within the organization. This project team also had to comply with certain hard aspects in the project context. In this case the project was based on a business case that indicated what benefits the project should result in, and at what costs. The cost indication that was given was an estimation, serving as a frame for the project. Another factor putting pressure on a timely delivery of project results, was the commercial environment of the organization. It was important for the project team to deliver project results as quickly as possible.
In case 3, the project team did not have to comply with specific agreements that were made before the project. There was no pressure from a customer organization or a business environment that impacted the project. The project was supposed to be done using an Agile Scrum PM method, creating a more soft frame for the project. Thus, the low need to comply with hard aspects in this projects gave the project team space to more freely determine the use of hard and/or soft aspects in their PM method.
30
Discussion
In this section, the findings of this study will be used to answer the research question. Additionally, these findings will be linked with the current academic literature, in order to put the findings in perspective. Theoretical and managerial implications will be described, as well as the limitations of the study. Lastly, directions for further research will be given, which will conclude this thesis.
Hard and soft balance
This study found that, in all cases, the project teams to some extent balance hard and soft aspects in their PM method. All project teams have to some extent integrated hard and soft aspects in their PM method. Other authors have written about
Crawford and Pollack (2004), also identified this mechanism, describing that project seldom consist of just hard or soft aspects, and that aspects also can be part of both the hard and soft paradigm simultaneously, in order to effectively manage a project. Beer and Nohria (2000) found that different project management approaches often should be used in a single project to deliver the best results. Although, they emphasize that the tension that is resultant of combining the approaches should be managed well to deliver these results. In his work on cultural change, Boonstra (2013) states that in cultural change hard and soft interventions are always combined in projects. The balance between both hard and soft depends on the situation. Lastly, Cristobal (2016) advocates a multimethod approach to analyzing project aspects to determine whether to incorporate hard or soft aspects in the PM method. By advocating this approach, Cristobal shows that hard and soft aspects can be integrated in a single PM method.
Thus, this study has found corroborating data that project teams in practice balance hard and soft aspects in a PM method, confirming the findings of the abovementioned authors.
Hard and soft aspects balancing
31 After analyzing for hard aspects, that set the frame, soft aspects where integrated in the PM method. Meaning that, soft aspects were fitted into the hard from, rather than vice versa. Thus, it were the hard aspects that were dominant in balancing hard and soft, determining the space left to
incorporate soft aspects in the PM method.
If these findings of this research are compared to findings in the field, we see that some authors acknowledge this mechanism as well.
When sequencing Theory E (hard) and Theory O (soft) approaches, Beer and Nohria (2000) encouraged to start with Theory E. They advocate this approach, as starting with soft interventions, would result in these people feeling betrayed when starting to use hard interventions. For example, involving people in early stages of the project, and later on cutting them loose, would result in negative feelings about the process.
Cristobal (2016) states that, as project contexts tend to get messier in nature, project managers should use softer aspects in a project where needed. Cristobal recognizes that projects often have a hard frame, as there are, for example, factors like organizational strategy and decision milestones project teams need to comply to. These hard aspects set the frame for the project, after which project teams can start to analyze other aspects and determine if these aspects should be managed in a hard or soft way.
Thus, this mechanism is recognized by some authors. Project teams first analyze for hard aspect, who set the frame for the PM method. After this, soft aspects are fitted into this frame. Therefore, hard aspects are found to be dominant in balancing hard and soft aspects in the PM method.
Contingencies influencing hard and soft
Studying the cases in this research identified several contingencies that seem to impact the balance between hard and soft aspects in a PM method. Examples of contingencies found in this study are the size of a project, the duration of a project, the pressure for results of a project, and the pressure to use a PM methodology during the project. These factors all impact the project aspects and the incorporation of hard and soft aspects in the PM method, as is described in the Results section of this paper.
32 the project approach. For example, Beer and Nohria (2000) acknowledge that factors like time and phase of the change influence the choice for hard or soft aspects in the PM method.
Boonstra (2013) states that factors affecting the use of hard or soft approaches is affected by the urgency and phase of the change. This study found some additional contingency factors that influence the balance between hard and soft aspects in the PM method.
Finding contingencies that determine the incorporation of hard and soft is contradictory with the mechanisms that Crawford and Pollack (2004) and Cristobal (2016) assume in their works. The
framework of Crawford and Pollack (2004) and the multimethod theory that was proposed by Cristobal (2016) both assumed that project teams had the freedom to analyze project aspects themselves. Project teams were assumed to be analyzing project aspects purely based on the nature of these aspects. In practice, however, the project teams had to comply with influences outside project control, showing that this freedom in practice can be limited. Thus, this study enriched the academic literature by discovering new factors that influence the balance in a PM method.
Managerial implications
Next to the theoretical implications, the findings have implications for practice. Based on the findings of this research, three implications will be discussed in this paragraph.
First, managers and project teams should be aware that in most projects, hard and soft aspects should be combined, to increase the chance of project success. Thus, balancing hard and soft aspects should be mixed to develop an effective PM method. This means that PM methods that are “popular” in an organization should be approached with a critical view, to assess their appropriateness for projects. Thus, managers should be mindful that a PM method should be a means to an end, instead of vice versa.
33 of successful completion of the project. Thus, it is important for managers to keep the end goal in mind, and see to what extent instructions are beneficial to deliver project results.
Third, managers should take the contingencies that were found in this research into account. When developing a PM method, managers should be aware of the impact that these contingencies may have on the incorporation of hard or soft aspects. For example, a commercial organization may require more hard aspects in a PM method, as there is more pressure for results.
Limitations
In this paragraph, limitations of this study will be described. First, the organizations that were
approached for cases were found through the network of the researcher. This meant that cases were not picked through random sampling, which may have had a negative effect on the validity and
generalizability of the results. Second, for the first case, participants for the interviews were selected by the manager of the project. This increased the chance of bias, as there could be a reason for choosing these particular employees for the research. Third, all the cases had similar PM methods that were dominant in their organizational processes, as well as all the cases were about IT initiatives that were developed and implemented over a period 1 and 2 years. Due to these similar characteristics it is harder to generalize the findings of this study to smaller projects, and organizations that more dominantly use a hard PM method in their organization.
Further research
In the last paragraph of this thesis, some suggestions for further research will be given to provide some basis to enrich the academic knowledge.
This study has found some contingencies that impacted the balance between hard and soft aspects. Looking at the works of Beer and Nohria (2000) and Boonstra (2013), limitations like time and phase of change are recognized to impact the incorporation of hard or soft aspects in the PM method. Thus, this study has broadened the knowledge in the literature field by finding more contingencies. In future research it may be interesting to explore whether there are more contingencies affecting the balance between aspects.
34 the overall impact of contingencies on PM methods. In their articles, Crawford and Pollack (2004) and Cristobal (2016) seem to assume that PM methods are designed purely on project aspects. In this study, factors outside project influence were found to impact the balance between hard and soft aspects. Further research should direct attention to what extent project teams have the freedom to analyze project aspects themselves, and to what extent factors outside the project limit this freedom.
Lastly, all projects studied were about an IT subject, and had a similar size and duration. By studying projects that have different characteristics, the current knowledge could be expanded, as projects with different characteristics there may be different mechanisms found that impact the balance between hard and soft.
35
References
Atkinson, R., Crawford, L., & Ward, S. (2006). Fundamental uncertainties in projects and the scope of
project management. International journal of project management, 24(8), 687-698
Balaji, S., & Murugaiyan, M. S. (2012). Waterfall vs. V-Model vs. Agile: A comparative study on SDLC.
International Journal of Information Technology and Business Management, 2(1), 26-30.
Beer, M., & Nohria, N. (2000). Cracking the code of change. HBR’s 10 must reads on change, 78(3),
133-141.
Bengtsson, P. (1999). Multiple case studies–not just more data points. Term paper in graduate course in
Research Methodology. Publisher Unknown, 1-9.
Boehm, B. (2002). Get ready for agile methods, with care. Computer, 35(1), 64-69.
Boonstra, J.J. (2013) Conclusion on interventions for cultural change, in: Cultural change and leadership
in organizations: A practical guide to successful organizational change. ch. 23. Chicester:
Wiley.http://www.jaapboonstra.nl/wp- content/uploads/2013/01/ Interventions-for-cultural-
change.pdf
Braun, V., & Clarke, V. (2006). Using thematic analysis in psychology. Qualitative research in psychology, 3(2), 77-101.
Bredillet, C. N. (2010). Blowing hot and cold on project management. Project Management Journal,
41(3), 4-20.
Burnes, B. (2005). Complexity theories and organizational change. International journal of management
reviews, 7(2), 73-90.
36 Cockburn, A. (2003). People and methodologies in software development. Faculty of Mathematics and
Natural Sciences.
Cockburn, A., & Highsmith, J. (2001). Agile software development, the people factor. Computer, 34(11),
131-133.
Cohen, D., Lindvall, M., & Costa, P. (2004). An introduction to agile methods. Advances in computers,
62(03), 1-66.
Crawford, L, & Pollack, J. (2004) Hard and soft projects: a framework for analysis. International Journal
of Project Management, 22, 645-653.
Eisenhardt, K.M. (1989). Building theories from case study research. Academy of Management Review,
14(4), 532- 550.
Fowler, M., & Highsmith, J. (2001). The agile manifesto. Software Development, 9(8), 28-35.
Golafshani, N. (2003). Understanding reliability and validity in qualitative research. The qualitative
report, 8(4), 597-606.
Gustafsson, J. (2017). Single case studies vs. multiple case studies: A comparative study.
Gustavsson, T. K., & Hallin, A. (2014). Rethinking dichotomization: A critical perspective on the use of
“hard” and “soft” in project management research. International Journal of Project Management, 32(4),
568-577.
Hancock, D. R., & Algozzine, B. (2016). Doing case study research: A practical guide for beginning
researchers. Teachers College Press.
Hornstein, H. A. (2015). The integration of project management and organizational change management
