Feedback and feedforwards help you succeed! Part 2

In search of the root cause….

The journey could be a little tedious but is worth taking.

The RCA or Root Cause Analysis as it is popularly known among task performers and managers is one of the most crucial links of the feedback–feedforward loop. This analysis and the subsequent finding(s) set the ball rolling towards a solution for the whole issue. It is a structured and effective way to reach the root of the problems caused.

Before taking you through the various steps involved in an effective RCA, I would like to remind you that one of the most important requisites for an RCA to be effective is to indulge in the exercise as a team — it is a group activity.

Get members from the various teams involved in the process together — beware that to begin with it might seem that the feedback has nothing to do with certain teams until you delve deeper and find the actual root cause. If you can ensure that each representative is familiar with the process that is going to be investigated, it will make your life easier. A cross-functional team can provide you with all possible perspectives. This will steer you towards making an informed decision.

We will now take a peep at the 5 steps involved in an RCA and the subsequent PA (Preventive Action).

i. Problem Statement: The first step is to identify the problem and define the Problem Statement

This is important because we cannot take the feedback we received as the actual problem. The person giving the feedback might have fed back only issues he/she faced.

Examples:

a. Customer unhappy with the end product — this could be the feedback provided. The actual problem statement would be to check and define what aspect of the product disappointed the customer.

b. A client could be very unhappy with the help desk management system provided by a vendor — the client only expresses what he/she feels as technical expertise to identify the problem lies with the developer and his/her organization. Upon further probing or discussion with the client, you may probably understand that the problem statement is that ‘the client finds the user interface unfriendly because he was looking for a Graphical User Interface (GUI) while what was given to the client was a menu-driven one. So the problem statement would now become ‘the wrong type of interface offered to the client’

ii. Identify the root cause: After analyzing all the possible contributing factors, you need to arrive at the root cause.

This is the pivotal stage that provides the framework for a successful management of the issue(s) at hand. It can at times expose multiple causes for a single feedback before we arrive at the root cause. While the first stage can be taken to identify the actual symptoms of an illness, the second stage identifies the deeper problem — the disease itself.

Example

In the example given above, it would first appear from the client’s feedback that the developer had done a poor job. But the analysis done at this stage may prove to be a game-changer and the focus would now be on the contract signed in or the developer brief provided to the developer etc. and probably has nothing to do with the performance of the developer at all! Do you see the difference between the symptom and the actual illness?

There are many ways of identifying the root cause, however, the most recommended is the one from the Lean Management arsenal, the Five Whys Technique. This is a very useful technique for individuals and organizations and is worth a separate write up and a few more minutes of your precious time. My next part in this series will focus on the same.

iii. Find a solution: Arrive at way(s) to arrest/prevent the problem

Now that you have arrived at the root cause of the issue, you will have to find a solution for the problem — the medicine for the illness. Having identified whether the root cause lies with an individual, which is quite rare as against popular belief, or the system or the workflow, it is now time to wrack your brains solution. The same team should continue to work on the solutions part so as to make the solution viable and sustainable.

iv. Corrective Action: An action to rectify the current feedback received

Corrective actions need to be taken to resolve the current issue, to eliminate a nonconformity or deviation or defect that incurred in the past and provoked the feedback at hand. This need not necessarily be a sustainable solution and the intensity of the action would depend on the extent of importance given to that particular client.

Example

In the example regarding UI, the vendor has the option to redo the entire UI for free as per the client’s expectation even if the client had not made the requirement explicit in the service level agreement probably because the client is of much importance. Alternatively, the vendor could offer to do it for a cost or enhance the existing menu-driven one to make it extremely user friendly. Note that this a corrective action for this one instance and not really a sustainable one.

v. Preventive Action: i. A long-term solution for preventing the issue from recurring

This has to be a sustainable solution and one that would prevent the feedback from recurring. This should have the approval of the all the stakeholders and should be shared with everyone involved.

The preventive action for the example would be to strengthen the documentation around agreements and contracts and the workflow with reference to passing on the requirements to the developer.

An effective RCA can be done for positive feedback as well so as emulate the successful model. If an effective RCAPA is done even negative feedback would add value to the system and we cannot agree more with Henri J Kaiser that, ‘Problems are only opportunities in work clothes’.

Climbing the RCAPA staircase with awareness and caution would lead to greater insight…

Happy and Fruitful Feedback Analysis!