School of Innovation, Design and Engineering
Review and Approval Process
-An Operation Development Project at ABB FACTS R&D
Master Thesis, Product Development
30 credits, D-level
Product and Process Development, Concurrent Engineering
Master Thesis Programme Innovation and Product Design
Malin Bånghammar & Marie Norling
Date of presentation: 15th June 2012
Tutors:
Rolf Lövgren, Mälardalen University
Mikael Wilroth, ABB FACTS
Examiner:
Rolf Lövgren, Mälardalen University
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Abstract
ABB is a global leader in Power and Automation Technologies. This Theses Work has been
carried out at ABB FACTS R&D Department in Västerås. ABB FACTS intend to develop new
Product Platforms that is partly accomplished with new methods and processes. This Master
Thesis concerns the development of a generic Review and Approval Process for these R&D
Projects.
The development of the generic Review and Approval process is mostly founded on several
interviews of employees at ABB FACTS. The respondents are employees from several
departments with different amount of experiences and background. In addition to the
interviews a Literature Study focused on Roles and Responsibilities, Document Management
and R&D Processes was performed.
Information in connection to the problem statements concerning Responsibility- and Project
Roles in R&D projects and Review and Approval Execution was collected and analyzed during
the project. Information regarding how to demonstrate Roles and Responsibilities in relation
to the project participants was also considered.
The result of this project consists of a Responsibility Chart where all R&D Project related
Document Types are listed in relation to the defined Project Roles. This Responsibility Chart
also display what responsibility every Project Role has regarding review and approval related
to the Document Types. Besides the Responsibility Chart also other objects were developed,
such as a Review Record, a Process Description and a User Guide.
The above mentioned results are developed in close cooperation with several R&D Project
Managers. Furthermore the expectations are that the developed result will be taken in usage
and thereby continuously be revised and improved in order to suit the organization to
maximum extent.
Keywords: ABB FACTS, Process Development, Review and Approval Processes, ISO 9001,
Stage-Gate, R&D, Operational Development, RACI, Responsibility Chart, Project Role,
Responsibility Role.
2
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Acknowledgements
First of all we would like to send a warm thank you to our ABB FACTS tutor Mikael Wilroth.
Without your experienced input and feedback this Master Thesis would not have been
possible.
We would also like to announce our appreciation to the VU- team for their engagement and
invaluable feedback on our work throughout the whole process.
A big thank you also goes to the whole Research and Development Department for making us
feel welcome. Our appreciation also goes to the other employees at ABB FACTS that have
participated in interviews and provided us with valuable information during our work. The
information that you all shared with us was priceless for the result of this Master Thesis.
At last we would like to thank our tutor at Mälardalen University, Rolf Lövgren. We really
appreciate the expertise knowledge that you shared with us and for the helpful discussions
we had during the project.
Thank you!
Malin Bånghammar & Marie Norling
3
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Dictionary
DRM
–
A Design Review Meeting is a meeting where one or several
parts of the construction are reviewed. It shall result in a
protocol that describes the reviewed parts and the action
points clearly. The protocol shall be archived with the rest of
the projects documentation (ABB-document10, 2008).
eCM
–
The document management system used at ABB FACTS.
Flow Chart
–
“A schematic representation of a sequence of operations, as
in a manufacturing process or computer program. Also called
flow diagram, flow sheet.” (The free dictionary2, 2012-05-31)
Issued document
–
A document that is produced.
Platform Product
–
“A platform product is built around a pre-existing
technological subsystem (a technology platform)” (Eppinger
and Ulrich, 2008, p. 20).
Project Role
–
In this Master Thesis the term Project Role has been used as a
definition of a person with a specific competence in a project.
RACI
–
Role and Responsibility Matrix for projects.
Responsibility Role
–
In this Master Thesis the word Responsibility Roles is used to
define the responsibility one person has. The responsibility
can for example be “approver” and that means that the
Responsibility Role in this example is the approver of a certain
Project Task.
VU-team
–
The aim for a VU-team is to establish a clear operational
improvement where the businesslike situation and the
strategic direction are considered. The aim is also to create a
structure that enables continuity in case of changes of
leadership. The goal is to create both short- and long-termed
results regarding realization of the company’s visions and
strategic goals, engage all co-workers and to build a common
company culture (ABB-document4).
4
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
Workshop
–
2012-06-08
“An educational seminar or series of meetings emphasizing
interaction and exchange of information among a usually
small number of participants: a creative writing workshop.”
(The free dictionary1, 2012-05-09)
5
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Abbreviations
AC
–
Alternating Current
D
–
Plant Design & Construction
DE
–
Electrical Design
DM
–
Plant Design
DRM
–
Design Review Meeting
eCM
–
Enterprise Content Management
FACTS
–
Flexible AC Transmission Systems
FMEA
–
Failure Mode Effect Analysis
ISO
–
International Organization for Standardization
M
–
Marketing & Sales
MoM
–
Minutes of Meeting
MRS
–
Market Requirement Specification
O
–
Operations
OpEx
–
Operational Excellence
P
–
Product Management & OpEx
PDM
–
Product Data Management
PEM
–
Project Execution Model
6
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
PUGH
–
Pugh concept selection
QFD
–
Quality Function Deployment
R&D/R
–
Research and Development
RACI
–
R = Responsible (author)
A = Accountable (approving person)
C = Consulted (review)
I = Informed (carbon copy)
RC
–
Responsibility Chart
T
–
Technology
TC
–
Control System Integration
TOPS
–
Total Optimized Process System
TRS
–
Technical Requirement Specification
TS
–
System Design
TTT
–
The Template Tool
VU
–
Operational Development
WBS
–
Work Breakdown Structure
7
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Contents
1.
INTRODUCTION ............................................................................................................................................ 13
1.1
1.2
ABB FACTS ........................................................................................................................................... 13
PROJECT INTRODUCTION .......................................................................................................................... 13
2.
AIM OF PROJECT ........................................................................................................................................... 13
3.
PROJECT DIRECTIVES .................................................................................................................................. 13
4.
PROBLEM STATEMENT ................................................................................................................................ 14
5.
PROJECT DELIVERIES AND DELIMITATIONS ............................................................................................ 14
5.1
DELIVERIES ............................................................................................................................................. 14
5.1.1
Gate 1 - Planning and Requirements .............................................................................................. 15
5.1.2
Gate 2 - Literature, Interviews and FACS Processes ....................................................................... 15
5.1.3
Gate 3 - Design ................................................................................................................................. 15
5.1.4
Gate 4 - Test and evaluation ........................................................................................................... 15
5.1.5
Gate 5 - Presentation ....................................................................................................................... 15
5.2
LIMITATIONS ........................................................................................................................................... 15
6.
THEORETICAL BACKGROUND & SOLUTION METHODS ........................................................................... 16
6.1
6.1.1
6.2
6.2.1
6.2.2
6.2.3
6.3
6.4
6.5
6.5.1
6.5.2
6.6
7.
PROJECT PLANNING – GANTT CHART ......................................................................................................... 16
Project Gates .................................................................................................................................... 16
INFORMATION GATHERING ....................................................................................................................... 17
Literature Review ............................................................................................................................ 17
Company Insight .............................................................................................................................. 17
Interview Method ............................................................................................................................ 18
QFD ....................................................................................................................................................... 19
FUNCTION ANALYSIS ................................................................................................................................ 19
DESIGN PROCESS ..................................................................................................................................... 20
Concept Generation ......................................................................................................................... 20
Concept evaluation .......................................................................................................................... 21
SUMMARY – THEORETICAL BACKGROUND & SOLUTION METHODS................................................................ 22
APPLIED SOLUTION PROCEDURES ............................................................................................................. 23
7.1
PROJECT PLANNING – GANTT CHART ......................................................................................................... 23
7.2
INFORMATION GATHERING ....................................................................................................................... 23
7.2.1
Literature Review ............................................................................................................................ 23
7.2.2
Company insight .............................................................................................................................. 30
7.3
QFD ....................................................................................................................................................... 44
7.4
FUNCTION ANALYSIS ................................................................................................................................ 45
7.5 DESIGN PROCESS - RESPONSIBILITY CHART ............................................................................................... 45
7.5.1
Brainstorming - Responsibility Chart ............................................................................................. 45
7.5.2
Concept Evaluation - Responsibility Chart ...................................................................................... 47
7.5.3
Concept Development – Responsibility Chart .................................................................................. 48
7.6 DESIGN PROCESS - RESPONSIBILITY ROLE .................................................................................................. 48
7.6.1
Brainstorming - Responsibility Role ............................................................................................... 48
7.6.2
Concept Evaluation- Responsibility Role ......................................................................................... 50
7.7 DESIGN PROCESS- TYPE OF REVIEW ........................................................................................................... 52
7.7.1
Brainstorming - Type of Review ...................................................................................................... 52
7.7.2
Concept Evaluation- Type of Review ............................................................................................... 53
7.7.3
Concept Development – Type of Review .......................................................................................... 54
7.8 DESIGN PROCESS – REVIEW RECORD ......................................................................................................... 54
7.9 CONCEPT DEVELOPMENT – REVIEW RECORD ............................................................................................. 55
8
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
7.10
7.11
7.12
8.
2012-06-08
FMEA ................................................................................................................................................... 56
DESIGN PROCESS – REVIEW AND APPROVAL USER GUIDE .................................................................... 56
SUMMARY – APPLIED SOLUTION PROCEDURES ........................................................................................... 57
RESULTS ........................................................................................................................................................ 59
8.1
RESPONSIBILITY CHART ........................................................................................................................... 59
8.2 RESPONSIBILITY ROLES .............................................................................................................................. 61
8.3
TYPE OF REVIEW ..................................................................................................................................... 61
8.4 REVIEW RECORD ........................................................................................................................................ 62
8.5
THE REVIEW AND APPROVAL EXECUTION PROCESS..................................................................................... 63
8.5.1
Review and Approval User Guide .................................................................................................... 65
9.
ANALYSIS....................................................................................................................................................... 66
9.1
9.2
9.3
9.4
9.5
10.
10.1
10.2
11.
11.1
11.2
11.3
11.4
11.5
12.
HOW DO THE REVIEW AND APPROVAL PROCESSES FUNCTION AT ABB FACTS TODAY? .................................. 66
WHAT KINDS OF RESPONSIBILITY ROLES NEED TO BE INCLUDED IN THE REVIEW AND APPROVAL PROCESS AT ABB
FACTS? ...................................................................................................................................................... 66
WHAT KINDS OF DOCUMENT TYPES AND PROJECT ROLES NEED TO BE DEFINED IN A R&D PROJECT AT ABB FACTS?
67
HOW SHOULD THE RESPONSIBILITIES IN RELATION TO THE PROJECT ROLES BE CLARIFIED AND DESCRIBED? ..... 67
HOW SHOULD THE REVIEW AND APPROVAL PROCESS BE EXECUTED? ............................................................ 68
CONCLUSIONS & RECOMMENDATIONS ................................................................................................. 69
CONCLUSION ........................................................................................................................................... 69
RECOMMENDATIONS ................................................................................................................................ 69
REFERENCES ............................................................................................................................................ 71
PRINTED REFERENCES .............................................................................................................................. 71
DIGITAL REFERENCES ............................................................................................................................ 71
ABB INTRANET ....................................................................................................................................... 72
ORAL REFERENCES ................................................................................................................................... 73
FIGURE REFERENCES ................................................................................................................................ 73
APPENDICES ............................................................................................................................................. 74
9
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
List of Appendices
APPENDIX 1 – PROJECT DIRECTIVES ...................................................................................................... X
APPENDIX 2 – REQUIREMENT SPECIFICATIONS .................................................................................. X
APPENDIX 3 – GANTT CHART ................................................................................................................... X
APPENDIX 4 – ORGANIZATIONAL CHART ............................................................................................. X
APPENDIX 5 – INQUIRE SHEET .................................................................................................................. X
APPENDIX 6 – INTERVIEWS ....................................................................................................................... X
APPENDIX 7 – QFD ....................................................................................................................................... X
APPENDIX 8 – FUNCTION ANALYSIS ....................................................................................................... X
APPENDIX 9 – PUGH ANALYSIS ................................................................................................................ X
APPENDIX 10 – RESPONSIBILITY CHART ............................................................................................... X
APPENDIX 11 – FMEA .................................................................................................................................. X
APPENDIX 12 – REVIEW RECORD ............................................................................................................. X
APPENDIX 13 – REVIEW AND APPROVAL USER GUIDE ...................................................................... X
10
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
List of Figures
FIGURE 1 – GANTT CHART ........................................................................................................................ 15
FIGURE 2 – PROJECT GATES ..................................................................................................................... 15
FIGURE 3 – THE HOUSE OF QUALITY ...................................................................................................... X
FIGURE 4 – THE FUNCTION TREE ............................................................................................................. X
FIGURE 5 – THE GENERIC PRODUCT DEVELOPMENT PROCESS ....................................................... X
FIGURE 6 – STAGE-GATETM MODEL – FROM DISCOVERY TO LAUNCH .......................................... X
FIGURE 7 – LINEAR RESPONSIBILITY CHART ....................................................................................... X
FIGURE 8 – SIMPLIFIED LINEAR RESPONSIBILITY CHART ................................................................ X
FIGURE 9 – EXAMPLE OF RACI CHART ................................................................................................... X
FIGURE 10 – R&D PROJECT – DESIGN PROPOSAL PHASE ................................................................... X
FIGURE 11 – PHASES OF THE R&D PROCESS ......................................................................................... X
FIGURE 12 – PROJECT STRUCTURE G2- .................................................................................................. X
FIGURE 13 – DOCUMENT LIFE CYCLE .................................................................................................... X
FIGURE 14 – CONCEPT 1 – RESPONSIBILITY CHART ........................................................................... X
FIGURE 15 – CONCEPT 1 – MAIN HEADINGS AND SUB HEADINGS .................................................. X
FIGURE 16 – CONCEPT 1 – SHEET 2 PROJECT ROLES ........................................................................... X
FIGURE 17 – CONCEPT 1 – SHEET 3 RESPONSIBILITY ROLES ............................................................ X
FIGURE 18 – CONCEPT 2 – RESPONSIBILITY CHART ........................................................................... X
FIGURE 19 – CONCEPT 3 – RESPONSIBILITY CHART ........................................................................... X
FIGURE 20 – FINAL TYPE OF REVIEW AND APPROVAL ...................................................................... X
FIGURE 21 – REVIEW RECORD – CHECK BOXES ................................................................................... X
FIGURE 22 – REVIEW RECORD – REVISION ID COLUMN .................................................................... X
FIGURE 23 – REVIEW RECORD – COMMENT IMPLENEATATION RESPONSIBLE ........................... X
FIGURE 24 – REVIEW AND APPROVAL USER GUIDE – RESPONSIBILITY CHART ......................... X
FIGURE 25 – RESPONSIBILITY CHART (RC)............................................................................................ X
FIGURE 26 – RESPONSIBILITY CHART – NAMES ON PROJECT ROLES............................................. X
FIGURE 27 – RESPONSIBILITY CHART – RESPONSIBILITY ROLE DESCRIPTIONS ........................ X
FIGURE 28 – RESPONSIBILITY CHART – DOCUMENT CONTROL ...................................................... X
FIGURE 29 – TYPE OF REVIEW AND APPROVAL ................................................................................... X
FIGURE 30 – REVIEW RECORD – FIRST PART ........................................................................................ X
FIGURE 31 – REVIEW RECORD – SECOND PART ................................................................................... X
FIGURE 32 – THE REVIEW AND APPROVAL EXECUTION PROCESS
FIGURE 33 – USER GUIDE ........................................................................................................................... X
11
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
List of Tables
TABLE 1 – PUCH SCORE EXPLANATION ................................................................................................. X
TABLE 2 – THE PRINCIPLES OF PUGH CONCEPT SELECTION ............................................................ X
TABLE 3 – DEFINED PROJECT ROLES RELATED TO EACH DEPARTMENT ..................................... X
TABLE 4 – INTERVIEW SUMMARY – DELIVERY PROJECTS, POSITIVE AND NAGATIVE ............ X
TABLE 5 – INTERVIEW SUMMARY – DEVELOPMENT PROJECTS, POSITIVE AND
NEGATIVE .................................................................................................................................. X
TABLE 6 – CONCEPT 1 – RESPONSIBILITY ROLE .................................................................................. X
TABLE 7 – CONCEPT 2 – RESPONSIBILITY ROLE .................................................................................. X
TABLE 8 – CONCEPT 3 – RESPONSIBILITY ROLE .................................................................................. X
TABLE 9 – CONCEPT EVALUATION – RESPONSIBILTY ROLE............................................................ X
TABLE 10 – CONCEPT 1 – TYPE OF REVIEW AND APPROVAL ........................................................... X
TABLE 11 – CONCEPT 2 – TYPE OF REVIEW AND APPROVAL ........................................................... X
TABLE 12 – CONCEPT 3 – TYPE OF REVIEW AND APPROVAL ........................................................... X
12
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
1. Introduction
This Master Thesis considers the area of Product and Process Development. The project has
been carried out at ABB FACTS R&D department during spring 2012 and concerns their
Research and Development Processes for new Product Platforms.
1.1 ABB FACTS
ABB is a global leading company in power and automation technologies and operates in more
than 100 countries. Their technologies enable the customers to improve their performance
and also to lowering the environmental impact. ABB strive to integral sustainability into all
their business aspects (ABB1, 2012-01-24).
ABB FACTS is a power industry term that stands for Flexible AC Transmission Systems. This
term covers technologies that enhance the security, capacity and flexibility of power
transmission systems. ABB FACTS provide solutions that enable power grid owners to
increase their existing transmission network capacity. This while maintaining or improving
the operating margins for grid stability (ABB2, 2012-01-24).
In the field of FACTS, ABB is the worldwide leader and can provide a full FACTS portfolio and
also in-house manufactured key components (ABB2, 2012-01-24).
1.2 Project Introduction
In the following years ABB FACTS intend to develop several new Product Platforms. This
development effort is partly accomplished with new methods and processes. A VU-team is
currently working to enable a uniformed and enhanced R&D Process for these new Product
Platforms.
ABB FACTS strive after a generic R&D process for these new projects. The aim of this Master
Thesis is to create a generic Reviewing and Approval Process for these R&D projects. The
project directives are available in Appendix 1 – Project Directives.
2. Aim of Project
The aim of this Master Thesis is to develop one part of the R&D Processes for ABB FACTS new
Product Platforms. The goal is to create a generic Review and Approval Process for R&D
Projects at ABB FACTS.
3. Project Directives
To make sure that this project is following the initiators expectations, the project initiator has
stated a couple of directives, see Appendix 1 – Project Directives. These directives contain
the following statements:


