Supporting customers in Odd hours

Giving a title to this subject was indeed a tough job because I was doing more of a reflective thinking. One of my colleague told me that, customer wake him up every day for one pre-text or other every alternative day. I told him that, i keep my phone either in silent mode or downstairs while I am sleeping. All of them were shocked. Initially they thought i do it because i do not have US customers to support. I told them, this is the fundamental principle I operate upon.

The guidelines are simple.

1. If your team is working while you are sleeping, they are expected to manage the situation. This is typically a communication we give to the team and typically we ensure that we use follow the sun model to handle all high severity issues.
   
2. If we are doing a grave yard shift, still the team is expected to handle along with shift in charge. Do not expect complete collapse everyday.
3. Anything other than above two dimensions, can wait till I wake up. The reason is that, to bring in experts and key people to have a look at the issue, would require my day time and i can do very little during my night time.

These guidelines are not applicable if we are doing a major go live and we are on hyper care support because the project is not in steady state both in terms of resource tuning and support process streamlining. Other than this, I strictly believe in the above approach.

There was a time i used to be awake by 4 AM in the morning and go through all the emails and analyze the critical issues. But still i had to wait till team is available (India business hours) to make the next steps. I could have done the same thing starting 8 AM in the morning. This is the retrospective thought.

We think that, we are the key to the success of operations, my suggestion is just change the way we and set appropriate expectations. With every change, there will be a transition period, but at the end of it, we get our life back...

Promising on Delivery Vs Delivering on Promise

