fmea as a tool for managing risks in ict projects, based ... · fmea as a tool for managing risks...

www.ajbms.org Asian Journal of Business and Management Sciences

ISSN: 2047-2528 Vol. 3 No. 12[01-24]

©Society for Business Research Promotion | 1

FMEA as a Tool for Managing Risks in ICT Projects, based on the PMBOK

Antoniolli, Pedro Domingos UNIMEP

E-mail: [email protected]

Argoud, Ana Rita Tiradentes Terra

UNIMEP E-mail: [email protected]

Benevides, Gustavo

UNIMEP


Pires, Silvio Roberto Ignácio

UNIMEP


ABSTRACT

Project management has been consolidated into organizations due to its high

added value, allowing that project results are delivered on time, budget, scope

and quality. This is specially important for ICT projects, for which innovation is

usually present. For such, the correct resource allocation, and effective

management require application of project management techniques and tools.

In this sense, risk management enables the identification of project threats, so

that negative impacts be mitigated or eliminated. However, risk management

techniques are still not widely used by companies. In this context, this paper

objective is to evaluate the FMEA (Failure Mode and Effects Analysis) usage as

a tool for mitigating risks in ICT projects, based on the practices of the PMBOK.

This feasibility is verified by a case study in a transnational autoparts

enterprise. The results show that FMEA is an important tool to complement

risks qualitative analysis, and contributes to project success.

Keywords: FMEA, ICT (Information and Communication Technology), Lean

Production, Project Management, Risk Management. 1. INTRODUCTION

The globalization of markets has brought new dimension of competitiveness, marked by

profound and rapid changes in economic, technological, marketing, and cultural basis. This

requires from business organizations more assertive ways to respond to these requirements.

Such initiatives, according to Lima, Pereira and Souza (2009), comes from contemporary models of management, and are made possible as enterprise projects results. Thus, projects

are essential to implement new goods and services, being so importante to conclude them

succesfully.

In this sense, Festa and Assumpção (2012) argue that projects that involve ICT (Information and Communication) in logistics businesses result in "changes in processes with improved asset utilization, yielding higher productivity and quality / consistency in operations, reducing waste and delivery times ". Hartman and Ashrafi (2002) point out that ICT is one of the

fastest growing sectors in emerging countries. Van Ark (2001) complements that the ICT

diffusion in all economy áreas constitutes a prerequisite for the technology potential in

generating positive impacts into economic growth and productivity. Hagemann (2008) adds

that the period of the US economy “boom”, between 1992 and 2001, coincides with the spread of new information and communication technologies, being these elements

mailto:[email protected]





ISSN: 2047-2528 Vol. 3 No. 12[01-24]


recognized as drivers, both for economic growth and for the US productivity acceleration.

However, one factor that affects ICT projects results are the associated risks (WILLCOCKS

and GRAESER, 2001).

Carpinetti and Souza (2014) argue that the push for enterprises competitiveness requires

not only innovation, but also processes optimization and cost reduction initiatives, which

representes operational improvements, providing high quality products to increasingly

demanding markets. Taj and Morosan (2011) and Gurumurthy and Kodali (2011) explain

that the approach to implementing lean production gains importance as a mechanism for achieving organizational effectiveness. This happen due to the fact that lean focus relies in

the operational efficiency and effectiveness, reduction of non-value added activities, thus

becoming crucial for enterprises.

Womack and Jones (2003) define seven classic inneficiency types: transportation, inventory, movement, waiting, overproduction, defects and super processing. Additionally, the authors

propose five principles that guide the implementation of lean production: (1) define value

from the customer perspective; (2) identify the value stream for each product family; (3)

create a flow through the value adding activities; (4) extract value from subsequent

activities; (5) eliminate waste and pursue perfection.

Rebelato et al. (2009) argue that lean production was initially applied in the manufacturing

processes into Toyota Corporation in Japan, by the engineer Taiichi Ohno, in 1950 decade.

The authors add that, due to its effectiveness in quality improvements, these principles

were extended for other processes nature and types, generalization which is called lean

thinking. Piercy and Rich (2009) complement, explaining that both concepts and its

techniques have been increasingly used in administrative flows, called lean office, or lean service.

To Womack and Jones (2003), "lean thinking essential starting point is the value, which can be defined only by the end customer. And it is only meaningful when expressed in a specific product that meets customer needs, at a specific price and time".

Carpinetti and Souza (2014) found several studies involving lean production systems

applications in the existing literature.

Vinodh and Balaji (2011) propose a decision support system based on the fuzzy logic

concept to assist managers on identifying key constraints to waste elimination. Vinodh and

Chintha (2011) recommend a technique of fuzzy QFD to map lean attributes and enablers elements for improvement. Ramesh and Kodali (2012) proposed the adoption of Analytical

Hierarchy Process (AHP), in combination with planning objectives, to support the selection

of processes to be mapped using VSM (Value Stream Mapping) tool, according to

organization competitive priorities.

Carpinetti and Souza (2011) argue that a distinct contribution to the reduction of different

types of waste prioritization can be achieved by adapting the FMEA (Failure Mode and

Effect Analysis) technique to evaluate the waste modes. Also, the authors cite that the

FMEA is as a well known approach for product and processes quality improvements. To

Qiang (2009), the FMEA has been used as a support tool for the detection and prevention of

failures at various stages of product development, including its operational life. However, the author explain that FMEA application into administrative processes was still in the initial phase. Moreover, Sankar and Prabhu (2001), Ookalkar et al. (2009), and Inoue e

Yamada (2010) state that FMEA is a systematic approach for prioritizing and implementing

improvement actions, based on the analysis of the severity, occurrence, and ease of

detection of failure modes, thus being applied in different ways, to several contexts.

In this sense, Sawhney et al. (2010) propose the FMEA use to analyze failures in the

implementation of lean production, considering four critical resources: people, materials,

equipments and schedules. Rhee and Ishii (2003), and Von Ashen (2008) propose a cost-

oriented approach for prioritization of failure modes. Moreover, Franceschini and Galetto


ISSN: 2047-2528 Vol. 3 No. 12[01-24]


(2001) propose the use of linguistic variables and fuzzy logic to define the risk priority level.

Thus, this article aims to analyze the FMEA feasibility as a tool for mitigating risks in ICT projects, based on the practices of the PMBOK (Project Management Book of Knowledge).

The paper is structured into six sections, being the first introductory, the second discusses

the applied methodology, two subsequent (third and fourth) sections to literature review,

the fifth describes the application of FMEA into an ICT project, and the sixth is reserved to

final conclusions and recommendations for future researches.

2. METHODOLOGY

Marconi and Lakatos (2002) argue that a problem must be defined clearly and objectively.

Thus, the problem being investigated in this article is described by the question: What are the benefits of applying FMEA as a tool for mitigating risks in ICT Projects, based on PMBOK practices?

Based on this context, basic assumptions include:

Performance of risk management on ICT projects might be positively influenced by the use of tools which provide additional data for project failure modes identification;

FMEA has been proved to be, based on the reviewed literature, important lean production technical componente, applied into product and processes development;

FMEA offers, according to its characteristics and content, structured usage in risk management for ICT projects, taking as basis PMBOK defined processes.

Menezes (2000) argue that a research can be classified under four dimensions: nature,

approach, objectives and technical procedures.

These authors indicate that, with respect to its nature, a research can be considered basic

or applied. This article is classified as an applied research because it focuses theoretically in discussing the concepts and applications of FMEA on ICT project management, based on

the PMBOK.

With regard to how to approach the problem, Silva and Menezes (2000) explain that

research can be classified as quantitative or qualitative. This article is classified as qualitative research due to the method of interpreting the data, being its main focus on the

process and its meaning.

Silva and Menezes (2000) argue that, in relation to the objectives, research can be classified

as exploratory, descriptive or explanatory. This work is characterized as a descriptive survey

because it involves the available literatura review, and proposition of FMEA technique usage to support risk management on ICT projects.

Talking about technical procedures, Silva and Menezes (2000) indicate that a research can

be categorized as: bibliographic, documentary, experimental, survey, case study, research,

ex-post-facto, action research or participatory research. This research is based on concepts and techniques described in the literature, and these techniques application in a ICT

project, within an auto parts manufacturing company, being therefore classified as

bibliographic. Additionally, the characteristic of the application of these concepts in a

particular case falls into the procedures of case study.

The choice of case study is contingent and convergent with the nature of the problem, and the current state of knowledge. The following considerations justify the mehtod choice:

This study focus is the FMEA use in ICT projects risk management, being the available literature on this topic scarce;

The knowledge leve lies on development early research stages. Thus case study proves to be the most appropriate approach for the proposed research. As suggested

by McCutcheon and Meredith (1993), Yin (1989) and Eisenhardt (1989), this

approach is typical in the early stages of the development of theory, where events or

phenomena, have little or no cataloged knowledge;


ISSN: 2047-2528 Vol. 3 No. 12[01-24]


There are not yet published a precise idea of the FMEA variables that contribute to reduce negative impacts of potential risks in ICT projects. Thus, these elements

should be clarified during the research process, with continuous comparisons

between the evidence of the case and the literature. As a result, the problem detailing will be refined during the study (EISENHART, 1989);

Research the FMEA application to ICT projects requires the researcher to place the events in a chronology, to determine causal connections. By doing this, the case

study becomes the initial basis for such causal references (YIN, 1989).

