Department of Real Estate and Construction Management Thesis no. 299

Real Estate Development and Financial Services Master of Science, 30 credits

Architectural Design and Construction Project Management

Author: Supervisor: Derya Bahceci Linnea Holmgren Stockholm 2014

Tina Karrbom Gustavsson

Agile perspectives in construction projects

– How to improve efficiency in the design phase

II

Master of Science thesis

Title Agile perspectives in construction projects – How to improve efficiency in

the design phase

Authors: Derya Bahceci & Linnea Holmgren

Department: Real Estate and Construction Management

Master Thesis number: 299

Supervisor: Tina Karrbom Gustavsson

Keywords: Construction Project Management, Traditional Project Management,

Agile Project Management, Design phase, Program-stage, System-stage, Efficiency

III

Abstract The long project durations in construction projects usually includes changes. From the initial project

idea to the end of the design phase, the requirements and expectations of the project tends to change.

There could be many reasons for this, such as new or more thorough specifications from the client, or

perhaps, changed factors in the surrounding. A problem is that changes might have consequences in

terms of added costs, extended time and transformed scope. Hence, unwanted changes often mean that

the resources are used in an inefficient way since re-work has to be done. This often affects the client

satisfaction negatively since, as earlier mentioned, costs might increase, time might be extended or

scope could have to be changed.

The aim to work efficiently in the design phase of construction projects lays the foundation for this

report. More specifically, this master thesis looks into how agile methodologies can make the

program- and system-stages, of a construction project, more efficient and thereby increase the client

satisfaction.

Agile methodologies could be described as “the ability to rapidly respond to change”. The agile

methodologies are about realizing that projects are prone to changes because of changing

circumstances. It is about realizing that we develop our knowledge and understanding of a project as it

proceeds, which means that we must adapt to new information as it is gained. In one single word,

agility is all about flexibility.

The agile methodologies are suited for projects with high complexity and uncertainty. It is also

suitable to work in agile ways when a project has unclear specifications, changing situations, complex

project goals and results needs to be achieved continually or early in the project process

Conclusions that have emerged through this master thesis are that agile methodologies could improve

efficiency in the program- and system-stages. This can be possible by dividing each stage into shorter

cycles. In this way, the stages would become more manageable since it is easier to get an overview of

the closest upcoming work. Shorter cycles can also make it easier to keep the goal focus through the

whole project process since more frequent reconciliations are being held.

Working in shorter cycles gives the opportunity to have more frequent reconciliations with the client

as well as with the project team. Reconciliations are held in the beginning and in the end of each cycle.

This means that the client gets the opportunity to express wishes and requirements during the

reconciliations which results in possibilities to make eventual changes throughout the stage. This

prevents major changes from occurring in the end of the stage which means that resources can be used

more efficiently. Also, when changes are made continually instead of after-the-fact, the costs of

making unwanted changes becomes decreased. The client involvement and the agile approach could

for these reasons affect the client satisfaction positively.

IV

Sammanfattning De långa projekttiderna i byggprojekt innebär ofta att förändringar måste genomföras. Krav och

förväntningar på projektet ändras ofta från den initiala projektidén till slutet av projekteringsskedet.

Detta kan ha flera orsaker, såsom till exempel nya eller mer detaljerade specifikationer från

beställaren, eller också förändringar i omgivningen. Ett problem med dessa oönskade

förändringsarbeten är att de oftast resulterar i negativa konsekvenser såsom ökade kostnader,

förseningar och förändrad omfattning av projektet. Förändringar innebär att omarbetningar måste

göras, vilket i sin tur oftast innebär att resurser inte används på ett effektivt sätt. Ett ineffektivt

resursanvändande påverkar ofta även kundnöjdheten negativt eftersom att projektet resulterar i högre

kostnader, förlängd tidsplan eller en förändrad omfattning.

Målet att arbeta effektivt i projekteringsskedet i byggprojekt ligger till grund för detta examensarbete.

Denna studie handlar mer specifikt om hur agila projektmetoder kan göra program- och systemskedet i

byggprojekt mer effektivt och därmed även öka kundnyttan.

Agila projektmetoder kan beskrivas som ”förmågan att snabbt kunna anpassa sig till förändring” och

handlar om att inse att projekt ofta förändras på grund av förändrade omständigheter i omgivningen.

Det handlar dessutom om att förstå att kunskapen och förståelsen för projekt ökar under tiden som ett

projekt fortlöper, vilket innebär man måste anpassa sig till nya de nya omständigheterna och

kunskaperna. Agila projektmetoder kan kortfattat beskrivas med ordet flexibilitet.

Agila projektmetoder är lämpade för komplexa projekt med stor osäkerhet. Det är även passande att

arbeta agilt i projekt som har vaga specifikationer, förändrande omständigheter, komplexa projektmål

och när resultat måste uppnås kontinuerligt eller tidigt i projektprocessen.

Slutsatser av examensarbetet är att agila projektmetoder kan öka effektiviteten i program- och

systemskedet. Ökad effektivitet möjliggörs genom att dela in projektet i kortare cykler. Detta gör att

man får en bättre överblick över det skedet man arbetar i, och därmed får man även en tydligare bild

över det närmast kommande arbetet. Kortare cykler underlättar även att behålla målfokus genom hela

projektprocessen i och med att tätare avstämningar hålls.

Genom att arbeta i kortare cykler ges även möjligheten att ha tätare avstämningar med kund, men även

tätare avstämningar inom projektgruppen möjliggörs. Detta eftersom att avstämningar hålls både i

början och slutet av cyklerna. I sin tur innebär detta att beställaren har större möjlighet att uttrycka sina

önskemål, vilket resulterar i möjligheten att göra eventuella förändringar under skedenas gång istället

för att låta dessa utvecklas till större förändringar (omarbetningar) som måste genomföras i slutet av

skedena. När förändringar utförs kontinuerligt minskar även kostnaden för att genomföra de oönskade

förändringarna. Det ökade kundengagemanget och de agila arbetssätten i stort tycks därmed kunna öka

kundnöjdheten i projekten.

V

Acknowledgements This master thesis of 30 ECTS is conducted at the department of Real Estate and Construction

Management at the Royal Institute of Technology in Stockholm, Sweden. The work has been

performed in collaboration with the global consultancy firm WSP, the department of Management.

The work started in January 2014 and was finished in June 2014.

The authors had the aim to investigate how construction projects could be managed more efficiently

and the topic “agile methodologies” was suggested by the authors. The specific research question

however, was formulated together with the supervisor at the consultancy firm WSP Management,

because the authors wanted to write about something that was of importance for the company.

The process during the thesis has been interesting because the authors only held little knowledge about

agile methodologies in the beginning of the thesis. By going from a rather low level of knowledge to a

deep understanding of the topic has resulted in an extensive process and development in the thesis.

This is because the direction of the topic has changed as the authors have gained more knowledge.

When looking back, this has resulted in both positive and negative aspects. However, since agile

methodologies is a fairly new subject with little research within the construction industry, there was no

other option.

First and foremost, we would like to thank our supervisor at WSP Management, Lars Hansson, for

being involved and engaged during the whole process. We are grateful that you have taken your time

and have been committed during the process.

We would also like to thank our supervisor at the Royal Institute of Technology, docent Tina Karrbom

Gustvasson. You have been a source of inspiration and we highly value your input and ideas to this

thesis.

Last but not least, we would like to thank all the interviewees, who all are project managers and client

design managers at WSP Management. Thank you for taking your time, the interviews have been of

large importance for the results of the master thesis.

Stockholm, June 2014

Derya Bahceci and Linnea Holmgren

VI

Table of contents 1. Introduction ....................................................................................................................................... 1

1.1 Background ................................................................................................................................... 1

1.2 Theoretical framework .................................................................................................................. 2

1.3 Problem ......................................................................................................................................... 3

1.3.1 Why do major changes occur in the end of the program- and system-stages? ...................... 4

1.4 Purpose .......................................................................................................................................... 4

1.5 Research question .......................................................................................................................... 5

1.6 Delimitation ................................................................................................................................... 5

1.7 Disposition..................................................................................................................................... 5

2. Method ................................................................................................................................................ 6

2.1 Information collection ................................................................................................................... 6

2.2 Interview procedure ....................................................................................................................... 7

2.2.1 Interview with experts............................................................................................................. 7

2.3 Analysis of interviews and suggested efficiency improvements ................................................... 8

2.4 Validity, reliability and replicability ............................................................................................. 8

2.5 Possible biases ............................................................................................................................... 8

2.6 Comments on the chosen method .................................................................................................. 9

3. Literature review ............................................................................................................................. 10

3.1 Client ........................................................................................................................................... 10

3.2 Client satisfaction ........................................................................................................................ 10

3.2.1 Client satisfaction in the construction industry .................................................................... 11

3.3 Traditional project management .................................................................................................. 12

3.3.1 What is traditional project management? ............................................................................ 12

3.3.2 Traditional processes ........................................................................................................... 12

3.3.3 Challenges with traditional project management ................................................................ 16

3.4 Agile Project Management .......................................................................................................... 16

3.4.1 What is agile project management? ..................................................................................... 17

3.4.2 The agile manifesto............................................................................................................... 18

3.4.3 Agile characteristics ............................................................................................................. 18

3.4.4 Challenges with agile project management.......................................................................... 23

4. Empirical findings ........................................................................................................................... 25

4.1 Facts about the case study ........................................................................................................... 25

4.1.1 Coordination challenge ........................................................................................................ 25

4.1.2 Train design unknown .......................................................................................................... 25

VII

4.1.3 Many parties involved .......................................................................................................... 26

4.2 Collected answers ........................................................................................................................ 26

4.2.1 Communication .................................................................................................................... 26

4.2.2 Project planning ................................................................................................................... 27

4.2.3 Project success factors ......................................................................................................... 28

4.2.4 Documentation ..................................................................................................................... 29

4.2.5 Time, cost and quality........................................................................................................... 29

5. Analysis ............................................................................................................................................ 31

5.1 General findings .......................................................................................................................... 31

5.2 The four chosen factors ............................................................................................................... 31

5.2.1 Planning in short cycles ....................................................................................................... 31

5.2.2 Reconciliations ..................................................................................................................... 32

5.2.3 Welcome changes ................................................................................................................. 33

5.2.4 Project team collaboration ................................................................................................... 34

5.3 Challenges with agile methodologies in construction projects ................................................... 35

5.3.1 Agile literature is beautified ................................................................................................. 35

5.3.2 Time ...................................................................................................................................... 36

5.3.3 Documentation ..................................................................................................................... 36

6. Conclusion ........................................................................................................................................ 37

6.1 Question ...................................................................................................................................... 37

6.2 Answers ....................................................................................................................................... 37

6.2.1 Shorter cycles ....................................................................................................................... 37

6.2.2 Reconciliations ..................................................................................................................... 37

7. Future research areas ..................................................................................................................... 39

8. References ........................................................................................................................................ 40

8.1 Literature ..................................................................................................................................... 40

8.2 Internet ........................................................................................................................................ 40

8.3 Oral .............................................................................................................................................. 41

8.4 Figures ......................................................................................................................................... 41

Table of figures Figure 1: Construction project process overview, showing the design phase separately. ....................... 2

Figure 2: The possibility to influence the project is large early in the project, the cost of making

changes increases with time. ................................................................................................................... 2

VIII

Figure 3: Cost-uncertainty curve showing that uncertainty in projects reduces with time, costs for

making changes increases with time ....................................................................................................... 4

Figure 4: The construction project process in the project managers guidelines. ................................... 13

Figure 5: Practices of lean and agile usually differ even if they have shared principles/philosophy ... 17

Figure 6: Time is fixed in agile methodologies; scope could vary within the given resources ............. 22

Figure 7: The organizational structure of case study project ................................................................. 25

1

1. Introduction This chapter gives an introduction to the context of this master thesis by presenting background

information, theoretical framework, problem and purpose. Thereafter, the research questions as well

as delimitations follow. Finally, the disposition of the report is presented in order to give the reader

an overview of the study.

1.1 Background Construction project managers need to lead and manage their projects throughout the whole project

life-cycle. This is hence not an easy task because construction projects are large, involves many

disciplines and includes high-risks. Also, construction projects are often unpredictable because of their

one-time nature. For these reasons, among all, construction projects require flexible management and

leadership to respond to changes that occurs along the way (Gould & Joyce, 2009).

To enhance the challenging coordination, planning and control-work of construction projects, it is

