Case study

Preempting Problems
How Motorola
minimized risk
before changing
business-critical
applications

By Vic Nanda,
Motorola

n todays dynamic business environment, most companies face the

difficult challenge of quantifying and reducing risk due to planned
changes. This may include changes to a companys business processes,
IT applications or to the overall business environment.
Without the use of a formal method, the organizationwide impact of a
potential failure cant be quantified and simply becomes a subjective estimate (such as high, medium or low). If a formal risk assessment exercise is
conducted, only the localized impactor the immediate consequenceof
a failure is investigated, and there is no way to extrapolate the impact of a
failure to an entire company.
But there is a way to see the whole picture, and then act accordingly. An
organization can apply an approach that enhances design failure mode
effects analysis (DFMEA) to quantify and reduce its risk exposure in the
face of imminent change. Motorola did so with the help of the design,
measure, analyze, improve and control (DMAIC) method and, in the
process, averted significant setbacks during an IT application upgrade
and avoided spending more than a half-million dollars annually attributable to systems failures.
Project background
As part of a multimillion-dollar IT initiative, Motorola launched an ambitious project in 2006 to redesign and simplify the globally distributed
architecture for a business-critical application. The ultimate objective was
to improve operational efficiencies and cut costs by eliminating disparate
IT applications that offered similar functionality for Motorolas different
business units. Instead, one consolidated IT application would serve all
business units.
Due to this fundamental architectural change, there was potential for
post-implementation defects that would create downtime and put existing
business operations at risk. During the design phase of the project in late
2007, senior management decided the proposed architecture should be
examined thoroughly for potential failures. This entailed evaluating the
new architecture for design flaws that might jeopardize requirements for
high availability and reliability.
A Six Sigma project team (SSPT) was formed and included the following
participants: one Green Belt, one Black Belt (BB), one Master Black Belt,
one customer representative from the parent IT project that had spawned
the new project, and 15 subject matter experts from various functional
areas within the scope of the project.
A governance team for the project was also formed that was comprised of
two project sponsors, one project Champion, one representative from the
finance organization, the leader of the Six Sigma program in Motorola IT
six sigma forum magazine

february 2010

Preempting Problem s

Figure 1. Technical process flow

B2B Standard Order L2-L3
Using Dropship Phase 1
(Business Process)
System Architect
Thu Feb 07, 2008 12:33

(system)
Oracle_
ERP_
Orders

Ship Card
to provide
Promise
date

Oracle Sourcing
in OM to
provide
fulfillment details

Perform
Credit
Check

Yes

Manual
changes
applied on
Sales Order

SO changes required?
CTO Model?

Start

Perform
ATP
Check

Sales Order/
RMA/Mixed
Order Entered

Create New
Sales Order

Book
Sales
Order

Create Dropship
Purchase Order

Import
Requisition

Extract
Purchase
Order

Perform
Credit
Check

Update Sales
Order Status

Dropship
Purchase Order
Receipt

Import ASN
Receipt
for PO

Dropship
Sales Order
Shipped

Yes
3A4 Place Purchase Order

Configure/
Validate Model

Customer Order Credit Validation

Trifecta

Trifecta
3A8 Purchase Order Change
3B2 Advance Shipment Notification CMF

3A6 Distribute Order Status

Export Compliance Confirmation
3A4 Purchase Order Confirmation CMF

3B2 Advance Shipment Confirmation

3A8 Purchase Order Change Confirmation CMF

3A9 Purchase Order Cancellation Confirmation CMF
3A9 Purchase Order Cancellation Request CMF
(system)
Oracle_
ERP_ISC

Communicate
Sales Order
Status

Update Sales
Order Status

Extract
ASN
SO changes required?

Is Inventory available?
Extract
Sales
Order

Import
Sales
Order

Inventory
Available

Motorola
Pick
Release

Shipment against
Internal Sales Order
Ship
Confirm
Invoice Data

Manufacture
or buy

Buy
Export Compliance Verification

Export Compliance Verification

Maufacture/
Assemble

Buy from
Internal
Source

(system)
Vastera

Check
Compliance

Check
Compliance

Check
Compliance

Finance
Create
Customer
Invoice

Please note: This figure offers a high-level overview of a process flowchart structure. Focus on the specific activities is not necessary.

and the immediate supervisor of the BB on the SSPT.