Thus, this article aims to corroborate the relevance of the concepts presented in the

literature and in the industry about the PMBOK, to minimize risk impacts on projects, supported by FMEA, a technique to prevent the failures modes.

3. RISKS MANAGEMENT IN ICT PROJECTS, BASED ON PMBOK Carton et al. (2007) states that project management helps managers to standardize routines

and tasks, and ensure that available resources are used efficiently and effectively. For the

authors, the application of project management principles enables managers to establish and properly use metrics for achieving success in these projects, evidenced by comparing the project value added with the cost it consumes. Yet, according to Carton et al. (2007),

project management as a discipline is a recent concept, with little more than fifty years.

During this period, succesful practices and techniques have been included in the PMBOK

(Project Management Book of Knowledge).

Carton et al. (2007) explain that the PMI (Project Management Institute), organization

globally recognized, is the entity that consolidates such practices in the PMBOK. PMI has

branches (chapters) worldwide, as well as thousands of associated professionals.

Carton et al. (2007) argue that the PMI produced the PMBOK first version in 1987, and

since then has continually working to improve it, producing the third edition in 2000, fourth in 2008, and fifth in 2013. For the authors, the PMBOK is a set of standards (good

management practices that are common to different projects), and describe the required

competences and knowledge within the project management profession.

Kerzner (2002) argue that a project is a single enterprise, with an identifiable goal, which

consumes resources, and operates under defined conditions of time, cost and quality. The PMBOK (2013) defines project as "a temporary endeavor undertaken to create a product, service, or only outcome".

Based on this, the PMBOK (2013) argue that project management is the application of

knowledge, skills, tools and techniques to projects, to meet their requirements.

A benchmarking survey conducted by PMI in 2007, with 185 companies from various

sectors, found that 78% of organizations reported problems with their projects time, as 64%

had problems of cost, 44% identified issues / restrictions in quality, and 39% noted

problems of customer satisfaction. Additionally, types of found problems reveals that: 66%

of companies said they had problems to achieve deadlines, 64% reported communication

problems, and 62% reported constant scope changes (PMI, 2007).

The PMBOK (2013) defines five steps within project life cycle: initiation, planning,

execution, monitoring and control, and closing.

Relevant aspect described by the PMBOK (2013) is the lessons learned record, (eg.: facts identified during project execution, which serve as an important source for continuous

improvement in future projects management, due the possibility of avoiding losses and / or

inefficiencies to reach these projects goals.

To Kerzner (2006) "as the company avoids documenting lessons learned, it can quickly

regress to the immaturity in project management, because knowledge is lost, and past mistakes can be repeated".


ISSN: 2047-2528 Vol. 3 No. 12[01-24]


Project management comprises ten areas of expertise: integration, scope, time, cost, quality,

communications, human resources, risks, stakeholders, and acquisitions (PMBOK, 2013).

ICT projects usually involve some degree of innovation. Within this perspective, Henderson

and Clark (1990) categorize innovation into four groups: incremental, modular,

architectural and radical. The authors consider that incremental innovations consolidate

the company competitive position. Already radical generate real change for the industry,

probably because there is na effectiveness decrease of current business skills.

Still concerning innovation projects, Keegan and Turner (2002) and Daintry et al. (2005)

argue that new approaches that combine the existing theory on project management with

the management of the innovation process are required. Lau Kong (2006), on the other

hand, state that there are five common categories of restrictions in projects: economic,

legal, environmental, technical and social. These restrictions may, under certain conditions,

lead to risks to the project objectives achievements. For Dorofee et al. (1996), risk is considered "the possibility of loss". However, the PMBOK

(2013) considers risks as potential events that may be both benefits and costs to the project objectives. Thus, for the PMBOK (2013) a risk is "any combination of likelihood and impact, which potentially represent benefits or harm to the project's success". Chapman and Cooper

(1983), on the other hand, defines risk as "exposure to the possibility of economic or financial loss or gain, physical injury, damage, or delay, as a result of the uncertainty associated with the adoption of a course of action".

Within this perspective, the PMBOK (2013) mentions that there are three elements presente

in a risk: (1) existence of a potential event that could be translated into the loss or gain on

the project objectives; (2) the uncertainty related to the expected result, the risk of the

occurrence of this project; (3) the need to take actions with respect to this potential risk, in order to maintain the conditions for the project to achieve its objectives.

Dey et al. (2007) explain that the risk refers to future conditions or circumstances that are

beyond the control of the project team, and have an impact on this project if it occurs.

Thus, while a "issue" is an existing problem to be treated, the risk is a future problem, since

the potential has not yet been accomplished. The authors add that the degree of risk for such projects varies with the complexity, size (in terms of time and budget) and project

location.

Verzuh (2000) stresses the importance of risk management in projects, since the

application of the techniques contributes decisively for the project meets requirements of

the triple constraint (on time, within budget and with the required scope). Raz, Shenhar and Dvir (2002) complement, through research, that the risk management practices are not

widely used to conduct projects in business, being an area where further research is

required.

The PMBOK (2013) defines six main iterative risk management activities: (1) Plan risks management; (2) Identify the risks; (3) Perform qualitative risk analysis; (4) Perform

quantitative risk analysis; (5) Plan risk responses (accept, avoid, mitigate, transfer); (6)

Monitor and control risks.

Kangari and Riggs (1989) classify risk management methods into two categories: classical

models (eg.: probability analysis and Monte Carlo simulation), and conceptual models. In this sense, the authors noted that the conceptual models have two problems: (1) require

detailed information on the planning phase of the project, and sometimes the information is

not yet available, and; (2) the applicability of these models is limited to projects in which

problems are partially defined, requiring subjective evaluations, not being handled by the

classical models. Cooper et al. (2005) argue that risk management provides a consistent process for decision

support, since uncertainty with respect to the information available becomes smaller. The


ISSN: 2047-2528 Vol. 3 No. 12[01-24]


authors cite the following benefits as a result of this management: (1) risk prevention; (2)

develop contingency plans to manage the risks and impacts; (3) Improvement in the

allocation of resources (eg.: budgets and time) to these risks, and (4) Exploration of opportunities for projects.

Dey et al. (2007), on the other hand, argue that risk management can be done

systematically in three stages: identification, analysis, and risk response. Within this line,

Tummala and Leung (1999) developed a methodology to risk management that includes:

risk identification, measurement, assessment and control / monitoring of risks. Already Turner (2009) suggests as elements of risk management: evaluation of experts,

decomposition of the risk management plan, review the assumptions regarding these risks,

decision making and brainstorming to identify the risk factors affecting the project.

Chapman and Ward (2004) indicate that efficacy in risks treatment comprises in defining

the best estimate of what might happen, in what proportion, thus representing one of the key elements to adopt best practices in project management.

Dulaimi et al. (2002) and Gann and Salter (2000) address another important aspect of risk

management, including the skills of the involved stakeholders, which according to Lampel

(2001), consist of: knowledge, skills, and behaviors that these stakeholders have. Thus, the

combination of all the relevant skills is essential to manage the results of any project (FREEMAN, 2010).

For Murphy, Heaney and Perera (2011), the risk assessment is essential in identifying

factors that constrain and impact innovation projects, as in ICT projects cases.

Dey et al. (2007) with respect to ICT projects, indicate that despite the managers argue that

they conduct risks effectivelly in their projects, there is evidence that management not

occur in a systemic way. For the authors, technical risks addressing usually happen.

However, other types of equally fundamental risks, marketing and financial, there is hardly

appropriate treatment, which enhances the need for integrated risk management approach.

For the case of ICT projects, specifically software development, Schwalbe (2002) states that

the risks are classified under the following categories: marketing, financial and technical.

Thus, aspects such the degree of adhesion of the solution to customer requirements,

economic benefits the software brings, if compared to the investment required for its

development, are relevant to the first two categories. Related to the solutiion technical

feasibility issue, as well as the proper operation and availability of the solution various components, such as hardware, database, network, software, belong to the third category of risks. Dey et al. (2007) also reported that scope changes, lack of resources, poor

understanding of the problems, ambiguous requirements, and issues related to the

technical aspects of information security, are common elements presente in software

development projects, and can generate risks. For the authors, the success of the project

depends on the criteria of quality, functionality and agility of the system being delivered. Baccarini et al. (2004) identify seven categories of risks associated with ICT projects:

1. Commercial and Legal Relationship: poorly performing vendors, as well as conflicts

over the ownership of intellectual capital, and friction between clients and

contractors are some kind of risks identified under this category (JONES, 1993;

KRASNER, 1998); 2. Economic Circumstances: which implies into changes in market conditions,

competitors' actions, or even the fact that the software is no longer needed (JONES,

1993; ENGMING and HSIEH, 1994);

3. Human Behavior: understaffed and poorly qualified staff are among the risks under this category, as described by Engming and Hsieh (1994), and Yoon et al. (1994);

4. Political Circumstances: which includes low support of corporate culture, lack of support from top management, and requirements motivated by politycal aspects,

with low synergy among them (IRANI and LOVE, 2001; BARKI and HARTWICK,

1989; KRASNER, 1998);


ISSN: 2047-2528 Vol. 3 No. 12[01-24]


5. Technology and Technical Issues: inadequate documentation, software does not fit

the expected goals, low system performance, technical constraints by adopted

