TVE-MILI19004

Master’s Thesis 30 credits

May 2019

Managing Design Change in Complex

Production Development Projects
A Study at Scania Gearbox Assembly

Beata Gradin

Master´s Programme in Industrial Management and Innovation

Masterprogram i industriell ledning och innovation
 Abstract
Managing Design Change in Complex Production Development
Project – A study at Scania Gearbox assembly

Beata Gradin

The speed of launching new products will accelerate and so the

complexity of products and productions systems (Sorli et al 2006;
Teknisk- naturvetenskaplig fakultet
UTH-enheten Windt et al., 2008). Change is a natural effect of product
development and it offers opportunities to develop the related
Visiting address: production (Jarratt et al, 2011; Lager, 2002). To increase the
Ångströmlaboratoriet launching, simultaneous development projects with a multi-project
Lägerhyddsvägen 1
structure can be initiated (Araszkiewicz, 2017). This results in
House 4, Level 0
transmitted design changes from the product development project
into the related production development project. In turn, the
Postal address:
production development project needs to manage these transmitted
Box 536
design changes.
751 21 Uppsala

The study has investigated how transmitted design changes shall

Telephone: be managed in production development projects. This was
+46 (0)18 – 471 30 03
performed by exploring theoretical fields of Engineering Change
and Project Management and collecting empirical data from a
Telefax:
studied complex production development project at Scania DT.
+46 (0)18 – 471 30 00

A standardized Transmitted Design Change process is

Web page:
http://www.teknik.uu.se/student-en/
recommended to use in order to achieve better communication in-
between the interdependent projects and manage change with
respect to risk and without harming other processes. Furthermore,
project management methodologies and its characteristics were
discussed in order to support and facilitate the management of
transmitted design changes. The study concludes that both flexible
and traditional project management methodologies shall be
adopted in these complex development projects with high levels of
interdependencies. The combined strategy supports changes and
uncertainties with flexible iterations and controls the projects with
standardized processes and structure.

Keywords: Complex Project, Engineering Change, Production Development,

Project Management, Simultaneous Development, Transmitted Design Change

Supervisor: Karin Lundquist

Subject reader: Åse Linné
Examiner: David Sköld
TVE-MILI19004
Printed by: Uppsala Universitet
Popular Science Summary
The importance of enabling transmitted design changes management will increase as the
demand for short simultaneous development projects increases. The interdependency between
a product development project and a production development project indicates that if something
changes it will most certainty affect the other and vice versa. Therefore, interdependency and
simultaneous project structures lead to transmitted design changes. Additionally, projects with
frequent design changes result in high levels of project complexity which leads to difficulties
in steering and planning a project.
This study contributes with new knowledge to production development projects in order to
master transmitted design changes as a result of simultaneous work tasks and high levels of
interdependency. The findings cover a strategy for announcing and managing the design
changes, as well as recommendations about educating the project employees, suitable project
management methodologies and new determined responsibilities for each individual project
employee.
The study found that simultaneous activities, communication strategy, and the process of
announcing and managing design change shall be standardized. The communication strategy is
an important stage in the suggested strategy and should be performed on a regular basis with a
shared responsibility between the interdependent projects; the product development project
shall provide information and the production development project look for additional
information needed. It is also suggested to adopt flexible project management methodologies
to be able to manage unexpected and frequent changes. Flexibility can be achieved by iterations
and the suggested iteration strategy will be carried out through learning stages between the
design change management and during the selection of change solution. However, too complex
development projects also need standardized processes and control. Therefore, a combined
project management strategy is proposed, to enable flexibility in terms of iterations, but keep
control by standardizing processes and using routines for the announcement and management
of transmitted design changes. This will make complex development projects more efficient in
manage design changes and less delays and late rework will occur.
Acknowledgement
It has been an honor to conduct my master thesis at Scania DT, Södertälje. I am sincerely
grateful for the support all involved persons have provided me and the freedom to select a thesis
topic of my interest. Therefore, I like to thank my principle, Karin Lundquist, at Scania DTTFA,
who gave me this opportunity. You are a true inspiration and a very knowledgeable manager
who have supported my work with accuracy, a lot of freedom and own responsibility. You have
let me grow.

Furthermore, I would like to thank all respondents at Scania DT and Scania Improvement
Office. Your words have been of great importance for strengthen the significance of this study
and further studies in the field of managing transmitted design changes in production
development projects.

Last but not least. I would like to thank my subject reader, Åse Linné, at Uppsala University
who has been a good sounding board and supported me along my way. I have appreciated your
equality among all students, your positivity and optimistic view, as well as your way of giving
feedback.

Uppsala, 26th April 2019

Beata Gradin
Table of Content
1. INTRODUCTION ................................................................................................................ 4
1.1. PROBLEMATIZATION ..................................................................................................... 4
1.2. PURPOSE AND RESEARCH QUESTION ........................................................................... 5
1.3. THE STUDIED PRODUCTION DEVELOPMENT PROJECT .................................................. 5
1.4. DICTIONARY ................................................................................................................. 6

2. THEORY ............................................................................................................................. 7
2.1. CHANGE ....................................................................................................................... 7
2.1.1. Engineering change ............................................................................................. 7
2.1.2. Change effect .................................................................................................... 11
2.2. PROJECT.................................................................................................................... 13
2.2.1. Project character................................................................................................ 13
2.2.2. Interdependencies ............................................................................................. 15
2.2.3. The effects of Project Management Methodology .............................................. 17

3. METHOD .......................................................................................................................... 19
3.1. W ORK PROCESS ........................................................................................................ 19
3.2. RESEARCH IDEALS, STRATEGY AND DESIGN ................................................................ 20
3.2.1. Interviews .......................................................................................................... 21
3.2.2. Scania documents ............................................................................................. 24
3.3. ANALYSIS METHOD .................................................................................................... 25
3.4. RESEARCH MEASUREMENTS ...................................................................................... 26
3.4.1. Reliability ........................................................................................................... 26
3.4.2. Validity ............................................................................................................... 26
3.4.3. Generalizability or particularization .................................................................... 26
3.5. BIAS AND PRE-KNOWLEDGE ....................................................................................... 27
3.6. ETHICS....................................................................................................................... 28
3.6.1. Interviews .......................................................................................................... 28
3.6.2. Confidential material .......................................................................................... 28
3.6.3. Copyright ........................................................................................................... 29
3.6.4. Managing the result ........................................................................................... 29

4. EMPIRICAL STUDY ........................................................................................................ 29

4.1. SCANIA DOCUMENTS .................................................................................................. 30
4.1.1. Scania Engineering Change Order .................................................................... 30
4.1.2. Scania Project Management Methodologies ...................................................... 31
4.2. INTERVIEW RESULT .................................................................................................... 33
4.2.1. The project´s background .................................................................................. 33
4.2.2. Level of interdependency ................................................................................... 36
4.2.3. Direction of change ............................................................................................ 37
4.2.4. How design change affects production development .......................................... 38
4.2.5. Effects of design change solution ....................................................................... 41
4.2.6. Suggested improvement potential ...................................................................... 41
4.3. EMPIRICAL SUMMARY ................................................................................................. 43
1
5. ANALYSIS ....................................................................................................................... 43
5.1. INTERDEPENDENCY AND PROPAGATED CHANGES....................................................... 43
5.2. MAPPING DESIGN CHANGE ......................................................................................... 46
5.3. CHARACTERIZING THE PROJECT ................................................................................. 50
5.3.1. Level of complexity ............................................................................................ 50
5.3.2. Support design change management................................................................. 51
5.4. HOW TO ENABLE DESIGN CHANGE MANAGEMENT? .................................................... 53

6. CONCLUSION ................................................................................................................. 55
6.1. RESEARCH QUESTION 1 ............................................................................................. 55
6.2. RESEARCH QUESTION 2 ............................................................................................. 57
6.3. RECOMMENDATIONS .................................................................................................. 59
6.3.1. Project Management Methodology support ........................................................ 60
6.3.2. Learning: pre-change ......................................................................................... 60
6.3.3. Announcing design change ................................................................................ 61
6.3.4. Managing design change ................................................................................... 61
6.3.5. Implement change ............................................................................................. 62
6.3.6. Learning: post-change ....................................................................................... 62
6.4. ACADEMIC CONTRIBUTIONS........................................................................................ 62
6.5. RESEARCH CREDIBILITY ............................................................................................. 64
6.6. DIFFICULTIES AND DELIMITATIONS .............................................................................. 65
6.7. SUGGESTIONS FOR FUTURE STUDIES ......................................................................... 65

REFERENCES ......................................................................................................................66

APPENDIX ................................................................................................................................. 1
1. INTERVIEW GUIDE – BACKGROUND INTERVIEWS ................................................................... 1
2. INTERVIEW GUIDE – EMPIRICAL INTERVIEWS ........................................................................ 2
3. INTERVIEW VISUALIZATION: DESIGN CHANGE PROCESS ....................................................... 3
4. TEMPLATE: SCANIA DESIGN CHANGE REPORT...................................................................... 4
5. CHECKLIST: SCANIA DESIGN CHANGE MANAGEMENT ........................................................... 4

2
Figures
Figure 1. Process of managing EC (Author’s own illustration) .................................................. 8

Figure 2. The generic engineering change process, (Jarratt et al., 2011, p. 107) .................. 10

Figure 3. Stacey Matrix (Author’s own illustration of Stacey’s Matrix) .................................... 14

Figure 4. Formulating questions for an interview guide (Bryman & Bell, 2011, p.477) .......... 22

Figure 5. Figures supporting the interviews (Author’s own illustration) .................................. 23

Figure 6. Planning qualitative content analysis (inspired by: Bryman 2011, pp.505-506) ...... 24

Figure 7. Simplified ECO instruction (Author’s own illustration) .............................................. 30

Figure 8. PEIP (Author’s own illustration) ................................................................................ 32

Figure 9. PD-process (STD4303en 2013, p. 2) ....................................................................... 33

Figure 10. Simple multi-project structure in Scania FPP (Author’s own illustration)............... 33

Figure 11. TOGS project and the dependent product development project (Author’s own
illustration) ........................................................................................................................ 34

Figure 12. Level of interdependency, respondents’ answers (Author’s own illustration)........ 36

Figure 13. Change directions, figure shown during interviews (Author’s own illustration) ..... 37

Figure 14. Summary of interdependency between product DP & TOGS (Author’s own
illustration) ........................................................................................................................ 45

Figure 15. Combined engineering change management process (Author’s own illustration) 46

Figure 16. Iterations in TDC-process (Author’s own illustration) ............................................. 58

Tables
Table 2. Respondents Background Interviews ........................................................................ 22

Table 3. Respondents Empirical Interviews ............................................................................ 23

Table 4. ECM Process; Scania standards, Scania´s reality, and ECM theory ....................... 49

Table 5. The seven improvements suggestions ...................................................................... 54

3
 1. Introduction
This study instigates the theoretical fields of engineering change and project management with
the aim to investigate how production development projects shall manage transmitted design
changes from an interdependent product development project. The thesis is made in
collaboration with Scania DT, and the TOGS (The Obvious Gearbox Supplier) subproject group
DTTFA.

1.1. Problematization
In earlier years reductions of costs and natural resources have been the biggest interest in means
of becoming a successful company. But with the globalization these factors have changed.
Today, the degree of innovation and the capability to launch new products fast decides if a
product, or company, succeeds or not (Sorli et al. 2006). The latest years, technology
innovation, environmental conditions, and changing requirements, have impacted the demands
on manufacturing companies. It is told that these trends is something that the companies cannot
avoid (Vogel & Lasch, 2016). Furthermore, the complexity of production systems has
increased due to changes, shorter product life cycles and demand of high product variation
(Windt et al., 2008).

The most quoted definition of EC is that it is it change that has to be executed when the design
is released from the development project (Huang et al., 2003). Other researchers claim that EC
can appear in the beginning or during the product development, and late announced change
creates greater concerns as for instance when the product is released to the production because
the changes can affect the whole supply chain with delays and increased costs (Alblas &
Wortmann, 2012). The reason why production lines needs to be change can for instance be
because of new product requirements. The new requirement can for instance be generated from
the development department changing an existing product (Kernschmidt et al., 2014). Lager
(2002) would argue that the dependent project offers opportunities; when the product
development changes it offers opportunities for production process development to change, and
vice versa. Additionally, this interdependency can result in a domino effect of changes/a change
propagation which can be seen as negative and needs to be managed (Kernschmidt et al., 2014).
If EC escalates the management becomes more difficult and creates uncertain plans for the
ongoing project. The domino effect of escalated changes can occur from relatively small
engineering changes and it is important to educate the employees in detecting and monitoring
change correctly (Alblas & Wortmann, 2012). The most used process of managing EC is a
model created by Jarratt et al. (2005), the model supports the management by dividing the tasks
in to six steps, including iterations, learnings, and a risk assessments to lower the risks and
change propagation. Additionally, the literature suggests different project management
methodologies depending on the project´s complexity/frequency of change. Alblas and
Wortmann (2012) means that all projects have a degree of complexity and different impacting

4
environments and projects with allot of changes can be seen as having a fluctuating project
environment. A project with high complexity needs a flexible focused project management
method - the higher complexity a project holds, the more flexible project management method
is needed. If the complexity is low a more control-based/traditional project model can be used.
It is recommended to investigate the projects complexity at the beginning of the project, to
choose and tailor the project management model (Eriksson et al., 2017). Moreover, if the
complexity is too high in terms of certainty (know how to take action) and agreement (how to
solve issues), it is suggested to use a combined project management methodology, e.g. an agile-
stage-gate model (Metz 2018; Stacey 2007).

The literature presents models and theory of how a product development project can adjust to
a design change and does not mention production development projects. It is also shown that
different project management methodologies may support managing design change more
easily. Additionally, clear statements exist how a project´s changing environment shall be
managed and how interdependencies can be embraced and managed. However, although a
complex production development project clearly can be affected by the design changes, theories
are missing about how these projects shall manage the transmitted changes when these
development project are occurring simultaneously. Therefore, the following study will focus
on filling the gap of literature about how a production development project can manage
transmitted design changes from the product development project.

1.2. Purpose and Research Question

The thesis purpose is to provide information of how a current production development project
has managed transmitted design changes (RQ1), and propose how these transmitted design
changes can be managed in a more efficient way to avoid delays (RQ2). This was made by
exploring a specific production development project at Scania DT, Södertälje, which affects by
transmitted design changes from an interdependent product development project. The empirical
data was then analyzing and compared to an extended literature review within the fields of
engineering change and project management.
RQ1: How has an existing production development project managed transmitted
design changes from an interdependent product development project?

RQ2: How shall transmitted design change be managed in production development

projects with respect to project management theory, the project character, and
levels of interdependency to other development projects?

1.3. The Studied Production Development Project

A couple a years ago TOGS, the Future Powertrain Project was initiated at Scania with the goal
to produce a new powertrain consisting of e.g. a new gearbox. Scania DT, the gearbox
assembly, became responsible to adjust and develop the existing assembly line of gearboxes to

5
suit both the existing and the new gearbox in a project called TOGS, The Obvious Gearbox
Supplier. TOGS was announced in year 2016 with the goal to commence GW gearbox
production after the summer of 2019. Up until now, the product design has been developing at
the same time as the adjusting of the assembly/production lines.
Due to restricted schedules, the production development project and the product design
development had to occur simultaneously. To both develop a new product and the associated
assembly lines simultaneously is challenging and unique at Scania which has contributed to a
postponed product introduction. The product development work resulted in frequent design
changes which implies change in interdependent projects. The design changes increase the
multi-projects complexity and most of the delays are told to be associated to design changes of
the product development project. The design changes are neither announced nor solved through
a standardized way. For these reasons, TOGS project and the subproject group DTTFA will be
investigated in means of answering RQ1, and be the object in the analysis discussion.
Furthermore, will recommendations be provided to suit TOGS and DTTFA.
The empirical study took the perspective of the TOGS project and from the eyes of the project
team DTTFA. This implies that interdependent projects in FPP and other TOGS-subproject
groups view were left out and the perspective from the discussed product DP. Additionally, the
main focus has been to study the design changes caused by the product DP transmitted in to
TOGS.

1.4. Dictionary
Notion Description
CE Concurrent Engineering
DC Design Change
DP Development Project
DTTFA Scania DT´s Technical department Final Assembly (TOGS subproject group)
EC Engineering Change (the theoretical term of DC)
ECM Engineering Change Management
ECO Scania´s Engineering Change Order standard
F-gen Function generation (stage in PD-process)
FMEA Failure Mode and Effect Analysis
FPP Future Powertrain Project
GW New (currently developing) gearbox, will be produced at Scania DT
GZ Existing gearbox in production at Scania DT
PEIP Scania´s Production Equipment Investment Process (standard)
PD-process Scania´s Product Development Process (standard)

6
 PFMEA Scania´s Process Failure Mode and Effect Analysis (standard)
PMM Project Management Methodology
Product DP Scania R&D´s product development project
RFQ Request For Quotation (requirement specification)
TDC Transmitted Design Change (suggested process)
TOGS The Obvious Gearbox Supplier (the studied production development project,
subproject to FPP)
V-gen Verification generation (stage in the PD-process)

2. Theory
This chapter covers a deeper understanding of the theory connected to the thesis purpose and
research questions. The theory has been collected to create a better understanding of the studied
area and to provide relevant data for the analysis. The literature has been divided into two main
sections; Change and Project: Change involves theory about engineering change (EC),
Engineering Change Management (ECM), Change Propagation, and Incremental and Radical
changes. It is revealed that even small engineering changes can escalates to crucial events and
needs to be managed carefully. Change can be controlled by investigating risks and evaluating
the best solution.

The Project section first discusses a project character by investigating complexity and
turbulence. A projects turbulence and complexity is important to understand in order to
organize and steer a project with correct management and methodology. Secondly,
interdependency was studied to understand how a product development project affects the
production development project, and how EC can propagate to other projects. Furthermore,
Multi-Project Environment gain an understanding of the complexity and Concurrent
Engineering, CE, was studied as a strategy to manage interdependent projects with
simultaneous tasks which supports the project structure, communication, and planning. Lastly,
flexible vs. traditional project management methodologies are discussed. The findings show
that complex projects with high levels of change are best managed with a flexible management
methodology and that projects with high interdependencies and multiple simultaneous tasks
need a well-functioning communication, standardize processes, and lowered level of decision-
making.

2.1. Change
2.1.1. Engineering change
Historically changes have been seen as something normal within product development projects
or as changes the production department was responsible for. Engineering Change, EC, refers

7
to making adjustments to a product and engineering change management, ECM, to the
organizing and control of the ECM process (Jarratt et al., 2011).

