“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.
That’s an inoueigns way of thinking about it.
Thank you, Shirl 🙂