Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 2 Next »

How to use the template

This template is a guide to help you document how you do things to achieve the results you get. In order to get consistent, repeatable outcomes, it is important that others know and understand your method. That is what process documentation is all about.

This template has sections. Each section has prompts with instructions and examples that guide you to specify the information required in each section.

Delete this ' How to use the template' section after writing the information in all the subsequent sections.

Process General Details

All information in this section is mandatory.

Process NameRoot Cause Analysis (RCA) Process
Process DescriptionThe RCA process is a quality management tool. It is the process of defining, understanding and solving a problem. It has a two-fold purpose: 1) to identify the real cause of a non-conformance or quality problem 2) to suggest changes to permanently eliminate the problem through process improvements. By doing the RCA, it is possible to identify the precise point in the causal chain where corrective action or intervention prevents the non-conformance from occurring.
Process Scope

Root Cause and its corrective action identification process will be initiated for specific events which are listed below. The initiation of RCA process is not limited only for these events but can be initiated of other events by notifying the Solutions Program Management team about the event and its impact. The below events will mandatorily trigger a RCA and identification of corrective actions either to improve the product or to improve the delivery process 


  1. Any P1/S1 Bug identified in production
  2. Recurring defects across the release testing (twice or more)
  3. Recurring Bugs in production irrespective of severity (Twice or more)
  4. Deployment issue
  5. Metrics missing the LCL & UCL
  6. Adhoc items e.g Failed Migration, Environment unavailability etc.


RCA will mainly focus on identifying the preventive actions i.e the actions that will help to reduce or remove the potential of similar issue to happen again. Some of the above trigger will need a corrective action to fix the issue and will call for a RCA to identify the preventive action.

Process RolesSolution Program Management, Release Manager, Product Manager, Tech Manager, Tech Leads
Process BoundaryThe end of a release cycle triggers the start of the RCA process. The RCA Meeting for P1s will be held once a month on the 4th Thursday of the month. The acceptance and implementation of the corrective/preventive actions that have devolved mark the end of the RCA process.
Process StagesThe RCA process has 5 stages.
1) RCA Event Trigger
2) Identify Root Cause and Corrective Action
3) Review and Approve Root Cause and Corrective Action
4) Implement Action
5) Validate Results and Close

Process Diagram

This section is mandatory. Repeat this section as many times as required from stage 1 of the process until the last stage of the process. Delete the Information section after you enter details in the table.

Input
  1. Any P1/S1 Bug identified in production
  2. Recurring defects across the release testing (twice or more)
  3. Recurring Bugs in production irrespective of severity (Twice or more)
  4. Deployment issue
  5. Metrics missing the LCL & UCL
  6. Adhoc items e.g Failed Migration, Environment unavailability etc.
Output

1. List of Corrective/Preventive Action

Role(s) InvolvedSolution Program Management, Release Manager, Product Manager, Tech Manager, Tech Leads
Stage Activities

All the stakeholder meet with a primary goal to analyze problems or events to identify:

  • What happened
  • How it happened
  • Why it happened…so that
  • Actions for preventing re occurrence are developed

Exceptions 

None

Process Metrics

None

  • No labels