important to have efficient methodologies which take into consideration that the projects are often

initiated under large uncertainties (Winch, 2010). The term “uncertainty” includes both “complexity”

and “predictability”. Complexity means that information is available but too costly or time-consuming

to collect and analyze. Predictability means that the past is not a reliable guide to the future because

the future is by definition unknowable whilst past experience is a valuable guide to the future

In the beginning of the 1990’s, software developers within the IT-industry were discontent with the

current, traditional project management methodologies. They meant that traditional methodologies

assume that the future is predictable because plans are made without taking into consideration that

unwanted changes might occur. They meant that the assumption of predictability is problematic

because it implies that resources, money, time and creativity are used according to old plans, this in

turn leads to waste (Opelt, et al., 2013). Further, the software developers thought that it is hard for the

clients and the project team to know exactly all requirements in the initiation of a project (Gustavsson,

2007). According to these software developers, the traditional processes are blocking the way for new

requirements. This is clearly a problem in a changing environment such as construction projects

(Opelt, et al., 2013).

Due to these dissatisfactions, the project managers came up with a new, more flexible approach to

project management, called “agile methodologies”. In contrast to the traditional methodologies, the

agile methodologies take into consideration that the future is impossible to predict. Proponents of agile

methodologies believe that it can be more suitable for managing projects because it includes

approaches to managing changes (Gustavsson, 2010).

The design phase of construction projects can be seen as a project on its own, consisting of three

stages, those are the program-, system- and detailed design-stages. The main focus of this report lies in

the first two steps of the design phase, namely the program- and system-stages, see Figure 1.

2

Figure 1: Construction project process overview, showing the design phase separately.

The reason for focusing on the design phase is that the possibility to influence a project is largest in

the beginning of the project, and the possibility decreases as the project proceeds, see Figure 2.

Figure 2: The possibility to influence the project is large early in the project, the cost of making changes increases with time

(Rocque, 2013).

1.2 Theoretical framework The aim to work efficiently in the planning stages of construction projects lays the foundation for this

report. More specifically, this study looks into how project management in terms of resources (money,

time and scope) can be more efficiently used within the often uncertain, program- and system-stages.

This focus has been chosen in collaboration with Lars Hansson, team leader for project managers at

WSP Management. The subject was chosen due to dissatisfaction about situations where resources

3

were used inefficiently. This was considered due to changes that occurred continuously, but old

methodologies did not support continuously changing project settings. This lead to situations where

major changes had to be made to the design work, further explained in section 1.3.

Traditional and agile management methodologies are presented in this master thesis and have been

investigated with regard to efficiency. By efficiency, the authors refer to fewer changes in the end of

the program and system-stages. In other words, “efficiency” is the theoretical framework used while

looking into the two project management methodologies. This framework has been chosen because

traditional project management methodologies has been claimed to be inefficient (Gustavsson, 2007).

Also, this subject was chosen because the discussion of more efficient management within

construction projects has gotten a large focus within the industry during the last years. Finally, this

framework was chosen because WSP Management sees potential for improvements in current

methodologies. The consultancy firm is interested in finding and implementing new methodologies for

improved efficiency which means that findings of this study could create value in the real business

world.

To further clarify the theoretical framework of this thesis, the definition of efficiency is presented as

follows (Investopedia US, 2014): “A level of performance that describes a process that uses the lowest

amount of inputs to create the greatest amount of outputs. Efficiency relates to the use of all inputs in

producing any given output, including personal time and energy. “

1.3 Problem The long project durations in construction projects usually mean that changes are made to the initial

plans. This is because the requirements and expectations for the project tend to change from the initial

project idea to the end of the design phase. There could be many reasons for this, such as new or more

thorough specifications from the client, or perhaps, changed factors in the surrounding. However, the

changes often occur as a result of the non-predictable future. A problem is that changes also might

have consequences in terms of added costs, extended time and transformed scope. Or it can also be

seen that the problem is that the processes does not support making changes. Hence, unwanted

changes could mean that the resources are used in an inefficient way since re-work has to be done. If

this is the case, this often affects the client satisfaction negatively since costs might increase, time

might be extended or scope might have to be changed.

In general, the later changes occur in a project, the more costly will the changes be, and the more

inefficient will the use of resources be spent (Project Management Institute, 2013). This is because the

re-work required involves changing plans, trade-offs and to make sure that the different parties are

agreed before proceeding with the project. This in turn implies higher costs and often also leads to

extended project time. In order to minimize the inefficient resource-usage in the program- and system-

stages of construction projects, new ways of working, such as agile methodologies, needs to be

investigated in the search for improvements.

4

Figure 3: Cost-uncertainty curve showing that uncertainty in projects reduces with time, costs for making changes increases

with time (Project Management Institute, 2013)

1.3.1 Why do major changes occur in the end of the program- and system-stages? To be able to understand if the major changes that occurs in the end of the program- and system-stages

could be avoided or decreased, it needs to be clarified why those changes occurs, to begin with.

One reason for major changes to occur in the end of the program- and system-stages is that the project

has been started when there were large uncertainties about requirements and future circumstances of

the project. However, uncertainties decrease as the project proceeds and changes has to be made

according to new requirements, wishes and circumstances. An interviewed project manager at WSP

Management explains that major unwanted changes occurs because the teams are working towards a

scope and goal that the project cannot afford and does not have time to deal with. This happens

because the project is not specified enough when the project team starts working with it, which means

that the project team works towards the wrong goals from the initiation of the project. It could also be

due to the processes that do not support changes to be made during the project. The uncertainties in the

initiation of the project imply that many parts of the project need to be reworked later on. Furthermore,

this seems to happen because not all decisions can be taken in the beginning of a project, some

decisions have to be taken when more knowledge about the project has been gained.

A project manager at WSP gave an example of a project where an important decision was taken in the

end of the system-stage. The decision was to decrease the project budget significantly, but to keep the

same scope and the same time-plan. This implied that the project team had to rework the plans and see

what could be cut down on, to make the project fit within the new, smaller, budget. However, when

the major unwanted changes occur in the end of the program- or system-stages, they often cause

delays. Several project managers have told that they expect major changes to occur in the end of the

program- or system-stages, and therefore they include re-working time in their time-plans. When this

buffer time is not included, the major changes causes time-pressure in the project and the deliveries

sometimes even becomes less well-performed. The major changes that occur in the end of the

program- and system-stages also costs money to adjust (Hansson, 2014).

1.4 Purpose The purpose of this master thesis is to investigate if increased efficiency can be attained by using agile

methodologies in the program- and system-stages of construction projects. Efficiency is referred to in

terms of less major changes in the end of these stages.

5

1.5 Research question The investigated research question in this report is the following:

How could agile methodologies affect the amount of major unwanted changes in the end of

the program- and system-stages in construction projects, in order to increase efficiency?

Also, the following sub-question has been investigated:

How could agile methodologies in construction project management affect the client

satisfaction?

1.6 Delimitation Since the process in construction projects includes many phases and is very comprehensive, this report

is limited to only focus on the program- and system-stages. The purpose with this limitation is to entail

specific, rather than general, conclusions and recommendations for WSP Management as well as for

other project managers within the industry. It also aims to contribute to project management theory.

Furthermore, focusing on these stages gives the largest possibilities to influence and affect the project

as a whole in the early phases, see Figure 2.

In order to focus on a more general level of project methodologies, another delimitation is to focus on

methodologies in general rather than on practical tools. Finally, the authors refers to “efficiency” only

in terms of less changes in the end of the program -and system-stages and not any other aspects of

efficiency.

1.7 Disposition Firstly, the chosen research method is described and presents how the work has been carried out.

Secondly, the literature review describes the client’s role in construction projects and also explains

what is meant by the “client satisfaction”. Further, the literature review presents traditional- and agile

project methodologies to provide an understanding of what characterizes these two methodologies.

Thereafter, the empirical framework is presented. This includes the results of the interviews with

regard to an efficient use of resources. In this part, a case study project is also presented to give the

reader an example of a construction project and what complexities it includes, and also to understand

where there are potential for efficiency improvements within construction projects.

The analysis chapter follows after the empirical chapter. In the analysis, the literature and empirical

findings are elaborated upon and suggestions of how efficiency can be increased are presented.

Thereafter conclusions are presented. Those include the answers to the research question stated in

section 1.5. Finally, recommendations are given to WSP as well as to other students or organizations

who would like to do further research on this subject.

6

2. Method The working method, which has been a qualitative research, has followed three steps during the

project work.

The first step has been to carry out an information collection, i.e. a literature study. The traditional

and agile methodologies are studied to develop an understanding of their characteristics and

differences. Also it has been looked into how agile methodologies are applied within IT-projects

today, since that is the industry where the methodologies developed from.

The second step regards the interview process where interviews have been conducted with project

managers and client design manager within the construction industry. The authors also made a case

study in order to give an example of a construction project and its complexities. Interviews were held

with managers of the case study as well as with managers from other construction projects. The third

step comprises an analysis of the literature review and the interviews, thereafter follows

recommendations regarding efficiency improvements for WSP.

Working method:

1. Information collection

2. Interview process

3. Analysis of interviews and suggested efficiency improvements

2.1 Information collection An information collection in terms of a literature study has been carried out in order to deepen the

knowledge within the topic of this master thesis.

The authors’ presents the literature study by describing the current, traditional, project management

methodologies and further by presenting the more modern, agile project management methodologies.

Agile methodologies were studied because earlier research suggests that agility could handle

uncertainty in projects, this report aims to investigate this further and has focused specifically on the

program- and system-stages of the design phase.

The literature study has been crucial for the thesis since a deeper knowledge of agile methodologies

was created by embracing information through books, former master theses and scientific papers.

Furthermore, material collected from WSP has also been studied in order to get an understanding for

their current working methods and to get descriptions of concepts.

Other areas that have been studied besides agile project management are traditional project

management and client satisfaction. These areas also belongs to the core areas of this thesis, even

though the main focus has been put on agile project management.

The information in the literature study was mainly gathered through databases such as Google Scholar

and KTH Primo, since these webpages only provides scientific reports and hence, accurate and reliable

secondary data (Bhattacherjee 2012). The reliability of the collected sources has been investigated by

taking into account if possible biases were identified. Unreliable or inaccurate sources have been

eliminated.

Keywords that were used during the searches in databases were among others “agile project

management”, “agile project management in construction”, “agile manifesto”, “lean construction

7

management”, “traditional project management” and “customer satisfaction”. The literature study

resulted in a well-developed and deepened knowledge about the concepts mentioned above. Keywords

like “agile project management in construction” on the other hand only provided a limited number of

scientific reports. This indicates that agile methods within construction still are a rather new topic with

little research. Therefore, literature about agile project management in the software industry has been

studied to a larger extent.

2.2 Interview procedure In order to be able to conduct as good results as possible from the interviews, the authors had some

factors in mind before and during the execution of the interviews (Bhattacherjee 2012). For example,

interview material was not sent to the interviewees in beforehand, since the authors’ advocates

spontaneous answers. The risk of letting the interviewees see the questions in beforehand is that

answers might be prepared by the interviewee which results in less honest answers. Hence, an

incorrect picture might be the result. Due to the fact that the interviewees could not read the questions

in beforehand, it was important to clearly explain what was being meant by each question during the

interviews, so there would be no misunderstandings.

In order to reduce the risk of information getting lost, the interviews was recorded (Ekholm &

Fransson, 2013). The result of this was positive since both interviewers could focus on what the

interviewee said, rather than taking notes. Recording the interviews also enhanced the process of

analyzing the interviews. It also increased the possibility of transcribing the interviews correctly.

What the authors have had in mind when reproducing the interviews is that face expressions are

getting lost when listening to the records.

2.2.1 Interview with experts In order to know how project managers and client design managers work today, interviews have been

carried out. The answers have been compared to the literature study of traditional and agile project

methodologies in order to see the possible similarities and differences between literature and practice.

Moreover, by studying their current ways of working, the authors tried to find possibilities for

improvements by using agile methodologies in the program- and system-stages instead of working

with traditional methodologies. Improvements were searched for in terms of possibilities to decrease

the number of major changes that are unwanted and often appears in the end of those stages.

The interviews were carried out when the literature study was completed and when more information

about agile methodologies was gained (Ekholm & Fransson, 2013). The interviewees were chosen

from recommendations from the supervisor at WSP. It was assumed that the best way of finding

