|
Server : Apache/2.4.62 System : FreeBSD fbsdweb2.web.rcn.net 14.1-RELEASE FreeBSD 14.1-RELEASE releng/14.1-n267679-10e31f0946d8 GENERIC amd64 User : www ( 80) PHP Version : 8.3.8 Disable Function : NONE Directory : /domains/srakitin/OLD/newsletter/vol2/no5/ |
Upload File : |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Food for Thought: Getting to the Root of Customer Reported Problems</title>
<link href="/newsletter/StyleSheet.css" rel="stylesheet" type="text/css">
</head>
<OpenTracking/>
<!-- Do NOT delete previous line if you want to get statistics on the number of opened emails -->
<body>
<strong> </strong>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0">
<tr align="center" valign="top">
<td colspan="2"><img src="/newsletter/images/FoodForThoughtLogo.gif" width="600" height="105"></td>
</tr>
<tr class="Reference">
<td align="left" valign="top"><p>An e-newsletter published by<br>
Software Quality Consulting, Inc. </p>
</td>
<td align="right" valign="top"><p>May 2005, Vol. 2 No. 5 <br>
[<a href="http://www.swqual.com/newsletter/vol2/no5/vol2no5.txt" target="_blank">Text-only Version</a>] </p>
</td>
</tr>
</table>
<br>
<br>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0" class="BodyText">
<tr>
<td align="left" valign="top"> <p> Welcome to <em><strong>Food for Thought™</strong></em>, an e-newsletter from <strong> <a href="http://www.swqual.com?Intro" target="_blank">Software Quality Consulting</a></strong>. I've created free subscriptions for my valued business contacts. If you find this newsletter informative, I encourage you to continue reading. Feel free to pass this newsletter along to colleagues by clicking this <strong><a href="http://ui.constantcontact.com/roving/sa/fp.jsp?plat=i&p=f&m=sctz69n6">Forward Email</a></strong> link. If you’ve received this newsletter from a colleague and would like to subscribe, please click this <strong> <a href="http://www.swqual.com/newsletter/Subscribe.htm" target="_blank">Enter New Subscription </a></strong>link. If you don't wish to receive this newsletter, click the <strong><a href="#bottom">SafeUnSubscribe</a></strong>™ link at the bottom of this newsletter, and you won’t be bothered again.<br>
<br>
Your continued feedback on this newsletter is most welcome. Please send your comments and suggestions to <strong><a href="mailto:[email protected]">[email protected]</a></strong>. </p>
</td>
</tr>
</table>
<br>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0" class="BodyText">
<tr>
<td width="114" align="right" valign="top" background="/newsletter/images/RedSpacer.gif"><div align="center"><img src="/newsletter/images/InThisIssue.gif" width="114" height="37"><br>
</div></td>
<td width="15"> </td>
<td align="left" valign="top"><p> In <a href="#article"><strong>This Months’ Topic</strong></a>,
I discuss using Root Cause Analysis to find the real cause of Customer Reported Problems… <br>
<br>
Regular features to look for each month are:</p>
<ul>
<li> <a href="#morsel"><strong>Monthly Morsels</strong></a><br>
Hints, tips, techniques and reference info related to this month’s topic</li>
</ul>
<ul>
<li> <a href="#calendar"><strong>Calendar</strong></a><br>
Conferences, workshops, and meetings of interest to software engineers, QA engineers and anyone interested in software development</li>
</ul>
</td>
</tr>
</table>
<br>
<br>
<a name="article"></a>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0" class="BodyText">
<tr>
<td width="114" align="left" valign="top" background="/newsletter/images/RedSpacer.gif"><p align="center"><img src="/newsletter/images/ThisMonthsTopic.gif" width="114" height="37"><br>
</td>
<td width="15"> </td>
<td width="471" align="left" valign="top" class="BodyText"><p align="center" class="Headline">Getting to the Root of<br>
Customer Reported Problems</p>
<p> Of all the kinds of problems that software development organizations face, <strong>Customer Reported Problems </strong>(CRPs) are clearly the most important. This is because CRPs represent potential gaps in your knowledge of how your customers use your software. CRPs may be the result of deficiencies in your product marketing, software development, test, or fulfillment processes. CRPs can often result in unplanned releases that are both disruptive and expensive. </p>
<p> When the underlying cause of CRPs are not fully understood, they can result in poor solutions that often create more problems than they solve. Nothing frustrates customers more than a supplier who is unable to resolve problems quickly and with correctly.</p>
<p><strong> Motivation</strong></p>
<p> By now, we should all know that the sooner a problem is found the easier and less costly it is to fix. Barry Boehm [1] demonstrated this almost 25 years ago. Current data [2] suggest that even the most experienced developers inject one defect for every 10 lines of code they write. While effective testing can find up to 95% of these defects prior to release, that still leaves quite a few defects for customers to find. </p>
<p>Finding critical defects in your software is very disruptive not only for your customers but for your software development organization as well. Unplanned releases to fix CRPs divert expensive development resources from tasks that generate revenue (new features, new products, etc.) to tasks that don’t generate revenue (bug fixes). Unplanned releases are clearly not good for your bottom line. </p>
<p>CRPs represent more than just defects. CRPs should be broadly defined to include<strong> any failure of software and services</strong> (including code, documentation, installation, customization, fulfillment, training, etc.) that negatively impacts customers. </p>
<p><strong>Root Cause Analysis </strong></p>
<p>Working in safety-critical industries has allowed me to become familiar with several tools not routinely used in the commercial software development industry. One such tool is called <strong>Root Cause Analysis</strong> (RCA). This tool is commonly used within a Six-Sigma framework. </p>
<p>I’ve adapted the traditional <strong>RCA Process</strong> to make it work effectively within typical software development organizations. RCA helps people understand <strong>WHAT, WHY</strong>, and <strong>HOW</strong> an <strong>event </strong>(a CRP) occurred. </p>
<p><strong>Overview</strong><br>
<br>
</p>
</td>
</tr>
<tr>
<td align="left" valign="top" background="/newsletter/images/RedSpacer.gif"><img src="/newsletter/vol2/no5/images/shuttle.jpg" width="110" height="83"></td>
<td> </td>
<td align="left" valign="top" class="BodyText"><p>RCA is routinely used to investigate the cause of major disasters including: </p>
<ul>
<li> Airline crashes </li>
<li> Space Shuttle accidents </li>
<li> Chemical and nuclear plant disasters </li>
</ul>
<p> RCA helps us:</p>
<ul>
<li> understand causes of customer dissatisfaction </li>
<li> understand the <strong>what</strong>, the <strong>why</strong>, and the <strong>how</strong>… </li>
<li> reduce rework by preventing recurrence </li>
<li> identify process weaknesses </li>
<li> improve customer satisfaction </li>
</ul>
<p> In applying RCA to a typical software development organization, we need to keep in mind the fact that finding the root cause of a CRP may be difficult because:</p>
<ul>
<li> We often have an incomplete problem definition </li>
<li> Causal relationships are unknown </li>
<li> We tend to focus on finding quick solutions and assigning blame </li>
</ul>
<p> Let’s now look at terms specific to the RCA process.</p>
<p><strong> Terminology</strong></p>
<p> The RCA Process uses the following terms: </p>
<table border="1" cellpadding="5" cellspacing="0" bordercolor="#000000" bgcolor="#FFFF99" class="BodyText">
<tr>
<td valign="top"><p><strong> Event</strong></p></td>
<td valign="top"><p> Any failure of software and services (including code, documentation, installation, customization, training, fulfillment, etc.) that impacts customers. A CRP is an example of an event.</p></td>
</tr>
<tr>
<td valign="top"><p><strong> Causal Factors</strong></p></td>
<td valign="top"><p> Factors that contribute to occurrence of an event.</p></td>
</tr>
<tr>
<td valign="top"><p><strong> Causal Relationships</strong></p></td>
<td valign="top"><p> Cause and effect sequence in which a specific action creates a condition that contributes to or results in an event.</p></td>
</tr>
<tr>
<td valign="top"><p><strong> Corrective Action </strong></p></td>
<td valign="top"><p> Specific actions taken to eliminate root cause of a CRP. There are two kinds of Corrective Actions (CAs): </p>
<ul>
<li><strong> Immediate CA</strong> is taken soon after CRP is reported to help customer recover (examples: workaround, hot fix, etc.) </li>
<li><strong> Long Term CA</strong> taken to prevent recurrence. Long Term CA results in changes to process and procedures </li>
</ul></td>
</tr>
<tr>
<td valign="top"><p><strong> Root Cause</strong></p></td>
<td valign="top"><p> Cause that, if corrected, prevents recurrence of this and similar <strong>CRPs</strong>. </p>
<p> Attributes of root causes: </p>
<ul>
<li> Represent specific underlying causes of <strong>events</strong>… </li>
<li> Can be reasonably identified… </li>
<li> Can be fixed by Management… </li>
<li> Lead to effective <strong>corrective actions</strong>…</li>
</ul></td>
</tr>
</table>
<p>Let’s look a bit closer at the attributes of root causes:</p>
<ul>
<li><strong> Root Causes represent specific underlying causes of</strong><strong>CRPs</strong></li>
</ul>
<ul>
<ul>
<li> The goal of RCA is to find specific underlying causes </li>
</ul>
</ul>
<ul>
<ul>
<li> The more specific the investigation is about why a CRP occurred, the easier it will be to arrive at <strong>CAs </strong>that will prevent recurrence </li>
</ul>
</ul>
<ul>
<li><strong> Root Causes can be reasonably identified…<br>
<br>
</strong>
<ul>
<li> The RCA investigation must be cost-effective <br>
<br>
</li>
<li> A good RCA Process helps keep ROI high <br>
<br>
</li>
</ul>
</li>
<li><strong> Root Causes can be fixed by Management…</strong> <br>
<br>
<ul>
<li>Management needs to know exactly why a CRP occurred before effective <strong>CA</strong> can be taken to prevent recurrence<br>
<br>
</li>
<li>Vague root causes such as “user error”, “software failure”, or “external factors” are not helpful because Management can’t do much about them<br>
<br>
</li>
</ul>
</li>
<li> <strong>Root Causes lead to effective Corrective Actions… </strong></li>
</ul>
<ul>
<ul>
<li> Corrective actions are directly related to the identified root causes </li>
</ul>
</ul>
<ul>
<ul>
<li> Vague corrective actions mean specific root cause was not found </li>
</ul>
</ul>
<p> Now that we have some terms defined, let’s look at the Root Cause Analysis Process.</p>
<p><strong> RCA Process Overview</strong></p>
<p> The RCA Process consists of investigating, understanding, and categorizing underlying root causes of observed CRPs. It can be best performed by a small cross-functional team and can be easily incorporated into your <strong>Defect Triage Process.</strong></p>
<p> The RCA Process includes a detailed a nalysis based on gathering factual information obtained from:</p>
<ul>
<li> Available documents and records </li>
<li> Interviews with staff and customers </li>
<li> Brainstorming sessions with staff</li>
</ul></td>
</tr>
<tr>
<td align="left" valign="top" background="/newsletter/images/RedSpacer.gif"><img src="/newsletter/vol2/no5/images/tree.gif" width="110" height="118"></td>
<td> </td>
<td align="left" valign="top" class="BodyText"><p>And the RCA Process uses simple tools including:</p>
<ul>
<li> Why Trees </li>
<li> Pareto Analysis</li>
</ul>
<p> An effective <strong>RCA Process</strong> helps determine appropriate and effective corrective actions by identifying both an <strong>Immediate Corrective Action </strong>(what should be done today to resolve the CRP) and<strong> Long Term Corrective Action</strong> (what should be done to prevent recurrence).</p>
<p> In applying the <strong>RCA Process</strong>, the Triage Team starts with a specific CRP and asks:</p>
<ul>
<li> What is it about way we operate that allowed this CRP to occur? </li>
</ul>
<p> Most root causes are found in way we operate. That includes:</p>
<ul>
<ul>
<li> Who does what? </li>
<li> How things get done? </li>
<li> Why we behave way we do? </li>
</ul>
</ul>
<p> The Triage Team asks questions about “Who does what”, “How things get done”, and “Why we behave the way we do”, in order to identify factual information that can be helpful in identifying real root causes.</p>
<p> In asking these questions, the Triage Team uses a tool called the <strong>Why Tree</strong>. Why Trees are similar to Fault Trees in that the CRP is placed at the top. We then ask “Why did this happen?” and start drilling down into “Who does what”, “How things get done”, and “Why we behave the way we do”. At each level, the team continues to ask “Why” – usually at least five times (though for simpler problems, less than five Whys may suffice).</p>
<p> The following illustrates a partially completed <strong>Why Tree </strong>for a simple problem: </p></td>
</tr>
<tr>
<td align="left" valign="top" background="/newsletter/images/RedSpacer.gif"><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<img src="/newsletter/vol2/no5/images/vol2no5_clip_image004.gif" width="110" height="85"></td>
<td> </td>
<td align="left" valign="top" class="BodyText"><p><img width="432" height="300" src="/newsletter/vol2/no5/images/vol2no5_clip_image003.jpg"> </p>
<p> Answers to <strong>Why</strong> questions may need to be determined from documents (like Functional Specifications, Test Plans, User Manuals, etc.), from records (like test results, shipping invoices, etc.), from interviews with staff and customers, and from brainstorming sessions.</p>
<p> The information shown in green circles on the Why Tree example represents <strong>probable root causes</strong>. The Triage Team reaches consensus on the <strong>most probable root cause(s)</strong>. Often, there will be more than one root cause.</p>
<p> Using the <strong>Why Tree</strong>, the Triage Team develops an <strong>Immediate CA</strong> (which could be a workaround, hot fix, patch, new CDs, new doc, etc.). The team also identifies <strong>effectiveness checks</strong> that can determine if the <strong>Immediate CA</strong>, once implemented, has effectively resolved the CRP.</p>
<p> Once the <strong>Immediate CA</strong> is implemented and the <strong>effectiveness checks </strong>are satisfactory, the Triage Team decides if a <strong>Long Term CA</strong> is needed. A <strong>Long Term CA</strong> would be appropriate if the root cause points to systemic problems. If so, they begin to develop a<strong> Long Term CA</strong>. The team does this by:</p>
<ul>
<li> Reviewing existing processes and procedures </li>
</ul>
<ul>
<li> Identifying process weaknesses directly related to <strong>root cause</strong></li>
</ul>
<ul>
<li> Identifying potential process and procedure changes </li>
</ul>
<ul>
<li> Identifying<strong> long term effectiveness checks </strong></li>
</ul>
<p> Once the team has competed work on the <strong>Long Term CA</strong>, it can be presented to Management and implemented. The team then collects data to determine if <strong>long term effectiveness checks </strong>are satisfactory.</p>
<p> Now let’s identify the specific steps needed to perform an effective RCA.</p>
<p><strong> RCA Process Steps</strong></p>
<p> Step 1 - Data Collection </p>
<p>The majority of time spent analyzing events will be spent gathering data. Complete information and a thorough understanding of events required to identify <strong>causal factors</strong> and real<strong> root causes</strong>.</p>
<ul>
<li> Data collection begins with an accurate statement of what occurred in the Customer’s words:<br>
<br>
<ul>
<li> Descriptions of <strong>CRPs</strong> are sometimes “filtered” by Technical Support. It is critical that the original problem stated in the Customer’s words are recorded and reviewed by the team to prevent wasted effort… <br>
<br>
</li>
<li> Data collection will initially be sketchy – use the <strong>Why Tree</strong> to identify additional data to collect… <br>
<br>
</li>
</ul>
</li>
<li> Collect general information about Customer. Some examples:<br>
<br>
<ul>
<li> Is this Customer a power user or novice? </li>
<li> Has this Customer received training? </li>
<li> Is this Customer’s use and/or data unique? <br>
<br>
</li>
</ul>
</li>
<li> Collect information about Customer’s environment. Some examples: <br>
<br>
<ul>
<li> Does this Customer have a standard release or customer-specific release? </li>
<li> What are their platform/database/operating system releases? </li>
<li> Have they received hot fixes recently? Are they installed?<br>
</li>
</ul>
<br>
Your Technical Support staff should gather this information by using a c hecklist of questions to ask when Customers report problems.</li>
</ul>
<p> Step 2 – Determine What Happened</p>
<p> The Triage Team starts with the CRP in the Customer’s words and asks “Why did this happen?” As they start to drill down, they create the <strong>Why Tree </strong>and continue asking “Why?” until there are no more answers. Usually, you need to ask “Why?” a minimum of 5 times. </p>
<p> This process will identify additional information to collect. For example:</p>
<ul>
<ul>
<li> Was the requirement defined in the Software Requirements Spec? </li>
<li> Was the requirement ambiguous? </li>
<li> Was the requirement tested? If so, how? </li>
<li> Was the testing effective? </li>
<li> Was user training provided? Was it effective? </li>
<li> Are there platform, environment, or configuration issues? </li>
</ul>
</ul>
<p> When the team is satisfied that they have answered all the relevant questions and gathered all relevant information, the team is then ready to identify potential root causes.</p>
<p> Step 3 - Root Cause Identification</p>
<p> Based on the <strong>Why Tree</strong>, the Triage Team reviews results and identifies <strong>most probable root causes</strong>. The team ensures that <strong>most probable root causes</strong> meet the following criteria:</p>
<ul>
<ul>
<li> They represent specific underlying causes of events… </li>
<li> They can be reasonably identified… </li>
<li> They can be fixed by Management… </li>
<li> They can lead to effective corrective actions…</li>
</ul>
</ul>
<p> Once the team is satisfied that they have identified the <strong>most probable root cause(s)</strong>, they document their results.</p>
<p> With this information, the team can then identify an <strong>Immediate CA</strong>. These actions can be taken <strong>immediately</strong> to help resolve the original CRP. <strong>Effectiveness checks </strong>are included as part of the<strong> Immediate CA.</strong></p>
<p> Step 4 – Long Term Corrective Action</p>
<p> Once an <strong>Immediate CA</strong> is implemented and determined to be effective, the Triage Team decides if a <strong>Long Term CA</strong> is warranted. Usually, root causes that identify underlying systemic problems are good candidates. Also, once root causes are identified, they should be added to a list, as illustrated below:</p>
<p align="center"><strong> Example Root Cause List</strong></p>
<table border="1" align="center" cellpadding="5" cellspacing="0" bordercolor="#000000" bgcolor="#FFFF99" class="BodyText">
<tr bgcolor="#FF6600">
<td valign="top"><p align="center"><strong> RC </strong></p></td>
<td valign="top"><p><strong> Root Cause Description </strong></p></td>
</tr>
<tr>
<td valign="top"><p align="center"> 1 </p></td>
<td valign="top"><p> Requirement was defined in SRS but not tested </p></td>
</tr>
<tr>
<td valign="top"><p align="center"> 2 </p></td>
<td valign="top"><p> Requirement was tested but test was inadequate </p></td>
</tr>
<tr>
<td valign="top"><p align="center"> 3 </p></td>
<td valign="top"><p> Requirement was not defined in SRS </p></td>
</tr>
<tr>
<td valign="top"><p align="center"> 4 </p></td>
<td valign="top"><p> Requirement was in SRS but was ambiguous </p></td>
</tr>
<tr>
<td valign="top"><p align="center"> 5 </p></td>
<td valign="top"><p> Code was incorrect – Code review not held </p></td>
</tr>
<tr>
<td valign="top"><p align="center"> 6 </p></td>
<td valign="top"><p> Code was incorrect – Code review held but didn’t catch it </p></td>
</tr>
<tr>
<td valign="top"><p align="center"> 7 </p></td>
<td valign="top"><p> Installation or configuration issues… </p></td>
</tr>
<tr>
<td valign="top"><p align="center"> 8 </p></td>
<td valign="top"><p> Version compatibility issues… </p></td>
</tr>
<tr>
<td valign="top"><p align="center"> 9 </p></td>
<td valign="top"><p> User training issues… </p></td>
</tr>
<tr>
<td valign="top"><p align="center"> 10 </p></td>
<td valign="top"><p> etc… </p></td>
</tr>
</table>
<p> The Pareto Principle tells us that, in many cases, 80% of all problems result from only 20% of root causes. Performing a <strong>Pareto Analysis</strong> based on the Root Cause List can help determine what areas should be the focus of <strong>Long Term CA</strong> in order to keep the ROI high.</p>
<p> The following example illustrates a simple Pareto Analysis of observed root causes and their associated CRPs.</p>
<p align="center"><strong> Example of Simple Pareto Analysis of Observed Root Causes</strong></p>
<table border="1" align="center" cellpadding="5" cellspacing="0" bordercolor="#000000" bgcolor="#FFFF99" class="BodyText">
<tr bgcolor="#FF6600">
<td valign="top"><p align="center"><strong> CRP </strong></p></td>
<td valign="top"><p align="center"><strong> RC #1 </strong></p></td>
<td valign="top"><p align="center"><strong> RC #2 </strong></p></td>
<td valign="top"><p align="center"><strong> RC #3 </strong></p></td>
<td valign="top"><p align="center"><strong> RC #4 </strong></p></td>
</tr>
<tr>
<td valign="top"><p align="center"> 10002 </p></td>
<td valign="top"><p align="center"><strong> x </strong></p></td>
<td valign="top"><p align="center"> </p></td>
<td valign="top"><p align="center"><strong> x </strong></p></td>
<td valign="top"><p> </p></td>
</tr>
<tr>
<td valign="top"><p align="center"> 10014 </p></td>
<td valign="top"><p align="center"> </p></td>
<td valign="top"><p align="center"><strong> x </strong></p></td>
<td valign="top"><p align="center"><strong> x </strong></p></td>
<td valign="top"><p align="center"><strong> x </strong></p></td>
</tr>
<tr>
<td valign="top"><p align="center"> 10045 </p></td>
<td valign="top"><p align="center"> </p></td>
<td valign="top"><p align="center"><strong> x </strong></p></td>
<td valign="top"><p align="center"> </p></td>
<td valign="top"><p> </p></td>
</tr>
<tr>
<td valign="top"><p align="center"> 10345 </p></td>
<td valign="top"><p align="center"><strong> x </strong></p></td>
<td valign="top"><p align="center"><strong> x </strong></p></td>
<td valign="top"><p align="center"> </p></td>
<td valign="top"><p align="center"><strong> x </strong></p></td>
</tr>
<tr>
<td valign="top"><p align="center"> 16778 </p></td>
<td valign="top"><p> </p></td>
<td valign="top"><p align="center"><strong> x </strong></p></td>
<td valign="top"><p> </p></td>
<td valign="top"><p> </p></td>
</tr>
<tr>
<td valign="top"><p align="center"> 17889 </p></td>
<td valign="top"><p> </p></td>
<td valign="top"><p align="center"> </p></td>
<td valign="top"><p> </p></td>
<td valign="top"><p> </p></td>
</tr>
<tr>
<td valign="top"><p align="center"> 18779 </p></td>
<td valign="top"><p> </p></td>
<td valign="top"><p align="center"><strong> x </strong></p></td>
<td valign="top"><p> </p></td>
<td valign="top"><p> </p></td>
</tr>
<tr>
<td valign="top"><p align="center"> 19921 </p></td>
<td valign="top"><p> </p></td>
<td valign="top"><p align="center"><strong> x </strong></p></td>
<td valign="top"><p> </p></td>
<td valign="top"><p> </p></td>
</tr>
<tr>
<td valign="top"><p align="center"> 19992 </p></td>
<td valign="top"><p> </p></td>
<td valign="top"><p align="center"> </p></td>
<td valign="top"><p> </p></td>
<td valign="top"><p> </p></td>
</tr>
<tr>
<td valign="top"><p align="center"> 20001 </p></td>
<td valign="top"><p> </p></td>
<td valign="top"><p align="center"><strong> x </strong></p></td>
<td valign="top"><p> </p></td>
<td valign="top"><p> </p></td>
</tr>
<tr>
<td valign="top"><p align="center"><strong> total </strong></p></td>
<td valign="top"><p align="center"><strong> 2 </strong></p></td>
<td valign="top"><p align="center"><strong> 7 </strong></p></td>
<td valign="top"><p align="center"><strong> 2 </strong></p></td>
<td valign="top"><p align="center"><strong> 2 </strong></p></td>
</tr>
</table>
<p> From this analysis it is clear that addressing Root Cause #2 with a <strong>Long Term CA</strong> would have the highest ROI. The Triage Team would identify and propose a <strong>Long Term CA</strong> and present recommendations to Management. Included with this are effectiveness checks. Once implemented, data is collected and reviewed by the Triage Team to ensure that the systemic issues have been effectively eliminated.</p>
<p><strong> In Summary…</strong></p>
<p> Incorporating <strong>RCA</strong> into your Triage Process can lead to several benefits:</p>
<ul>
<ul>
<li> Increases your ability to discover real root causes </li>
<li> Helps identify WHAT, WHY, and HOW </li>
<li> Leads to effective immediate and long term corrective actions </li>
<li> Improves Customer Satisfaction </li>
<li> Reduces rework and eliminates unplanned releases </li>
</ul>
</ul>
<p> By incorporating <strong>Root Cause Analysis</strong> into your <strong>Triage Process</strong>, the resolution of your CRPs will be more effective and your customers will certainly be happier.</p>
Till next time…</td>
</tr>
</table>
<br>
<br>
<a name="morsel"></a>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0" class="BodyText">
<tr>
<td width="114" align="right" valign="top" background="/newsletter/images/RedSpacer.gif"><img src="/newsletter/images/MonthlyMorsels.gif" width="114" height="37"></td>
<td width="15"> </td>
<td align="left" valign="top"><p> Every month in this space you’ll find additional information related to this month’s topic.</p>
<ul>
<li> <strong>References</strong>:<br>
<br>
[1] Boehm, B., <em>Software Engineering Economics</em>, Prentice-Hall, 1981<br>
<br>
[2] Humphrey, W., <em>A Discipline for Software Engineering</em>, Addison-Wesley, 1995.<br>
<br>
[3] Gano, D., et. al., <em>Apollo Root Cause Analysis – A New Way Of Thinking</em>, Apollonian Publications, 1999<br>
<br>
[4] <a href="http://www.eh.doe.gov/techstds/standard/nst1004/nst1004.pdf" target="_blank"><strong>US Dept of Energy, <em>Root Cause Analysis Guidance Document</em>, DOE-NE-STD-1004-92, February 1992</strong></a><br>
A technical guidance document on how to perform traditional root cause analysis, primarily used for investigating nuclear power plant accidents.<br>
<br>
[5] <a href="http://www.asq.org/pub/qualityprogress/past/0704/qp0704rooney.pdf" target="_blank"><strong>Rooney, J. and Vanden Heuvel, L., "Root Cause Analysis for Beginners”, <em>ASQ Quality Progress</em>, July 2004, p. 45-53</strong><br>
</a>A good paper to read for an overview of the traditional Root Cause Analysis process…<br>
<br>
[6] Fagerhaug, T., and Andersen, B. (ed.), <em>Root Cause Analysis: Simplified Tools and Techniques</em>, ASQ Quality Press, 1999. </li>
</ul>
<ul>
<li> <strong>On-line Resources</strong>:
<br>
<br>
<ul>
<li><a href="http://www.cs.mdx.ac.uk/research/SFC/index.html" target="_blank"><strong>Software Forensics Centre at the School of Computing Science, Middlesex University ( UK)</strong></a><br>
An interesting site with lots of resources related to software failures<br>
<br>
</li>
<li><a href="http://qualitypress.asq.org/index.html" target="_blank"><strong>ASQ Quality Press</strong></a><br>
Search ASQ’s on-line bookstore for books and resources on Root Cause Analysis</li>
</ul>
</li>
</ul>
</td>
</tr>
</table>
<br>
<br>
<a name="calendar"></a>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0" class="BodyText">
<tr>
<td width="114" align="right" valign="top" background="/newsletter/images/RedSpacer.gif"><img src="/newsletter/images/Calendar.gif" width="114" height="37"></td>
<td width="15"> </td>
<td align="left" valign="top"><p> Every month, you’ll find news here about local and national events that are of interest to the software community …</p>
<ul>
<li> <strong>Software Quality Calendar</strong><br>
<br>
There are many organizations that sponsor monthly meetings, workshops, and conferences of interest to software professionals. <a href="http://www.swqual.com/links/upcoming.html" target="_blank"><strong>Find out what’s happening…</strong></a></li>
</ul>
<ul>
<li> <strong>Workshops Offered by Software Quality Consulting</strong><br>
<br>
Software Quality Consulting offers workshops in many topics related to software process improvement. <a href="http://www.swqual.com/seminars/courses.html" target="_blank"><strong>Get more info...</strong></a></li>
</ul>
</td>
</tr>
</table>
<br>
<br>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0" class="BodyText">
<tr>
<td width="114" align="right" valign="top" background="/newsletter/images/RedSpacer.gif"><img src="/newsletter/images/AboutSQC.gif" width="114" height="37"></td>
<td width="15"> </td>
<td align="left" valign="top"><p> Software Quality Consulting provides consulting, training, and auditing services tailored to meet the specific needs of clients. We help clients fine-tune their software development processes and improve the quality of their software products. The overall goal is to help clients achieve Predictable Software Development™ – so that organizations can consistently deliver quality software with promised features in the promised timeframe.</p>
To learn more about how we can help your organization, <a href="http://www.swqual.com" target="_blank"><strong>visit our web site</strong></a> or <a href="mailto:[email protected]"><strong>send us an email</strong></a>.</td>
</tr>
</table>
<br>
<br>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0" class="BodyText">
<tr>
<td align="left" valign="top"><p> I hope this newsletter has been informative and helpful. Your comments and feedback are most welcome. <a href="mailto:[email protected]"><strong>Send me your feedback…</strong></a></p>
<p>Thanks,</p>
<p> <img src="/newsletter/images/BusinessCard.gif" width="270" height="121" align="right"><img src="/newsletter/images/Signature.gif" width="90" height="68"><br>
Steve Rakitin<br>
<br>
<strong><a href="mailto:[email protected]">[email protected]</a></strong></p></td>
</tr>
</table>
<div align="center"><br>
<FONT class="Reference"> Food for Thought and Predictable Software Development are trademarks of Software Quality Consulting, Inc. <br>
Copyright © 2005. Software Quality Consulting, Inc. All rights reserved.
Graphic design by <B><U><FONT color=blue><a href="mailto:[email protected] ">Sage Studio</a></FONT></U></B></FONT></div>
<a name="bottom"> </a></body>
</html>