The definition of EC is wildly discussed in the theory of EC and ECM. Harmaz et al. (2012)
made an extensive literature review regarding ECM and mapped the different definitions in the
means of finding a common understanding. Earlier literature states that EC is modifications in
the functionality, material, software or dimension and appear after the product is launched in
production, or, when it released from the product development. However, some have also stated
that EC can appear during the product development/product design process and life cycle
(Alblas & Wortmann, 2012, Jinping et al., 2017).

The most quoted definition of Engineering change originates from Huang et al. (2003, p. 481).

“Engineering changes are the changes and/or modifications in dimensions,

fits, forms, functions, materials, etc. of products or constituent components
after the product design is released.”

Moreover, the most common view is that an EC can escalate into further changes in the product
development or production and are therefore a critical task for the project to solve (Harmaz et
al., 2012). Because EC can affect changes across various functions in a manufacturing firm,
adjustment activities needs to deal with identified EC and its impact (Huang et al., 2003). Even
smaller engineering changes, that are seen less critical, can lead to great concerns if they
propagate/escalate (Gil et al., 2006). Additionally, it is stated that if an EC happens during a
production development project, the EC needs to be managed in a way to neither harm nor
propagate into the production line. However, if a change unfortunately escalates to changes a
in the production line, it has to be managed in a “correct way” (Kernschmidt et al., 2014). Some
literature has seen that Engineering Changes are best managed in separate projects to easily
control, plan and monitor the EC (Alblas & Wortmann, 2012). Other suggests tools and
assessments in order to investigate the change effect and managed the propagation (Harmaz et
al., 2012). Multiple processes exist on how to manage an engineering change. All these
processes are divided into different phases or stages and include investigations of the change,
approval for change and execution (Jarratt et al., 2011), one is presented further down in this
section. Harmaz et al. (2012) instead sees the process of managing engineering changes in three
stages and have proposed five goals of ECM;

Figure 1. Process of managing EC (Author’s own illustration)

Goals of ECM (Harmaz et al., 2012):

 Less – to achieve less ECs. Avoid the EC before it occurs and reduce the number of EC;

8
  Earlier – Is about identify EC and manage EC in time, before the change propagates into
further changes;

 More Effective – To decide an effective way of implementation and solution;

 More Efficient – Means to implement the required EC efficiently;

 Better – Is about learning from implemented ECs for future ECM.

Pre-change stage refers to the first goal of ECM and means to ese or prevent Engineering
Change from occurring, and it is divided in to three extended categories; (1) People-oriented,
to which educate the employees in how to discover and handle ECs, (2) process-oriented, which
focuses of product development optimization and process modelling, and lastly (3) product-
oriented covers concepts of the projects architecture, such as; design for variety, design for
manufacturing, modularization, and requirement management. The second stage is In-change
stage and refers to the goals Earlier, More Effective, and More Efficient. This stage involves
several tools, methods, systems and strategic guidelines on how to manage the ECs. The in-
change stage is further categorized into; Organizational issues, Strategic guidelines, ECM
systems, Methods & IT Tools, and ECM Process (presented below) (Harmaz et al., 2012). The
last stage Post-change stage covers the last goal, Better, and is about becoming better in
managing ECs in the future (Harmaz et al., 2012).

The ECM process developed by Jarratt et al. (2005) is the most quoted and comprehensive
model. The process is divided into three stages with a total of six process steps (Harmaz et al.,
2012, Jarratt et al., 2011), see figure 2. The ECM process model looks linear to its
characteristics, but possible iterations between two of the steps makes the model more flexible.
Flexibility is important to achieve in means of selecting the best solution return to steps
(iterations) if needed. The first iteration can be seen from step 3 back to step 2 and the second
from step 4 back to step 3. The iterations are good if a decided solution turns out to be too risky
or when a further risk assessment is needed. The ECM process also includes break points, this
are similar to gates in a stage-gate model, and by every break point can the EC be stopped
and/or reviewed and continued (Jarratt et al., 2011).

9
 Figure 2. The generic engineering change process, (Jarratt et al., 2011, p. 107)

The ECM process starts with a change trigger. In the first step in the EC process is to establish
a request for the engineering change. It is common to have a standardized format of how to
make the request. The request has to include the reason for the change, priority of the change,
type of change, what components or systems that will likely be affected. This shall be sent out
to the “change-controller” who enters the information about the Engineering Change in to a
change database (Jarratt et al., 2011).

The second step is to identify possible solutions to solve the engineering change. A single
solution is often examined, in means of saving time or because the solution was the obvious
answer for the EC (Jarratt et al., 2011). However, if is recommended to evaluate different
options. This stage is often omitted which may lead to escalating changes and an uncontrolled
change propagation (Kurdve et al., 2016). Both Eriksson et al., (2017), Zhang (2013), and
Pollack (2007) recommends that the decision shall influence stakeholders and that complex
projects should adopt a flexible project management method to enable managing changes, last
stated recommendation is also agreed by several other studied authors. When a solution is
selected, the risks should be assessed and investigate the impact and dependencies to the
production, suppliers, and the budget. Furthermore, it is discussed that late announced or
discovered EC´s creates more damage (Jarratt et al., 2011). This goes in line with the statement
that EC´s creates larger concerns if they appear when the product is released to the production
(Alblas & Wortmann, 2012). To evaluate the change propagation of a decision can a risk
analysis (ie. FMEA – failure mode effect analysis) be used. It is necessary to use a risk
assessment tool when managing radical changes and improvements, but it is not as necessary
for incremental changes (Kurdve et al., 2016)

10
In the fourth step selection and approval of solution and second phase during approval, a
suggestion shall be approved and a cost benefit analysis be carried out. The decision is often
taken by the projects steering committee. If the board does not agree, or if the cost benefit
analysis presents unpleasant numbers can the iteration path lead the process back to the third
step again (Jarratt et al., 2011).

The last phase, after approval, includes step five and six. The fifth step, to implementation the
engineering change can be done immediately after the approval or planned later depending on
the nature of change and the product life cycle (the process of designing/developing a product).
An important aspect in this step is to ensure that all paper work (i.e. drawings, assembly
schedules) are updated to the latest engineering change. Lastly, when the change has been
implemented for a period of time, should it be reviewed and evaluated. It is stated that few
companies fulfil the last steps (Jarratt et al., 2011).
2.1.2. Change effect
Change propagation is the domino effect, or escalation of changes, from e.g. a design change
(or EC). The change propagation can be divided into two categories; ending change propagation
and unending change propagation. Ending change propagation are changes that are brought to
a conclusion within an expected time. It can both be a high number of changes or a quickly
decreasing number of changes. Unending change propagation, is the opposite. The conclusion
points are unclear and are more likely to escalate into larger and changes (Jarratt et al., 2011).
Depending on the degree of initiated change, the change can create downstream effects such as
redesign and project delays (Chua & Hossain, 2012). This is the reason why small Engineering
Changes can culminate into mayor changes. The changes affect various levels and lead to
frequent changes between the components interfaces. The higher level of uncertainty the change
propagation has, the higher uncertainty will spread to other connected projects (Alblas &
Wortmann, 2012). This means that all EC needs to be considered and managed with respect to
its potential change effect (Chua & Hossain, 2012).
The reason why change propagation is usual in design projects is because of the
interdependencies between multiple parts and activities associated with the products design and
because of the uncertainty to develop something completely new. An EC can affect
interdependent activities both internally and/or externally (Chua & Hossain, 2012). The
external changes are more difficult to predict and control, and can arise at any stage during the
design project. External change can for instance be new customer demands, construction
methods, field conditions etc. (Chua & Hossain, 2012). A new customer requirement could for
instance be improved safety, quality, performance, or/and a quicker delivery (Alblas &
Wortmann, 2012). Another author states that external change can be effects on other products
within the same product family, the common manufacturing process, or business-related change
with e.g. connected suppliers (Jarratt et al., 2011). Effects of internal EC are more predictable

11
and belongs to the engineering process, closed design loops, related components and sub-
systems (Chua & Hossain, 2012, Jarratt et al., 2011).

The aspect of change propagation is important when managing engineering changes. Poor
decisions may increase the propagation negatively (Jarratt et al., 2011). The change propagation
can be inhibited by correct use of ECM process, see section 2.1.1. The second step in the ECM
process, identification of possible solution/solutions to change request, need to be thought
through carefully and evaluate with different solutions, both for radical changes and
incremental changes (Kurdve et al., 2016). Additionally, it is proposed to even out the changes
into incremental changes which is told to lead to less change propagation than radical changes.
However, at the same time it is discussed by several authors that radical change leads to higher
levels of innovation. Moreover, incremental and radical change are called mental approaches
of how manufacturing companies needs to execute process or product changes (Kurdve et al.,
2016, p. 160):

“Change as little as possible, improve in many small steps”

“Take a large step, and include as many improvements as possible”

The first quote represents incremental change and the second is about radical change. Radical
change is named to be explorative and top-down driven, incremental changes have instead
predicted outcomes and are operator driven. Incremental projects can however, lead to the
opposite, to radical change, if the predicted outcome becomes absent. Furthermore, incremental
change can be seen as continuous improvements and can for instance be to improve the existing
production line, shorten lead-times or increase productivity, in small steps. If an incremental
approach is selected for a certain project, is it important to ensure that the project has sufficient
time, because incremental changes takes a longer time to implement than radical changes,
however it lower the risk and cost of a project (Kurdve et al., 2016).
Radical changes can be implemented to improve or adjust an existing production system,
however, during a shorter period of time and increased complexity of change (Kurdve et al.,
2016). Furthermore, a radical change can be for new product development or to manage radical,
large impacting, engineering changes in a separate project. It is also stated that great
technological changes can create EC´s and further propagations, due to the radical new
technology and adjustment to it (e.g. Albas & Wortmann, 2012, Buganza et al., 2009, Metz
2018, and Stacey 2007). So, it is again recommended to evaluate the risks of making radical
changes, before executing them. This could for instance be made through a standardized risk
assessment sheet, e.g. FMEA - Failure Mode Effect Analysis (Kurdve et al., 2016).

Different project management methodologies are recommended for incremental focused

project as well as for radical change projects. Traditional models, such as stage-gate are more

12
suited for incremental change, and flexible managerial methods for radical changes, to ese the
management of change and turbulence (Buganza et al., 2009).

2.2. Project
2.2.1. Project character
Project based work has become very common in organizations today. A project can be defined
as a temporary organization which executes a certain task with limited resources and within a
specific time period. The character of a project varies a lot and depends for instance on the
projects objectives, time period, involved tasks, assigned resources, need for support etc.
(Hallin & Gustavsson, 2012).

The tasks and objectives of projects can sometimes be uncertain, lead to complex project
structures and impact the surrounding environment with turbulence. The notion of
environmental turbulence is used to explain project with rapid changing demands from both
customers and technology. Turbulence from customers is called market turbulence and
describes by customers’ preference shifts. Technology turbulence depend instead on
technology innovation which impacts the new product development. A project with a high
uncertainty from both technology and customers leads to a high turbulence environment. To
ease the management, it is best to see turbulence as a result of uncertainties rather than a
synonym of uncertainties (Buganza et al., 2009).
Each project needs to tailor its own way of managing environmental turbulence, but some
guidance is provided by Buganza et al. (2009). Marketing turbulence is seen to be best managed
trough delay concept freezing, executing early experiments, and tests with customers, adapt
cross-functional project teams, and create a flat organizational structure. To delay concept
freezing (when the concluded design is decided) is a way to achieve project flexibility because
predetermined deadlines is said to inhibit the degree of innovation and ability to manage change
and technological innovation. A cross-functional project team and flat organization is
recommended to guarantee knowledge exchange, better communication functions and reduce
need for coordination by simultaneously achieving process rapidity.

A projects complexity increases with growing unexpected behaviors and characteristics. The
degree of complexity varies in every project, but complexity exists in all types of projects.
Although the subject has been studied extensively, there is little known what determines the
complexity of the project. Even the Project Management Institute (PMI) argues that complexity
in projects will not go away, it will only increase (Bakhshi et al., 2016).

Complexity is a notion that can be confused with something that is complicated. Therefore, to
provide a common understanding and shared language on how to manage the complexity the
project´s complexity has to be understood and investigated (Maylor & Turner, 2017). Bakhasi
et al. (2016) complied earlier researchers’ factors for project complexity (125 factors) and found

13
seven drivers for complexity; Context, Autonomy, Belonging, Connectivity, Diversity,
Emergence and Size. Context is about the environment where the project is working in, if the
objectives and project path is unclear will the project be complex. Belonging is about
centralized and decentralized projects, complex projects are decentralized where people have
chosen to be included and do so for the sake of its own purpose. Emergence accounts for
predicted results, simple projects can foresee parts of the results, but complex projects are
indeterminable and not predictable. In complex projects is it important to achieve an emergence
capable to support to identify errors and results, as well eliminate bad behaviors. The last driver
is size and depends on the objectives, complex projects have unlimited objectives.

Another way to categorize a project´s complexity is developed by Ralph Stacey wo designed

the matrix called “The Stacey Matrix”, see figure 3. By looking at the degree of certainty (x-
axis) on a project and level of agreement (y-axis) in the project, the matrix supports the decision
of what project management methodology (traditional or flexible) a project should adopt.
Projects are closer to certainty when the linkage between cause and effect can be determined.
It is usual that a project is closer to certainty when events from the past occur, because the
project team knows how to take action. This means that new or even unique events and issues
are far away from clarity. It is bad practice to try solve the new/unique events/issues with
knowledge from previous experiences, here other management is needed. The agreement axis
scale is from close to agreement and far away from agreement and represents if the group, team
or organization have agreed upon how to solve an issue (Stacey, 2007).

Figure 3. Stacey Matrix (Author’s own illustration of Stacey’s Matrix)

Furthermore, the arrow (going from the simple zone to the chaotic zone) represents how clarity
becomes chaos by passing a complicated and a complex zone. The five circles with numbers
visualize areas of decision making and management types. The first circle is Technical rational
decision making, which means that past information from earlier projects can support upcoming
issues and events in the current project. Projects categorized in this first area can be planned

14
with specific actions and expected outcomes (Stacey, 2007). Other sources have complimented
this area to be managed with a traditional project management method, such as waterfall project
management methodologies (Metz, 2018). The second zone, Complicated, has two circles.
Circle two is Political decision making, and relates to projects that are close to certainty but
more distanced to agreed. Here compromises are common in order to find an agreed solution
to solve the issue. As an opposite to this, the third circle is Judgmental decision making, issues
that are closer to agreement and further away from certainty on how to solve them. These are
solutions that the group, team or organization agree on but where the solutions cause and effect
are difficult to determine. In these projects is it best to follow common visions and objectives,
then preset plans (Stacey, 2007). The second circle is said to be managed traditionally (with
waterfall project management), and the third circle with more flexible management such as
Agile-principles (Metz, 2018). The third zone is complex, and includes the forth circle. The
complexity zone is a wide area and projects in this area could achieve high creativity, innovation
and breakthroughs. Therefore, managers will need the capability to adopt to different project
management methodologies (both traditional and flexible) to both handle control (traditional)
but also enable changes and creativity (flexible) (Stacey, 2007). Complex projects are said to
be run with Agile-scrum, flexible management, project principles (Metz, 2018). The last zone,
Chaotic, relates to projects with high levels of uncertainty and disagreement. Chaotic projects
often result in breakdown or anarchy because the involved group, team or organization can’t be
managed through ordinary planning, visioning, and negotiating. An organization should try to
avoid these kinds of projects (Stacey, 2007).

2.2.2. Interdependencies
A project can exist as a single-project, or as the most usual – as a part of a multi-project
environment (Aritua et al, 2008). In multi-project environments, several interdependencies
exist. An interdependent project is a project which success depends on another project(s)
(Aritua et al., 2009).
Araszkiewicz (2017) express the importance of managing multi-projects in today’s business
environment and consider that it has a significant impact on a company’s competitive
advantage. Furthermore, the main reason why multi-projects are formed is because of
uncertainties and interdependencies between projects (Araszkiewic, 2017). Another reason for
initiating multi-projects are said to be to achieve business objectives, while the involved
projects has the purpose to enhance the main business operation or service provision. So, the
purpose of managing multi-project is to create an overall organizational strategy for involved
projects (Aritua et al, 2008). Despite the importance and objectives, all multi-project are
classified as complex due of the issues related to project planning, coordinating and controlling
several projects simultaneously (Araszkiewicz, 2017).

There exists five types interdependencies; resource interdependencies, market or benefit,

interdependencies out-come dependencies, learning dependencies, and financial dependencies
15
(Killen & Kjaer, 2012). The most interesting interdependencies related to the thesis is; out-
come dependency and learning dependency. Killen and Kjaer (2012) explains that an out-come
dependency is when a project is dependent of the end result of another project, and learning
dependencies is when a project need the capabilities and knowledge from other projects. Out-
come and learning dependencies can for instance be identified between a product development
project and production process development project. All types of development projects in
industries imply an integration of products and production development – the product
development affects the production process development and correspondingly, production
development affects the product development. For instance, new developed products that differ
from previous products generate a demand for new machinery and production layout (Chronéer
& Bergquist, 2012). However, confusion can appear between distinguishing product
development and production development. Although, the product development offers
opportunities for production process development and vice versa. Therefore, is it important to
understand the differences (Lager, 2002).;

 Product development projects are stated to have an extrovert focus with the means to
attract customers. This kind of development often starts with a customer dialogue and
may include activates such as of material science, simulations, and design work.
(Chroneer & Bergquist, 2012). This type off development project can furthermore be
driven through a desire to improve the existing product, such as product properties,
quality, composition, sustainability etc. (Lager, 2002).

 Production development projects have an introvert focus to improve or adjust the

industry´s production process. The objectives that initiate an execution of production
development projects is cutting costs, eliminating waste, increase the process flexibility,
minimize variation, improvement of production volumes, environment-friendly
production, or effects from the production development project (Chroneer & Bergquist,
2012, Lager 2002).

Concurrent Engineering is a strategy to manage interdependent projects. The approved

definition to Concurrent Engineering, CE, is created by the Institute for Defense Analysis, USA
(Sapuan et al., 2006, p. 144):

Concurrent engineering is the systematic approach to the integrated,

concurrent design of products and related processes including manufacture
and support.

It is said that CE comes from the time when industries developed and became larger. Formerly,
engineering both developed the product and its related manufacturing process. But as the
industries grew, work became specialized. Designers developed the products and
manufacturing engineers designed the related manufacturing process. CE became the link
between the specialized functions (Sapuan et al., 2006). CE creates a simultaneous work in the

