What if the Value is Not Being Attained?

One of the key duties for CSMs during Phase 6: Value Realization is to ensure that the value that is being attained is measured, analyzed and reported to the customers’ decision makers. This is so that these decision makers have the information needed to be able to make the decision to renew service contracts and replace products, on the basis that value is being realized currently and therefore it makes sense for them to ensure that this value continues to be realized.

But how about if measurements are being taken, analyzed and reported that show that value is not being attained, or at least not being attained as much as the customer desires or requires it to be? Well this type of situation is of course of equal if not even greater importance for the CSM to step in and deal with than our first scenario [reporting on progress, covered in other articles]. In this situation the task of the CSM is to help the customer as best as possible to turn the situation around such that the products and/or services are generating value for the customer. Of course this may be a lot easier said than done, and there are many reasons why a product or service may be failing to deliver the required or desired value for which it was purchased. The start point to fixing the problem is to find out why the value is not being created. This is referred to sometimes as root cause analysis and we will take a look at how the CSM might go about performing this activity.

Know Your Outcomes and Milestones

First though, and before even this start point can be reached, CSMs are advised to check back in their documentation to make sure that the desired and/or required outcomes for the initiative have been correctly identified, since it is possible sometimes that customers might inadvertently (or even on occasions deliberately) move the goalposts and may now be attempting to attain unrealistic outcomes that are simply unachievable. This of course can be very easily done simply by reviewing the Customer Engagement Strategy (or similar) that the CSM created during Practical CSM Framework Phase 1: Preparation and the Customer Success Proposal and Customer Success Contract (or similar) that the CSM created during Practical CSM Framework Phase 2: Commitment.

Once the CSM is reassured as to the correct outcomes and/or significant milestones that have been agreed between the supplier and customer, the CSM can start work on root cause analysis. The idea of root cause analysis is to determine the real or underlying cause of the problem, so that this underlying issue can be fixed and in so doing the problem can be resolved in a way that reduces the likelihood of its re occurrence as much as possible.

What is Root Cause Analysis? Example: Fixing a Headache

For example if you have a headache then one possible cure for the headache might be to take a painkiller such as paracetamol or aspirin. This painkiller may well reduce or even entirely remove the feeling of pain that the patient is experiencing, but the underlying cause – the reason why they were getting the headaches in the first place – has not been dealt with. Perhaps this underlying problem will fix itself without any intervention needed, in which case all will be fine. If not however, then when the effects of the pain killer have worn off, the patient will be back again experiencing the same headache as before.

Perhaps the underlying problem or the root cause of the problem is discovered to be dehydration. If this is the case, and if the patient is rehydrated – for example by drinking a glass or two of water – then the chances are that over time the pain will go away without the need for a pain killer, since the root cause of the pain has itself gone away. Of course it is also entirely possible that even if as in this example the underlying problem is addressed, it might take a while for the effects of this fix to be felt. In our example it might take a while even after our patient has drunk the water for all the cells in the patient’s body to rehydrate back to their normal, hydrated state. In this circumstance, it might be a good idea for the patient to both treat the root cause of their problem by taking on liquids and also simultaneously treat the symptoms of pain by taking a pain killer. In this situation the existing discomfort associated with dehydration is treated as well as the underlying issue, so that the patient both feels well in the short term and continues to feel well in the longer term.

Root Cause Analysis Steps

Here are the steps for using root cause analysis:

Step 1: Define the problem and explain its impact

Step 2: Define the process

Step 3: Identify possible causes

Step 4: Identify and implement countermeasures

Step 5: Test for resolved

1. Define the problem and explain its impact

When identifying and defining the problem and the impact it is having, make sure you remain focused on the facts rather than emotions or opinions, and on describing the problem rather than jumping too quickly to solution mode. “The Five Ws” is one good way to define the problem (what, when, where, who, why and how).

An example of a well-defined problem would be:

5.1% of products sold are currently being returned by customers as faulty within the warranty period of 12 months. This level of returns is approximately twice the average for our industry as a whole of 2.6%. This problem is causing customers to be frustrated with our products and losing us an estimated $15m pa in repair and replacement costs combined with lost sales opportunities due to damaged brand reputation, compared with if our returns rate was at the industry average.

If relevant and desirable, you might at this stage provide a stop-gap solution or a “workaround” such as temporary hosting of a mission critical application at a third party datacentre whilst you get to the bottom of the problem that is occurring in your own datacentre, or the diversion of orders to another production line or even another factory whilst you work on getting the problem fixed on this production line.

2. Define the process

As you know from Module 2, there are three aspects of any business capability – people, process and tools. All too often the problem is blamed on people when really it is to do with the process, or with the tools or the training and support of the people, not the people themselves.

To identify what is happening (Step 1) or to start gathering information about the circumstances in which the problem occurs, the recommendation is for you (or someone) to actually go to the physical place where the problem occurs and either observe it happening or talk to the people who have observed it happening and record the process steps and if possible describe exactly at what stage the problem occurs and how it happens. Talk to as many people who are involved with the process as possible to get a rounded and three dimensional view of what’ happening. It may be useful to create a workflow diagram or simple process map that explains all the steps in the process and shows where the fault occurs.