Perform a Literature Study.
Discuss and collect opinions with employees from concerned departments.
13
Mälardalen Univeristy
Malin Bånghammar & Marie Norling




2012-06-08
Develop relevant Process Descriptions, Role Descriptions and a list that
contains different Document Types.
Construct different relevant templates such as, for example, a Review
Record.
Make sure that the stakeholders review and approve the developed
documents, instructions and solutions.
Participate in VU-meetings that concerns R&D processes.
The Master Thesis shall also result in an English written report where the above tasks are
presented. An oral presentation is also necessary to make sure that ABB FACTS acquire
opportunity to take part of the result.
4. Problem Statement
The Project Requirement Specification is available in Appendix 2 – Requirement Specification.
According to the Project Description, problem statements have been established to help
reach a satisfying result. The Problem Statements have been developed and reformulated in
collaboration with the Project Initiator and also according to how the project has developed
during time. The problem statements are:





How do the Review and Approval Processes function at ABB FACTS today?
What kinds of Responsibility Roles need to be included in the Review and
Approval Process?
What kind of Document Types and Project Roles need be defined in a R&D
Project?
How should the responsibilities in relation to the Project Roles be clarified
and described?
How should the Review and Approval Process be executed?
5. Project Deliveries and
Delimitations
Within this section the limitations and expected deliveries concerning this Master Thesis are
described. The deliveries are divided into planned gates to ensure that the project proceeds
within the time schedule.
5.1 Deliveries
This Master Thesis is planned into five gates. Certain predetermined activities must have
been performed to pass these gates. This gate structure was chosen to ensure that the
specific tasks tied to the gates were completed in time. Besides the activities tied to this
gates other activities will be performed. Those activities are for example attending to
meetings and writing on the report. Descriptions of each gate are listed below.
14
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
5.1.1 Gate 1 - Planning and Requirements
Most of the project planning should be finished to this gate. A clear Project Description and
Requirement Specification also need to be established. Here it is also important to acquire a
good and fundamental knowledge about the aim of this project and the problems that need
to be solved.
5.1.2 Gate 2 - Literature, Interviews and FACS Processes
To pass this gate a Literature Study need to be executed. Performing interviews of
stakeholders are also included in this stage as well as get a better understanding of the
current R&D processes at FACTS.
5.1.3 Gate 3 - Design
This stage is focused on developing the new templates and Process Descriptions for the
Reviewing and Approval Processes in the R&D projects.
5.1.4 Gate 4 - Test and evaluation
In gate 4 the developed templates should be tested and evaluated by the stakeholders. The
test and evaluation will be executed with both Workshops and Review Meetings. This is done
to see how functional those are in their real context. Depending on these Test Results
necessary changes will be executed.
5.1.5 Gate 5 - Presentation
This stage is about getting ready for the presentations. There will be two presentations, one
will be held at ABB FACTS and the other one at Mälardalen University.
5.2 Delimitations
Besides the information included in the gates described above this project has other
restrictions. The Project Delimitations are listed below.




The Master Thesis stretches over a fulltime period of 20 weeks.
The presentation date of this Master Thesis is the 15th June 2012.
This Master Thesis will not consider the contents of the R&D Project
Related Documents.
R&D Project Role Descriptions will not be developed during this Master
Thesis
15
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
6. Theoretical Background & Solution
Methods
The Theoretical Background and the Solution Methods used in this Master Thesis are
described in the following section.
6.1 Project Planning – Gantt Chart
The Gantt Chart is a traditional tool for representing the project tasks in comparison with a
time line (Eppinger and Ulrich, 2008, p. 337). To make sure the project is following schedule it
is important to have a clear and well prepared Project Plan. Using a Gantt Charts is a method
of presenting project schedule information. Those activities are displayed against the time
line to show the current status for each task compared to the planned (Mantel and Meredith,
2010, p. 342). The Gantt Chart is a traditional and recognized presenting tool when different
tasks need to be executed (Eppinger and Ulrich, 2008, p. 337).
Figure 1, Gantt Chart represents a Gantt Chart for the Cheetah project illustrated in the book
Product Design and Development (Eppinger and Ulrich, 2008, p. 337). The Gantt Chart
contains a box for each task which represent the time to complete the task. This box is filled
to represent how far the task has been completed. The Gantt Chart also contain a time bar
(Eppinger and Ulrich, 2008, p. 337).
Figure 1, Gantt Chart (Eppinger and Ulrich, 2008, p. 337).
6.1.1 Project Gates
As mentioned in the Project Deliveries this Master Thesis is divided into five gates. The
reason why the gate model was used in this project is because it is already in use by the R&D
department. To ensure that this Master Thesis is within the time schedule and that it is going
in the right direction are two other reasons to why the gate structure was used. The process
for this Master Thesis is illustrated in Figure 2, Project Gates.
16
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Gate 1
Gate 2
Gate 3
Gate 4
Gate 5
•Planning
•Requirements
•Literature
•Interviews
•FACTS
processes
•Design
•Test and
evaluation
•Presentation
Figure 2, Project Gates
6.2 Information Gathering
Different kind of scientific methods have been used for the information gathering during this
Master Thesis. The scientific methods used are Literature Review and Interview Method.
These methods were used in order to gather the specific information that was needed to
execute this project.
Information about ABB FACTS was also gathered to receive knowledge about the company
and how this Master Thesis can be executed to enhance their R&D Process.
6.2.1 Literature Review
Guidelines from Hart (1998) Doing a Literature Review have been followed during the
Literature Review Process that has been executed during this project. Hart defines a
Literature Review as (Hart, 1998 p.13):
“The selection of available documents (both published and unpublished) on
the topic, which contain information, ideas, data and evidence written from
a particular standpoint (…)”
According to Hart the reading process should begin with skimming through the book and
noting its structure, topic and style. To identify the key chapters the parts of the book should
be quickly glanced at. Thereafter it is favourable to identify the idea, aims and logic for the
work by reading the preface and introduction. At last, the chapters that have been identified
as important according to the needs should be read (Heart, 1998 p. 54).
Guidelines according to Hart have also been followed during this Literature Review. These
guidelines are for example that is important to identify and discuss relevant Key Landmark
Studies on the topic, to use as much up-to-date material as possible and to critically evaluate
the material. It is also important to manage the information that the review produces by
having a system for record management. Also aspects that should be avoided have been
considered, such as; discuss outdated material, usage of jargon language, to misspell names
and not to have proper references (Heart, 1998 p. 219).
6.2.2 Company Insight
To ensure a good End Result to this Master Thesis an insight in ABB FACTS current processes
was necessary. The gathered information concerned information about the organization and
how the departments work with the Reviewing and Approval Processes. Also information
about the R&D Process, Roles and Responsibilities, Document Management Systems and
17
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Quality Assurance was be important. This kind of information was crucial to be able to create
a generic Reviewing and Approval Process for the R&D Projects.
6.2.3 Interview Method
Interviewing is an excellent research method that is designed to gather specific information.
This method can result in both quantitative and qualitative data. A successful interview
generates information or clarifies conclusions that other methods could not account for
(Hageback, 2002).
To choose respondents for the interviews a method called Samples that attempt to maximize
range was used. The aim for this method is that the interview respondents will be
intentionally selected so that all cases will be represented (Hageback, 2002).
The interview method that has been used during this process is called Semi structured
interviewing. According to Hageback (2002) this interview method is based on an interview
guide, is well prepared and has clear instructions. But the interviewer is still flexible to
explore new information.
A good preparation is essential to be able to receive the demanded data from the interview.
Some aspects should be considered before the interview is performed (Hageback, 2002);




Educational and social level
Ethnic or cultural characteristic
Gender
Age
The interview question can either be open- or close- ended. The differences between these
kinds of questions are that a close- ended question has fixed alternatives in contrast with
open- ended questions that have open alternatives. A close- ended question could for
example look like: “what are your interests?” 1) Training 2) Working 3) Meet people. When
the frequency of something is needed this type of question is too prefer. If the interview
should result in a description regarding the respondent’s emotions concerning a subject then
the open- ended question is more preferable.
During an interview, many things can be done to positively influencing the respondents.
Those can be seen in (Hageback, 2002).
6.2.3.1 Tape recorder or not
During an interview a tape recorder can be used as a substitute for note taking and it can also
give a better chance to get the whole picture of the interview. The negative side of using a
tape recorder is that some respondents do not like being recorded and therefore they might
leave out information (Hageback, 2002).
If a tape recorder is used a transcription needs to be done after the interview. This is very
time consuming, one hour tape can take up to six-eight hour to transcribe. The positive
aspects of using a tape recorder during the interview are that no information gets lost and
the information can be analyzed in different ways (Hageback, 2002).
18
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
6.2.3.2 Guidelines for constructing questions
According to Hageback (2002) there are some guidelines that could be used while
constructing interview questions to ensure a better interview result. During this project these
guidelines have been used. Those guidelines are available in (Hageback, 2002).
6.2.3.3 Guidelines for performing an interview
According to Hageback (2002) a couple of guidelines regarding interview technique should be
followed. A couple of these are for example that it is important to introduce yourself and the
project, to not interrupt the respondent and to remember the purpose and focus on the
subject. More guidelines are available in (Hageback, 2002).
6.3 QFD
The QFD is a method that is organized to develop the major pieces of information necessary
to understanding the Engineering Specifications and problem. The positive effects of
performing a QFD are (Ullman 2010 s. 145-147):
―
―
―
―
―
Hears the voice of the customers.
Develops the specifications or goals for the product.
Finds out how the specifications measure the customers’ desires.
Determines how well competitions meet the goals.
Develops numerical targets to work
toward.
By using the QFD method it builds the
House of Quality, see Figure 3, The House
of Quality. The House of Quality is a
diagram that consists of many rooms, each
containing valuable information.
Step 1, Who, stands for who the customers
are, what describes what the product
should do, step 2 determines who versus
what, step 3 identifies how the problem is
solved now (what competitions the product
has). Now versus what shows the
information compared to what the
customer desire, this find out where there
are opportunities for an improved product.
Figure 3, The House of Quality (Ullman 2010 s. 147)
Step 5, how, determines how to measure the product’s ability to satisfy the customer’s
requirements. The correlation between the engineering specifications and the customer’s
requirements is given by what versus how. Step 8, how versus how, shows the
interrelationship between the engineering specifications. The QFD method is mostly suitable
for collecting functional requirements (Ullman 2010 s. 145-148).
6.4 Function Analysis
All products have a reason to be developed, a purpose to fulfil. When a product is developed
there are some important things that need to be considered (Österlin, 2007, p.42);
19
Mälardalen Univeristy
Malin Bånghammar & Marie Norling




2012-06-08
Why the product exist
Main purpose
Central idea
How it can be done
The reason why the product exists is called the Main Function. The function that cooperates
with a higher function is called Sub Function and if one of the sub functions is removed the
higher function is not fulfilled. There is also one function that is called the support function
and this function is supporting a superior function but the support function is not necessary.
All functions should be expressed with one verb and one substantive (Österlin, 2007, pp. 4243).
Together all functions are formatting a hierarchy which can be illustrated by a tree structure,
see Figure 4, The function tree. This tree structure answers two the questions “why” and
“how”. The main function at the top answers to the questions “why” and the functions at the
bottom answers the “how” questions (Österlin, 2007, p. 43).
Why?
How?
Main
function
Sub function A
Sub function B
Support
function
Figure 4, The function tree (Österlin, 2007, p. 43)
6.5 Design Process
The Design Process considers how to create new products that turns into a success. The
success means that the product turns into profit and benefits society in some way. The
Design Process contains events and guidelines to define a clear starting point. This starting
point should help the designer from visualizing a product to realizing the product in real life.
This should be done without constraining the creative process (Haik and Shahin, 2010, p. 8).
6.5.1 Concept Generation
In many companies, about 15 percent of the design developing time is spent on Concept
Generation. A concept can be represented in many ways; it can for example be represented
in a sketch, calculations and textual notes. The key point of a concept is to represent enough
detail so that the functionality can be ensured.
“If you generate on idea, it is probably a poor one. If you generate twenty ideas,
you may have a good one.”
(Ullman, 2010, p. 172)
20
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
There are different methods that can be used to generate concepts.. Using different methods
can help to solve a specific problem. One of the methods is called brainstorming and it is a
proven technique when new ideas are needed (Ullman, 2010, pp. 189-190).
6.5.1.1 Brainstorming
Brainstorming is a good method to use when new ideas are needed. The method is especially
useful in teams because then each member’s ideas will trigger ideas from the other team
members because each ideas are from his or hers own viewpoint. There are a few simple
rules that need to be considered when performing a brainstorming (Ullman, 2010, p. 190);
1. All generated ideas should be recorded. In the beginning a secretary should
be appointed, that person shall also be a contributor.
2. First generate as many ideas as possible, then verbalize them.
3. Think wild. Ridiculous, impossible ideas may lead to useful ideas.
4. Do not allow evaluation of the ideas during the generation. It is important
to ignore any evaluation, judgment, or other comments on the value of an
idea.
The brainstorming session should preferable be focused on a specific function and it is also
important to encourage humour during the brainstorm session (Ullman, 2010, p. 190).
6.5.2 Concept evaluation
In the concept evaluation phase in this project a couple of techniques for choosing the best
concepts have been used. Those techniques are presented below.
“The goal is to expend the least amount of resources on deciding which
concepts have the highest potential for becoming a quality product.”
(Ullman, 2010, p. 213)
6.5.2.1 PUGH Concept Selection
The PUGH Concept Selection helps to narrow down the number of concepts quickly and it
can also improve the concepts (Eppinger and Ulrich, 2008, p. 130).
While performing a PUGH Concept Selection the concepts are rated in order to compare the
concept to the reference. The comparisons are executed in order to see how the concepts
meet the demanded criteria’s. The demands are also weighted with a number between one
and five where five stands for high importance. A scale of better than reference, same as
reference and worse than reference could be used to rate the concept, if the concept doesn’t
need a finer scale. If the concept needs additional resolution to distinguish the concepts a
finer scale can be used (Eppinger and Ulrich, 2008, pp. 131-135). The scale used in this
Master Thesis is illustrated in Table 1, PUGH score explanation and the principles of a PUGH
Concept Selection can be seen in Table 2, The principle of PUGH concept selection.
21
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Score explanation
2
Much better than reference
1
Better than reference
0
Equal as reference
-1
Worse than reference
-2
Much worse than reference
Table 1, PUGH score explanation
Demands
Demand 1
Weight
3
Reference
0
Concept 1
1
Concept 2
0
Demand 2
4
0
0
1
Demand 3
2
0
-1
1
+1
+6
Sum
Table 2, The principle of PUGH concept selection
6.5.2.2 FMEA
FMEA stands for Failure Modes and Effects Analysis which implicate a systematic review of a
product or process, its function, failure mode, failure cause and failure effects. The FMEA is a
very useful tool for reliability analysis. An FMEA is often used to analyze the relation between
components failure mode and the correspondent failure effects. It also analyzes what
arrangements that need to be taken to prevent failure and how to reduce the failure effects
(Bergman and Klefsjö, 2002 pp. 113-114).
The result of this analysis is presented in the form of a FMEA-document. The configuration of
this document can vary depending on the purpose of the analysis (Bergman and Klefsjö, 2002
pp. 113-114).
6.6 Summary – Theoretical Background & Solution Methods
To make sure that this project was following the time plan a detailed Project Plan in the form
of a Gantt Chart was established and followed. Certain predetermined project gates were
also used to help the project to move forward continuously.
The Theoretical Background of this project is built on a couple of Scientific Methods.
Considering the information gathering methods those methods were for example a
Literature Review and a specific Interview Method. Also methods for Problem Understanding
and the Design Process were used. Those methods are QFD, Function Analysis,
Brainstorming, PUGH Concept Selection and FMEA.
22
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
7. Applied Solution Procedures
In this chapter the information gained using the scientific methods are described. The
scientific methods that have been used are Literature Review and Interview Method. The
information gained considering ABB FACTS is also described within this chapter. After the
presentation of the Information Gathering section the Design Phase is presented. The Design
Phase is divided into the five areas that are developed during this Master Thesis. These areas
are Responsibility Chart, Responsibility Role, Type of Review, Review Record and User Guide.
7.1 Project Planning – Gantt Chart
It is important to have a well prepared Project Plan when working in projects. A Gantt Chart,
presented in Appendix 3 – Gantt Chart, was established in the beginning of this Master
Thesis. This tool was used to visualize the work process and to show which task that has to be
executed before another task. This Gantt Chart was also used to be able to construct a
detailed Time Plan.
Within this Gantt Chart the five Gates are placed to illustrate which week the gate shall be
completed and which task that are included in the gate.
7.2 Information Gathering
The Scientific Methods that have been used to gather information during this Master Thesis
are a Literature Review and a specific Interview Method. The output from these methods has
brought information about the company and a lot of other information that was helpful for
this project. This information is available in the following sections.
7.2.1 Literature Review
Within the Information Gathering Phase a scientific Literature Review was performed. The
literature that was considered in this Master Thesis mostly regarded information about
processes, Stage-Gate, Cross Functional Project Teams, Roles and Responsibility,
Responsibility Charts and ISO 9001. The result from the Information Gathering Phase can be
found under each Sub Heading below.
7.2.1.1 Process
According to Bergman & Klefsjö a process can be described as:
“A coherent set of activities that are repeated in time”
(Bergman and Klefsjö, 2002, p. 38)
The work that is executed in an organization is usually a process and the goal for the process
is usually to satisfy customers. The goal for a process can also be to gain an end result where
the use of recourses is the least as possible (Bergman and Klefsjö, 2002, P. 38).
The Product- and Manufacturing Process are very complex and therefore different groups of
people are responsible for different areas. These areas are for example marketing, design,
manufacturing and overall management (Ullman, 2010, p. 8).
23
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
The Product Development Process has a structured flow of information and activities and
therefore a process flow diagram can illustrate the process. To develop for example marketpull, platforms and high-risk products a generic process is used. The Generic Product
Development Process is illustrated in Figure 5, The Generic Product Development Process.
Each stage in the process is followed by a gate to confirm that the stage is completed and to
determine whether the project shall proceed or not (Eppinger and Ulrich, 2008, p. 22).
Figure 5, The Generic Product Development Process (Eppinger and Ulrich, 2008, p. 22)
7.2.1.2
Stage-Gate TM Process
The Stage-Gate Process can be seen as a blueprint to manage the product innovation and be
able to improve the effectiveness. The Stage-Gate Process breaks the project into typically
four, five or six stages and they are discrete and identifiable. The stages are designed to
gather information needed to be able to bring the project into the next gate or decision
point. Before every stage there is a gate which control quality and go/kill checkpoints for the
process (Cooper, 2001, pp. 129-130).
The Stage-Gate model is illustrated in Figure 6, Stage-Gate TM Model – From Discovery to
Launch (Cooper, 2001, p. 130). Further information about the Stage-Gate Model is available
in Winning at New Products, accelerating the process from idea to launch by R. G. Cooper.
Figure 6, Stage-Gate TM Model – From Discovery to Launch (Cooper, 2001, p. 130)
7.2.1.3 Cross-Functional Project Teams
Within new product development the increased use of cross-functional project team is
related to a higher project success (McDonough III, 2000). McDonough performed a
reliability analysis with the question “What was the primary reason for moving to the crossfunctional team approach?” The result showed that the reason depended on the
performance outcome and process improvement. The performance outcome reasons were
for example to improve the quality of new products developed and to be on-target in
schedule. The Process improvement reason was for example to get an improved process to
develop new products (McDonough III, 2000).
24
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
The Stage-Gate Processes consist of a project team that is cross-functional. The project
members come from different departments like marketing, engineering, R&D and
operations. The team differs from time to time as the project requirements demand. But
some of the project members are present in the project from the beginning to the end just to
ensure the responsibility and commitment (Cooper, 2001, pp. 118-120).
7.2.1.4 Roles, Responsibilities and Authority
A common way of defining people’s responsibility and authority are by procedures, it specify
individual actions and decisions. It is at the level of procedures that one can be specific about
what a person’s tasks are and what result they are responsible for. A procedure often
describes tasks rather than objectives and the procedures should contain role titles or
position instead of names of individuals. The reason to the last mentioned is that the person
who has the role title will inevitably change. Then the persons only have to know their
position or roles (Davis 1997, pp. 276-277).
One very important task is to define the different roles of the Team Members. The roles
should be clearly defined so that the Project Management and all Project Team Members in
the project are aware what is expected from them. This is also important in order to
determine the responsibilities and boundaries of the authority (Antvik and Sjöholm, 2007, p.
28).
Job Descriptions or Job Profiles that describe the responsibilities that a person has are useful.
Those descriptions that are produced for job evaluation may be used in the management
system. If they are produced for that purpose the objectives people, that are responsible for
achieving and the decision that they are authorized to make, should be specified (Davis 1997,
p. 276).
It is necessary to define who should do what in a project or else thus tasks that are
unattractive will be left undone. Therefore the authority and assignment of responsibilities
needs to be delegated by the management (Davis 1997, pp. 272-273).
Responsibility and authority goes hand in hand and it is not possible for a person to only have
one of those. If these two are not matched, responsibility or authority is greater than the
other one, problem arises (Davis 1997, p. 272).
One way of defining responsibility and authority that has become more and more popular
are with Flow Charts. The Flow Chart illustrates the job titles and the assigning they have
regarding actions and decision. It also shows in a clear way that anyone with the indicated
title has the responsibility to perform an action or decision described in the shape. The Flow
Chart may consist of colour codes in order to make global changes less tedious when there is
a change in job titles. Organization projects differ and some undertake projects rather than
operate continuous with processes or production lines. The organizations that undertake
projects have a need to define and document project-related responsibility and authority,
this are often temporary to the project. Project Organization Charts and Project Job
Descriptions for each role are necessary to define the responsibility, authority and
interrelationship for the project organization. Project structures are temporary and therefore
a system that controls the interfaces between the line function and the project team is
needed. According to Davis such a system would for example include (Davis 1997, p. 277):