improvement-possibilities is to interview experienced professionals who are working in construction

projects, and thereby finding possibilities of efficiency improvements. The interviewees varied in age

and gender which have contributed to a more dynamic input to the thesis. There is however a risk that

WSP chose interviewees that have the same opinions. This would in that case mean that the interviews

are biased (Bryman, 2012). This has improved the process of analyzing, comparing and drawing

conclusions from the interviews.

The sampling strategy for the interviews was with a sampling frame of seven persons. Some

spontaneous interviews with project managers were held for additional questions that arouse, but those

were not counted as part of the planned interviews. All interviewees are professional employees and

works as project- and client design managers in the program- and system-stage of different

construction projects at WSP Management.

8

The sampling-technique used was a non-probability sampling since the interviewees not were chosen

randomly (Bryman, 2012). The interviews were semi-structured which means that the questions do not

have to be asked in a pre-decided order and follow-up questions are welcomed. This type of interviews

is similar to regular discussions, rather than strict interviews, and is suitable when an open discussion

wants to be achieved.

Since this master thesis is qualitative study, an operationalization of the collected data had to be done

in order to be able to measure and compare results from the interviews. This is because results were

mainly of “soft values” which usually are hard to compare and draw general conclusion from.

Therefore, in this study, the information and experience of the project managers has been regarded as a

measure of how traditional methodologies work today and what possibilities for improvements there

seems to be.

2.3 Analysis of interviews and suggested efficiency improvements The analysis of the interviews focused on investigating if agile methodologies could avoid or decrease

the scope of the major changes that often occur in the end of the program- and system-stages in

construction projects. Also, the interviews was conducted to understand how project managers works

today so that possibilities for improvements could be identified.

The authors have suggested efficiency improvements for project managers who work in the program-

and system-stages. These recommendations are based on the literature review, the interviews with

project managers at WSP, and the frequent meetings with the supervisor from WSP.

2.4 Validity, reliability and replicability

In order to conduct a reliable study, the authors have avoided being subjective and asking ambiguous

questions (Bryman, 2012). The researchers aimed at conducting a study with a high level of reliability,

which means that the study should be consistent. This was of high importance since a high level of

reliability implicates a trustworthy result. Additionally, the level of validity has been controlled by

ensuring that the literature was up to date and trustworthy.

Finally, a high level of replicability results in a higher degree of trustworthiness which is desirable

(Bryman, 2012). Replicability is connected to reliability and means that the study is consistent and that

the same results would be generated if the same study was performed all over again. The researchers

have accomplished this by using reliable resources (only academic and professional), interviewing

respondents with sufficient knowledge, using proper referencing and by being objective throughout

the whole process.

2.5 Possible biases The construction project managers and client design managers from WSP, who participated in the

interviews, are working as consultants for different projects and for different clients. The various

projects and clients they are working for has given a more heterogenic input to the research and helped

the authors to understand different aspects of construction projects (Bryman, 2012).

The construction industry is often considered to be conservative and the authors were aware of the risk

for bias when gaining input from project managers. Some expressed clearly that they distrust new

project methodologies. Also, input from project managers who have opposite ideas could have led to

bias i.e. project managers’ who believes in using a new methodology within their projects (Bryman,

2012). To avoid these sorts of biases, it has been important that the authors kept these possibilities in

mind and always thought of the input with the theoretical framework in mind.

9

Yet another possible bias was the strong will of the authors to come up with a result that the

consultancy firm expects or desire (Bryman, 2012). This bias was important to consider thoroughly

from the beginning of the project in order to not create any hypotheses about relations between

variables that are not scientifically proven. An advantage has also been that the two authors have been

able to warn each other if any type of biases seemed to occur.

A limitation was that the amount of time for the research was not long enough to investigate the topic

further and neither to interview more than a few project- and client design managers. Therefore, the

generalizability of the study is discussable. The generalizability of this thesis might not be for the

whole construction industry. However, the fact that all interviewees had fairly unanimous answers

shows that the question is of interest and that there seems to be possibilities for improvements.

Further, the fact that the question is of interest for the interviewees, gives an indication that other

organizations than WSP also might have interest of this topic and hence this master thesis. The results

have been depending on the project- and client design managers who participated in the interviews and

how honest they were to the authors.

2.6 Comments on the chosen method The authors of this report chose to carry out the study in the described way because of several reasons.

First of all, an understanding had to be gained of the characteristics for the traditional and the agile

methodologies, and hence, what differentiates them. In the beginning of the thesis, the authors thought

that traditional- and agile methodologies were two completely different ways of working. After the

literature study and interviews, the authors came to the conclusion that the traditional- and agile

methodologies have the same processes. However, the authors came to the conclusions that processes

are worked with in different ways because of different characteristics for the two methodologies.

Further, the purpose of conducting interview was to compare literature to practice, and to see in what

way construction project managers currently are working. This was done to come up with eventual

improvement suggestions.

10

3. Literature review The following literature review will present the main topics of this thesis. The chapter will present who

the authors refers to as “the client” in construction projects. This is described because different

words, such as “customer”, are used in other industries. The role of the client is presented because

this study aims to provide an understanding of what “client satisfaction” is and how it can be

obtained by increased efficiency in the design phase. Finally, traditional and agile project

management methodologies will be presented to give the reader a larger understanding of the two

methodologies and what differentiate them.

3.1 Client The client is the one who provides financial resources to carry out a construction project, therefore the

clients’ wishes and needs are of great importance (Winch, 2010). The clients’ financial resources are

used to create a construction which provides a net gain to the society and economy in which the

physical asset is created. In other words, the client of a construction project is someone who is having

construction work carried out (Boverket, 2014).

It is however important to also include the requirements and wishes of other affected parties. One such

party could be a donator who has donated the financial resources to the client who in turn uses it for

the construction. Another party, with requirements, could be the end-user. The end-users will be using

the physical asset (building, or other construction) or will be directly affected by it (Wikforss, 2012).

The requirements and wishes of all important parties are for this reason important to include when

planning for a construction.

In section 4.1, the case study project of this report is presented. The client of the case study project is

“The Public Transport Division of Stockholm County”. They have ordered new depots for storage of

subway trains and are providing the financial resources that the PM of the project should use to carry

out the construction project. The end-users of these subway-depots are the company who works with

maintenance of the trains in the depots.

Another example that points out the client could be the construction of a school-building. The client

could be a real-estate company who owns the school-building, and the end-users would then be the

professors and students who will actually use the building.

This clarifies the client and the end-user(s) and gives an insight to the many requirements and needs

that should to be taken into consideration when constructing a building. The clients’ often hires project

managers (PMs’) and client design managers (CDMs’) from consultancy firms, for instance from

WSP, to capture the whole picture of requirements and to carry out the construction project from

initiation to a finished building (Hansson, 2014).

When the “client” is mentioned in this report, it is referred to the party that has ordered a new

construction that should be carried out within budget, on time and to the required final quality.

3.2 Client satisfaction “Customer satisfaction” is a more well-known concept than “client satisfaction”. However, in the

construction industry, it is rarely referred to the “customer” but rather to the “client”. The expression

“client satisfaction” will therefore be used instead of “customer satisfaction” in this report in order to

make the information consistent with the terms used in the construction industry.

11

The term “customer satisfaction”, or as in this case “client satisfaction”, is a well-known measurement

tool, for project managers in order to know the degree of satisfaction of their clients (Kärnä, 2004).

Client satisfaction has shown to be the most essential factor when it comes to the perception of project

success (Dov and Lechler, 2003). Clients seem to be satisfied when the quality of a product is better

than the standard of that product. Further, Dov and Lechler (2003) argue that advantages of achieving

a high level of client satisfaction are the following:

“Improving communication between parties

Enabling mutual agreement

Evaluating progress towards the goal

Monitoring accomplished results and changes, etc.”

As earlier mentioned, to accomplish a high level of client satisfaction in a project, it is fundamental to

understand the clients’ wishes and requirements (Kärnä, 2004). Moreover, the project manager must

also understand what it is that creates value for the clients’ organization. To gain this understanding, it

is crucial that the project manager and the client have good communication and collaboration

throughout the whole project.

According to Dov and Lechler (2003), another factor that contributes to client satisfaction is planning

(Dov and Lechler, 2003). They express that “plans are nothing, planning is everything” and explain

that planning is not a one-time task and that plans only are useful if they are continually updated. The

reason for this is because surrounding factors constantly changes and that the plans therefore also need

to be changed. They mean that if plans are continually updated and adjusted to surrounding factors,

they can become success-factors for projects since this makes the plans more realistic and achievable.

3.2.1 Client satisfaction in the construction industry Client satisfaction in the construction industry is a rather under-researched topic (Kärna, 2004). The

topic is though very important in the construction industry, since it is advantageous for a company to

retain a client or improve the organizations’ reputation, which is crucial for future project success.

Parties that have successfully worked together are often willing to work together again in the future;

this can also be seen in partnering agreements which are becoming more and more common in the

construction industry (Wikforss, 2012). For instance, if the PMs’ or CDMs’ from WSP make a client

satisfied, it is a greater chance that the client will hire WSP for their upcoming projects as well. The

opposite is also true, that means that who know that they are going to work together in the future have

larger incentives to cooperate efficiently in their current projects.

In order to enable as high client satisfaction as possible, it is important for the organization to work

with continual reconciliations (Kärnä, 2004). Conversely, it has been shown that dissatisfactions about

a project are often introduced late in the project. This is a clear disadvantage for PMs’, because the

later in the process, the more of the clients’ money has already been spent and also the more it costs to

make changes, see Figure 2 and Figure 3. This in turn means that there are smaller possibilities to

make changes if dissatisfactions occur late in construction projects since there budget might not be

large enough to improve it at that point.

The client is assessing the project process three levels, which all are implicating the client satisfaction.

According to Kärnä (2004), these three levels are the following (Kärnä, 2004):

Comparison – between the quality of the process, the client’s expectations and the adjusted

goals for the project.

12

Comparison – between the quality of the process and the experiences, which have emerged

during the process.

Comparison – between the client’s expectations and experiences.

As earlier mentioned, client satisfaction might lead to retention of clients (Kärnä, 2004). However, in

the construction industry, a high level of client satisfaction does not guarantee loyalty or retention

since the procurement in construction often is determined by price or by the public procurement law

(Wikforss, 2012). Client satisfaction is still though of big importance for companies in the

construction industry since this most likely affects companies’ reputation which will make them more

competitive in the market (Kärnä, 2004).

3.3 Traditional project management What identifies a project is its’ temporary and unique nature. In the construction industry, the projects

usually have external clients (Tonnquist, 2007). The project is based on the clients’ requirements,

wishes and needs. The clients’ construction project manager works to identify requirements and

further to coordinate, plan, organize, control, lead and follow-up the construction project from idea to

final product.

According to PMI, the traditional project management methodologies are called “predictive life-

cycles” because the planning for the project is made early on in the project. In other words, the project

scope, time and costs to deliver the end-product are determined early in the project, i.e. when there is

not enough knowledge about the project yet (Project Management Institute, 2013).

To develop an understanding of how the traditional project process and methodologies look in

literature, this section describes concepts and processes of traditional project management.

3.3.1 What is traditional project management? Traditional project methodologies arose in the middle of 19th century during the cold war. The reason

for the occurrence of traditional methodologies was due to the constant striving of being ahead of

enemies. This means that one wanted to be first regarding everything, i.e. as short lead-time as

possible was the key-factor. To achieve completing tasks on as short lead-time as possible, several

activities were performed in parallel with each other (Gustavsson, 2013). However, by the time,

project participants started to make counter reactions to this kind of project management. In reality, it

was not possible to perform activities in parallel and tasks were instead performed sequentially.

(Gustavsson, 2013).

3.3.2 Traditional processes Tonnquist (2007) presents the plan-driven project processes and its’ different phases. It typically starts

out with initiation, continues with a feasibility study and further on to planning and execution before

closing the project and handing-over the outcome to the clients (Tonnquist, 2007). An overview of the

project process is presented in Figure 4. Each phase in the project process is focusing on a subset of

project activities and project management processes.

The work required in each phase differs from the others and will therefore require different skill-sets

from members of the team. The project team may therefore vary from phase to phase (Project

Management Institute, 2013).

In WSP’s guidelines for project management, the different phases of a construction process are also

described (Svensk Byggtjänst, 2009). These guidelines are produced by Svensk Byggtjänst (2009) and

13

