Let us consider a simple scenario of writing code for a new application for a customer. The process starts with a clear understanding of customer business, key user’s expectations and customer management’s expectation regarding business benefits driven out of this application.
The most important journey begins with capturing all these details as minutely as possible. I always recommend not to map application with the business but map business with the application to get maximum benefits from the deal and make customer happy and satisfied.
Mostly during the requirements capturing, we start zeroing down the nearest application available with us and start moulding our requirement documents keeping in mind to sell that application to customer. That is the biggest mistake we make when we start looking at customer business framed in our existing application. Worse is when we change the direction of business discussion trying moulding it in our product way.
That itself starts leading to a big disaster. This strategy will definitely leave us with less efforts and more margins without customer knowing that we are delivering his business solution to him with an already product in place with us. But usually it will not be able to win the situation after implementation of product when the users and management starts reflecting their frustration. Even if you are paid for such project, it is not going to get you further business or reputation in the market.
On the other hand when you are capturing customer business requirements, never let any of your existing product come into your mind. Record all business requirements as if writing on a blank slate. Afterwards maybe you can find out the gap in an existing product and business requirements and thereby arriving at a conclusion of moulding this existing product with least twists or deliver him a new built product.
At the end of the day the customer should not only pay you but greet you with a smile on his face even after one year of delivery of the product.