Job description for each role stating responsibilities, authority and
accountability
25
Mälardalen Univeristy
Malin Bånghammar & Marie Norling





2012-06-08
Procedures that identified the roles responsible for each task and for
ensuring that information in conveyed to and from these staff at the
appropriate time
Procedures that consolidate information from several disciplines for
transmission to the customer when required
Monitoring procedures to track progress and performance
Procedures that ensure the participation of all parties in decisions affecting
the product, its development and production
Procedure for setting priorities and securing commitment
Responsibility Charts
One way of displaying roles and responsibilities in a project is by using Responsibility Charts.
Those charts can be called different names such as RACI, Linear Responsibility Chart or
Responsibility Matrix but they are all a way of showing the different responsibilities a role
has. These charts are especially useful in Cross-Functional Project Teams (Cornelius-Fichtner,
2012-04-20).
A Responsibility Chart is helpful to show what role that is responsible for each task and it
also shows critical interfaces between units. This can require special managerial
coordination. To manage to construct a Linear Responsibility Chart all personnel and
organizational responsibility for each task must be listed. The Linear Responsibility Chart is
illustrated in Figure 7, Linear Responsibility Chart. A simplified Linear Responsibility Chart can
be used if the project is not too complicated, se Figure 8, Simplified Linear Responsibility
Chart. (Mantel and Meredith, 2010, p. 263)
It is important that the Project Manager identify the roles and responsibilities early in a
project. The RACI Chart, see Figure 9, Example of RACI Chart, could be helpful to manage that
and it also helps avoiding confusedness over the roles and responsibilities during a project.
Projects easily run into troubles without clearly defined roles and responsibilities. When the
roles and responsibilities are clearly defined and everyone knows exactly what is expected it
leads to benefits for the project. The benefits can for example be that it is easier to complete
the work on time, to the right level of quality and within the budget (Haughey, 2011). Figure
9, Example of RACI Chart, shows a RACI Chart where the letters represents which role that
has the responsibility, accountability, which will be consulted and informed for each task. All
projects roles and tasks involved in delivering a project should be identified and listed in this
chart (Haughey, 2011). A couple of ways of presenting roles and responsibilities are
presented in the different charts below.
Figure 7, Linear Responsibility Chart (Mantel and Meredith, 2010, p 263).
26
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Legend:
▲ Responsible
● Support
■
○
Notification
Approval
The numbers in the Simplified Linear Responsibility chart stands for;
1. Actual responsibility
2. General supervision
3. Must be consulted
4. May be consulted
5. Must be notified
6. Final approval
Figure 8, Simplified Linear Responsibility Chart (Mantel and Meredith, 2010, p. 264).
According to Haughey (2011) the acronym RACI stands for:
Responsible (R): “The person who does the work to achieve the task. They have responsibility
for getting the work done or decision made. As a rule this is one person; examples might be a
business analyst, application developer or technical architect.”
Accountable (A): “The person who is accountable for the correct and through completion of
the task. This must be one person and is often the project executive or project sponsor. This is
the role that responsible is accountable to and approves their work.”
Consulted (C): “The people who provide information for the project and with whom there is
two-way communication. This is usually several people, often subject matter experts.”
Informed (I): “The people who provide information for the project and with whom there is
one-way communication. There are people that are affected by the outcome of the tasks so
need to be kept up-to-date.”
(Haughey, 2011)
27
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Figure 9, Example of RACI Chart (Haughey, 2011)
RACI is also available in other versions like RASCI, RACIO and RACI-VS. The S in RASCI stands
for Support, the O in RACIO stands for Out of the loop or Omitted and the VS in RACI-VS
stands for Verify and Signatory (Haughey, 2011).
7.2.1.5 ISO 9001
ISO 9001 is a standard that require an organization to establish a Quality Management
System. By following those requirements it will provide the management system with the
capability to supply products and services that satisfy the organization’s customers.
Control of documents
ISO 9001 requires that certain documents need to be controlled. According to David Hoyle
the documentation of documents is necessary to ensure that (Hoyle 2006, p. 190):








“Documents fulfil a useful purpose in the organization”
“Resources are not wasted in the distribution of non-essential information”
“Only valid information is used in the organization’s processes”
“People have access to appropriate information for them to perform their
work”
“Information is kept up to date”
“Information is in a form that can be used by all relevant people”
“Classified information is restricted only to those with a need to know”
“Information is important to the investigation of problems; improvement
opportunities or potential litigation are retained”
Document control procedures
This standard requires that a document procedure will be established to define the controls
needed. This means that various activities required to control different types of documents
should be defined and documented (Hoyle 2006, p. 191-192).
The purpose of documentation of documents is to ensure that appropriate information is
available wherever needed and secondly to prevent the unintentional use of invalid
information. It is in the process descriptions that documents that need to be controlled are
defined. Documents that not are referred to the Process Description are not required to be
28
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
controlled though they are not essential for the quality achievement. Procedures that require
use or preparation of documents should also have specified procedures for their control. It is
possible to produce one or more common procedures that concern the control and that
apply to all documents. Depending on document type, organizations involved, approval,
publication and use the stages in the process may differ. Therefore several control
procedures may be needed (Hoyle 2006, p. 192).
The document control procedures should consider information as; planning of new
documents, preparation of documents, standards for formats and content, identification,
review and approval, revision of issued documents, document maintenance and document
storage. The complete list is available in (Hoyle 2006, p. 192-193):
The above features may not be separately prescribed if the documents are electronically
stored. If so, the document database may perform many of these features automatically
(Hoyle 2006, p. 193).
Document review
A review can be described as another look at something and can be responded to the
Continual Improvement Principle. Reviews are necessary when taking remedial action,
preventing errors, taking preventive actions and taking maintenance action. Review is also
necessary for validation of documents in use and taking improvement action. Reviews can be
either periodic or random. Random reviews arise from an error or a change that is either
planned or unplanned. Periodic reviews check the policies, processes, products, procedures,
specification etc. for continued suitability and could for example be scheduled once a year
(Hoyle 2006, p. 197-198).
Document approval
Before documents are made available for use they have to be approved prior to issue by
designated authorities. This means that that the document has to be judged to make sure it
fit the intended purpose. This has to be done before the document is distributed or
published. Document approval is necessary because it ensures that the documents in use
have been judged by authorized personnel. It also prevent that unapproved documents are
in circulation causing errors from using invalid documents (Hoyle 2006, p. 194).
Revision of documents
An update of a document should be followed of a review. This procedure responds to the
Continual Improvement Principle. There are a number of key stages for changing documents
that should be followed (Hoyle 2006, p. 198-199):









Identification of need
Request for change
Permission to change
Revision of document
Recording the change
Review of the change
Approval of the change
Issue of change instructions
Issue of revised document
Some of these stages are not addressed in ISO 9001.
29
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Identifying the change
ISO 9001 requires that changes to documents are identified. That is necessary because it
should be possible to find what has been changed in a document following its revision (Hoyle
2006, p. 202-203).
The benefits of identifying changes are (Hoyle 2006, p. 203):




