Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
deveshbohre1
Explorer

In today’s world,  everywhere there is a flood of offers running such as Buy One Get One, free holidays for coming years and so on, which is nothing but overtaking our basic requirements by their supply (kind of Force Purchase, which they call Product Promotion).

Customer is bound to buy the freebies, without knowing the fact that these freebies are not really Free of Cost.  In such cases basically customers are only looking ‘WHAT’ they are getting Free and not WHY they are getting it free or WHY they need those Freebies.

How this related to our requirement gathering? This might be the question arisen in your mind.

Let’s go back to the phase of Requirement Gathering or Requirement Validation, where we have a list of wishes from users, it’s a human nature if customer or end user is asked about their requirements, they may turned back with a huge list of wishes. Sometimes they know what is being asked or may not even knowing what actually their expectations are, but most of the time they are not knowing WHY they are asking for those specific requirements. In simple words Customers are not always good at articulating their needs, so it is important to play back your understanding of their requirements to ensure clarity.

We should always prefer to ask question against each of the requirement from the clients asking ‘WHY’ he /she is looking for such requirement, surprisingly you will find Most of the time user is not knowing the answer to ‘WHY requirement was listed down?’ there might be some work around available for those requirements or might be these requirements are not really economically beneficial to customer.

Some of the outcome I observed while asking WHYs from the user are listed below.

  • Better Utilization of Resources

Though sometimes we are instructed not to ask too many questions from client regarding the requirements raised, which is a wrong approach to any project requirement, I feel, even if it’s been asked or discussed by some other or previous team member, or in any previous requirement gathering meetings or sessions, it is always preferred to be clear on the requirements and helps to create a clear, concise and thorough requirements document, which can be shared with customer.

Asking ‘WHY’ always helps us to deliver the correct solution with less rework and less efforts and hence makes the ‘HOW’ easier.

  • Cost Saving Approach

With current industry trends, where almost everyone is adopting some cost saving measures, most of the requirements are functionally and technically valid requirements and can be delivered also, though it is also experienced that most of the requirements after getting delivered, are not in much use. This is because sometimes the requester or user raises these requirements not as a part of necessity, but due to day to day competitions within the peers, and they wanted to create or project an image to management. This organization approach sometimes leads to excess project cost involved in getting developed some of the functionalities which are not very much in use.

While Asking “WHY” during Requirement gathering, which may involve some cross functional business persons to validate the requirement, most of the time these requirements are shorted out during internal business discussions only and can help the customer to decide how beneficial this requirement would be if delivered.

  • Optimized Allocation of Budget

Some of the requirements are passed the Requirement Validation phases, as being functionally, technically and legally feasible, though Business can prioritize these requirements based on various other factors, such as the frequency or usability of the requirement.

This decision can also be taken based on the “WHYs” asked from different business users related to the requirement raised, and by asking WHAT steps/work around business is currently having? HOW this will be affecting user’s performance if been delivered, is it a globally required or only helping to enhance user’s performance of some specific geographical location. These few questions may help Customer or Business to decide WHY to validate or approve the requirement and hence HOW to get it delivered for betterment of the Business.

  • Active Involvement of Business User

By involving various cross functional/business users during the Requirement gathering and by sending questionnaires related to the raised requirements makes the users more precise to their requirements. A continuous discussions on business requirements fills gap between not only the functionality but also fills the communication and cultural gaps between teams.

This also develop a scene of importance within the users towards the new functionality to be developed for betterment of business and helps in coming phases of the deliverables such as testing the functionality or even passing the knowledge to other business users of the new functionality.

  • Helps Improving Relationship with Client

As in different phases of the project delivery our aim was not only to deliver a  functionally or technically or legally valid business solution but at the same time we are more clear on how it will be economically suitable to the customer business, this approach helps to build a relations between the customer and the services provider, where customer start considering the service provider as a business partner and not a just vendor, who is providing its day to day IT services for betterment of core business and to help achieving organizational goals more effectively and economically.

As during entire process of requirement gathering and validation basically our aim is to clarify the business requirement raised by the user, it helps to present most suitable functional and Technical design of the solution for the requirement raised. And as the delivery team is clear on WHY this requirement is raised and WHAT is expected to be delivered, helping HOW to deliver makes easier.

1 Comment
Labels in this area