1) The document describes a risk management framework developed for semiconductor projects that combines elements from project management and failure modes and effects analysis. 2) The framework includes categorizing projects based on time and complexity, then applying a simplified failure modes and effects analysis process to identify risks. 3) The goal is to create a simple and easy to use risk management process that can be effectively applied in concurrent engineering environments common in the semiconductor industry.

1. Risk management framework using FMEA for concurrent and
complex engineering environments in semiconductor domain
by
Anju DROLIA
1
Anand HARDI
1
Jacques GALBRUN
2
[1] STMicroelectronics Greater Noida, India; [2] STMicroelectronics Crolles, France
Abstract
In the era of knowledge industry, risk management plays a vital role to improve the bottom line.
Business is more challenging in semiconductor Industries where product life-cycles are shorter, time-
to-market is more aggressive and uncertainty due to concurrent engineering is higher.
Post-project analysis done in our organization, indicate that majority of projects failed to control cost,
schedule & need due to weak project risk management. Silicon Defect data from problem analysis
with 8D methodology shows that Risk Management needs to be strengthened.
This Paper describes structured approach of Risk Management. We have built risk management
framework with the amalgamation of PM practices from PMBOK[1] and the FMEA[2] approach from
AIAG guidelines [6]. From PMBOK we took “what” of risk management and from FMEA we defined
“How” of the framework. We have extended this approach to establish Risk Management process by
using Boundary diagram and function analysis, which can be integrated from team level to Top
Management.
Risk management framework=f(“What” risk-management -PMBOK, “How” of FMEA)
The definition of the framework should be valid for variety of projects[3] types and complexity.
We categorize project types based on function of time and complexity-factor
Project_type = f(time, complexity-factor)
Time = 2 days-1year+ duration of projects
Complexity factor of a project is a measure of the interdependency, probability of changes and
uncertainties of elements[3]
The project needs to be analyzed according to five contexts[4], Simple, complicated, complex, chaotic
and disorder. We need to empower people and have the leverage to apply their creativity in this
complex situation[5] to move forward.
1. Introduction
In the era of knowledge industry and dynamic
market situation, risk management plays a vital
role to improve the bottom line of the
organization. Life is more challenging in
Fig 1

2. semiconductor domain where market cycles are typically shorter and the uncertainty is higher compared
to other traditional industries.
Hence if we see the characteristic of the semiconductor projects, they typically are as follows:
1. State of art; with strong R&D flavor
2. Focus on Time to market: Deadline driven
3. Concurrent Engineering: Product/Process Design, Development and Market evolving
simultaneously
4. Huge uncertainties
5. Highly knowledgeable and creative workforce
In this scenario we need a methodology which should show the value addition in the development
process and easy to use. Also from the above point we see that the Risk Management is one of the low
hanging fruit and if we can master that then we will be able to better negotiate the uncertainties and
navigate through the concurrent engineering environment.
2. Risk Management need and background
2.1. Ground Reality: Risk Challenges Today
Our organization, which has core competency to deliver highly technical products, has project manager &
teams who mainly focused on technical aspects hence there are various risk challenges being faced as
shown in the following table.
2.2. Problems’ analysis from 8Ds’ records for Risk Management needs
Ad-hoc approach
Partial or No Risk identified during project start
Major Risk Identified during project execution at
late stage when it is getting translated into an
issue
No Systematic Approach
Different approach being followed by teams which
results in ineffective Risk analysis
Risk Management is not planned hence risk
Identification is always done on crisis basis
Informal Risk Analysis e is done hence effectiveness is
person dependent
Process Awareness
Process awareness is very low in Project teams hence
risk effectiveness is not there
Project Managers lack know-how on various tools &
framework on Risk Management
Organizational Resistance
Project team's reluctance nature to share risk with next
level.
Risk exists in Project but since it is not known to
management level hence when it arrives , team tries to
avoid and it becomes issue
Project Manager develop resistance towards time
envolvement for risk management
Risk Challenges