Approval authorities are able to identify what has changed and therefore
speed up the approval process.
Users are able to identify what has changed and therefore speed up the
implementation process
Auditors are able to identify what has changed and therefore focus on the
new provisions more easily
Change initiators are able to identify what has changed and therefore verify
whether their proposed changes were implemented as intended.
Identify changes to documents can be done in several ways. First of all it can be done by
sidelining, underlining, emboldening or with similar techniques. It is also possible to identify
changed documents by changing records within the document (front or back) denoting the
nature of change. A separate change note with details about what has changed and why is
also an alternative (Hoyle 2006, p. 203).
Identifying the current revision of documents
ISO 9001 requires that the current revision status of documents can be identified. It is
important that when a document is revised its status changes to signify that it are no longer
identical to the original version. To indicate the status of a document date, letters or
numbers can be used. It is important that every change to a document revises the revise
index (Hoyle 2006, p. 204).
The identification of current revision of documents its necessary because then planners can
indicate the version that is to be used and also that users are able to clearly establish which
version they are using or which version they require (Hoyle 2006, p. 204).
Reapproving documents after change
The ISO 9000 standard requires that documents need to be reapproved after revision. If the
original document has been subject to approval prior to issue then any changes should also
be subject to approval prior to issue of the revised version. The approval does not have to be
by the same people that approved the original the main thing is that the approvers are
authorized (Hoyle 2006, p. 206).
7.2.2 Company insight
This Master Thesis has been carried out at the Research and Development Department at
ABB FACTS. To be able to accomplish a good and satisfying result a lot of information
regarding the company and its current processes has been collected. The following section
considers that information.
7.2.2.1 ABB FACTS Organization
The entire ABB and therefore also ABB FACTS are working in a matrix structure. In this matrix
structure requirements are placed on each manager. As far as possible in a given situation,
30
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
those requirements aim to consult and inform about measures and decisions that interfere
with other functions or projects within FACTS and ABB (ABB-document2, 2011).
ABB FACTS is divided into several departments. These departments work with different areas
in the development process. The Organizational Chart for ABB FACTS is shown in Appendix 4
– Organizational Chart (ABB-document1, 2011). The concerned departments are described
below.
Operational Excellence
The Operational Excellence responsibility is to act as a support to the different processes at
FACTS. All FACTS activities should follow the ABB FACTS standards ABB-document2, 2011).
Operations
The Operations/Project Support department is dealing with Operational Purchasing and
other related processes. The responsibilities of this department include ensuring that
efficient processes are implemented related to the business system, issuing request to
purchase, purchase orders, SOX requirements, adding/deleting suppliers in the business
system and Suppliers List and also follow up of suppliers performance (ABB-document2,
2011).
Plant Design and Construction
Plant Design and Construction is divided into sub departments. The departments that are
relevant for this Master Thesis are Electrical Design and Plant Design.
The Electrical Design Department is responsible for the electrical plant design, including the
purchasing of equipment for protection relay and control systems, auxiliary power systems,
communication equipment and control cables. This department is also responsible for
programming some of the protection relays.
The Plant Design Department is responsible for electromechanical plant design including the
purchasing of switchgear material, power cables and container buildings (ABB-document3,
2011).
Research and Development
The R&D department has the responsible to drive the technology and product development
activities at FACTS to develop new products for FACTS global market. The responsibilities are
also to drive FACTS intellectual Property work and compiling and regularly updating the
strategic R&D plan for FACTS (ABB-inside3).
This department is carried out in a project form according to the Gate model. It is
department R that has the overall responsible and that coordinates the R&D projects (ABBdocument3, 2011).
The R department is divided into three minor departments – RP, RT and RH. The RP stands
for R&D projects and this group is responsible to manage the R&D projects. Developing the
best practices and procedure for managing R&D projects within FACTS are also included in
the RPs responsibility. R&D Technology, RT, is responsible for developing and maintaining
expertise within power systems, power electronic system, control algorithms and software.
This group is also responsible for contributing to the concept design of new solutions in the
R&D Projects. R&D Hardware, RH, has the same responsible as RT but within the areas of
mechanical and electrical design of plants, power electronics design and hardware. Both RT
31
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
and RH have a group composed of R&D engineers and specialists within the area (ABBinside3).
Technology
This department is divided into sub departments but those departments who are involved in
this Master Thesis are System Design and Control System Integration.
The System Design Department is responsible for designing a technical system solution,
based on the customers’ requirements or problem. This solution is for the primary system
with associated system studies. Another responsibility for System Design is the production
and documentation of the control, regulation and protection relay systems.
The Control System Integration Department is responsible for system development,
programming and testing of control and protection relay equipment, including the operator
interface and any communication to superior systems (ABB-document3, 2011).
7.2.2.2 FACTS R&D Processes
ABB FACTS has currently almost no established processes for their R&D projects. Therefore a
VU-team is currently working to develop these processes. A Process Map describing the R&D
process containing milestones is under construction. The Process Map is supposed to
illustrate all milestones that are necessary to perform to be able to complete each gate.
The Process Map shall be used as a presentation material to be able to visualize the R&D
Process. The Process Map is not supposed to be used as a tool during the project.
Figure 10, R&D Project – Design Proposal Phase (ABB-document15)
32
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
The Design Proposal Phase in the R&D Process is presented in Figure 10, R&D Project –
Design Proposal Phase. The white bubbles are the deliverables that are supposed to be
produced during the gate. The arrows are supposed to show which deliveries are depended
on the previous deliverables.
The ABB FACTS R&D Process is following the Stage- Gate Model and the process is illustrated
in Figure 10, Phases of the R&D Process. This process is supposed to have a Concept
Development Phase between gate 0 and gate 2 and a Productisation phase between gate 2
and gate 5. During the first phase of the R&D Process the R department is working with the
R&D project with 100 percent effort but in the second part the process department R’s
involvedness should decrease. In the second part of the process the T & D departments step
in and work with 100 percent effort. In the first phase the T & D departments are supposed
to act as a support to the R department and in the second phase it is the other way around.
During the whole project the R&D Project Leader are working with the project.
In the Concept Development phase the R department has the responsibility to develop the
document needed to pass gate 2. The R department should also have the responsibility to
approve these documents. In the Productisation phase it is important that the T and D
departments are approving the document that shall be used for delivery projects in the
future.
Figure 11, Phases of the R&D Process
Between G0 and G2 the R&D Project Manager and the other Team Members work together
in a group to reach the goals. In the Productisation phase the R&D Project Manager from the
R department leads the other departments. This structure is presented in Figure 12, Project
Structure G2-.
33
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Figure 12, Project Structure G2-
7.2.2.3 The ABB Gate Model
The ABB Gate Model is a model for Technology-, Product and System Development. This
decision model can be applied to all technology, product and system development projects
within ABB. The ABB Gate Model is used to help the organization to ensure that all the
aspects about system/products are ready for release and also to get control over the project
(ABB-document5, 2012).
ABB Gate Model has eight gates and every gate is a decision point. The Gate owner evaluates
the project and the projects result from a business point of view, in the decision points. The
Gate Owner also determines if the projects should continue. If the decision is to continue
some changes can be done in the project scope or plan. The decisions that are taken during
the Gate Meetings are documented by the R&D Project Manager. These documents should
thereafter be approved by the Gate Owner (ABB-document5, 2012).
Description of gates
The ABB Gate Model consists of eight different gates. These gates are (ABB-document5,
2012):
Gate 0 – Agreement to Start
In this gate the project is started as a result from the product planning process which
includes for example pre-studies. The product planning process provides input to a
recommendation to start the project and inputs to the gate 0 meeting. The organization can
choose to have a pre-study before gate 0 or include it between gate 0 and gate 2 (ABBdocument5, 2012).
The gate 0 meeting results in a decision to execute the project study, change the scope or not
to start the project. Also a project manager and a steering committee are appointed,
recourses are allocated and decision about gate 1 and gate 2 are taken (ABB-document5,
2012).
Gate 1 – Agreement on Scope
Before Gate 1 a requirement specification is prepared and the Gate Owner summons a Gate
1 meeting when an agreement has been done about what requirements are needed to give
the highest value in relation to the development effort within the given time frame. In Gate 1
also an investigation about what time to market and the product cost to meet the market
requirements is performed (ABB-document5, 2012).
The goal of this gate is to obtain the agreement on the project scope. The Gate 1 meetings
results in a decision whether to start planning the project or if the project needs to be
terminated (ABB-document5, 2012).
34
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Gate 2 – Agreement to Start Project Execution
The goal of this gate is to obtain an agreement of the project plan and the feasibility of
implementing the requirements using the selected technology. The Gate Owner summons to
a Gate 2 Meeting when the requirements allocated to the project is stable and when the
project plan is ready. The Gate 2 Meeting should result in a decision whether to continue to
execute the project after the requirement specification, selected product concept, the
project description and the project plan. The target dates are set for the remaining gates if
the decision is continue (ABB-document5, 2012).
From now on all approved document should be considered to be under a formal change
control (ABB-document5, 2012).
Gate 3 – Confirm Execution
The goal in this gate is to confirm the project goal and the project plans. The Gate 3 Meeting
is summon when some of the design are decided, at this point all detail design do not need
to be completed. The Gate 3 Meeting will result in a decision whether to terminate the
project or not (ABB-document5, 2012).
Gate 4 – Agreement on Reading for Introduction
The Gate 4 Meeting goals are to ensure that the targeted functionality and release date are
confirmed. The goal is also to ensure that the production introduction activities can start at
full scale. When the implementation is complete, when the product has passed the product
verification with a successful result and when the release date can be confirmed the Gate
Owner summons a Gate 4 Meeting. The main decision of this gate meeting is if the project
should be terminated or if the introduction should start (ABB-document5, 2012).
Gate 5 – Release / Handover
When the validation of the product is complete and all the preparations are done for the
release the Gate Owner summons to a meeting. During this meeting it should be ensured
that the product has been validated for compliance with the requirements and also that the
organization is ready for this new product (ABB-document5, 2012).
After this meeting a result whether the product is going to be released or if it needs to be
terminated is taken (ABB-document5, 2012).
Gate 6 – Close project
At this gate the project is completed and the goal is to confirm that the organizations have
received all deliveries and to close the project. The Gate 6 Meeting is summoned by the Gate
Owner when the project is completed and during the meeting a decision regarding the closer
of the project is taken (ABB-document5, 2012).
Gate 7 – Capture return on investment
The goal for this gate is to investigate the result of the project. It investigates if the results
fulfill the promised, how the product fit the market, if the product meets the goals related to
ABB and the customer (ABB-document5, 2012).
The result of the Gate 7 meeting is to get feedback from the project. The feedback should be
used to improve the development processes and for considerations about the future of the
product (ABB-document5, 2012).
35
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
7.2.2.4 Roles and Responsibilities – ABB FACTS
In a R&D Project there are people from several departments cooperating. To be able to
develop a satisfying Review and Approval Process it is important to define what kinds of
Project Roles these departments contribute the R&D Projects with. After a couple of
discussions with different departments it was understood that it would be preferable if the
different departments had similar roles and Role Descriptions, especially the technical
departments. This would decrease the confusedness regarding roles in the R&D Projects
though all project members would already be familiar with the terms.
One of the technical departments had recently produced a document defining what roles are
present at that department. The corresponding responsibility for every role was also
described. It was decided that this document should be used as a reference during the
further discussions together with the other departments. The goal was trying to create a set
of general roles that are applicable at most of the departments, especially the technical
departments.
After interviews and discussions with several departments it turned out that all of those
defined roles were not necessary at all departments. Especially the Component Responsible
role did not suit the other departments; therefore this role is only listed at the System Design
Department. It was also some difficulties trying to apply those roles to the Control System
Department. Due to the fact that this department is working with software development it
needs other types of specified roles, roles that are more adapted for software development.
Therefore the Control System Department got to keep some of their own already defined
roles.
The following roles are roles that have been accepted by the different departments, see
Table 3, Defined Project Roles related to each department.
DE




DF
 Project Responsible
Project Responsible
Design Area Responsible
Competence Owner
Tool Owner
DM





M



Project Responsible
Design Area Responsible
Competence Owner
Simulation Model Responsible
Tool Owner
O




Project Responsible
Competence Owner
Tool Owner
P


Project Responsible
CM Responsible
User Documentation
Training Responsible
36
Product Manager
Quality Assessor
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
R





S

R&D Project manager
Design Area Responsible
Competence Owner
Test Responsible
IP Coordinator
TA


TC






Service and Support Responsible
Spare Part and Repair Responsible
TS







Project Responsible
Project Responsible
Design Area Responsible
Base Software Architect
System Architect
Tool owner
Configuration Manager
Additional Roles





Project Responsible
Design Area Responsible
Component Responsible
Competence Owner
Simulation Model Responsible
Tool Owner
Configuration Responsible, Tools
Business Unit Manager
Department Manager
STECO Member
Gate Assessor
Gate Owner
Table 3, Defined Project Roles related to each department
Those roles that have existing Role Descriptions are described below.
Competence Owner
The Competence Owner has expertise within a specific area and the purpose with this Project
Role is to build expertise necessary to support the organization. The duties that the
Competence Owner has consists for example of manage the relevant base documents and
instructions and identify and propose necessary actions to ensure a competitive solutions
within the area of expertise (ABB-document11, 2012).
Component Responsible
At the TS Department the Component Responsible shall promote the knowledge of main
circuit components, to support the FACTS employees with expertise and to be a contact
towards the sub suppliers. The Component Responsible is responsible to be informed about
relevant standards and internal design rules. This role has duties which consist for example of
managing the relevant base documents and witness type tests and support the Project
Responsible/Design Area Responsible with review of test records (ABB-document11, 2012).
Configuration Manager
At the TC department the Configuration Manager is responsible for the CM tool and also
builds all formal baselines, release revisions and project upgrades. It is also the only role
privileged to create new branches and merge branches (ABB Document13, 2010).
37
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Design Area Responsible
The Design Area Responsible is responsible for a specific task in a project. This Project Role
has the responsibility to be informed about the budget and delivery date. The scope of work
that the Design Area Responsibility has is for example to perform the task including
documentation, initiation of review process and possible revisions, re-work and archiving.
The Design Area Responsible is also responsible to make sure that the work is performed,
reviewed and documented. This shall be done according to instruction, guidelines and
handbooks. The Project Role responsibility also includes documenting the DRM with a
protocol (ABB-document11, 2012).
Gate Assessor
The Gate Assessor role in the Gate decision process regards providing a neutral opinion in
order to further enhance the quality of the facts to underlay the gate decision. The
responsibilities are for example to review the gate decision material with the Project
Manager together with the stakeholders, to participate at the Gate Meetings and also to
present decision recommendations (ABB-document5, 2012).
Gate Owner
The role for the Gate Owner is to drive decisions based on relevant facts and by involving key
stakeholders. The decisions should be in the interest for ABB and the customer. The
responsibilities for the Gate Owner are for example to lead the Gate Meetings and the
decision taking (ABB-document5, 2012).
Project Manager
The role for a project Manager is to professionally manage the projects in ABB for the
customer’s interest. The responsibilities for the Project Manager in Gate Decision Process
are for example to communicate the decision taken to all relevant stakeholders and also to
invite to Gate Meetings (ABB-document5, 2012).
Project Responsible
The Project Responsible refers to the engineer who has been delegated the overall
responsibility of a specific project by the manager. The Project Responsible has the
responsibility to perform the task but also to follow up the cost and time schedule. The
overall responsibility always remains with the Project Responsible even if the specific task is
delegated to a Design Area Responsible (ABB-document11, 2012).
Simulation Model Responsible
The Simulation Model Responsible is responsible for specific application models and for
specific simulation tools. The duties that this Project Role has are for example to ensure that
new functions developed for a specific project are documented and stored in such a way that
they can be reused (ABB-document11, 2012).
Technical Responsible Control Software
The Technical Responsible Control Software is responsible to ensure that there is always base
application available and the scope and quality of this base application must meet internal
and external needs. The duties that this role has are for example to maintain the robustness
and usefulness of the base application and design, implement and test base functions that
can easily be adapted for projects (ABB-document12, 2011).
38
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Tool Owner
The Tool Owner is the owner of a design or a simulation tool. For example the Tool Owner is
responsible for monitoring the existing licenses and identify need for more or less licenses to
ensure that the number and cost for licenses is optimized (ABB-document11, 2012).
Quality Assessor
The Quality Assessor is a Project Role that department P wants to include in the R&D
Projects. This Project Role shall be responsible to ensure the quality. The information
regarding the Quality Assessor came up during a discussion with the department P.
Steering Committee
The purpose of the Steering Committee is to deliberate and coordinate the Insurance and
Risk Management (ABB-inside2, 2011). The Steering Committee supports the Project
Manager during the phases between the Gates. The responsibilities that the Steering
Committee has are for example to provide with resources and support concerning time
schedule (ABB-document5, 2012).
The Steering Committee summons a meeting whenever it is necessary but the sessions
should be at least twice per year. During these sessions MoM will be recorded (ABB-inside2,
2011).
7.2.2.5
Review and Approval Process – ABB FACTS
The following section considers information regarding the Review and Approval process at
ABB FACTS. The information is gained from both internal material and interviews. The
interviews are divided into two paragraphs; the Review and Approval Process regarding the
Delivery Projects and the other one regarding the R&D Projects.
Review and Approval Process - Documented Information at ABB FACTS
A general rule regarding the review and approval is that each document shall be reviewed
and approved by at least one person besides the Author. The review and approval shall be
made in eCM and instructions and guidelines for ABB FACTS staff shall normally be approved
by the Function Manager or the Superior (ABB-document7, 2010).
The person that has the authority to review and approve documents is defined by each
function in separate documents and shall also have relevant knowledge about the subject to
approve. Only documents that are in approved status and in the latest approved issue shall
be considered as valid. This rule is mandatory for documents that have or could have an
impact on ABB FACTS business performance or documents that are related to valid laws and
regulations (ABB-document7, 2010).
The reviewer has a responsibility to perform the technical verification of the reviewed
subject. A DRM Checklist should always be used if available due to it serves as a guideline for
the actual review and as a protocol of the review. When the review has been executed the
reviewer verifies the document by approving the checklist in eCM (ABB-document8, 2011).
The reviewing process must follow an established review process that need to be properly
documented. The responsibility of the approver on the other hand is to ensure that the
correct reviewing process has been followed during the review (ABB-document8, 2011).
If there only are minor changes necessary to a document the approver can determine that no
prior review is needed and therefore proceed with the approval (ABB-document8, 2011).
39
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Externally created project documents which are given ABB FACTS identity shall be approved
by a project member before issued. A review process may be required for this (ABBdocument7, 2010).
Documents that are created and approved in an engineering tool such as CAD Drawings can
be imported to eCM and put to approved status by the author/creator without a review
process in eCM (ABB-document7, 2010).
Documents with no impact on business performance are not governed by laws and
regulations or do not serve as an input to other ABB FACTS Functions may be put into
approved status or be left in draft status in eCM (ABB-document7, 2010).
Interviews – Current Review and Approval Process
To receive knowledge about the existing Reviewing and Approval Processes at ABB FACTS a
number of interviews were performed. To enable an overall picture regarding how the
Reviewing and Approval Processes is working at the moment, the respondents for these
interviews were from several different departments.
An inquire sheet was designed according to the guidelines from section 6.1.2 Interview
method to ensure a qualitative output from the interviews. This inquire sheet can be found in
Appendix 5 – Inquire Sheet.
To confirm the output from the interviews a second meeting with the respondents was
requested after the first round of interviews. The aims for these meetings were to coordinate
the result from the interviews together with the respondents and also to present how much
the Review and Approval Process differs between the departments. A couple of
complementing questions especially regarding the R&D Projects were also asked.
The participating departments for the interviews were; DE-Electrical Design, DM-Plant
Design, OS-Project Support, R-Research and Development, TC-Control System Integration and
TS-System Design.
A summary of the result from the interviews are presented below in Table 4, Interview
Summary – Delivery Projects, positive and negative and in Table 5, Interview Summary –
Development Projects, positive and negative. The interviews from each department can be
seen in Appendix 6 - Interviews.
Interview Summary- Delivery Projects
All departments that have participated in the interviews regarding the Reviewing and
Approval Processes for delivery projects are handling the processes in different ways. In
general all departments have a certain process for their reviewing and approval. One
department mentioned that the processes are working well in theory but that it is still up to
every person how well these processes are used. During these interviews it were mentioned
that some important steps in the Review and Approval Process may be skipped due to a tight
schedule.
Some departments mentioned that they are using DRM’s and some of them also use
checklists.
Some departments are working with different software’s which makes it impossible to
upload the working files to eCM. Therefore the departments who have this problem have a
40
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
different Review and Approval Process depending on which software that is used. This
problem is currently taken under consideration and will hopefully be solved in the future by
upgrading the Document Management System, eCM.
A general apprehension for the departments is that the documents that are produced during
a project shall be reviewed and approved before the documents are delivered to the
customer, supplier or to another department.
Mostly all of the departments mentioned that a role description regarding who has the right
to review or approve a document is missing. At some departments such descriptions are in
progress. There are also uncertainties concerning what it means and what responsibilities it
carries to review and approve a document. On which level a document should be reviewed
and what responsibilities the reviewer has are questions that need to be formalized.
A general apprehension is also that the processes for review and approval are important to
ensure a high quality.
Positive
Negative

DRM and Checklists are used by some
departments.

Departments are handling the
processes in different ways.

At some departments all documents and
their number can be found in a document
folder.

Important steps may be skipped
due to a tight schedule.

The review and approval are important to
ensure a high quality.

The most departments are
missing role description.

Uncertainties concerning what it
means to review and approve.
Table 4, Interview Summary – Delivery projects, positive and negative
Interview Summary- R&D projects
At the most of the concerned departments it seems to be a lot of confusedness regarding the
reviewing and approving processes in the R&D Projects. There are for example almost no
established processes describing how to handle this kind of processes. As a consequence of
this important decisions are not documented as they should and therefore these decisions
are neither reviewed nor approved. This is an issue that is pointed out by several
departments. Non documented decisions are a serious quality issue.
Another issue that is mentioned by a couple of departments is that the specifications in the
development projects are not sufficiently described. To be able to get a more exact
description of what to develop, what inputs that is needed and also to know when a project
is finished, some department wish to have more detailed specifications. These documents
should describe the project specifications, limitations and goals and it should also be
reviewed before it is delivered.
41
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
It has also been mentioned that the lack of resources in the R&D projects can be explained by
the unclear specifications. This is because it is difficult for a manager to commit resources
with unclear specifications.
Some departments have expressed a need for Role Descriptions in the R&D Projects. Today
this is something that is missing. A Time Plan containing clear review occasions is also
something that has been mentioned to be missing. It would also be preferable if the
documents that are supposed to be reviewed or approved were more specified.
One department expressed that the Review and Approval Processes often are performed too
late in the process, especially considering the approval processes. This causes a lot of stress
among the employees. Due to this it is important to reserve time for the Reviewing and
Approval Processes in the beginning of a process.
A couple of departments have mentioned that is not a hundred percent clear what it really
means to review and approve a document and that this is something that needs be specified.
According to some of the departments an overall description about how the Revision
Management should be handled would be very useful.
Positive