The concept of physically going to the site of the problem is described as a “gemba walk”. The word “gemba” means “the actual place” in Japanese, and the concept comes from Lean Management best practices that dictate that managers who want to know what’s really happening need to get out of their plush offices, grab a safety helmet (if necessary) and go and take a walk around the shop floor where everything takes place – for example where the cars are assembled, or where the developers create the applications, and so on.

3. Identify possible causes

If the root cause of the problem is known then this step can be omitted and instead the root cause can simply be documented and the CSM can go on to Step 4. Assuming the root cause has not yet been identified, in this step the CSM helps the customer to consider and document what the possible causes of the problem might be. What’s needed is as comprehensive a list as possible, in order to increase the likelihood of the true cause having been identified and documented within that list.

The classic approach is a brainstorming workshop with as many different people as are useful. An idea group size for brainstorming is around 5 to 9 people, since generally speaking this provides sufficient energy and creativity in terms of ideas sharing, provides sufficient different perspectives, and yet remains manageable in terms of ensuring everyone attending gets opportunities for input into the conversation and where necessary consensus opinions can be reached.

To help the group consider all possible causes, it makes sense to break down the overall topic into more manageable categories that allow workshop attendees to focus their minds on just one aspect of the “system” in which the root cause of the problem resides. For example one category to discuss and consider might be “communications”, another might be “process documentation”, another might be “service and maintenance”, and so on. If you as the CSM are not sure what categories would make sense for the particular problem the brainstorming team will be working on, get a subject matter expert (for example the process owner) to help you formulate the list of categories to use.

Another popular methodology is called “Five Whys”. The concept here is that the CSM – or indeed the brainstorming group – keep asking the question “why?” to unpeel layers of causality below which are deeper causes, until finally there are no more possible questions “why?” to ask because the root cause is reached. The idea here is not to insist upon there being five or any other specific number of layers to unpack, but simply to recognize that just because an answer has been reached it doesn’t mean that the ultimate, root cause has yet been uncovered, and to continue to explore each cause that has been identified to see if it in turn has underlying causes. When no underlying causes can be discovered then the “root” cause can be said to have been reached.

Another brainstorming tool is the “Cause and Effect Diagram”, often referred to as the “Fishbone Analysis” method, and also sometimes referred to as the “Ishikawa Analysis”. This is a best practice technique from Six Sigma that captures different effects in a way that encourages the uncovering of their causes. To perform a fishbone analysis you start by agreeing and writing down a problem statement. From this you branch out the major categories of potential causes of this problem. For each major category you then again branch out with sub categories of that category, and you sub categorise as many times as necessary until ultimately you reach actual causes.

Once all possible root causes have been discussed, identified and documented, you need the team to help you further by sorting the list of potential root causes to the problem into priority order, with the most likely cause at the top and the least likely at the bottom.

6. Identify and implement countermeasures

In this step you will go through the list of possible causes one by one, starting with the most likely cause. For each cause, you first need to identify one or more countermeasures (ie solutions to the problem) to try out. Sometimes the solution to implement may be obvious (for example if you’ve identified that the cause of the problem is a broken part then replace that part with a new one). At other times there may be multiple possible countermeasures to try. If this is the case then as with the list of potential root causes, you need to prioritize your list of countermeasures and try the best one first. In this instance the “best” countermeasure to try might be the most likely one to work, but you may also need to consider other factors such as cost to implement, time to implement, difficulty to implement and so on. It may sometimes make sense to try a simpler countermeasure (for example one that takes just five minutes and costs nothing) first, even though another countermeasure (one that perhaps would take several days of someone’s time to implement) might be more likely to resolve the problem.

If the necessary countermeasure turns out to take a lot of time to implement (for example perhaps you need to order a spare part, or perhaps you need to get outside expertise to assist with it) then you may want to consider a stop gap or interim workaround at this stage if you have not already done so.

Work through the list of potential solutions one-by-one. Unless you have a real necessity to do so, do not apply more than one countermeasure at a time, else you will not know which solution actually fixed the problem. This will make it harder to fix this or similar problems in the future if you encounter them.

As with any work, make sure you plan any solution implementation, obtain any authority to proceed that might be necessary, assign owners to take on the task and provide them with a deadline for completion and agree with them what “completion” will mean. Also make sure you have identified a way to take measurements to learn if the solution has worked.

7. Test for resolved

Once the solution is in place, test it by taking and then analyzing these measurements to determine if the problem has been fixed. If it has not been fixed, try the next countermeasure on your list. If the problem has been fixed then also check to make sure that the countermeasure has not produced any further problems to the system, and if all is good then document both the problem and the countermeasure for future reference.

The Role of the CSM in Solving Customers’ Problems

CSMs should be able to recognize when it is appropriate for them to take on the role of “problem solver” and when to take more of a back seat, allowing and enabling others (for example one of the customer’s own members of staff) to take control. In the latter situation the CSM should still be proactive with advice and assistance as appropriate.