are intended for project managers. Those guidelines include descriptions of the project process and

checklists for each phase of a construction project.

According to these guidelines, the project process starts out with a feasibility study and continues with

a design phase, similarly to Tonnquist (2007). The design phase consists of three stages, the program

stage, system stage and detailed design stage, as was also described in section 1.1. When the detail

design is finished, the project moves on to production, testing, inspection and finally handing-over and

closing. The process is presented in Figure 4:

Figure 4: The construction project process in the project managers guidelines (Svensk Byggtjänst, 2009). Thi process is also

called the waterfall model (Hughey, 2009)

The following sections are giving brief explanations to each stage of the construction project process

according to the guidelines from Svensk Byggtjänst (2009). The program- and system-stages are

explained more thoroughly than the other stages because this report is focusing on the potentials to

increase efficiency in those stages. The production phase and testing phase will only be briefly

described since these phases are outside the scope for this report.

3.3.2.1 The feasibility study

Tonnquist (2007) explains that the feasibility study intends to answer the question “why” and “if” a

project should be started and carried out. In other words, this phase give an explanation to the reason

for existence of the project (Tonnquist, 2007).

The feasibility study defines the goal and purpose of the project. It states the project scope in terms of

what is to be done and how it should be done (Tonnquist, 2007). The feasibility study investigates the

current circumstances for the project and should be carried out carefully since it could save lots of time

and effort in the later stages of a project.

In the feasibility study, it is also of great importance to make a stakeholder-analysis, since many

internal and external parties could have opinions and thereby affect the project (Tonnquist, 2007). As

this is the preparation for the project, Tonnquist (2007) describes that it is crucial to plan for the

communication to stakeholders who might be supporters or opponents to eventual projects. Further,

the risks of the project can be identified, and planned for, through a SWOT-analysis. In such an

analysis, the internal strengths and weaknesses as well as external opportunities and threats are

14

analysed and treated to minimize negative surprises later on. The planned organisational structure for

the project should also be set up in the feasibility study.

In the feasibility study, a project time-plan is made and roughly describes the way towards the project

goal; it should include the most important tollgates and could be presented as a milestone plan where

estimates for budget and time are also included (Tonnquist, 2007).

3.3.2.2 The design phase

The design phase of a project aims to answer the question “how” the project goals are going to be

reached (Tonnquist, 2007). The goals were stated in the feasibility study and now it should be planned

for how the project should be executed.

The design phase is described as three different parts in construction projects according to the

guidelines for project managers (Svensk Byggtjänst, 2009). These different parts are described in

Figure 1 in section 1.1 and are:

The program stage

The system stage

The detailed design stage

3.3.2.2.1 The program stage

The planning for the construction phase starts in the program-stage (Svensk Byggtjänst, 2009). The

design manager of the client makes an analysis of project requirements and needs. Thereafter, a broad

range of investigations are made and documentation for these should be prepared to describe the

project and its scope. These are called “program-documents” and include technical requirements,

spatial requirements, environmental requirements, plans and also aesthetic design plans.

This means that the program-stage aims to give a final definition of the end-product, its’ goals,

requirements and properties (Svensk Byggtjänst, 2009). Project-activities are planned for and

structured in an orderly way, so that the results are easy to measure and follow up. The management

team is created and each persons’ role in the organizational chart is described in written. The different

options for project-execution are considered and evaluated and plans are made for how the external

stakeholders are going to be managed. A kick-off meeting is held with the involved consultants and

architects.

The architects then start to create the first sketches and visualisations for the construction project and

should create different versions so to give options to the client to choose between (Svensk Byggtjänst,

2010). The different alternatives are then considered and the best one is chosen for the project

execution. These first drafts from the architects are important to confirm so that technical and

functional requirements can be reached. The technical and architectural documents become the base

for decision-making and are so called suggestion-documents.

Routines for change management are decided upon and a time-plan is made (Svensk Byggtjänst,

2009). The time-dimension is thereafter supposed to be fix, which means that the decided deadlines

should be held. Furthermore, systems for economical-management are determined and plans for

allocating financial resources are made. The costs should then be controlled on a continual manner and

finished costs should be followed up by comparisons to the budget for the program-stage. The budget

for the upcoming system-stage should now also be determined and a communication plan should be

made.

15

In the end of this stage, a program-document should be prepared (Svensk Byggtjänst, 2010). This

document forms the basis for the upcoming design-work of the project. It includes the clients’ wishes

and requirements. The program document include a project description, an organization description,

technical description, sketches, drawings, environmental goals, plot investigations, quality policy, time

plan and project cost calculations.

3.3.2.2.2 The system stage

This is the stage where all technical solutions for the construction should be decided upon, in other

words, the system of the construction should be planned for (Svensk Byggtjänst, 2010). The

construction as well as installations and other technical components of the construction are defined in

such a way that the requirements specified in the previous step are achieved. The documents produced

in this stage should include descriptions, drawings and motivations for why these systems were

chosen.

The planned construction should be clearly defined and determined by the end of this stage (Svensk

Byggtjänst, 2010). When the technical solutions are chosen and the future functions of the end-product

are determined, the total execution costs of the project should be calculated. Based on this, a budget is

prepared and presented to get financial resources to start working with the detailed design.

The presented documents in the end of the system stage leads to a tollgate where the decision of

proceeding or not proceeding is made. This is the point where presented documents and proposals are

often rejected. If the presented system documents are rejected, they have to change in order to get

approval. These changes are costly and the project group often considers their work until that point as

“wasted”. In this situation, the design team and manager tries to negotiate in order to bargain on what

should be included and what should not, this lead to major changes in the end of the system-stage (or

program-stage). This constitutes a common problem for construction managers in different types of

projects today. Recall the research-question of this master thesis:

How could agile methodologies affect the amount of major unwanted changes in the end of

the program- and system-stages in construction projects, in order to increase efficiency?

3.3.2.2.3 The detailed design phase

The detailed design stage is the final part of the design-work (Svensk Byggtjänst, 2009). In this phase,

the technical documents and drawings are formed in detail, based on the documents from the system

stage. The construction documents are being prepared, these form the documents according to which

the construction is going to be built. In this stage, all preparations for the production is made in terms

of time-planning, workplace-planning as well as planning for establishment, logistics and

commissioning. Any changes that might occur to the decisions made in this stage have to be handled

in accordance with routine-work and those changes must be documented to be able to be clearly

communicated to all project members. But before any changes can be made, the consequences of those

have to be evaluated and changes should only occur if accepted by the steering group.

3.3.2.3 The production phase

In this stage, the construction should be performed in accordance with the documents prepared in the

previous stages (Svensk Byggtjänst, 2009). Plans for production are made and economical, time as

well as quality and environmental aspects are controlled during the whole production phase. As

mentioned before, any changes that the project group wants to make needs to be approved from this

stage on, and this procedure shall follow routine change-management work. The changes made might

have consequences which require time or economy to be adjusted.

16

3.3.2.4 The testing phase

The different functions in the construction should be tested when finished (Svensk Byggtjänst, 2009).

When the contractors have made their own internal tests, the combined functions have to be tested,

that is systems produced in cooperation with other parties. The documents produced from testing

should be used when evaluating if the execution has been performed according to contracts.

3.3.2.5 The inspection phase

The finished and self-tested product is now inspected by external parties to make sure they have

followed all regulations and contracts (Svensk Byggtjänst, 2009). Eventual notifications are discussed

in the “finish meeting” and needs to be adjusted to approve the construction for commissioning.

Lastly, a final inspection is made and contractor-works are approved in documents which are sent to

the Building Department of the local authorities.

3.3.2.6 The handing over phase

When the construction is completed and everything is approved, the construction can be handed over

to the client (Svensk Byggtjänst, 2009). When this is done, the project manager of the construction

project should make a final report which presents the project results. The client then needs to sign

these documents to approve that the project has been completed.

Another important part of the final report is to consider the experiences and knowledge gained during

the project (Tonnquist, 2009). It is important that the project manager takes time to reflect about this to

create a knowledge-base for upcoming projects.

3.3.3 Challenges with traditional project management Traditional methodologies are, among all, used in construction projects where “after-the-fact changes”

are hard or costly to make (Hass, 2007). However, these methodologies assume that once a project

phase is completed, it should not be changed or revised. One problem with the traditional

methodologies is that the clients’ requirements are expected to be formulated in advance. This implies

that they are blocking the way for new requirements (Opelt, et al., 2013). Also, it implies an

assumption of predictability i.e. that any events that could affect the project are foreseeable (Hass,

2007). Hass explains that the traditional methodologies expect the client to know in advance exactly

what he or she requires from the project. Traditional methodologies are therefore seen as wasteful

since it will probably deviate from early-made plans.

However, Hass (2007) describes the traditional, plan-driven methodologies as disciplined and

structured methods for planning and control of projects (Hass, 2007). Kerzner (2011) states that the

project members should be committed to make efficient plans in the beginning of each project. He also

states that the number of changes to the plans should be minimized by committing to realistic

objectives from the beginning (Kerzner, 2011).

3.4 Agile Project Management The traditional project management methodologies were considered as slow and static by software

developers (Gustavsson 2011). For this reason, they searched for more supportive methodologies in

order to work more efficiently. They came up with some values that were more dynamic than the

traditional methodologies; these values were used with different names before the name “agile” was

agreed upon and are presented in section 3.4.2.

17

3.4.1 What is agile project management? Agile methodologies could be described as “the ability to rapidly respond to change” (Oxford

University Journals, 2013). The agile methodologies developed as a response to dissatisfactions about

traditional methodologies, which are keeping time, cost and scope fixed in a project. This means that

the traditional methodologies were seen as inflexible and therefore a group of software developers

came up with the “agile” methodologies which are more flexible (Oxford University Journals, 2013).

The reason for traditional methodologies to be considered as static and inflexible is that they advocate

making plans in early stages, and to follow these early plans without welcoming changes to time, cost

or scope (Gustavsson, 2011). Often, changes that occurred were seen as failures.

The agile methodologies are about realizing that projects are prone to changes because of changing

circumstances (Oxford University Journals, 2012). It is about realizing that we develop our knowledge

and understanding of a project as it proceeds. Shortly, this means that we must adapt to new

information as it is gained during the project. Not only the new information gained, but also the

changing project environment is taken into account in an agile mindset. In one single word, agility is

all about flexibility.

The agile methodologies have their roots in the lean methodologies, but they are not the same (Opelt,

et al., 2013). Shortly described, the lean philosofy is about eliminating waste and to eliminate all steps

that do not generate value in a value stream (Lean Enterprise Institute, 2009). The difference between

lean and agile goes back to the fact that “shared principles” are not always the same as “shared

practices”, see Figure 5 (Rudd, 2012).

Figure 5: The practices of lean and agile usually differ even if they have shared principles/philosophy (Rudd, 2012).

Rudd (2012) explains that the agile and lean principles are similar but that there are differences in the

way the principles are practiced. Both lean and agile aims to increase efficiency and are considering

efficient management of resources, however, the practices of them are different depending on different

work situations (Rudd, 2012). It is explained by Opelt, et al. (2013) that lean practices requires stable

processes and seeks to reach automation of processes in stable environments. Agile methodologies on

the other hand are mainly dealing with increasing efficiency in projects which are by definition

unique, one-time and could not be set equal to an automatic process. Projects are often carried out in

unpredictable and uncertain environments.

The most used agile methodology today is called “scrum” (Cohn, 2012). It is mostly used in software

development projects but could also be used in any other type of project. In this report, when the

authors refer to agile methodologies, it is mostly referred to methodologies used in “scrum”.

18

3.4.2 The agile manifesto The agile manifesto states the four main principles that agile methods are built upon and those are

presented below (Beck, et al., 2001):

Individuals and interactions over processes and tools.

Working software over comprehensive documentation.

Customer collaboration over contract negotiation.

Responding to change over following a plan.

To avoid misunderstandings about these agile principles, many agilists (proponents of agile methods)

are clarifying that they put value in the statements to the right but that they value the items to the left

even more (Beck, et al., 2001). Each principle of the agile manifesto is shortly described by

Gustavsson (2011) and is presented:

Individuals and interactions over processes and tools:

The first principle of the agile manifesto means that the project team and its members are

responsible to apply the best working processes and methods for the specific project. This

means that the team composition and the project-specific conditions needs to be considered for

each project, this is because each project is unique.

Working software over comprehensive documentation:

The second statement in the agile manifesto is mainly considering software development