The project team was chartered with the following
objectives:
1. Assess and quantify the risk to the entire company
as a result of potential failures in the proposed
new IT architecture.
2. Perform risk mitigation and provide improvement recommendations so the root causes that
pose the greatest risk to the company can be
addressed in an orderly fashion.
3. Estimate the reduction in risk, subject to implementation of recommended improvements.
Define phase
The team formulated the following statements:
Business case statementThe shift from a distributed IT architecture to a consolidated one was pro-

10

february 2010

W W W . AS Q . ORG

found and introduced significant risks that had to be

thoroughly understood and mitigated.
Opportunity statementProactive discovery of
design flaws could help uncover defects early in the
project and help minimize:
Cost of poor quality (COPQ) associated with
resolving design flaws later in the project (before
deployment)or worse, the much higher rework
cost if design flaws were discovered after deployment.
Cost of business impact as a result of IT downtime
to resolve defects found after deployment.
Goal statementThe project goal was to increase
the robustness of the new IT architecture by delivering measurable cost avoidance of at least $250,000
by identifying flaws in the proposed architecture by
March 14, 2008.
Project scopeThe scope identified the specific

Shipment Acknowledgement

P r e e m p t i n g P r o b l ems

In

this project, the

DFMEA

method served as a powerful tool for

quantifying and minimizing organizationwide risk.

architecture baseline to be analyzed, and listed seven

technical process flows to be evaluated to ensure their
flawless execution with the new architecture. The
scope also specified interfaces to other IT applications
that were in scope of the analysis.
Project planMilestone dates were set for the end
of each of the phases in the DMAIC lifecycle of the
project. A high-level project plan was supported by
a detailed plan that drilled down into each of the
project phases and listed start and end dates along
with responsibility for projects tasks.
The project due date was set by the SSPT and the
project sponsors.
Measure phase
This phase involved creating a measurement plan
that listed the performance measures to be used to
baseline current process performance and to calculate
project return on investment (ROI).
The performance measures were:
1. COPQinternal failure, or the total cost of IT
rework to resolve a process defect found before
go-live.
2. COPQexternal failure, or the total cost of IT
rework to resolve a process defect found after
go-live.
3. Business impact, or the impact in dollars to the
business due to a post-release defect.
Measurement data were collected from 57 large
IT projects to baseline process performance. Data
showed an average of 43 pre-release defects per projectwhich cost an average of $132.05 per defect to
resolveand an average of nine post-release defects
per project (defects reported after release of an IT
application to the business users).
The cost of rework for post-release defects was
$1,065.85, about eight times the cost of resolving prerelease defects. This is consistent with similar data
reported by IBM.1 Cost of an outage was based on a
2003 incident of a critical business application.
This phase ended with a formal milestone review
that involved the presentation of the phase results to
the project governance team.

Analyze phase
During this phase, the seven technical process flows
identified in the project were examined and modeled.
Process maps (abstractions of real processes) were prepared to depict the steps within the business-critical
application and its interfaces with other applications.
An example of a technical process flow is shown in
Figure 1. The four horizontal rectangles represent
four different business-critical applications involved in
this particular scenario, and the multiple dotted lines
from one rectangle to the next represent interface
messages between the applications.
After the technical flows were developed, the
DFMEA template (Table 1, p. 12) was populated with
header information for each process flow separated,
including names of activities (small boxes in Figure 1)
and interface messages (dotted lines in Figure 1). This
saved time during the DFMEA workshop because the
SSPT had templates ready for use.
With pre-work of the process maps completed, a
DFMEA workshop was scheduled and began with onehour training for the SSPT on the DFMEA Six Sigma
tool.
The team used the traditional 10-point scale for
scoring occurrence and detection. A five-point scale
was used for scoring severity because it aligned with
Motorolas five-point scale for scoring severity of
defects reported against IT software applications.
Risk priority number (RPN) = probability
(maximum = 10) x detection (maximum = 10)
x severity (maximum = 5).
RPNMaximum = 10 x 10 x 5 = 500.
RPNr = Reduced RPN after implementation of
corrective actions.
The SSPT deemed high-risk failures as those that
had an RPN > 80. This was also referred to as the
acceptance threshold.
The SSPT then decided to focus on uncovering
failure modes related to:
Planned modifications to the underlying

six sigma forum magazine

february 2010

11

Preempting Problem s

Table 1. DFMEA template

Failure mode effects analysis (FMEA)
Process/product: <Process name>
FMEA team: <List names of the people who contributed to this
FMEA>
Black Belt: <name>
Item
process steps

Key
process input

Potential
failure mode (In
what ways can the
key process go
wrong?)

Extract ASN
outbound
Customer order
credit validation
Extract SO