Negative
Preferable if the documents that are
supposed to be reviewed or approved
were more specified.

No established Review and Approval
Process

Important decisions are not
documented

Missing Role Descriptions

Missing Time Plan with clear review
occasions
Table 5, Interview Summary- Development Projects, positive and negative
7.2.2.6 Document Management System
ECM is an abbreviation for Enterprise Content Management and is a globally used tool within
ABB. Big parts of ABB is using this tool for their Document Management. ECM’s primary
mission is to facilitate global collaboration in projects between engineering centres, ensure
security and compliance and also to reduce infrastructure footprint (ABB-inside1).
“ECM tools and strategies allow the management of an organization’s
unstructured information, wherever that information exists”.
(ABB-inside1)
ECM has been selected as the Document Management System in three ABB divisions, which
mean it has around 7500 users in at least 20 countries (ABB-inside1).
42
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
The Document Life Cycle
The Document Life Cycle is illustrated in Figure 13, Document Life Cycle and is valid for all
document management and document publishing situations in general (ABB-document6,
2006).
Figure 13, Document Life Cycle (ABB-document6, 2006)
The establishing phase in a document life cycle is the part that is relevant for this Master
Thesis. The establishing part contains review, approval and release. The documents should go
through a check and approval within the responsible organization to assure the quality. In
many cases the quality assurance requires that the document shall go through a specified
process. These processes contain steps with review, approval and release which may include
several steps and vary in degree of strictness (ABB-document6, 2006).
Reviewing is the base for the approval. The approval signifies that the content has been
checked out and that it is correct. There are different kinds of processes for the approval that
can be applied depending on specific requirements. Both internal and external organizations
can be involved. In some cases there is no review or approval procedures used, instead the
author is responsible for both the approval and release (ABB-document6, 2006).
The approval process differs in order to follow a formal procedure or not. When there is no
formal approval procedure there are no requirements to follow any established rules for
review, approval and release. In this case the document is created in accordance with ABB
general rules and the author is unpronounced responsible for review, approval and release.
When there are requirements for the document to follow a formal review, approval and
release procedure with formally authorized parties, a formal approval procedure process
should be used (ABB-document6, 2006).
The document management system provides the authors, reviewers and approvers with
functions that enable comments and mark-ups to help review and update (ABB-document6,
2006).
A released document version cannot be changed without doing a revision. In a revision a new
document version is establish and the new document version should include the update of its
associated metadata. The new version should have draft as status and then the document
normally follow the same review, approval and release process as the predecessor (ABBdocument6, 2006).
43
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Workflow
When a document is produced it need to go through a Review and Approval Process before
the document is valid. The Review and Approval shall always be done in eCM and this is done
by the built in feature workflow (ABB-document14, 2011).
A workflow is created by the document author after the document is produced. In this
workflow the reviewers and the approver are selected. When the document shall go through
the review a notification is send to the reviewers and the Document Status is changed to “In
Review” in eCM. If the document is rejected some changes must be done before the
document goes to review again. If the document is pressed forward by the reviewer the
approver receives a notification. The approver can either reject or approve the document
and if it is approved the document author gets a notification. When all reviewers and the
approver have approved the document the document status is changed into “Approved” in
eCM (ABB-document14, 2011).
7.2.2.7 R&D Project Document types
One important task in this Master Thesis was trying to define what types of documents that
are produced in a R&D Project. This was done by having interviews and discussions together
with the relevant departments. It turned out to be quite a difficult task to define those
document types though most of the departments find it hard to point out what kind of
documents are generally produced in a R&D Project. A couple of respondents found it
unclear what kinds of documents they were expected to produce during a R&D Project and
another opinion was that the R&D Projects are so unlike each other which make it hard to
define general document types. In the ABB Gate Model Report (ABB-document9) key
deliverables such as specific documents are pointed out. This document also served as a help
during the work with trying to define the different document types. After several meetings
and discussions together with the departments a set of document types were defined. It was
also decided that for the documents that are produced in departments besides the technical
departments it is not necessary to divide them into types because it involves such a few
documents. The Document Type List can be seen in Appendix 10 – Responsibility Chart.
7.2.2.8 ISO 9001 at FACTS
The Quality Department is the department who ensure that for example the standard ISO
9001 is followed by ABB FACTS. Every six month a Certification Firm visits FACTS to ensure
that the requirements for ISO 9001 are fulfilled.
Every year intern revisions are executed at FACTS and a plan for these revisions is made. A
current revision is for example to ensure that ISO 9001 is followed. The Q department is
working to get all the Department Managers to perform their own intern revisions. These
intern revisions should for example ensure that all department processes are following ISO
9001. Those revisions often lead to suggested improvement actions to enhance the
processes.
7.3 QFD
To receive more knowledge about the project and to be able to transfer the project demands
into properties of the result a QFD was performed. The project demands that were stated in
the Project Directives from ABB FACTS were listed in the QFD. Suggestions on how to fulfil
those demands were suggested and then also listed in the QFD. Thereafter the relationship
between the demands and solutions where weighted. Thereby it was possible to see what
44
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
suggested solutions had the strongest relationship to the demands. The information that
came out from the QFD was later considered during the development of the result.
The QFD can be seen in Appendix 7 – QFD.
7.4 Function Analysis
To clarify the most important and needed functions in the Review and Approval Process two
Function Analyses were established. Two main functions were clarified by performing this
Function; “Admit review and approval” and “Classify review and approval objects”. One of
the main functions is clearly that the process needs to admit review and approval, but it is
also very important to clarify what objects that need to be processed. Thereof the second
main function “Classify review and approval objects” was clarified.
To identify what sub functions that need to be present to fulfil the main functions a Function
Analysis was performed for both of these main functions. Those Function Analyses can be
found in Appendix 8 – Function Analysis.
7.5 Design process - Responsibility Chart
An easy way to demonstrate and clarify responsibilities relative to Project Roles is by using a
Responsibility Chart. In this project it was decided to develop a Responsibility Chart that is
adapted to suit the current organization. After discussions together with the VU-team it was
decided that the Responsibility Chart shall be able to be used independently. This means that
it should not be necessary to use another document to be able to understand the
Responsibility Chart. The development of the Responsibility Chart is described in the
following section.
7.5.1 Brainstorming - Responsibility Chart
To obtain ideas about the Responsibility Chart the concept generation session was executed
in the form of a brainstorming.
The brainstorming session was focused on questions like; how should the Responsibility
Chart be designed to suit the department? What should be included? Should certain
headlines be used? The concepts that were generated during the brainstorming session were
evaluated and combined into the three concepts that are presented below.
7.5.1.1
Concept 1 –Responsibility Chart
In the first concept of the Responsibility Chart all Document Types was listed in relation to
the roles, se Figure 14, Concept 1 – responsibility Chart. At the left side of the Excel work
sheet the document types is found under each gate and working group. At the top of the
sheet the different departments are listed as main headings and the corresponding Project
Roles are listed as sub headings. The sub headings can be minimized to only make the
relevant areas visible for the reader, see Figure 15, Concept 1 – Main headings and sub
headings.
The reason why the gate structure is followed in this concept is because it corresponds to the
design of the R&D Process Map that is currently developed by the VU- team.
The Responsibility Chart has three pages and the first page is the actual matrix that describes
what responsibility each role has relevant to each Document Type. The second sheet has a
45
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
table where the Team Members are listed to their corresponding Project Role. The third
sheet has a description to each responsibility role that is included in the Responsibility Chart.
These pages are presented in Figure 14-17.
Figure 15, Concept 1 – Main headings and sub
headings
Figure14, Concept 1 – Responsibility Chart
Figure 16, Concept 1 – Sheet 2 Project Roles
Figure 17, Concept 1 – Sheet 3 Responsibility Role
7.5.1.2
Concept 2 –Responsibility chart
This concept was developed in order to change the column at the left side of the
Responsibility Chart. In this concept the Document Types are sorted below each department
instead of after each gate. This is illustrated in Figure 18, concept 2 – Responsibility Chart.
46
Figure 18, Concept 2 – Responsibility Chart
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
The column “Type of Review” were added in order to make it esier for the users. In this way
the user can see what kind of review that is necessary for each Document Type.
This concept also has three sheets as Concept 1 – Responsibility Chart. Sheet two and three
are the same in this concept.
7.5.1.3
Concept 3 –Responsibility Chart
This concept is also a concept concerning how to illustrate all Document Types and Role
Responsibilities. The left side of the document is the same as in Concept 1 – Responsibility
chart and it also contains the second and third sheet described in concept 1. At the top of
this document there are no departments and roles listed, instead there are different
activities and document numbers. This concept should instead of the abbreviations have the
roles listed in the middle. Concept 3 is illustrated in Figure 19, Concept 3 – Responsibility
Chart.
Figure 19, Concept 3 – Responsibility Chart
7.5.2 Concept Evaluation - Responsibility Chart
As mentioned, several concepts were developed during the brainstorming session. A PUGH
Analysis was used to evaluate the presented concepts and to choose the final concept. It is
important to be methodical when concepts shall be evaluated and for that reason this
method was used.
For this concept selection activity the original RACI Chart described in 7.2.1.4 Roles and
Responsibility was used as a reference. In this evaluation the demands came from the Project
Directives and also from inputs by the employees at ABB FACTS. These demands were
weighted against each other in order to find out which demands were the most important.
The Pugh Analysis can be seen in Appendix 9 – PUGH Analysis.
The Pugh Analysis showed that concept number one and concept number two reached
higher score than the reference concept. Concept number two got the highest score and
therefore this concept was chosen.
47
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
7.5.3 Concept Development – Responsibility Chart
During a workshop/presentation session after the final concept had been chosen some new
information affecting the Responsibility Chart were revealed. This resulted in that a new slide
for document control was created. In this slide every document that is supposed to be
produced during a project should be listed by the Project Manager. This slide contains more
information regarding the documents such as document status and document number.
Information regarding the Project Roles in the Responsibility Chart was also gained during
this session. On opinion was that the Project Roles that are mutual for several departments
should be listed outside the department groups in the Responsibility Chart. This would
decrease the amount of roles in the Responsibility Chart and therefore improve the
readability. This information only affected the Department Manager role. The other Project
Roles was decided to be kept as they were because otherwise some important information
would have got lost. This is for example information regarding what departments that should
be involved in the Review and Approval Process for certain Document Types.
The design of the RC was also changed. More discreet colours were used and the headline
rows got filled with colour to enhance the readability in the Responsibility Chart.
The final Responsibility Chart is presented in Appendix 10 – Responsibility Chart.
7.6 Design process - Responsibility Role
To be able to develop a Review and Approval Process it is important to have well defined
Roles and Responsibility Descriptions. It is for example very important to clarify who has the
authority to review and/or approve what document, especially as far as quality assurance is
concerned. After speaking with different departments it was clear that this was something
that was missing. This also concerns the R&D department. The Responsibility Roles are
supposed to be used in the middle of the Responsibility Chart. Therefore the Responsibility
Roles will clarify what authority and responsibility each Project Role has relative to what
Document Type, which is something that is very important for a functional Review and
Approval Process.
7.6.1 Brainstorming - Responsibility Role
To create satisfying Responsibility Roles that fit ABB FACTS working method a brainstorming
session was performed. This brainstorming considered how the Project Roles should be
presented in relationship to their responsibilities. Three different concepts were developed
and are presented below.
7.6.1.1
Concept 1 – Responsibility Role
This is the first concept regarding what Role Responsibilities that should be used in the
Responsibility Chart. This concept represents the originally RACI that was described in section
7.2.1.4 Roles and Responsibilities. The first column represents what Responsibility Roles that
needs to be defined and the second column shows what abbreviation that should be used for
every Responsibility Role in the Responsibility Chart. Table 6, Concept 1 – Responsibility Role
represent the originally RACI.
48
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Responsibility Role
Abbreviation
Short Responsibility Role Description
Responsible
R
This person is responsible for the task
Accountable
A
This person approves the task
Consulted
C
This person reviews the task
Informed
I
This people’s needs to be up-to-date
on the task
Table 6, Concept 1 – Responsibility Role
7.6.1.2
Concept 2- Responsibility Role
This concept has five different Responsibility Roles. Instead of the earlier mentioned roles
“responsible” and “accountable”, this concept includes “approver” and “reviewer”. Those
Responsibility Roles were chosen because the employees are already familiar with those
terms and those names also reflect their purpose in a better way. There is also another role
added, the “owner” role. This role is the person who owns the task. The Responsibility Roles
and abbreviations of this concept are illustrated in Table 7, Concept 2 – Responsibility Role.
Responsibility Role
Abbreviation
Short Responsibility Role Description
Approver
A
This person approves the task
Reviewer
R
This person reviews the task
Owner
O
This person is responsible for the task
Consulted
C
This persons should act as a support during
the task
Informed
I
This people needs to be up-to-date on the
task
Table 7, Concept 2 – Responsibility Role
49
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
7.6.1.3
2012-06-08
Concept 3 –Responsibility Role
In concept three one Responsibility Role was added in comparison to concept two. The
Added Responsibility Role is named “Support”. The Support role is responsible to act as a
support to the Owner during the whole task. This concept has more Responsibility Roles due
to better sort out the different responsibilities and to ensure no Project Role gets too much
work. The Responsibility Roles and their descriptions are presented in Table 8, Concept 3 –
Responsibility Role.
Responsibility Role
Abbreviation
Short Responsibility Role Description
Approver
A
This person approves the task
Reviewer
R
This person reviews the task
Owner
O
This person is responsible for the task
Consulted
C
This person provide expertise
knowledge and information for the
task
Informed
I
This people needs to be up-to-date on
the task
Support
S
This persons should act as a support
during the task
Table 8, Concept 3 – Responsibility Role
7.6.2 Concept Evaluation- Responsibility Role
To get relevant feedback on the three above mentioned concepts a workshop together with
the VU-team was performed. In cooperation with the VU-team those concepts were
evaluated. The mostly discussed roles during this meeting were the Owner, Reviewer and
Consulted roles.
It was mentioned that the name “Owner” could be misinterpreted to someone that owns the
project. Therefore “Author” served as a better name. “Author” is also a better alternative in
accordance with eCM due to the fact that the issuer of a document in eCM is named Author.
Another thing that was considered during this workshop was which one has the responsibility
to inform concerned functions about the completion of a certain project task.
Document Author is a Responsibility Role already described by ABB FACTS and this
Responsibility concerns the documents. The responsibilities that this role has are used within
the Author developed during this Master Thesis. The Document Author is described below:
The responsibility that the Document Author has is to ensure that the right process is
followed before a new document is issued. The responsibility is also to act as an owner to the
issued document during the life cycle and therefore keep the information valid and revise. If
the document is not valid and revised it should be withdrawn. Included in this responsibility
50
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
are to inform if a new document revision is available and to change the links. If a person not
longer is responsible for the issuing function the function manager assumes or delegates the
responsibility (ABB-document7, 2010).
Regarding the Reviewer Role it was discussed however the reviewers should be involved in
the execution of the project task or not. It was suggested that the earlier mentioned Support
Role could be a part of the Reviewer Role instead of having a specific role for this. Thereby it
would always be a technical expert present in the execution of the project task, which was
something that was asked for. Another suggestion was that the receiver of the specific
project task also should be part of the execution of the project task. Direct input from the
receiver of a project task is very valuable though it will give direct feedback if for example a
solution is practicable or not. With this in consideration it was specified that the receiver of a
project task must be included in the reviewers.
In accordance to the information gained from the workshop, from the earlier information
gathering and interviews, the final concept could be developed. The final Responsibility Role
concept is illustrated in Table 9, Concept Evaluation – Responsibility Role.
Responsibility Role
Symbol
Author
Au
Responsibility Role Description
This role has the responsibility to make sure that the
project task is completed. Either the Author performs
the task by itself or gets help from other employees.
The author has the responsibility to ensure that the
right process has been followed before a new
document is issued. It is the Author who starts the
new workflow of the issued document in eCM.
The Author also has the responsibility to own the
issued document. This means that it is included to
keep the information valid and revise during the
documents life cycle. It is also included to keep the
links updated and inform if there are any new
revisions.
It is also the Authors responsibility to inform
concerned functions about the completion of the
concerned project task (role Informed).
This role can only be assigned to one person.
Reviewer
R
This role has the responsibility to act both as a
reviewer and also as a support during the project
task.
The reviewer has a responsibility to perform the
technical verification of the reviewed subject. A
Review Record should always be used during a DRM.
Checklists should be used if available.
51
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
The supportive part of this role aims to, by two-way
communication, provide expertise knowledge for the
project task. It is important that the receiver of the
project task serve as a supportive reviewer during the
project task.
It is important that the reviewer, if possible, reviews
the document in eCM.
This role can be assigned to several people.
Approver
Ap
The responsibility of the approver is to ensure that the
correct reviewing process has been followed during
the review.
The approver always approves the document in eCM.
The approver shall be the nearest manager of the
Author.
This role can only be assigned to one person.
Informed
I
Persons who need to be kept up-to-date on progress,
mostly regarding the completion of the task or
deliverable. Only one-way communication is
necessary.
This role can be assigned to several people.
Table 9, Concept Evaluation – Responsibility Role
7.7 Design process- Type of Review
There are three main types of review occasions; internal DRM, external and internal DRM
and only eCM based review. Both the review occasions with DRM shall write MoM during the
meeting. The Responsibility Chart needs to clarify which one of these types of reviews that
needs to be performed according to what Document Types. This only regards the review
process and even if the review shall be performed with a DRM it still needs to be processed
in eCM.
7.7.1 Brainstorming - Type of Review
In the concept generation regarding the Type of Review a brainstorming session was
performed. During this brainstorming session several concepts were developed. The three
most promising concepts were chosen to go further with. Those three concepts are described
below.
7.7.1.1
Concept 1 –Type of Review
Concept one was developed in order to be easy to understand and to use. In this concept the
whole text for which type of review that should be used is visible in a separate column in the
Responsibility Chart. The Type of Review is illustrated for each Document Type and this
concept is available in Table 10, Concept 1 – Type of Review.
52
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Document Type
Document Type 1
Type of review
eCM based review/Approval
process
Role 1
R
Role 2
C
Role 3
R
Document Type 2
Project internal DRM + MoM
C
A
I
Document Type 3
Project internal and external
DRM+ MoM
I
R
C
Table 10, Concept 1 – Type of review
7.7.1.2
Concept 2 –Type of Review
In this concept there is still a separate column for the Type of Review but instead of all the
text abbreviations of the different Review Types are used. This concept makes the
Responsibility Chart smaller and therefore makes it easier to use. This concept is presented in
Table 11, Concept 2 – Type of Review.
Document Type Type of review
Document Type 1 eCM
Role 1
R
Role 2
C
Role 3
R
Document Type 2 In
C
A
I
Document Type 3 In & Ex
I
R
C
Table 11, Concept 2 – Type of Review
7.7.1.3
Concept 3 –Type of Review
In this concept the abbreviations is still used but they are placed inside the Responsibility
Chart together with the Responsibility Roles. This means that there is no separate column for
the Review Type. This makes the Responsible Chart smaller than the other Concept would
but it may be a bit more straggly to use. Concept three is available in Table 12, Concept 3 –
Type of Review.
Document Type
Document Type 1
Role 1
ReCM
Role 2
CeCM
Role 3
ReCM
Document Type 2
CIn
AIn
IIn
Document Type 3
IIn & Ex
RIn & Ex
CIn & Ex
Table 12, Concept 3 – Type of Review
7.7.2 Concept Evaluation- Type of Review
A Pugh analysis was established to evaluate the concept developed concerning how to
display the type of review that is needed for each Document Type. This Pugh can be seen in
Appendix 9 – PUGH Analysis. The demands that were used during the evaluation were taken
from both the Project Specification and also from inputs from the employees at ABB FACTS.
After consideration this demands were weighted with numbers between one and five where
five represented high importance and number one low importance. In this Pugh Analysis the
lowest score were considered to three.
53
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Three concepts were developed concept two was chosen to act as the reference. Concept
two was chosen because it was believed to be the concept that best fulfilled the demands.
The evaluation resulted in an equal result for concept one and a negative result for concept
three. Due to this concept three was terminated and after consideration also concept one
was terminated due to the negative result concerning “clear document overview”. In the end
concept number two were chosen together with a couple of improvement actions.
7.7.3 Concept Development – Type of Review
After the concept selection some new information was gained from the VU-team about the
Type of Review. It was mentioned that the Project Internal DRM + MoM and the Project
internal and external DRM + MoM could be mentioned only as DRM. This information
changed the end result into only two Types of Review, eCM and DRM. The final solution is
presented in Figure 19, Final Type of Review.
Figure 19, Final Type of Review
7.8 Design Process – Review Record
During the interviews at the different departments it was mentioned that important
decisions are not documented properly. After a meeting together with the Quality Manager
it was also reviled that actions from Review Meetings were not followed up properly either,
or at least not documented. To solve these issues a generic Review Record was developed.
The Review Record was developed in cooperation with a couple of R&D Project Managers
and also with input from the Quality Manager. By using a Review Record important decisions
and actions will be documented and it will also make sure that those actions and comments
are followed up.
The Review Record has a table where the Project Name, Date of Review, Issued Document,
Issued Document Number, Participants and the Participants role shall be filled in.
54
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
The Project Managers made it clear that the Review Record has to be easy to fill out;
otherwise it would be a risk that people would not use it. Whit this in mind the amount of
text in the Review Record was kept down and check boxes were used as much as possible. By
using check boxes it reduced the amount of text in the document and it also reduced the
amount of text that the user has to write personally, see Figure 20, Review Record – Check
Boxes. The Review Record has been designed in a very strict table format. This will also help
the users to fill out the document in the correct way.
Figure 20, Review Record – Check Boxes
One important input from the Project Managers was that it would be preferable if the
revision history could be illustrated in the Review Record. Therefore also a Revision ID
column was added, this is presented in Figure 21, Review Record – Revision ID Coulmn.
Figure 21, Review Record – Revision ID Column
7.9 Concept Development – Review Record
The first draft of the Review Record was reviewed by the VU-team and the head Manager at
the R department which resulted in a couple of changes. First of all the Revision ID Column
was decided to be removed though it was decided that almost the whole Review Record
table should be repeated for every revision instead. Also a row for related documents was
added. These are documents beside the issued document that need to be considered during
the review. It was also mentioned that it need to be pointed out which person are
responsible for the implementation of the comments that are revealed during the meeting,
this is illustrated in Figure 22, Review Record – Comment Implementation Responsible.
55
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Figure 22, Review Record – Comment Implementation Responsible
7.10 FMEA
To identify possible risks with the developed concepts a FMEA was performed. All risks that
were detected were given recommended actions. To minimize the risks all indentified risks
were considered and recommended preventive actions were taken. The functions in the
FMEA were divided into three categories; Responsibility Chart, Review and Approval in
general and Review Record. All these categories have different failure mode where the
failure mode and failure effect is affected.
The actions that were taken to minimize the risk frequency were to develop a User Guide to
the concerned functions. The User Guide explains the Responsibility Chart and the Review
Record so the risk for misinterpretation is decreased. After the User Guide was developed
the FMEA was updated. For further information about the FMEA see Appendix 11 – FMEA.
7.11 Design Process – Review and Approval User Guide
The FMEA were executed to find possible failure modes. The majority of the risks concerned
misinterpretations. A User Guide regarding how to use the Responsibility Chart and The
Review Record was therefore developed.
The Review and Approval User Guide was developed with the vision to be easy to follow and
to give a good overview about the Review and Approval Process. The User Guide is divided
into two sections; Responsibility Chart and Review Record.
The Responsibility Chart has four slides within the User Guide which explains each sheet in
the Responsibility Chart. The first slide regarding the Responsibility Chart is presented in
Figure 23, Review and Approval User Guide – Responsibility Chart. Important information is
explained with red arrows and also a short text describing the slide is available.
The Review Record is explained in the same way as the Responsibility Chart. The whole
Review and Approval User Guide is presented in Appendix 13 – Review and Approval User
Guide.
56
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Figure 23, Review and Approval User Guide – Responsibility Chart
7.12 Summary – Applied Solution Procedures
In this section the methods described in section 6. Theoretical Background was used in order
to gain information and to be able to reach a final result.
Information that was needed for the project was gathered in this section and the information
was both from ABB FACTS and also from other sources. The information that was gathered
was for example about ISO 9001, Stage-Gate Model, Roles and Responsibility, how ABB
FACTS are handling review and approval today and Responsibility Charts.
A QFD and a Function Analysis were performed in order to reach a better understanding of
the project.
The design process was divided into five areas; Responsibility Role, Responsibility Chart, Type
of Review, Review Record and User Guide.