projects. To make it more adapted to other kinds of projects, it could be changed into “Useful

project outcome over comprehensive documentation”. This means that it is not the

documentation but the continuously created project results that matters.

Customer collaboration over contract negotiation:

In the end of each cycle of an agile project the customer is involved to bring forward opinions

and thoughts about the project. This means that the customer collaboration is core to bring the

project towards success. The customer gets involved throughout the whole agile project

process by reviewing, discussing and deciding in the end of each cycle. Again, in construction

the word “client” is used rather than “customer”.

Responding to change over following a plan.

The agile manifesto states that changes are welcomed in agile projects. The reason for this is

that agile projects does not believe in “predicting the future” by planning for every detail in

advance. The plans should instead be dynamic and agile teams should realize that projects are

prone to change.

3.4.3 Agile characteristics The project phases in agile project management are the same as those in the traditional project

management. However, the agile methodologies have some different approaches to handling the

project phases (Gustavsson, 2011). This section will present the most important agile methodologies

that could be used in the program- and system-stages.

Some critics perceives agility as chaotic ways of working with no planning, while in fact, agility is

about frequently doing detailed planning instead of making detailed plans for a whole project at once

(Gustavsson, 2011). Agile methodologies consider that “we get things wrong before we get them

19

right” (Miller, 2001). Also, agile methodologies regard time as fixed and processes are often run in

parallel, as inspired by lean philosophy, in order to finish tasks on time (Gustavsson, 2014).

In agile methodologies, the major difference is that the project phases are worked through in

incremental steps and each phase is divided into short, iterative cycles (Miller, 2001). The agile

process is adaptive to changes that occur during a project. Below are a number of agile characteristics

presented:

Characteristic 1 – Levels of planning

Characteristic 2 – Planning in short cycles

Characteristic 3 – Reconciliations

Characteristic 4 – Welcome changes

Characteristic 5 – Project team collaboration

Characteristic 6 – Communication

Characteristic 7 – Documentation

Characteristic 8 – Time is fixed

Characteristic 9 – Uncertain and complex projects

Characteristic 1 - Levels of planning

The planning in agile methodologies is done in different levels. All planning activities are worked with

in iterative ways where the plans will be repeated and adjusted continuously as circumstances changes

(Opelt, et al., 2013). As always with agile methods, the parts that are being planned should be as short

as possible in order to guarantee a delivery within the set time frames (Gustavsson, 2011).

Plans should not be too detailed since it is seen as a waste of resources and time (Gustavsson, 2011).

This is because it is known that too detailed planning have to be re-done later on anyway. Too little

planning on the other hand is also risky since this might lead to mistakes due to lack of information. In

order to ensure the right level of detail in the planning phase, the following five levels of planning

should be completed.

1. Vision

2. Road map

3. Deliverance plan

4. Cycle plan

5. Daily plan

Vision – The first level of planning is the vision and shows the planned end-product for the whole

project (Gustavsson, 2011). It explains what should be done and why, in a describing and simple way.

It is important that the vision is being thoroughly produced in order for all actors involved to know

where they are heading and what the goals for the project are.

Roadmap – This is the most long-term plan after the vision and should therefore not be too detailed by

not guaranteeing specific dates (Gustavsson, 2011). The time perspective should rather show the entire

project roughly, from start to the end of the project.

Deliverance plan – On the third level, dates and time limits are introduced (Gustavsson, 2011). The

whole project should not be planned but the focus should rather be on specific parts of the project

which the project team believes will generate some kind of value for the project at the moment. When

comparing with traditional methods, these parts described above correspond to milestones.

20

Cycle plan –The whole project is broken down to short cycles (Gustavsson, 2011). The team should

deliver a project result in the end of each cycle. Since time is fixed, time cannot be extended if it does

not go as planned. If more time is needed, the team has to delete some of the activities or perform then

in the next cycle. The cycle plan is based on the deliverance plan and the length of the cycles should

be one to four weeks depending on the project size.

Daily plan – In this plan, the upcoming days and who has the responsibility for each activity is being

planned (Gustavsson, 2011). The daily plan, as well as the deliverance- and cycle plan, should be

continually updated during the project. The vision and the roadmap on the other hand are created in

the beginning of the project and are not being revised. All plans except the daily plan is being planned

during the start-up phase of the project.

Characteristic 2 - Planning in short cycles

When working with agile methodologies, the projects process proceeds by a series of iterative work-

packages, or short cycles, according to the “cycle-plan”. Each cycle are called “sprints” in the most

used agile methodology, scrum (Scrum.org, 2014). The cycles begin with planning meetings where

priorities of requirements are made for the upcoming cycle. The value of the activities decides in what

order activities should be performed. The activity ranked with the highest value should be prioritized

first and hence performed first. In the end of each cycle, a review-session is held to go through the

deliverables of the completed cycle.

This incremental way of working, step by step, makes it possible for the project team to respond to

feedback and change so that they create only what is required (Scrum.org, 2014). The biggest benefit

of agile is said to be the early deliveries of value (Oxford University Journals, 2013). Also, any

hindrances or problems can be identified early in the project process which means that risks can be

avoided when they are identified just-in-time. The risk for project failure is minimized by closely

collaborating with the client and by incrementally bringing value early in the project.

Characteristic 3 – Reconciliations

The client is involved in the beginning of each short cycle which means that agile methodologies

require a larger demand on the client in comparison to traditional methodologies (Gustavsson, 2011).

In agile methodologies, the short cycles ends with some kind of delivery of project result. This in turn

follows by reconciliation-meetings where previous experience is discussed. These meetings are held in

order to improve the coming cycles by analyzing how the previous cycle went. In this way, the project

team can improve their work during the project instead of waiting until the next project to analyze and

implement improvements.

It is easier to finish projects when working agile compared to traditional project management because

reconciliations have continually been carried out during the project process (Gustavsson, 2011). This

means that the client is well aware of the result of the end-product before the actual handing-over

which in turn means that there are few surprises in the end of a project. The continuous presentations

of results and reconciliations often end up in a successfully followed time plan since the project team

must deliver results in the end of each cycle.

Characteristic 4 - Welcome changes

The lists of requirements from the client should be flexible and possible to change (Gustavsson, 2011).

The strength in agile methodologies is that prioritizations, requirements and goals are allowed to

change in each new “short cycle” throughout the project. This further explains the focus on flexibility

in agile methodologies.

21

Each cycle should be iterative and continually improved, since this is the most important thing with

agile methodologies (Gustavsson, 2011). This procedure takes into account that the first iteration is not

the best, and that it needs to be worked on further to get it 100% correct (Miller, 2001). The iterations

are therefore a way of welcoming and handling changes.

Characteristic 5 - Project team collaboration

Agile teams are characterized by being small (five to nine people), empowered and multi-skilled

(Gustavsson, 2011). The reason for working in small teams is to enable good communication and to

facilitate efficiency. The agile methodologies do not provide complete, detailed descriptions of how all

the work is going to proceed in a project. Instead, the team has to together take responsibility for the

deliverables of each cycle (Scrum.org, 2014).

Agile ways of working relies on cross-functional teams and self-organization which means that there

is not one specific leader who decides which tasks each person in the team should perform (Cohn,

2012). Neither is there a leader who tells the team how a problem should be solved. All the

responsibility is decentralized to the project team members so that they can share knowledge cross-

functionally. Each project member in an agile team should feel equally responsible for the project and

the project team should take joint decisions (Gustavsson, 2011).

As the project team have power to make decisions, the focus gets decentralized from the project

manager who can instead work to make the project more efficient by paving the way for the project

team (Gustavsson, 2011). The main responsibilities of the project manager in agile methodologies are

to deal with conflicts and eliminate problems that occur within the team. This means that they do not

have a traditional project manager but rather a supportive coach. This way of working can eliminate

waste in terms of financial resources, time or results. Even though agile methodologies advocate that

individuals should have cross-functional competence, it does not mean that they have equal shared

responsibility for single activities. It is therefore important to allocate responsibility between members

in the team for each activity. Otherwise the risks of uncompleted tasks are large because no one will

take responsibility for the execution of the tasks.

Agile methodologies include important factors such as the need for each project member to belong in

the team, to learn from each other, to create something together and to be creative (Scrum.org, 2014).

It is also about growing as a team, to together improve and interact with each other.

Characteristic 6 – Communication

The communication plan is especially important in the agile processes (Gustavsson, 2011). This is

because good communication is one of the core values in agile methodologies. Therefore, a

communication plan should be made in the feasibility study in order to facilitate the creation of goals

and benefits.

The agile methodologies aim to enhance communication and create smoother work-flows (Oxford

University Journals, 2013). The reason why agile ways of working focus so much on communication

is to decrease the difference between the project result and the clients’ request. This means that good

communication makes the end product in accordance with the clients’ wishes.

Person-to-person communication is encouraged which is described in the agile manifesto that states

“individuals and interactions over processes and tools” (Boehm, 2003). The different ways of

communicating are trying to bring forward the tacit knowledge. Boehm (2003) also explains in his

article, that this does not mean that the entire project communication relies on tacit knowledge since

that would be risky when team-members drop off a project.

22

Characteristic 7 – Documentation

Recall the second principle of the agile manifesto which was restated into “Useful project outcome

over comprehensive documentation” in order to make it more adaptable to other types of projects than

in software development. This statement means that it is not the documentation but the project results

that matters. Less expert and less confident clients and managers tends to see documentation as a sort

of security blanket according to (Boehm, 2003). He writes that they produce documents even for less

critical and less complex situations. He means that this is to not focus on the most appropriate parts of

documents desired. Boehm (2003) also adds that these produced documents will probably never be

read by non-experts, or even if it is read, it will be incorrectly understood. He points out that it is not

necessary to try to provide the users with guidance for all, or most, foreseeable situations.

Characteristic 8 - Time is fixed

The project management triangle (cost, time and scope) in agile methodologies is different compared

to in traditional (Owen, et al., 2006). The biggest difference is that in agile methods, time is fixed and

is seen as “holy”, compared to scope which is fixed in traditional methods. In agile methodologies, if

work does not go according to initial plans, the scope could be adjusted to fit within the time frame

rather than extending the time. Furthermore, if it is not possible to complete an activity within the time

frame, it has to be moved to the next sprint, which is a common name for cycle.

As shown in Figure 6, the agile project management triangle is turned upside down compared to the

traditional project triangle (Owen, et al., 2006). As the figure explains, this means that resources and

time are the fixed elements within agile methodologies while scope is the fixed feature in traditional

methodologies. Scope on the other hand is the element that varies in agile projects compared to

resources and time in traditional.

Characteristic 9 - Uncertain and complex projects

The agile methodologies are suited for projects with high complexity and uncertainty where changes

to initial plans are inevitable (Opelt, et al., 2013). It is suitable to work in agile ways when a project is

performed under changing circumstances, has unclear specifications, complex project goals and results

needs to be achieved continually. This is because the agile methodologies advocate that deliveries are

produced continually in each short cycle.

Figure 6: Time is fixed in agile methodologies; scope could vary within the given resources (Owen, et al., 2006)

23

3.4.4 Challenges with agile project management So far, agile methodologies have been discussed with mostly an optimistic mindset and positive

outcomes. Below are a number of challenges discussed in the literature presented:

Challenge 1 – Flexibility restrictions

Challenge 2 – Opponents views

Challenge 3 – Contractual and regulatory issues

Challenge 4 – Development process conflicts

Challenge 5 – Business process conflicts

Challenge 6 – People conflicts

It shall be kept in mind that the agile methodologies arouse in the software-development sector and the

challenges presented here might not be the same as the challenges for working agile in construction.

Challenge 1 - Flexibility restrictions

Situations where working agile can be a challenge is when the project has a fixed deadline and a strict

scope (Gustavsson, 2013). This is a challenge because it does not allow flexibility, which is one of the

cornerstones in agile methodologies. If the project has a fixed deadline but not as strict scope on the

other hand, it is possible to work agile since scope can be changed, revised or prioritized differently.

Challenge 2 - Opponents views

Opponents of agile methodologies have the common view that these are a bit fuzzy, not so strict and

involve mainly soft values (Gustavsson, 2011). This perception can be due to projects that have failed

to practice agile methodologies (Oxford University Journals, 2013).

Challenge 3 - Contractual and regulatory issues

In general, challenges of working agile regard contractual and regulatory issues (Gustavsson, 2013).