16
development of a new product. It means that the manufacturing engineers can work to create
the optimal manufacturing process as the same time as the product´s design is developing
(Fischer et al., 2018). It is also stated to be a key to success on the market, to be able to develop
the correct product and launch it in right time (Singhry et al., 2016). Automotive industries who
adopt Concurrent Engineering in their development project and business prove to reduce the
time-to-market, lowering costs, and improve quality (e.g. Sapuan et al., 2006; Bhuiyan et al.,
2006).

Implementing concurrent projects should be executed as follow, in several steps. The first steps
are to define and formalize the process and overlapping activities. This is made to evaluate and
plan how and when the different activities should occur and be overlapped. When the first two
stages are evaluated, it is important to standardize the process, because it is stated that by
Bhuiyan et al. (2006, p. 41);
“A standardized process delivers better quality projects, which in turn
means better product”

Then, a single person shall be defined as the point of contact when an issue occurs. This person
is responsible for updating and ensuring that the process is executed. Without the responsible
person information cannot be foreseen and communication be impaired. High level of
communication is a main aspect in means of implementing a successful concurrent engineering
process because communication is told to increase the understanding of working in overlapping
activates and shall include of face-to-face and two-way communication, or/and shared data
environments, so all involved members have access to all information shared in the project
(Bhuiyan et al., 2006).

After the establishment of CE is set, people and technology have to be selected and
educated/adjusted. People involved in this project are said to work in multi-functional teams to
enable a broad knowledge in the project group (Bhuiyan et al., 2006).

2.2.3. The effects of Project Management Methodology

Project Management Methodologies, PMM, are defined by the Project Management Institute
as set of methods, techniques, procedures, rules, templates, and best practices used in a project
(Project Management Institute, 2008). Hallin and Karrbom (2012) describe that PMM should
create a common language and intend to support the implementation of the project by dividing
all work tasks into steps, like for instance important operations, prioritization and decisions
taking. The presented views of PMM go in line with Packendorff’s (1995) suggestion about
what project planning and control is. He argues that project planning and control are collected
methods to find the optimal sequence of activities and effective use of resources. Additionally,
is it stated that projects have to be managed depending on the specific project environment and
context. All projects are unique, which indicates that projects within the same company have
to be evaluated and managed differently (Buganza et al., 2009). In line with, Buganza et al.
17
(2009), Jarratt et al. (2011), and Metz (2018), Albas and Wortmann (2012) state that projects
with a fluctuating environment, which implies increased turbulence, complexity, and far from
certainty and agreement, have to develop a flexible project process to manage upcoming
changes. Furthermore, the authors argue that projects with a fluctuating environment are not
applicable to traditional linear project management approaches, due to the volatile environment.

A traditional project management methodology can for instance be a waterfall method or stage-
gate. A stage-gate model is a model that supports a sequential linear process with pre-set
objectives with a clear timeframe. The process consists of different stages with milestones or
gates in between. Milestones are sub-objectives and gates can for instance decide if a project
should continue, be reviewed or dismissed (Hallin & Karrbom, 2012). Stage-gate models are
more suitable in simpler projects with smaller changes and with a stable environment (Buganza
et al., 2009). The waterfall methodology is built on the principle that one step or task has to be
completed before moving on to the next one. Just as the stage-gate model enables the waterfall
method to evaluate if the project can move on to the next step or not (Hallin & Karrbom, 2012).
This kind of traditional management method has become more and more criticized (Conforto
et al, 2014). Some researchers claim that the traditional models are no longer effective, due the
new key factors of success, innovation and faster launches, and quick new product development
(Cooper & Sommer, 2016). The dynamic market environment with constant launches of new
innovations implies that the established manufacturing firms have to become innovation
masters in the continually changing industrial environment (Brandl et al., 2018). Because the
contemporary markets and organization are developing in an unpredictable way and with the
combination of new developing innovations and technology, companies are facing an increased
project complexity. This complexity needs a new flexible project management approach
(Saynisch 2010). Further, it is also stated that established manufacturing firms have generated
an increased interest in adopting flexible/agile principles to handle higher product and
production complexity, customization and also mitigation of risk (Brandl et al., 2018).

Regarding the literature, it seems like contemporary industrial companies should adopt a
flexible PMM approach to enable the increased fluctuating environment both internally and
externally. Suggestions exist that the company has to learn when a project needs more
flexibility, and when traditional linear principles can be performed (Špundak, 2014). Another
possible approach to keep Packendorff’s (1995) suggestion about project planning and control,
but simultaneously adopt flexibility characteristics is to adopt a hybrid approach. To combine
flexible methodologies (agile) with traditional linear (stage-gate) principles can be called a
hybrid, agile-stage-gate or scrum-stage-gate (Brandl et al., 2018). Several authors state that a
hybrid approach would be the solution for the contemporary industrial companies to manage
change (e.g. Brandl et al., 2018, Conforto et al, 2014, Cooper & Sommer, 2016, and Sommer
et al 2015, etc.). A hybrid PMM is a combined management methodology that consists of agile
project management (APM) and the traditional management method stage-gate (Brandl et al.,

18
2018). It is told that a hybrid would lead to a more effective management methodology that also
meets the customers need. Cooper and Sommer (2016) mean that the traditional stage-gate
model phases will take place at project management level and governance, and that agile
method, e.g. scrum, will take place in the project execution, in the project teams. To use the
hybrid PMM also provides several beneficial profits. For instance; better internal
communication, better personal moral, and a more efficient planning by using flexible planning
models with no pre-set deadlines. To not pre-set deadlines leads to meeting the requirements
and focus on the customer.

3. Method
The method chapter begins with a summary about the thesis process. The thesis process covers
the work from generated idea to solved research questions. Additionally, the method chapter
presents the selection of theoretical content, empirical data, and lastly, short about the analysis,
conclusions, and recommendations. Furthermore, the study´s research ideals, strategy and
design, reliability, validity and generalizability will be discussed. Lastly, arguments about the
thesis bias, pre-knowledge and ethics are raised.

3.1. Work process

The thesis idea comes from the authors interest of project management and project success.
After being introduced the TOGS project during a summer internship 2018, several thesis ideas
were generated within the field of project management. In later discussion with Scania
DTTFA´s group manager, one thesis idea was selected and the investigation started. The initial
idea was to examine Scania’s project management methodologies/processes and identify
improvement suggestions. However, due to the topic broadness and lack of limitations, several
interviews were conducted to understand the “real problems” within TOGS project. After these
interviews, a discussion was held with the thesis supervisor, and the idea was refined several
times. When the idea was finally approved the study could begin. The work process is described
in a linear way to simplify the process, obviously, the process was more complex and involved
several iterations in-between problematizing, theoretical framework, empirical data, and the
analysis.

The theoretical framework started by investigating Engineering Change, EC. EC theory built
an understanding about the problem and lead to further theoretical research areas connected to
EC and EC Management. It was identified that EC depends on interdependencies between
different projects, is connected to a project´s complexity, and the change can be incremental or
radical. Moreover, the interdependencies can be managed by concurrent engineering or
controlled in a multi-project environment. Lastly, project management methodologies were
investigated with the purpose to support the different suggested management methods stated in
the theory of project complexity and EC. The theory was then divided into two groups; Change

19
and Project. However, the dependency between change and project management is highly
important in this study. The theoretical framework was limited by the thesis limitations, found
in section 1.3.

When the theoretical framework was written the empirical work began at Scania DT in
Södertälje. The author focused on Scania´s subproject group DTFFA´s view of actual design
changes (as the theory would have named Engineering Change, EC) between their project
TOGS and the design team´s product development project at Scania R&D. Several additional
interviews were held and a document analysis was conducted on Scania DT´s standards,
instructions, and routines. To give the reader an understanding of Scania´s standardized project
management philosophies and other work processes related to this study, the document analysis
was presented before the interview data in the empirical chapter.
Later the empirical result was interpreted and analyzed in comparison to the theoretical
framework. Interdependencies and propagated change was firstly analyzed, then the studied
design change examples at Scania DT was mapped, followed by an analysis about project
management principles in relation to complexity and change, and lastly, DTTFA´s
improvement suggestions were analyzed. When the analysis was made, conclusions were
drawn. The conclusion answered the thesis research questions and then formulized
recommendations for Scania DTTFA (and the interdependent product DP). Lastly further
studies, research credibility, and contributions were put forward.

3.2. Research ideals, strategy and design

The research ideal depends on the research aim and purpose (Bryman & Bell, 2011). The thesis
has two main purposes, firstly to present how a real project production development is
managing design changes transmitted from an interdependent project, and the secondly to
propose a more effective way of managing transmitted changes in production development
projects. This means that the study needed to understand the target group (Scania´s subproject
group DTTFA) and investigate related theory to build a “theoretical framework”. Therefore,
qualitative strategy was used with a combined inductive and abductive ideal. Bitektine (2008)
categorized qualitative research strategy combined with an inductive approach as one of the
most usual research paradigms in social science methodology. Qualitative research is explained
to interprets and understands humans and the results from an inductive study, and abductive,
can be simplified to be a “new theory” (Bryman & Bell 2011).

The selected method firstly supported identifying the research questions, thesis purpose, and
narrow the thesis scope down. This was made by conducting interviews, inspired by the
methods of semi-sutured interviews. Then, when the thesis purpose was stated, the ideals and
strategy made it possible to understand the researched area at Scania DT with a second set of
interviews (see more about the interview strategies in section 3.2.1). The inductive ideal
enabled a freedom to analyze the respondents’ reality and Scania document in the analysis, and

20
the abduction´s flexibility to move back and forth between empirical data and the theoretical
framework helped constructing the analysis, and resulted in a conclusion and recommendations
to the studied project at Scania.

With support and knowledge from the theoretical framework and the empirical data collected
through the interviews and collected Scania documents, the first research question has been
answered:

RQ1: How has an existing production development project managed transmitted

design changes from an interdependent product development project?
As a result of analyzing the empirical data trough theoretical framework the second research
question was answered. However, the question is only answered within the restrictions enclosed
by the study’s limitations, see section 1.3:

RQ2: How shall transmitted design change be managed in production development

projects with respect to project management theory, the project character, and
levels of interdependency to other development projects?

3.2.1. Interviews
The most common method for gathering data in qualitative research is to conduct interviews.
The qualitative interviews are less rigid, often flexible, and aim to investigate and understand
the respondents point of view (Bryman & Bell, 2011). The methodology of semi structured
interviews inspired the 13 conducted interviews at Scania that were conducted in to two rounds.
Gerring (2017) explains that qualitative interviews often research small sample groups and adds
that a single person can be interviewed several times for one qualitative research, to get deeper
understanding and ensure that the collected data is correct. Two respondents participated in
both rounds of interviews because of their position and knowledge in the examined subproject
group.

The purpose if the first round of interviews was to identify an issue which later could be
examined. These interviews will be called “background interviews”. However, the background
interview data shall be seen as empirical data. The second set of interviews collected the
empirical data, “empirical interviews”, and were closely connected to the thesis purpose. For
both rounds of interviews several interview guides were tailored to suit the respondents’
knowledge and field of responsibility. All questions were asked in an open way and formulated
to avoid leading or loaded questions. Additionally, supplementary questions were asked to let
the respondents embroider their answer. This was made to enable full capacity of the semi
structured interview and not steer the respondents. Furthermore, all interviews were audio
recorded and transcribed (ethic issues and bias are presented in section 3.6.1.).

Background Interviews, see the interview guide in appendix 1. Seven backgrounds interviews
were kept with Scania employees from different departments, mostly managers from the

21
gearbox-production site, but also one employee at Scania improvement office, see table 1. The
seven interviews covered a broad view of how Scania in general works within projects and how
TOGS project is executed. In total 7-12 open pre-planned questions were asked, all associated
to Scania´s standardized project management methodologies and TOGS. Not all respondents’
answers were suitable to include in the study, but all interviews helped create the thesis purpose.

Reference/Employment Division Date

Manager DTT 05-02-2019
ex-Manager DTT 31-01-2019
Specialist DTT 31-01-2019
Group manager DTTFA 05-02-2019
Project Manager DTTFA 31-01-2019
PPS responsible Imp. Office 30-01-2019
Head of industrial engineering DFM 05-02-2019
Table 1. Respondents Background Interviews

Bryman and Bell (2011) suggests reviewing the interview guide several times and execute a
pilot interview before conducting the real interviews (a suggested process of how to formalize
an information guide is seen figure 4.). Before conducting the first set of interviews, the
interview guides were proofread by DTTFA´s group manager. The questions were revised and
a pilot interview was conducted with the group manager in order to achieve good data quality
and adequate questions.

Figure 4. Formulating questions for an interview guide (Bryman & Bell, 2011, p.477)

Empirical interviews, see interview guide in appendix 2. The empirical interviews were the
core data in this study and should be seen as the fundament for the analysis and provided
recommendations to Scania. The interviews were conducted when the thesis purpose was
defined and the theoretical framework was written. Six carefully selected employees from the
DTTFA group participated. Onwuegbuzie and Leech (2009) express that the best sample group
is selected randomly. However, they continue, a qualitative sample group is usually small and
could therefore consists of the “accessible population”, which is the participants that is available
to the researcher. The sample group was selected by DTTFA´s group manager after a request
from the author. The request searched three to five subproject managers with insight in design
changes and how change affects the production development project. Four subproject managers
were selected. Additionally, the group manager herself and DTTFA´s project manager also
participated, see table 2.

22
 Reference/ Employment Division Date
Subproject Manager A DTTFA 25-03-2019
Subproject Manager B DTTFA 19-03-2019
Subproject Manager C DTTFA 13-03-2019
Group manager DTTFA 12-03-2019
Subproject Manager D DTTFA 13-03-2019
Project Manager DTTFA 13-03-2019
Table 2. Respondents Empirical Interviews

The interview guide consisted of four-six open pre-stated questions with additional sub-
questions. The first two questions were asked to all respondents, and supports with two figures.

Figure 5. Figures supporting the interviews (Author’s own illustration)

Figure 5. (Q1) supports question one and asked about the experienced dependency between
TOGS (the production development project) and the product development project. The
respondents' task was to point out how high dependency they experienced. Additionally, all
respondents argued for the dependency. This created an interactive activity and made it easy
for the respondent to talk about dependencies. Furthermore, the study got support to better
understand the respondents by visualizing the result.

Figure 5. (Q2) shows the directions of change. This visualization supports the author to explain
the question from what direction occurred design change appears. The figure hopefully
provided a unified understanding of the question, which lower the risk for own interpretations
and respondents bias. Additionally, Q2´s answers narrowed the study to focus on the design
change perspective: product DP to production DP, which implicated that the main focus in the
analysis, conclusion, and recommendations has taken this point of view.
The following interview questions were created to mirror the steps in Jarratt at al.:s (2005) ECM
process, see theoretical framework section 2.1.1, and with the knowledge about project
interdependencies, change, and complexity. The interviews resulted in a better understanding
of the projects complexity and interdependency to the product development project (the design
team) and additionally five design change examples were stated by the participating subproject
managers. Some weeks after the conducted empirical interviews, some of the respondents were
asked agin, not in an interview context, how their stated examples were solved. This
information was, if suitable, included in their respective example.

23
 3.2.2. Scania documents
As a part of the empirical section, Scania documents (secondary sources) were found and
summarized trough a method inspired by qualitative content analysis. The process by Bryman
(2011) inspired the study´s content analysis, see figure 6:

Figure 6. Planning qualitative content analysis (inspired by: Bryman 2011, pp.505-506)

The documents covered an understanding how Scania employees and groups shall work within
development projects, purchasing production equipment, handling risks, and managing design
change.

The themes used to gather information was generated by the thesis research questions, purpose,
interviews, and written theoretical framework (Step 1, figure 6). Bryman and Bell (2011) states
that the themes help the researcher to see patterns in/between the document(s), by moving back
and forth between conceptualization, data collection, analysis, and interpretations.

The Scania documents were found at Scania´s intranet browser and the following word
combinations were used to find relevant documents. The background interviews and theoretical
framework helped formulating the word combinations; “Project Management”, “PD-process”,
“PEIP”, “Engineering Change”, “production change”, and “FMEA”. Standards, routines,
technical writings, and additional Scania web-pages were find. Several documents were read.
The most extensive documents were selected to be included in the summary (step 3, figure 6.).
Furthermore, themes were created to obtain the relevant information to the Scania document
summary. The following themes were used:

 Design change  Communication

 Propagated change  Team work
 Interdependency  Project management
 Announce engineering/design change  Project management methodology

24
  Manage engineering/Design change  Flexibility
 Decision making  Control
 Risk analysis
The Scania document summary attempted to cover the overall view, the process (if existed),
and details of interest. Details could for instance be communication path ways, how to use the
language in a report, and reasons why something shall be executed. Furthermore, a quantitative
document analysis can be done by presenting manifest content – to see the content as what it is,
or latent content – to interpret the documents content (Graneheim & Lundman, 2004). The
summarized Scania documents are presented by the manifest content. The documents cover the
view of how Scania “shall work” and represents standards, routines, and technical documents.

3.3. Analysis Method

The analysis was performed to discuss the gathered data; both empirical and theoretical data,
and make an attempt to come closer to answer the thesis two research questions, RQ1 and RQ2.
The analysis included all stated theories, the summarized Scania documents, and the
background and empirical interview results. The generated themes in 3.2.2., for analyzing
Scania documents, were again used to guide the analysis. This resulted in four sub-analysis
topics:

5.1. Interdependency and propagated change (Teams for guidance: design change, propagated
change, interdependency, teamwork, communication). This analysis discussed the theoretical
frameworks view of Scania´s interdependent project climate and how design changes transmit
to TOGS from the product DP.

5.2. Mapping Design Change (Teams for guidance: announce engineering/design change,
manage engineering/design change, decision making, risk analysis). This analysis mapped
Scania DTTFA´s work with design change, together with Scania´s ECO standard, and the
theory about EC, ECM and ECM process. This section ended with a summary analysis
summary what Scania does and does not do in comparison to the theoretical framework.
5.3. Characterizing the project (Teams for guidance: project management, project management
methodology, flexibility, control). The analysis was furthermore divided into two sections;
level of complexity and support design change management, and analyzed the project
methodologies and processes, complexity, and enablers for change. Lastly, the character of the
studied production development project was stated.

5.4. How to Enable Design Change Management? (teams for guidance: design change,
announce engineering/design change, manage engineering/design change, communication).
This sub-topic analyzed the respondents stated improvement suggestions together with the
theory.

25
The analysis made it possible to draw conclusions and answer the thesis stated research
questions. Furthermore, could recommendations be suggested to the studied project at Scania,
TOGS, and the interdependent product DP. In the contributions, section 6.4, some generalized
recommendations can be seen.

3.4. Research Measurements

Reliability, validity and generalizability are measurements of quality, rigidity and potential of
wider research.