Shipment confirmation

Potential effects Severity of effect to Potential cause(s) Probability of

of failure
customer (1-5)
of failure (What
occurrence (1-10)
causes the key
input to go wrong?)

Motorola release pick

3A4, 3A8 or 3A9

Export
Motorola release pick
compliance
verification
Extract purchase Drop ship PO
order outbound

ASN = abstract syntax notation

DFMEA = design failure mode effects analysis
PO = purchase order
RPN = risk priority number
SO = sign off

commercial-off-the-shelf (COTS) business application. Failures in the COTS application due to

inherent defects were outside the scope of the
analysis because that was a risk users of the COTS
application were already exposed to, and those
defects were unrelated to the planned redesign
of the architecture.
Interface messages between the business-critical
application being redesigned and all other interfacing business applications.
The discovered failure modes were categorized as:
Application-related failures, including application crashes, version or patch-related problems,
application errors and configuration errors.
Data-related failures, including data validation
errors (data type and length), incomplete data
and data corruption.
In the case of IT applications, there are also failures
that can be attributed to infrastructure failures such as
network failure, memory leaks, database design errors
and capacity problems (CPU, memory or storage).
Due to the immensity of these types of infrastructure

12

february 2010

W W W . AS Q . ORG

failures, it was determined a separate DFMEA for

infrastructure-related failures was needed.
To save time, the team leveraged similarities across
the technical flows during the DFMEA analysis so
subsequent analysis could focus on unique differences
between the flows. In other words, if part of the technical flow between flows A and B was the same, then the
failure modes uncovered for that part during DFMEA
analysis of flow A would be applicable to flow B.
Finally, any additional miscellaneous failures identified were included in the DFMEA analysis for risk
assessment and possible handoff to others, such as the
infrastructure-related DFMEA analysis team.
Extending traditional DFMEA
As noted earlier, a significant challenge for the SSPT
was to devise an approach to extrapolate the results
of the traditional DFMEA to get a better sense of risk
exposure for all of Motorola. This entailed taking
a broader view of the RPN scoring in the DFMEA
exercise.
You might argue the severity scale can be used for

P r e e m p t i n g P r o b lems

this purpose. For example, a failure with a severe

impact that reaches across an organization could be
rated a 10 on the 10-point scale, but this approach
doesnt allow for a systematic way of computing organizationwide risk. For instance, an outbound variant (from enterprise resource planning [ERP] 7),
depending on the type of failure, could be encountered in up to three different variants of the process
(see Figure 2, p. 14).
Likewise, on the other side of the transaction,
depending on the type, a failure may be encountered
in up to six different ERPs. Or, a failure could be
encountered in up to two different process variants
inbound. Therefore, to get a true sense of organizationwide risk (referred to as enterprise RPN, or
eRPN), the individual RPN must be multiplied by
the number of process variants or ERPs, as the case
may be.
For instance, if a risk with an RPN of 500 is multiplied by one, it yields an eRPN of 500. On the other
hand, if a risk of a lower RPN of 200 is multiplied by
seven (assuming it would be encountered in all the
ERPs), it yields an eRPN of 1,400. In this example,

Action
taken

Risk priority
(reduced)

Recommended Responsibility and

action
target completion
date

Detection

RPN

Severity

Page: 1 of 1
Current controls that Probability
prevent either
of detection
the cause or
(1-10)
the failure mode

Occurrence

FMEA date: March 10-11, 2008

the risk that poses greater organizationwide risk is the

one with the lower RPN of 200. Without extrapolating
the risk to the entire company by using this concept
of eRPN, the team would have been misguided in
focusing on the failure with the RPN of 500.
eRPN = RPN x [ number of variants or

number of ERPs]
Maximum
= 500

Maximum
=3

Maximum
=7

3 variants (outbound)
2 variants (inbound)

7 ERPs

eRPNMaximum = 500 x 7 = 3,500.

eRPNr = Reduced eRPN after implementation of
corrective actions.
Computing eRPN is only part of the answer. Because
many failure modes might share common root causes,
those causes become relatively more important than

six sigma forum magazine

february 2010

13

Preempting Problem s

Figure 2. Computing enterprise-RPN (eRPN)

Three variants

Two variants
ERP 7

Outbound

Inbound

6 ERPs
Extract 1

Extract 2

Extract 3

Extract 4

Extract 5

Extract 6

One

Two

Three

Four

Five

Six

ERPs 1 6
RPN = risk priority number
ERP = enterprise resource planning
eRPN = enterprise RPN