This is because it does not entail flexibility or that it regards decisions which cannot be affected.

Examples of the above described situations can be public procurements, which require detailed plans

from the start to the end.

Challenge 4 - Development process conflicts

This points out the challenge of merging agile and traditional methodologies (Elliot, 2008). Since it is

rare to work completely agile when implementing agile management, it must be combined with

already existing methodologies. It is then important that there is a balance between the different

methodologies, which is hard to achieve according to Elliott. Another challenge with this problem,

which also was mentioned by Gustavsson (2011), is that the project group might have different

mindsets when blending traditional and agile methodologies (Gustavsson, 2011).

Challenge 5- Business process conflicts

These conflicts can occur when business processes are not adapted to work in agile ways (Elliot,

2008). Individuals constituting the project team are required to have more skills than in traditional

projects. The reason for this is because they should be multi-skilled rather than an expert within one

area. Furthermore, the team should be able to make decisions since they together have the overall

responsibility, compared to the project manager who carries the overall responsibility in traditional

projects. This in turn requires that the organization is able to accommodate the human-resources

needed.

24

Challenge 6- People conflicts

There is a challenge for the organization to make the team work closely, which might require a

different office set-up (Elliot, 2008). Since agile methods advocates close relations, it requires a shared

work-place so that the project members can meet.

25

4. Empirical findings The following chapter will present the findings collected from interviews performed with project

managers (PMs’) and client design managers (CDMs’) who are working in different types of

construction projects. A case study is presented in order to give an example of a construction project

and its complexities. Interviews have been performed with managers of the case study as well as with

managers from other construction projects. The empirical findings gives examples from all conducted

interviews. Five important areas have been investigated during the interviews and are presented in

this chapter.

4.1 Facts about the case study The case study project is a re-construction of a depot for subway-trains in Stockholm. The depot-

building is used for storage, service and maintenance of the subway-trains; therefore it has technical

solutions that are important for the maintenance of the trains. The client of the project is The Public

Transport Division of Stockholm County Council. The project goal is to make the depot large enough

for new subway trains that will be delivered in 2016. Each new train-wagon unit will be longer than

the current wagons. The new wagons will not fit in the small depot, which makes the reconstruction

necessary. The project is currently in the system-stage within the design phase. A principal overview

of the organizational structure in the case study project is presented in Figure 7.

Figure 7: A principal organizational structure of the case study project.

4.1.1 Coordination challenge The complexity in this project lays in the coordination of the case study project and several other

depots in Stockholm. Some new depots are being built and some are also under re-construction. In

total, there are six ongoing re- and new-constructions of depots.

There will always need to be depots available for storage and maintenance of the trains so that the

commuters in Stockholm’s public transport can be unaffected. It is crucial to make the overall co-

ordination work smoothly to avoid complications. This is crucial to not disturb the traffic and

everyday commuters.

4.1.2 Train design unknown The authors have interviewed the PM and CDM of the case study project. The interviewed PM

mentions that the re-construction of the depot project is dependent on the design of the new subway-

26

wagons, which are not entirely designed yet, so the requirements coming in today will most likely

change. The PM explains that the design of the new train-wagons have to run in parallel with the re-

construction of the depot to be able to finish the project in time.

The CDM of the case study project adds that the problem have not been to understand “what” to

design but rather to understand “why” it should be designed in certain ways, and also for which type

of technical functions. The technical functions of the wagons are not known yet, so there are

uncertainties of how the depots shall be technically designed to be suitable for the new wagons. This

inconvenience constitutes large uncertainties in the project.

4.1.3 Many parties involved The case study project has many stakeholders with different interests and requirements, which are hard

to balance. The main task in the system-stage of the project is described by the PM of the case study

project:

“We are currently trying to capture the requirements from our clients, they are many and they have

different interests and opinions. We are trying to capture it all into one picture.”

(Authors’ translation)

The many stakeholders as well as the uncertainty of how the wagons will be designed imply that

changes occur, the PM of the case study project expresses:

“It has been a lot of changes; or rather a lot of works with client-requirements because the

requirements have not been clear from the start.”

(Authors’ translation)

4.2 Collected answers Seven PM’s and CDM’s have been interviewed in total. The interviews focused on five topics that the

authors consider as important for this report. The topics are communication, project planning, project

success factors, documentation and time- cost & quality. The empirical findings for each topic are

presented in the following sections. The presented answers for these topics are collected from PM’s

and CDM’s from both the case study project and also from other projects.

4.2.1 Communication One of the interview-areas was communication. This is because communication is core to enhance the

project process.

4.2.1.1 Trust

One interviewed PM, who is not involved in the case project, is currently working in a mega-project

and stated during an interview that communication is a complex task in all sizes of construction

projects. In order to facilitate the communication, the essence of trusting the project team has been

helpful according to the PM who also highlighted the importance of having a supportive leadership.

The PM stated that it is necessary to give space to the project team and to let them take their own

responsibility. The PM means that it is important to give the team space because it allows them to

work creatively and make eventual mistakes, which is expressed in the following quotation:

“They have the courage to do their work if they feel that I trust them, but they also dare to make

mistakes which is completely natural. If no one makes any mistakes, I have been fooled, since

everyone makes mistakes”. (Authors’ translation)

27

It was also pointed out that the work has to be decentralized with trust in others to be able to finish the

project within the deadline. The PM meant that it would not be possible to handle it in another way for

such large mega-project. The complete openness, acceptance and transparency lead to trust according

to the PM.

4.2.2 Project planning Questions were asked about project planning because the authors wanted to capture how the planning

procedure works in projects today and what restrictions that are recognized by the PMs’ and CDMs’.

This was done in order to further analyse and find opportunities for enhancing and improving the

planning procedure.

4.2.2.1 Plans are made in advance

The PM of the case study project explained one reason to plan for activities a long time in advance.

The PM mean that early planning is forced by the client because they require calculations on costs for

a long time ahead. To know the project costs, the project team needs to make thorough plans in early

stages. The reason that the client wants calculations is that the client is lending money which they have

to pay interest on. The clients want precise numbers of costs so that they can keep the interests down

on the loans. However, this is a challenging task for the PMs’.

“It is a hard task to estimate the costs because we are only in the system-stage and we do not know

everything about the project yet.” (Authors’ translation)

The same PM explained that it would be good to do the planning in later stages when more knowledge

about the project has been gained. However, the PM means that it is not possible to wait with the

planning, because they have to control for costs. Also, the design of the train-wagons and the design of

the depot need to run in parallel due to time pressure, the PM explain that the project will otherwise

not meet deadline. In other words, the managers of the project knows that changes to initial plans will

occur as the project moves forward, and they know that changes will cost time and money to adjust,

but they do not see any other option than to plan ahead to meet deadline.

4.2.2.2 Proactive planning

The CDM of the case study project states that there is a very large probability that the client wishes to

change the requirements in the end of the project, due to these complexities of construction projects.

However the CDM often sets an earlier deadline than the actual deadline. This is done to avoid that

people only work when the time is close to deadline. The CDM means that designers need a certain

amount of pressure to work and deliver, otherwise a lot of work is pushed ahead until the last minute

and panic occurs. The CDM explains that another benefit of earlier deadlines is that it allows easier

coordination of the different disciplines since the work of each discipline builds on the works of the

other disciplines. For instance, the CDM takes architectural design as an example; when the architects

are done with their design, it is easier for other disciplines such, as the installation-designers, to know

what and how they should design. The CDM also makes sure that other disciplines start working in

advance by requiring documents which are written descriptions of their planned technical solutions.

This forces the designers to work proactively and it is a way to help the team to avoid lack of time

later on.

4.2.2.3 Incremental planning procedure

Several of the interviewed PMs’ who are not involved in the case study project explained that there is

usually a general time-plan which covers the whole time-line of the project from the first to the last

day. They state that this is the first thing to be done for a construction project. The PMs’ explain that

28

the purpose is to create a clear overview of the intended project. In the general time-plan, rough

estimations of time and costs are made for each stage of the project. This is done to find the right

contractor but also to get an overview of the project life-cycle. Each phase is then planned for

separately, after the overall project-time plan has been made. The construction project processes are

therefore described as incremental by the interviewed PMs’ as well as by Svensk Byggtjänst (2009), in

the guidelines for project managers. This means that each step taken towards the project goal delivers

outcome.

4.2.2.4 Parallel planning

A PM who is not involved in the case study project points out that the program-stage is about

collecting the requirements from the client, while the system-stage is about planning for how these

requirements are going to be delivered.

The detailed design stage follows after the system-stage and eventual changes that will need to be

made becomes evident in the system-stage. Therefore, the PM means that it is a good idea to make the

detailed design in parallel with system-stage because it becomes easier to make changes in the

program-documents.

4.2.3 Project success factors During the interviews, all the PMs’ and CDMs’ have been asked about project success in terms of

time, scope and money. This was done to understand what they consider as a “successful project” and

what they think is required in order to result in a successful outcome.

4.2.3.1 Clear and common goals

The CDM of the case study project mentions a special condition in order to succeed with the currently

on-going system phase, which is to clarify the goals for this specific phase. The CDM means that the

goals used to be clear but have been changed recently and are therefore not clear anymore. Hence, the

CDM explains that it is of greatest importance that this is being done as soon as possible so that all

project participants knows exactly what should be done.

Another success factor is, according to the interviewees, to work towards common goals. Project

participants must know what the possibilities are to affect the goal, since it is known in beforehand

that the end-result never will be as planned. Therefore, the project team must know what the goals are

regarding the final cost, finish-time and end-quality of their project. In other words, participants

should be aware of where in the project there is room for flexibility and where it is not, in order to

reach project success.

4.2.3.2 Collaboration

A CDM who are not involved in the case study project describes the most important success factor in

order to succeed in the program- and system stages:

”The most important thing in order to succeed in the program-and system-stages is the cooperation. It

is entirely crucial since it is so complex and involves so many stakeholders.”(Authors’ translation)

Cooperation is said to be a key success factor because good cooperation allows finding solutions,

which drives the project forward, rather than focusing on disagreements that arise when the

cooperation is bad.

The CDM mentions that the reason why they have achieved good cooperation within the project team

is because they have succeeded in having the same goal. It is explained that having a common

29

understanding of the project goal is central to reach project success. Also, it is important that the PM is

involved in defining the goal and further actively highlights the goals for the project team throughout

the whole project process. PMs’ and CDMs’ described in several ways that they believe that goal-

focus helps the project to reach successful outcomes.

4.2.4 Documentation The second principle of the agile manifesto states that “useful project outcome” should be valued over

“comprehensive documentation”. The authors have therefore interviewed the PMs’ and CDMs’

regarding documentation to understand what they think about comprehensive documentation and why

it is currently documented to a large extent in construction projects today.

4.2.4.1 Information transfer

The PM of the case study project described that documentation is very important for future re-

constructions. The PM explained that they are currently re-constructing a building which does not

have enough documentation from its initial construction. This situation makes the re-construction

process challenging. The PM means that there is a lack of knowledge about the building so a lot of

extra work has to be performed to understand how the construction is built and what technical

solutions it has.

“Documentation is very important to enhance future re-construction projects”. (Authors’ translation)

4.2.5 Time, cost and quality As presented in the literature review, agile methodologies consider time as fixed. Questions have been

asked during the interviews to understand what managers in construction projects consider about

changes to time, cost and quality (scope).

4.2.5.1 Costs

The quotation below expressed by the PM of the case study project gives an indication of the

challenges with costs:

“The sum of money is a guessed sum! We are not sure about anything early in the project when the

budget is determined, but the sum is locked and we have to stay in budget. (Authors’ translation)

The PM of the case study project explains that the planned budget is decided upon in a very early

stage. It is therefore only based on very rough plans and most of the planned costs are estimated by

guessing. At the same time, all the PMs’ and CDMs’ decisively state that costs, i.e. money spent are

the fixed factor for their current construction projects. They mean that the costs are very critical to

perceive the project as successful. They also stated that the clients would require well-founded and

solid explanations if budget were exceeded and they would have to pay more than planned. However,

an example of unforeseeable things that anyway could increase the costs would be appealed authority

decisions which extend the project time and hence costs more money.

The PM of the case study project further describes the difficulty of specifying exact costs when the

project team does not know how the trains will look yet. It is a great challenge to reconstruct depots

for new trains, which are not yet decided upon, under such a critical constraint for the costs. According

to both the PM and CDM of the case study project, the client are going to have to make a lot of