3.4.1. Reliability
Reliability is about if the research can be repeated. It is argued that reliability is difficult to
achieve in qualitative research because a social environment will after time change character.
However, if another researcher wants to repeat the research, she or he should adopt the same
research methodologies. Because if not, the answers will not be possible to compare (Bryman
& Bell, 2011).

This study used Scania documents and two sections of interviews to collect empirical data. To
interpreted and analyze the Scania documents in a manifest way will probably be achievable
again. However, the respondents’ answers will be difficult to repeat due to the temporary
project organization, respondents bias and pre-knowledge, as well as the uniqueness of the
project.
3.4.2. Validity
Validity has been questioned if it should be a part of qualitative studies or not. The reason is
because its close connection to use different measurements. However, validity in qualitative
studies is told to increase when the researcher understands the respondent and can guarantee
that all respondent understands the questions (Michrina & Richards, 1996). Bryman and Bell
(2011) means that validity is achieved when the respondent give significant answerers and when
the researcher has gathered the correct right information and measuring what she wants to
measure.
To ensure validity during the conducted interviews, supporting visualizations and background
information were presented to the respondents to ensure that they understood the authors
questions (read more in the section 3.3.1 Interviews). Furthermore, the respondents were asked
additional questions in means to embroider their answers. Validity in the Scania document
summary was “ensured” by only presenting the manifest content and making the summaries
broad and detailed in a degree to not harm Scania.
3.4.3. Generalizability or particularization
Generalizability is a term that describes how well the research can be generalized onto a larger
population. The opposite to generalizability is particularization. Bryman and Bell (2011) states

26
that generalizability is lower for qualitative research than quantitative studies due to the
qualitative purpose to understand a specific case. This study focused on a specific project and
was studied with quantitative methods and an abductive and inductive approach. Therefore, the
result will be difficult to generalize and is closely connected to Scania, the TOGS-project, and
DTTFA project group. However, similar projects (in terms of the industrial context and
complexity, and interdependencies between a production DP and product DP) might find the
conclusions and recommendations interesting. Learnings from the theoretical framework (about
Concurrent Engineering), shows that interdependent development project saves project time
and that a company’s success builds on launching in the right time – which implicates that
interdependent projects have to be executed, and the need to solve issues related to design
changes will increase (e.g. Sapuan et al., 2006).

3.5. Bias and Pre-Knowledge

Bias is important to consider when conducing a qualitative study. Bias can impact the analysis
and conclusions of the thesis and respondents can be biased in the interviews.

The used qualitative research methodologies come from the hermeneutical tradition and build
on the author's interpretations of the collected data and result. It is stated that the author's
interpretations and assumptions come from collected pre-knowledge, experiences, social
judgments and norms (Patton, 2002). This could for instance be the case of the empirical chapter
when the author describes the perspective of the respondents with own words.

The author has recently completed all courses within the master’s program “industrial
management and innovation” and was during the summer 2018 employed in the DTTFA-group
as a summer intern. As a strength, this will impact the understanding of the problems at Scania
DT, both from a theoretical perspective and a practical and work-related perspective. The author
bias has to be taken into account by the reader while reading this thesis. Michrina and Richards
(1996) claim that an open climate is important to achieve during the interviews, to ensure
trustworthy answers. Furthermore, Michrina and Richards (1996) discuss power relations. If
power relation is unequal the interview can result in a feeling that one party feels talked down
or ignored. Instead it is recommended to achieve an equal relationship with mutual respect.
Perhaps, the authors bias and pre-knowledge have an impact when the author knows the project
members in the DTTFA and fragments in their work tasks. This could have given the study
more trustworthy answers and reduced the risk for power relations, than if the respondent and
authors had met for the first time.
The choice of only taking DTTFA´s point of view in describing the issues related to the group
and ongoing project, will also effect the thesis’s analysis and recommendations. In order to
manage the bias all interviews were transcribed and a lot of quotes being used in the empirical
chapter. Bias can also be discussed in relation to the involvement of DTTFA´s group manager
in both proofreading the interview guide and selecting respondents. However, the selection and

27
proofreading mainly help the author asking relevant questions depending on the respondent’s
knowledge and responsibilities at Scania, it was not done to steer nor impact the study´s result.

3.6. Ethics
Bryman and Bell (2011) state that four main areas of ethical principles are; (1) harm to
participants, (2) lack of informed consent, (3) invasion of privacy, and (4) deception. Harm to
participant can be physical harm, damaged self-esteem development or career prospect, or/and
stress. The harm to participants also includes confidentiality and animosity. In qualitative
studies, it is important to not expose the participants identity. Lack of informed consent is about
asking the participants for permission to contribute in the study. If lack of informed consent
occurs, the participants are observed in secret witch are not an ethical action. The third ethical
principle is about the participants privacy. Everyone has the right to privacy and it is not ethical
to expose a participant´s privacy. Lastly, deception is about telling the real purpose with the
research.
3.6.1. Interviews
Because of the presented ethical principles above, the respondents were informed about the real
purpose of the study. It was also important to consider personal integrity when conducting the
interviews and transcribing the material. Therefore, an honest approach was used. For instance,
all respondents were asked if they accepted being audio recorded during the interviews. The
purpose of the study and interview was also communicated before performing the interviews in
means of being transparent and receive trustworthy information. Furthermore, the respondents
had the freedom to not answer specific questions if they felt that the questions interfere with
their knowledge, ethics, or security.
3.6.2. Confidential material
The author has signed a paper of confidentially at Scania which implicates that the author is not
allowed to spread business secrets, confidential material etc. In order to make the thesis public,
the empirical chapter has excluded confidential and sensitive material, and was double checked
with the author´s principle at Scania before spreading the information.
The Scania document summary has been formulated with an intention to make the summary
detailed – to still understand it and enable use. However, in a more generalized manner to
excluded confidential and sensitive material.

The interviews have excluded the participants identity, financial data, precise numbers of
produced parts, and name of parts, in order to make it less traceable.

28
 3.6.3. Copyright
Virtual data, such as figures and pictures are copyright by the studied article´s authors and the
companies (Bryman & Bell, 2011). Therefore, all figures in the report are remade in order to
manage the copyright.

The interviewed respondents “own their own words” (Bryman & Bell 2011). This means that
all stated quotes in the empirical chapter has a real source. However, the source is not explicitly
named, in means of protecting the respondent’s privacy.

3.6.4. Managing the result

The results from the empirical study can be interpreted as sensitive for Scania and especially
the project group DTTFA due to the revealed examples of design changes and issues between
the production development project TOGS and product development project. This could lead
to extended issues in the relationship between the two interdependent projects. Therefore, the
empirical chapter “4.1.4. How design changes affect production development” was carefully
written and proofread by DTTFA´s group manager.

4. Empirical Study
This chapter covers the empirical data collected at Scania DT. The data originates from the
conducted empirical interviews and collected secondary sources representing of Scania´s stands
and routines.
Scania AB was founded year 1891 in Södertälje Sweden. Today, the firm operates all around
the world with production facilities and assembly plants related to the automotive industry.
Since January 2015, Volkswagen owns 100% of Scania AB and Scania belongs to the
Volkswagens subsidiary TRATON. TRATON´s vision is to become the global leader of the
truck and transport services industry. Scania’s vision is to become a leader in sustainable
transport solutions. Furthermore, Scania´s wish is to make the whole worlds transport industry
clean, safe, and effective, and also contribute to economic and social development, without
risking the environment or human health. In order to meet both parties’ visions, the FPP-project
was initiated with the means to produce a more fuel-efficient powertrain for the global market.
A powertrain consists of e.g.; engine, gearbox, drive shaft, axle, steering, and software. The
subproject of adjusting and developing the assembly line to produce the new gearbox GW is
called the TOGS-project and is located at Scania DT, the gearbox assembly plant in Södertälje.
The production site consists of several preassembly lines, where gearbox components are
produced, and one main assembly line where the complete gearbox is assembled. The TOGS-
project has adopted PEIP and PD-process as project management methodologies. The
subproject does not use any standards or routines of how to assess risks nor announce and
manage design changes.

29
 4.1. Scania Documents
4.1.1. Scania Engineering Change Order
Whatever change that has to be made to an existing article, an ECO – Engineering Change
Order has to be written. The ECO has the purpose to provide a uniform, rational and coordinated
information about the change to all involved functions (STD3438 2013). In this section, one
instruction (ECO Technical Writing, 2017), one standard (STD3438 2013), and one description
(90001, 2011) have been investigated in order to create an understanding of how Scania shall
announce and work with Engineering Change.

It is stated that an ECO has to be established already in the design concept stage. Furthermore,
Scania has developed an ECO mailbox, which is a mailbox function that enables different
subscriptions on various types of ECOs. This means that an employee can subscribe to a
specific ECO type and get updates on email. Employees can also search for a specific ECO in
the mailbox function (ECO Technical Writing, 2017).

Figure 7. Simplified ECO instruction (Author’s own illustration)

The process of ECO starts with describing the engineering change, see figure 7, by stating;
What? Where? How? This shall be very brief to reduce misunderstanding. Then the impact and
dependencies have to be considered, for instance by evaluating which other components that
will be affected by the changes and if the procurement and/or production will be affected in
some way. Also, an extended description and background to the change shall be written.
Reasons for changes could for instance be reduction of costs, standardization, market change,
production or assembly request, and/or incorrect specifications. Questions to guide the
description are; what is the problem? Where is the problem? When does this problem occur?
How does it manifest itself? Why does it occur? What and who is responsible? (90001, 2011;
ECO Technical Writing, 2017). Finally, the target groups should be considered. The target
group intends the affected division groups inside Scania, for instance; design department,
product structure department, production engineering department, after sales department,
marketing department, lab and testing center etc. in the relationship to production engineer
department it is stated that (ECO Technical Writing, 2017, p. 9);

“An ECO is a direct signal to those persons responsible for manufacturing

and assembly preparations and production execution. Machining and

30
 mounting assembly instruction changes requires clear and correct
information.”

Lastly, the ECO instruction contains a lot of guidelines on how to use the language while
writing the ECO. For instance, what verbs to use, shall instead of should, and will if it is a
coming change. It is also stated to be of importance to write compared to if a new article will
supersede an existing article, and that if the new article will be assembled a clear description
shall be written (ECO Technical Writing, 2017; STD3438, 2013). Additionally, it is stated that
a risk analysis, a Failure Mode and Effect Analysis – FMEA, should evaluate the risk of the
change (90001, 2011).

Scania´s FMEA (Failure Modes and Effects Analyses) is a risk assessment to manage the
effects of various deviations. FMEA is especially used to ensure potential deviations that can
occur during a development work of for instance products or manufacturing processes. Further,
Scania has developed PFMEA, were P stands for Process, to reduce quality deviations in the
manufacturing process. Scania has templates and tools to support the FMEA and PFMEA risk
assessment work (Process-FMEA för bearbetning, 2010). The Scania FMEA standard
STD4005 (2017) presents a deeper description how to use the related FMEA-templates. The
template helps the employee to map the deviation in order to solve the failure. The process
firstly guides the employee to write a description about the occurred event and the function the
task should execute. The failure mode should be stated, and failure cause, failure effect and
control – how the failure mode can be identified. Lastly, the employee shall assess the risk of a
failure to occur, and assess the damage it would make, and how to detect it.

4.1.2. Scania Project Management Methodologies

Scania established a standard of how the organization should handle projects and assignments
year 2007. It was written to master future product and operational challenges and it states that
(STD4293en, 2007, p.3);

Projects are created to achieve specific targets that shall be reached within
a given time frame, using a temporary organization with specified
resources.

In Scania’s project standard, it is stated that communication and common understanding of the
project target is two of the most important factors in a project. It is described that the common
understanding enhances motivation and security and that the understanding of the project target
prevents conflicts and contradictions.
Furthermore, is it stated that the greatest concern for project managers is to achieve a successful
cross-functional co-operation. This could be established through visualization tools,
communication plans and project rooms where all visualized project items can be kept. The
visualization can, for instance, be the project plans and product concepts which also are two

31
ways to increase more effective and better the communication between the cross-sectional
project groups.

To have a common ground for the project Scania has developed a Business Model to visualize
how to execute a project. The Business Model is divided in to five phases; Initiation, Pre-study
(preparation), Execution, Termination (conclusion), and Follow-up (expected benefits). The
Business models are created to investigate why a project should be announced, how projects
shall be prioritized and whether a project can continue or have to be discontinued. To answer
the questions when the parts of the project shall be executed and what it shall deliver, Scania
has a number of Management Models to use; PEIP, PD-process, IT project management process
and PPS (STD4293en, 2007). PEIP and PD-process are the two Scania standardized project
processes that are used in TOGS. Therefore, these are presented further below.
Scania PEIP
Scania’s Production Equipment Investment Process, PEIP, assists in evaluating and guiding an
equipment purchase, visualized in figure 8 (Scania PEIP, 2018).

Figure 8. PEIP (Author’s own illustration)

Regarding the thesis purpose, the most interesting steps are the ones that include suppliers and
stating requirements for purchase. In the third step Project start up and requirement
specification it is stated that the suppliers need product information (e.g. desired functions and
work methods) to be able to answer the RFQ with a potential equipment solution. In the phase
Quotation work the technicalities shall be clarified and quotations from different suppliers be
summarized. This is followed by “technical discussions” with each approved supplier. In the
fifth step Tendering a supplier is selected and the order shall be placed. However, in the sixth
step Projecting late design changes can occur. It is stated that design changes may appear and
if it affects the ordered equipment it will most probably lead to delayed deliveries (Scania PEIP,
2018).

In-between all steps Phase transitions ensure that the team fulfils the requirements for each
phase. For instance, it is required in all phases to perform lessons learned. The lessons learned
has the purpose to present mistakes and positive experiences from the project to improve the
purchasing production equipment in the future (Scania PEIP, 2018).

Scania PD-process
Scania´s Product Development process, PD-process, is created to constantly work with product
development, in means of meeting customers´ demand in terms of quality and function. The
process is created to enable cross-functional work, fit different sizes of projects, and achieve a

32
flowing process characteristic. The process is categorized into yellow arrow, green arrow and
red arrow to easily categorize the projects phase (STD4303en, 2013).

The studied part of TOGS-project is currently in the green arrow phase – product development.
However, the TOGS project group that manages the existing gearbox (GZ) is in the red arrow
phase – product follow-up.

Figure 9. PD-process (STD4303en 2013, p. 2)

A product development project has the primary aim to change Scania´s regular product
programme. The only production related information in the development phase before the ramp
up, states that SOP, Start of Production, is a restricted production or assembly for verifying the
ordering, logistics and production process. See the figure 9 to understand the development flow.

4.2. Interview Result

4.2.1. The project´s background
The TOGS-project exists in a multi-project environment as being a subproject of Future
Powertrain Project, FPP (consists of developing several truck components to launch a new truck
with a new driveline). Furthermore, the study has focused on the subproject group DTTFA who
is responsible for develop and adjust the Final Assembly positions at Scania DT, see figure 10.

Figure 10. Simple multi-project structure in Scania FPP (Author’s own illustration)

33
The studied TOGS-project was initiated 2016 with the purpose to introduce a new gearbox
generation (GW) to the existing assembly line no later than summer 2019, and also increase the
number of produced gearboxes. In March 2019, the project entered the v-generation phase. This
means that the GW will start being produced in a low scale, for tests and verification of
production equipment and the gearbox features. However, delayed tasks have resulted in
postponed deadlines. A major reason for the delays is occurred design changes transmitted from
the product development project, product DP, into the production development project, TOGS.

The subgroup DTTFA consists of ten project members, one project manager, and one group
manager. The adjustment and development of the final assembly line includes both developing
new preassembly lines and adjusting the existing assembly positions, including acquiring new
production equipment to both gearboxes (GZ and GW) and unique equipment for GW,
replacing old and existing equipment, balancing the assembly lines, and ensuring that the
assembly lines can handle a lower takt time. Balancing the assembly positions implicates a
development work to ensure that all stations in the assembly lines are filled with assembly to
match the required takt time and therefore the required output volume. A visualization of the
TOGS project and DTTFA´s work and dependencies to the interdependent product DP is found
in figure 11.

Figure 11. TOGS project and the dependent product development project (Author’s own illustration)

The TOGS project was initiated a long time before the design of new gearbox was fully
developed. In March 2019, parts of the product design were still not completed. The
development work is divided into different generation phases; F-gen and V-gen. F-gen phase
is the Function- and Property-generation phase with four sub phases; 1.1, 1.2, 2.1, 2.2. V-gen
phase is the verifying generation phase and when the V-gen phase is complete, the serial
production can start.

It is stated by almost all respondents that the project is a unique case at Scania, implementing a
new gearbox model in an existing facility at the same time as the new product is designed and
not building a new production site when the product is fully developed. Moreover, to develop
the new gearbox at the same time as adapting and acquiring its assembly lines sets high demands
on the possibility to perform simultaneous work. The simultaneous project setup has resulted
in multiple design and requirement changes that TOGS has had to handle. The ex-manager at

34
DTTF expressed in the interviews that it is unique and challenging to develop the product and
associated assembly lines simultaneously, he continues;

“As in the most cases, the product is finalized before the assembly plant
start adjusting the lines. This signifies that the product development team
and we at DT have to collaborate closely, work with continuous changes
and revise product updates all the time”

However, a question can be raised whether there exists a close collaboration between the
functions and if continuous updates really occur. Indications are that it does not exist a common
way announcing design changes and/or known when a change shall be announced.
Subsequently, everyone involved in TOGS have to embrace a flexible way of working, because
they need to be prepared for change – whenever it occurs. The DTTFA´s group manager
expressed;
“The project members need to manage a lot of flexibility and embrace a
willingness to change. Our basic position should be that things will
change.”

Soon the project will go into the execution phase including the adjustment of the assembly lines
at Scania DT. Scania DT´s Technical Manager expresses that every small change in the
workshop adoption plan will affect the time plan and create a domino effect. Therefore,
adjustments have to be monitored closely and a new role will be initiated to manage these
adjustments, be the single point of contact, and “the spider in the net” for the whole project.

The TOGS-project utilizes two Scania standardized project models. One model for purchasing
equipment, called PEIP (Production Equipment Investment Process), and one to develop the
product and setting up production called the PD-process. A manager at Scania DT describes
the models as processes that visualize the workflow, but do not help managing the project. A
specialist at Scania DT describes PEIP and PD-process as linear models to ensure that the
project fulfils all pre-set steps, and that the models are built on “the Toyota way”. Despite the
use of correct project management models, several respondents expressed a desire for more
flexible project management models. An employee from Scania´s improvement office
expressed that PEIP and PD-process are linear project models which aim to achieve pre-set
goals, working towards relicensing a “known product”. Furthermore, she argues that the models
might inhibit effective project-flow and limits the degree of innovation and new thoughts. She
suggests adopting agile principles and seek answers, work with flexibility and dare think
differently and innovatively. DTTFA´s group manager believes that a flexible way of working
would reduce project time, because flexible project management methods includes methods for
change and iterations. An iteration is broadly told to include development, design, test, and
evaluation.