solution operationalization, incomplete applications and inappropriate user interface (BOEHM, 1989; BARONAS and LOUIS, 1988; JONES, 1993; ENGMING and HSIEH

1994; KING, 1994);

6. Controlo of tasks and Mangement: unrealistic budget and / or project schedule,

frequent scope uncontrolled changes, high formalization of the acceptance criteria

and or tests validation, failures in monitoring the evolution of the project, lack of

single point of ownership, poor leadership, functionality not well developed, and lack of formal change management (KRASNER, 1998; KING, 1994; BOEHM, 1989;

YOURDON, 1996; THOMSETT, 1995, CUNNINGHAM 1999);

7. Individual Activities: comprising specification in an excessive level of detail, and

unrealistic expectations regarding the adopted solution (CUNNINGHAM, 1999;

THOMSETT, 1995). Thus, as cited by Dey et al. (2007), project delays not only add costs for any penalties

imposed by customers, but also add costs from higher prices for goods and services, loss of

company image / product, and incurred opportunity costs. Additionally, the authors

consider that among the available tools for risks mapping and treatment, FMEA (Failure

Mode and Effect Analysis) is considered the most appropriate, reason why it was selected for this study.

4. FMEA AS A TOOL TO SUPPORT PROJECT RISK MANAGEMENT

FMEA (Failure Mode and Effects Analysis) consists of a technique developed in the 1950s to

prevent failures in aircraft production. The FMEA shows excellent results, so that it was applied by NASA in the Apollo project and then was commercially widespread (ALLBIEN et al., 1998). So, with focus on manufacturing projects and processes, is still in the

exploratory phase for services applications. Murphy, Heaney and Perera (2011) complement

the FMEA is a technique for mapping the risk widely used in automotive and mechanical

engineering, but little explored in other areas such as in construction projects. Also

according to Murphy, Heaney and Perera (2011), the FMEA allows the assessment of

potential causes and effects of a failure into product or process. Unlike other procedures for identifying hazards, FMEA can evaluate the criticity of a potential risk, which generates significant implications for risk management in projects. Thus, the identification of "priority risk" of a constraint allows that the stakeholder can adopt the appropriate strategy for

defining the response to this risk.

Chuang (2010) explains that the basic procedure of setting priorities for FMEA improvement

is based on the NPR (Risk Priority Number), which in turn is based on multiplying ratios of the three resulting assessment:

1. Severity that the effects of failure modes impact the client (ranging from 1 to 10);

2. Possibility of occurrence of failure modes (range 1-10);

3. Effectiveness of procedures for the detection of the modes of failure prevention

(ranging from 10 to 1, being the higher effectiveness, the lower index). Allbien et al. (1998) argue that this management tool consists of structured procedures with

the aim of analyzing the potential modes of failure of a system, using as a basis an

approach composed of the following elements (Table 1):

Function: Purpose of the system / module with the desired level of performance;

Failure Modes: Specification that may fail;

Effects: Impact over the primary function, and over customer’s expectations;

Severity of the failure effect (S), which can be very high (compromises the security or operation involves infringement of regulations), high (causes customer

dissatisfaction), moderate (causes some dissatisfaction due to performance

degradation or malfunction), low (when causes light dissatisfaction by small drop in performance);

Causes: Reasons of the failure probability. Is the root cause of the failure mode, which creates the potential for failure occurrence, described in the column "failure

mode". Causes identified as the same failure mode may have different roots.


ISSN: 2047-2528 Vol. 3 No. 12[01-24]


According to Toledo (2013), determining the root cause should be done when one of

circumstances is present: (1) the severity level is 9 or 10; (2) the result of multiplying

the severity by the occurrence is the largest FMEA result; (3) the risk is greatest of this FMEA results. However, if it is possible to eliminate the failure mode, will not be

necessary to determine the root cause;

Occurrence (O): Index that measures the probability of failure, as a result of these events impacts. Can be classified as very high, high, moderate and low. In general, it

is used an index from 1 to 10, as shown in Table 2, to determine the historic values

that may be used, even probabilistic or qualitative data. Palady (2007) argues that two questions can arrise with this analysis: "how often is the mode of failure" and "how often is the cause of the failure mode";

Controls: Are defined specific controls and systems to be used to detect each failure mode. In addition to detection controls, may have also set prevention controls to

avoid the occurrence of the failure mode;

Detection (D): Indicates the probability that a failure mode be detected (Table 3). The rating is downward, which means that higher the probability of detection, lower the

classification;

Risk Priority Number (RPN): Indicator resulting from the multiplication of S, O, D, and which determines the risk to be prioritized (which provide greater value);

Recommended Actions: Palady (2007) states that defined actions to: (1) Prevent potential problems; (2) Reduce the consequences of potential problems; (3) Increase the likelihood of early detection of the problem; (4) Provide mechanisms for early

detection of problems of high severity;

Status: Indicates the status related to mitigation / elimination of identified risk.

Table 1: FMEA Structure. Source: Palady (2007)

Table 2: Failure Mode Ocurrence Probability. Source: Palady (2007)

Failure

ProbabilityOccurrence of the Mode Rate

Very High Less or equal 1 by 1 10

1 in 5 9

1 in 10 8

1 in 15 7

1 in 18 6

1 in 20 5

1 in 25 4

1 in 50 3

1 in 70 2

Very LowThe failure is eliminated by

preventive control1

FMEA - Failure Mode and Effects Analysis

Summary

Low

Higu

Moderate

Function Failure Mode Effects

Se

ve

rity

Causes

Occu

rren

ces

Controls

De

tectio

n

RP

N

Recommended

ActionsStatus

FMEA - Failure Mode and Effects Analysis

Summary


ISSN: 2047-2528 Vol. 3 No. 12[01-24]


Table 3: Failure Detection Probability. Source: Palady (2007)

Helman (1995) emphasizes that FMEA purpose it to define actions that enable the incidence of potential causes

reduction. This is possible by prioritizing the negative impacts of these failures on the system or process

performance, which is determined by its RPN (Risk Priority Number). Palady (2007) states that FMEA is

currently a key element in quality planning due to resource optimization and high levels of satisfaction obtained

by customers. For Yang and Bai (2009), the FMEA is a reliable method for identification of failure modes, and

their effects.

According to Palady (2007), FMEA process conduction is described by the following steps (Figure 1): describe

the product or process; define functions; describe the potential failure modes; describe the effects of failures;

determine the causes; define the controls methods or current controls; calculate the risks; define actions; assess /

evaluate the results.

Figure 1: FMEA Process Conduction Steps. Source: Palady (2007)

Detection

Opportunity

Probability of Detection

through Process ControlRate Detection Probability

No Detection

Opportunity

No Process Control. Can not

detect.10 Virtually Impossible

Problem

Detection after

Processing

Problem

Detection at

Source

Problem

Detection after

Processing

FMEA -Failure Mode and Effects Analysis

Detection of the failure mode

after processing by the

operator through visual,

auditory, tactile way.

Detection of failure mode at

the station by the operator

through visual, audible, tactile

way.

8

6

Remote

Very Low

Detection of failure mode post

processing activity by operator,

who will prevent further

processing

4 Moderately High

Identify FailureMode

Identify FailureEffects

Identify FailureCauses

Evaluate Detection

Evaluate Detection

Determine RPN

Determine Action

Evaluate Controls / Detection Ways


ISSN: 2047-2528 Vol. 3 No. 12[01-24]


Siqueira (2005) states that if the FMEA application is not conducted in a structured

manner, complying with the predefined steps, there may result in increased complexity,

even for the same component may be different failure modes, and different causes acting, causing recommendations development for several actions, some of them not connected

with the correct failure mode cause, being thus unnecessary or superfluous. Palady (2007)

indicates that there are two types of FMEA:

Project and Process oriented, for the development of product and

process, respectivelly.

On Design FMEA (Design Failure Mode and Effects Analysis - DFMEA), the focus is on

finding flaws in the product design and specification, while the Process FMEA (Process

Failure Mode and Effects Analysis - PFMEA) considers potential flaws in the execution of the process, compared to its specification (SILVA et al., 2008).

Murphy, Heaney and Perera (2011) argue that an essential element that helps on the risks identification consists in defining the scope of the project (including its product, for some

cases) on many levels as necessary for the correct identification of these risks. Thus, the

WBS (Work Breakdown Structure) can be used as basis for this purpose, especially during

the project planning phase. The authors stress, however, that the identification of risks is

based on stakeholders tacit and / or subjective judgment. Thus, the authors suggest that the FMEA document be shared with participants for further relevance check, description,

and mainly because of the constraint, and the effect of this restriction on the project.

For the application of FMEA in risk management projects, and in accordance with the

PMBOK (2013), it is necessary to follow the procedures for qualitative and quantitative risk

analysis. In this sense, the recommendation is that after the qualitative risk analysis, risk categorization (and their identification of severity), a standard FMEA procedure be

established, which consists, according to Murphy, Heaney and Perera (2011) and Palady

(2007), in four stages:

Stage 1 - Risk identification: described by the project life cycle (eg.: initiation, planning, execution, monitoring and controlling, closing) as well as the workstream

/ dimension being managed (according to the work package in the WBS ), number of risk / restriction, and the risk impact on the project.

Stage 2 - Analysis: Identification of potential failures, with their specific causes and effects.

Stage 3 - Definition of the RPN (risk priority number): Based on the risk probability and impact, obtained in qualitative risk analysis, establish the probability of