compromises during the project in order to be able to complete the project within the budget, but also

because it is known that new conditions will arise during the project that will affect budget and time.

30

4.2.5.2 Time

It is mentioned by several managers that time is usually not fixed but that it is one of the most critical

factors because it has a large importance for the clients’ perception of the project success, handing

over dates and logistic aspects. A PM who is not involved in the case study project mentions that a

difficulty with time in construction projects is to a large extent dependent on the building-permit

process. Furthermore, according to a CDM who is not involved in the case study project, the majority

of the permits are being appealed which can make it impossible to keep the time plan.

4.2.5.3 Quality (scope)

The majority of the interviewed managers stated that the most flexible dimension is the quality (or

scope). This means that when the costs are fixed, one can only add or reduce the scope to what the

project budget can afford.

31

5. Analysis The following chapter will analyze four factors of the agile characteristics that were presented in

section 3.4.3. These four factors have been chosen by the authors because they are considered to be

the most valuable agile principles in terms of efficiency. Furthermore, challenges with agile

methodologies within construction projects have been chosen and are analyzed.

5.1 General findings A general finding of this master thesis is that agile methodologies are not something new. It is rather

some different approaches that could enhance the project process for PMs’ and CDMs’. Project

processes are independent of the methodologies that are used, but it is rather the way in which the

processes are handled that differs.

When comparing the literature with the interviews, one of the main findings was that traditional

methodologies in practice do not always correspond well to how it works in theory. In fact, current

traditional practices seem to consist of agile characteristics to a fairly large extent. After the

interviews, it was clear that the PMs’ and CDMs’ are working more or less agile in their everyday

work, even if they are not aware of it themselves. The reason for this might be that theory of

traditional methodologies is obsolete and not updated according to how PMs’ actually work today.

Another reason might be that agile methodologies are more of a trend rather than a new and

revolutionary project methodology.

5.2 The four chosen factors The following four factors are analyzed in this section. These are chosen from the agile characteristics

presented in section 3.4.3:

Planning in short cycles (Characteristic 2)

Reconciliations (Characteristic 3)

Welcome changes (Characteristic 4)

Project team collaboration (Characteristic 5)

5.2.1 Planning in short cycles It could be seen that the PMs’ of the case study project already works partly agile by setting frequent

deadlines and requiring sub-deliveries from all disciplines to make sure that the work is moving

forward. This could be interpreted into that the managers’ works with shorter cycles in some sense.

5.2.1.1 Short iterative cycles

The authors argue that the short cycles could allow the project members to find eventual hindrances

during the program- or system-stages. This is beneficial because it could avoid the project team from

having to re-work the plans in the end, or after, the stage.

While planning for construction projects, one challenge and complexity lies in the need to synchronize

the works of many different disciplines. There are several examples of projects where time and money

have been spent on producing design-documents which are not performable or valid. Each re-start or

major change have then extended the completion time and in some cases doubled the costs of the

project. This could be avoided if the designers of different disciplines had reconciliations with each

other in the start and in the end of each short cycle, as agile methodologies suggests. This mean that

major unwanted changes could be prevented from occurring because the continuous reconciliations

will help the project members to identify problems as they occur, and the team can thereby deal with

32

difficulties right away instead of afterwards. This will save time and money for the project since the

changes would become less comprehensive.

When planning in short cycles, frequent deadlines should also be set to avoid that work is being done

in that last minute. This results in a more efficient use of resources because the project members will

have to work during the whole process, see section 4.3.2.

5.2.1.2 Parallel processes

The interviewees described that they are currently running parallel processes in their projects as the

agile methodologies advocates. The reason for this is that the more detailed stage a project gets to, the

more knowledge about the project is gained and eventual adjustments of the previous stages can be

made. This is seen to be very advantageous because it is possible to meet deadlines in a shorter time,

and thereby to reduce costs. At the same time, this implies larger risks and uncertainties since a

process is started before the previous is finished. It is hence an important task to make trade-offs

between the size of the risks that is taken and the importance of finishing the project on a certain time.

5.2.2 Reconciliations Frequent reconciliations are among other things characteristics of agile methodologies. The managers

of the case study project seem to meet often. However, they could benefit from having more frequent

reconciliations in the project. According to agile methodologies, reconciliations should be held in the

beginning and end of each cycle.

Based on literature and interviews, client contact and involvement are seen to be of great importance

when it comes to efficiency improvements, according to the authors. The reason for is that more

frequent reconciliations means that the client will have more impact on the outcome of the project and

can direct it in the desired way.

5.2.2.1 Client reconciliations

In addition, client contact and involvement seems to be especially important in terms of reducing

major changes that often has to be made in the end of the program- or system-stages. Many of the

interviewees mentioned that reconciliations with the client take place approximately once a month.

However, if these reconciliations took place more often, fewer changes would be made and

unnecessary work could be avoided. This is assumed because it enables the possibility to make sure

that the work is going as planned, and that the client and the project team are “on the same page”. This

would ensure that the project is moving towards the right goals.

Further on, the authors argues that other advantages also could come with more frequent client contact.

Those are trust, respect and better relations in general. Strong relations positively affect the outcome of

the project. A team that has close collaboration is also assumed to be able to solve problems and deal

with obstacles in easier ways.

As stated above, the authors strongly believe that efficiency can be gained by working with good

client contact according to the agile methodologies. However, one problem seems to be that the client

does not have time to be more involved than they already are. Another problem mentioned by a PM, is

that some clients have the opinion that they should not have to be frequently involved, since they have

hired a professional team to lead the project for them. If the client has this view, it is of course hard to

attain closer client contact. However, a possible solution to this problem could be to explain the

potential advantages of more frequent reconciliations to the client. If the client understands the

importance of putting sufficient resources into each ongoing project, the optimal solution would be to

not overload each PM with too many projects at once. Each PM of the client should only have the

33

amount of work-load and only be involved in the number of projects that they can be actively involved

in.

Another challenge mentioned by one of the PMs’ is that the client makes too many changes and that

frequent reconciliations, which is already being held in this case, not is a solution to this problem. This

is an interesting point which made the authors question if it might be possible that more frequent

reconciliations even encourages the client to make changes because they are given the possibility to do

so. This problem expressed by an interviewed PM cannot be seen as general for construction projects

before a further investigation has been done. However, the authors have several thoughts of why the

client makes too many changes. Is it because the client lacks understanding of the project? Or is it

because the project team has made an insufficient stakeholder analysis, which causes problems when

new stakeholders appears and expresses views that have not been taken into consideration earlier?

Might it be because the project team or PMs’ was not able to understand the clients’ needs and

requirements in the initiation? Or is it due to lack of time?

The reasons can be many, but as earlier mentioned the authors believe that more frequent client

contact always will be positive for the project outcome and could help to reduce the often occurring

changes by using resources more effectively. Moreover, if it is a general problem that the client makes

too many changes in projects, one can argue that it should be more important than ever to hold

frequent reconciliations. This is in order to be able to tackle and discuss the problems as soon as

possible, and thereby minimize the waste of resources.

5.2.3 Welcome changes The managers of the case project expect changes to occur since the depot in the case study project is

being planned for although the train-wagons are not designed yet. Although it is a difficult task to

welcome changes, the authors believe that planning in shorter cycles can enhance the procedure. This

is due to the close reconciliations in the beginning and end of each cycle. During these, changes to

plans can be discussed and planned for.

5.2.3.1 Expected changes

As mentioned earlier, the program- and system-stages are creative processes. PMs’ have during the

interviews been expressing that they almost always expect changes to occur on work that have been

performed in the program- or system-stages. The authors interprets that the current most common

approach to deal with expected problems is to proceed with the work anyway and produce plans that

later will have to change. The reason for this is that PMs’ seem to think that this is the only way to

move the project forward. This is an interesting aspect and there might be possibilities for efficiency

improvements. If PMs’ expects changes to occur, one can wonder how much time they are spending

on making the plans that they know will have to change. Maybe, it might be possible to spend less

time on plans and only make them thorough enough in order to reduce waste of resources.

A PM expressed during an interview:

“It takes 10 ideas to make a sketch and 10 sketches to find a solution”. (Authors’ translation)

This quote clarifies the reasoning of proceeding with the project work despite the expected changes.

What is interesting, is that the PMs’ mean that the first idea seldom is the best, and that the projects

needs time for reflection to let the ideas grow and later change when better solutions can be found. The

authors argue that this might be true since the project members’ gains increased project knowledge the

further in the process they get.

34

The reason for expecting changes to occur seems to be due to experiences from previous projects

where major changes have been necessary. The changes take time and costs money to make. Some of

the interviewed PMs’ have even expressed that they are so sure that changes will occur that they

reserve time-for-changes in their time-plans. This buffer-time is typically reserved in the end of the

program- and system-stages. To avoid this, it is necessary for the PMs’ to organize the work in such a

way that these changes do not come all at once in the end of a project stage. This could be possible

with agile methodologies which say that “changes should be welcomed”. The changes would not

constitute such a time-and money-consuming task if they occurred continuously throughout the

program- and system-stages instead of being handled all at once in the end of these stages.

Even though it is seen as positive to welcome changes during the project, it could also give the feeling

of interruption to the project members. It would especially be interruptive if the changes occurred

sporadically during the work process. From this point of view, it can seem like changes that comes

with agile methodologies are not so welcomed in practice, since they result in an increased effort by

the project team. According to the authors, this should be handled by structuring the communication

properly. The project process should be planned in short cycles and changes should only be discussed

in the end of a cycle (and in the beginning of the next), in this way the change becomes a natural part

of the creative design phase because there is time reserved for welcoming changes. The authors

therefore argue that it is important to stick to discussing eventual changes during reconciliations in the

beginning and end of each cycle. Besides that, the project team should be allowed to work

undisturbedly.

5.2.4 Project team collaboration The managers of the case study project seem to have close collaboration. The importance of good

collaboration has recurred in the literature of agile methodologies. After completing the interviews, the

authors are strongly convinced that good collaboration increases efficiency in terms of decreased

waste of time, cost and labor. In addition, gained efficiency through team collaboration is expected to

be one of the largest drive-forces to get projects forward, since focus is put on solutions rather than

difficulties and dissimilarities.

5.2.4.1 How to reach efficient collaboration

Project team collaboration also seems to play a large role in order to decrease the major changes in the

end of the program- and system-stage. However, the difficulty is that good team collaboration is only

mentioned as being important, but it is seldom stated how that could be reached. There are three points

that the authors believe could help to improve team collaboration and increase efficiency:

Trust

Self-governance teams

Goal-focus

Trust seems to be an important factor in order to achieve good team collaboration, since it is hard to

attain efficient team-work without trusting co-workers. One of the PM’s stated that trusting the co-

workers results in that each team-member has the courage to perform their work in the best way

possible. Putting trust in the team could also help the team becoming self-governing i.e. autonomous.

However, it is assumed that this requires that the team has a common project goal, good

communication and respect for each other.

Self-governance teams give more time for the PMs’ to focus on crucial tasks. This in turn is assumed

to reduce waste of resources since it is seen to increase the possibility to deliver higher quality of the

35

product. Furthermore, this could also contribute to minimizing the major changes that often have to be

made in the end of the program- or system-stages.

Goal focus contributes to good team collaboration. This means that everyone should share the view of

what, why and for whom the project is going to be delivered. Having a shared goal-focus is of large

importance in order to not spend resources on the wrong things, to reduce the risk of disagreements,

and to thereby work efficiently. What was not answered in the interviews was how goal-focus could

be attained throughout the stages. The authors consider that this can be done by working with agile

methodologies which includes frequent reconciliations, and these will constantly remind the team of

the goal.

5.3 Challenges with agile methodologies in construction projects In the following section it is discussed on the challenges with working in agile ways. The mentioned

challenges are both general for all types of projects but some challenges are more specific for the

construction industry. According to the authors, these challenges are important to take into

consideration when working with agile methodologies in construction projects. The reason is that there

are different conditions to work agile in different industries. This can cause problems if it is not taken

into account.

5.3.1 Agile literature is beautified When reading literature about agile methodologies in general, the authors consider it to be beautified

and simplified. This is because working agile is described as simple to implement, and no major

challenges are presented. However, from the interviews, it has come to the authors’ knowledge that

this is in fact not true for construction projects. One of the interviewed PM’s are working agile and

explains that it is difficult for the whole project team to succeed working agile, because of mainly two

