prerequisites for an ict-platform at volvo group...
TRANSCRIPT
Department of Product and Production Development CHALMERS UNIVERSITY OF TECHNOLOGY Gothenburg, Sweden 2015
Prerequisites for an ICT-platform at
Volvo Group Trucks Study of the product development and production interface within projects Master’s thesis in Production engineering
Johan Korteniemi David Mattsson
Prerequisites for an ICT-platform at
Volvo Group Trucks
Study of the product development and production interface
within projects
Johan Korteniemi
David Mattsson
Supervisor: Atieh Hanna, Pierre Johansson, Magnus Åkerman
Examiner: Åsa Fasth-Berglund
Department of product and production development
CHALMERS UNIVERSITY OF TECHNOLOGY
Göteborg, Sweden 2015
Prerequisites for an ICT-platform at Volvo Group Trucks
Study of the product development and production interface within projects
© JOHAN KORTENIEMI & DAVID MATTSSON, 2015
Departments of Product and Production Development
Chalmers University of Technology
SE-412 96 Göteborg
Sweden
Telephone +46 (0)31-772 1000
Cover:
A picture of collaboration (Pixabay, 2015)
Chalmers Reproservice
Göteborg, Sweden 2015
i
ABSTRACT
This work was conducted at Volvo Group Trucks Operations (GTO) at Lindholmen,
Gothenburg.
Product development projects at Volvo Group Trucks have a tendency of being delayed. One
possible problem causing this effect is the lack of transparency between two departments
handling product development and production. This thesis investigates if an ICT-platform
could facilitate the communication and information flows, the use of IT-tools and project
processes in project work, which otherwise could hinder the collaboration between the two
departments.
The research was first conducted by a pre-study which focused on getting background
information of the different project processes and tools used by the departments. The acquired
knowledge was used to construct interview questions which were asked to employees at
Volvo working with the mentioned areas. The empirical findings from the interviews were
used in the analysis together with theory found in the literature study.
From the analysis several improvement areas were found and categorized as: communication,
documentation, knowledge, resources and gates. Several improvement areas showed that they
could be supported by an ICT-solution, but some areas was found to hinder the
implementation of an ICT-platform. Due to the limitation of the project the authors of this
thesis could not say in what extent the improvement areas were affecting other departments at
the company.
Keywords: ICT, project, standardization, process
ii
SAMMANFATTNING
Det här arbetet genomfördes på Volvo Group Trucks Operations (GTO) på Lindholmen i
Göteborg.
Produktutvecklingsprojekt inom Volvo Group Trucks har en tendens att försenas. Ett möjligt
problem som orsakar den här effekten är bristen på transparens mellan två avdelningar som
hanterar produktutveckling och produktion. Det här examensarbetet undersöker om en ICT-
plattform kan underlätta kommunikationen, informationsflödet, användningen av IT-verktyg
och projektprocesser i projektarbeten, som annars skulle kunna hindra samarbetet mellan de
två avdelningarna.
Undersökningen genomfördes först genom en förstudie som fokuserade på att få
bakgrundsinformation om de olika projektprocesserna och verktygen som används av
avdelningarna. Den förvärvade kunskapen användes för att konstruera intervjufrågor som
ställdes till de anställda på Volvo, som arbetar med de nämnda områdena. De empiriska
resultaten från intervjuerna användes i analysen tillsammans med teorin från litteraturstudien.
Genom analysen kunde flera förbättringsområden konstateras och kategoriseras som:
kommunikation, dokumentation, kunskap, resurser och ”gates”. Flera förbättringsområden
visades att de skulle kunna stödjas av en ICT-lösning, medan det konstaterades att vissa
områden skulle hindra tillämpningen av en ICT-plattform. På grund av arbetets avgränsning
kan författarna till denna studie inte säga i vilken utsträckning förbättringsområdena påverkar
andra avdelningar på företaget.
Nyckelord: ICT, projekt, standardisering, process
iii
PREFACE
This work was partially supported by the Know4Car project, grant agreement number
284602, funded by the EC Seventh Framework Programme theme FoF-ICT-2011.7.4.
ACKNOWLEDGEMENT
There are several people we like to acknowledge that helped us during our thesis work. First
of all, we would like to thank our supervisors at Volvo Group Trucks, Pierre Johansson and
Atieh Hanna, for their supporting roles and all their input and feedback throughout our thesis
work.
We would also like to thank our examiner Åsa Fasth-Berglund and supervisor Magnus
Åkerman at Chalmers University of Technology, who have helped us greatly with structuring
our thesis and given advice on how to proceed with the project.
We are deeply grateful for all eleven anonymous interviewees for have taken the time and
answering our questions. Without them we would never had acquired the knowledge to
complete this thesis.
Last but not least, we would like to thank Volvo Group Truck Operation for the opportunity to
conduct our master thesis within their organization, as well as the whole group at the office
who made us feel welcomed.
Gothenburg, June 2015
Regards,
David and Johan
iv
ABBREVIATIONS
Ad-hoc – “Created or done for a particular purpose” (Oxford dictionary)
CPM – Chief Project Manager
DFA – Design For Assembly
DVP – Develop Product and Aftermarket Product Portfolio
GTO – Group Trucks Operations
GTT – Group Trucks Technology
ICT – Information Communication Technology
ICT-platform – Several ICT-solutions that cooperates
ICT-solution – A function that facilitates one project area
ILG – Industrial Launch Group
JSON – JavaScript Object Notation
K4C – Know4Car
OBS – Organizational Breakdown Structure
PAP – Project Assurance Plan
PGT – Project Governance Tool
PM – Project Manager
PMR – Product Modification Request
PSM – Project Steering Model
PTM – Project Time Management
QDCF – Quality, Delivery, Cost and Feature
RBS – Resource Breakdown Structure
SC – Steering Committee
STP – Standard Time Plan
WBS – Work Breakdown Structure
White-book – Summary of a completed project, including lessons learned
XML – Extensible Markup Language
TABLE OF CONTENTS 1. Introduction .......................................................................................................................... 1
1.1 Background ....................................................................................................................... 1
1.2 Know4Car ......................................................................................................................... 2
1.3 Problem Definition ........................................................................................................... 2
1.4 Purpose ............................................................................................................................. 2
1.5 Research Questions........................................................................................................... 3
1.6 Limitations ........................................................................................................................ 3
2. Method ................................................................................................................................... 4
2.1 Methodology ..................................................................................................................... 4
2.2 Pre-study ........................................................................................................................... 5
2.3 Literature study ................................................................................................................. 5
2.4 Interviews ......................................................................................................................... 6
2.5 Analysis ............................................................................................................................ 8
2.6 Repeatability ..................................................................................................................... 8
2.7 Validation ......................................................................................................................... 8
3. Theory ................................................................................................................................... 9
3.1 Product development and production interface ................................................................ 9
3.2 Project ............................................................................................................................... 9
3.2.1 Project Management ................................................................................................ 10
3.2.2 Stage-Gate ................................................................................................................ 15
3.3 ICT/Collaboration network ............................................................................................. 17
3.4 Change Management ...................................................................................................... 18
4. Empirical Findings ............................................................................................................. 20
4.1 Current Process and Tools at Volvo ............................................................................... 20
4.1.1 DVP .......................................................................................................................... 20
4.1.2 PAP and PGT ........................................................................................................... 21
4.1.3 PSM .......................................................................................................................... 21
4.1.4 Time Plans ............................................................................................................... 22
4.1.5 Communication and Documentation ....................................................................... 22
4.2 A General Concept of Project Work in a Start Cost Project .......................................... 23
4.3 Improvement areas ......................................................................................................... 25
4.3.1 Communication ........................................................................................................ 25
4.3.2 Documentation ......................................................................................................... 26
1
4.3.3 Knowledge ............................................................................................................... 27
4.3.4 Resources ................................................................................................................. 27
4.3.5 Gates ........................................................................................................................ 28
5. Analysis ............................................................................................................................... 29
Communication .................................................................................................................... 29
Documentation...................................................................................................................... 29
Knowledge ............................................................................................................................ 30
Resources .............................................................................................................................. 31
Gates ..................................................................................................................................... 31
6. Discussion ............................................................................................................................ 32
6.1 Further work ................................................................................................................... 34
7. Conclusion ........................................................................................................................... 35
References ............................................................................................................................... 36
Appendix A ................................................................................................................................ I
Communication ....................................................................................................................... I
Documentation...................................................................................................................... III
Knowledge ............................................................................................................................ VI
Resources ........................................................................................................................... VIII
Gates ...................................................................................................................................... X
Appendix B.............................................................................................................................. XI
Appendix C ............................................................................................................................. XI
Appendix D ........................................................................................................................... XII
1
1. INTRODUCTION
The introduction chapter includes a background of the company which includes the current
state at the company and a general description of the theory surrounding the problem
definition. A short background information about the origin of this thesis will be brought up
in chapter 1.2. The problem definition brings up the current problem and then the purpose
chapter describes why the chosen methods have been used. After chapter 1.4, the research
questions narrow down the research field to end up with the aim of this paper. The last
chapter limitation includes both limitations and delimitations.
1.1 Background The project was conducted at Volvo Group Trucks Operations (GTO) at Lindholmen,
Gothenburg. GTO is a department under Volvo Group Global. The Volvo Group employs
around 100,000 people and is a world leader in trucks, busses, industrial and marine engines
and construction equipment. GTO handles the production of engines, transmissions, spare
parts and vehicles for Volvo Group Trucks. This also includes managing the process changes
in the production.
GTO follows a certain flow when working on a project which is called Project Steering Model
(PSM). PSM helps steer the project towards important activities that are executed in the right
order, open gates and complete the project. There are several factors that can activate a
production project; optimization of a process, improvement of work ergonomics and product
changes.
Product development and changes are handled by Group Trucks Technology (GTT). GTT
preforms research in product development, product planning and support products in the
aftermarket. At the moment, GTT has a project model called “Develop Product and
Aftermarket Product Portfolio” (DVP). The process of handling a project in a product development environment is documented in the DVP-Handbook. The handbook describes the
principles and different activities on how to handle product development projects. The cross-
functionality between GTT and GTO is a well discussed subject at Volvo Group Trucks both
concerning projects and assignments. The focus on this thesis is on how the project work at
GTO and GTT is preformed and also the correlation between the two departments in product
development projects.
How well a communication and information flow between the two departments determines
the quality of the product and how fast the product can go into production (Bellgran &
Säfsten, 2010).
One way of supporting the information and communication flow is by using an ICT-platform
(Information Communication Technology), ICT-solutions can help speed up the product
project, increase the efficiency between engineering and design, and increase the
collaboration in an organization (Camarinha-Matos, Afsarmanesh, Ollus 2008).
This thesis will investigate how and if an ICT-platform can support the structured project
work and information flow between GTT and GTO. The aim of this thesis is to see if an ICT-
platform can support process/activities and visualized information channels to increase the
efficiency and transparency of project work. This master thesis originates from the project
2
Know4Car (K4C) which is an EU initiative to increase the collaboration between companies.
The chapter below gives further information about the K4C project.
1.2 Know4Car Know4Car is a project which involves several
companies and institutions, supported by EU,
who are developing an Internet based tool (ICT-
platform) for managing manufacturing
knowledge. Focus lies on collaboration between
product, production and suppliers. The aim of
K4C is to be user friendly where the right
knowledge easily can flow between internal and
external stakeholders. See Figure 1.1.
1.3 Problem Definition The transparency and collaboration between GTT and GTO is known to be a problem when
working in product development projects. These problems sometimes result in product
projects being delayed. This is not supported by the principles that should be followed in a
product project.
One transparency problem is that GTO generally finds that they are getting hands-on
information too late when working in product development projects and that it is hard to get
hold of this information by their own. At the current state, it is the project manager at GTO
that has deeper knowledge on the activities that are being carried out in a product
development project. Employees at GTO need to go through their manager to retrieve this
information. This thesis strives to find a solution to make the interface between GTT and
GTO more transparent and increase the collaboration.
1.4 Purpose The purpose of this thesis is to investigate and document the practical project work, including
communication and data flows. The documentation will then be used to identify improvement
areas. These improvement areas will be the foundation when trying to determine if an ICT-
platform can be implemented and assist project work at Volvo Group Trucks.
Figure 1.1 Know4Car Circle.
(Know4Car consortium, 2015)
3
1.5 Research Questions Three research questions were prepared to help approach the project, they are presented in
Table 1.1. Below each research question is a brief explanation of why the areas were
investigated. The last three columns show how the research questions were answered.
Table 1.1 Research Questions
RQ# Research question Pre-study Interviews Theory
RQ1 How is practical project work carried out at
GTO and GTT?
Due to the size of both GTO and GTT the
research will only result in a general
understanding of how project work is carried
out. Some areas are more researched to find
where and how project information is
communicated.
x
x
RQ2 How is information communicated between
GTO and GTT in project work?
From RQ1 not all communication is
documented, but the documented
communication will be analyzed and compared
with theory to build a firm base that can be
elaborated to support an ICT-solution.
x
x
RQ3 How can an ICT-solution support project
work and collaboration at GTO and GTT?
Theory from the literature study on the
advantages from an ICT-platform will be
compared with the analysis of the improvement
areas at Volvo.
x
1.6 Limitations The total time for the project was 20 weeks. Due to the short time span, a complete
observation of all branches in the organization and interactions within product and production
development could not be documented. Therefore the ICT-solution will cover ad-hoc
functions which help the collaboration between product development and production. We are
aware that product documentation (e.g. CAD files, simulation results, engineering reports,
applicable variant combination, etc.) is an important part of the project work and the
communication between GTT and GTO, but this has been excluded from our scope.
4
2. METHOD
In the method chapter the methodology that was used will be explained, the chapter will also
cover how the different methods were used.
The different method used and in which order is illustrated in Figure 2.1.
2.1 Methodology The chosen methodology was developed over time with the underlying research questions in
mind.
The project was conducted through an inductive qualitative research. Inductive research was
chosen over deductive research to find out if the problem is an anomaly at Volvo. To do this,
the improvement areas were inductively researched. This means that the results were verified
with theory. A deductive approach would do the opposite, verify the theory or a hypothesis if
it is applicable to the real world. The difference is illustrated in the picture below. (Bryman &
Bell, 2003)
Figure 2.2 Difference between inductive and deductive reasoning
A quantitative approach was not chosen because it only answers the problem from an
objective stand point (Bryman & Bell, 2003). This thesis tries to determine how the practical
work is carried out. Therefore a qualitative approach was more suitable.
Figure 2.1 Method precedence chart
Pre-study Literature
Study Interviews Analysis
Comparing
results with
ICT theory
5
The empirical findings from the pre-study and the interviews were analyzed to find patterns
and compared with theoretical findings.
2.2 Pre-study In order to understand the current situation at Volvo Group Trucks a pre-study was conducted
to study the areas which would be or could be affected by implementing an ICT-platform. The
article from (Orlikowski, 1992) argues that a pre-study has to be performed. If a study is
underestimating the current situation at a company, it may result in an incomplete prerequisite
for an implementation of an ICT-platform.
The current project processes at GTT and GTO were studied which are called DVP and PSM
respectively. The study consisted of reading the manuals for both DVP and PSM, this
included research in the Project Assurance Plan (PAP), Project governance tool (PGT) and
Standard time plan (STP). To collect more information and understand the structure of K4C a
presentation was held by the developers of the platform. A project plan was coded with the
JSON format, which is based on XML, partly to obtain practical knowledge on how an ICT-
platform could be used and also how it can be structured. The project plan was then imported
into the K4C-platform. A simulation was done of the project plan preformed from the CPM
(Chief Project Manager) perspective. First, the project plan was implemented and the right
expertise (engineers, reviewers and Project Managers (PM)) was dedicated to each activity in
the project plan. The project plan was then sent out to a virtual PM who appointed resources
to each activity; the resources had to have the right expertise to be appointed to the activity.
2.3 Literature study A literature study was conducted in two phases, in the pre-study and while performing the
analysis. The first of the two can be read in chapter 2.2. The later was made to get up to date
knowledge of the subject investigated and to help with the analysis of the data collected.
6
2.4 Interviews The interviews were conducted through semi-structured interviews. In most cases the
interviews were audio recorded and after each interview the recordings were transcribed.
Semi-structured interviews were chosen over structured interviews, this was made in order to
get more subjective answers and in turn get more information on what the interviewee thought
was important in the surrounding areas of the questions (Bryman & Bell, 2003). A structured
interview was not chosen because it aims only to answer the question asked and the
interviewee is not allowed to talk about other concerns (Bryman & Bell, 2003). This resulted
in two problems. First, the interviews were conducted to get a general understanding of how
project work is carried out at different positions at GTO and GTT, including problems that
concern the interviewees in their daily work. Secondly, when the interviews were constructed
the interviewers did not have enough experience to construct aimed questions. It could be
argued that the last interviews were more tilted towards structured interviews than they were
in the beginning. An explanation of why it was structured like this can be found later in this
chapter.
After the recordings had been transcribed they were deleted according to the agreement set by
the interviewers and the interviewees. A total of eleven persons were interviewed at ten
different occasions. The interviewees’ positions, occupancy and organization can be seen in
Table 2.1.
Table 2.1 Interviewees
Nr. Occupancy Position Organization
1 Quality assurance PM GTT
2 Project PM GTO PM GTO
3 Project PM PM GTO
3 Project Portfolio Coordination Engineer GTO
4 Cross-Functional Coordinator
(Commodity, Product) PM GTT
5 Project (Commodity) PM PM GTT
6 STP – Time Planning PM GTT
7 Tooling PM GTO
8 Intro Engineer PM GTO
9 Technical Designer Engineer GTT
10 Technical Preparation Engineer GTO
11 PTM CPM GTT
7
In Figure 2.3 an organization chart visualizes which departments that were interviewed (red
boxes), the red line is the communication channeled between GTT-chassis and GTO. A more
elaborated chart can be found in Appendix B.
Figure 2.3 Visualization of the interviewed departments
The communication between GTT-design and GTO and the internal communication studied
can be seen in Figure 2.4 below. The red marked communications are external
communications from GTO, The blue and black lines are internal communications that were
documented. The non-filled boxes are departments that have not been interviewed, which
makes the communication path only verified by one partner.
Figure 2.4 Internal communication at GTO including external communication
The interview questions were adapted to the specific occupation and position of the
interviewee. In appendix D the general questions can be found. These were different for
interview sessions six and ten. This was due to the information gathered consisted of
background information and deeper knowledge of how the Standard Time Plans (STP) were
used and how a new Project Time Management (PTM) program worked. After each interview
a walkthrough of the questions were performed to estimate how well they worked, which in
8
some cases lead to minor changes. The alterations mostly consisted of collecting more
information about a specific subject or clarifying the questions. As stated earlier, these
questions could be seen as structured, still the interviews were conducted in a semi-
constructed manner.
2.5 Analysis When all interviews had been conducted two areas were separated: general project work and
improvement areas. General project work is presented in chapter 4.1 and 4.2 in the Empirical
Findings chapter improvement areas can be viewed in chapter 4.3. The general project work is
a combination of the pre-study and information collected in the interviews and answers of
RQ1 and RQ2.
Improvement areas were found through the interviews where problems or concerns was
brought up by interviewees and then put into an excel sheet. Each improvement area was
labeled into five categories and merged into a second excel sheet, see Appendix A. The
categories were: Communication, Documentation, Knowledge, Resources and Gates. In the
chapter 4.3 Improvement Areas in Empirical Findings, improvement areas that resembled
each other or were identical were merged into one single problem. In the analysis the root
causes are investigated with help of the theory found in the literature study. At last, the
improvement areas validated by theory were compared with the advantages of an ICT-
platform, see Figure 2.5. This was done to find out if an ICT-solution was applicable to the
improvement area, which also answers RQ3. In the discussion chapter, comparisons between
applicable ICT-solutions and the prerequisites for an ICT-platform are discussed.
2.6 Repeatability The empirical data collection was performed with interviews and literature studies on the
current state at Volvo. Two concerns are brought up on the repeatability of this thesis results.
Firstly, the system is dynamic, changes are made in the organization and work procedures
may change, which have an effect on the result if the study is to be repeated. Secondly, the
people that were interviewed could have been affected by the interviewers like tone of voice
or follow-up questions. If then another person would have interviewed them the answers
could look different.
2.7 Validation The empirical findings was gathered with scientific methods and then validated with theory
found in the literature study.
Results Analysis ICT
Theory
ompare
ompareup
port
Figure 2.5 Comparing results with the theory of ICT
9
3. THEORY
The theory chapter addresses the necessary theoretical framework to answer the research
questions.
The theory found consists of (in order as they are represented); the interface between product
and production, information about general projects, project management and the affecting
management issues surrounding the improvement areas, the advantages and disadvantages of
having an ICT-platform. The chapter ends with a theoretical chapter about change
management. The project and management theory is from the book (PMI, 2013) which the
DVP is based on.
3.1 Product development and production interface A common characteristic for companies that have product development and production is the
de-coupling of the two areas, which is done to minimize certain risks but may lead to
integration issues. Earlier research has shown that cultural, geographic and organizational
barriers have an impact on the interface between product development and production. This
tends to make projects miss the target time plan where production start-up is pushed forward
in time with other resulting problems i.e. rework of the design. Results from earlier research
show that by improving the formalization, the understanding between product development
and production will gain a smoother production start-up. Formalization may be both
organizational i.e. having clear goals and giving roles and responsibilities to the right person,
as well as having a standardized way of working and the use of formal documents.
(Vandelvelde, 2003)
3.2 Project The fundamentals of having a project model is to acquire a structured and organized work
flow and by this capture important areas, variables and key functions that otherwise would
have been overlooked. Each project, if finished, results with a unique product or service. A
standardized project model will help achieve higher efficiency with work methods that are
developed to be more effective and still support the flexibility to achieve a unique product.
The flexibility of a project decreases over time where risks and uncertainty are high in the
beginning of the project phase but will later decrease. This correlates with the cost of change,
which increases with the total project time and thus the flexibility. This is illustrated in Figure
3.1. (PMI, 2013)
10
Figure 3.1 How uncertainty correlates with cost of changes (PMI, 2013)
A project can be standardized and efficient but it is also important to standardize how the
handling of project results and how communication with other projects and organizations are
managed. Lack of documentation and communication will result in important parts will
misplaced. It is up to the manager to lead the project to success. The different parts described
in the next chapter will highlight what makes a good project and how it should be managed
(PMI, 2013).
3.2.1 Project Management
Project management is seen as several areas that affect the project, see Figure 3.2 (Rosenau &
Githens, 2005). When a project is failing it is usually because one or several of these areas is
not fully covered.
Figure 3.2 Fundamental areas in project management
(Rosenau, Githens, 2005)
11
(Rosenau & Githens, 2005) mentions three common problems that occur when working in
projects:
Most product failure is at the interface of subsystems, and individual contributors
typically do not pay attention to interfaces until after they have completed most of
their work on their assigned piece of the system.
Time and again, the biggest complaint of people in projects is poor communication.
Senior managers expect project managers to manage projects as if they were a
business, taking a strategic and holistic perspective on the project.
A successful project can be many things from how well deliverables were met, customer
satisfaction amongst other. But what makes a project successful is how the different areas
were handled and balanced between each other. The paragraphs below will bring up
suggestions on how to handle these areas in order to make the project successful, all areas will
not be fully covered such as risk and procurement. (Rosenau & Githens, 2005)
Scope Management
The amount of work that is needed to complete a project is defined in the scope. This also
includes goals, constraints and limitations of the project. With a clearer goal early in the
planning of the scope, it is easier to foresee each activity and the requirements of the project
(PMI, 2013). When the scope has been defined, the deliverables can be described in detail and
visualized as a work breakdown structure (WBS). The WBS can be made in several different
ways, e.g. a precedence diagram can be used to see all deliverables in a logical order or a
hierarchical diagram where activities are portrayed in a top-down approach. A general work
breakdown structure with a top-down approach consists of four levels where the highest level
is the project itself and then is broken down into deliverables of major components. The third
level is more detailed and consists of sub-deliverables and the fourth and last are specific
activities or work packages that needs to be performed, see Figure 3.3.
Figure 3.3 Work breakdown structure (WBS)
12
Communication
Communication is often subjective and a complex process. When working in a project it is
important that the messenger is as objective and neutral as possible, that the receiver can
translate what has been said without the sender’s or receiver’s personal thoughts affecting the
message. (Ying & Pheng, 2014)
When a message is sent, the sender encodes the message and sends it over a medium, the
message will be affected by noise. The noise can corrupt the message and alter its purpose.
Another factor that can affect the message is when the receiver tries to decode the message.
The messages meaning can affect the translation for the receiver, this communication is called
one-way communication and is illustrated in Figure 3.4. (Ying & Pheng, 2014)
Figure 3.4 One-way communication (Ying & Pheng, 2014)
In two-way communication there is a higher chance that the receiver understands the
message. The communication is viewed as a process where sender and receiver are
exchanging information where both are active and receive feedback from each other during
the communication period. The feedback acknowledges that the receiver has understood the
message by communicating back to the sender. The process can be viewed in the Figure 3.5.
In an organization the communication is often restricted to certain formats by the manager,
this has a tendency to form how communication is sent and received. These formats of
communication are debated, they do not take in aspect of how well the sender can distribute
the message. (Ying & Pheng, 2014)
Figure 3.5 Two-way communication (Ying & Pheng, 2014)
13
For an organization to work properly it must be transparent for all stakeholders in the
organization. If this is not the case, different parties will find their own communication
channels, which will make it hard for the organization to effectively monitor the information
flow. Organizations do not generally have a platform for which different stakeholders can
communicate and this makes it even harder for stakeholders with different interest to
collaborate. The effect of this is that the organization will lose control of what information is
sent. Without understanding the information sent through the organization it is hard to control
what is being sent and in turn how this is interpreted. (Ying & Pheng, 2014)
When a project lacks of poor communication it could be for several reasons. As has been
mentioned before, modern technique with people trying to communicate with computers can
be problematic if the message is interpreted differently than what it was intended. Eye-to-eye
contact usually facilitates this issue. Another example may be that people are unwilling to
share their information and sees it as a source of power. It could also depend on people not
knowing the structures within the project or cross-functional problems where technical
language is not perceived properly in other departments. (Pinto, 2007)
Information and Knowledge management
When handling information in projects it could either be structured data or unstructured data.
If the data is structured it can be stored in rows and columns and if it is unstructured it could
be different files like pdf’s or emails. When data is unstructured it cannot be stored in a
database in the same manner as structured data can, which leads to difficulties when trying to
retrieve it due to the complexity of identifying the data itself. Project management data is
usually unstructured and saved on a network based platform. (Eds. Somasundaram &
Shrivastava, 2009)
To make this data easy to find there should be standardized guidelines and work instructions
on how to store this on the platform. During a project, the ability to update documents is a key
feature that will facilitate the work. When a document is updated, a notification system should
be implemented so that all the stakeholders know an update has been made. (PMI, 2013)
The maturity level of the project management shows how standardized and structured a
company is when working in projects. Higher level gives a higher degree of standardization.
This could be used as a measurement for companies that want to benchmark its level of
standardization. (Pinto, 2007)
Knowledge management is a factor in global companies to execute successful projects.
Knowledge could be described as data that has been processed by people with experience and
is useful for others in a company. To make use of the acquired knowledge in later projects, a
knowledge database should be established, known as lessons learned log. Knowledge is
usually divided into explicit knowledge, which is formal knowledge of different subjects.
Tacit knowledge on the other hand is knowledge combined with experience and hard to
transfer between people. According to earlier research, knowledge management can be
described as the four processes seen in Table 3.1. A company that has several projects in its
organization triggers different mechanisms depending on what the project incorporates. The
mechanisms can be facilitated with different technologies as can be seen from Table 3.1.
(Becerra-Fernandez, 2006)
14
Table 3.1 Four processes in knowledge management (Becerra-Fernandez, 2006)
Processes Examples of Mechanisms Examples of Technology
Discover new knowledge -Meetings
-Collaborative creation of
documents.
-Video-conferencing
-Databases
Capture existing knowledge -Prototypes
-Learning by doing.
-Lessons learned log database
-Computer-based
communication
Share knowledge with others -Presentations
-Manuals.
-Expertise locator system
-Web-based access to data
Apply knowledge -Hierarchical relationship
in organizations
-Support centers.
-Resource planning system
-Decision support system
In a cross-functional global company, ICT is competent to share knowledge and information
as long as it is easily accessed and updated regularly. This will be further elaborated in
chapter 3.3. (Coakes, 2006)
Resources
Resource management includes how the project team is managed. People with varied
expertise are assigned roles, authorities, responsibilities and competences and the amount of
time one set off to the project. Resources can be replaced while the project is in progress at
any time, but it is beneficial to have the same team as early and as long as possible during
project execution. When a project team is put together, there needs to be team members with
different background. It is also beneficial to have a project leader that has a certain amount of
experience from earlier projects.
There are different tools available when managing the resources. When planning a project a
hierarchical-type chart could be used. This shows the organization in a structure chart, which
gives a holistic view of the teams and the relationships in between. Each box with several
project members could be seen as a group. When a Work Breakdown Structure (WBS) has
been made to show the project deliverables, an Organizational Breakdown Structure (OBS)
could be made as seen in Figure 3.6. This is used to show the deliverables each department
and teams are responsible for. Then there is a Resource Breakdown Structure (RBS) which is
a hierarchical list of resources including a detailed description of each resource. This can be
connected with the WBS and facilitate planning, monitoring and managing costs. Another
type of chart is the Responsibility Assignment Matrix (RAM). This takes all the activities into
account and connects them to each resource in a matrix based chart. (PMI, 2013)
15
Figure 3.6 Organizational Breakdown Structure (OBS) in a project
Due to people having different chemistry among each other, conflicts are inevitable. How
successful a project manager is when managing the project often depends on their ability to
resolve conflicts. There are five different techniques for resolving conflicts that project
managers or project members could use (PMI, 2013):
Avoid
Accommodate
Reconcile
Force
Collaborate
The conflict may be resolved with the techniques but the core problem may still persist. If
there are personnel problems that cannot be solved with the techniques, the project manager
preferably needs to have argumentation convince top management that some of the personnel
need to be replaced. (Pinto, 2007)
3.2.2 Stage-Gate
Around the late 1980s and the early 1990s a new concept was needed to handle the new
paradigm shift for the commercial product development. Before the 1990s there was no need
of fast development of products, but in the 1990s this changed. The market demanded higher
customization and more variations of products. One model that emerged was the Stage-Gate
model (Cooper, 1990). The Stage-Gate model has different stages were specific activities are
being carried out by all stakeholders, after each stage there is a gate. The purpose of the gates
is to check that all deliverables have been completed and that the project can proceed into a
new development stage, see Figure 3.7. The idea is to include resources in the beginning of
the project to minimize the increased cost of a fundamental change later in the project
(Anderson, 1993). In the earlier phases managers review the progress of the project and at
each gate grant more funds to the project if the criteria’s are fulfilled.
16
One successful adaptation of the Stage-Gate method was done by the companies Corning
Glass and Nortel Networks. Corning Glass had a difficult time during the IT-crash in the
1990s, they did not have continuous product development and had lived on one innovation at
a time. They adapted the Stage-Gate model on top of how they successfully developed
products earlier. The different stages Corning Glass brought forward can be seen in Table 3.2
(Stage-Gate product development, 2012)
Table 3.2 Description of the different stages in the Stage-Gate model
Stage Process
0 Discovery of new opportunities including the development of product ideas by the
project management team.
1
Scoping through a basic evaluation and assessment of the marketability of a new
product idea. Product ideas are assessed based on known competition and the
product's competitive advantage.
2
Developing a business case based on careful research that details why a product
will succeed. During this stage the product is defined, milestones are established
and each department assesses the product's feasibility.
3 Development focuses on the product design and the development of prototypes.
4
Testing and validation, both in house and in the field with consumers. Trial sales
efforts are conducted to measure both the product's functional and market
performance.
5 Product launch.
The Stage-Gate model has since been further developed and implemented in different
companies e.g. Volvo Group Trucks with their product development process, DVP. How
many gates there are and what type of stages depend on the company’s development process
(Anderson, 1993). By adopting the Stage-Gate model, companies aim at lower development
cost and to get products faster on the market (Anderson, 1993).
Through the years the Stage-Gate model have been modified to help overcome some of the
criticism that has been directed towards it. (Grönlund, et al., 2010) states them as following:
Stage 4 Gate Stage 3 Stage 2 Stage 1 Gate Gate
Figur 3.7 Stage-Gate model
17
Time-consuming, resulting in timewasting activities
Bureaucratic procedures
No provision for focus
Restriction of learning opportunities
The four presented issues could occur in a Stage-Gate model.
3.3 ICT/Collaboration network ICT stands for information communication technology and is a concept on how information
and communication management can be facilitated.
Different concepts are used to achieve more efficient development projects, such as
restructure of the organizations, project models and management tools. The idea with ICT is
that it tries to merge the different concepts. It can be a management tool but also a platform
for other means such as communication and data sharing, for example extend collaboration
between countries and organizations for educational purposes (Khakhar, et al., 2007).
This chapter will highlight the ICT concept adapted for manufacturing companies where great
advantages can be made with a well-functioning ICT-solution. The concept of ICT and what it
tries to accomplish reflects what internet has to offer; collaboration and flexibility with shared
resources (people and data) and openness.
One aspect that differentiates the two areas is the view on communication. Internet is based
on horizontal communication, which means that there is no hierarchical structure, meanwhile
ICT solutions have a tendency to use both horizontal and hierarchical communication (Duque,
et al., 2007).
Manufacturing companies are expecting that they need to develop technologies such as ICT-
platforms in the upcoming future to help them stay competitive on the market. (Marco,
Montorio, 2007)
(Camarinha-Matos, Afsarmanesh, Ollus, 2008) addresses what manufacturing companies can
gain from an ICT-solution with a collaborative network. Customers in the list below can be
interpreted as different stakeholders at different departments in a project:
Business partners can quickly and easily get together to benefit from a business
opportunity, fulfill the need and then disclose the collaboration.
Increasing applications in early stages of product life cycle, speeding up and giving
more efficiency to engineering and design.
Increased customer collaboration and logistics enhance market understanding and
reduce delivery times and times to market.
Customer collaboration in after delivery networks enables new form of support
activities over the life-cycle of the delivered product or service.
Efficiency relies on capability for companies to co-operate despite different
infrastructures, business cultures, organizational forms, and languages, legal or fiscal
systems.
Business networks themselves continuously change.
18
To accomplish the effects mentioned above there are several criterias that need to be met to
build a firm base which an ICT-solution can stand on. Much of the research in ICT has
surrounded areas with ad-hoc solutions, meanwhile the understanding of collaborative
research has been missed. The collaboration is often surrounded by architectural flaws in most
systems, where several different tools or software are used, several different communication
channels and differences between organizations, makes it hard to implement an ICT-platform.
To effectively establish a base for an ICT-platform, the different infrastructure needs to be
customized to fit into a coherent platform. This customization requires highly skilled
engineers who have knowledge in applications. (Camarinha-Matos, Afsarmanesh, Ollus,
2008)
(Rabelo, 2008) states the following three preconditions have to be set to be able to implement
an ICT-platform.
1. Requires collaboration among involved partners that does not only involve sending e-
mail messages.
2. The existence of trust, considering that partners shall rely on each other (at all levels).
3. All (or most) of the activities carried out within a collaborative network organization
should be made via computer networks, i.e. digital transactions should be the routine,
and not an exception.
(Rabelo, 2008) also states that organizations need to be transparent and adaptive to facilitate
the implementation of a communication and information channel in the current state of the
organization. By having all of the mentioned requirements, people using the ICT-platform
will see it as a must have and not as an optional tool. To complement the technology of the
ICT-platform, the platform requires powerful computer power and high internal and external
security.
In chapter 3.2.1 four processes were mentioned and to have the most efficient use of
knowledge in a company, all four of these processes should be managed efficiently. An ICT-
platform would greatly facilitate knowledge management in a company. If the platform has
embraced all four of the processes it will be a more standardized way of working. Explicit
knowledge can be managed with structured databases, and tacit knowledge can be managed
by socialization like meetings and video conferencing. Although a platform that manages tacit
knowledge is hard to implement due to the difficulties of documenting experience. (Becerra-
Fernandez, 2006)
When a company has implemented an ICT-platform there are both positive and negative sides
when it comes to conflict management. A case study (Correia, 2008) has shown that an ICT-
platform facilitated conflict management by having an effective and formal way of
communicating. On the other hand the ICT could also aggravate conflict due to different
personalities of the communication participants, where misinterpretations could occur.
3.4 Change Management If a new work method or technology is implemented in a company, people are the primary
factor in either success or failure in achieving the change. If people are positive to the change
it is easier to implement, but if they do not support the change, it could be due to several
causes.
19
(Suran, 2015) mentions three important factors on how to implement change successfully.
First the company needs to have a clearly defined strategy of why a change is necessary and
that it is understood by all departments and teams. If the strategy is not communicated well
people tend to fear the unknown of what consequence the changes may bring for themselves.
Another factor mentioned is to have an effective organizational structure. If a company has its
organization divided into teams, competitive attitude may grow between them which may
prevent sharing information. The third and last factor mentioned is to have effective processes
and communication processes. This leads to trust among the employees towards the
management because the process assures a consideration of their ideas for different changes.
If a company has met the three factors, the next mission is to get employees to accept the
change. Convincing employees may be hard, but if the right information is communicated in a
way that benefits the company and workers are inspired, the change will be easier to
implement. It is also important to listen to the employees and let them test the new changes in
a real situation and then let them make suggestions on how the change can be more effective
in their daily work. Furthermore it is important that top management shows a specific way of
how the change will be implemented that everyone understands. Factors to successfully
implement change and how to achieve employee acceptance of change, is summarized in the
lists below. (Suran, 2015)
Factors to successfully implement change
1. Clearly defined and communicated strategies.
2. Effective organizational structure.
3. Effective processes, including communication processes.
How to achieve employee acceptance of change
1. Convince employees of the need for change.
2. Listen to employee concerns and needs.
3. Involve employees in the development of the change.
4. Communicate the implementation plan.
20
4. EMPIRICAL FINDINGS
As explained in the method chapter the results will be divided into two groups. The first part
presents the current state at Volvo and the tools used can be found in Appendix C. This
includes how people communicate in projects and a generalized summary of how a product
development project would be carried out at Volvo Group Trucks. The second part of this
chapter consists of improvement areas which are divided into five parts; Communication,
Documentation, Knowledge, Resources and Gates.
4.1 Current Process and Tools at Volvo There is a range of different project types at Volvo besides the product development projects.
Generally a large product development project is called Start cost project.
Start cost projects has four different scales A, B, C and D. Scale A has the longest lead time
and scale C has the shortest. Scale D is called Intro-block. The purpose of an Intro-block is to
bundle and prepare the production for the implementation of new product changes. The
product changes are implemented at specific dates and follow a specific time plan. The major
difference between a Start cost project and an Intro-block project is that the former is used
when developing a whole vehicle or powertrain and the latter is used when bundling a set of
product modification requests. Product Modification Request (PMR) is a project which is
issued by customer request; they are smaller than Start cost projects and are implemented in
the Intro-blocks.
The creation of a Start cost project can have several different triggers. It can either be based
upon customer demand or legislations. A reoccurring phenomenon while forming the project
is that it starts off with a requirement and during the process, new issues occur. New
technology is needed to be able to meet the requirements. Over time more problems are
detected which expands the scope of the project.
There are two kinds of quality notification and assembly systems that handle issues, called
System A and System B, see Appendix C. In general they are not regarded as projects but if
the issues affect the production or product at large they can initiate a project.
4.1.1 DVP
DVP (Develop Product and Aftermarket Product Portfolio) is the project model GTT follows.
This originates from the Stage-Gate model and is adapted for Volvo Group Trucks’s product development. Before the DVP, an older process was used called the GDP (Global
Development Process). Only recently started projects use DVP as a model, while older active
projects still uses the GDP. The DVP comes with a handbook that describes principles that the
management should follow like, quality assurance, cross-functional teams, how to plan the
project and prove the project is feasibility amongst other. The handbook also addresses all
aspects of a product development project like, starting a project, organization, planning, risk
management, decision making etc. The DVP is in close correlation with PGT, PAP and the
Standard Time Plan. A more detailed description of the three will be brought further down.
The amount of gates and stages depends on the particular project, how large it is and what it
21
Figure 4.1 Gate process
contains. A new initiative has been developed to increase resources in earlier stages of the
project. This initiative is called RnD30.
4.1.2 PAP and PGT
Project Assurance Plan (PAP) is a tool in projects that help state and review deliverables for
the gates, plan the next gate and view the project description to see if it meets the QDCF
principles (Quality, Delivery, Cost and Feature). The gate "process" is visualized in Figure
4.1. The deliverables are predefined at each gate in a template by the CPM and PMs, and the
amount deliverables varies with the different sizes of projects. The PAP also includes
documentation of project definition, project time plans and white books.
The Project Governance Tool (PGT) is a web based software connected to PAP and aids the
Steering committee (SC) in taking decision of opening gates or not. It also works like a gate
auditor to view the status of the project and project team where monitoring the progress and
information of what the next deliverable or agenda consists of. Only certain persons have
access to the projects PGT, this access is given by the CPM of the project.
4.1.3 PSM
The Project Steering Model (PSM) is a general project model, which is used for
industrialization changes in process and business projects carried out at Volvo Group Trucks
Operations. The model consists of a couple of different principles for example roles and
responsibility, documents and governance. Another important principle is the PSM Flow,
which is a flow chart showing phases and gates in a project. This helps the project team to
focus on a certain activity and assisting the steering committee to make important decisions at
a certain time. The earlier project process, GDP, had been successfully aligned with the PSM
process. When asked about the issue during the interviews, an example of how the GDP and
PSM could be aligned was showed. This has not been performed for the DVP, where the
explanation is that the DVP model is too new and not enough experience to construct an
alignment model.
22
4.1.4 Time Plans
What time plan to use depends on the grade of the Start cost project: A, B, C or D.
Start cost projects have one main time plan where all stakeholders are included. The time plan
is a template that gives all stakeholders a visualization of the whole project in form of a Gantt
chart. Start and end dates, gates, critical activities and stakeholders are highlighted in the
Gantt chart.
GTT has 4 levels of time plans and different responsibility areas as can be seen in Table 4.1.
Table 4.1 Time plan levels
Level Area Responsibility
1 Main Time Plan CPM
2 Commodity time plan PM
3 System/Module time plan Sub-PM
4 Component/Part time plan Team Leader
GTO does not follow the same levels of time plans as GTT, instead their PM creates a level 2
time plan to suit the main time plan (see chapter 4.1.3). The level 2 time plan is adapted to fit
both the DVP process and the PSM process. The different departments at GTO may construct
more levels of time plans but are not directly connected to the different levels of the main
time plan.
To create time plans, different tools are used depending on personal preferences. CPMs can
require PMs to use a specific scheduling tool for their level two and three time plan. Either
Microsoft Project or Excel is used. A new tool has been developed for handling standard time
plans and is called PTM (Project Time Management). This is an ICT-tool where each time
plan is linked, and when one is updated the other ones get notified. The one responsible for
the time plan can accept or decline the update. It is also supposed to help people in projects
that are not CPM or PM to have access to a web based visualization of the time plans and
their status.
4.1.5 Communication and Documentation
The communication at both GTO and GTT are performed through PGT, e-mail, Microsoft
Share Point, Lync, meetings and by phone. PGT is used in direct correlation with deliverables
and gates, where templates are stored at each activity that has to be done before certain dates.
E-mails are regularly sent for different reasons, often with unstructured data, where it can
vary from new emerging problems to sending new documents. Microsoft Share Point is the
main platform to store all the important project documents like project description, time plans
and organization charts. Lync is used both in online meetings and to send messages to
concerned people. How people interact and what tools people prefer to use for communicating
are up to each person or group. Closed projects and their descriptions, including white books
are saved in a database called System C, see Appendix C. Product changes are sent through
23
System F and affected production changes is sent through System E, see Appendix C. The
data is of structured nature in both systems.
At GTT Chassis, there is an ad-hoc manual for how to work in different roles and what
knowledge is needed for a role, but it has not been updated for years.
4.2 A General Concept of Project Work in a Start Cost Project This paragraph will highlight certain parts of a Start cost project. The whole organization or
all information in such project is not presented. What includes is the information about project
work gathered from the interviewees. Each of the interviewees has different tasks and method
while working. This concept has merged all interviews to try to visualize how the different
interviewees are connected. Figure 4.2 gives a general illustration of how the different
information and communication flows between GTT and GTO are connected.
Figure 4.2 Information and communication flows between GTT and GTO
Product planning generates a Start cost project based on customer demand. Product planning
then sends out prerequisites of the product to the CPM. The CPM then gathers PMs on the
different departments that are affected by the project and a concept is developed to meet the
specifications of the product. Each department then creates a business case, to calculate the
cost and then sends it to the finance department. If the product change is financially viable the
request is accepted.
24
The business case results in demands from the stakeholders e.g. production (GTO) and
aftermarket. The demands are distributed via PGT and are discussed through meetings. The
demands defines the product's shape and attributes, this is necessary for different reasons and
depends on who the demands originate from. It could be GTO who wants the product to be
easy to assemble, it is then up to the GTO PM to collect information from relevant actors
within GTO and bring it to the CPM of the Start cost project. Each factory does not have the
same production requirement which leads to different demands. This is where intro engineers’ helps with the merging of the demands to fit a common tool and production system.
The CPM structures the standard time plan to fit this particular project and in turn sends the
time plan to affected PMs, who then create a level 2 time plan. The time plans are discussed at
meetings, in some cases a physical time plan is saved on a whiteboard. In the earlier stages of
the project all PM’s meet every two weeks to discuss deliverables and how the project is
going compared to the standard time plan. It is up to the individual PMs to choose what the
time plan is based on and what tools they use, for example Microsoft Project or Excel. At
GTO, PSM has to be adapted to fit the gates with the product project.
The product matures during the development loops, which have been added in the DVP to
increase time and resources in the earlier phases of the project. There are a total of eight
development loops, where each loop begins with the same prerequisites and demands as the
previous ended with. Development loops help departments to have similar understanding of
the product and ensures that they all are on the same level of knowledge in the product
specification. The different departments are generally in different stages in their own
development process, where development loops help their own development to be more
aligned with the standard time plan.
When a loop is completed the product is “frozen” and no more changes are allowed until the
next loop. Designer and technical preparation has to have a meeting if a change is made to a
product. If a change is made it will be noted by changing the article number of the product in
System F. Intro engineers then implement the changes into the master structure System E.
They are sent to the factories through target structure System E which they in turn alter to fit
into their production system. All factories have an Industrial Launch Group (ILG) which
through meetings verifies that all activities have been performed in all local departments and
suppliers.
The first gate the project needs to pass is the feasibility gate, during the feasibility and concept
phase the product is developed during the previous named development loops. After the
concept gate it is no longer allowed to change the products specifications. GTO gradually gets
more involved the further the project proceeds, primarily based on the maturity level of the
product. Technical preparation is the main actor from GTO in the earlier loops, intro
engineering takes on a larger role after the concept gate and tooling and equipment gets more
involved when a production change is under development. The sooner information about the
product reaches GTO-regional and local, the earlier they can plan and change the production,
for example contact suppliers for tools and equipment, give assembly instruction that the
factories can implement into their production.
GTO gathers information from the project in two ways. Firstly, communication between
designers and technical preparation consists of updates on the design and information
surrounding the demands from GTO, the information is not new but more detail and specific.
25
Secondly, technical preparation distribute information to tooling and intro engineering on
which updates are ongoing and they also take notes from mentioned departments on how the
production will be affected by the changes.
New vital information is gathered by the GTO PM who shares it with GTO local and regional
departments via Microsoft share point. This is done regularly each week with included
meetings. A Start cost project does not always affect the whole production. In the beginning
of the project it is usually small, but grows larger over time with new information, and due to
this it can go from a line organization problem to a project at GTO-regional.
The Final Industrialization Gate (FIG) is an important gate; it verifies all aspect of the
production instruction, assembly sequences, lead times etc. The verification of the product has
been performed at Final Development Gate (FDG) and is GTT’s responsibility. The
verification is primarily done at the Pilot Plant (PP), where the product's manufacturability is
tested. Simulations of the assembly sequence are also done but only around 80% of all
variations can be verified, this is primarily because of the large amount of variants. When the
project has gone through the Release Gate (RG) the series production can start and the
responsibility of the product is handed over to GTO-local with support from intro engineering
if needed.
4.3 Improvement areas The improvement areas are concerns mentioned at the interviews, see Appendix A. Under
each part a summary of the reoccurring improvement areas that were mentioned and the
highlighted words in the chapters is the subject of each paragraph.
4.3.1 Communication
There is no group management to secure that all e-mails are sent to the right people. When
PM or CPM sends out important emails to all stakeholders there are usually a lot of e-mail
addresses to handle manually. This could sometimes lead to emails not getting to the
concerned persons who then can miss important information, meetings, etc. (see Appendix A,
C1.1, C1.2, C1.3)
The project management can sometimes be time consuming when the project grows and
changes line organization or when several projects are merged. The communication between
all stakeholders is crucial for the different departments so that delays can be minimized. (see
Appendix A, C2.1, C2.2)
When it comes to the communication between GTO and GTT it is important that information
between product development and production is transparent. This is not always the case
which may lead to time plans getting out of sync between departments and projects might be
delayed. Also when departments are isolated due to holding information within its walls, time
consuming activities appears and may cause frustration and less value adding work time.
When concepts are changed late it is important that all stake holders get the information fast,
otherwise project costs may increase due to expensive long lead time tool development. At the
moment there is only one person that tries to extract information from the product
26
development to maintain a fast response to changes. (see Appendix A, C3.1, C3.2, C3.3, C3.4,
C3.5, C3.6, C3.7, C3.8, C3.9, C3.10)
The performance of the project has a lot of factors, where one could be people chemistry and
how the interaction between persons may be carried out. (see Appendix A, C4.1, C4.2, C4.3)
4.3.2 Documentation
There are several inconsistencies when handling project files like storing data, updating data
and where to find manuals (see Appendix A, D1.1, D1.2, D1.3, D1.4, D1.5, D1.6, D1.7). This
could lead to confusion and time consuming activities due to people having to search for the
right documents for their project. Although some CPM’s set rules in the beginning of a project to get more consistency (see Appendix A, D1.8). There are also problem with the
structure of the project files, how the files are stored and their naming convention. There is
also lacking gates alignment between DVP and PSM. (see Appendix A, D2.1, D2.2, D2.3,
D2.4)
Project management is lacking when smaller projects are merged into a larger project, which
takes time and resources, and people at GTO must contact the GTO PM to obtain the latest
information about what product the project includes (see Appendix A, D3.1, D3.2).
It is hard to visualize the project plan and get a holistic view of the whole project (see
Appendix A, D4.1, D4.2). It is important to have all stakeholders understanding the scope of
the project and make it as clear as possible.
Having no transparency is a problem that usually occurs in projects spanning over several
departments. It is especially problematic between the product development at GTT and
production at GTO. When GTO does not participate in the development loops as they should
and GTT does not have an understanding of the production, the departments may suffer from
isolation that causes important information to be locked up. Due to long lead time tools that
need to be ordered in time, an employee from GTO tries to obtain the information that is
needed and thus break the isolation. It is also very hard to interpret the project in the
beginning which makes it hard to start working with the production of the product (see
Appendix A, D5.1, D5.2, D5.3, D5.4, D5.5).
There are no guidelines for a PM as to which tools to use, which makes the time plans in
projects, end up in a lot of different formats. Moreover when files are in different formats it
takes time to convert them into a convenient format which any program can use (see
Appendix A, D6.1, D6.2).
When project members are replaced a lot of project experience may be lost, but it also makes
it hard, if not impossible, to document experience. Intro engineers have a lot of correlated
projects and they have to search for the connected impacts when a certain product change has
been made. If a key project member is replaced it will cause problems due to the lost
experience (see Appendix A, D7.1, D7.2).
When working in projects there are some administrative activities that are waste of time due
to tedious way of working (see Appendix A, D8.1). Other time related issues are the Intro
blocks. These are for the most parts movable if a problem occur, but there are some
exceptions that are not moveable due to i.e. legal requirements like safety issues (see
Appendix A, D8.2, D8.3).
27
There are ways to measure project quality and it is not that comprehensive, which means that
the cost of the project is discarded, hence priority amongst the projects cannot be obtained.
The ILG is responsible to verify and assure that all activities in a project have been
performed and saves a status file at the Microsoft Share Point storage (see Appendix A, D9.1,
D9.2).
4.3.3 Knowledge
An important factor when introducing new work methods is to educate people of why the
change is necessary. If the information about the change has not been communicated as well
as it should, people tend to fall back on the old and practiced way of working or use of tools.
(see Appendix A, E1.1, E1.2, E1.3)
When it comes to the awareness of new project models, some project managers are not aware
of the high workload in the beginning of a project. This leads to a time pressure throughout
the project and may delay deliveries. (see Appendix A, E2.1, E2.2)
There is no clear information on why or how to use project tools like PGT or processes like
DFA or PSM, which makes it hard to follow them. (see Appendix A, E2.3, E2.4, E2.5)
Project managers may choose how the document structure should look like or how to follow
a process which could lead to misunderstandings between stakeholders. (see Appendix A,
E3.1, E3.2, E3.3, E3.4)
4.3.4 Resources
The project group members are usually dismantled after a project is finished. Reusing
resources from a project that has worked well would facilitate the next project. When
working with new project models it can be difficult to estimate the time it takes for each
deliverable before each gate which leads to delayed projects. Searching for resources is
usually time consuming and hard to find new resources when a team member has left a
project. Solving a problem can be done faster if the right expertise is found as fast as possible.
(see Appendix A, R1.1, R1.2, R1.3, R1.4, R1.5, R1.6)
Due to the amount of people in projects that span over several departments, the CPM or Intro
engineer could miss contacting all the stakeholders within the project group. The organization
charts are made in a PowerPoint-file and has no connection to the e-mail client which is one
potential improvement area. (see Appendix A, R2.1, R2.2, R2.3)
When it comes to different roles in a project the people chemistry is usually a performance
factor that is hard to estimate before a project start. (see Appendix A, R3.1, R3.2)
It is also hard to get a holistic view of the project and all its stakeholders and when a project
is late everyone needs to be informed. (see Appendix A, R4.1, R4.2)
28
4.3.5 Gates
Gates are an important part of project work. Since each project looks different from the other,
the PM needs to have an opportunity to merge gates or adapt project plans when late product
changes have been made. The cross-functionality in a project is important when different
departments need to adapt gates with their process so that delays are easier to handle. (see
Appendix A, G1.1, G1.2, G1.3, G1.4, G1.5)
29
5. ANALYSIS
This chapter includes an analysis to find differences between the theory chapter and the
results chapter. A summary is presented in each improvement chapter in a form of a table. An
analysis of the improvement areas and the correlating ICT advantages will also be brought up.
The project management and the different processes used currently at Volvo Group Trucks
are a reflection of the presented theory; much of the theory is based upon the book (PMI,
2013), which in turn is regulated by the ANSI standard ANSI/PMI 08-001-2012. The DVP
follows the Stage-Gate principle, though using their own concept of the method, and with
RnD30 it also aims for more resources at early stages. Time plans are used throughout the
organization in projects with the help of WBS and RBS. Inconsistencies concerning different
kinds of communication and data handling has been detected, where there are no structured
process, there are directives on how people should carry out the process but not all PM or
CPM are consistent with following or demanding that they are followed.
Communication As could be seen in the theory chapters there were a lot of different areas that needs to work
to have a successful project. Communication is a complex part of the project work as can be
seen in the theory. This also states that there are virtual communication methods that will
facilitate at global companies. When comparing the theory with the result chapter it can be
seen that there are some improvement areas standing out, like emails getting to the right
people, transparency between departments and people chemistry. The areas and their
correlation to theory are presented in Table 5.1. According to the theory it is important to
have good communication between all the stakeholders when the project scope grows, which
is discussed in the next chapter.
Table 5.1 Communication results validated by theory
Results Theory
E-mails not getting to the right
people.
People not knowing the structure of the project
(Ying & Pheng, 2014)
Transparency leads to essential
information not being communicated
When the organization is not transparent it has
problem with distributing information (Ying &
Pheng, 2014)
People chemistry leads to conflicts. People having different personalities, conflicts are
inevitable. (PMI, 2013)
As can be seen from the ICT chapter in the theory, an ICT may help with the two first issues.
The first can be solved due to the hierarchical communication structure where people may be
able to send e-mails to whole groups. The second could be solved as a result of the
implementation of the ICT, where collaboration will be facilitated (Rabelo, 2008). The third is
ambiguous due to there are both positive and negative sides with an ICT (Correia, 2008).
Documentation When it comes to information storage the theory states that data can be either structured or
unstructured. Most project data is unstructured and hence it is more convenient to be stored on
30
a network based storage platform. This can be confirmed by the results that the data is stored
on Microsoft share point. Although, according to the results there are inconsistencies when
storing data and what tools to use and does not comply with the theory. This states that the
data should have standardized guidelines and work instructions in how to store it.
The theory states that it is important to have a holistic view of the whole project that helps all
stakeholders understanding the scope. This is not the case according to the results, which
shows that it is usually hard to have a visualization of the whole project. Transparency
between departments is also an area that differs. The theory states that it is important for
global companies to have a transparent organization, but the results shows that the production
department may feel isolated due to the product development department not sharing
important information in time.
Furthermore the theory mentions that when people are replaced in projects experience may
disappear and this knowledge can for instance be saved in a lessons learned log. The results
confirm that it can be problematic but also that it is difficult to document experience.
Table 5.2 Documentation results validated by theory
Results Theory
Inconsistencies in naming conventions, file
structure when storing project files and
tools.
To make data easy to find there should be
standardized guidelines and work instructions.
(PMI, 2013)
Visualization of the project plan is hard. It is important that all stakeholders understand
the scope. (Pinto, 2007)
Isolation leads to less transparency
between departments.
Important that global companies are
transparent. (Pinto, 2007)
When people in projects are replaced
experience may be lost.
Important to have a lesson learned log to
document experience. (Becerra-Fernandez,
2006)
The theory states that a standardized document structure is vital for having an effective
project work. ICT may facilitate all four issues but there is some interference that needs to be
solved in advance which will be discussed in the next chapter. (Coakes, 2006) (Camarinha-
Matos, Afsarmanesh, Ollus, 2008) (Rabelo, 2008)
Knowledge Knowledge improvements in most cases revolve around methods not fully being implemented
and enforced. Inexperience in project work and clear initiatives from CPM and PMs makes it
hard for people to structure their work.
Table 5.3 Knowledge results validated by theory
Results Theory
People are not aware of why a work
method change is necessary. Change management (Suran, 2015)
There is no clear information on how to
use project tools.
There should be standardized guidelines and
work instructions. (PMI, 2013)
31
When it comes to knowledge the theory mentions four processes that can be facilitated with
an ICT (Becerra-Fernandez, 2006). The first issue in Table 5.3 is a change management type,
where the next issue is of a kind that could be included into one of the processes.
Resources The theory states that keeping resources throughout the project is beneficial. The result shows
that when someone in the team leaves the project it is hard to find new resources and it takes
time. The theory also states that when managing the resources several tools can be used for
visualization of the organization or having an expertise locator system. PowerPoint is used
according to the results to visualize the organization, but does not have a connection between
the resource and e-mail client. This may lead to excessive work.
Table 5.4 Resources results validated by theory
Results Theory
Project is dismantled after a project is finished
and people can leave in the middle of a project.
Having the same team throughout the
project is beneficial. (PMI, 2013)
When someone leaves the project it is hard to
find new resources.
It would help to have an expertise
locator system (Becerra-Fernandez,
2006).
As could be seen in the theory chapter 3.3, an ICT-solution could facilitate both resource
planning and expertise locator system that could be used to find the right resources (Becerra-
Fernandez, 2006). This will be further discussed in the next chapter.
Gates The empirical findings show that gates are not always followed. They can be moved ahead in
time and some deliverables can be moved to the next gate. There is also an improvement area
connected to fit the different time plans for each department.
Table 5.5 Gates results validated by theory
Results Theory
No alignment of the different time plans
for each department
Time consuming, resulting in unnecessary
activities. (Grönlund, et al., 2010)
Gates are not always followed Bureaucratic procedures. (Grönlund, et al., 2010)
The first improvement area is primarily a result of lack of knowledge, for instance during the
interviews the connection between PSM and DVP could not be found. An ICT-solution helps
this alignment for companies to cooperate despite different organizational forms (Camarinha-
Matos, Afsarmanesh, Ollus, 2008). The second area could not be supported by an ICT,
bureaucratic procedures needs to be standardized to be able to be supported.
32
6. DISCUSSION
The discussion focuses on the improvement areas from the empirical findings and the
supporting theory. The first paragraph discusses the problem defined in the problem definition
and how it is affected by the improvement areas. Second paragraph mentions if an ICT-
function is applicable to the improvement areas. The third paragraph states if an ICT-platform
can be implemented at Volvo Group Trucks. The last paragraphs discusses how an ICT-
platform could be implemented and how the general response could be expressed.
As could be seen from the analysis there are correlations between the current state and the
theory. The theory consists of chapters that highlight how a general project and a product
development project should be managed to successfully develop a product with high quality
and in time. In the analysis several cases are shown that the improvement areas does not
coincide with the standards of a well-functioning project process, as mentioned in the theory.
From the problem definition it is stated that projects at Volvo Group Trucks are delayed and
that they are not following the principles set when working in product development projects.
The authors do not think these improvement areas are solely responsible for the delays in
product development projects, and this thesis cannot answer in what extent the improvement
areas affect projects because of the small research scope. However the authors can assume
from the interviews that they do affect the collaboration between the chassis department at
GTT and GTO when working in such projects. The theory states that ineffective collaboration
makes project ends up being delayed (Vandelvelde, 2003), with this the authors can say that
the improvement areas are delaying product development projects, but as said earlier the
authors cannot say to what extent the improvement areas are affecting a product development
project. The authors also assume that the improvement areas look similar between other GTT
departments and GTO. This assumption is made on the basis from the interviews with GTO
employees.
According to the analysis several areas were found where an ICT-solution could help support
the project work at Volvo. (Becerra-Fernandez, 2006) also gives examples on how ICT-
solutions could facilitate the improvement areas. This leads to ad-hoc solutions, which does
not fully incorporate the complete project infrastructure as mentioned in the theory
(Camarinha-Matos, Afsarmanesh, Ollus, 2008). An organization needs an ICT-platform that
incorporates all aspects of project work.
Table 6.1 Prerequisites not fulfilled
Improvement areas Theory
Easy access to data and regular updates (Coakes, 2006)
Transparency (Rabelo, 2008)
Several different software’s and tools (Camarinha-Matos, Afsarmanesh, Ollus,
2008)
Several and unstructured communication
channels (Camarinha-Matos, Afsarmanesh, Ollus,
2008)
33
The mentioned improvement areas in Table 6.1 are prerequisites that need to be managed in
advance of implementation of a fully functional ICT-platform. The theory states that it can
support some of these areas, i.e. increased collaboration will increase the transparency. The
authors’ thinks that the transparency with for example not knowing who to contact; is an
unstructured transparency and it needs to be structured before an ICT-platform can support it.
Other issues that need to be mentioned are the amount of different software tools used. By
having that amount of tools it is difficult to construct a coherent ICT-platform. Also a more
general issue is the different personalities among people which are both difficult to estimate
and to solve. That being said, GTO and GTT incorporate the three preconditions that were
stated by (Rabelo, 2008).
1. Requires collaboration among involved partners that does not only involve sending e-
mail messages.
2. The existence of trust, considering that partners shall rely on each other (at all levels).
3. All (or most of) the activities carried out within a collaborative network organization
should be made via computer networks, i.e. digital transactions should be the routine,
and not an exception
By having the three preconditions the authors argues that it justifies that Volvo is ready to
start investigating on how an ICT-platform should be implemented.
How an implementation of an ICT-platform would succeed and how it will be accepted
depends on the preconditions. As had been said earlier there are a lot of tools at Volvo, this
could be discussed to be several ad-hoc solutions. As stated from the interviews, some
software are seldom used because of lack of knowledge of the software or that they are too
complex to use. An example is the database with completed projects; the inconsistent naming
convention makes it hard for people to find the projects they are looking for. This is a case of
software being implemented or managed wrong. If employees could give feedback on the
system before implementation the authors thinks that a more general acceptance would help
the implementation of an ICT-platform.
If all these underlying issues are not taken into account when developing an ICT-platform, it
will probably not work as intended even if the platform itself is working as it should.
34
6.1 Further work For the first paragraphs in the discussion, it is stated that the scope of this research is only
applicable to the research area. To be able to find out if the results of this thesis can be
applicable to all stakeholders involved in product development projects and their respective
interfaces, all departments at Volvo needs to be researched.
The prerequisites for an ICT-platform are not fully met, which means that further research
needs to be conducted on how standardized project work can be managed at Volvo. Not only
to give a more detailed analysis of the subject, but also to create a foundation for the
architecture of the ICT-platform. It would also be interesting to see if and how the PTM
system could be implemented into the final ICT-platform.
If an ICT-platform would be implemented, a research on the current technical knowledge at
Volvo needs to be performed. This to find out if they have the expertise to translate the
practical project work into a complete ICT-platform.
35
7. CONCLUSION
The conclusion addresses how and where in the thesis the research questions were answered.
The purpose of this master thesis was to find out if an ICT-platform can be implemented and
help project work at Volvo. The results from the discussion show that an ICT-solution can be
implanted but to implement an ICT-platform further work is needed.
How is practical project work carried out at GTO and GTT?
How practical project work is carried out is answered in the empirical findings, chapter 4.2. It
is evident that for product development projects a Stage-Gate model is used which is designed
for product development projects. Meanwhile GTO uses a project process called PSM, which
is used primarily for production changes and not product changes. At the moment the two
different project models are not completely aligned.
How is information communicated between GTO and GTT in project work?
This is answered in the empirical findings chapter 4.1. Several different tools and
communication channels are used when sending information, where unstructured data is often
sent through e-mail and Microsoft Share Point, and structured data is sent via System E and
System F. The communication, information and transparency mentioned in the problem
definition were found during the interviews, which resulted in several potential improvement
areas. The scope of this research limits the field of how well the different improvement areas
cohere with other departments at Volvo and is suggested as further work.
How can an ICT-platform support project work and collaboration at GTO and GTT?
This is answered in chapter 5 and elaborated in chapter 6. Several ad-hoc solutions could be
found to increase the collaboration between GTT and GTO. As mentioned in the discussion
the ad-hoc solutions will only resolve one issue. Moreover it was stated that the company is
not ready for a complete implementation of an ICT-platform, which has been suggested for
further work.
ICT-solutions could be implemented but only to solve specific problems. To be able to
implement an ICT-platform the prerequisites need to be solved.
36
REFERENCES
Anderson, R. E., 1993. Can stage-gate systems deliver the goods?, Financial Executive, vol 9
no 6 pp. 1-34.
Becerra-Fernandez, I., 2006, ICT and Knowledge Management Systems in Encyclopedia of
Knowledge Management, ed D. G., Schwartz, IGI Global, Pennsylvania, pp. 230 - 236.
Bellgran, M., Säfsten, K., 2010. Production Development. 1st ed. London: Springer.
Bryman, A., Bell, E., 2003. Business Research Methods. 3rd ed: Oxford University Press.
Camarinha-Matos, L. M., Afsarmanesh, H., Ollus, M., 2008. Ecolead and cno base concepts
in Methods and tools for collaborative networked organizations, eds L. M. Camarinha-Matos,
H. Afsarmanesh, M. Ollus, Springer, US pp.8-21.
Coakes, E., 2006. Storing and sharing knowledge: Supporting the management of knowledge
made explicit in transnational organisations. The Learning Organization, vol. 13 no. 6, pp.
579-593.
Cooper, R. G., 1990. Stage-gate sytemes: a new tool for managing new products. Business
Horizons, vol. 33 no. 3, pp. 44-54
Correia, A.-P., 2008. Team conflict in ICT-rich environments: Roles of technologies in
conflict management, British Journal of Educational Technology, vol. 39 no. 1, pp. 18–35.
Duque, R., Collins, M., Abbate, J., Azambuja, C. C., Snaprud, M., 2007. History of ICT in
Past, Present and Future of Research in the Information Society, eds W. Shrum, K.R.
Benson, W.E. Bijker, K. Brunnstein, Springer, US pp 33-45.
Grönlund, J., Sjödin, D. R., Frishammar, J., 2010. Open Innovation and the Stage-Gate
Process: A revised model for new product development, California Management Review, Vol.
52, 3, pp. 106 –131.
Khakhar, D., Cornu, B., Wibe, J., Brunello, P., 2007. ICT and Development in Past, Present
and Future of Research in the Information Society, eds W.Shrum, K.R. Benson, W.E.
Bijker, K.Brunnstein, Springer, US pp 47-62.
Know4Car consortium, Circle, 2015. Available from: <
http://www.know4car.eu/public/pictures/temp.png/view>. [1 June 2015]
Marco, T., Montorio, M., 2007. The future of manufacturing: Survey of international
technology foresight initiatives in Advanced Manufacturing. An ICT and Systems
Perspective, eds M. Montorio , M. Taisch , K-D. Thoben, Taylor & Francis, pp. 1-12.
Pixabay, 2015. Available from: < http://pixabay.com/sv/sociala-medier-personlig-581783/>.
[1 June 2015]
Rabelo, R. J., 2008. Advanced Collaborative business ICT infrastructures in Methods and
tools for collaborative networked organizations, eds L. M. Camarinha-Matos, H.
Afsarmanesh, M. Ollus, Springer, US pp. 8-21.
37
Rosenau, M., Githens, G., 2005. Successful Project Management: A Step-by-Step Approach
with Practical Examples. 4th ed. New Jersey: John Wiley and Sons, Inc.
Pinto, J., 2007. Project Management, Achieving Competitive Advantage Global Edition. 1st
ed. Harlow: Pearson Education Limited.
Project Management Institute, PMI, 2013. A Guide to the Project Management Body of
Knowledge (PMBOK Guide). 5th ed. Newtown Square: Project Management Institute, Inc
Somasundaram, G., Shrivastava, A. (eds) 2009. Information Storage and Management:
Storing Managing and Protecting Digital Information, Wiley Publishing, Indianapolis.
Stage-Gate product development, Idaho State Journal, 2012. Available from:
http://search.proquest.com/docview/942991869 [1 June 2015]
Suran, S., 2015. How to Effectively Implement Change, Journal of Corporate Accounting &
Finance,vol. 26, no. 4, pp 5–12
Vandevelde, A., Van Dierdonck, R., 2003. Managing the design-manufacturing interface.
International Journal of Operations & Production Management, vol. 23 no. 11/12, pp. 1326-
1348.
Orlikowski, W. J., 1992. Learning from Notes: organizational issues in groupware
implementation. In Proceedings of the 1992 ACM conference on Computer-supported
cooperative work (CSCW '92). ACM, New York, NY, USA, pp. 362-369.
Ying, Z., Pheng, L. S., 2014. Project Communication Management in Complex Environments.
1st ed. Singapore: Springer.
.
I
APPENDIX A
Communication Subject
Nr.
Interview
Nr. Specific Issues General Issues Proposed Solution
C1.1 2 Send email to concerned
PMs
Group
management
Automated within ICT
C1.2 2
Communication GTT-
GTO enclosed,
sometimes CPM missed
contacting stake holders
Group
management
Improved cross
functionality with
direct messages to all
stake holders within a
group
C2.1 3
The size of the project is
not determined, it can
grow and switch from
one line organization to
another (said by GTO)
Project maturity More information
about the project to all
stake holders
C2.2 3 Merging projects takes
time and resources
Project
management
Standardized way of
grouping projects
C3.1 3
GTO-local needs info
about the product, GTO
PM needs info about the
production
Transparency Good communication
between product
designer and technical
preparation
C3.2 3
GTO doesn’t find the organization
transparent. GTO needs
to ask for information.
Transparency Better communication,
right information
should flow to the
right people
C3.3 3
Product development is
isolated within GTT
(said by GTO)
Transparency Invite GTO to have
better understanding in
product development
C3.4 3
There are three
communication
interfaces (said by
GTO), GTT-GTO PM,
GTO Regional-GTO
Local, GTO Regional
Transparency Merge communication
C3.5 3
Delayed Start cost
project usually result in
shorter lead time for
GTO. GTO works
harder, may cause bad
quality
Transparency
Communication or hint
in time so GTO may
have a chance to
handle it
C3.6 3
Tools are developed and
suddenly the concept is
changed and the tool is
outdated, this leads to
high costs
Transparency Better communication
at the right time
II
Communication Subject
Nr.
Interview
Nr. Specific Issues General Issues Proposed Solution
C4.1 4, 10
The performance of the
project is based on the
chemistry between
people and also how
older projects worked
out (the “best” solution is not always the best
solution)
Neutralize people
chemistry
Standardized
communication
approaches
C3.7 4
GTO is not a part of the
development loops as
they want and should be
Transparency Better cross-
functionality
C4.2 4
The technical
preparation team and
people involved in the
industrialization phase
do sometimes have
divided opinions
Communication
and
standardization
Better communication
within GTO
C3.8 4
GTT only sees a
fraction of the
production development
Transparency Better cross-
functionality
C1.3 5
Everyone needs to be
informed when a project
is late
Transparency Group communication
C4.3 5
GTO may have to
deliver a concern to
GTT that first was not a
demand but when they
got challenged it turns
out into a demand
(GTT: Sometimes the
cost of fixing the issue
is more than just leaving
it as it is)
Neutralize people
chemistry
Due to different
personalities.
Standardized
communication
approaches
C3.9 7
One person tries to get
out information from a
project on GTT due to
long lead time tools
Transparency GTO needs
information early
C3.10 10
GTT can change the
whole concept of a
product from what we
were working on.
Transparency GTO needs fast
updates so they don’t work on outdated data
III
Documentation Subject
Nr.
Interview
Nr. Specific Issues General Issues Proposed Solution
D1.1 1
Product change leads to
not all IDs are updated
through the chain
Inconsistency
when updating
data
D1.2 1 Documents need to be
updated
Old documents Notification system for
stake holders
D1.3 1, 2, 10
Same document are
stored on different
places, templates are
hard to find
Inconsistency
when storing files
Documents needs to be
stored on same place,
template database
D8.1 1
Quality status reporting
takes time, needs to be
reported to the manager
No flexible status
system
Quality reporting
system
D1.4 2
Hard to find
documentation on how
to use different tools
Inconsistency on
which database to
use for how-to
documents
Knowledge database
D2.1 2
The structure on
Microsoft Share Point
looks different
depending on the PM
Inconsistency in
structure
Standardized structure
(names and place of
files and folders)
D1.5 2
Small product changes
(GTT) does not lead to
a new article number
which may affect other
departments later
No alert system
through the whole
stake holder chain
Visualize/educate the
importance in how a
decision may cause
problems later. Fail
proof when changing
product.
D1.6 2
Few people read white
books
Inconvenient to
find
documentation
Lessons learned log
D1.7 2
Structured work flow
plan is not updated
Inconvenient to
update project
plan
Easier accessible and
updated structured
work flow (process
handler)
D3.1 3 Merging projects takes
time and resources
Project
management
Standardized way of
grouping projects
D3.2 3
Needs to contact GTO
PM for information
about the product
project portfolio
Project
management
Easy access to the
portfolio
D4.1 4
It’s more important to be able to visualize the
project plan than what
tool to use. Microsoft
Project is hard to
visualize.
Visualization Visualize project plan
in ICT
IV
Documentation Subject
Nr.
Interview
Nr. Specific Issues General Issues Proposed Solution
D5.1 4
GTO isn’t a part of the development loops as
they want and should be
Transparency Better cross-
functionality
D4.2 4
One hard aspect is to
get a good picture of the
whole project
Holistic view Visualization and
connect stake holders
within ICT
D5.2 4
GTT only sees a
fraction of the
production development
Transparency Better cross-
functionality
D7.1 4
Experience is the most
important input to a
project, can’t be replaced with systems
Experience
Management
Capture relevant
experience (Serena).
Tag cloud where
common activity names
and time consumption
from earlier projects
are saved
D6.1 4
GTT and GTO uses
different tools which
leads to time consuming
formatting
Tools Common tools
D1.8 5
When starting a project
CPM can set the rules
for the project, i.e. what
project planning tool to
use or the structure in
Microsoft Share Point
Rules
management
The rules is included
when starting a project
so all PMs can see
D5.3 7
One person tries to
obtain information from
a project on GTT due to
long lead time tools
Transparency GTO needs information
early
D6.2 7
People use tools of their
own choice (i.e. project
planning) due to
different knowledge
Tools Standardized way of
working
D2.2 7
People doesn’t always save files in a structured
way on Microsoft Share
Point
Standardization Standardize structure
and way of working
D2.3 7
Project info should be at
Microsoft Share Point,
this is not always the
case
Standardization Standardize structure
and way of working
V
Documentation Subject
Nr.
Interview
Nr. Specific Issues General Issues Proposed Solution
D8.2 8
8 intro block per year, 4
small, 4 large. Usually
System A and System
B, see Appendix C. The
larger is PMR and Start
Cost. Specific dates.
Time Calendar or similar
D9.1 8
Measurement of project
quality in terms of
faults or no faults. Not
accounting the money
each project costs leads
to no priority
Project priority If money was included
the problematic
projects could have a
better priority order
D8.3 8
Some intro blocks can’t be delayed due to legal
requirements i.e. air bag
Time Importance system
D9.2 8
ILG – Industrial Launch
Group. Local at each
factory where they look
through all departments
and suppliers to see if
all activities have been
done. Work saved in an
Excel sheet in Microsoft
Share Point
Project assurance The work of ILG could
be facilitated in an ICT
D7.2 8
There is a designated
Intro Engineer that
takes care of PMR,
System A and System B
(see Appendix C) in
their respective area,
where they need to
investigate how
different changes
impact each other
Project correlation Correlation between
changes and connect
impacts
D2.4 10
Aligned gates between
DVP and PSM is under
construction. PSM is
great for in-house
projects but only use the
tools for product
projects
Official structure Official structure
removes the need of
doing a local solution
D5.4 10
GTT can change the
whole concept of a
product from what we
were working on.
Transparency GTO needs fast updates
so they don’t work on outdated data
VI
Documentation Subject
Nr.
Interview
Nr. Specific Issues General Issues Proposed Solution
D5.5 10
In the beginning of a
project it is really hard
to interpret the project
Project maturity
Transparency
All stake holders needs
to know their part and
task as soon as possible
Knowledge Subject
Nr.
Interview
Nr. Specific Issues General Issues Solution
E1.1 1 ”Why change a fully working GDP”
Change
management
Information and
education
E2.1 2, 3
Some people are not
aware of high
workload in the
beginning of a project
and changes the way of
working (front end
loading)
Awareness Educate on how to
execute a DVP project
E2.2 2
Not enough resources
when using DVP leads
to late deliveries
Awareness Information the
workload in a certain
type of project leads to
easier planning of
resources
E4.1 3
GTT PMs has good
information about
GTO, designers have
not
Transparency Information/education
to the right people
E3.1 3
PSM can be followed
in different ways:
-Experience of PM
-General experience of
the project group
-How mature the
project is
Standardization Educate/inform how a
project model should be
followed
E1.2 4
RnD30 and other new
improvements needs to
have set goals that
people understand
Change
management
Educate why
E2.3 4 PGT and PAP is hard
to follow
Awareness Education of tools
E2.4 5
GTO says no to a lot of
issues regarding DFA.
(Impression from GTT
is that they don’t understand DFA)
Awareness
Educate/inform why a
certain task is important
VII
Knowledge Subject
Nr.
Interview
Nr. Specific Issues General Issues Solution
E3.2 7
People use tools of
their own choice (i.e.
project planning) due
to different knowledge
Standardization Standardized way of
working
E3.3 8
Different conditions
between factories, not
only technical but
language and cultural
as well
Standardization Standardization that
accounts for different
causes
E1.3 9
The hard part is to get
people to use new
products and tools
Change
management
Educate and show the
benefits
E2.5 10
Educate people in PSM
so they know what
tools that are available
Awareness Education will decrease
the scattering on how a
project should be
executed
E3.4 10
Assembly simulations
are done but can’t cover all parts, designs,
variations and models.
GTT and GTO are not
in an agreement on
who should handle the
assembly simulations.
Standardization Everybody knows who
should do what
VIII
Resources Subject
Nr.
Interview
Nr. Specific Issues General Issues Proposed Solution
R1.1 1 Different organizations
on every project
Resource problem Visualize organization
and hierarchy
R1.2 2
Not enough resources
when using DVP leads
to late deliveries
High workload,
Resource problem
Database on the
workload connected to
each role
R2.1 2
Communication GTT-
GTO enclosed,
sometimes CPM missed
contacting stakeholders
Group
management
Improved cross
functionality with
direct messages to all
stake holders within a
group
R1.3 2
Takes time to search for
resources
Resource problem Resource pool, system
to see how many and
what projects people
are part of
R1.4 2 People are being
replaced
Resource problem Resource assurance
R3.1 4
The performance of the
project is based on the
chemistry between
people and also how
older projects worked
out (the “best” solution is not always the best
solution)
Neutralize people
chemistry
Standardized
communication
approaches
R1.5 4
It is important to have
capable people in the
project
Resource problem Resource assurance
R4.1 4
One hard aspect is to get
a good picture of the
whole project
Holistic view Visualization and
connect stake holders
within ICT
R4.2 5
Everyone needs to be
informed when a project
is late
Transparency Group communication
R3.2 5
GTO may have to
deliver a concern to
GTT that first is not a
demand but when they
got challenged turns out
into a demand (GTT:
Sometimes the cost of
fixing the issue is more
than just leaving it as it
is)
Neutralize people
chemistry
Due to different
personalities.
Standardized
communication
approaches
IX
Resources Subject
Nr.
Interview
Nr. Specific Issues General Issues Proposed Solution
R2.2 8
12 technical areas where
intro engineering has
one person at each area.
Local engineering is
divided into layout and
Technical Preparation
into modules. Have to
talk to several, not only
one local engineer when
the layout is changed.
Group
management
ICT should have the
responsibilities of each
engineer divided in
both modules and
layout and then group
the affected people
R2.3 8
It is important to be
effective on meetings
and that they follow an
agenda and structure.
GTO PM has a list on
who to invite on
meetings
Group
management
The right people on
meetings and stick to
the agenda
R1.6 10
Experience and contacts
has a huge impact on
how fast a problem can
be solved
Resource and
experience
management
Right people know
how to solve problems
R1.7 10
Organization charts are
used but not always
updated, takes time to
find your resource
Resource problem ICT can be updated
automatic when people
leave projects or new
one arrives
X
Gates Subject
Nr.
Interview
Nr. Specific Issues General Issues Solution
G1.1 1
Late changes on product
make production less
adaptable
Transparency
G1.2 1 Gates can sometimes be
merged
Dynamic platform
G1.3 3
PSM gates needs to be
adapted to fit into DVP
gates
Is done internally at
GTO right now
G1.4 4 Delays in a Start Cost
project spreads
G1.5 6
Departments have
different lead times and
cannot always follow
time plan
Time plan Dynamic platform
XI
APPENDIX B
APPENDIX C
Tools and IT-Tools
There is a range of different tools available in both project work, assignments and line work,
where each tool usually has one specific purpose. Below is a list of specific and general tools
used in projects.
System A - Quality issues notification system
System B - Product modification notification system
System C - Closed projects database
System D - Resource management system
System E - Production database
System F - Product database
System G - Tolerance tool
PGT - Project governance system
Microsoft Share Point
Lync
Intranet
Microsoft Project
Excel
XII
APPENDIX D
Introduction of ourselves
Explaining why we are conducting this interview.
Can we record this interview?
Questions of introduction
Would you like to tell us about your education and career?
What role do you have in the organization?
Can you tell us briefly about what you are working on and what kind of projects?
The organization of the project
What roles are there, what is the interaction are their between the different roles?
Main Questions
Type of project
Do you follow any project model?
How easy is the PSM/DVP followed?
How do you find this project model? (Does it fulfill its purpose?)
If you follow the PSM differently depending on the project?
What tools do you use to create and manage projects?
Manual and IT tools
How do you delegate tasks and how do you follow up?
What tools do you use to control the project?
Is there documentation on how to work with these tools?
We have heard that the startup cost project will be delayed, how are you affected by it?
What do you think is the reason?
Internal Data Management & Communication
How do you process value adding data? (Recycled / stored data)
What internal communication tools do you use?
External Data Management & Communication
How does the data being exchanged between the other departments? How to check that the
data has been received?
How do you share with you of your output from a value creation process to other
departments?
XIII
What communication has taken place before data is exchanged?
Collaboration GTO-GTT
In which phase of the project will the collaboration the with the GTT/GTO increase?
Is it in any particular phase of the project which is working?
If there is a change of a product how do you notice it and vice versa?
Are there limitations or directives on how data is supposed to be communicated between
departments?
Do you perceive the organization as transparent?
Suppliers
Do you communicate with suppliers? How is the communication?
How are the data between you and supplier? Are there limitations or directives for the flow of
information?
How are things generally going when working in projects?
Does project work well?
What are the strengths / weaknesses?
Some special things that you think are missing?
Concluding questions
What do you have and what do they expect in the future?
If there was a tool that could facilitate projects, would it be used, or does it feel like one in the
crowd? What would be needed for PM and other users to feel it is a necessity in their daily
work?