detection and hence the corresponding RPN.

Stage 4 - Prioritization: comprising the prioritization of actions to be taken, and the management response to the actions (with contingency and mitigation plans

associated).

Then performing the quantitative analysis based on PMBOK (2013), with PFMEA

specification, as described by Palady (2007).

5. FMEA for ICT Projects

The FMEA method proposed in this paper, called PJ-FMEA, focuses on the identification of the risk modes in ICT projects, and the prioritization of actions to eliminate these projects

risk modes. Thus, their use helps on this projects planning actions improvements.

This proposal development consists in defining a checklist of modes (or types) of risks,

adapting the scales for severity, occurrence and ease of detection, and the procedure for

setting the priority level of risk. The PJ-FMEA was used as a support tool in the implementation of an ICT project's Autoparts Ltd, as stated on Figure 2.


ISSN: 2047-2528 Vol. 3 No. 12[01-24]


Figure 2: FMEA Usage on ICT Project Risk Management. Source: Adapted from Souza and

Carpinetti (2014)

CurrentSeverity

ResponsePlans

FutureSeverity

PJ-FMEA - Risk Mode and Effect Analysis - Project A (ICT)

WorkstreamWorkstream

DescriptionRisk Mode Risk Mode Cause

Ocu

rren

ce

Det

ecti

on

Consequence /

Effect

Seve

rity

RP

N

CP

N

Pri

ori

ty Risk Response /

Recommended

Actions

One failure modes checklist for ICT projects was defined, based on the existing literature, as

described in Table 4.

Table 4: Risks Modes for ICT Projects.

Risk Type (Mode) Risk Cause Type (Mode) References

1. Commercial and Legal Relationship 1.1 Desempenho do Fornecedor Inadequado Krasner (1998)

1.2 Litígio na proteção da propriedade intelectual Krasner (1998)

1.3 Fricção entre clientes e fornecedores Jones (1993)

2. Economic Circunstances 2.1 Changes on Market Conditions Jones (1993); King (1994)

2.2 Competitor's Actions Thomsett (1989); Jones (1993)

2.3 System is no longer needed Engming and Hsieh (1994)

3.Human Behavior 3.1 Lack of Staff

Abdel-Hamid (1989); Abdel-Hamid and

Madnick (1991); Engming and Hsieh

(1994)

3.2 Low Quality Staff

Cooper (1993); Yoon et al . (1994);

Fuerst and Cheney (1982); Nelson and

Cheney (1987)

4. Political Circunstances 4.1 Corporative Culture not Supportive

Irani and Love (2001); Engming and

Hsieh (1994); Leitheiser and Wetherbe

(1986)

4.2 Lack of Executive SupportLeitheiser and Wetherbe (1986); Barki

and Hartwick (1989)

4.3 Set of unrelated requirements Krasner (1998)

5. Technology and Technical Issues 5.1 Inadequate Documentation Boehm (1989)

5.2 Solution does not meet the required purpose Baronas and Louis (1988)

5.3 Low system performance Jones (1993); Glass (1998)

5.4 Limitations of Technical Solution Boehm (1989); Jones (1993)

5.5 Incomplete Requirements Shand (1993); Engming and Hsieh (1994)

5.6 Inappropriate user interface Jones (1993); King (1994)

6. Project Management and Control 6.1 Unrealistic project schedule and BudgetKing (1994); Krasner (1998); Bohem

(1989); King (1994); Turner (1999)

6.2 Constant change requests by Customers Jones (1993); King (1994); Clancy (1994)

6.3 Lack of acceptance criteria for testing and for

solution validation, by client.Boehm (1989)

6.4 Failures in the daily progress review Clancy (1994); Yourdon (1996)

6.5 Lack of unique accountability pointFuerst and Cheney (1992); Thomsett

(1995)

6.6 Poor Leadership King (1994); Clancy (1994)

6.7 Development of system functionality incorrectly Boehm (1989)

6.8 Lack of Formal Change Management ProcessJones (1993); Davis and Olson (1984);

Cunningham (1999)

7. Individual Activities 7.1 Excessive specificationsBoehm (1989); Turner (1999);

Cunningham (1999)

7.2 Unrealistic expectations Thomsett (1995)


ISSN: 2047-2528 Vol. 3 No. 12[01-24]


Table 5 shows a qualitative description of the severity of the impact mode risk for ICT

projects, considering different levels in a scale of 1 to 10. The definition of the contents, however, was based on the existing literature on FMEA (OOKALKAR et al., 2009; INOUE

and YAMADA, 2010).

Table 5: Severity Indexes for ICT Project

Table 6 presents a qualitative and quantitative description of the risk ocurrence mode for

ICT projects, and was based on the literature available on FMEA (INOUE and YAMADA,

2010; KUMAR and CHATURVEDI, 2011), but with adaptations for managing risks in ICT

projects. In this regard, a variable adapted specifically for this study refers to the time

period used as sources for the allocation of occurrence in ICT projects, which is three years.

Table 6: Possibility of Risk Ocurrence on ICT Projects

Severity

IndexSeverity Qualitative Description

1No Impact - There is little tightening restrictions on the project, with no impact on

quality, cost, time and scope.

2Low Impact with no Relevance - there are delays and / or additional costs, without

influencing the project goals nor the baseline with respect to cost and time.

3

Low Impact with Low Relevance - no small loss to the project objectives, requiring

rework or minor corrections in project deliverables, no additional time or budget are

needed.

4

Impacts on work packages without generating delays and / or additional costs - there

are delays in activities that are not on the project critical path. Additionally, it can

involve impacts to other project resources, but without affecting deadlines, budget

and scope.

5Very Low impact on project objectives - affect cost, time and / or scope, and require

actions from manager to achieve the project goals.

6

Low impact on project objectives - affect cost, time and / or scope, and require actions

from manager to achieve the project goals. It might require that the project change

management process be put into practice.

7

Medium impact on project objectives - affect cost, time and / or scope, and require

actions from manager to achieve the project goals. It requires that the project change

management process be put into practice, with sponsors approval of these changes.

8

High impact on project objectives - affect cost, time and / or scope, and require actions

from the project manager to achieve the project goals. The impact entails delays and /

or significant increase in costs, and can be translated into the project loss of

functionality. It requires a project change management, contingency planning, and

approvals process.

9

Very high impact on project objectives, with unrecoverable losses possibility - affect

cost, time and / or scope, requiring action by the manager to achieve the goals

(revised) for this project. The impact entails delays and / or significant increase of

costs, and represent loss of functionality in the project. It require the project change

management, approvals, contingency plan, and review of new goals for the project

continuity.

10

There is no project continuity - the impact on costs, time, and / or scope is so severe

that there is no chance for recovery. It requires that the project closing process br put

into practice.


ISSN: 2047-2528 Vol. 3 No. 12[01-24]


Table 7 presents a qualitative and quantitative description of procedures for the risks

detection modes (causes) in ICT projects, and was also based on the scores obtained in the literature, but with adaptations.

Table 7: Scale of Risk Detection Type for ICT Projects

Detection

IndexQualitative Description Quantitative Description

1The cause of the risk will certainly be detected before it

occurs.

Detects and avoids the

occurrence 100% of the

time

2Very high possibility of detecting the cause of the risk before

it occurs.

Detects and avoids

occurrence 85% of the time,

and only detects for the

remainder

3High possibility of detecting the cause of the risk before it

occurs.

Detects and avoids



remainder

4 There is great chance to detect the risk before it occurs

Detects and avoids



remainder

5 There is little chance to detect the risk before it occurs.

Detects and avoids



remainder

6 There is very little chance to detect the risk before it occurs.

Detects and avoids



remainder

7

There is no risk cause prevention mechanism, but there is a

process of risk monitoring and control during the project, in a

systemic way.

Does not prevent the risk,

but detects 90% after the

occurrence, before

affecting the project

objectives

8

There is no risk cause prevention mechanism, but there are

actions for risks monitoring and control, wth no maturity level

to ensure repeatability, procedures and frequency required

for effective management.



occurrence, before


objectives

9

There is no risk cause prevention mechanism, and actions for

risks monitoring and controlling are sporadic, without

showing maturity level that ensures the effective

management of project risks.



occurrence, before


objectives

10There is no risk cause prevention mechanism, nor

systematized actions for monitoring and controlling risks.

Detects less than 1% of the

time, and the risk usually

affects the project

Occurrence

IndexQualitative Description of Risk Ocurrence

Quantitative

Description

1

Very Rare - even experienced project managers find no

records of this risk in previous projects, during specified

period.

Almost no ocurrence

chance (0,1 %)

2

Unlikely - Experienced project managers found one

occurrence described in projects carried out in the specific

period.

Chance less than 1%

3

Small Chance of Occurrence - Experienced project managers

found few records in documented projects in the given

period.

Occurrence Chance

between 1% and 3%

4

Moderate Chance of Occurrence - Experienced project

managers found few cases reported in the documentation of

projects in the given period.

Ocurrence Chance

between 3% and 5%

5Few Occurrences - Project managers found few reported

cases in projects conducted in certain period.

Ocurrence Chance

between 5% and 8%

6

Considerable Number of Occurrences - Project managers

found multiple occurrences in projects conducted in certain

period

Occurrence Chance

between 8% and 15%

7Often Occurs - records are obtained from this type of risk in

most projects in a given period.

Occurrence Chance

between 15% and

25%