reasons. The first reason is that agile ways of working require relations rather communication. This is

a tough task in construction projects where many stakeholders are involved. The second reason is that

close collaboration required in agile methodologies can be frustrating to the team members. In other

words, the team members are forced to build close relations with other team-workers. This is

frustrating because the team members are working on building relations that has to be broken later on,

because the project team will most probably change in the next project.

The PM who works with agile methodologies is currently in a large and complex construction project

(Klevby, 2014). These kinds of projects should according to theory be very suitable for agile

methodologies. However, the PM is very discontent as explained above. It can therefore be discussed

whether this is a proof that agile methodologies are not suitable for large and complex projects in

construction, or if this project is just an exception.

Since agile ways of working has shown to not only be purely positive but also demanding and

difficult, it all seems to come down to a matter of input versus output, i.e. does the extra efforts of

working agile increase the efficiency enough to choose to work agile? And does agile methodologies

reduce waste of resources enough in the end of the program and system-stages? It would be “worth the

extra effort” if the output of working agile is larger than the input and vice versa. This might however

be hard to measure because it is not obvious how to measure “extra effort” as an input since a

comparison is hard to do. This is because all projects are unique and two equal projects would be

needed to be able to measure the possible gained efficiency of using agile methodologies. To do this,

traditional approaches would be applied to one of the projects and agile approaches to the other. The

perceptions and final outcomes would then be compared. Since this is impossible, due to the

uniqueness of each project, it is hard to really know what is more efficient.

36

5.3.2 Time As mentioned in the literature study, time is the locked constraint in agile methodologies. This might

be hard to attain in construction projects since there are factors that cannot be affected in construction

projects. An example of such a factor is the process of getting building permits. It is not possible to

affect this process and it usually takes a long time to get the permit.

5.3.3 Documentation The four factors analyzed correspond very well to the agile manifesto. The arrows below means

“corresponds to”.

Individuals and interactions over processes and tools Project team collaboration (factor 4)

Customer collaboration over contract negotiation Reconciliations (factor 3)

Responding to change over following a plan Welcome changes (factor 2)

However, the second principle of the agile manifesto states that “useful project outcome” should be

valued over “comprehensive documentation”. The authors do not agree to this because construction

projects are different from software-development projects. The reason for not agreeing is that

comprehensive documentation seems crucial to reach useful project outcome in construction projects.

Legal and contractual aspects as well as the long life-span of constructions make comprehensive

documentation necessary in construction.

5.3.3.1 Legal- and contractual aspects

Legal- and contractual aspects makes it necessary to produce more documents than would actually be

necessary for the project due to asymmetrical information between different parties. There are many

legal aspects that need to be followed in order to get building permits and to report to authorities in

order to gain project supporters. The project is forced to produce a lot of documents in order to show

that the project is legally fulfilling the different aspects.

5.3.3.2 The long life-span of constructions

The long life-span of constructions implies that re-constructions often have to be made at some point.

Documentation is then crucial in order to avoid complications that might arise due to lack of

knowledge/documentation of the existing building.

37

6. Conclusion The answers to the research question are presented in this chapter. These are based on the analysis of

the literature study and the interviews with project managers at WSP Management. However, the

authors also points out the difficulty to prove the results.

6.1 Question Research question:

How could agile methodologies affect the amount of major unwanted changes in the end of

the program- and system-stages in construction projects, in order to increase efficiency?

Sub-question:

How could agile methodologies in construction project management affect the client

satisfaction?

6.2 Answers The results of this master thesis shows that agile methodologies are already used to some extent in the

design phase of construction projects. However, the word “agile” is seldom used to describe the

current ways of working.

Two possibilities for improvements have been identified where agile methodologies could be

implemented in the program- and system- stages. These two possibilities could decrease the amount of

major unwanted changes in the end of these stages and thereby increase the efficiency. The first

possibility is to divide the stages into shorter cycles and the second possibility is to have more frequent

reconciliations with the client. These two conclusions are described further in section 6.2.1 and 6.2.2.

However, it should once again be pointed out that the authors also have thought about the difficulties

to prove that the agile ways of working could decrease the number of major unwanted changes. The

reason for this is, as earlier mentioned, that it would require that two identical projects to be carried

out. One of the projects would have to be performed in traditional ways and the second project in agile

ways. This would have to be done in order to really compare the possibilities to decrease the number

of major unwanted changes. However, this is not possible since all projects are unique.

6.2.1 Shorter cycles Dividing the program- and system-stages into shorter cycles is seen to make each stage more

manageable since it is easier to get an overview of the closest upcoming work. Working in shorter

cycles could also facilitate keeping the goal focus since deadlines could be set more frequently

because reconciliations are also being held more often. This in turn could avoid postponing the work

until the end of the program- and system-stages, which means that resources could be used more

efficiently during the project process.

6.2.2 Reconciliations As mentioned before, working in shorter cycles is seen to enable more frequent reconciliations

because the start and the end of each cycle include meetings with the client. This means that the

clients’ gets the opportunity to express their wishes and requirements throughout the stage. This could

result in the possibility to make eventual changes which are made continuously in order to prevent

major changes from occurring in the end of the stage.

38

This could develop a closer relation with the client and hence enable a larger understanding of the

project. It is first when all project members have a common understanding of what, why and for whom

the project is going to be delivered, that the project team could achieve a successful outcome. A

successful outcome could in turn lead to a more satisfied client, since the client would have a larger

possibility to affect the end-product.

In the beginning and the end of each cycle, the different disciplines (whose work are dependent on

each other) could also have more frequent reconciliations to ensure that the program- and system-

stages flows more smoothly. This is because they can synchronize the work and solve eventual

problems proactively instead of waiting until problems occur. This could also contribute to avoid

major changes in the end of the stages and thereby use resources more efficiently.

To sum up: Time, money and human resources could with an agile mindset, be more effectively used.

The reason for this is that major changes are prevented from occurring in the end of a stage. This

means that agile methodologies could lead to a more satisfied client, which would have clear benefits

for organizations who wants to improve the project management process and gain a greater

competitiveness. Besides gained competitiveness, the possible increased client satisfaction could have

advantages such as client retention, good reputation, and further improved communication.

39

7. Future research areas During this master thesis, different problems and issues have been encountered. These difficulties

have however been outside the scope of this master thesis and have therefore not been further

investigated. This chapter will therefore present recommendations for future research within this area.

In order to have more frequent reconciliations with the client and thereby gain advantages, as

described in the previous chapter, the client must obviously have agreed to this way of working. The

problem with more frequent reconciliations with the client is that the client fairly often considers it

unnecessary to be more involved, since they have hired a professional project manager who should

manage the project for them. An interesting aspect for future research is therefore, how the client

could be motivated to be more involved in projects.

This master thesis has been investigating the possibilities to decrease the major changes that occur in

the end of the program- and system-stages. A topic for future research can therefore be to investigate

the reasons for these changes to occur. In this master thesis, different reasons for the occurrence have

been discussed but not investigated further. Examples of discussed reasons are weak stakeholder

analysis, lack of knowledge by the client, difficulties in communication etc. However, knowledge of

the actual reasons behind the changes could have great impact on projects, since major changes then

could be directly minimized.

Another suggestion for future research areas regards how agile methodologies should be implemented

in an organization. Is it more beneficial to implement it little by little, or should the whole organization

try to change their ways of working all at once? Furthermore, when is it a “right” time to start working

agile?

Finally, another area that would be beneficial to investigate regards the second principle of the agile

manifesto; “working software over comprehensive documentation”. In other words, can documents be

produced more efficiently to reduce the need for comprehensive documentation? An interesting aspect

for future research therefore regards the importance of documentation in construction projects.

40

8. References

8.1 Literature Bhattacherjee, A., 2012. Social Science Research: Principles, Methods, and Practices, USA: Global

Text Project

Bryman, A., 2012. Social reserach methods. 4 ed. Oxford: Oxford University Press.

Boehm, B., 2003. People Factors in Software Management: Lessons From Comparing Agile and

Plan-Drivan Methods, Arlington: University of Southern California.

Dvir, D. & Lechler, T., 2003. Plans are nothing, changing plans is everything: the impact of changes

on project success, Amsterdam: Elsevier.

Ekholm , M. & Fransson, A., 2013. Praktiskt intervjuteknik. Stockholm: Almqvist & Wiksell Förlag

AB.

Elliot, S., 2008. Agile Project Management, Hesinki: University of Helsinki.

Gustavson, T., 2011. Agil projektledning. Första upplagan red. Stockholm: Sanoma Utbidning.

Gustavsson, T., 2013. Agile – konsten att slutföra projekt. 2 red. Karlstad: TUK Förlag AB.

Kärnä, S., 2004. Analysing customer satisfaction and quality in construction - the case of public and

private customers. Nordic Journal of Surveying and Real Estate Research - Special Series, 2(3), pp.

67-80.

Miller, G. G., 2001. The Characteristics of Agile Software Processes, Salisbury: Salisbury University.

Opelt, A., Gloger, B., Pfarl, W. & Mittermayr, R., 2013. Agile contracts - Creating and managing

successful projcts with scrum. New Jersey: John Wiley & Sons, Inc..

Owen, R., Koskela, L., Henrich, G. & Condinhoto, R., 2006. Is agile project management applicable

to construction?, Manchester: University of Salford.

Oxford University Journals, 2012. Being Agile. IT Now, 54(2), p. 43.

Oxford University Journals, 2013. Developing WIth Agile. IT Now, 55(2), pp. 13-15.

Project Management Institute, 2013. A Guide to the Project Management Body of Knowledge. 2013

red. Pennsylvania: Project Management Institute, Inc..

Svensk Byggtjänst, 2009. Leda Byggprojekt, Stockholm: Svensk Byggtjänst.

Svensk Byggtjänst, 2010. Studenthandledning Byggprocessen, Stockholm: Svensk Byggtjänst.

Tonnquist, B., 2007. Projektledning. 2 red. u.o.:Sanoma Utbildning.

Wikforss, Ö., 2012. Lecture. Stockholm: u.n.

Winch, G., 2010. Managing construction projects. 2nd edition red. Manchester: Wiley-Blackwell.

8.2 Internet Beck, K. o.a., 2001. Manifesto for Agile Software Development. [Online]

Available at: http://agilemanifesto.org

[Använd 08 05 2014].

41

Boverket, 2014. Byggherre och ägare. [Online]

Available at: http://www.boverket.se/Bygga--forvalta/Bygglov-och-anmalan/Byggherre-och-agare/

[09 04 2014].

Cohn, M., 1998-2012. Scrum. [Online]

Available at: http://www.mountaingoatsoftware.com/agile/scrum

[14 04 2014].

Hughey, D., 2009. University of Missouri-St. Louis. [Online]

Available at: http://www.umsl.edu/~hugheyd/is6840/waterfall.html

[Accessed 23 05 2014].

Investopedia US, 2014. Investopedia. [Online]

Available at: http://www.businessdictionary.com/definition/efficiency.html

[04 04 2014].

Lean Enterprise Institute, 2009. lean.org. [Online]

Available at: http://www.lean.org/whatslean/principles.cfm

[12 05 2014].

Rudd, C., 2012. Solutions IQ. [Online]

Available at: http://www.solutionsiq.com/the-agile-ceo/bid/83993/Agile-vs-Lean-False-Debate

[12 05 2014].

Scrum.org, 2014. What is scrum. [Online]

Available at: http://scrum.org

[12 04 2014].

8.3 Oral Gustavsson, T. K., 2014. Docent [Intervju] (06 05 2014).

Hansson, L., 2014. Meeting [Intervju] (20 02 2014).

Klevby, D., 2014. [Interview] (9 04 2014).

8.4 Figures Owen, R., Koskela, L., Henrich, G. & Condinhoto, R., 2006. Is agile project management applicable

to construction?, Manchester: University of Salford.

Project Management Institute, 2013. A Guide to the Project Management Body of Knowledge. 2013

red. Pennsylvania: Project Management Institute, Inc..

Rocque, B. L., 2013. Three Houses Consulting. [Online]

Available at: http://threehouses.com/docs/RocqueProceeding.pdf

[14 05 2014].

Rudd, C., 2012. Solutions IQ. [Online]

Available at: http://www.solutionsiq.com/the-agile-ceo/bid/83993/Agile-vs-Lean-False-Debate

[12 05 2014].

Svensk Byggtjänst, 2009. Leda Byggprojekt, Stockholm: Svensk Byggtjänst.