35
The background interviews discovered that TOGS depends on the product DP and that design
changes appear frequently. Further knowledge is missing how design change shall be managed
and responsibility is vaguely stated. This lead the empirical investigation to focus on existing
interdependencies and experienced design change management.
4.2.2. Level of interdependency
During the interviews, the respondents were asked to mark the interdependence between the
production development project and project development project at an ungraded scale, see the
result in figure 12. As an explanation to the task, they were told that an interdependence is when
a project’s success depends on another project, so called out-come dependency, or when a
project need the capabilities and knowledge from another project, called learning dependency
(Aritua et al., 2009; Killen & Kjaer, 2012). All respondents stated that there exists a high
dependency between the design development and the production development. One participant
said that “99%” of the changes originate from the product development project and that the
design changes are rarely reported.

Figure 12. Level of interdependency, respondents’ answers (Author’s own illustration)

Furthermore, everyone stated that the production development project needs the product
information to know how to develop and adjust the production. For instance, when writing
requirement specifications for the RFQ´s (Request For Quote) to supplier in order to purchase
production equipment as a part of the PEIP-process, a multitude of product information is
needed. This could for instance be information regarding press forces or other assembly
verification requirements, surface machining details, weights, measurements of articles etc.
Examples of equipment that are purchased to the production are lifting equipment, screw
drivers, pressing machines, glue machines, robots, rotation tools as well as complete assembly
lines and conveyors.

36
 4.2.3. Direction of change
The literature states that a project with a lot of changes leads to high environmental turbulence.
This could for instance be changes in requirements and technology which affect the ongoing
development project (Buganza et al., 2009). “Change” in this interview question was explained
to the respondents as “production requirements that requires design changes” or “design
changes that requires production change”, or if change appears in both directions, see figure 11.

Figure 13. Change directions, figure shown during interviews (Author’s own illustration)

In the interview, the respondents were showed figure 13 and explained the description regarding
change mentioned above. Further, the respondents were asked to explain in what directions
change appeared. The answer was united. Everyone saw that change appears from both
directions, but that it is most common with design changes from the product DP that escalates
change to TOGS, the production DP.

In two interviews the notion of DfMA - Design for Manufacturing and Assembly – was raised
by the respondent. The respondents told that the product designers should use DfMA to design
new gearbox components in means to be suited for manufacturing and assembly, with respect
to ergonomics and efficiency. However, as the complexity the lack of time in the design has
increased, the DfMA has suffered. Instead, the product DP focus on designing a fuel-efficient
truck with great performance and functions, which contemplates the use of DfMA.

Information from TOGS which can affect the product DP can for instance be determined
requirements specified in the RFQ. In cases when a RFQ is sent out to production equipment
suppliers and the design is not yet fully developed, the RFQ can set boundaries on the design.
However, good quality and design exceed the RFQ´s limitations which implies that if the
product needs to be changed when a supplier is requested, several consequences and increased
change propagation may occur. One respondent said that as long as the design changes does
not require changes of the related production equipment, the change is relatively small and often
manageable.

“It may look like a simple thing, a small change, but it can affect a lot”
(Group Manager, DTTFA)

However, as stated, the most common direction of change occurs from the product DP to
TOGS. The reason is the constant development of the gearbox, with different generation phases
in the development process, that are executed in order to achieve the product goals (fuel

37
efficiency, noise, shift quality, weight, repair cost, article cost). Design changes created by the
product development is announced in different ways. Some changes are informed by the
designers directly to the affected subproject managers in TOGS. However, some changes have
been realized during investigations of other issues, or even when testing the prototypes. These
are changes that the designers have made in the product DP, but were not reported to TOGS.

In the next section five design change examples will be presented. It is revealed how changes
have been discovered and how uncertainty affects the TOGS project.

4.2.4. How design change affects production development

Five stated examples present different types of design changes that has affected TOGS. The
examples were presented by the four interviewed subproject managers. One of the examples
was stated by two of the managers. The most descriptive examples were chosen, at least one
from each respondent.

The examples include how the design change should have affected TOGS if the change would
not have been recognized and managed. Common for all examples is that design changes have
arisen to late in the project.

Example 1. The first example is about a small engineering change that was not reported to
TOGS and could have led to major consequences if it was not solved. The example is about the
component Planetary Gear, which has thousands of variants, and needs to be pressed together
at the production line at Scania DT. The production equipment needs to have a large extent of
flexibility due to the high number of variants. Due to space limitations at the production site at
DT, all variants cannot have a specific pressing equipment. The design change was revealed
when one of DTTFA’s subproject managers was in contact with the product design team
regarding a separate issue, but instead this even larger issue, was realized. It turned out that the
designers had changed the machining surface of the product, which affects how the pressing
equipment can force the articles together without damage.

In this case a requirement specification, RFQ, had been sent out and the selected supplier had
started developing the design of the pressing machine. At this stage, the design team knew that
a supplier had been selected and that further changes leads to consequences.
When the subproject manager contacted the equipment supplier, they were not willing to
change their design. The subproject manager looked at the supplier’s ideas and suggested a
solution to increase the flexibility of the equipment. “I almost did the suppliers work”, the
subproject manager said. In the end, the supplier agreed to adjust the equipment according to
the suggested solution. In this case, the change was revealed in time. If TOGS had realized the
change a week later, or never, the procured pressing machine would not have suited the
planetary gear variation. This would have resulted in extra direct costs and extended delivery
time.

38
Example 2. The second example was discussed by two subproject managers and is about when
the product DP designers have not yet decided the design of a product and TOGS needs this
information in order to purchase the relevant equipment. The article in this example is a type
of sealing that requires tools for assembly. This design insecurity required high levels of
flexibility, and a lot of communication between the product DP, TOGS, and the supplier.

In the coming production of GW and GZ, two types of sealing will exist. One of the variants is
an existing variant that will be assembled in a preassembly line at Scania DT, and the new,
unknown variant has to be assembled in the main assembly line, which will affect the balance
of the line. As described in section 4.2.1., the balance is a task to ensure that all required
assembly can fit to the stations in the assembly line according to the required takt time trough
output volume. The assembly time for mounting the new sealing is unknown, and if the task is
removed from the main assembly line, there will be a gap in the balance that has to be filled
out. Furthermore, due to unsuccessful tests of the new sealing, the designers selected to
postpone the assembly of the new sealing, and initially assembly the existing sealing.
In this case the product DP did not believe that the change would affect TOGS “because the
production will remain as the old way”. However, it affected both the production and logistic
planning. This implies that the main assembly line balance will have a gap - that has to be
"balanced out" or filled out and the logistic team needs to reschedule and reorganize the material
on the workshop floor.

Example 3. This example regards a large design change and high levels of uncertainty, which
lead to an uncontrolled project process and delayed the equipment procurement. The component
will be assembled on one of Scania DT’s preassemblies. At one point the responsible subproject
manager said;

“This project has basically been in the same status since September 2017
when the pre-study started... Sometimes there are such big changes in the
components design that it changes the entire scope of acquiring
equipment.”

In October 2018, the acquisition of equipment began based on the latest known design
generation of the component and TOGS sent out a RFQ to suppliers. Known changes from the
next design generation were buffered to be sent out in a collective document at a later stage in
the RFQ process. However, just two days before sending out the updated RFQ, the production
development group began to get worrying internal information from the product DP regarding
insecurity on what changes that would be made. Some changes were crucial and would require
more advanced equipment. At this point, the design of the component was so complex that
TOGS did not know if they could handle the changes, or if it even was possible to assemble the
component at Scania DT.

39
After a time of constant changes, the subproject manager called its suppliers and said that the
updated requirements and drawings will have to wait. The project continued to work internally
with changes, but when they realized that the designers did not come forward with the product
design solutions, TOGS-project called the suppliers again and froze the purchase of equipment.
During this time, the project could focus on other things and let the product DP work on the
design. The project was frozen for 6 weeks, and a high pressure was put on the designers to
produce concrete assembly solutions that could be handled by the suppliers. The issue was not
yet solved when the interview was held.
Because of the high uncertainty with constant change, the subproject manager said they have
learned a lot, but they have also exceeded the budget about 5 times, and the space for of
assembling the components part has become more than three times as large. The subproject
manager could show that for each design generation, the project has grown and become more
complex, expensive, and larger. But also, the uncertainty and delays have resulted in that the
established processes (PD-process and PEIP) can no longer be followed if the time plan was to
be maintained. In March 2019, the subproject is only doing what they must to do to be able to
meet the start of production of GW.
Example 4. This example is about when component´s weight increase and the ergonomic
requirement changes. Initially in the TOGS-project, the new GW gearbox consisted of a lot of
articles in the weight span between 2-3 kg. This implied that the operator could lift and assemble
the article without using a lifting tool. However, due to design changes the weight of the specific
article has increased to 8 kg. This means that a lifting tool is now required due to ergonomic
standards. However, it has been noticed that if a lifting tool becomes too complex for “low
weight” components, it may not be utilized and the operators will start to assemble the article
by hand which in the end will injure the operator. Therefore, lifting tools which handle the
lightest articles are seen as the most difficult to develop, because is sets higher demands on
usability. This implies the product DP need to take the weight into consideration when
designing a component, and also provide the information to interdependent projects.

Example 5. This example regards insufficient communication between the product DP, TOGS,
and testing department at DT. The change was identified one week before the gearbox moved
in to v-gen production. The change on the article, a nut, may look as a simple issue, however,
it will affect the whole gearbox verification stage and related tests.

In all tests at the testing department the nut has been tightened with 600 Nm, a very high torque
(normal torque, the force to tightening, is about 20-60 Nm). 600 Nm was used in a similar
assembly process of a nut on the existing gearbox, and no other requirements had been stated
from the product DP. However, all gearboxes assembled at the testing department were leaking
and nobody knew why – until the product DP asked what torque was used when tightening the
nut. It was revealed that the nut must be tightened with almost the double torque.

40
This information had never been revealed before. The subproject manager said that it is difficult
to blame anyone for this, TOGS could have asked the product DP before or the product DP
could have provided the right assembly instructions earlier.

As an effect, the purchased nutrunner cannot handle the required torque and TOGS needs to
upgrade it. This resulted in increased costs, delayed deliveries, and effects of the v-gen
production.

4.2.5. Effects of design change solution

Almost all respondents mentioned that the space available for assembly of the gearbox´s
preassembled components is the most difficult measure to handle when adapting the assembly
due to a design change. One respondent refers to the space limitations as the “greatest enemy”.
If it was possible to have all articles close to the assembly lines, the need for logistic work
would decrease. This implies that when a change appears in the assembly process it most
certainly also affects the logistic systems and development. The logistic development work at
Scania DT are handled by another TOGS project team. An additional interdependency was
realized here which DTTFA has to consider when taking a decision for change.

Furthermore, time and money are two project resources that have to be taken into account when
deciding which solution to use for handling a design change. It is difficult to find time for
rewriting a RFQ or re-negotiating a purchase. Best practice is to purchase the correct equipment
the first time. However, if a re-negotiation is required due to a design change, it will have a
direct effect on costs and time.

Beyond this, quality must always be considered as the means of change. Changes should only
be made in order to achieve a better gearbox with improvements on quality, more cost-effective
assembly, ergonomics or facilitate difficult technologies. The project manager at DTTFA
expressed;

“We should never make changes for the sake of making changes. Scania´s
purpose is to produce a great gearbox, if it would have been possible to do
it on the first try, we would not have had any change.”

4.2.6. Suggested improvement potential

During the empirical interviews, with the purpose understand interdependencies and how
design change effects and are managed, the respondents raised some suggestions for
improvement.

One subproject manager at DTTFA suggested a “5-phase strategy” on how the design team
should announce change; (1) When the designers know that a change will occur, they should
do a ”heads-up” and inform the production PD regarding what potential articles will be affected
→ (2) in the next step the designers should inform exactly what articles that will be affected →
(3) then inform how the article potentially will be affected by the change → (4) inform about
41
what article that will be affected, and how they it will be changed → (5) lastly, an exact
description regarding the change of the article should be presented, in order to be able to inform
the production equipment suppliers. The reason why information is desired before the change
is executed and decided is because of TOGS need of information to be able to purchase
equipment. In the first and last example in section 4.2.5, the supplier could have been informed
earlier and the correct production equipment would have been purchased at once.

Another subproject manager suggested weekly or monthly reports from the designers. It could
for instance be a list with changed articles, and if TOGS found some article interesting the
designers could tell further information about that change. However, another subproject
manager stated that they shall only work with real determent facts, not with “potential changes”,
meaning that it is too risky to start adjusting to a potential change and not with determent
changes. Instead the subproject manager suggests having close contact with the designer and
collect changes until a change is decided.

To have a standardized way of managing and informing changes is preferred by almost all the
respondents during the empirical interviews. One manger recommends having weekly meetings
where new changes shall be reported. It is also preferred to formulate a standardized way of
communicating the change. The designers should inform the correct subproject manager
immediately when a change appears. The suggested communication is almost as the process
looks today, but it is not an unspoken or standardized communication way. Furthermore, one
respondent told that some designers are well organized in how they report changes, but as
realized in the examples above the change announcements are fragmented. Some invite the
involved production development members to meetings and present the latest changes,
however, some designers never send any updates. It is argued that this is due to the lack of
standardizations, or as one subproject manager at DTTFA explains it;
“Well, I believe that much information is missing due to the fact that the
designers do not want to give away information about changes that are not
yet completely established”

The product development process is a complex set-up with different generations and decision
points. Due to its characteristics, some designers may not consider providing TOGS with
information. Some respondents believed that designers with insight in the operations of Scania
DT’s production site understand the importance of informing change. However, some designers
have never visited the production and thus do not understand the importance of informing on
change. Then, the notion of responsibility can be discussed. Who are responsible for
announcing and seeking change? The project manager in DTTFA-team expresses that the
responsibility should be equal between both parties. The product DP should feel a responsibility
to inform about upcoming changes, and TOGS should seek changes and inform if the product

42
DP with necessary production information and equipment-supplier information. DTTFA´s
project manager described the responsibilities as;

“I believe that change should be informed trough a dialog and personal

contact. Both parties have a responsibility. They should take responsibility
for each other’s reasonability.”

4.3. Empirical summary

When looking at all the collected information at Scania, both from the interviews and intranet,
is it clear that TOGS uses the correct project management methodologies, regarding the Scania
standards. PD-process for the development work and being synchronized with the product DP
and PEIP as the process of purchasing production equipment. Scania also has a standardized
way on how to manage and communicate engineering change for released products. However,
The ECO standard is not utilized in the gearbox development project and the project members
in TOGS expresses its lack of a standardized process. From DTTFA´s perspective the largest
identified issue is how design changes are reported from the product DP to TOGS, and how the
changes shall be managed when they appear. Therefore, the thesis selected to focus on design
change management and how to achieve a better system of announcing design change in
industrial interdependent development projects.

5. Analysis
The analysis is divided into four sub-section. The four sub-topics starts out with (5.1.) analyzing
the interdependencies that exists in the DTTFA subproject group together with
interdependency, change propagation, and concurrent engineering theories. The second sub-
topic (5.2.) maps the design changes management at DTTFA in relation to engineering change
in theory and Scania ECO standard. The two first sub-topics will focus on analyzing collected
content to later answer RQ1. The third sub-topic (5.3.) analyzes the used project management
models in TOGS and analyze them in relation to Scania documents and the theoretical
framework. Additionally, the sub-topic investigates flexible and controlling management
principles, which end up in characterizing TOGS-project. The last sub-analysis topic (5.4.)
analyzes Scania DTTFA´s stated improvement suggestions in relation to related theory.

5.1. Interdependency and Propagated Changes

The gearbox production development project, TOGS, is a part a FPP project. Aritua et al.,
(2008) would classify TOGS as a part of a multi-project because of the project´s goals. Scania´s
business objective is to become a leader in sustainable transport solutions, which means that
FPP´s goals is to create a more fuel-efficient truck to become a leader in the sustainable
transport sector and TOGS´s goal is to produce a fuel-efficient gearbox to support FPP´s goal.
With these goals technology turbulence can be seen as the FPP project means to develop a new

43
product innovation (Buganza et al., 2009). However, in relationship between the product DP
and TOGS other can turbulence exist. Lager (2002) would argue that Product DP and TOGS
offers opportunities for development in both directions. If the production site develops its way
of producing a product it generates possibilities to develop the product and if the product
changes it offers opportunities to develop the production. Chronéer and Bergquist (2012) agree
and express that new developed product generates a demand for new equipment and production
layout. By understanding Lager (2002), Chronéer and Bergquist (2012) view of opportunities
and need for change, can the studied interdependencies be understood. In TOGS, there is a
constant need of information from the product DP and frequent changes occur which have to
be adopted by TOGS. Buganza et al., (2009) argue about market turbulence which implies when
the customers require change. The studied projects, TOGS and product DP, would perhaps not
call any actor for customer nor supplier. However, looking at the most common direction of
change, TOGS demands information and the product DP has the authority to provide
information. This indicates that an internal customer-supplier relationship might exist. At least,
turbulence clearly exists in the project and a high level of interdependency exist. Killen and
Kjaer (2012) would classify the existing dependency as both an out-come dependency and a
learning dependency since TOGS needs both knowledge and results from the product DP.

Environmental turbulence, from the technology or market, can be managed by e.g. delaying
concept freezing (moving realize date) and adopt cross-functional teams (Buganza et al., 2009).
Seen in example 3, page 34, the subproject manager first decides to freeze the project internally
and later freeze the external parts of the project - the purchasing of production equipment. The
subproject manager took this decision to let the product DP come forward with a concrete
concept of the component´s design. To delayed concept freezing is a good strategy because it
increases the projects flexibility and time to innovate. Furthermore, other recommendations to
manage environmental turbulence is to work in cross-functional teams (Buganza et al., 2009).
Cross-functional is told to improve the communication, knowledge exchange, and decreases
the need of coordination of simultaneous work (Bhuiyan et al., 2006). In Scania´s standard
STD4293en (2007) and STD4303en (2013) it is stated that cross-functional teams are a great
concern for project managers, however, the PD-process is created to support the cross-
functional work.