8Occurs Very Often - project managers found record of this

type of risk in most projects in the given period.

Occurrence Chance

between25% and

35%

9Almost Allways Occurs - project managers identify record of

these risks in almost all projects conducted in certain period

Occurrence Chance

between 35% and

50%

10Certain Possibility of Occurrence - managers always identify

this type of risk in previous projects at any given time

Occurrence Chance

above 50%


ISSN: 2047-2528 Vol. 3 No. 12[01-24]


The PJ-FMEA was based on the standard procedure for FMEA application (columns of PJ-

FMEA):

Workstream / Work Package: Identifying the scale of the project where the risk falls;

Workstream Function: description of the main purpose of the work package;

Risk Mode: Identification of risk mode guided by the checklist shown in Table 4;

Risk Mode Causes: description of the possible causes of the risk mode;

Ocurrence: Index of the cause of the mode of risk ocurrence, based on Table 6;

Detection: easy of risk failure mode detection index, based on Table 7;

Effect of Risk Mode: Description of the effects of the risk mode in the project;

Severity of the risk mode: The mode index of the risk severity, based on Table 5;

Risk Priority Number (RPN): Calculation of NPR based on the criteria of: severity, occurrence and detection, discussed later (Equation 1);

Cause Priority Number (CPN): Calculation of the number that indicates the priority of the cause, related to different RPN. This issue will be discussed below (Equation

2);

Priority Analysis: Based on the calculated index, defines the action priority level with respect to this risk response.

The risk failure mode identification is supported by the application of the Delphi technique

and Ishikawa Diagram, in order to search the root cause of the risk. The severity (S),

occurrence (O) and detection (D) indexes were based on qualitative and quantitative descriptions in Tables 5 - 7, respectively. Descriptions of the effect of the mode of risk were

complemented for the content presented in Table 5.

Based on the required information to calculate the priority number, the project team

estimates the RPN, based on equation (1):

In addition to calculating the RPN, was defined by the project team that, because of the

possibility that some causes are responsible for more than one type of risk in ICT projects,

it would be important to define a index which measures causes importance on the most

severe risk types. To make this identification, it was suggested to use a second indicator, the CPN (Cause Priority Number), associated with each cause of risk, defined as the sum of

the CPN to all risks caused, at least in part, by a particular cause. This index is described

by equation (2):

Based on these definitions, was done na application of the PJ-FMEA for one ICT project,

described in the next section.

5. CASE STUDY 5.1 The Company

The Autoparts Ltd is a transnational auto parts company, with US headquarters. It has

thirty plants in the world, ten in the country of origin, with a presence on all continents. The company has about 60,000 direct employees. The annual demand for your main

product is 180 million units.

In Latin America, there are eight business units, considering plants and sales offices,

located in Argentina, Uruguay, Chile, Brazil, Colombia, Venezuela, Peru and Mexico.

In Brazil, the Autoparts Ltd has been present since late 1930s, and currently has two

plants, four sales subsidiaries, five automotive centers, and approximately 4.000 direct

employees. It has a distribution network comprising 150 distributors and about 560 sales

points.


ISSN: 2047-2528 Vol. 3 No. 12[01-24]


The project subject of this paper case study deals with the componentes production process

automation, inside a manufacturing unit which produces 40,000 daily units of the main

product. 5.2 The Production Process

The production process consists of three main steps, as shown in Figure 3:

a) Components Preparation (1st stage): This stage involves the homogenization of raw

materials to generate the compound, basic material to be used into calendering and

extrusion processes, to generate the remaining components of the main product. As a result of the calendering, are generated about 15 different components

(Components Type1). As a result of the extrusion, 5 different components are

generated (Components Type 2);

b) Building (2nd Stage): comprises product assembling, that is, in this step the various

components are added to the main product for subsequent curing process; c) Curing (3rd Stage): Final step of the manufacturing, in which the product receives

its final conformation and properties, thus being concluded.

Figure 3: Autoparts Ltd Productive Process

5.3 The Project

This project scope, named Project A, consists in developing a solution of ICT (Information

and Communication) to:

Perform raw materials transfer from raw materials warehouse (A) to consumption warehouse (B), this latter located at the production starting point. This transfer

occurs by means of bar codes reading, and consequent inclusion on the corporate ERP – Enterprise Resource Planning (SAP). For this process, the concept of FIFO

(First In First Out) was observed;

Automatic raw material stock consumption, in mixing, calendering and extrusion processes, by reading barcode label material, and consequent registration in MES

(Manufacturing Execution System), ando n SAP.

For this project implementation, was selected a multifunctional team, with participants

from logistics (5), Manufacturing (8), Engineering (3), Finance (3), and IT (5), besides three

partners companies, being one for developments in SAP ERP, other to do adjustments to

the MES system, and the last to make integration of plant floor systems with global

manufacturing systems.

The development adopted methodology for the project was based on the PMBOK (PMI,

2013). Minor adjustments were made to follow guidelines of the Company PMO (Project

Management Office). This project implementation took eight months of duration, and a

budget of US$ 500,000.

The communication with stakeholders process consisted of weekly meetings, both to

monitor the project evolution, and also for in progress tasks review, risks and issues status.

These meetings were conducted remotely, using collaborative software (Webex). Meetings

with project sponsors were held monthly. Were mapped 27 direct stakeholders involved on

this project.


ISSN: 2047-2528 Vol. 3 No. 12[01-24]


Main identified project workstreams include: ICT, Change Management, Raw Material and

Inventory Control, Production Automation, Master Data.

The risk management adopted framework was the PMBOK (PMI, 2013), considering the

FMEA as na instrument to complement the qualitative risk analysis process (Figure 4).

Figure 4: Project Risk Management Processo n Autoparts Ltd

Figure 5 details the Project A Risk Matrix, resulting from the qualitative risk analysis, identifying impacts,

probabilities and severities for each risk. The procedure used to perform qualitative risk analysis was based on

the Delphi technique, described in the PMBOK (2013).

Figure 5: Project A Risk Matrix

4,67Number of Risks Severity Severity After Mitigation

6 15 5

Risk

NbrRisk Description Probability Impact Impact Area Responsible Mitigation Plan

Probab. After

Mitig

Impact After

MitigMitigation Cost Contingency Contingency Cost Status

Risk Index

Initial

Risk Index

Mitigated

1Delays in the preparation of master data for

Project Go LiveMedium Medium Scope

Master Data

Leader

Prepare in advance the required data for

system operationsLow Medium -$

Prepare data products that

will be used in the month of

Go Live Project (partial)

Mitigated 9 3

2Possibility of delays in the systems interface

deploymentHigh High Scope ICT Leader

Add resources to perform parallel

developmentMedium High 10.000,00$

There is no contingency. If

no interface, project delays100.000,00$ Mitigated 25 15

3Lack of preparation from business staff to

operate the systemMedium High Schedule

Change

Management

Leader

Establish communication plan with

metrics on the level of involvement /

preparation

Low Medium -$

Conduct training for

recertification in the month

of go live

10.000,00$ Mitigated 15 3

4Possibility of Project Allocation of Employees

with Low Qualification / Preparation Medium Medium Deliverables Project Manager

Constant evaluation (weekly) of employee

performance. To establish a replacement

plan with Consultancy

Low Medium -$ -$ Mitigated 9 3

5Possibility of problems in defining access

profiles to the new featuresMedium High Deliverables ICT Leader

Perform unit and integrated testing in QA

environmentLow Low -$

Availability of IT Risk

Analyst during Go Live-$ Mitigated 15 1

6Possibility of problems with system performance

(slow)Medium High Deliverables ICT Leader

Perform stress test on approval

environment systemLow Medium -$

Adjusting programs with

low performance after Go

Live

15.000,00$ Mitigated 15 3

Project A

Index of Mitigated RiskProject Name

Project Manager

Risk Response Plan

After Project Risk Matrix elaboration, was done the categorization of the risks (Figure 6),

based on the results of the qualitative risk analysis, after mitigation procedures properly mapped, and agreed among the project team and key stakeholders.

Figure 6: Project A Probability x Impact Matrix

Based on the qualitative risk analysis results, all six risks were selected to the application

of PJ-FMEA, according to Apendix I.

I

m

p

a

c

tHigh - 5

2. Possibility of delays in the

systems interface deployment

Medium - 3

1. Delays in the preparation of

master data;

3. Lack of preparation from business

staff;

4. Allocation of low Qualification

Staff;

6. Problems with system performance

> 25% 75%

Low - 15. Possibility of problems in

defining access profiles to the

new features

Probability


ISSN: 2047-2528 Vol. 3 No. 12[01-24]


5.4 Results Analysis

From the establishment of the qualitative analysis, meetings were conducted with

participation of the project team, and stakeholders are aware of the risks, to identify the root cause of these modes of risks.

The results show that there is a concentration of the causes of the risks, as follows:

1. Commercial and Legal Relationship: inadequate supplier performance was the only

identified cause of the risk of late delivery of the system interfaces. While this is an

important cause to risk mitigation / elimmination, was classified as low priority; 2. Economic Circunstances: No causes of risks associated with this type of project in

ICT have been identified. This fact is due in part to the characteristics and nature of

the project, since it is project focused on improving internal operations;

3. Human Behavior: In this type of risk the low quality of staff is present in four of the

six identified risks (67%), being considered of high priority for these three. Additionally, lack of personal was identified in two (33%), rating medium priority in

