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
2
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.
3
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!
4
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).
5
Workshop – “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)
6
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
7
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
8
Contents
1. INTRODUCTION ... 13 1.1 ABBFACTS ... 13 1.2 PROJECT INTRODUCTION ... 13 2. AIM OF PROJECT ... 13 3. PROJECT DIRECTIVES ... 13 4. PROBLEM STATEMENT ... 145. 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 PROJECT PLANNING –GANTT CHART ... 16
6.1.1 Project Gates ... 16 6.2 INFORMATION GATHERING ... 17 6.2.1 Literature Review ... 17 6.2.2 Company Insight ... 17 6.2.3 Interview Method ... 18 6.3 QFD ... 19 6.4 FUNCTION ANALYSIS ... 19 6.5 DESIGN PROCESS ... 20 6.5.1 Concept Generation ... 20 6.5.2 Concept evaluation ... 21
6.6 SUMMARY –THEORETICAL BACKGROUND &SOLUTION METHODS... 22
7. 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
9
7.10 FMEA ... 56
7.11 DESIGN PROCESS –REVIEW AND APPROVAL USER GUIDE ... 56
7.12 SUMMARY –APPLIED SOLUTION PROCEDURES ... 57
8. 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 HOW DO THE REVIEW AND APPROVAL PROCESSES FUNCTION AT ABBFACTS TODAY? ... 66
9.2 WHAT KINDS OF RESPONSIBILITY ROLES NEED TO BE INCLUDED IN THE REVIEW AND APPROVAL PROCESS AT ABB FACTS? ... 66
9.3 WHAT KINDS OF DOCUMENT TYPES AND PROJECT ROLES NEED TO BE DEFINED IN A R&DPROJECT AT ABBFACTS? 67 9.4 HOW SHOULD THE RESPONSIBILITIES IN RELATION TO THE PROJECT ROLES BE CLARIFIED AND DESCRIBED? ... 67
9.5 HOW SHOULD THE REVIEW AND APPROVAL PROCESS BE EXECUTED? ... 68
10. CONCLUSIONS & RECOMMENDATIONS ... 69
10.1 CONCLUSION ... 69 10.2 RECOMMENDATIONS ... 69 11. REFERENCES ... 71 11.1 PRINTED REFERENCES ... 71 11.2 DIGITAL REFERENCES ... 71 11.3 ABB INTRANET ... 72 11.4 ORAL REFERENCES ... 73 11.5 FIGURE REFERENCES ... 73 12. APPENDICES ... 74
10
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
11
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
12
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
13
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.
14
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.
15
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
16
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).
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.
17
Gate 1
•Planning •RequirementsGate 2
•Literature •Interviews •FACTS processesGate 3
•DesignGate 4
•Test and evaluationGate 5
•PresentationFigure 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
18
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).
19
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.
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);
20
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. 42-43).
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).
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)
Main
function
Sub function A
Sub function B
Support
function
Why?
21
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.
22
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 Weight Reference Concept 1 Concept 2
Demand 1 3 0 1 0
Demand 2 4 0 0 1
Demand 3 2 0 -1 1
Sum +1 +6
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.
23
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 aLiterature 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).
24
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 market-pull, 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. Beforeevery stage there is a gate which control quality and go/kill checkpoints forthe 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
cross-functional 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).
25
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
26
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.
27
Legend:
▲ Responsible ■ Notification ● Support ○ 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.”
28
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
29
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
30
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,
31
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 (ABB-document3, 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
32
and RH have a group composed of R&D engineers and specialists within the area
(ABB-inside3).
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.
33
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
34
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 (ABB-document5, 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).