To execute a product development project at the same time as a production development project
can be managed with Concurrent Engineering. The method is used to achieve better
communication, and increase team work and collaboration (Sapuan et al., 2006). In the theory,
it is stated that Concurrent Engineering has become adopted by almost all automotive
manufactories today. But, the concept of Concurrent Engineering was not mentioned during of
the interviews at Scania DT. However, some features of the Implementing Concurrent
Engineering, by Bhuiyan et al. (2006), are explicit requested during the empirical interviews.
Some respondents expressed the need to have a “single person of contact” – this is something

44
that shall be decided in step three “identify process ownership”. However, indications from the
background interviews shows that a single-point-of-contact will be announced when the project
goes in the execution phase; when the production site will start adjusting the assembly lines.
The technical manager argued that it is needed to ensure that change will be managed to not
propagate into larger production changes.

The empirical interviews investigated how high the interdependency is and understood why
DTTFA´s are dependent on another project. Due to a visualized exercise during the interviews,
can the result be presented in a figure, see figure 14.

Figure 14. Summary of interdependency between product DP & TOGS (Author’s own illustration)

The results clearly present a unified, high level of interdependency and the reason is stated to
the need of product information to specify requirements for purchasing new production
equipment and knowledge to plan the assembly process. Additionally, the empirical result about
the direction of change shows that most of the changes are done by the product DP and affects
TOGS to adjust and change. The respondents from DTTFA express that even small design
changes has led to large changes in the assembly line. This transmitted change effect from the
product DP can be called design change propagation and external change because it propagates
outside the product development project (Chua & Hossain, 2012). A change propagation, can
also be classified as ending or unending, it depends on if the change can be solved during an
expected time and how it will snowball into further changes (Jarret et al., 2011). The examined
examples from the empirical interviews show different degrees of propagated changes from the
product DP. Some could be solved within a more certain time, and for some it was not clear
how or when the solution was going to be settled.

The theory presents that interdependencies in development projects usually generates change
across different areas of the project, for instance the production site (Chua & Hossain, 2012).
It is also expressed that a high level of uncertainty leads to uncontrolled propagation (and Albas
& Wortmann, 2012). To ease the change propagation transmitted from the product DP can
Hamaz´s ECM goal “less” be studied. Harmaz et al. (2012) means that the designers can use
project architecture, for instance design for manufacturing or design for verity, to ease or
prevent EC´s from occurring. DfMA (Design for Manufacturing and Assembly) is stated to be
used by the designers at Scania and in the gearbox design development. However, designing a
gearbox suited for the assembly process suffer, because of higher demands of performance and
efficiency.

45
Scania has a standardized document for how the company shall announce and manage
Engineering Change, Scania ECO. However, the document does not clearly express that it
should be used inside development projects or anything about EC education. During the
empirical interviews the respondents clearly stated the lack a standardized way of managing
design changes from the product DP. This means that the Scania ECO-standard is something
that is not used within the project, or perhaps something the project did not even know existed.

5.2. Mapping Design Change

To investigate engineering change management, the six process steps originally designed by
Jarret at al. (2005) will be used, together with suggestions how to become better in managing
Engineering Change (Hamza et al., 2012). The extended version and deeper description about
all steps in the two processes can be seen in the theoretical framework above, section 2.1.
Change. Moreover, Harmaz et al. (2012) express that Jarratt´s ECM process be a part of the in-
change stage. Despite this, a clear connection can be seen between the pre-change step by
Harmaz et al., and Jarratt´s Before approval, and In-change stage and During approval, and
Post-change stage and After approval. See a simplified version of ECM process by Jarratt et al.
(2005) and combined with Hamza et al. (2012) process of managing engineering change;

Figure 15. Combined engineering change management process (Author’s own illustration)

The table below is constructed to mirror the ECM-process by Jarret et al. (2011). The table
presents Scania´s standards, routines, and technical writings, which represents how Scania shall
announce design changes by the ECO-standard and evaluate risk by Scania´s FMEA or PFMEA
routine. DTTFA´s reality of managing design changes in TOGS is also presented, and
furthermore is the theoretical view of how a project can announce and manage design change.

ECM Scania Standard Scania DTTFA ECM Theory

Process Shall
Trigger Cost reduction,
standardizing work,
market change, request
from production or
assembly department
Reality
New generations in the
design process, cost
reduction, quality
insurance, and failed
tests leads to design
Could/Description
“it is normal to change the
design in development
projects” (Jarratt et al.,
2011).

46
 (ECO technical writing,
2017).
1. Change Write an engineering
request change order in a rational,
Announcing unified and coordinated
change way. It has to include:
What change that will be
made. Where the change
will occur. How the
change will be managed.
Also, dependent effects
need to be stated
(STD3438).
The change shall then be
considered with the target
groups. i.e. the production
engineering department.
Then should the ECO be
announced in the ECO
mailbox and accessible
for all subscribers (ECO
technical writing, 2017).
2. Possible In the announcing of EC
Solution dependent parties shall be
considered. For instance,
if the change results in
new mounting instruction,
shall clear and correct
assembly information be
stated (ECO technical
writing, 2017).
changes (Empirical Modifications of products
Interviews, 2019). or related components –
for instance, fits, forms,
functions, materials etc.
(Huang et al., 2003).
Several different ways It is stated to be ordinary
(Empirical Interviews, to have a standard for how
2019): to make a change request
Change found by TOGS (Jarratt et al., 2011).
when investigating other The request should cover;
smaller issue. The reason for change, its
priority, type, and possible
Changes found in the
dependent change. Further
testing stage by TOGS.
it is recommended to add
The change was not
the change in the
reported from the
“engineering database”, so
product DP.
the change can be find by
The design is not
affected employees
decided yet, allot of
(Jarratt et al., 2011).
different calls.
Hamaz et al. (2012)
Multiple and frequent
suggests educating the
changes reported from
employees in how to
the design DP.
discover and manage ECs.
Change reported from
the Design DP, but stated
that it will not affect
TOGS.
There is no standardized
way of announcing
change between the
product DP and TOGS.
In this stage, the change Necessary to compare
is made by the product different solutions to
DP and TOGS has to reduce the scale of
make an adjustment! propagation.
The choice of solution In the “design
has to take in to development” check how
consideration: Space in the potential solution
the production or affects the supplier,
assembly line, time and production and budget
resources, and increase (Jarratt et al., 2011).
or remain the quality.
Seems like DTTFA
report changes to the
production equipment
suppliers quickly if the
RFQ is sent out.
47
 3. Risk It is stated that the
Assessment change´s risks shall be
evaluated with a FMEA.
However, a Scania FMEA
(PFMEA) standard exists
in order to assess failure
effect in the production.
4. Select It is not clearly stated how
solution the selection shall be
executed.
However, it is express that
an ECO has to inform
target groups (internal
stakeholders) about the
coming change (ECO
Technical writing, 2017).
5. Not stated in Scania’s
Implement- documents about ECO
ation how to implement the
solution.
6. Review Not stated in Scania’s
Change documents about ECO if
During the interviews, it The EC risks in means of
was not stated that the dependencies to
DTTFA subproject production has to be
managers had a considered. If the studied
standardized way of change is too risky, the
evaluating risks. ECM process goes back to
However, due to the step 2, an iteration is made
limitations of space, (Jarret et al. 2017).
time, and resources, and FMEA a risk assessment
to ensure quality, some tool is recommended to
effects of the change evaluate the change
were considered. propagation (Kurdve et al.,
2016).
Kernschmidt et al. (2014)
underlines the importance
of understand and inhibit
change propagation into
the production lines.
Has to consider the same Select a solution and
as in step 2 and step 3. create a cost benefit
At DTTFA, the analysis for that change. If
communication with the board do not accept the
equipment suppliers is costs change, the ECM
very important. DTTFA process goes back to step
has to inform them with 3 (Jarratt et al., 2011)
design requirements and The theory of EC
changes. Additionally, suggested to include
the suppliers make the stakeholders in the
decisions of how to decision making (e.g.
change the production Eriksson et al., 2017).
equipment design.
From the stated The change
examples the solution implementation depends
depends on which phase on the development
the subproject is in. The process of the product, it
following examples can be implemented
where found in the immediately after
interviews; Increase approval or planned later
flexibility of production (Jarratt et al., 2011)
equipment, change
requirement
specification, and
purchase a new tool.
The review can be made The implemented solution
when the gearbox part has to be reviewed after a
has entered next
generation phase.
48
 the changes should be
reviewed.
However, in-between all
stages in the PEIP project
process, a review is
needed to learn from the
executed work.
Because, if a change period of time to learn
requirement appears in from the change.
the current generation,
the change will be
implemented in next
generation.

Table 3. ECM Process; Scania standards, Scania´s reality, and ECM theory

Through the mapping some differences can be seen. The largest identified concern is that
DTTFA does not use a standardized process of announcing nor managing EC. However, a
Scania standard exists of how Scania shall announce change and involve affected groups if a
design change has to be conducted of an existing component. The theoretical framework states
that it is good to use a process to manage engineering change and the “success theory” of
Concurrent Engineering, CE, explicitly expresses that a standardized work process leads to an
increased project quality. The process of initiating CE includes of mapping the work process
and then standardizing the best practice.
Several similarities exist between the ECM-process; before approval-stage and the Scania
ECO-standard. For instance, that the identified change has to be placed at a common electronic
platform (EC database or Scania ECO-mailbox). This implies that the Scania´s ECO Standard
could cover the first ECM process step. But the standard does not clearly express when the
ECO standard shall be used, if it e.g. in product development projects or just for changes of
products where production has commenced. Perhaps, the standard is to complex and time-
consuming for this type of development project with frequent design changes.

Other deviations between the “reality” and the theory can furthermore be seen in the second
step; possible solutions. Scania DTTFA does not state that different options considered are to
solve a change, however they consider different measurements (i.e. time, space, suppliers etc.)
in means of taking a decision. Moreover, the third step is not outspoken to be executed with a
standardized analyzing tool. However, a Scania standard (FMEA/PFMEA) exists on how to
assess a risk. The difference in the fourth step is that the theory states the importance of
evaluating the costs. As learnt from the empirical interviews, TOGS must adjust to the design
changes, even if the production equipment is already purchased. This could lead to escalated
costs. The fifth step to execute change at once or implement it later in the development process
(in the following generation) is rather similar, to the theory. Lastly, the change is not reviewed
in the way as the theory states since Scania DTTFA does not express that they review the change
with the means to learn from it. However, reviews can be seen between all steps in the PEIP-
process with the purpose to learn from good practice and worse events.

49
 5.3. Characterizing the Project
It is seen that depending on a project´s complexity and degree of change frequency different
project management methodologies are suggested. To analyze TOGS project characteristic in
terms of used project processes, complexity, and frequency of design changes, suitable
improvement suggestions can be identified in means to increase the efficiency in managing
design change.

The theory states that a project management methodology is a set of e.g. methods, techniques,
templates, and best practices (Project Management Institute, 2008). DTTFA uses two models
to steer TOGS, PEIP and PD-process. Regarding STD4293en (2007) the project is utilizing
correct project management models and shall support the managers when the project shall be
executed and what is shall deliver. However, inside the projects the models are called “project
processes” because they do not support the project management. Instead the processes ensure
that the project fulfil pre-set tasks and supports the project with visualized guidance.
Both models, PEIP and PD-process, are built on linear principles which implies when one step
is done and accepted, the project can continue. However, in PEIP´s step six (out of nine steps)
the information states that design changes can occur which might impact the equipment
purchase. This means that changes can occur after the tendering is made which in turn implies
that Scania employees and purchase projects have to be able to manage late changes. In the
project management model, PD-process, different product generations are included, which
means that iterations exist in the linear development process that TOGS has to adopt and adjust
to, even though the processes accounts for changes and includes iterations in terms of
generations. The respondents clearly state a need for better routines of how to manage design
changes in TOGS.

In the stated design change examples, section 4.2.4., the used project management methodology
is not clearly presented. But some information reveals if the generation phase (f-gen, and v-gen
in the PD-process) gets impacted and in what stage the purchasing, PEIP, might be. It is also
presented how a subproject manager have to adopt their own flexibility in means of solving the
issues or disregarding the purchase process completely. This gives a conclusion that PEIP and
PD-process are models which steps should be followed, but that the employees need to create
their own way of following the project processes and include own flexibility.

5.3.1. Level of complexity

In 5.1. TOGS was classified as a part of a multi project environment. By accepting
Araszkiewicz (2017) the idea that all multi-project is classified as complex due to the project
planning, coordinating, and control TOGS and FPP would clearly be stated as complex.
However, there exists several ways of evaluating complexity. By looking at the seven drivers
for complexity, two of them; emergence and size, can be analyzed in relation to the TOGS and
FPP project (Bakhasi et al., 2016). Emergence is about predictable result. Size represents the
50
scale of the project objective. As stated earlier in the analysis FPP´s objective to “create a more
fuel-efficient truck to become a leader in the sustainable transport sector, and TOGS´s goal to
produce a fuel-efficient gearbox to support FPP´s goal” are two very broad goals with few clear
boundaries. The empirical data also shows that the product design is constantly changing. With
these two notions, the studied project would be classified as complex.

Furthermore, the Stacey Matrix was studied with the means to later categorize TOGS
complexity (see whole description in section 2.2.1). The initial background interviews revealed
the uniqueness of the project and the Scania DT´s immaturity and inexperience in executing
large development projects. Stacey (2007) states that simple projects are close to certainty and
agreement because the project can make decision based on earlier experiences. But, if the
project is unique or involves particular events, the clarity becomes vague and the complexity
increases. Due to TOGS clear but broad goal and used project processes with pre-set execution
steps (DP-process and PEIP) the project is relative close agreement “what should be executed
in the project” but further away from clarity “how it shall be executed, what to develop and
how to adjust to change”. This argument would classify TOGS in to the third circle –
judgmental complicated. However, looking at the stated design changes examples, an increased
complexity can be identified because the agreement decreases with frequent design changes
and the clarity drops further.

Regarding Stays (2007) and Metz (2018) this type of complicated project should be managed
with increased flexibility, i.e. with agile principles. If the complexity increases even more in a
project, Stacey (2007) recommends a project to adopt a combined project management model
that both enables flexibility, but also controls the process (further discussions about this in a
coming section below).

5.3.2. Support design change management

In the theoretical chapter, different project methods were recommended depending on the
projects character. The Stacey Matrix said that the farther away a project is from certainty and
agreement, the need for flexible management methodology increases, e.g. agile principles with
iterations (Metz, 2018). Also, when managing engineering change and its propagation,
flexibility is an important factor to enable iterations and ensure selecting the correct solution.
For the presented reasons, the ECM-process has included two iteration points which have made
the process more flexible (Jarratt et al., 2011).

Understandings from the background interviews identified a potential iteration work which
could be incorporated in Scania’s standardized product development process. An iteration
principle could be implemented in each product generation of the PD-process. One iteration
could look as following: develop the component → design a component prototype → test the
component → evaluate the component (find features that needs to be change) → (start over)
Develop (include the changes) → Prototype → Test → Evaluate, etc.

51
Kurdve et al. (2016) and, Albas and Wortmann (2012) discuss the notion of incremental and
radical change in relation to ECM and propagating changes. The authors mean that incremental
change evens out the risks of implementing an EC, and leads to less propagations. One
respondent in the empirical interview answered that design changes were “buffered up”, this
means that changes were saved and not managed until they were fully determined. The reason
was stated to be because of insecurity and frequent design change. This goes in line with the
project managers statement that the subproject managers should only adjust to “real facts” and
not to potential change. Another subproject manager said instead that it would have been good
if they got a “heads-up” on potential changes, so they could prepare their equipment suppliers
if some requirement would change. The idea of buffering changes and then adjust a larger
change could be considered as a radical change, while announcing a heads-up, would be an
incremental way of managing change transmitted from the product DP. It is said that radical
changes are more associated with risks but takes less time to execute than incremental change
(Kurvede et al., 2016). The project management of radical vs. incremental change also differs
in the literature. While incremental change can be handled tough control and traditional models-
because it is relatively easy to plan the execution, radical changes requires a higher flexibility
in the management methodology to enable manage change and insecurity (Buganza et al. 2009).

Summarizing, flexible ways of managing a project can be done by agile-principles such as

including iterations in an otherwise linear process. The flexible project management
methodologies suit the following project characteristics:

 Judgmental, complicated projects (Metz 2018; Stays 2007);

 Complexity in technology and innovation (Saynisch., 2010);
 Fluctuating environment with allot of changing demands (Buganza et al., 2009);
 Enable manage Engineering Change (Eriksson et al., 2017; Pollack, 2007; Zhang
2013);
 Managing radical change (Buganza et al., 2009).
A traditional project management methodology can for instance be a state-gate model and
waterfall project management methodologies (Hallin & Karrbom, 2012, & Metz 2018).
Traditional, linear and controlling project management principle can be used for:

 Execute incremental changes (Buganza et al., 2009);

 Simple projects (Metz 2018; and Stays 2007);
 Political, complicated projects (Metz 2018).
Metz (2018) present an idea to have a combined way of managing complex projects to both
have some control in the governance and processes, but still enable flexibility in the execution.
A hybrid can for instance be agile-stage-gate or scrum-stage-gate model (Brandl et al., 2018).
The hybrid variant is suited for;

 Projects with changing demands (Brandl et al., 2018; and, Sommer et al., 2015);
52
  Projects that wants to increase the communication and improve project planning (Cooper
& Sommer, 2016).
From the analysis, the TOGS-project can be classified as complex and within a multi-project
environment which executes with project management models that are not supporting the
management, but steering the execution. Moreover, the literature would recommend this type
of project to a flexible project management principle, as the complexity and/or turbulence
increases.

5.4. How to Enable Design Change Management?

The interviews resulted in some improvement suggestions stated by the DTTFA team members.
Eight of the suggestions were selected to be analyzed in relation to the theoretical framework
and Scania documents. (The improvement suggestions can be found in the empirical section,
4.2, most of them can be seen in section 4.2.6.)

# Name Short description

1. “5-Phased To get information before the change is decided, to inform the

Strategy” equipment suppliers about potential changes.
The 5 phases: (1) potential change, (2) Affected parts, (3) Potential
effects on other parts, (4) Change on part(s), (5) Exact change
description.

2. “Change Reports” Weekly or monthly change reports from the product DP. The
product DP could provide additional information if TOGS wants.

3. “Buffer Change” To have close contact with the designer (product DP) and collect
changes until a change is decided.

4. “Standardized How to announce, communicate, and manage design/engineering

Routines” changes.
To know whom to contact in TOGS and which designer.

5. “Weekly Meetings” A meeting where new changes being reported by the product DP
and production requirements by TOGS.

6. “Equal It is believed that an equal responsibility would lead to larger

Responsibility” information exchange and earlier discovering of change. For
instance, TOGS shall search for change, and the product DP shall
provide design change information.