both;

4. Political Circunstances: The greatest cause mode considered was the lack of

executive support, present in three (50%) of the six project risks. This fact may represent, according to Kerzner (2006) and Neves et al. (2009), that the organization

does not have a high maturity level in project management. However, this risk mode was considered as medium-impact in all three instances;

5. Technology and Technical Questions: The cause with the highest incidence was the

incomplete requirements, present in three (50%) of the six risks, and considered a

high priority at all. Inadequate documentation is presente in two risk (33%), yet both

were considered as medium priority. Technical limitations of the solution was

defined as medium priority, whereas the solution presents technical limitations low priority for risk 2, and average risk priority;

6. Project Management and Control: Cause mode with higher incidence was poor

leadership, present in three (50%) of six risks, being considered a medium priority

for two risks (1 and 4) and with high priority for risk 3. Lack of a single point of

"accountability" is displayed as the cause of two types of risk (1 and 3), both considered as low priority. Cause "failures in daily review for progress" is found as

the cause of two risks (1 and 2). However, the risk to 1 (delays in the preparation of

master data) is considered a high priority, whereas for risk 2 (possibility of delays in the availability of interfaces), is considered a medium priority. In additon, "schedule and budget of the project unrealistic" is found in two opportunities, risks in 2, 4

(possibility of employees with low qualification / preparation for the project), both bieng considered as medium priority. The "development of system functionality incorrect" was identified only in risk 6 (possibility of problems with the performance

of the system), and even then categorized as low priority; 7. Individual Activities: “Unrealistic Expectations” was considered the cause with

greater occurrence, being present in 2 cases (33%), risks 1 and 6. For both is

considered low priority.

Related to risks individual analysis, were identified the following priority causes, for which might be developed action plans. For risk 2, based on the impact identified as resulto f the

qualitative analysis, a contingency plan might be developed.

1. Delay in máster data preparation of master data: were considered as priority causes:

low quality of staff (1008 points), incomplete applications (1176 points), and failures

in daily progress review (1152 points). For each of the causes, was proposed an

action plan, as detailed in Appendix I; 2. Possible delays in the availability of interfaces: Again the low quality of staff was

identified as a cause of high priority (1008 points). Incomplete applications also

appears as a priority issue (1176 points). For both actions was defined plan as

Appendix I;

3. Lack of preparation from business staff to operate the system: Poor leadership was identified as a priority issue (1008 points). This fact may indicate that the

organizational change management process is not currently being applied in the

Company;


ISSN: 2047-2528 Vol. 3 No. 12[01-24]


4. Possibility of employees with low qualification / preparation for the project: Was

considered the primary cause: low quality of staff (1008 points), strengthening the

hypothesis that this is a major cause to be confronted by the leadership; 5. Possible problems in defining profiles: incomplete requirements figure as the cause

of higher priority (1323 points);

6. Possible problems with system performance: this item does not present causes with

high priority. Identified as a medium priority, it is only the technical limitations of

the solution (540 points).

Thus, based on qualitative analysis and complementation by PJ-FMEA, was made the risk

quantitative analysis. However, rather than considering only the risk 2 (based on the

qualitative analysis stated by the PMBOK), were also included risks 1, 3 and 4, due to their

criticity presented as PJ-FMEA results.

6. CONCLUSIONS

This paper first introduced the main concepts of FMEA and project management, based on

the available literature. From this analysis, was proposed an adaptation of the FMEA

technique, adjusting it for risk management in projects, called PJ-FMEA. Following this

proposal, these FMEA procedures were applied to an ICT project, within an auto parts

company. This project scope consisted of automated functionality for raw materials consumption, and reporting of semi-manufactured products, which involved integration of

this company information systems (specifically an ERP with a MES solution). For this

project, six potential risks had been identified, and qualitative analysis pointed as high

impact and high probability the risk 2 (possibility of delays in the interface between

systems). The application of PJ-FMEA, however, based on all risks evaluation and on failures modes found in the available literatura, identified as main causes of risks three

additional causes, for which a set of actions to mitigate or eliminate such effects on project

objectives were done.

Thus, based on Womack and Jones (2003) and Rother and Shook (2003), the main objective

of the implementation of lean practices is to eliminate inefficiencies. The contribution of the FMEA technique in risk management enabled the identification of root causes to various

risks, which were treated fairly, generating added value in conducting projects, especially in

avoiding rework, delays and defects, with impacts on cost, time and scope the project.

This study, however, does not intend to close the subject, rather it is an empirical analysis, which requires further clarification, since it is a descriptive research within the field of

project management, with application to a single case, and under specific conditions.

Moreover, the similarities of FMEA with the requirements of best practices described in the

PMBOK, complements the qualitative risk analysis, and become relevant as contribuition to

the field of project management.

REFERENCES ALLBIEN, E.; GROT, U.; SCHNEIDEREIT, U. (1998), “The new method of the quality

system”. Industrial Engineering and Management, Vol. 5, pp. 18-21.

BACCARINI, D.; SALM, G.; LOVE, P. E. D. (2004), “Management of Risks in Information

Technology Projects”. Industrial Management & Data Systems, Vol. 104, No 4, pp.

286-295. BARKI, H.; HARTWICK, J. (1989), “Rethinking the concept of user involvement”, MIS

Quarterly, Vol. 13 No. 1, pp. 43-63. BARONAS, A. M. K.; LOUIS, M. R. (1988), “Restoring a sense of control during

implementation: how user involvement leads to system acceptance”, MIS Quarterly,

Vol. 12 No. 1, pp. 111-23. BOEHM, B.W. (1989), “Software Risk Management”, IEEE, Computer Society Press,

Washington, DC. CARTON, F.; ADAM, F.; SAMMON, D. (2007), “Project management: a case study of a

successful ERP implementation”, International Journal of Managing Projects in

Business, Vol. 1 No. 1, pp. 106-124.


ISSN: 2047-2528 Vol. 3 No. 12[01-24]


CHAPMAN, C. B.; COOPER, D. F. (1983), “Risk analysis: testing some prejudices”, European

Journal of Operational Research, Vol. 14, pp. 238-47. CHAPMAN, C.; WARD, S. (2004), “Why risk efficiency is a key aspect of best practice

projects”. International Journal of Project Management. Vol. 22, p.619-632.

CHUANG, P. (2010), “Incorporating disservice analysis to enhance perceived service quality”,

Industrial Management & Data Systems, Vol. 110 No. 3, pp. 368-391. CUNNINGHAM, M. (1999), “It’s all about the business”, Inform, Vol. 13 No. 3, p. 83.

DEY, P. K.; KINCH, J.; OGUNLANA, S. O. (2007), “Managing risk in software development projects: a case study”, Industrial Management & Data Systems, Vol. 107 No. 2, pp.

284-303. DOROFEE, A.; WALKER, J.; ALBERTS, C.; HIGUERA, R.; WILLIANS, R. (1996), “Continuous

Risk Management Guidebook”. Pittsburgh, PA: Software Engineering Institute,

Carnegie Mellon University. DULAIMI, M. F.; LING, F.; OFORI, G.; DE SILVA, N. (2002), “Enhancing integration and

innovation in construction”, Building Research and Information, Vol. 30 No. 4, pp.

237-47. EISENHART, K. M. (1989), “Building theories from case research”. Academy of Management

Review, Vol. 14, No. 4, pp. 532-550. ENGMING, L.; HSIEH, C. T. (1994), “Seven deadly risk factors of software development

projects”, Journal of Systems Management, Vol. 36 No. 6, pp. 38-42.

FESTA, E.; ASSUMPÇÃO, M. R. P. (2012), “Uso da Tecnologia de Informação e Desempenho Logístico na Cadeia Produtiva de Eletroeletrônicos”. Revista Ciência e Tecnologia. Vol.

17, No. 33, pp. 7-23. FRANCESCHINI, F.; GALETTO, M. (2001), “A new approach for evaluation of risk priorities of

failure modes in FMEA”, International Journal of Production Research, Vol. 29 No.

13, pp. 2991-3002. FREEMAN, E. (2010), “Strategic Management: A Stakeholder Approach”, Cambridge

University Press, Cambridge. GANN, D. M.; SALTER, A. J. (2000), “Innovation in project-based, service-enhanced firms: the

construction of complex products and systems”, Research Policy, Vol. 29 Nos 7/8, pp.

955-72. GURUMURTHY, A.; KODALI, R. (2011), “Design of lean manufacturing systems using value

stream mapping simulation”, Journal of Manufacturing Technology Management,

Vol. 22 No. 4, pp. 444-473. HAGEMANN, H. (2008), “Consequences of the new information and communication

technologies for growth, productivity and employment”, Competitiveness Review: An

International Business Journal, Vol. 18 No 1 / 2, pp. 57-69. HARTMAN, F.; ASHRAFI, R. A. (2002), “Project management in the information systems and

information technologies industries”, Project Management Journal, Vol. 33 No. 3, pp.

4-14. HENDERSON, R.; CLARK, K. (1990), “Architectural innovation: the reconfiguration of existing

product technologies and the failure of established firms”, Administrative Science

Quarterly, Vol. 35 No. 1, pp. 9-30. HELMAN, H. (1995), “Análise de falhas (Aplicação dos métodos de FMEA e FTA)”. Belo

Horizonte: Fundação Cristiano Ottoni, Escola de Engenharia da UFMG. INOUE, H.; YAMADA, S. (2010), “Failure mode and effects analysis in pharmaceutical