others that might be responsible for one type of failure. Therefore, repetitive root causes must be carefully considered as they are likely to pose the most risk
to the organization.
By adding the eRPN of all failures that are attributed
to the same root cause, you can estimate the risk posed
by a specific root cause to the organization. This is
referred to as cumulative eRPN. That is, cumulative
eRPN is the sum of enterprise risk of all failures that
are attributed to the same or similar root cause.
Brainstorming causes
The first step is brainstorming the potential failures
at each step of the process. The SSPT examined each
process step and interface message and brainstormed
potential application and data-related failures. Each
potential failure was assessed for cause of failure.
Based on the team consensus on severity, probability
of occurrence and detection, the RPN score was computed for each failure.
During a one-week workshop, the SSPT uncovered 57 failure modes, including 27 high-risk failure
modes that exceeded the acceptance threshold and
had broad enterprise impact. Table 2 shows a partial
snapshot of the top-five high-risk failure modes, sorted
in descending order by eRPN. To allow for legibility,
certain columns have been suppressed.
The SSPT was interested in root causes with the

14

february 2010

W W W . AS Q . ORG

greatest cumulative eRPN. A partial snapshot of the

top-three root causes is shown in Table 3, p. 16. All
failures that were attributed to the same root cause
are listed in the first column while the associated root
cause is listed in the second column.
Figure 3, p. 17, shows the root causes organized
in descending order by cumulative eRPN. The different shadings in each histogram bar correspond
to the different failures attributed to the same root
cause.
For example, the first bar has six different failures
that result from this root cause. The heights of these
shaded portions in the first bar correspond to the
magnitude of organization-wide risk (eRPN) associated with each of those failures.
Improve phase
In this phase, the team brainstormed improvements
and corrective actions for this list of root causes. A
total of 15 improvement recommendations for the 13
root causes were made.
Figure 4, p. 18, shows the original risk profile and
the projected reduction in risk profile, subject to the
implementation of the improvement recommendations. This before-and-after representation of quantified risks served as a powerful way to present overall
risk exposure to senior management.
Recalculated RPNs show that 80% of the failure

P r e e m p t i n g P r o b l ems

Table 2. Top five high-risk failure modes

RPN

Enterprise RPN
(number of
affected flows x #
of affected ERPs
x RPN) - eRPN

Recommended action

Failure to provide
specified info per
customer in the ASN.

360

2160

Recommend that a
detailed request for ASN
data fields be specified.

24

144

No credit check
validation.

300

1800

Need SOA for credit

check. This may be
used for compliance
check as well.

10

60

120

840

30

210

30

210

Item process
steps

Potential effects
of failure (What is
the impact on key
output variables?)

Potential cause(s) of
failure (What causes
the key input to go
wrong?)

Extract ASN
outbound.

Fines from unhappy

customers.

Customer order
credit validation.

Revenue impact
(shipped to
customer with bad
credit or exceeding
available credit).

Master data
synchronization
between two
ERPs for BOM.

Wrong product built.

Data not synched.

Lack of identification
ERP configuration
of common elements
differencesERP
Failed processes
of key dataERPs
application/
(bottomline impact).
perform functions
process setup.
differently.

Need common
nomenclature
data governance.

Failed processes.

Failure

Effect

Lack of identification
of common elements
of key dataERPs
perfom functions
differently.

245

1715

225

1575

225

Cause(s)

1575

Original
enterprise
risk

This is a GEMS-specific
issue (business-specific).
This will create requests
for Motorola PDM.
Decode program should
be capable of dealing
with BOM changes (refer
to DropShip for details).
Identify common
elements of key data
(data quality control);
OM will be the system of
record for the common
elements.
Identify common
elements of key data
(data quality control);
OM will be the system of
record for the common
elements.
Recommendation

Reduced enterprise risk

(after corrective action)

ASN = abstract syntax notation GEMS = Motorola department

BOM = bill of material
PDM = product data management
ERP = enterprise resource planning RPN = risk priority number
eRPN = enterprise RPN SOA = service-oriented architecture
eRPNr = enterprise RPN reduced OM = order management

modes could be further lowered below the acceptance threshold if the associated corrective actions
were implemented. Only one of the 27 failure modes,
with an RPN of 120, remained above the acceptance
threshold of 80 even after implementation of all corrective actions.
Next, each recommendation was examined for
implementation impact to the IT project using the
following criteria:
1. No negative financial impact (budget).
2. No schedule impact.

RPNr eRPNr

3. No impact to business processes.

