Archive | November, 2015

Apprehension of comprehension !

24 Nov

“How do we identify which tool do we need to work on?” asked a participant in a panel discussion on automation. I think same question; however, in different styles was asked at least 4-5 times. It was interesting to note that question, not because it seemed ‘great question’, but I couldn’t figure out why this question was being asked. Fundamentally, it seemed like the person who is asking this question must know the answer. Have you come across a fruit vendor asking you to buy an apple without even checking if you need an apple or an orange! So, should it not be that the tool / technology / approach /architecture / design / best practices etc be derived based on customer requirements?

I am sure most of you all (especially in IT) must’ve come across the popular cartoon strip where in the sales person has convinced customer that he will deliver a palace whereas the requirement was a simple house and finally, the customer gets delivered a hut ! How many times do we genuinely try to even understand what the customer requires? It is nothing to do with automation alone. This is a question that most of the people seem to ‘presume’ that they’ve understood the requirements depending on ‘their’ experience. As David Murray explains in his book ‘Plan B’, we are taught to look out for solutions, we are seldom taught to understand the problems in the first place. Then there are some folks, who try to thrust with IT tools that they’ve worked earlier and which ‘they’ are ‘comfortable’ with. Do they even try to understand if those tools will help the customer solve the problem? Take for example that there is a requirement to implement a helpdesk. The solution is not to sell BMC Remedy or OTRS or ServiceNow just because they are used widely or that one is familiar with. One needs to first understand the needs, budget, environment and long term aspects of the customer. Often, it is either IT driven (traditional approach) or business driven (so called, agile approach). If there is no value addition to the customer by implementing (either the feature or the entire system), let’s not do it.

We’ve come across some set of customers who really understand and are crystal clear on the requirements. Most importantly, they would’ve already derived benefits of getting the system implemented. I must admit that even as practitioners, we’ve learned from such implementations and realized how such things help add value. There are many customers who would seldom be clear on requirements. It is not surprising to us anymore that they take more than several weeks to even answer the queries that we would’ve asked them for seeking clarity on the requirements that they had defined! Our first exercise when we get customer requirements is to review it carefully, comprehend and seek clarity on all requirements. The second activity (post estimating efforts) is to share what they would get as a part of deliverables or post implementation. We tend to take them through the exercise, demos and discussions so that they the expected system, not surprises. Despite this, I admit that some customers tend to squeeze last drop of the oil and ask for more features to be delivered within the same timelines. However, since we now have set a practice to get most of the requirements clarified and verify that there is a value addition; we’ve enhanced our chances of successful implementations. Have you overcome ways such of your apprehensions? Share or comment, if so pls.

Do not Forgo, Go for it

20 Nov

Last week, I got 7 calls in a span of 5 minutes asking me to call back immediately as there was a Severity 1 issue raised by one of our customer’s end customer. I was in a middle of another important meeting and couldn’t respond. After my meeting, I called up to inquire what the issue was and I was asked to consider it as the highest priority and help get it resolved. Since I was not able to access my emails, I called up one of my colleagues requesting her to look into the issue and resolve accordingly. The issue had been raised for about 3 hours and nobody had bothered to even read the end customer’s mail to check what the issue was. The favorite corporate attitude ‘pass the buck’ was very evident. Since we have partnered with our customer to serve some of their end customers, they thought it is easier to put it on us and let the end customer know that experts are working on it.

Our L2 colleague hardly took less than 15 mins to identify that it was not even an issue, let alone it was raised as Severity 1 issue! The end customer had seen a screen, assumed certain things and without even getting clarified, had raised a Severity 1 issue.

I’ve seen this growing trend amongst few to run away from the issues even before trying to understand them. Most of them seem to have a feeling that they would be considered below par if the issue does not get resolved by them. I think that since such people keep running away from every such situation, they do not learn and tend to remain below par. They find it more lucrative to identify someone who can take responsibility to resolve the issue. Guess what? That lot of ‘someone who takes the responsibility’ keeps learning and growing and the cycle continues. Here are few tips that I can share based on my experience –

  • Acknowledge that there has been an issue and that if someone has reached out to you, that means they have some hope and entrusted you to at least look into the issue.
  • Many times, the issue is usually blown up (like the above incident that I explained). Do not tend to take a stance or assume that you may not be able to resolve it even before looking into the issue.
  • Most of the times, the issue would’ve already been resolved by someone, somewhere in the world. You may have to find out those steps/solutions in case if your skills are limited.
  • There is usually a tendency to start getting into a blame game and assume that you’ve been framed, or the issue has been assigned to you intentionally. Such things seldom help to learn or resolve the issues. Get over such negative thoughts and focus on understanding the issue and identifying the solution/cause. Discuss it with your team members and I’ll not be surprised that you get the solution, almost every time.

I can summarize the above tips into one – Do not forgo, go for it.