research”, International Journal of Quality and Service Sciences, Vol. 2 No. 3, pp.

369-382. IRANI, Z.; LOVE, P. E. D. (2001), “The propagation of technology management taxonomies for

evaluating information systems”, Journal of Management Information Systems, Vol.

17 No. 3, pp. 161-77. JONES, C. (1993), “Assessment and Control of Software Risks”, Prentice-Hall, Englewood

Cliffs, NJ. KANGARI, R.; RIGGS, L. S. (1989), “Construction risk assessment by linguistics”, IEEE

Trans. Manag., Vol. 36 No. 2, pp. 126-31. KEEGAN, A.; TURNER, J. R. (2002), “The management of innovation in project-based firms”,

Long Range Planning, Vol. 35 No. 4, pp. 367-88. KERZNER, H. (2002), “À procura da excelência em gerenciamento de projetos”. São Paulo:

Willey.


ISSN: 2047-2528 Vol. 3 No. 12[01-24]


KERZNER, H. (2006), “Gestão de Projetos: as melhores práticas”. Porto Alegre: Bookman.

2006. KING, J. (1994), “Sketchy plans, politics stall software development”, Computer World, Vol.

29 No. 24, p. 81. KUMAR, E. V.; CHATURVEDI, S. K. (2011), “Prioritization of maintenance tasks on industrial

equipment for reliability: a fuzzy approach”, International Journal of Quality &

Reliability Management, Vol. 28 No. 1, pp. 109-126. KRASNER, H. (1998), “Looking over the legal edge of unsuccessful software projects”, Cutter

IT Journal, Vol. 11 No. 3, pp. 11-22. LAMPEL, J. (2001), “The core competencies of effective project execution the challenge of

diversity”, International Journal of Project Management, Vol. 19 No. 8, pp. 471-83.

LAU, E.; KONG, J. (2006), “Identification of constraints in construction projects to improve performance”, Proceedings of the Joint Conference on Construction, Culture,

Innovation and Management, Dubai, November 26-29, pp. 655-63. LIMA, E. P,; GARBUIO, P. A. R.; COSTA, S. E. G. (2009), “Proposta de Modelo Teórico-

Conceitual Utilizando o Lean Seis Sigma na Gestão de Produção”. ENEGEP. Salvador.

LIMA, J. F. G.; PEREIRA, S. L.; SOUZA, E. V. (2009), “Gerenciamento de Projetos Baseada na Gestão por Competências: Um Estudo de Caso no Setor de Artigos Esportivos de uma Indústria Manufatureira”. ENEGEP. Salvador.

MARCONI, M. A., LAKATOS, E. M. (2000), “Técnicas de Pesquisa”. São Paulo:Editora Atlas.

5ª edição. MCCUTCHEON, D. M.; MEREDITH, J. R. (1993), “Conducting case study research in

operations management”, Journal of Operations Management, Vol. 11 No. 3, pp.

239-56. MURPHY, M.; HEANEY, G.; PERERA, S. (2011), “A methodology for evaluating construction

innovation constraints through project stakeholder competencies and FMEA”.

Construction Innovation, Vol. 11, No 4, p. 416-440. NEVES, S. M.; SILVA, C.S.; TURRIONI, J. B. (2009), “Melhoria Contínua em Gestão de

Projetos: Análise de Uma Incubadora de Base Tecnológica”. ENEGEP. Salvador.

OOKALKAR, A. D.; JOSHI, A. G.; OOKALKAR, D. S. (2009), “Quality improvement in hemodialysis process using FMEA”, International Journal of Quality & Reliability

Management, Vol. 26 No. 8, pp. 817-830. PALADY, P. (2007), “FMEA: Análise dos Modos de Falha e Efeitos. Prevendo e prevenindo

problemas antes que ocorram”. São Paulo: IMAM, 3a edição.

PIERCY, N.; RICH, N. (2009), “Lean transformation in the pure service environment: the case of the call service centre”, International Journal of Operations & Production

Management, Vol. 29 No. 1, pp. 54-76. PMBOK (2013), “Project Management Body of Knowledge”. 5a ed. Project Management

Institute - PMI. PROJECT MANAGMENT INSTITUTE (2008), “Estudo de Benchmarking em Gerenciamento de

Projetos Brasil 2007”. Project Management Institute – Chapters Brasileiros, 2007.

Disponível em: http://www.pmi.org.br Acesso em 25 abr. 2008. QIANG, R. (2009), “Research on sales quality system improvement based on FMEA”.

Proceedings… 6th International Conference on Service Systems and Service Management. June 08-June 10, pp. 905-909.

RAMESH, V.; KODALI, R. (2012), “A decision framework for maximizing lean manufacturing performance”, International Journal of Production Research, Vol. 50 No. 8, pp. 2234-

2251. RAZ, T.; SHENHAR, A.J.; DVIR, D. (2002), “Risk management, project success, and

technological uncertainty”. R & D Management. Vol.32, n.2, p.101-109.

REBELATO, M. G.; RODRIGUES, A. M.; RODRIGUES, I. C. (2009), “Análise das Lacunas Presentes na Integração da Manufatura Enxuta com a Metodologia Seis Sigma”.

ENEGEP. Salvador. RHEE, R. J.; ISHII, K. (2003), “Using cost based FMEA to enhance reliability and

serviceability”, Advanced Engineering Informatics, Vol. 17, pp. 179-188.

ROTHER M.; SHOOK, J. (2003), “Learning to See: Value Stream Mapping to Create Value and Eliminating Muda”, Lean Enterprise Institute, Cambridge, MA.

SANKAR, N. R; PRABHU, B. S. (2001), “Modified approach for prioritization of failures in a system failure mode and effects analysis”, International Journal of Quality &


ISSN: 2047-2528 Vol. 3 No. 12[01-24]


Reliability Management, Vol. 18 No. 3, pp. 324-335. SANTOS, J. A.; CARVALHO, H. G. (2006), “Referencial Brasileiro de Competências em

Gerenciamento de Projetos”. Curitiba, Brasil: Associação Brasileira de Gerenciamento

de Projetos, 2006. SAWHNEY, R.; SUBBURAMAN, K,; SONNTAG, C; RAO, P. R.V.; CAPIZZI, C. (2010), “A

modified FMEA approach to enhance reliability of lean systems”, International

Journal of Quality & Reliability Management, Vol. 27 No. 7, pp. 832-855, 2010. SCHWALBE, K. (2002), “Information Technology Project Management”, Thomson Learning,

Scarborough. SILVA, E. L., MENEZES, E. M. (2000), “Metodologia da pesquisa e elaboração de

dissertação”. Programa de Pós Graduação em Engenharia de Produção,

Universidade Federal de Santa Catarina, Florianópolis, 118p. SIQUEIRA, Y. P. (2005), “Manutenção Centrada na Confiabilidade: manual de

implementação”. Rio de Janeiro: Qualitymark.

SOUZA, R. V. B.; CARPINETTI, L. C. R. (2014), “A FMEA-based approach to prioritize waste reduction in lean implementation”, International Journal of Quality & Reliability

Management, Vol. 31 No. 4, pp.346-366. TAJ, S.; MOROSAN, C. (2011), “The impact of lean operations on the Chinese manufacturing

performance”, Journal ofManufacturing Technology Management, Vol. 22 No. 2, pp.

223-240. THOMSETT, R. (1995), “Project Pathology: Causes, Patterns and Symptoms of Project Failure”

– Training Notes Project Risk Management, Thomsett Company, London. TOLEDO, J. C.; AMARAL, D. C. (2013), “FMEA – Análise de Tipo e Efeito de Falha”, GEPEC –

Grupo de Estudos e Pesquisa em Qualidade. UFSCAR. TUMMALA, V. M. R.; LEUNG, Y. H. (1999), “Applying a risk management process (RMP) to

manage cost risk for an EHV transmission line project”, International Journal of

Project Management, Vol. 17 No. 4, pp. 223-35. TURNER, J. R. (2009), “The Handbook of Project-based Management: Leading Strategic

Change in Organizations”, McGraw Hill, 3ª Ed.,New York, NY.

VAN ARK, B. (2001), “The Renewal of the Old Economy: An International Comparative Perspective”, OECD, Paris.

VERZUH, E. (2000), “Gestão de Projetos”. Rio de Janeiro: Campus. VON ASHEN, A. (2008), “Cost-oriented failure mode and effects analysis”, International

Journal of Quality & Reliability Management, Vol. 25 No. 5, pp. 466-476. YOURDON, E. (1996), “Tools and processes for death march projects”, Cutter IT Journal –

Application Development Strategies, Vol. 8 No. 12, pp. 27-35. VINODH, S.; BALAJI, S. R. (2011), “Fuzzy logic based leanness assessment and its decision

support system”, International Journal of Production Research, Vol. 49 No. 13, pp.

4027-4041. VINODH, S.; CHINTHA, S. K. (2011), “Application of fuzzy QFD for enabling leanness in a

manufacturing organization”, International Journal of Production Research, Vol. 49

No. 6, pp. 1627-1644. YANG, H.; BAI, Z. (2009), “Risk Evaluation of Boiler Tube Using FMEA”. Proceedings…Sixth

International Conference on Fuzzy Systems and Knowledge Discovery. Vol. 07, pp.