About 7 years back, one of the customers gave a T Shirt with the text in the front Delivering on Promise. Since we had only one T shirt, we put it in a photo frame and displayed it (my boss's idea...) in our work area. I kept on looking at that T shirt wondering how interchanging words delivery and promise can make signficant difference in the meaning. In reality it is a continuim - You promise on delivery and deliver on promised delivery. However more often, Indian way of workings stops at Promising on Delivery (this not a broad generalization, but my experiences over the past 8 years). The cultural difference between Western way of working against Indian way of working can be summarized with these interchanging of words.

When I returned to India 8 years back, after working for close to 6 years outside India, promising on delivery was my biggest challenge. Whenever we discussed on delivery dates on deliverables, team used to promise specific dates. Once the discussion is over, many a times, i used check on the delivery date whether work is completed or not. More often than not, i was in for a surprise , on the promised delivery date, delivery does not happen.

When I used to check with the team, typically i used to get three responses

1. Almost complete and will give in next couple of hours - interprete - i started working and the deliverable is close to 50% completion and will finish other part in next couple of hours or so. The good news here is that, there is no unexpected surprises from technical stand point
2. I will give tomorrow - interprete - Oh my god.. i forgot about this, i will work on this today and tomorrow and hopefully it will complete tomorrow subject to not finding any additional technical interruptions - You as a manager in a bad shape here for sure
3. Since you did not come back to me, i thought it is not important and hence did not work on this issue - interprete - You as a manager expected to do follow up to show the importance, you did not do your job and hence i did not do mine. At least i consider this as honest answer because you are certain that, nothing has been done.

A few such hiccups later, slowly adjusted to Indian way of working, and put together a process around follow up for Promising on delivery. More than follow up i started looking deeper into the deliverables to see whether there is any technical or process constraint that may come up in terms of delivery. Over a period of time, i built my own rules on follow up.

1. Follow ups are not done on weekly meetings, but daily routine checks with the team members to see how things are progressing. I realized the importance in this model, because meetings are only to discuss risks and issues and not for follow ups
2. Be sensitive to different styles of working. You will find a few team members do not like follow ups because they deliver on promise. Need to identify them and have a slightly different approach. Otherwise, they feel you are micro managing and it will have further negative impact.
3. Never pull up the team members in public or in meetings on failed deliveries. No one is happy for missing a deadline or delivery date. How you handle the situation would pave the way for future. From that perspective, i usually the support the team member to get back on track and work together with them.

Using this follow up approach as well as mentoring and coaching, over a period of time, the team moves from Promising on delivery to Promising on delivery and delivering on promised delivery. You as a manager need to see this transition and adapt slowly to a new way of working. In fact, suddenly you may find a lot of time in your hands and you need to find ways to fill them up. This is a welcome change and I am always happy when the team moves to a autopilot delivery mode.

How did i fare in a challenging situation

I am playing the role of project manager for close to 8 years and have definitely faced a lot of challenging situations in my career. Somewhere down the line i got into the feeling that i have figured it out all and am able to handle any situation. Surprisingly, i found myself in a strange situation and was very close to having a break down two months back.

As a manager and leader, i was managing a project. This project had a strange clause of warranty support for six months. In other words, if there is any issue is there in their production environment because of either standard product issue or enhancements we developed, we were required to support and resolve the issue.

When we started on the warranty support, we had a fairy tale relationship. We (two members from customer and myself) used call ourselves as three Musketeers . It continued that way for a while till real problems started hitting in production environment (there are multiple reasons and am not getting into details).

The fairy tale started becoming complex, because in addition to this, they were also bringing in gaps in implementation (not found during testing) and expecting us to cover them as well. Here i was handling all these combination of issues and fighting with customer almost everyday to say NO to the issues or correct the solution accordingly. Saying YES and correcting the solution was easy to handle, but saying NO started creating stress internally. We need to be tactful, polite and logical while saying NO. This combination started taking a lot of energy from me internally.

I probably never said so many times NO to a customer in such short duration. Please remember the problem for customer is real . We are saying NO from the perspective of my organization scope. There were times they were questioning professional ethics and organization delivery quality. Also at times, the calls were very aggressive to the extent of being irrational.

So here i go, identified the root cause of my near nervous break down. Unfortunately this did not absolve my accountability and commitments to the organization. I still have to find a way out to control the situation instead of situation controlling me. As the time for the warranty period closure reached i started approaching the issues using the following guidelines and framework.

1. Stop saying NO, but take your time and do the analysis and provide appropriate answer (it could be NO in the end).
   
2. Start realizing that there is an end to every problem and just stay together till the problem dies its natural death.
3. Start looking around you and see that every one has one problem or other and just accept them and deal the best way you can
4. Do not take anything personal, if we cannot fix it, state the same and if we can do it, just do it (the nike way)
   

Besides these four principles, i got great support from friends and family in this period and that allowed me to pull through this tough period. I realized their value at times of crisis. During Christmas holidays, i just left my laptop at home and took off on my vehicle to South India tour. Somehow i landed up visiting so many temples in those four days, i could never imagine. Believe me it was not planned that way, but it really helped to get over some parts of my stress. Then my brother came over to visit me, and this also helped a lot.

One lesson i learned in the process never believe that you faced every possible scenario. There is something new waiting in the corner and how you survive that one, determines your success. In the above case, i still do not know how well i fared part, but i can say this much... I survived...

If not, images like the one on this article.. will ensure that..we survive....

Expectations and Reality

I remember beginning this article at least a week back and promising myself that, i shall finish it that day... that was expectation and here i am still trying to complete is reality. This gives a glimpse towards the gap between expectation (s) and reality. Many a times, we often find ourselves in a situation like this, though we do not admit immediately. Let me walk through you a few examples in my career to highlight this gap more often...

How often you walked into performance appraisal discussion in your compay on the assumption that you have done really great and you be rated as star performer. During the discussions you get the reality that your are an average performer. Then you start breaking your head on what did you do wrong. The fact is that, you have done nothing wrong, but there are others who have done things differently and better than you.

This is probably the same race you have been through from school days. I remember one of my friend stating that, till 10th she was very best and she did even get a rank at state level, then when she joined +12 in a large city where 90% + is common, she became a commoner. This happens more often with large corporations where only the best get an entry into the organization and when the very best are compared.. you know the story.

Let me give another perspective, in a recent conversation with a customer (we almost finished implementing the solution), the customer was mentioning that, during initial discussions with the implementation partner, the partner mentioned that everything is possible. I was mentioning to them that if a there is a generic question, most likely i would have given the same answer. Only when we start understanding real expectations of the customer during implementation phase, reality strikes in. Again a gap between expectation and reality. In this situation, both the parties have to work a way towards solution and probably evaluation process should be more aligned to reality than high level queries.

In another case, we demonstrated a template to customer stating that, template covers best practices and processes. The customer expectation was that, the template is up to date with latest releases and processes. The reality is, it covers only important processes, and not all the new processes. Here again, now we start managing the gap in a painful way.

In one of the outsourcing engagements i was engaged in (2003), the expectation from the customer was that we bring in the right set of people and in three months transition of the knowledge happens and then a simple switch on and off (from resource perspective). The reality was, it took more than 6 months to stabilize and in one of the process areas it took close 12 months. Half of my time was spent on managing this gap than actual any productive work.

Long back in one of the SAP implementations, there was an expectation that the employee cost data to be moved to projects to do actual tracking. While during the proposal phase this looked simple, there will be data at employee level and this can be moved as standard feature. At the time of implementation, we realized the expectation was to do actual cost to the penny level. The customer is not implementing payroll, however we promised during the proposal, and for the rest of the project we were building semi payroll module to get to the actual cost as much as possible.

In all the above incidents, common thread is that the stakeholders are not aligned or they talk two different (business) languages. Unless both the parties work towards bridging this gap early in the cycle, this gap between expectation and reality will not go away. Many a times, this may become a show stopper along the way.

In many ways, expectations are like assumptions, the other party does not even have the opportunity to validate. It is like a perception in people mind that comes out only when reality strikes in. One or probably the only way we can minimize this gap is by being transparent and straight in our interactions with people.

On parting note, many occasions we are left to manage with the expectations set by others. If we are transparent and handle issues directly with honesty and integrity, we might be able to succeed more often than you can imagine.