53
 7. “Knowledge about To increase the knowledge. Some respondents saw that designers
Production” who had knowledge about production development were better in
communicating change.

8. “Increased In the background interviews a more flexible way of working was

flexibility” suggested and to increase the management of adopting to change.

Table 4. The seven improvements suggestions

Due to DTTFA´s different experience in how they receive information about design changes
most of the suggested improvements are on how they want to receive information. As analyzed
in table 1. row “1. change request” (page 43), Scania´s ECO standard states that engineering
changes should be announced trough a special ECO-mailbox. The Scania document thus
confirms the theoretical framework that companies usually have a standardized way of
requesting a change. However, as stated before, the standard is not utilized within the studied
gearbox development project.
Furthermore, some suggestions about better communication and relationship are desired.
According to the Scania standard STD4293en (2007) communication increases by using
visualized tools such as project plans and product concepts. Due to the fact that TOGS is using
the correct project management models, regarding STD4293en, the PD-process´s visualized
tools are utilized. However, as discovered in example three section 4.2.4., could all process
steps could no longer be completely fulfilled – due to the subprojects delays caused by design
change. In the theory about; Implementing Concurrent Engineering, overlapping activities
should be mapped and the communication should be stated. The preferred communication way
is to have face-to-face, two-way, meetings and have all project-data accessible for all members
(Bhuiyan et al., 2006).
Three of the suggestions (improvement 1., 2., and 5.) can be categorized as an attempt to
achieve incremental changes and these improvements would help the subproject manager to
know if the equipment supplier needs to be informed. The third improvement could also
generate knowledge about a future change. However, as analyzed earlier, buffered changes can
result in larger changes, perhaps a radical change which would imply higher risks and increase
the change propagation.

Improvement suppressions 4 and 6 are both about responsibilities. The fourth improvement
means to have a standardized way of announcing change and construct a responsibility plan for
whom the designer shall contact when announcing a change. The sixth suggestion “equal
responsibility” is about the project members’ responsibility to both search and announce
change. Perhaps it is typical in complex projects to lose the sense of responsibility and need to
inform other parties. Bakhasi et al. (2016) means that the “belonging” gets decentralized in
complex projects, which mean that employees are involved in the project because of its own

54
sake. And because of the complex multi-project structure it becomes difficult for the project
members to see the dependencies between all subprojects.

In the theory of EC, the goal “less”, implies to educate the employees in how to discover and
manage Engineering Changes (Harmaz et al., 2012). The other way around, the seventh
suggestion “Knowledge about Production”, implies to educate the designers (in the product DP)
about the production development work. Perhaps increased knowledge would increase the
information flow and the change propagation be hindered in time.

Several improvement suggestions involve an idea to standardize the work to achieve a

controlled routine in communication, announcing, managing, and control the design changes.
However, the last idea implies to adopt a more flexible project management method to be able
to change. This idea was revealed during the background interviews when questions had a more
holistic perspective of the ongoing project. Flexibility is something that TOGS´s subproject
managers need to include in their work and achieve in means of being able to change. One
subproject manager also stated that flexibility is needed to include in the RFQ (requirement
specification) to even be able to purchase a production equipment.

6. Conclusion
The studied project´s complexity has increased due the existing interdependencies in-between
different subproject groups which has caused a simultaneous work structure. Jarratt et al. (2011)
argues that changes historically have been normal in product development projects, and theories
discussing change propagation reveals that the change can result in additional changes
internally and/or externally, e.g. the related production. This has been identified in the studied
production development project, TOGS. Empirical findings show that a high interdependency
exists and that most of the design changes occur in the product DP and transmits into TOGS.
To be able to develop the related assembly positions, TOGS depends on receiving product
information and assembly instructions from the product DP. Furthermore, a standardized way
of receiving transmitted design changes in TOGS has not existed, nor a routine how to manage
design changes. Theories exists how Engineering Change shall be managed by product
development project and how these projects shall control change propagation and risk. A
theoretical gap was identified here, which this study intended to fill: How a production
development project manages design changes (RQ1), and what improvements the production
development project (and the interdependent product development project) shall implement in
means becoming better in managing design changes (RQ2). The conclusion will summarize the
thesis by answering the stated research questions RQ1 and RQ2, provide recommendations to
Scania DT, and lastly, discuss contributions, research credibility, and further studies.

6.1. Research question 1

RQ1: How has an existing production development project managed transmitted design

55
changes from an interdependent product development project?

The empirical data and analysis show that there does not exist a unified way on how design
changes appear in the studied production development project, TOGS. However, most of the
design changes appear in TOGS when the product DP decided to adjust the product design.
Therefore, the focus was decided to study transmitted design changes from the product DP to
TOGS.

The answer took inspiration form the process steps of the ECM-process, suggested by Jarratt et
al. (2011); trigger, 1. change request, 2. possible solution, 3. risk assessment, 4. select solution,
5. implement, and 6. review change.

Trigger: Different reasons exist why the product DP has to change. For instance, after testing
issues reviles and the component needs to be changed. The test result can for instance indicate
that durability and efficiency has to be improved. Furthermore, cost reduction can be a trigger
for change. The reasons for conducting a design change was seen as similar to the theoretical
framework´s Engineering Change.

Change request: The announcement of design change was identified as the most diverse
activity. The empirical interviews found following ways how change was reported or
discovered: when investigating other design related issues, during testing, frequent changing
design, not decided design, different change calls, and change was told to not affect the
production development project but it did. In the production development project the
responsible subproject managers are liable for solving the transmitted design changes.
Possible solution, risk assessment, and select solution: When the solution of change is to be
decided the production development project considers; assembly space, time and resources to
allocate to the change, and ensure or improve quality. Furthermore, other inter interdependent
development project has to be considered and sometimes the production equipment supplier
has to be involved in the solution, especially when the development of a productions
equipment´s design had commenced.

Implementation: The implementation of solution depends on the type of change. Some

respondents mentioned the importance of including flexibility in their solution to enable enable
a spectrum of changes without harming neither the assembly position´s design nor the
purchased production equipment, and meet both new product requirement and supplier’s
requirements. Implementation when a supplier was involved is mostly conducted by the
supplier, however, monitored by the subproject manager. Other types of change that do not
affect the purchasing of equipment are stated to be relatively small changes which can directly
be implemented in TOGS. When a design change is implemented by the product DP it can be
seen in the next product generation. This means that in following tests, the result shows if the
change was beneficial or not.

56
Review change: To learn from occurred design changes or review if the change lead to good
contributions is not done in the studied production development project.

6.2. Research question 2

RQ2: How shall transmitted design change be managed in production development projects
with respect to project management theory, the project character, and levels of interdependency
to other development projects?

Findings shows that turbulent projects haves to adopt a flexible project management
methodology in order to be able to adjust to changes, and that interdependent projects within
multi-project environments need good and structured communications and lowered levels of
decision making. Furthermore, design change shall be managed with a structured process that
enables flexibility. Therefore, Transmitted Design Change process, TDC-process, is suggested.
The process comes from the idea that an Engineering Change, EC, can be managed in a separate
project (which implies that a separate process model can be used) and inspired by the statement
that most of the EC processes are divided into different stages (Jarratt et al., 2011). The process
is also inspired by the implantation principles of Concurrent Engineering; map interdependent
activities, standardize process, construct a communication plan, and educate project employees
(Bhuiyan et al., 2006). Additionally, the steps of ECM-process and Scania´s ECO standard have
been of great importance when formulating the suggested strategy.

The theoretical framework concluded that high levels of change are related to project
complexity. Change in this sense relates to fluctuating preferences and technology changes
which impact the development of the product design. Furthermore, a projects internal opinions,
agreement and certainty can evaluate the project´s complexity. With high levels of agreement
with clear goals and project path, the complexity is reduced. However, if for instance the
developed design is uncertain and changes occur, the complexity increases.
A project complexity shall be managed with increased flexibility. Flexibility can be achieved
through adaptation of agile-principles, such as iterative processes. Moreover, some authors state
that a combined project management methodology shall be used to be able to control the
changes. A combined management model can e.g. be an agile-stage-gate model which ensures
control in the governance and flexibility in the operations. The hybrid principles state
improving a projects communication, panning and possibility to manage changing demands.
These are all features that the studied project is lacking. Agility was discussed in the analysis
and iterations were identified to become possible to adopt in the product development
generations. Simplified it could be expressed as: develop → test → develop → test etc. The test
results could then be provided to interdependent projects – e.g. the production development
project in means to be able to adjust to the identified changes quicker. Iterations in the
production development project will be achieved when identifying, evaluating, and assessing
different solutions, further presented below.

57
Additionally, the Transmitted Design Change process, TDC-process, includes a circular
(iterative) characteristic by its pre-change and post-change learnings, see figure 16. The figure
illustrates the iteration loops of TDC-process. The process starts with educating project
members (E) Then when the first design change (DC) occurs, it shall be announced (A), then
managed (M) and implement (I), and finally, the last step is learnings from the previous process
(L).

Figure 16. Iterations in TDC-process (Author’s own illustration)

Pre-change tasks (E) have to be performed in the beginning of a project and includes educating
the project members in how the design change management shall be communicated and
executed. Regarding the theoretical framework, education of Engineering Change reduces the
number of changes and calms the change effects and their willingness to propagate into other
projects. It is recommended to educate all involved project members that may affect an
interdependent project. Regarding the purpose of this study, the interdependent product
development projects and production development project shall be educated in each other’s
work and development processes in means of creating an equal understating. Furthermore, a
communication plan and responsibilities have to be decided. The communication plan shall
include how often changes shall be reported and how they shall be provided. The theory, as
well as Scania ECO standard, recommends distributing Engineering Changes trough a common
project database.

Post-change learning (L) shall be performed when the transmitted design change can be
evaluated. The interdependent production development project is responsible for evaluating and
publishing the post-change learnings in the common project database. These learnings close the
change loop (iteration) by evaluating the change and learning from mistakes and good practice.
Furthermore, the impact on time plans and budget shall be evaluated in means of understanding
the scale of the design change propagation. When the learnings are written, they have to be
embraced by the interdependent project – otherwise it is unnecessary to execute a learning step.

The suggested way to announce (A) a design change is to provide a design change report and
publish it in a common databased project area. Due to the difficulties to know what design
change information that has to be exchanged, suggests the interdependent projects are suggested
to use change reports. The report makes it possible for the product DP to do a “heads up” before
the change are completely determined and shallowly inform about all decided changes. The

58
design change report shall be updated by the product development project and include both
determined and potential design changes that might affect the product development project.
Moreover, the design change report shall continuously be updated with changes generated from
tests-activities, development-changes, superseded articles, uncertainties etc. The reason is
because of the theoretical framework´s suggestion to announce a design change by requesting
the change in a common data base, and the empirical result shows that a need for unified
information and mutual responsibility. The change report shall assure that all determined and
potential changes are presented together with important component information. Furthermore,
when the report is updated by the product development project it has to be published to the
interdependent production development project, which then has the responsibility to take action
if a change seems interesting. If further information is needed the production development
employee shall contact the responsible employee in the product development project.
When a change has to be conducted in the production development project, the management
(M) shall adopt flexibility in terms of iterations. An iteration can be included when identifying,
comparing, and assessing different options to solve the transmitted design change. Firstly,
assess the design change in means to understand the change reason and effect, then decide if
the change shall wait for further change (be buffered) or executed directly. As found in the
theoretical framework, the ECM process enables iterations in-between; identification of
possible solutions and risk assessment, and risk assessment and approval of solution. Just as the
ECM process, the suggested Transmitted Design Change process includes iterations. Before
implementing a transmitted design change dependencies to suppliers, other assemblies,
processes, and components shall be taken into consideration. If too high risks are revealed the
process shall lead back to the prior step and another solution shall be selected and assessed.
This iteration makes the process flexible by choosing one solution, test it, evaluate, choose one
other, test, evaluate etc. Eventually the best solution will be selected and implemented.

When the final solution is determined, the implementation (I) has to be planned. Regarding the
literature, the implementation has cope with the development process, decencies to other actors
(suppliers, interdependent projects, components etc.) and what type of change that will be
implemented. This intend to ensure that a production development project should take the
generations of the product development process into account when implementing the change
solution.

6.3. Recommendations
The recommendations and implementation plan is comprised of the self-made TDC-process,
Transmitted Design Change process, created to support a production development project
receiving and managing transmitted design changes form the product. The TDC-process can be
generalized to a broader field of interests; however, the section focuses on providing TOGS

59
specific implementation strategies and work processes trough support of the conclusions drawn
in section 6.1.

As the answer to RQ2 indicates, the TDC-process process covers guidelines for announcing,
managing, and implementing a design change. Furthermore, it states that Scania´s ECO
standard inspired the announcement stage. However, due to frequent design changes appearing
in TOGS and the high level of interdependency, the suggested way of managing design change
is simplified and created to be less time consuming than Scania ECO-standard.

An extended version of the TDC-process was created to suit Scania´s project TOGS and
interdependent product development project, see appendix 3. Additionally, one template and
one checklist was created to support the TDC-process, see appendix 4, and appendix 5. The
following subsections cover the stages of TDC-process, responsibilities and surrounding
project management support.
6.3.1. Project Management Methodology support
TOGS are suggested to enable more flexibility, but keep the existing standardized Scania
project management processes and complement it with the Transmitted Design Change process.

Regarding the theoretical framework, Scania FPP and TOGS´s design changes management
shall enable flexibility and control. Flexibility simplifies the management of changes and makes
it possible to run complex projects with fluctuating behaviors. Control gives the project
structure, common language, and division of work tasks.

The Transmitted Design Change process constitutes of traditional, linear principles, and
flexibility will be achieved through the correct use of the process together with opportunities
from the PD-process´s generations. The gearbox development project shall continue utilizing
PD-process, but the project needs to embrace the product generations as an iterative activity (as
a feature in agile-project principles) to take advantage of the change opportunity. This will be
made through announcing and managing the changes with use from the stated recommendations
in section 6.2.3 and 6.2.4.
6.3.2. Learning: pre-change
Before the start of the project, TOGS, shall educate the employees in managing design change
in the project. It shall be of responsibility for all managers involved in FPP and TOGS to educate
the employees connected to the gearbox development projects. The education shall include;
knowledge about how a design change can escalate into other projects, required communication
strategy, and information exchange. The interdependent projects shall also learn about
dependent parties’ project processes. For instance: The product DP shall learn about TOGS
purchase processes (PEIP), and production development, and assembly process at Scania DT.
TOGS project members shall learn about how to adopt the design changes in to TOGS.

60
Furthermore, a communication plan shall be created to visualize the responsibilities if change
occurs.

6.3.3. Announcing design change

TOGS needs information from the Product DP in order to be able to adjust the assembly line
and provide the production equipment suppliers with correct information. Therefore, the
announcing step has to be monitored closely.
The communication plan shall support the product DP to contact the correct subproject manager
in TOGS, or vice versa. Furthermore, the plan shall include what information that is required
to be exchanged. As concluded in section 6.1.2. the information exchange shall be supported
by a design change report and distributed in at common data base. More specific, TOGS and
the product DP are recommended to use a common mailbox (inspired by Scania´s ECO-
standard). The mailbox can be named “FPP Gearbox DC”, and shall only include gearbox
related changes and learnings.

To achieve a common language in communicating design changes, a template is created,

(appendix 4). The report is suggested to be continually (daily) updated and distributed with an
even interval (every second week is suggested, weekly believes to implies too much work, and
monthly leads to bad communication). The product DP shall be responsible for filling in the
report and in a unified document send it by using the common mailbox.
The template shall state part name and number, and responsible designer from the product DP
(who TOGS can contact if further information is needed), change classification, and initiated
change date. The change classification shall indicate the status and type of change. Four
classifications are recommended; A1, A2, B, and C. A1 and A2 are determined changes where
A1 signifies that a component has got a new design and A2 that the component is superseded.
The new part number shall be stated if the component is superseded. B indicates that the product
will probably be changed, e.g. if a related component is changed. As stated in section 6.2.2.,
the product DP employees shall learn how to evaluate the potential propagation of design
changes. Lastly, C stands for components with unknown design.

The communication plan and mailbox shall be created before project execution. All project
members are responsible to subscribe to the common DC-mailbox.

6.3.4. Managing design change

The management stage starts when the design change announcement is made and a change has
propagated into TOGS. The subproject managers in TOGS are responsible for executing this
step. The management is about selecting the best solution of solving the transmitted design
changes.

As stated in the section 6.1.2. this step has to evaluate if the change shall be buffered or executed
directly. If the changes are decided to be buffered, coming steps wait until the complete change

61
shall be solved. When the change shall be solved, the same iterative execution follows as in
section 6.1.2 in means of selecting the best solution. Inspired by Scania’s FMEA/PFMEA
standard the change shall be assessed by evaluating the failure mode and effect (what type of
change and how it affects the production development project). The risk assessment constitutes
of a compromised assessment inspired by empirical interview findings and the theoretical
framework. TOGS have to consider following limitations and factors: production equipment
suppliers (depending on stage in PEIP and if an RFQ is placed), space in the assembly line,
time and resources to allocate, ensure high product quality as well as interdependent processes,
components, and projects. If the change affects a placed requirement specification, RFQ, or
purchased equipment the production equipment supplier shall be contacted in this stage.

6.3.5. Implement change

The subproject managers in TOGS are responsible for the implementation. The PD-process
generations indicate that a design change will be implemented in the following generation. This
implies that if a design change is announced correctly, TOGS shall be able to implement the
transmitted change directly. In some cases, for instance when a RFQ is placed and the
production equipment supplier will implement the solution, the responsible subproject manage
has to monitor the implementation and ensure that the latest design changes are reported.

6.3.6. Learning: post-change

The learning stage shall be executed when change has been implemented and can be evaluated.
The subproject manager in TOGS are responsible to provide the learnings. Questions that a
subproject manager can ask is: What triggered a change in TOGS? How was the change
discovered? What was successful? What could have been made differently? How did the design
change affect the project? Did the design change propagate from TOGS, examine both internal
and external propagation? Did the change affect time and budget? Was better product quality
achieved?

When the learnings are written, they have to be embraced by the product DP. Therefore, the
learnings will be published in the DC-mailbox. All involved project members are responsible
to read the learnings.

6.4. Academic Contributions

During the creation of the theoretical framework, literature about transmitted design change
management in production development projects was realized to be non-existing. However, the
theoretical findings showed how Engineering Change can be managed in a structured way, and
that interdependency provided knowledge about a change behavior and risk to propagate into
other projects (Chua & Hossain, 2012; Harmaz et al., 2012; Jarratt et al., 2011;). The theory
revealed that a product development project creates “opportunities” for the production to
change, and vice versa (Lager, 2002). However, nothing states how a production development