The final concept regarding the Responsibility Roles was chosen after a workshop with
the VU-team. The concepts that were developed before the workshop were considered
under this session and some important factors were discussed. The final concept has the
Responsibility Roles of Author, Reviewer, Approver and Informed.

The final concept regarding the Responsibility Chart is concept two but after the Pugh
Analysis was performed some new information was revealed. This resulted in a
document control slide in the Responsibility Chart and changed colours to enhance the
readability. Also some of the Project Roles were moved out from the department
categories in order to only have one of the Project Roles listed in the Responsibility
Chart.
57
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08

The final concept regarding the Type of Review and Approval Process was chosen after a
Pugh Analysis had been performed. This final concept was concept number two together
with an improvement action. The action was to construct a description to make the
process easier. The final concept has a column in the Responsibility Chart that describes
the specific documents type of review and approval.

A Review Record were developed in order to ensure that important decisions are
documented properly and followed up properly. The Review Record was developed in
consensus with some R&D Project Managers and with the Quality Manager. The first
draft was reviewed by the VU-team and the head manager at the R department, which
resulted in a couple of changes.
When all concepts were evaluated and the final concepts were chosen a FMEA were
executed. All risks were listed, rated and recommended actions were given. The risks were
mostly about misinterpretation and therefore the recommended actions were to develop a
User Guide.

The User Guide was developed to lower the risk for misinterpretation during the use of
the Responsibility Chart or Review Record.
The actions taken were documented in the FMEA and a new risk analysis was performed.
58
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
8. Results
In this section the generated results of this Master Thesis are described. As mentioned earlier
in this report the aim of this project was to develop a generic Review and Approval Process
for the R&D Projects. The result is divided into six parts; Responsibility Chart, Responsibility
Roles, Type of Review, Review Record, The Review and Approval Execution Process and the
User Guide. These parts are presented below one by one.
8.1 Responsibility Chart
One of the aims of this Master Thesis was to construct relevant templates that should
enhance the R&D Review and Approval Process. A list of R&D Document Types and generic
Project Roles were therefore developed. This template is called a Responsibility Chart (RC)
and is especially constructed to fit the ABB FACTS R&D Department.
At the first sheet in the Responsibility Chart Document, see Figure 24, Responsibility Chart
(RC), the actual Responsibility Chart is illustrated. In the left column the identified Document
Types are listed under each department. In the top row the identified and general Project
Roles are listed. There are also some other information regarding in which gate the
document should be approved and what kind of review that is necessary present. In the
middle of the RC abbreviations of the Responsibility Roles are present. Those Responsibility
Roles shows what kind of responsibility each Project Role has corresponding to each
document type.
Figure 24, Responsibility Chart (RC)
The next sheet, Names on Project Roles, is describing the Project Roles. Here all the Project
59
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Roles are listed in left column. The next column is describing what competence area each
Project Role has. In the third column the name of the Project Member that corresponds to
each Project Role is listed and thereafter that person’s email is available. It is the Project
Managers responsibility to fill out this list in the beginning of a project. This sheet will help
the users to see which person in a specific project that owns what role; see Figure 25,
Responsibility Chart – Names on Project Roles.
Figure 25, Responsibility Chart – Names on Project Roles
In the next sheet a description of the Responsibility Roles is available. Here all Responsibility
Roles are listed together with information about what responsibility each of those roles has.
This is necessary to help the users to remember what the abbreviations in the RC stand for
and also to make the information of each Responsibility Role easily reached. Slide three is
presented in Figure 26, Responsibility Chart – Responsibility Role Description.
Figure 26, Responsibility Chart – Responsibility Role Description
In the last sheet, Document Control, all Document Types are listed. Here the R&D Project
Manager is supposed to fill out all the documents that are planned to be produced during the
project. Also more information regarding the documents is supposed to be available. This is
presented in Figure 27, Responsibility Chart – Document Control.
60
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Figure 27, Responsibility Chart – Document Control
The final Responsibility Chart is available in Appendix 10 – Responsibility Chart.
8.2 Responsibility Roles
The aim of this Master Thesis was to develop a Review and Approval Process for the R&D
Projects. The result of the Responsibility Chart mentioned in the section above depends on
this result. Without the Responsibility Roles the Responsibility Chart is useless.
The final Responsibility Roles are; Author, Reviewer, Approver and Informed.
Author, Au
The Author has the responsibility to make sure that the task is
completed, the responsibility to own the document and to inform about
the task.
Reviewer, R
The Reviewer has the responsibility to act as a reviewer but also as a
support during the project task.
Approver, Ap
The Approver has the responsibility to approve the task.
Informed, I
The Informed are the people that needs to be kept up-to-date on a task.
8.3 Type of Review
The aim of this Master Thesis was to develop a Review and Approval Process for the R&D
Projects. Without the information about the Type of Review the user of the Responsibility
Chart does not have the knowledge about how the review needs to be executed.
61
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
The result regarding the Type of Review is a column in the Responsibility Chart where this
information is listed to each Document Type. The final solution is illustrated in Table 28, Type
of Review.
Figure 28, Type of Review
8.4 Review Record
To make sure that important decisions are properly documented and to make sure that
actions after review meetings are followed up properly a Review Record was developed. The
Review Record is divided into two parts. The first part contains general information about the
issued document and related documents see Figure 29, Review Record – First part.
Figure 29, Review Record – First part
The second part of the Review Record is the part that will be repeated for every Review
Meeting. Here all data concerning the actual review is present. This part contains
information concerning meeting participants, reviewed part of the document, meeting
decisions and document revisions. Before every new Review Meeting this part of the Review
Record is supposed to be copied and pasted under the previous table. By doing this the
history regarding the concerned document will be saved. This part of the Review Record is
presented in Figure 30, Review Record – Second part.
62
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Figure 30, Review Record – Second part
The whole Review Record is available in Appendix 11 – Review Record.
8.5 The Review and Approval Execution Process
The aim of this Master Thesis was to develop a Review and Approval Process for the R&D
projects. The following paragraph is describing the general Review and Approval Process that
has been developed during this Master Thesis.
In the beginning of a project the Project Manager is supposed to adapt the Responsibility
Chart to make it suit the concerned project. Adapting the Responsibility Chart mean that the
Project Manager take a look at the Document Control Plan slide in the Responsibility Chart
and fills in the documents that will be produced during the project. The Project Manager also
should fill out the “Names on Project Roles” in the Responsibility Chart to define what Project
Roles are included in the project, in what area the Project Role is responsible for and which
persons that owns these roles.
The author of a document is defined by “Au” in the Responsibility Chart. It is the Author’s
responsibility to make sure the relevant document is produced and also to start the new
Workflow in eCM for that document. When a document has been produced and completed a
review of the document need to be performed. The roles that are supposed to review the
specific document are also specified in the Responsibility Chart, this time with the letter “R”.
The review can be executed in two different ways; DRM and only eCM based review. The
63
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
type of review for each document is shown in the Responsibility Chart. It is important to
clarify that all reviews should be executed in eCM. When a document has been sent for
review the Document Status field in the Responsibility Chart should be updated to “in
review”.
If a DRM is performed a Review Record shall be used. If the DRM contains more than one
document a Review Record shall be used for each document. If actions are listed during this
meeting they shall be corrected and thereafter the Review Record should be signed to
confirm that those actions are taken. The Review Record shall follow the document through
all revisions and if a new revision shall be reviewed the table “Meeting Number” shall be
copied and pasted underneath and thereafter filled out. If a checklist is available is shall be
used during the review. Also the Review Record and the Checklist shall be approved before
the specific document goes to approval.
The Approver “Ap” is the one who approves the document in eCM and thereby the
document reach the status of approved. The approver ensures that the review process has
been performed in the correct way and that the reviewers have enough competence for the
task. When the document has been approved the Author need to update the Responsibility
Chart so the Document Status is changed to “approved”. It is also the author’s responsibility
to inform relevant parties about the produced document. Those parties that need to be
informed are marked with an “I” in the Responsibility Chart. When the document is approved
it is the “Au”s responsibility to keep the document valid. The Review and Approval Execution
Process is illustrated in Figure 31, The Review and Approval Execution Process.
Figure 31, The Review and Approval Execution Process
The Responsibility Chart should be a document that is available for every Project Member
during the project. The Responsibility Chart should be used through the whole project and
thereby support the team with guidance regarding the Review and Approval Process.
The responsibility Chart demonstrates the Responsibility Role that each Projects Role has for
each Document Type. Therefore all Project members can easily see what responsibilities that
person has trough the whole project as far as review and approval is concerned.
64
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
8.5.1 Review and Approval User Guide
A User Guide was produced for the Review and Approval Process. In this User Guide the
execution of the Responsibility Chart and the Review Record is explained. This guide has
been produced in order to avoid misinterpretation regarding how the Review and Approval
Process should be executed. Figure 32, User Guide illustrates the first slide of the User Guide.
The whole User Guide is presented in Appendix 13 – Review and Approval User Guide.
Figure 32, User Guide
65
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
9. Analysis
The solutions that have been developed during this Master Thesis are in this section
described and argument with explicitly reasoning. This analysis demonstrates that the
developed solutions are solutions to the aim of this Master Thesis. The analysis is divided
after each Problem Statement.
This Master Thesis has resulted in solutions considering how the Review and Approval
Process shall be executed at ABB FACTS R&D department. The information gathering in this
Master Thesis was performed in order to be able to answer the problem statements
formulated in the beginning of this project. All the collected information were taken into a
rigorously consideration in order to develop a generic Review and Approval Process for the
R&D projects.
9.1 How do the Review and Approval Processes function at ABB
FACTS today?
The Review and Approval Processes at ABB FACTS is not working well as it is today. All
departments have mentioned in the interviews that there is no functional established Review
and Approval Process at FACTS, especially not in R&D projects. It was also mentioned that a
time plan with clear review and approval occasions would enhance the review and approval
process. The fact that many decisions do not get documented properly was also reviled and
that is a serious quality issue. The Review and Approval Process developed during this Master
Thesis will help to solve this problem. The Responsibility Chart and the Review Record will
ensure no important documents are forgotten and that all decisions are documented. The
missing time plan for the review and approval occasions are solved with the Approval
Column in the Responsibility Chart.
During this Master Thesis comments concerning who should review or approve what
document have not been uncommon. The Responsibility Chart will solve this issue by
clarifying what role has the responsibility and authority to review what Document Type.
9.2 What kinds of Responsibility Roles need to be included in the
Review and Approval Process at ABB FACTS?
Duncan Haughey mentioned that projects easily runs into troubles without clearly defined
roles and responsibilities. When roles and responsibilities are clearly defined projects can
easily be completed in time, to the right level of quality and within the budget. The RACI
contains the following Responsibility Roles; Responsible, Accountable, Consulted and
Informed. These Responsibility Roles were taken under deep consideration in cooperation
with several R&D Project Managers and was adapted in order to fit ABB FACTS needs.
Information gained during interviews, workshops and also information considering ISO 9001
lead to the following final Responsibility Roles; Author, Reviewer, Approver and Informed.
Due to the close cooperation together with the Project Managers and VU- team the final
Responsibility Roles are already accepted by the R&D Department and therefore a relevant
result to this Problem Statement.
66
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Document Author is a defined role at ABB FACTS. This role is responsible for example to act
as an owner to the issued document during the life cycle. All responsibilities that the
Document Author has are reflected in the Responsibility Role Author that was produced
during this Master Thesis.
9.3 What kinds of Document Types and Project Roles need to be
defined in a R&D Project at ABB FACTS?
In section 7.2.1.3 Cross-Functional Project Team Cooper describes that the Stage-Gate Model
consist of cross-functional project teams. This is also the case for the R&D Projects at ABB
FACTS which also mean that there is at least one Project Role from each department included
in a R&D Project.
As mentioned earlier, all Project Roles in a project shall be clearly defined in order to avoid
misinterpretations in the project team regarding what is expected from each Project Role.
According to Davis this is also important due to the fact that unattractive activities will be left
undone without defined roles descriptions. The TS Department has recently developed a Role
Description for their department and some of those roles could be adapted to the R&D
Projects. Those roles were used as a reference in the development of the generic Project
Roles. It turned out that those roles were not applicable to every department and therefore
other Project Roles are defined in consideration with the concerned departments.
During an interview the Head Manager at the R department pointed out that it would be
preferable if there was a Project Responsible from each department in the R&D Projects.
According to this information the Project Responsible was defined as a generic Project Role
to the R&D Projects.
For today these defined R&D Project Roles are accepted by the concerned departments and
therefore also a relevant result to this problem statement. Moreover there will be a number
of future recommendations regarding the R&D Project Roles.
Regarding Document Types it was mentioned by several departments that the R&D Projects
are very unlike each other which make it difficult to define general Document Types for R&D
Projects. Trough several discussions and interviews with different respondents from every
department a list of Document Types was defined. Due to the close cooperation together
with the different departments this Document Type List can be considered as a relevant
result to this problem statement.
9.4 How should the responsibilities in relation to the Project
Roles be clarified and described?
According to Cornelius-Fichtner the Responsibility Chart is useful in Cross-Functional Project
Teams. This kind of charts is useful to show the responsibilities in relations to the Project
Roles. Therefore a Responsibility Chart was established to show the responsibilities needed
in the Review and Approval Process in relation to the Project Roles and Document Types.
Davis points out that the person who has a specific Project Role may change during the time
of the project and therefore the Project Roles preferable are illustrated by the Role Title
instead of by the name of the individual person. This is reflected in the layout of the
67
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Responsibility Chart due to the fact that the Project Roles are listed in the top row of the
sheet. Instead the individual persons are listed in the Names on Project Roles sheet.
9.5 How should the Review and Approval Process be executed?
ABB FACTS has decided that all documentation needs to be processed in the Document
Management System eCM. The built in function eCM Document Approval workflow is
therefore mandatory to be used in the Review and Approval Process. The Responsibility
Chart was partly developed in order to make it easier for the users when it is time to start a
new workflow in eCM, this by clarifying who has the responsibility to review and approve
what document. The Responsibility Chart also clarifies what kind of review that is necessary
for every document type.
Through a number of interviews with different departments it was known that it is a lot of
confusedness regarding what the responsibility roles really mean and what responsibility that
is included in those roles. By defining those Responsibility Roles the execution of the Review
and Approval Process will be better understood due to that the responsibilities that are tied
to every role will be much more clarified.
Due to the fact that ABB FACTS is ISO 9001 certified the quality department has been
involved in and influenced the result of this project according to those ISO regulations. One
important aspect that was pointed out from the Quality Department was that comments
from Design Review Meetings were not followed up and documented sufficiently. By using
the developed Review Record the meeting participants will be forced to document and also
to follow up commented actions and therefore solve those kinds of problems.
According to the result from the FEMA Analysis that were performed a User Guide regarding
how the Review and Approval Process should be executed was developed. This guide will
lead the users through the Review and Approval Process and thereby decrease the
uncertainties about how the Review and Approval Process should be executed.
68
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
10. Conclusions & Recommendations
The aim of this Master Thesis was to develop a generic Review and Approval Process for ABB
FACTS R&D Projects. The Literature Study, interviews, meetings and discussions provided
with information that lead to the development of the Responsibility Chart, Review Record,
Responsibility- and Project Roles and the Review and Approval User Guide. All of these
turned out to be very important factors in an efficient Review and Approval Process. The
result of this Master Thesis will help the R&D Projects at ABB FACTS to ensure the quality
that a functional Review and Approval Process provides with.
10.1 Conclusion
In the beginning of this project it was a big challenge to figure out where to start, how to
limit the extent of the project and how to formulate relevant Problem Statements. But
trough internal discussions in the Project Group and together with the Project Initiator, and
also depending on the amount of information that was gained from FACTS during the first
period of time, those uncertainties became more and more clear. In the end the Project
Group is satisfied with the result and also with the answers to the problem statements of this
Master Thesis. ABB Facts where also satisfied with the results and began to apply the
developed review and approval process immediately when the Master Thesis was
completed.
To be able to develop a generic Review and Approval Process one important factor was to
continuously perform interviews and to get feedback from employees from several
departments. A difficulty in this Master Thesis was that a lot of the gained information came
from employees at ABB FACTS which resulted in waiting periods due to the interview
participant’s tight schedule. This made it quite difficult to stick to the Project Time Plan.
One of the problem statements in this Master Thesis was to define what kind of Project Roles
that should be included in a R&D Project. This question turned out to be more comprised
than expected. Therefore it was necessary to add the Project Limitation that says that Project
Role Descriptions will not be considered in this project. Instead the answer to this question
resulted in a suggested set of roles for every department together with suggested future
work considering the Project Roles.
The opportunity to participate in the VU-team and the input that the team gave us were
extremely helpful in the process to develop the Review and Approval Process. Without the
VU-team’s commitment and valuable input to the interviews, workshops and continuously
reviews on our work we would not have been as satisfied over the result.
10.2 Recommendations
The information that was gained during this Master Thesis not only provided information to
the result but also to other areas. Some of the collected information did also fell out of the
frames for this project or were not further considered due to the time limit. This information
were considered and resulted in suggested future work. Those recommendations are:

The documents that have been developed during this Master Thesis are documents that
need to be continuously updated. The documents are developed according to the
69
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
information that is available today and adjustments will probably be necessary in the
future. A recommendation to the R&D Department is therefore to continuously keep
these documents updated. This suggestion regards the Responsibility Chart, Review
Record, Responsibility Role and the Review and Approval User Guide.

Another recommendation regarding the Review Record is to transfer the Review Record
in to a TTT-skeleton.

The TS Department has recently written a Role Description for their department. This
description has been used as inspiration during the development work of the suggested
Project Roles in the R&D Projects. This Role Description is well performed and a
recommendation to the R&D Department is to write their own Role Descriptions. A
further suggestion is that the Role Descriptions should be developed in cooperation with
all departments with the aim to develop so overall and generic roles as possible for all
departments.

Another recommendation is to develop DRM checklists for the most critical Document
Types. Those checklists would help to improve the quality and will also make sure that
important aspects will not be forgotten during the review.

During the interviews several departments has mentioned their disappointments
towards the Document Management System eCM. Therefore one recommendation is to
upgrade eCM as soon as possible so it fulfil all requirements that are needed for an
functional process. It is specifically suggested that eCM is upgraded so working files such
as CAD files and other Program Files can be processed there.
70
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
11. References
The references that have been used during this Master Thesis are divided into printed
references, digital references, ABB internal references, oral references and figure references.
11.1 Printed references
Antvik, S. and Sjöholm, H., 2007. Project management and methods. Stockholm: Elanders
Sverige AB.
Bergman, B. and Klefsjö, B., 2002. Kvalitet I alla led. 2nd ed. Lund: Studentlitteratur
Cooper, R.G., 2001. Winning at New Products, accelerating the process from idea to launch.
3rd ed. New York: Basic Books.
Davis, L., 1997. Quality Assurance, ISO 9000 as a Management Tool. Copenhagen:
Handelshøjskolens Forlag.
Eppinger, S.D. and Ulrich, K.T., 2008. Product Design and Development. 4th ed. New York: The
McGraw- Hill Companies.
Haik, Y., Shahin, T.M., 2010. Engineering Design Process. 2nd ed. USA: Cengage Learning.
Hart, C., 1998. Doing a Literature Review. London: SAGE Publications.
Mantel, S.J. and Meredith, J.R., 2010. Project Management, a managerial approach. 7th ed.
Asia: John Wiley & Sons.
McDonough III, E. F., 2000. Investigation of Factors Contributing to the Success of CrossFunctional Teams. Boston: Northeastern University.
Österlin, K., 2007. Design I fokus för produktutveckling. 2ed. Malmö: Liber AB
11.2 Digital references
ABB1. [Online] Available at:
http://www.abb.com/cawp/abbzh252/e1d71cc7979eaf7fc1256ae700474df0.aspx?v=71
82A&leftdb=global/ABBZH/ABBZH252.NSF&e=us&leftmi=76465d8d53273699c12571920
030dbef, [2012-01-24 time 12:50]
ABB2. [Online] Available at:
http://www.abb.com/industries/us/9AAC30100023.aspx?country=SE, [2012-01-24 time
12:46]
Cornelius-Fichtner. [Online] Available at:
http://www.cornelius-fichtner.com/index.php/pmp/241-pmp-exam-tip-the-responsibilityassignment-matrix-ram, [2012-04-20 time 10.55]
71
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Hageback, J., 2002. Interviewing as a Research Method – Brief introduction on how to
conduct an interview. [Online] Available at:
http://www.gvc.gu.se/utbildning/Student+vid+institutionen/stipendier/intervjumetoder
/ , [2012-02-01 time 12:35]
Haughey, D., 2011, What is RACI Matrix? [Online] Available at:
http://www.isanalisti.net/2011/10/what-is-raci-matrix/, [2012-03-05 time: 13.05]
QFDONLINE. [Online] Available at:
http://www.qfdonline.com/templates/ , [2012-03-25 time 13.26]
The free dictionary1. [Online] Available at:
http://www.thefreedictionary.com/workshop , [2012-05-09 time 16.02]
The free dictionary2. [Online] Available at:
http://www.thefreedictionary.com/flowchart , [2012-05-31 time 15.48]
11.3 ABB intranet
ABB-document1, 2011. FA2011-000452__en_FACTS_Organisationsschema. [In-house]
ABB-document2, 2011. Organization, Responsibilities and Authorities – FACTS. [In-house]
ABB-document3, 2011. Organization, Responsibility and Authority for the Technology
Departments. [In-house]
ABB-document4, VU information för ledare. [In-house]
ABB-document5, 2012. ABB Gate Model for Technology, Product and System Development
5.0. [In-house]
ABB-document6, 2006. Document management – Basic principles and methods. [In-house]
ABB-document7, 2010. Document Management at FACTS. [In-house]
ABB-document8, 2011. Roles and responsibilities system design department. [In-house]
ABB-document9. ABB Gate Model Report 5.0. [In-house]
ABB-document10, 2008. Styrning och kvalitetssäkring av konstruktioner inom
teknikavdelningarna. [In-house]
ABB-document11, 2012. Roles and responsibilities at FACTS system design department. [Inhouse]
ABB-document12,2011. Work Description – Technical Responsible Control Software. [Inhouse]
ABB-document13,2010. NOAH Software Change and Configuration Management. [In-house]
72
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
ABB-document14,2011. eCM Document Approval workflow users guide. [In-house]
ABB-inside1, ECM = Enterprise Content Management. [In-house]
http://inside.abb.com/cawp/gad00914/c1256a860020f91cc1256bd1004593c2.aspx
2012-02-27 t. 13.29
ABB-inside2, 2011. Steering Committee Procedural Rules. [In.house]
http://inside.abb.com/cawp/gad00984/09f15ea1ab5b7a02c1256c330051fb9a.aspx,
2012-04-19 10.45
ABB-inside 3, 2012. Welcome to the R&D (R) Department at FACTS. [In-house]
http://appl25.de.abb.com/Db/DB0004/db000856.nsf/60287130dafc599fc12571500026
e5fa/f708b765dce9ac2cc1257a0c003c0970!OpenDocument [2012-05-31 time 16.35]
11.4 Oral references
Lövgren, Rolf: Senior lecturer, Mälardalen University
Wilroth, Mikael: Project Manager, ABB FACTS Västerås
Interview Respondents, ABB FACTS Västerås
Other employees, ABB FACTS Västerås
11.5 Figure references
ABB-document6, 2006. Document management – Basic principles and methods. [In-house]
ABB-document15, VU - Process Map. [In-house]
Cooper, R.G., 2001. Winning at New Products, accelerating the process from idea to launch.
3rd ed. New York: Basic Books.
Eppinger, S.D. and Ulrich, K.T., 2008. Product Design and Development. 4th ed. New York: The
McGraw- Hill Companies.
Haughey, D., 2011, What is RACI Matrix? [Online] Available at: http://www.isanalisti.net/wpcontent/uploads/2011/10/raci.png, [2012-03-05 time: 13.05]
Mantel, S.J. and Meredith, J.R., 2010. Project Management, a managerial approach. 7th ed.
Asia: John Wiley & Sons.
73
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
12. Appendices
APPENDIX 1 - PROJECT DIRECTIVES ....................................................................................................... X
APPENDIX 2 - REQUIREMENT SPECIFICATIONS ................................................................................... X
APPENDIX 3 - GANTT CHART .................................................................................................................... X
APPENDIX 4 - ORGANIZATIONAL CHART .............................................................................................. X
APPENDIX 5 - INQUIRE SHEET .................................................................................................................. X
APPENDIX 6 - INTERVIEWS ........................................................................................................................ X
APPENDIX 7 - QFD ........................................................................................................................................ X
APPENDIX 8 - FUNCTION ANALYSIS ....................................................................................................... X
APPENDIX 9 - PUGH ANALYSIS ................................................................................................................. X
APPENDIX 10 - RESPONSIBILITY CHART ................................................................................................ X
APPENDIX 11 - FMEA ................................................................................................................................... X
APPENDIX 12 - REVIEW RECORD.............................................................................................................. X
APPENDIX 13 - REVIEW AND APPROVAL USER GUIDE....................................................................... X
74
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Appendix 1- Project directives (1/2)
75
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Appendix 1- Project directives (2/2)
76
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Appendix 2 – Requirement
specification
1. Requirement specification
A requirement specification has been established to ensure that the end result meet the
initiators expectations. All requirements regard the reviewing and approval processes for
R&D projects. The requirements of this theses work are:
1.1 General requirements
The general requirements of this Master Thesis are:



A literature study must be performed.
Collect and discuss information from different departments.
Participate at VU-meetings regarding R&D processes.
1.2 Deliveries
The deliveries of this Master Thesis are:




Role descriptions.
Templates.
Process descriptions.
An English written report.
1.3 Quality
The deliveries shall fulfil the demanded quality;