3. Since 2010 we are collecting the different root causes of our problems. The collection is based on the
problem solving reports as issued from the 8D analysis (for Problem solving methodology) and in
particular from the 8D(D4)-Root cause analysis.
The Root cause analysis refers to the (n)WHYs methodology invented by Taiichi Ohno.
For each problem we collect at least 4 root causes: Technical occurrence root cause (TORC), Systemic
occurrence root cause (SORC), Technical escape root cause (TERC) and Systemic escape root cause
(SERC). There can be more in case of cause conjunction.
Problems analyzed are confirmed non-conformities (NCs) to the product requirements.
We use the "Pareto analysis” to quantify and rank the different causes of our NCs.
Domain expert as 8D specialists have categorized the root causes.
Risk management, by Design FMEA in our case, is in the SORC category since it is a mean to improve
design quality not a NC at a physical point of failure which is a TORC nor a mean to detect the NC once
introduced in the product.
The data covers nearly 3 years, from 2010 to 2012.
The rolling or cumulative distribution gives the same result. (See graphic below)
For the above analysis we strongly foresee the necessity to improve risk management in product design
and development in our organization.
3. Risk Management Framework: Concept
In-order to build practical and customized process which can be easily adapted in concurrent environment
and is also able to ensure effectiveness, we have considered following parameters
- Simple & Easy to use: There has been lot of discomfort among Project Managers to follow a
complete Risk Management process using different PM Tools which requires them to spend
sufficient time in understanding themselves & then coaching the team and even then team fear

4. Project
Categorization
Risk
Management
Risk Assesment
with un-certainty on its effectiveness. Hence keeping this view in mind, we have tried to make the
process much simpler and customized to current environment
- Simplified Process: we have used Standard FMEA approach which is already being followed in
the organization as a part of Quality standard. This approach reduces the detailed coaching
needs for project team hence simplifying the process.
- Effectiveness: For the effectiveness, we have provided standard look-up table to the project team
after doing detailed functional analysis on various project data, so that risk identification can be
simple, short & highly effective.
3.1. Process Flow of the Risk Management Framework
3.1.1.Project Categorization.
In the first place we do not subject all the projects to the elaborate risk management
framework. We identify the projects which qualify for detailed risk management and then we
go ahead for the same.
Project_type = f (time, complexity factor) where
Time = 2 days to 1year or more duration of projects
Complexity factor of a project is a measure of the interdependency and uncertainty of the
constituent elements [3].
The project needs to be analyzed according to the five contexts [4], Simple, complicated,
complex, chaotic and disorder. We need to empower people and have the leverage to apply
their creativity in this complex situation [5] to move forward. Project Complexity can be
further classified based on cost, QMS and needs.
Project_type = f (time, complexity (cost, QMS & need))
For the sake of simplicity, currently we have taken only 3 types for complexity i.e. simple,
complicated and complex and for the time duration also we created 3 categories namely
short, medium and long term duration. Using these 3 types in both the axis we created a
simple 3x3 [fig1] matrix which can be used as a look up table for easy navigation.
Organization can have their own rule in terms of which projects they should subject to
elaborate risk management assessment and which ones can be let off with light risk
management framework.
Project_type Categorization matrix:
Complexity of Project
D
u
r
a
t
i
o
n
o
f
P
r
o
j
e
c
t
Simple Complicated Complex

5. 1 2 3
Short Term 1 1 2 3
Medium Term 2 2 4 6
Long Term 3 3 6 9
Fig 1
3.1.2.Risk Management Frame Work
Once project_type categorization is done then we proceed for developing the risk
Management framework. Having a strong product quality orientation in the organization we
build the risk management framework with the marriage of PM practices from PMBOK[1]
and the FMEA[2] approach from ISO TS 16949. From the PMBOK we took the “what” of
risk management and from FMEA we defined the “How” of the framework. We have
extended this approach to establish Risk Management process by using boundary diagram
and functional analysis, which can be deeply integrated from team level to Top
Management.
Risk management framework =
f(“What” risk management from PMBOK, “How” of FMEA )
Project Risk Management [1] includes the process of conducting risk management
planning, risk identification, risk analysis, risk response, monitoring and control on a project.
The objectives of the project risk management are to increase the probability and impact of
positive events and decrease the probability and impact of negative events in the project.
From the domain of quality we used the concept of boundary diagram analysis which is part
of the Advanced Product Quality Planning. It separates the boundary between the system
under consideration called the design system and the system surrounding the design
system called the Surrounding System.
It helps in capturing the elements outside the boundary, which may become potential
Causes of failure with unwell Effect. Also included are the Sub systems/ Components that
need clearance from the system under consideration.
Using the boundary diagram and function analysis we created a set of look up tables to
identify and fill up the risk management frame work. These look up table help the
operational project managers to identify the risk and its impact very quickly. The elaboration
of the table is illustrated in the case study.
4. Risk Management Case Study
a. Project: As described above, we first identified one project which is considered to be highly
critical and needs detailed Risk management. There is a new technology development program
launched for key customer. This program demands aggressive specifications against market

