In most of the software projects that I had worked with, the requirements are not captured and analyzed properly. This is one of the main reasons for the many problems that are being faced in the project. The requirements are written in an ambiguous manner and without analysis or application of mind and in most of the cases, the User Requirements Document seems to be a Vomit of the Customer (instead of Voice of the Customer). This is primarily because of the lack of understanding and analysis of the so called Business Analysts (BA); the BA’s emerge as Business Analysts by accident and not by intend.
The Wikipedia definition of Business Analyst (BA) is “A Business Analyst (BA) is responsible for analyzing the business needs of their clients and stakeholders to help identify business problems and propose solutions. Within the systems development life cycle domain, the BA typically performs a liaison function between the business side of an enterprise and the information technology department or external service providers.”
The BA should help the customer in identifying business problems that they have in their day today operations and propose solution so as to incorporate in the software application that is being built. To do this the BA should have a thorough knowledge of the customer’s business. Is it possible to have a thorough knowledge of the customer’s business? The answer is NO. Customer definitely knows his business better and much more than a BA would. Then, what is the value addition the BA can bring in to the table. The BA by his analytical skills should be able to point out the problems (or pain areas) and suggest alternate solutions(s) to solve these problems. The BA should be able to suggest innovative ideas in solving and sorting out the problems. For this the BA should have a good background about the industry in which the customer is in as well as draw an analogy to other industries as well. The BA should have a decent amount of technical expertise, he should be conversant with the usage of UML (Unified Modeling Language) with respect to Use Case Diagrams, Sequence Diagrams, Activity Diagrams etc., The BA should also be able to do a feasibility mapping of the requirements with the tools and technology that is being used to build the software application. These would help in better and uniform communication among the various stake holders, thereby BA performing a liaison function between the business side of an enterprise and the information technology department or external service providers.
The above qualities are clearly lacking with many of our BA’s and they really become Back Ache’s rather than Business Analysts in the project value chain.
2 comments:
Good One.
BA's are not born They are made BA's. For them to be a good BA a Guide, Mentor and Leader like you is required to bring them in the right place and make them understand their role.
Post a Comment