81-85, 2009. YIN, R. K. (1989), “Case Study Research: Design and Methods”, Sage, Newbury Park, CA.

YOON, H.; GUIMARAES, T.; O-NEAL, Q. (1994), “Exploring the factors associated with expert

systems success”, MIS Quarterly, Vol. 19 No. 1, pp. 83-106.

WILLCOCKS, L.; GRAESER, J. (2001), “Delivering IT and E-business Value”, Computer

Weekly Series, Butterworth and Heinemann, Oxford. WOMACK, J. P.; JONES, D. T. (2003), “Lean Thinking – Banish Waste and Create Wealth in

Your Corporation”, The Free Press, New York, NY.


ISSN: 2047-2528 Vol. 3 No. 12[01-24]


Appendix I: Results of PJ-FMEA application on ICT Project A, from Autoparts Ltd.


DescriptionRisk

Risk Mode

(Table 4)Risk Mode Cause (Table 4)

Occ

urr

ence

Det

ecti

on

Consequence /

Effect

Seve

rity

RP

N

CP

N

Pri

ori

ty Risk Response /

Recommended Actions

3.1 Lack of Staff 7 7

Delays on essential

activities

conclusion

9 441 882 Medium

Inform business

managers and sponsors:

communicating impacts

of lack of staff to the

project.

3.2 Low Staff Quality 7 4

Delays for errors

and / or rework

needs

9 252 1008 High

Frequent project

allocated resources

performance monitoring

(weekly)

4. Political

Circunstances

4.2 Lack of Executive

Support5 6

Delays on essential

activities

conclusion

8 240 720 Medium

Communicate project

sponsor about impacts

that lack of executive

support can bring to the

project, and prepare

action plan to mitigation.

5.1 Inadequate

Documentation6 7

Difficulty in

performing

essential activity

and / or

reprocessing

7 294 588 Medium

Usage of standardized

templates. Complement

existing documentation

in accordance with the

responsibilities matrix

5.5 Incomplete

Requirements7 7

Difficulty in

performing

essential activity

and / or

reprocessing

8 392 1176 High

Weekly review of master

data requirements, with

responsibility delegation

to solve pendent issues

6.5 Lack of Single

Accountability Point5 6

Communication

problems, with

possible delays

7 210 420 Low

Communication on the

responsibility matrix,

and weekly meetings to

inform project status

6.4 Failures in Daily

Progress Review8 8

Delays on essential

activities

conclusion

9 576 1152 High

Record of delayed tasks,

with daily monitoring,

and definition of

responsible / action plan

6.6 Poor Leadership 6 7

Difficulty in

performing

essential activity

and / or

reprocessing

7 294 882 Medium

Mapping of stakeholders

and impacts on the

project. Communicate

sponsor to mobilize

leadership

7. Individual

Activities7.2 Unrealistic Expectations 5 6

Delays on essential

activities

conclusion

8 240 480 Low

Weekly project status

meetings with

stakeholders to

communicate scope,

time, cost, acceptance

criteria

PJ-FMEA - Risk Mode and Effect Analysis - Project A - ICT

Master Data

Adjust in the

system data of

workcenters, raw

materials and

components,

before the Go Live

System

1. Delays in the

preparation of master

data for Project Go

Live

3. Human Behavior

5. Technology and

Technical Issues

6. Project

Management and

Control


ISSN: 2047-2528 Vol. 3 No. 12[01-24]


Appendix I: Results of PJ-FMEA application on ICT Project A, from Autoparts Ltd (contin.)


DescriptionRisk

Risk Mode


Occ

urr

ence

Det

ecti

on

Consequence /

Effect

Seve

rity

RP

N

CP

N

Pri

ori

ty Risk Response /

Recommended Actions

1. Commercial and

Legal Relationship

1.1 Innapropriate Supplier

Performance6 4

Delays by the need

to resources

changes

8 192 192 Low

Supplier Contract

Modification to include

clauses of financial

compensation in case of

damage

3. Human Behavior 3.2 Low Staff Quality 7 4

Delays by the need

to resources

changes

9 252 1008 High

Frequent project

allocated resources


(weekly)

5.4 Technical Limitations of

the Solution6 5

Delayed by the

need to review the

specifications and

reprocessos

8 240 480 Low

Define technical

meetings with other ICT

Teams to evaluate and

approve the project

technical solution.

5.5 Incomplete

Requirements

7 7

Inability to deliver

the project on time

(delay)

8 392 1176 High

Allocation of additional

staff and detailing of

technical solution in

modules

6.1 Unrealistic project

schedule and budget7 7

Delays by tasks

duration review9 441 882 Medium

Review scope, activities

and costs related to

budget and project

structure

6.4 Failures in Daily

Progress Review

8 6

Delays due to late

recovery action

plan

9 432 864 Medium

Review estimates and

costs and consequential

impacts and, whenever

appropriate, initiate

controlled change

process

1. Human Behavior 1.1 Lack of Staff 7 7

Delays on essential

activities

conclusion

8 392 784 Medium

Inform business

managers and sponsors:

communicating impacts

of lack of staff to the

project.

4. Political

Circunstances


Support5 6

Delays on essential

activities

conclusion

7 210 630 Medium

Communicate project





action plan to mitigate it.

6.5 Lack of Single

Accountability Point5 6

Communication

problems, with

possible delays

8 240 480 Low

Communication about

responsibility matrix to

stakeholders, and make

weekly meetings of

project status

6.6 Poor Leadership 6 7Delays and / or

reprocessing8 336 1008 High


and impacts on the


sponsor to mobilize

leadership

6.7 Lack of Formal Change

Management Process7 7

Delays in Core

Activities and

Impacts in Project

Scope

9 441 392 Low

Communicate project

stakeholders, according

to the change

management plan, the

approved process of

changes evaluation /

approval

Change

Management

Readiness of the

organization to

receive the

system, and

operates it

smoothly

3. Lack of preparation

by business staff to

operate the system

6. Project

Management and

Control


Information

Technology

Deployment of ICT

solution for

system

implementation

2. Possibility of delays

in the delivery of

systems interfaces

5. Technology and

Technical Issues

6. Project

Management and

Control


ISSN: 2047-2528 Vol. 3 No. 12[01-24]


Appendix I: Results of PJ-FMEA application on ICT Project A, from Autoparts Ltd (contin.)


DescriptionRisk

Risk Mode


Occ

urr

ence

Det

ecti

on

Consequence /

Effect

Seve

rity

RP

N

CP

N

Pri

ori

ty Risk Response /

Recommended Actions


Delays for errors

and / or rework

needs

9 252 1008 High

Frequent project

allocated resources


(weekly)

4. Political

Circunstances


Support5 6

Delays on essential

activities

conclusion

7 210 630 Medium

Communicate project





action plan to mitigate it.

6.1 Unrealistic project

schedule and budget7 7

Delays due to tasks

durantion review9 441 882 Medium

Record of delayed tasks,

with daily monitoring,

withdefinition of

responsible / action plan

6.6 Poor Leadership 6 7Delays and / or

reprocessing7 294 882 Medium


and impacts on the


sponsor to mobilize

leadership

5.1 Inadequate

Documentation6 7

Reprocessing and /

or delays in

essential activities

7 294 588 Medium

Complement the

documentation in

advance, considering the

new features x existing

user profiles x enabled

users by function.

5.5 Incomplete

Requirements7 7

Reprocessing and /

or delays in

essential activities

9 441 1323 High

Profiles Tests execution

in a alternative system

environmennt, before

release it into

production


Delays for errors

and / or need for

rework

8 224 896 Medium

Frequent project

allocated resources


(weekly)

5.2 Solution does not meet

the required purpose5 5

Delays by the need

to review the

specifications and

reprocessing

9 225 225 Low

Review technical design

specifications,

acceptance criteria and

approvals of the project

blueprint.

5.3 Low system

performance6 5

Delays by the need

to review the

specifications and

reprocessing

8 240 240 Low

Define technical



approve the project

technical solution.

5.4 Technical Limitations of

the Solution6 5

Delays by the need

to review the

specifications and

reprocessing

9 270 540 Medium

Define technical



approve the project

technical solution.

5.6 Inappropriate user

interface5 5

Delays by the need

to review the

specifications and

reprocessing

8 200 200 Low

Review technical design

specifications,

acceptance criteria and

approvals of the project

blueprint.

6. Project

Management and

Control

6.7 Development of

Incorrect System

Functionality

5 5

Delays by the need

to review the

specifications and

reprocessing

9 225 225 Low

Review project scope

and subsequent mapping

of the required changes.

If needed, start change

management process.

7. Individual

Activities7.2 Unrealistic Expectations 5 6

Delays on essential

activities

conclusion

8 240 480 Low

Weekly project status

meetings with

stakeholders to

communicate scope,

time, cost, acceptance

criteria

Information

Technology

Deployment of ICT

Solutions for

systme

operationalization

6. Possibility of

problems with system

performance (slow)

5. Technology and

Technical Issues

People

Qualification of

Project Staff and

of Organization

Employees

4. Possibility of

Employees with Low

Qualification /

Preparation for

Project Execution

6. Project

Management and

Control

Information

Technology

Deployment of ICT

Solutions for

system

operationalization

5. Possibility of

problems in defining

access profiles to the

new features

5. Technology and

Technical Issues


fmea as a tool for managing risks in ict projects, based ... · fmea as a tool for managing risks...

Documents