Upload
vominh
View
214
Download
1
Embed Size (px)
Citation preview
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
E-mail: [email protected]
Pires, Silvio Roberto Ignácio
UNIMEP
E-mail: [email protected]
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
www.ajbms.org Asian Journal of Business and Management Sciences
ISSN: 2047-2528 Vol. 3 No. 12[01-24]
©Society for Business Research Promotion | 2
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
www.ajbms.org Asian Journal of Business and Management Sciences
ISSN: 2047-2528 Vol. 3 No. 12[01-24]
©Society for Business Research Promotion | 3
(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;
www.ajbms.org Asian Journal of Business and Management Sciences
ISSN: 2047-2528 Vol. 3 No. 12[01-24]
©Society for Business Research Promotion | 4
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".
www.ajbms.org Asian Journal of Business and Management Sciences
ISSN: 2047-2528 Vol. 3 No. 12[01-24]
©Society for Business Research Promotion | 5
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
www.ajbms.org Asian Journal of Business and Management Sciences
ISSN: 2047-2528 Vol. 3 No. 12[01-24]
©Society for Business Research Promotion | 6
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);
www.ajbms.org Asian Journal of Business and Management Sciences
ISSN: 2047-2528 Vol. 3 No. 12[01-24]
©Society for Business Research Promotion | 7
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.
www.ajbms.org Asian Journal of Business and Management Sciences
ISSN: 2047-2528 Vol. 3 No. 12[01-24]
©Society for Business Research Promotion | 8
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
www.ajbms.org Asian Journal of Business and Management Sciences
ISSN: 2047-2528 Vol. 3 No. 12[01-24]
©Society for Business Research Promotion | 9
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
www.ajbms.org Asian Journal of Business and Management Sciences
ISSN: 2047-2528 Vol. 3 No. 12[01-24]
©Society for Business Research Promotion | 10
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.
www.ajbms.org Asian Journal of Business and Management Sciences
ISSN: 2047-2528 Vol. 3 No. 12[01-24]
©Society for Business Research Promotion | 11
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)
www.ajbms.org Asian Journal of Business and Management Sciences
ISSN: 2047-2528 Vol. 3 No. 12[01-24]
©Society for Business Research Promotion | 12
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.
www.ajbms.org Asian Journal of Business and Management Sciences
ISSN: 2047-2528 Vol. 3 No. 12[01-24]
©Society for Business Research Promotion | 13
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
occurrence 70% of the time,
and only detects for the
remainder
4 There is great chance to detect the risk before it occurs
Detects and avoids
occurrence 50% of the time,
and only detects for the
remainder
5 There is little chance to detect the risk before it occurs.
Detects and avoids
occurrence 30% of the time,
and only detects for the
remainder
6 There is very little chance to detect the risk before it occurs.
Detects and avoids
occurrence 10% of the time,
and only detects for the
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.
Does not prevent the risk,
but detects 50% after the
occurrence, before
affecting the project
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.
Does not prevent the risk,
but detects 10% after the
occurrence, before
affecting the project
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%
www.ajbms.org Asian Journal of Business and Management Sciences
ISSN: 2047-2528 Vol. 3 No. 12[01-24]
©Society for Business Research Promotion | 14
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.
www.ajbms.org Asian Journal of Business and Management Sciences
ISSN: 2047-2528 Vol. 3 No. 12[01-24]
©Society for Business Research Promotion | 15
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.
www.ajbms.org Asian Journal of Business and Management Sciences
ISSN: 2047-2528 Vol. 3 No. 12[01-24]
©Society for Business Research Promotion | 16
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
www.ajbms.org Asian Journal of Business and Management Sciences
ISSN: 2047-2528 Vol. 3 No. 12[01-24]
©Society for Business Research Promotion | 17
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;
www.ajbms.org Asian Journal of Business and Management Sciences
ISSN: 2047-2528 Vol. 3 No. 12[01-24]
©Society for Business Research Promotion | 18
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.
www.ajbms.org Asian Journal of Business and Management Sciences
ISSN: 2047-2528 Vol. 3 No. 12[01-24]
©Society for Business Research Promotion | 19
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.
www.ajbms.org Asian Journal of Business and Management Sciences
ISSN: 2047-2528 Vol. 3 No. 12[01-24]
©Society for Business Research Promotion | 20
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 &
www.ajbms.org Asian Journal of Business and Management Sciences
ISSN: 2047-2528 Vol. 3 No. 12[01-24]
©Society for Business Research Promotion | 21
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.
www.ajbms.org Asian Journal of Business and Management Sciences
ISSN: 2047-2528 Vol. 3 No. 12[01-24]
©Society for Business Research Promotion | 22
Appendix I: Results of PJ-FMEA application on ICT Project A, from Autoparts Ltd.
WorkstreamWorkstream
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
www.ajbms.org Asian Journal of Business and Management Sciences
ISSN: 2047-2528 Vol. 3 No. 12[01-24]
©Society for Business Research Promotion | 23
Appendix I: Results of PJ-FMEA application on ICT Project A, from Autoparts Ltd (contin.)
WorkstreamWorkstream
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
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
performance monitoring
(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
4.2 Lack of Executive
Support5 6
Delays on essential
activities
conclusion
7 210 630 Medium
Communicate project
sponsor about impacts
that lack of executive
support can bring to the
project, and prepare
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
Mapping of stakeholders
and impacts on the
project. Communicate
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
PJ-FMEA - Risk Mode and Effect Analysis - Project A - ICT
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
www.ajbms.org Asian Journal of Business and Management Sciences
ISSN: 2047-2528 Vol. 3 No. 12[01-24]
©Society for Business Research Promotion | 24
Appendix I: Results of PJ-FMEA application on ICT Project A, from Autoparts Ltd (contin.)
WorkstreamWorkstream
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. Human Behavior 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
7 210 630 Medium
Communicate project
sponsor about impacts
that lack of executive
support can bring to the
project, and prepare
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
Mapping of stakeholders
and impacts on the
project. Communicate
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
3. Human Behavior 3.2 Low Staff Quality 7 4
Delays for errors
and / or need for
rework
8 224 896 Medium
Frequent project
allocated resources
performance monitoring
(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
meetings with other ICT
Teams to evaluate and
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
meetings with other ICT
Teams to evaluate and
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
PJ-FMEA - Risk Mode and Effect Analysis - Project A - ICT