So, the usual blabber like “Business analysis is the process of gathering, eliciting req”…….oh come on. we all know that, don’t we? However, had I been twitter, the question “Is the Business Analyst track right for me?” would have been a trending question by now. I mean, so many people have asked me this till date.

Before we arrive at the answer, lets play a bit with the question itself. People who wonder about the above point may belong to roughly the below categories:

  1. The really green Greenhorn – the starry eyed kid who is fresh outta college into the apparently blinding bright world of IT
  2. The Disillusioned Enlightened – Professionals having loads of experience in IT but in different disciplines like Project Management, Process and Quality, Testing, and of course, Development.
  3. The Curious ‘How about BA’ – Professionals having loads of experience in non-IT. for example Insurance, Banks, Market Research Firms and anything else.

lets take a closer look into what business analysis is all about now.

In a normal day to day life of a BA, the activities are like

  1. Understanding customer’s objectives behind this project. In other words, to understand what are the pain points that are driving them crazy and making them invest in a software?
  2. Capturing the Business Requirements.
  3. Acquiring, or if not available, then creating the AS-IS process model (Present system)
  4. Understanding customers’ need from a functional standpoint. No, in fact from a techno-functional standpoint.
  5. Gaining a solid understanding of the above, and I mean really solid here. You must be in a position of command when it comes to requirements. This knowledge that you gain during the requirement gathering phase would be useful throughout the whole Software Development Life Cycle.
  6. Breaking down the Business requirements into User Stories (if you’re going agile way) or Use Cases (For classical way) [* If you do not know what user cases or user stories are, in a nutshell, they are the lists of *things* and steps that a user or a software should carry out in sequence, the options, the alternate choices, those stuff; get the drift? more on that coming up in my next blog though…]
  7. Documenting it – Develop a visual model of the TO-BE process. Finalize the Business Requirements, Use cases (or user stories)
  8. Driving the development from a requirement standpoint – guiding the Development and QA teams on what exactly is required – down to each field in the screen, each property under the hood.
  9. Reviewing the test cases, finding gaps in them, doing functional application review etc.

For the first set of aspirants above, the greenhorns, BA might not be the right way to start the career.

The reason: As you can see from point 1 under requirement analysis, to completely comprehend an organization’s vision and pain points, you need to be very well versed with the corresponding domain. You can only understand why a bank is hell bent on chucking their existing KYC solution if you know how general Banking compliance and regulations work.

The above point about domain knowledge is exactly why it might make some sense for non IT business SMEs ( the third type above – people having loads of real life hands on experience in their respective industries) from other industries like Banking and Financial Services to switch over to IT business analysis. These people bring to the table a treasure trove of practical hands on wisdom on how to solve a business problem using their years of experience; add to that the magic of IT and automation, and you have a perfect recipe for a successful software solution). There is, however, point 4 that they would need to work upon. In IT there is a certain angle in which you need to need to observe each requirement. That angle is determined by the tool or technology that you or your customers choose, to implement the solution. The way you envision a tool based solution is somewhat different than a vanilla technology based solution. More on that on my later blogs, I promise.

Coming over to the folks in IT industry, who had been working for years in other disciplines of IT than BA ( example: Senior developers having years of experience in design, coding, testing, delivery, etc), well, you need to take a difficult decision here. You have a wealth of expertise in the field that you had been working on. Are you sure you wish to let go of that and shift over to a new work profile? Please don’t take the statement in a negative way – The intent here is to help you evaluate the pros and cons and to take an informed decision. Coding and delivering and Business analysis are two things that are poles apart. Each has its own magic (ask me, I have done it all and enjoyed both immensely!) . If you fall into the above bracket, and finally wish to give Business Analysis a try, you might actually find yourself in an advantageous position after you join BA track. Your technical prowess, combined with your application oriented business knowledge would spell wonders in project and render the Midas touch to the requirement documents. You will have already developed the high level design in your mind while doing the use cases and wire frames. You will tend to align your business analysis in a way that is technically achievable, coz’ you have that secret superpower, your technical knowledge. Trust me.The developer team would love you for that!

Now, revisiting our original question “Is the BA track right for me”, the answer depends on whether you have the right skills and/or whether you would like to develop those skills and jump right in. If you think you would enjoy seeing yourself entrusted with the above set of jobs and more, then Congrats! BA Track is the way to go for you!

Please feed me back with your comments, response, abuse, whatever! Hope to hear back from you! Till the next time, happy reading! 🙂