62
project shall manage transmitted design change. So, the thesis purpose was to fill the gap of
literature and contribute an example of how a production development project is managing
transmitted design change and furthermore provide recommendations on how the management
can become better with respect to the studied literature and empirical findings.
The method to conduct two sets of interviews gave this study an advantage. The first set help
building the thesis purpose and formulate research questions and the second investigated the
discovered problematic area. To support the interviews, a method inspired by qualitative
content analysis was used to examine secondary sources; Scania documents, standards, and
routines. The documents states what Scania “shall” execute, and the interviews helped
understanding the respondents’ reality. If a similar research will be carried out, the author would
recommend to do collect empirical data through the stated method.
The theoretical framework together with the empirical data submits an analysis how the project
shall manage design change and achieve a suitable project management philosophy.
Additionally, the empirical contributions provide a real example of how design changes are
managed in a production development project. The empirical knowledge will hopefully be used
in further research in this field, as an example how the reality may look in a development project
at a global industrial firm.

Furthermore, as practical contributions have recommendations, a checklist, and a template been

provided. The practical contributions describe how the Scania´s project TOGS can become
better in managing transmitted design change and how the interdependent product DP can
support TOGS with design change reports. The recommendations state how design change shall
be announced, managed as well as implemented. Furthermore, the recommendation covers a
“pre-change stage” which shall increase the knowledge of the design change management and
determine responsibilities and a communication plan, and a “post-change stage” which shall
include learnings from the conducted change. It is up to TOGS and the interdependent product
DP to take responsibility and adopt to the stated recommendation.

To broaden the scientific contributions, an attempt will be made to generalize the provided
recommendations. Due to the requirement to meet the acceleration of new products and
complexity of production system. Production companies need to be able to manage
simultaneous development projects with high levels of complexity in the projects structure,
execution, and management (e.g. Vogel & Lasch, 2016; Sapuan et al., 2006). The proposed
TDC-process can so be adopted in means of control the transmitted design change management
with a structured process that as well enables iterative activities by executing learning stages.
If another production development project (with an interdependent product DP) want to assume
the TDC-process it is recommended (with inspiration from concurrent engineering) to map
interdependent activities and then also investigate the companies project management
methodologies – with the purpose to investigate how the TDC-process would work with the

63
company´s other strategies, methodologies, and processes. As recommended for Scania TOGS,
TDC-process will be a supplement onto their other methodologies and routines. Furthermore,
the empirical foundlings show that the two most important features of the TDC-process are the
iterative enablers and how the design change announcement (or searching) will be carried out.
The iterations will give the TDC-process a looping character and help the employees become
better in managing transmitted design changes by wringing and embracing learnings from each
change. In the pre-change stage shall also all project employees be educated of how to
announce, manage, implement, take learnings from a transmitted design change. The
announcement and searching for design changes is recommended to be an activity with a split
responsibility which has to be executed periodically. The purpose is to divide the consumption
of time to spend on reporting or searching the changes, and the pre-change education shall make
it clear why it is important to provide the information about changes. Moreover, the supporting
design change report template and TDC-checklist can be used to support the recommendations;
however, the specific production development project who adopt the TDC-process and adjust
it to the specific project has to ensure that the checklist reflects the changed TDC-process, and
that the design change report template is developed to suit the specific projects potential
“change classifications”.

This study provides an empirical example of how transmitted design changes are managed in a
production development project and also provides some arguments how the management can
become better. Thereby, the thesis met the purpose, and by that filled a gap in the literature in
the field of Industrial Engineering and Management.

6.5. Research Credibility

Since this study only examines one subproject in a large organization, difficulties and
disagreement might exist whether the conclusions can be generalized or not. However,
interdependence problems and frequent design change have to occur in many similar projects
in industrial firms. Therefore, some generalized answers how a production development project
can manage design changes are provided, see section 6.1.2. Nevertheless, the study´s bias and
ability to generalize has to be taken in to account if similar project adopts the recommended
Transmitted Design Change process.
In the beginning of the thesis some limitations was announced. For instance, that only TOGS
perspective was studied. By including empirical data from an interdependent development
project would perhaps enhanced the trustworthiness of the conclusions. The limitation also
constrained the theoretical framework with production engineering philosophies, innovation
and business concepts, and some management philosophies. However, the limitations gave the
study a consistent research area and focused on a production development project´s view and
theory based on Engineering Change theory and project management methodologies.

64
 6.6. Difficulties and Delimitations
Due to the project´s temporary setup and ongoing status, the adaptation of the study´s result
will be limited in means of achieving better design change management in the studied gearbox
development project at Scania DT. Likewise, the empirical collection will be difficult to
replicate. These factors limit the research to become generalized and fully adopted by the
studied gearbox development project.

The most difficult recommendation to implement is believed to be the “post-change learning”

between the design change loops. Despite similarities to the studied project´s used process of
purchasing equipment (PEIP – Production Equipment Investment Process), may these learnings
require too much time and work. The recommendation to share the reasonability of announcing
and searching for design change, and additionally the project employees own reasonability to
embrace learnings, can be discussed as a weak part of the recommendations. However, if all
interdependent project employees get educated (by the stated recommendations) this weakness
may be reduced.

6.7. Suggestions for Future Studies

The author suggests conducting a wider study to fully be able to state a general way of managing
design changes in a production development project. Because of the stated limitations, both the
theoretical framework and the studied case at Scania was limited. By changing the perspective
of research, with other theory or another project group at Scania (or other industrial company),
the findings would perhaps different conclusions and recommendations be stated. As for
instance, the perspective of innovation and business theory, or the perspective of the
interdependent product DP.

Additionally, the stated recommendations to TOGS have to be tested and examined, to

understand their impact and potential improvements. Furthermore, the “uniqueness” of the
project has to be examined. The empirical data presents that this type of project and these levels
of interdependency are unusual at Scania, but the theory of multi-projects and concurrent
engineering states the opposite. Moreover, it would be interesting to investigate how TOGS
affects other projects, especially gather a greater understanding how a production development
project impacts a product development project and other interdependent development projects
within the multi-project structure.

65
 References
Scientific Article

Alblas, A. A., and Wortmann J. (2012) Managing large engineering changes - The case of a
high-tech microlithography equipment manufacturer. International Journal of Operations &
Production Management
Vol. 32 No. 11,
pp. 1252-1280

Araszkiewicz, K. (2017). Application of Critical Chain Management in Construction Projects

Schedules in a Multi-Project Environment: a Case Study. Procedia Engineering 182, 33–41

Aritua, B., Smith N.J., and Bower, D. (2009). Construction client multi-projects — a complex
adaptive systems perspective. International Journal of Project Management 27, 72–79.
Bhuiyan, N., Thomson, V., and Gerwin, D. (2006). Implementing Concurrent Engineerng -
product development managers need a single, well-defined proeess with clear ownership and
goals. Research - Technology Managemen, Vol. 49, 38–43
Bitektine, A. (2008). Prospective Case Study Design – Qualitative Method for deductive Theory
Testing. Organizational Research Methods Volume 11, 160-180

Brandl, F. J., Kagerer, M., and Reinhart, G. (2018). A hybrid Innovation Management
Framework for Manufacturing – enablers for more agility in Plants. a CIRP 00 (2017) 000–
000 Procedia CIRP 72,1154–1159
Buganza, T., Dell’Era, C., and Verganti, R. (2009) Exploring the Relationships Between
Product Development and Environmental Turbulence: The Case of Mobile TLC Services.
Product innovation management, no. 26, 308–321

Chronéer, D., and Bergquist, B. (2012). Managerial Complexity in Process Industrial R&D
Projects: A Swedish Study. Project Management Journal, Vol. 43, No. 2, 21–36

Chua, D., and Hossain, A. (2012). Predicting Change Propagation and Impact on Design
Schedule Due to External Changes. IEEE, Transactions and engineering management, Vol, 59,
483-493
Conforto, E. C., Salum, F., Amaral, D. C., da Silva, S. L., and de Almeida, L. F. M. (2014).
Can Agile Project Management Be Adopted by Industries Other than Software Development?
Project Management Journal, Vol. 45, No. 3, 21–34

Cooper, R. G., and Sommer, A. F. (2016). Agile-Stage-Gate: New idea-to-launch method for
manufactured new products is faster, more responsive. Industrial Marketing Management, 59th,
157-180.

Eriksson P. E., Larsson, J., and Pesämaa, O. (2017) Managing complex projects in the
infrastructure sector — A structural equation model for flexibility-focused project
management. International Journal of Project Management 35 (2017) 1512–1523

66
Fischer, P. M., Deshmukh, M., Maiwald, V., Quantius, D., Gomez, A. M., and Gerndt, A.
(2018). Conceptual data model: A foundation for successful concurrent engineering.
Concurrent Engineering: Research and Applications, Vol. 26, 55–76


Gerring, J. (2017). Qualitative Method. The Annual Review of Political Science, 20, 15–36

Gil N, Tommelein I.D., and Schruben L.W. (2006). External Change in Large Engineering
Design Projects: The Role of the Client. IEEE Transactions on engineering management, Vol.
53, No. 3.

Graneheim, U. H., and Lundman, B. (2004). Qualitative content analysis in nursing research:
concepts, procedures and measurements to achieve trustworthiness. Nurse education today 24,
105-112.

Hamraz, B., Caldwell, N.H.M., and Clarkson P.J. (2012). A Holistic Categorization Framework
for Literature on Engineering Change Management. Systems Engineering, Vol. 16, No. 4, pp
473-505
Huang, G. Q., Yee, W. Y., and Mak, K. L. (2003) Current practice of engineer- ing change
management in Hong Kong manufacturing industries, Journal of Materials Processing
Technology 139, 481–487

Jarratt, T. Cladwell, N., Clarkson, J., and Eckert, M., (2011). Engineering change. an overview
and perspective on the literature. Research engineering design, 22, 103–124

Jarratt, T., Clarkson, J., and Eckert, C. (2005). Engineering change. In J. Clarkson & C. Eckert
(Eds.), Design process improvement, 262-285

Jinping, C., Zhang, S., Wang, M., and Xu, C. (2017). A novel change feature-based approach
to predict the impact of current proposed engineering change. Advanced Engineering
Informatics 33 132–143

Kernschmidt, K., Behncke, F., Chucholowski, N., Wickel, M., Bayrak, G., Lindemann, U., and
Vogel-Heuser, B. (2014). An integrated approach to analyze change-situations in the
development of production systems. Procedia CIRP, Conference on Manufacturing Systems,
17, 148 – 153

Killen, C.P. and Kjaer, C. (2012). Understanding project interdependencies: The role of visual
representation, culture and process. International Journal of Project Management, 30, 554–566
Kurdve, M., Sjögrenb, P., Gåsvaera, D., Widfeldt, M., and Wiktorssonc M. (2016). Production
System change strategy in lightweight manufacturing, Procedia CIRP 50, pp 160 – 165

Lager, T. (2002). A structural analysis of process development in process industry: A new

classification system for strategic project selection and portfolio balancing. R&D Management
32, 87-95

67
Mayor, H., and Turner, N. (2017). Understand, reduce, respond: project complexity
management theory and practice. International Journal of Operations & Production
Managemen. No. 8, 1076-1093

Onwuegbuzie, A. J., and Leech, N. L. (2009). Generalization practices in qualitative research:

a mixed methods case study. Qual Quant, 44, 881–892

Packendorff, J. (1995). Inquiring into the temporary organization: new directions for project
management research. Scand. J. Manag. 11, 319–333.

Pollack, J. (2007). The changing paradigms of project management. International Journal of

Project Management 25, 266–274

Sapuan, S. M., Osman, M. R. and Y. Nukman, Y. (2006). State of the art of the concurrent
engineering technique in the automotive industry, Journal of Engineering Design, Vol. 17, No.
2, 143–157
Saynisch, M. (2010). Mastering Complexity and Changes in Projects, Economy, and Society
via Project Management Second Order (PM-2). Project Management Journal, Vol. 41, No. 5,
4–20

Singhry H. B., Rahman, A. A., and Imm, N. S. (2016). Effect of advanced manufacturing
technology, concurrent engineering of product design, and supply chain performance of
manufacturing companies. International Journal Advanced Manufacturing Technology, 86,
663–669

Sorli, M., Stokic, D., Gorositza, A., and Campos, A. 2006. Managing product/process
knowledge in the concurrent/simultaneous enterprise environment. Robotics and Computer-
Integrated Manufacturing, 22nd, 399–408

Špundak, M. (2014). Mixed agile/traditional project management methodology – reality or

illusion? Procedia - Social and Behavioral Sciences 119, 939 – 948
Vogel, W. and Lasch., R. (2016). Complexity drivers in manufacturing companies: a literature
review. Logistics Research, jornal, 9:25, 1-66
Windt, K., Philipp, T., and Böse, F. (2008). Complexity cube for the characterization of
complex production systems. International Journal of Computer Integrated Manufacturing, Vol.
21, No. 2, 195-200
Zhang, L. (2013). Managing project changes: Case studies on stage iteration and functional
interaction. International Journal of Project Management 31, 958–970

Book

Bryman, A. (2011). Samhällsvetenskapliga metoder. Malmö: liber. IBSN: 978-91-47-09068-6

68
Bryman, A. and Bell, E. (2011). Business Research Methods. 4rd edition. Oxford: University
press. ISBN: 978-0-19-958340-9

Hallin, A. och Karrbom Gustavsson T. (2012). Projektledning. 1:2 uppl. Malmö: Liber. ISBN:
978-91-47-09725-8
Stacey, R. D. (2007). Strategic management and organizational dynamics: the challenge of
complexity to ways of thinking about organisations. Harlow: Financial Times, 5 ed, ISBN: 978-
02-73-70811-7

Patton, M.Q. (2002). Quantitative evaluation and research methods. Thousand Oaks California
US: Sage Publications Inc. ISBN: 978-0-7619-1971-1

Project Management Institute (2008). A Guide to the Project Management Body of Knowledge.
Fourth Edition (PMBOK Guide). Newtown Square, PE: Project Management Institute.


Web
Metz, T. (2018). Agile Vs Waterfall? Don’t Risk Failure by Using the Wrong One. MG Rush,
5th June, Collected; 1 mars 2019 https://mgrush.com/blog/2018/06/05/agile-vs-waterfall/

Scania Intranet

90001. (2011). Short description ECO

ECO Technical Writing. (2017). Instruction

Prosses-FMEA för bearbetning. (2010). Instruction

Scania FPP. (2017). Document

STD3438. (2013). The Engineering Change Order System – ECO

STD4005. (2017). FMEA Standard, pp. 35–39

STD4293en. (2007). Project and Assignments

STD4303en. (2013). Product Development process

Scania PEIP. (2018). Guidelines

69
 Appendix
1. Interview Guide – Background Interviews
Questions for all respondents
General
1 Describe your work at Scania DT?
The project models at Scania:
How does Scania Standard Project management model differentiate themselves?
2 (PEIP/PD/PPS)
Should it be the unique project decision to select what project management models that
3 will be used?
4 How shall Scania develop the PM-models and project management?
5 What benefits exists in having several PMMs?
6 What contradictions exists in having several PMM?
Interview, involved managers in TOGS:
TOGS-background:
1 How would you summarize TOGS? Purpose and goal??
2 What have you so fare accomplished?
3 Give some positive and negative aspects about the projects execution?
4 How have the projects time frame changed since the start?
The project management:
5 Your general view of the used PM-models?
6 Why did the project select PEIP and PD?
How does the PM-models help you in the project? Do the models fulfil your
7 requirements?
8 How does the PM-models support structure between the different project groups?
9 How does the PM-models support keeping up to deadlines?
Interview with technical manager at DT, knowledge about TOGS:
1 What improvements should TOGS do?
2 what are the grates concerns with TOGS?
3 Your general view of the used PM-models?
How does the PM-models help you in the project? Do the models fulfil your
4 requirements?
5 Why do you think Scania have brought in an external PM-model? (PPS)
Interview with PPS-responsible at the improvement office:
1 Why do you think Scania have brought in an external PM-model? (PPS)
2 Tell me more about PPS at Scania!
What concerns and risks do you see with today’s PM methods at Scania? (PPS, PEIP,
3 PD)
Interview with PM-model knowledge about Scania DT:
1 What improvements should TOGS do?
2 what are the grates concerns with TOGS?
1
 3 Why did the project select PEIP and PD in TOGS?
4 To what extent are PEIP and PD-process used at Scania?
5 Why do you think Scania have brought in an external PM-model? (PPS)

2. Interview Guide – Empirical Interviews

Questions to, subproject managers
First of all, mark the level of interdependencies between Product development and
1 production development. (figure 6 .Q1, page 22)
2 From what direction does change occur? (figure 6. Q2, page 22)
3 Tell me about a EC that have occurred in your work!
o Small/incremental or grate/radical?
o How did it propagate from a product change to a production change?
o How was is it announced?
o How was it evaluated?
o How was the change executed?
o Did you report the selected change and when the change is executed? If, where was it
reported?
o Who got affected by the change you did in the production development project?
4 How is propagation handled? Do you actively work to reduce propagation?
5 Does it exist a preferred way how to manage EC?
6 What have you learned from managing EC?
Questions to, project manager & group manager:
First of all, mark the level of interdependencies between Product development and
1 production development. (figure 6. Q1, page 22)
2 From what direction does change occur? (figure 6. Q2, page 22)
3 What is a design change for you?
Does it exist a “Scania-way” of handle design changes (a standard)? Or do you have an own
4 idea how it should be managed?
o How shall they be announced?
o How shall the solution be selected and announced?
o How is propagation considered?
o Who should be informed about a change from TOGS/the production DP?
Have there been any trouble announcing or receiving design changes? (seen from the
5 perspective; product PD –> production PD)
6 What can you learn from managing ECs?

2
3. Interview Visualization: Design Change Process

The suggested design change process (Author’s own illustration)

3
4. Template: Scania Design Change Report
# Date Part name part number Change classification Responsible
(A1, A2, B, C) designer
1.
: : : : : :

: : : : : :
n.

5. Checklist: Scania Design Change Management

TASK DONE

1 Educate employees

2 Create communication plan

3 Create DC-mailbox for project
4 Change Report
4.a Announced every second week
4.b Publish change report in DC-mailbox
Occurred change

5 Management
5.a Assess the change
5.aa (contact production equipment supplier)
5.b Find Solutions
5.c Compare solutions
5.d Risk assessment

5.da Limitations
5.db (contact production equipment supplier)
5.dc Ensure quality
5.dd Interdependency and effect
5.e Select solution
6 Implement
7 Learnings
7.a Publish the learnings in DC-mailbox