Outcome Based Approach

Disclaimer: I have been writing the blogs in the style of story telling based on real incidents but with some fiction added to emphasize the message. Hence please do not conclude anything based on the blogs. 

I received an email from Bhahmaji and I knew this will never be simple. Bharhaji recently went and visited a Customer. This means, the email from Bhahmaji will very likely contain all descriptions on how dissatisfied the customer is, and how the Customer is going to terminate the contract, and how Customer may sue us for a penalty of a few millions. Brahmaji loves to have escalations and reminds the customer on what all the areas when Customer can be unhappy. And than we will see Brahmaji floating emails and action plans on how is he going to address all Customer Concerns. Unfortunately even many organizations have a culture of appreciating leaders who address the escalations. But the leaders who do everything proactively and ensure no escalations are ignored and they may even be asked to leave to accommodate another blue eyed boy (or girl) to manage that "smoothly" running Portfolio.

I was used to it but still I needed to give some attention because at times Brahmaji could be right as well. ​When I opened the email, it was all the same. Customer has lots and lots of complaints and all were opened up when Balaji met them. Not even one was discussed in the weekly customer calls and even som daily calls.

Customer has serious concerns on our ability to do Continuous improvements. He was also worried about the Automation Opportunities which we never worked. He is highly disappointed about us not contributing towards any productivity gains. Support was going, all tickets were being fixed but with no interest on Customer's Business Problems.

Brahmaji completed the email with a statement that the Customer who has been with us for the last 5 years may leave us any day in next week including tomorrow.

He scheduled a crisis meeting.

I fortunately had time to accommodate myself to the discussion.

By the time I joined the call, I was hearing Brahmaji shouting on all the team for not doing anything. I heard the conversation without disturbing the flow of communication. Finally I announced my presence and asked Bhrahmaji on what is the action plan now.

Bhrahmaji said that we made action plan already and here are the major items.

​Action item	​Owner	​Target Date	​Status	​Remarks
​Daily Internal review meeting to be scheduled	​Bhahmaji	​Tomorrow	​Completed	​A Daily meeting calendar generated
​Weekly Project review meeting	​​Brahmaji	​Tomorrow	​In Progress	​Checking with Leaders availability
Steering Committe Review Meetinq ​	​Bhahmaji	​Next week	​In progress	​Checking with Steer Co member availability
​Speak to COE for Support on XXX Technologu	​Keshwa	​Next week	​Open	​XXX technology is required to do the task and the Project Manager needs to get the inputs from COE
​Initiate VISA requet for Apparao	​Chris	​Next week	​Open	​Apparao has to travel to execute Quater Closure issues
​....	​....	​....	​....	​...
​	​	​	​	​

I went through the entire list. For some time I didn't understand what is the plan. I was asking Bhrahmaji "What are the issues? and how are we going to address them?"

"Sir, I already shared the action plan. This plan is to address all concerns and issues raised by the Customer"

"OK. Please explain how are we going to address"

"I scheduled a Daily review call to discuss issues every day"

"OK. than?"

"We will fix the issues. We also scheduled a Project review on weekly basis. We talk to Steering committee on weekly basis and ....."

I opened the action items sheet and said. "Bhrahma.. all the action items that you mentioned will be completed once we schedule the meeting calendar and after a couple of discussions like initiating VISA request, discussing with COE etc. But at the end of closing all these action items are we sure the Issues are addressed?"

Bhahmaji was a bit silent.

"No sir. These are for solving the issues"

"Where is the plan to solve the issues and where is the rationale to decide whether the concerns of the Customer are addressed?

"...."

Can you Please explain what do you want to do and what do you expect to hear that the customer is happy?

"Hmm. If we do these reviews regularly ..."

"Bhahma! do you want the customer to explain what needs to be done to make him happy through these review meetings?"

"This is how I have been making him happy ..."

"Probably you could do that but you always wanted to hear from Customer through several discussions and than do the needful. Why cant we do this before Customer puts this much effort?"

"I cant say anything but it worked"

"OK, how are we going to ensure there is continuous improvement? What are the Automation Opportunities? What is the meaning of Fixing issues without interest and how can you convince customer that we are fixing issues with interest? ...."

"As of today I am not sure sir. But through these reviews ...."

They are all interlinked. You need to analyze and review the support tickets and summarize.

The issues can be repetitive. That is when you need to work on educating and ensuring elimination of the issues through root cause analysis. And by nature if they are bound to repeat, prepare a good Solution document and share instead of fixing them every time.

The issues can be knowledge gaps. In such case propose additional training. Once again the training's can be self paced through View Lets, recorded training's or Idiot guides so the audience don't depend on physical training's. Update the training manuals if required.

The issues can be due to Data. The Data issues can be either because poor migration and conversion scripts for data from other systems and cause Data Corruption regularly. It can also be because of the poor development without restricting the wrong entries without validations. You may have to investigate and clean the scripts apart from fixing the specific data issues.

The issues can also be because of wrong set ups of transactions and parameters. Explain on why certain transaction behave because of the setup and educate the customers to arrive at the right setup. You may also visit the documentation and any need for special training's on them.

Finally the tickets can be for technical Bugs. These are fully because your coding was not doing what was intended. Fix them completely and test thoroughly.

For every issue, tailor your ticketing system to take the inputs on how the addressing or not addressing the issue impacts the Business. This helps you understand how the system is being impacted. Identify the kind of tickets which take longer to fix either because of the external dependencies or by the process. And identify those kind of tickets which impact the Business to Maximum. Pick the top ten and try to optimize them to fix them fast and reduce SLA.

Bhrahmaji seems to have understood but his face shows there are still some open questions.

I picked on ticket that too 4 days to fix the issue.