6. competitiveness and very tight timelines to gain time to market benefits. Under this program, our
design unit needs to develop four product deliverables. Project Complexities & complication
involves following challenges.
New technical Challenges & specifications, requiring competitive solutions in the market
Technical Solution needs to be reusable as much as possible to take care of future
market needs
Frequent changing of Customer requirements
Highly un-stable & immature Technology
Two products (out of four products) being outsourced with two different companies
Communication Management complexity with different teams
Procurement handling
New methodologies to be introduced for development optimization needs
Aggressive time line of Project completion within 9months
b. Scope Detailing: Once project is identified, next step is to perform detailed project scope
analysis. Thus analyzed items can be further classified in two categories. Items which are linked
with product deliverable specifications are considered as part of Design FMEA and items which
were linked to product development to ensure product delivery are considered to be part of
Project Risk Analysis.
Design FMEA is a separate risk assessment practice being followed in our organization. Here we
are talking about Project Risk Management using FMEA approach hence once project scope
detailing is done, we are now able to identify specific scope which will be applied at IP/Library
level for risk assessments.
c. Define the Team: As per project scope needs, we identified following project Risk Analysis team
TEAM Attendance Reason
Team Leader M Project Team
Design FE Expert M
Design BE Expert M
Verification Expert M
Methodology Responsible M New Methodology
Technology Expert M New Technology Platform,New Design Flow
Design Flow Expert M
Customer representative X Changing specifications
QA Manager or FMEA
Expert
M FMEA process + procurement flow
Test Expert M IP Qualification
Design flow user X New Platform
M: Mandatory X: optional
Considering project complexities and having diversified FMEA teams in different locations,
First analysis is conducted at 3 different levels.
- 1st level: Functional Analysis to be done with internal project team
- 2nd level: Functional Analysis with external project team
- 3rd level: Functional analysis with technology, design flow & customer representatives.

7. d. Risk Identification: Next and most important step is to identify all possible risks
In-order to ensure the effectiveness of this step, we have done deep brain storming with various
Project Teams, PM & Quality Experts and tried to identify different failure modes existing in a
typical & complex project development cycle.
From the outcome of these discussions done at various levels, we could define a generic lookup
table which can be easily filled up or updated by project leader and it helps them to quickly
identify all possible failure modes as per their project complexities.
This functional analysis table describes project risk in 3 categories- need, schedule & cost. Any
risk realization will result in project failure in need, schedule or cost.
Below is the snapshot of functional table application for our current project
Item Function When How much (acceptance criteria) Failure Mode
Need
Align to Customer
requirement
MAT05 functional requirements partial functional specs
MAT05 safety requirements No specs
partial safety specifications
MAT05 Reliability requirements No specifications
partial mission profile specs
MAT05 Application Backward compatibility un-intended integration issue at SOC
Align to Technology
Requirements
MAT05 Compatibility to Platform specification,
Manufacturing Yield
partial specification
in-correct specifications
Align to CAD Flows compatibility to Flow Specifications partial specifications
Align to new
methodologies
MAT05 New Infrastructure, new development &
validation process
Process not defined
Process not reviewed
Prototype testing missing
Align to additional
needs for other
divisions
MAT0 -
MAT10
As per benchmarking/history statistics Not taken care
Partially done
Outsourcing model MAT05 -
MAT10
Licensing needs licensing needs defined
licensing needs partially defined
Data/Disk accessibility rights process process not defined
process defined partially
communication & reporting work model Process not defined
process defined partially
Schedule
Align to customer
requirements
MAT05 deliverable milestone needs partial milestones
un-intended milestones
Aligned to new
methodology needs
MAT05 Critical milestone needs no milestones
partial milestones
un-intended milestones
Manage pre-
requisites
MAT05-
MAT10
As per project development needs Pre-requisites delayed
Pre-requisites in-correct
Manage Specification
change
MAT05 -
MAT10
Agreed updated specs Not evaluated
Not agreed
Cost
Optimized
development cost
MAT05 -
MAT10
within forecasted budget cost overshoots
monitor
development cost
MAT05 -
MAT10
within forecasted budget exceed cost
un-intended cost
monitor cost of poor
quality/wastage
MAT05 -
MAT10
pre-requisite quality cost exceeds
Customer Defect cost exceeds