The templates should be designed according to ABB FACTS idioms.
The process descriptions should be designed according to ABB FACTS idioms.
The templates should be tested and redefined if necessary to make sure they fulfill their
purpose.
The process descriptions should be tested and redefined if necessary to make sure they fulfill
their purpose.
77
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Appendix 3 – Gantt Chart (1/4)
78
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Appendix 3 – Gantt Chart (2/4)
79
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Appendix 3 – Gantt Chart (3/4)
80
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Appendix 3 – Gantt Chart (4/4)
81
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Appendix 4 – Organizational chart
82
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Appendix 5 – Inquire sheet
Respondent:
Position:
Department:
Date:
Project:
Question 1
a. Is there any composed processes’ for reviewing and approving documents at your
department?
b. In that case, can you describe that process?
Question 2
a. How do you find the approval and reviewing processes ‘at your department works today?
b. What do you think works today regarding the reviewing and approval processes’?
c. What does not work today?
Question 3
At what stage in the process are documents reviewed?
Question 4
At what stage in the process are documents approved?
Question 5
What kind of documents are reviewed and approved?
Question 6
How do you know if a document needs to be reviewed and approved?
Question 7
83
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
a. Is there any set roles that describes who got the right authorities for reviewing and approving
documents?
b. I that case, where do you find that kind of role descriptions?
c. What implicates these roles?
d. How are these roles decided?
Question 8
a. How is the revision management working at your department?
b. How do you handle revision notes at your department?
c. Is there any differences concerning the revision management depending on document type?
Question 9
What do you believe is the common apprehension about the reviewing and approving
procedures at your department?
Question 10
Have you participated in a R&D project?
Question 11
In that case, what are your experiences regarding the reviewing and approval processes in
the R&D projects?
Question 12
Do you have any remaining comments regarding this topic?
84
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Appendix 6 – Interviews (1/6)
DE – Electrical Design
In the DE department there are certain processes for reviewing and approving documents.
These processes are working well in theory, but it is still up to every person how well these
processes are used. All documents produced in the DE department during a delivery project
will be considered in a DRM. During these kinds of meetings a certain checklist is followed to
make sure that the meeting is proceed as smooth and effective as possible. To make sure not
to consume unnecessary resources, the participants of these meetings are carefully chosen.
These DRM’s usually takes maximum 30 minutes, sometimes more if something special has
emerged. Almost every document produced in the department are reviewed and approved,
at least the ones that will be sent to other departments or to customers.
The reviewing and approving processes can look a bit different depending on what software
is being used. It is for example not possible for the document management system eCM to
run the CAD systems that are used at the DE department. Therefore it is necessary to have
separate reviewing and approval processes depending on what program is used. The output
of every activity in the PEM initiates a DRM. This generates a lot of meetings.
The most significant problem with de reviewing and approval processes regarding the
delivery projects at the DE department is that stressed employees may skip important stages
due to their tight schedule.
There are detailed instructions available for the DE department regarding the reviewing and
approval processes. The employees also now what they are aiming for regarding this area but
there are still some missing protocols. There are detailed instructions regarding role
descriptions available at TOPS.
Today it is not a hundred percent clear what it really means to be a reviewer/approver,
especially when it comes to the reviewing process. There are for example some uncertainties
about on what level a document should be reviewed. This is something that needs to be
formalized.
There are stated instructions about how revisions of documents should be managed. But
there are still employees that do this in their own way.
The revisions management is the same for all types of documents. But the documents could
be approved in different systems.
The general apprehension of the reviewing and approval processes at the DE department is a
bit spread. It depends on how stressed the employees are.
The reviewing and approval processes concerning the development projects are much more
unclear. A big problem is that crucial decisions are not officially documented. As a
consequence, many decisions are not reviewed. These leads to decisions are taken too easily
without enough knowledge and reflections. This concern most of the decisions in a
development project. The development projects are often perceived to be run badly, mostly
due to the lack of resources. Another problem is that the requirement specifications often
are unclear. Without a satisfying requirement specification there is a risk for bad quality.
85
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Another issue is that it is difficult to know exactly when a project is finished if a reliable and
well prepared requirement specification is missing.
It would be a good thing if the roles in a development project were specified beforehand and
if the requirement specifications could be clearer. A good time plan containing clear
reviewing opportunities is also something that is missing.
86
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Appendix 6 – Interviews (2/6)
DM – Mechanical Design
DM has a time plan for every project and all the review opportunities are documented in the
project model for their delivery projects. DRM’s are used and minute containing checkpoints
that should be reviewed are available at TOPS. The review and approval processes for
delivery projects are working very well at the DM department.
At the DM department the R&D projects are working well. The deliveries that the DM
department are expected to deliver are fairly described but this differs from project to
project. Some R&D projects have well defined specifications regarding what should be
included in the project or not. It is very important to have clear specifications and conditions
in the R&D projects. The DM department would like to have a document with clear
specifications that describes what need to be developed and also all the input that is needed.
A review and approval is made when a document is finished in a delivery project and
thereafter the document is sent to customer or suppliers. The documents that are reviewed
and approved at the DM department are documents that are produced within the
department DM. Examples of documents that goes through this processes are drawings,
reports and calculations reports. All documents that are included in a delivery project have to
go through the review and approval process.
The DM department has a description saying that it is the manager who decides who should
review or approve what document in a delivery project. The manager of the department
chooses the reviewer from without the person’s expertise. A senior engineer should review
documents within a project and it is the same person who reviews all documents within a
specific project.
In the R&D projects a senior engineer performs the review of documents; thereafter the
document is handled in a MoM. The last thing that happens at the DM department in a R&D
project is that the DM department’s manager is approving the document.
The reviewer should act as support to the person in charge for the project. It is important
that the reviewer do not get too involved in the project because then the reviewer will not
be able to review the document objectively. The reviewer should ensure that the
requirements from the customer are fulfilled. The reviewer marks that the document is
reviewed in the PDM system.
When a revision of a document need be done the document is checked out from the PDM
system and opened in for example Solid Works. Thereafter the document is placed in eCM
where anyone can review the document.
The DM department would like the R&D projects to have a more clear specification where an
all-embracing description about the project is written, today this is missing. This document
should describe the project specifications, limitations and goals and it should also be
reviewed before it is delivered to the department.
All decision that is taken during a R&D project must be documented.
87
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Appendix 6 – Interviews (3/6)
O – Operations
On the O department the reviewing and approval processes mainly regards instructions and
tenders, which are produced on the O department. The O department receives already
reviewed and approved documents from other departments and sorts them into the right
place in eCM. A link to that eCM document is thereafter sent to the manager for approval.
The workflow for reviewing and approval processes in eCM are not being used at the O
department. Instead mail are used due to information can be written in the mail. It is
important to keep the process as simple as possible. Another issue is that the reviewing
process can be delayed if the reviewing person is away from the office. In that case it would
be a good thing if the reviewing responsibility automatically could be sent to someone else
with the appropriate competence.
Tenders are reviewed and approved by the managers. Instructions in the other hand can be
written and reviewed by several employees. The last thing that happens in the document
management process is when the document is approved and at this department it mostly
regards instructions and tenders. Documents are always approved by the managers.
At this department there are no role descriptions that describes who got the right authority
and responsibility to review and approve documents. This is something that is missing and
therefore something like that should be stated. When these kinds of documents are stated
they should be found on TOPS.
Document revisions are handled by eCM and the TTT templates are used. Regarding revision
notes, every document has this table at the end where the revision notes are filled in
manually.
The document management system eCM is working better and better but it is still in need of
improvements. Suggestions of improvements are collected from the different departments
and then brought up to global decision holders. The reviewing function is currently under
investigation to look for improvement opportunities.
The PDM systems for the CAD programs will be able to communicate with eCM in the future.
This means that when documents are reviewed and approved in the PDM system they will
automatically be reviewed or approved in eCM. This will prevent the need to review and
approve the same thing in two different systems and therefore decrease the workload on the
employees.
It is very difficult to have the same reviewing and approval process for all departments
because every department is working so different due to each other. But it is very important
that people are aware of that documents need to be approved before they can be used of
other departments and/or costumers.
The OS department still receives questions regarding who is the one to review and approve
documents in an eCM workflow. This indicates that necessary instructions, guidelines and
information regarding how to work in eCM is missing or that they are now followed by the
employees.
88
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
The OS department is very unsure about how to handle the development projects. They think
that the development projects at least should have a ground structure for their folders in
eCM. One suggestion for the R department is that they should hire process owners for
documentation. This will create a better arrangement and also improve the quality.
89
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Appendix 6 – Interviews (4/6)
R – Research and Development
There are almost no established reviewing and approval processes at the research and
development department. Due to this, almost every person has their own process.
Documents are reviewed when they are about to be sent to a customer or if a R&D project is
close to passing a gate. The department continuously improves their ability to work
according to the gate model and therefore the reviewing and approval of documents have
been done more and more properly.
The reviewing and approval processes are often performed too late in the R&D process,
especially considering the approval processes. This causes a lot of stress around the
employees. Due to this it is important to reserve time for the reviewing and approval
processes in the beginning of a process.
It is well known what kind of documents that needs to be reviewed and approved; mostly it
regards design reports and specifications. It would still be preferable if the documents that
are supposed to be reviewed or approved were more specified.
There are no specified role descriptions for the R department. Unofficial it is the manager
that is supposed to be the one who approves everything. Considering the reviewer it is
common to pick someone that “feels right” to review the document.
What it really means to review and approve a document is not a hundred percent clear and it
is not specified.
How the revisions are managed is very personal and this is also something that differs a lot
from department to department. There are also questions considering what needs to be
reapproved after a revision has been made. Is it the whole document or only the revision
note? An overall description about how the revision management should be handled would
be very useful. All revisions that are produced in the department should be processed in
eCM, even though it is complicated.
A functional reviewing and approval process is very important and that is something that
should be pointed out in particular. As it is now, people do not really reflect on the
importance of a well defined reviewing and approval process.
90
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Appendix 6 – Interviews (5/6)
TC – Control System Integration
There are certain reviewing- and approval processes at the TC department. For the delivery
projects there are a lot of processed documents which are processed in DRM’s.
There is a big difference about how the delivery projects and the development projects are
handled. For the development projects there are not so much strict processes for how the
document should be handled. This is because the development process at TC is a very
iterative process and therefore it is hard to follow strict processes. The documents that are
produced during these projects are mostly in-house documents and they do not go through a
reviewing- and approval process.
There are many documents that have been produced during the development projects that
in the end of a project are collected and assembled to a final report that is reviewed and
approved. There is always someone who is deeply involved in the project who reviews these
documents because there is only a well grounded person that has enough competence to
identify possible inaccuracies. The documents that go through a reviewing process are
reviewed in the end of the project. This mostly concern final reports, subsystem descriptions
both hardware and software and also test reports. It is always the manager that approves
documents and this is mostly performed in eCM.
Revision management is very important, especially when it comes to software. The TC
department works with several different programs and therefore the revision management
can vary a bit depending on which program that is used. To be able to go back and look at
earlier versions of a document is a very important function at the TC department.
It is also important not to implement procedures that do not contribute with any value to the
projects.
91
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Appendix 6 – Interviews (6/6)
TS – System Design
The TS department has a composed process for their review and approval processes
regarding their delivery projects and good descriptions of that processes are available. The
review and approval processes at TS are strictly followed and that is beneficial for the quality
assurance. But this process does not work perfectly as it is today. Due to the lack of recourses
sometime it is hard to find reviewers and approvers with the right competence. If the
reviewing person does not have enough competence there is a risk for reduced quality. There
are also missing descriptions describing what it really means and what responsibility it carries
to review or approve a document. The common apprehensions at TS concerning the review
and approval processes for delivery projects are positive. The processes are important to
perform to ensure high quality.
At the TS department the delivery projects are working better than the R&D projects, due to
a more familiar process. In the R&D projects it is more up to the projects participants to
decide how the process should be handled.
The TS department is working with a flexible project management regarding their delivery
projects. At first a time plan is establish in the project. The documents are reviewed and
approved according to that time plan for the delivery project. All documents are reviewed
and approved before they are delivered to the customer. Mostly all documents will go
through a review and approval process and those documents are mostly reports, technical
documents, foundation for purchasing and overview documents. The TS department has a
project folder where all documents can be found with each document number. In the
beginning of a project all relevant documents is listed in this map. Those documents are
evaluated with the project leader and decisions regarding which documents are relevant for
the delivery project and which documents that should be delivered to the customer are
taken.
Regarding the R&D projects all decisions are not documented, this is a crucial problem. The
decisions that do are documented during these process are reviewed and approved. There is
some problem concerning this lack of documentation. These are for example that it
sometime is only one person who is involved in an important decision and due to the lack of
documentation a decision could not be controlled later in the process.
There are no clear role description concerning who has the right to review or approve a
document, but a description is in progress. Documents that TS has produced concerning the
review and approval process are composed after delivery projects.
When there is a document that needs to be reviewed in a delivery project the person who
prepared the document gives it to the reviewer who comments the document. Thereafter a
Workflow is launched in eCM where the reviewer gives the document the reviewed status
and thereafter the document is sent to the approver.
It can be difficult to find someone that has the authority to review a document and it is also
not clear who has the right authority and competence to do so. The persons who perform
the reviews vary but it is important that this person have the right competence. This is not
working perfectly as it is today. It is the manager who decides who the reviewers should be.
92
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
The employees at TS think that it should be more clear who has the right authority to make a
review according to each document type.
In general the reviewer is determined by the chef and the employee that is considered
appropriated for the task is chosen. In R&D projects there are more difficult to find a
reviewer due to the employees are not so informed in the area.
The person with the authority to approve a document is often the manager of the
department but sometimes other employees get the responsibility to approve. A common
opinion at TS is that it often takes too long time before a document is approved, too often a
approve issue get stuck in someone’s mailbox.
All revisions are handled in eCM. New revisions are saved with a new name together with a
different revision letter. There are strictly document numbers to every document. Revision
notes are written to the reviewed document. These notes regard date, what has been
changed, where the change was made, name on the person who changed the document and
which revision the document has. The revision notes are written in a table on the last page of
the document. After a revision has been made the document goes to a reviewer and
thereafter to an approver. All documents that go to the customer have revision notes, this do
not concern memos.
A common opinion at TS is that the document management system, eCM are slow and that
eCM need improvements. In a long-term perspective it is a critical situation because people
get tired of the system and find other solutions. There are also no guidelines about which
calculation files should be saved in eCM. TS believe that it should be a higher priority to clean
up in the project when the project is closed due to save only important files at eCM.
There are also difficulties regarding what status a document has when it is sent from other
departments.
It would be good if all decision that is taking during a R&D project are documented and if
there were clear reviewing opportunities. For example could all decision that is made be
considered in a MoM.
It could be hard to have a role description to a R&D project due to the high level the
description must have. This could lead to a document that not is helpful in the process. But it
could be a good base to have a role description connected to all the documents that is
necessary in a project. This document has to be changed before every R&D project.
It has to be clearer about when everything should be reviewed and approved in R&D
projects.
93
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Appendix 7 - QFD
94
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Appendix 8 - Function Analysis (1/2)
Admit Review and Approval
Demand competence
profile
Demand role
description
Admit availability
Admit review and
approval object
Admit reviewer and
approver
Admit object
description
Admit revision
management system
Admit access
Admit review and
approval
Admit review and
approval
management system
Admit time saving
Admit easy
procedure
Admit guidelines
Admit object status
Admit order of
priority
Admit review and
approval parameters
Admit time limit
95
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Appendix 8 - Function Analysis (2/2)
Classify Review and Approval Objects
Clarify document
types
Demand
competence
profile
Clarify delivery
method
Admit availability
Classify review
and approval
objects
Admit access
Clarify process
steps
Admit easy
procedure
Admit order of
priority
Clarify frequency
Clarify recourse
demand
96
Demand role
description
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Appendix 9 - PUGH Analysis (1/2)
Responsibility Chart
PUGH
Roles and Responsibility –
Responsibility Chart
Concepts for valuation
Demands
Weight
Reference
RACI
Chart
1
2
3
Show roles needed
in a R&D project
5
0
0
0
0
Show document
types needed in a
R&D project
5
0
0
0
0
Show
Responsibility Role
5
0
0
0
0
Easy to understand
3
0
+1
+1
-1
Fit R&D Process
3
0
+2
+1
+2
Clear document
type overview
4
0
-2
0
-2
No time consuming
3
0
+1
+1
-2
Show document
status
4
0
0
+2
+2
4
0
0
+1
0
Summary
+4
+21
-3
Continue?
No
Yes
No
Show type of
review and
approval process
Score explanation
2
1
0
-1
-2
Much better than reference
Better than reference
Equal as reference
Worse than reference
Much worse than reference
97
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Appendix 9 - PUGH Analysis (2/2)
Type of Review and Approval
PUGH
Responsibility Chart –Type of Review and
Approval
Concepts for
valuation
Demands
Weight
Reference
Concept 2
1
3
Show type of review and
approval
5
0
0
0
3
0
+1
0
No time consuming
3
0
0
0
Clear document
overview
3
0
-1
1
0
3
No
N
o
Easy to understand
Summary
Continue?
Yes,
improve
Score explanation
2
1
0
-1
-2
Much better than reference
Better than reference
Equal as reference
Worse than reference
Much worse than reference
98
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Appendix 10 – Responsibility Chart (1/9)
99
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Appendix 10 – Responsibility Chart (2/9)
100
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Appendix 10 – Responsibility Chart (3/9)
101
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Appendix 10 – Responsibility Chart (4/9)
102
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Appendix 10 – Responsibility Chart (5/9)
103
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Appendix 10 – Responsibility Chart (6/9)
104
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Appendix 10 – Responsibility Chart
(7/9)
105
Mälardalen Univeristy
Malin Bånghammar & Marie Norling
2012-06-08
Appendix 10 – Responsibility Chart
(8/9)
106
Mälardalen University
Malin Bånghammar & Marie Norling
2012-06-07
Appendix 10 – Responsibility Chart
(9/9)
107
Mälardalen University
Malin Bånghammar & Marie Norling
2012-06-07
Appendix 11 – Review Record
108
Mälardalen University
Malin Bånghammar & Marie Norling
2012-06-07
Appendix 12 - FMEA
109
Mälardalen University
Malin Bånghammar & Marie Norling
2012-06-07
Appendix 13 - Review and Approval
User Guide (1/9)
110
Mälardalen University
Malin Bånghammar & Marie Norling
2012-06-07
Appendix 13 - Review and Approval
User Guide (2/9)
111
Mälardalen University
Malin Bånghammar & Marie Norling
2012-06-07
Appendix 13 - Review and Approval
User Guide (3/9)
112
Mälardalen University
Malin Bånghammar & Marie Norling
2012-06-07
Appendix 13 - Review and Approval
User Guide (4/9)
113
Mälardalen University
Malin Bånghammar & Marie Norling
2012-06-07
Appendix 13 - Review and Approval
User Guide (5/9)
114
Mälardalen University
Malin Bånghammar & Marie Norling
2012-06-07
Appendix 13 - Review and Approval
User Guide (6/9)
115
Mälardalen University
Malin Bånghammar & Marie Norling
2012-06-07
Appendix 13 - Review and Approval
User Guide (7/9)
116
Mälardalen University
Malin Bånghammar & Marie Norling
2012-06-07
Appendix 13 - Review and Approval
User Guide (8/9)
117
Mälardalen University
Malin Bånghammar & Marie Norling
2012-06-07
Appendix 13 - Review and Approval
User Guide (9/9)
118