The ticket is for creating a User to one data warehouse. Why is this taking 7 days ? I looked at the SLA for such type of ticket. The SLA itself was 7 days.

I got in to the details. The User enters the Ticket in the system with the details of his system, and many technical parameters such as Proxy address etc. Many users are not familiar to enter these details. I have seen the support engineer taking the appointment to guide the user to enter these details. User enters the details and than resubmits the details. Support engineer gets some details on her own. Finally the synchronization of the Windows user with this Data-warehousing system takes 30 minutes.!!!!

I said this is an automation opportunity. Brahmaji quickly said that this takes 60 person days to make the Single Sign on.

What is the ticket volume for this User creation? 1200 tickets per quarter. (AUTOMATION)

Hence it is worth doing. All tickets of this category will be eliminated to free at-least 2,3 days of effort per ticket of the users who are supposed to work for business. This means about 2400 Person days of productive time gained by the Customer. These hours can be utilized any where-else for the productivity (PRODUCTIVITY GAINS). In addition, the Users start working in the Data-warehouse within no time. This is again Productivity gain !!!

Now, we continue this kind of analysis and present our observations periodically to the Steering Committee for prioritization and some investment from their side as well for more efficient system and with more productivity. (CONTINUOUS IMPROVEMENT)

Can the Customer say now that we are fixing the tickets without Interest on Customer ?

Know your Business Problem: Define Problem Statement

One day, I got an urgent call from my fellow leader Anil rathod that there is a serious escalation from the Customer and needed some help. I immediately went to his work place to understand the situation.

"Khaderao, I need as many technical people as possible from your team for the next 6-8 weeks. Please .. I cant fund them as the project is already overrun but I need your help"

I replied "I will try my best, but can I understand the issue and reason for escalation?"

"We need to load 4000 Sales order lines in to the Customer's ERP. They need this to be completed by this week or next"

"Oh, I heard this Cutomer went live recently. Why this escalation?"

"The customer went live 2 months ago. But they didnt enter any Sales orders and continued in their legacy system. Now they realized that they needed all these lines in ERP"

"If that is the case, why is the escalation?"

"Our team told that this can be done only in 4 weeks and asked for a Change request"

"Hmm"

"Customer says no one guided them and informed that Sales orders needed to be entered in ERP"

"Interesting. Once went live, all transactions must be in ERP unless there was a different plan"

"True. But he says no one informed them on the same"

"OK. Now what is the plan"

"I have a very meticulous plan and I am sure we can get there. But I need about 20-25 technical people to execute the plan"

"Why cant the customer wait for 4 weeks if thats what it takes?"

"One second. Let me check."

Anil called the Onsite Project Manager and after a couple of minutes, he said "the Customer needs these lines to be in the ERP before end of Financial Year to show the accounts receivables.... Otherwise his true budget will not be reflected and he will not get sufficient funds for next year"

"How much is the amount approximately"

Anil called his PM again.

"4.85 Billion Dollars"

"Oh." (Now I understand the business Problem)

"OK Anil, can we meet your team?"

On the way to his team working place, I called my technical people to reach there.

When I went there it was a great scene.

Sikhandi was talking to about 15 people.

"Pani, you take the first 100 lines, Veena take 101 to 200. Charles you 201 to 300..... And all of you will be working here till we are finished. I will arrange food and bed for all of you. Ibrahim, you need work with overlaps and keep updating the Onsite team..."

Sikhandi's face was glowing with excitement about the kind of meticulous plan he is going to execute.

In a span of 1 hour Customer made 2,3 calls to know what is the progress. Entire team is full of pressure . But Sikhandi is quite excited to do this.

In the mean time Sikhandi prepared a Dashboard to show how many lines are completed, in progress and yet to be migrated. He generated some charts as well to show the same report in colors and figures.

While Sikhandi's speech was going on, I went to the team lead kind of person and asked her to let me have a look at the list of lines to be migrated to ERP.

I asked her to sort the list in descending order of Line amounts. I generated a Pareto chart to check the lines that cover 80% of the revenue. It needed about 850 lines which are actually amounting to close to 4 Billions.

I waited till Sikhandi completed the speech.

"Anil, please take these 850 lines and distribute to the teams. Let this round be completed with full focus. and there cant be any errors or iterations and they all must work fine once migrated to ERP"

The team got the redistributed list. I told them to take the same time as planned earlier for 4000 lines but do the migration perfectly.

In the mean time customer made a few more calls. I kept the phone disconnected.

By evening the 850 lines were completed and tested.

I asked Sikhandi to provide the Update. Sikhandi was not happy. He however fed the report. Now the graphs show 850 lines completed with % of work completed and so on.

I tweaked a few things and modified the graphs to show how much revenue is covered instead of lines migrated.

Sikhandi was not happy. "We have been sending the progress in terms of lines. I prepared a great dashboard. Now you are sending something else"

I said "Sikhandi, I am not competing with you. For that matter no leader needs to compete with his own team. You are going to send this email with this progress. In the body of message please clearly mention that you covered 80% of the revenue amount to reflect in the ERP."

Sikhandi is a bit relieved. The email was sent. Anil called the customer and updated the same.

"Now you wont get any more calls from the Customer. Please continue the work and complete the rest of the lines in the order that is prepared by Sikhandi (???). "

"Also please ensure ! the Customer should now enter the sales only in ERP. No more lines in the Legacy system please.... "

***

This may conclude that

•  Understand the Problem Statement instead jumping to Solutions
• The key is to identify what is really impacting the stakeholder from the Problem
• Work for sufficient time to understand and plan the right task in place of jumping to tasks with no plan
• The Focus must be on the final outcome
• Every time lining up bunch of people may not work if the plan is missing