8. Item Function When How much (acceptance criteria) Failure Mode
Monitor skill set
versus Resource cost
MAT05 -
MAT10
as per agreed plan cost exceeds
cost not occurred
Monitor User-
training cost
MAT05 -
MAT10
as per agreed plan cost exceeds
cost not occurred
e. Risk Analysis: Risk analysis involves how project outcomes might change due to the impact of
risk event in that project. Once failure modes are identified, they are analyzed to identify
qualitative & quantitative impact of these risks on projects. We have defined following Risk
guidelines table to quantify risk impact.
Risk Severity Table:
Risk
Category
Label Value Definitions
Need
High 3 Requires decision with Platform/Customer interface
Medium 2
Requires decision with RM/PM as it impacts resource & schedules
& notification with platform/customer interface
Low 1 Requires decision at project team level but notification at PM/QM
Schedule
High 3
High delay (un-recoverable) in the critical path
or delay to customer plan (not negotiable)
or delay > 5%
Medium 2
Moderate delay in project plan
Moderate Delay to customer plan that can be negotiated or delay
up to 5% (Top Page Target)
Low 1
No Delay or insignificant delay which can be absorbed and
Customer plans not impacted
Cost
High 3 High (> 30% baseline cost)
Medium 2 Medium (> 10% but <30% baseline cost)
Low 1 Low (<= 10% baseline cost)
Risk Occurrence Table
Label Value Comment
Almost
Certain
3
Risk likely hood
Occasional 2
Rare 1

9. f. Risk Ranking & Prioritization: Next step is to rank & prioritize all risk so that high priority risks
can be accordingly assigned & planned. RPN is calculated here by multiplying SO (Severity &
Occurrence). Our Design FMEA methodology talks about severity ranking range from 1 to 9.
While in Project FMEA we have mapped these numbers into 4x1 tables
Label Value Risk Occurrence x Severity
Low 1 Low-Low
Medium 3
Low-Medium, Low-High, Medium-Low,
High-Low
High 6
Medium-Medium, Medium-High, High-
Medium
Critical 9 High-High
All risks, having RPN 6 or 9 are considered to be critical risk and needs to be planned for
mitigation & control actions.
5. Future Work :
Presently the first stage of the framework has been implemented, where we have defined the frame-
work and got the buy in from the team. We implementing above Risk Management framework on
current project (as identified above). Since Project is in Mat05 maturity, we have started with 1st step
of project scope identification and later to proceed with functional analysis.
Risk Implementation in current project will demonstrate project execution effectiveness and usage
simplicity.
Once this framework is completely demonstrated in current identified project, our next step to deploy
in other different projects and take forward it’s easy & seamless integration with Reporting system in
our organization so that it top level consolidation can be achieved.
6. Conclusion
Risk Analysis is an important aspect in the success of the project delivery, but it is seldom followed in
an appropriate way during the life cycle of the project. To overcome this we have tried to implement
the Risk Management Framework by keeping it
1. Simple: For the users, but lots of thought process goes in defining the lookup tables and
template
2. Sustainable: Since the decision points are easy to make as the good practices of PMBOK
and Quality domains are integrated
3. Value addition: Once the Management and operational PM community sees the value
addition they automatically take ownership to keep it a live document
7. List of Acronyms
MAT05 – Internal Maturity of an IP once specifications concluded

10. MAT10 – Internal Maturity of an IP, Cad Qualified
8. References
[1] PMBOK – Project Management Body of Knowledge, PMI
[2] ISO TS 16949: Quality standards
[3] Complexity Measurement: A New Comprehensive Metric for Project Management By Giuseppe Graci,
Dr. Balachandra Deshpande & David Martin, PM WORLD TODAY – FEATURED PAPER – DECEMBER
2010
[4] A Leader’s Framework for decision making by David J. Snowden and Mary E. Boone, Harvard
Business Review November 2007
[5] Project Management, Chaos theory and the Butterfly Effect By Robert Gordon & Wanda Curlee, PM
WORLD TODAY – FEATURED PAPER – DECEMBER 2010
Authors
Anju DROLIA
Anju Drolia has 14+ years of total experience in ST Micro-electronics with 8 years in
design development & project management activities and 6 years in program
management for different design groups. She is currently working as Program Manager in
SRAM Design Group.
Developing self-sustainable & highly effective PM Practices for design group is her keen
interest.
Anand HARDI
Anand has 23 years’ experience in semiconductor industry in diverse functions like
Libraries and IP development, Memory BIST, Test chip development, Silicon
qualification and Quality. He is heading CAD and Design Solutions Quality for the last
four years. His main focus currently is in quality methodologies in 8D problem solving,
Design & Project FMEA and Compliance to ISO/TS 16949 with a goal to achieve built-
in quality.

11. Jacques GALBRUN
Jacques have 30 years of experience in the microelectronic field having spent more
than 25 years with ST. He is an electronics Engineer from University Joseph Fourrier
Grenoble France.
He has publications and patent in the field.