If the above criteria were met, the recommendation was categorized as low implementation risk.
If one of these criteria was not met, the recommendation was considered high implementation
risk and required further impact assessment prior
to implementation.
Finally, the results of the analysis, along with the
assessment of implementation risk associated with
each of the recommendations, were presented to
senior management.

six sigma forum magazine

february 2010

15

Preempting Problem s

Table 3. Top three high-risk failure modes

Potential cause(s)
of failure (What
causes the key input
to go wrong?)

Recommended action

Responsibility
and target
completion date

Implementation
risk (low/high)

Cumulative
eRPN for the
root cause

Extract SO, extract

ASNoutbound,
export compliance
Errors in decode
verification, 3A6
mechanism for
distribute order
manufacturing BOM.
status, any
interaction message.

Create pre-processor logic for

taking sales BOM and generating
manufacturing BOM. Over long
term, need general restructuring
of BOMs to reflect a standard
BOM configuration process.

Data purged

Data purged

4110

ERP configuration
differencesERP
application/process
setup, need common
nomenclature data
governance.

Lack of identification
of common elements
of key dataERPs
perfom functions
differently.

Identify common elements of

key data (data quality control);
OM will send one set of common
elements.

Data purged

Data purged

3150

3A9 PO cancellation
request CMF, 3A9
PO cancellation
confirmation CMF,
3A8 PO change
confirmation CMF,
3A8 PO change,
extract PO
outbound.

Change request
too late in the
manufacturing
process, POSO
discrepancy, order
status info from ISC
to OM not available,
sequencing of the
changes, timings of
the cancellations.

Need order status synch (3A6)

near real-timebetween ISC and
OMPO and SO.
Design needs to incorporate this
status control point.
Additional actions:
Need a process for handling
SC-initiated change requests.
BAM will also help detect
changes.
Need workflow control for L2 PO
change before commit.

Data purged

Data purged

2593

Item process steps

Cause(s)

Recommendations

BOM = bill of material ISC = Motorola department

ASN = abstract syntax notation OM = order management
CMF = common message format
PO = purchase order
ERP = enterprise resource planning SC = source
eRPN = enterprise risk priority number SO = sign off

Control phase
As the implementation of the corrective actions was
spread over several months and phases of the parent
IT project, this Six Sigma project concluded with the
handoff of all corrective actions to the program manager of the parent IT project, along with assignment
of primary ownership and due date for each corrective
action.
Benefit realization
This project resulted in a 77% reduction in overall
risk to Motorola.2 Further, the risk of potential failure
for 26 of the 27 identified high-risk failure modes was
reduced to well below the acceptance threshold.
Based on historical data on the number of defects,
defect containment effectiveness and cost of rework

16

february 2010

W W W . AS Q . ORG

for 57 large Motorola IT projects, the SSPT determined that identification of the 27 high-risk defects
resulted in direct annual cost avoidance of $2,905 and
$5,329 in pre-release rework and post-release COPQ,
respectively.
By taking into consideration the business impact of
post-release defects and extrapolating historical data
from a similar outage affecting a much smaller portion of the business in 2003, the SSPT concluded that
similar outages in the future would have an annual
business impact of at least $560,000, depending on
the types of system failures encountered.
This includes items such as impact to cash-conversion cycle, cost of expedited freight, manual rework
of defective orders by business employees (non-IT
personnel), contract penalties, loss of business and
loss of export privileges. Therefore, minimum projected annualized cost avoidance was $568,234 or

P r e e m p t i n g P r o blems

Figure 3. Root causes that pose greatest risk to the enterprise

Cumulative eRPN for common root causes
4,000

Cumulative eRPN

3,000

2,000

1,000

0
Root cause 1
group

Root cause
group
1
2
3
4
5
6
7
8
9
10
11
12
13

10 11 12

13

Failure modes
Identify good error messaging process and standard
escalation process
Invoice data
3C1 return product
3A4 place purchase order
Extract purchase orderinbound
Additional step: item cost synch
Disconnect in transfer priceOM PO has a different
transfer price than the ISC SO
Master data synchronization between two ERPs for BOM
Customer order credit validation
3A8 purchase order change
3A8 purchase order change confirmation CMF
3A9 purchase order cancellation confirmation CMF
3A9 purchase order cancellation request CMF
Extract purchase orderoutbound
Need common nomenclature data governance
ERP configuration differencesERP
application/process setup
Any interaction message 2
Any interaction message 1
3A6 distribute order status
Export compliance verification
Extract ASNoutbound
Extract SO

