Root cause analysis..?

Root Cause Analysis
Root cause analysis is a technique that is used to describe about the problem ,which client or customer is facing. This problem which leads to the customer or client will interrupt the business or an delivering an particular software.
Describe the Issue:-
This is important to know about the problem from where the issue is arrived, in this step or stage the issue is drill-down. Try and break down issues into smaller individual where it is possible. Prioritize the issues and see if some are linked to internal and external factors.
Collect the information:-
Gather as much information about the situation as you can. Involve stake holders when ever possible to give input to the situation. some times it is the simple things that made a big difference.
To find out the root cause analysis we have two different techniques.
• 5-why techniques
• Fish bone method
5-why technique:-
A simple technique for identifying the possible causes where a group of people will brainstorm an issue by first asking why some thing happened then continue to ask why for each answers. there is no format of framing the questions but how well the questions are framed definitely help in getting the pertinent cause of the problem.
Example:-
Q.Why you get an error message?
A.There was an bug in software.
Q.Why was there a bug in the software?
A.There was a mistake in the code.
Q.Why was there is a mistake in the code?
A.The mistake was missed during the testing phase.
Q.Why was the mistake made during the testing phase?
A.There was not a test case written to the test that functions.

Why was not there a test case written for that function?
There was not a requirement to test that function.
For the above example you can see how asking why multiple times can help drill down to possible solutions of a problem. In this example a solutions could be to create a test case for that function that traces back to a requirements for that particular feature so that the testing team can test that particular function again.
Fish bone diagram:-
The root cause analysis process is also know as the “Ishikawa Diagram”
Fish bone diagram and the cause and effect diagaram,these tools make it possible to identify all of the potential effects in a prospective approach.
In this ishikawa diagram identified 5-keys which will point to the problem or issue.
 Process
 Machine
 Environment
 People
 Material
If we have a issue In the process
Then what kind of problem we have in process.
 The requirements gathering process is poorly documented
 There is no requirements configuration management
 There is no penalty for scope creep.
By the above key points we can notice that where the problem have been occurred. So that we can solve the problem or issue, according to that.
Example:-
Let us take an migration project which is related to the telephone domain (vodaphone..ind).
Description:-
Usually vodaphone is maintaining a large database(warehouse),where they can store 1-TB of data per day.
Query:-
They want to change the database to teradata to neteeza so that they can store large amount of data when compared to TD.

Condition:-
Usually they can maintain the data not more then 2-years. But after migration of TD to NZ they can store data up to 3-4 years.
Analysis:-
This will help them to analyze there business efficiently, and they can get reports in the bases of daily,monthly,weekly.
Explanation:-
While doing migration from TD to NZ we came to know that we have to change all the data types,which is supporting TD to NZ. Data types which is related to Td will not support to NZ.
Even after changing all the data types we are not able to process the data as we configured and when compared to td.
Issue:-
Actually issue is that even after changing all the data types from TD to NZ, we have to all ready installed a new version of NZ –Steeper which is not all used till now by any company.
Solution: –
Just we have an internal trail run with old data base steeper and we came to know that the issue is with the steeper.
So we have changed the new steeper to old version of steeper. By the getting approval from client.

Determine the best cause:-
Out of the possible causes there should be one causes that stands out. If so select this as your root cause and start to determine the solution to prevent this issues from happening again.
Determine the solution:-
Identify all the possible solutions and pick one the best solution that seems to be best solution for the issues. Involve some stack holders in this process ,gather there feed back to see on the selecting the best solution.

Test the solution:-
Test the solution in a test environment where you recreated the issue, if you were able to recreate the problem. This type of testing is very important and should be included in your sdlc.if you are unable to determine a solutions you may redo the 5-why techniques.
Getting sign-off:-
We have to get an approval that this solution you have selected is the one you go with.
Get the document approval from every one, agrees with the solution and also document the any reasons why people have not agree for this particular solution. This information can be used to update project document.