Root cause descriptions

Errors in decode mechanism for manufacturing BOM.
Lack of identification of common elements of key data.
Change request too late in the manufacturing process, PO-SO
discrepancy, order status information from ISC to OS not
available, sequencing of the changes, timing of the cancellations.
No credit check validation.
Failure to provide specified info per customer in the ASN.
Data not synchronized.
Current process only takes the order header and lines, and does
not take in adjustments.
Item cost not the same in both ERPs in the same entity.
Change management processing.
Change or cancellation rejection from ISC.
Data errorinvalid or incomplete.
Inability to create commercial invoice holds up shipment.
Insufficient error handling.

Note: Errors in decode mechanism for

manufacturing BOM pose the greatest
risk to the enterprise.
ASN = abstract syntax notation
BOM = bill of material
CMF = common message format
ERP = enterprise resource planning
eRPN = Enterprise risk priority number
ISC = Motorola department
OM = order management
PO = purchase order
SO = sign off

six sigma forum magazine

february 2010

17

more, depending on the types of system failures encountered.

The estimated project cost was $77,280.
Thus, this project yielded an ROI of 6.35 times
the investment in the first year alone.

Figure 4. Reduction in enterprise risk

Limitations

eRPNr (after), eRPN (before)

Preempting Problem s

Before and after corrective actions to potential failure modes

eRPN
eRPNr

2000

1500

Failure modes that show smallest

The results of this project are directly appliimprovement, unless strategic

cable to a situation in which a company wants
recommendations are implemented.
to quantify and reduce business risks due to
1000
process or technology changes. Even though
the change was technology-related in this proj500
ect, the underlying Six Sigma tool of FMEA
can be used to uncover potential failure modes
for a process (also called process FMEA, or
0
PFMEA) or during product design (DFMEA).
As with any approach, there are potential
1
4
7
10
13
16
19
22
25
limitations. It is widely acknowledged that an
Potential failure modes (27) above cut-off RPN
FMEA cannot uncover complex failure modes
(for example, a sequence of smaller failures
Note: This figure is not intended to show a trend. It is sorted by
that may have a compounding effect). The
decreasing order of eRPN. Original enterprise risk (red) can be
SSPT did not consider failure modes that were
significantly reduced (green) if recommendations are implemented.
associated with failures in the standard COTS
RPN = risk priority number
application because these were not a conseeRPN = enterprise risk priority number
quence of migrating to a new IT architecture.
Finally, the scoring of failure scenarios in
a FMEA analysis is always a subjective exercise, and final RPN scores are based on group
consensus. Also, in this case, the DFMEA analysis was
BIBLIOGRAPHY
challenging due to a lack of historical data regarding
Arkusinski, Andy, Failure Modes and Effects Analysis During Design of
potential failures. This was because the new architecComputer Software, presentation, 24th Digital Avionics Systems Conferture had not been previously implemented in other
ence, Oct. 30, 2005.
companies or within Motorola.
Haapanen, Pentti and Atte Helmunen, Failure Mode and Effects Analysis
Despite these limitations, the DFMEA method
of Software-Based Automation Systems, STUK (Finlands radiation and
nuclear safety authority), August 2002, p. 37.
served as a powerful tool for quantifying and minimizing organizationwide risk. Results of the analysis met
Vijayaraghavan, G.V., A Taxonomy of E-commerce Risks and Failures, masters degree thesis, Florida Institute of Technology, May 2003.
management expectations regarding quantification
of risk at the organizational level, and the approach
EDITORS NOTE AND ACKNOWLEDGEMENTS
described in this project can be readily adopted by
other companies that face similar challenges in assessThis article is based on an excerpt of Nandas Six Sigma Software Process &
ing organization-level risk exposure in the face of
Quality Improvement: Success Stories from Motorola, IBM, Xerox and Other Leading
Companies, McGraw Hill, 2010. The author thanks Motorola for its permisplanned changes in their business.
sion to include information contained in this article.

REFERENCE AND NOTE

1. Humphrey Watts, A Discipline for Software Engineering, Addison Wesley,
1995.
2. The balance of 23% should not be misunderstood as residual risk of any
one failure to Motorola. Instead, it is the cumulative effect of all 27 highrisk failures together. In other words, it is more appropriate to consider
each high-risk failure separately because the high-risk failures were not
related, and thus were unlikely to be encountered simultaneously.

18

february 2010

W W W . AS Q . ORG

What do you think of this article? Please share

your comments and thoughts with the editor by e-mailing
godfrey@asq.org.