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:
- The really green Greenhorn – the starry eyed kid who is fresh outta college into the apparently blinding bright world of IT
- 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.
- 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
- 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?
- Capturing the Business Requirements.
- Acquiring, or if not available, then creating the AS-IS process model (Present system)
- Understanding customers’ need from a functional standpoint. No, in fact from a techno-functional standpoint.
- 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.
- 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…]
- Documenting it – Develop a visual model of the TO-BE process. Finalize the Business Requirements, Use cases (or user stories)
- 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.
- 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! 🙂
Nice read and very informative too! You just saved me hours of Google-ing on a subject that is well saught after, but not that well comprehended!
Just got a question here.. You have mentioned that having prior development experience is a boon. But won’t it probably narrow down the spectrum of thought? I mean if I am a developer entrusted with envisioning a business solution, wont I be biased towards my technology and what can be achieved by that, rather than looking for what should be optimum for the business?
LikeLike
Nice read and very informative too! You just saved me hours of google-ing on a subject quite saught after, but not that lucidly explained!
Just a question that’s bugging me…
You have opined that having prior development experience helps.. But wont that make a person biased towards his technology and what can be achieved using that rather than looking for the most optimum solution to a business problem? I mean, to the development team that is of course good news, but how fair is it to the business?
LikeLiked by 1 person
That’s a great question Tamoghna! So, two aspects to it, as I have experienced. Let me explain.
Firstly, I agree partially with you on the point, since a developer who has only programmed in a certain tool and has been involved in coding only, will almost certainly be inclined to envision his solution such that it is aligned to the features offered by that tool. Now, if this guy becomes a BA going forward, his expertise will add an edge to the target solution only if it matches with the technology he knows. Thus, I strongly recommend that you should have had worked on multiple technologies for several years before jumping over to the BA trade,
-Which brings me to my second point – the definition for type 2 people (having loads of IT experience) would generally mean that these are people who have invested years in software development life cycle. That would encompass not just coding, but also enterprise application architecture design, enterprise class design etc. she/he must have participated in enterprise planning and design, things that are essentially technology agnostic. For example: for someone who has worked for years in Java/ J2EE and knows how to design the class structure, designing a solution for other technologies or tools will be a a cake walk. Of course, there will be a learning phase where she/he would need to acclimatize herself/himself with the nuances of the new technology and mentally map it to his knowledge base.
So, in other words, yes, in order to truly unleash the power of a software solution, you need to be not only technically sound and adept at analyzing the functional objectives, but also think in a technology agnostic way while deciphering the requirements (which has got nothing to do with technology as such). After that, you must be able to map these requirements to the technical components offered by your tool of choice.
Please let me know if that makes sense 🙂 would love to hear from you!
LikeLiked by 1 person
very well documented ….. and strong points mentioned without questioning the integrity of a developer and a ba ….well decisions are always difficult to take ….so are risks but then business analyst always have found a way to tackle dicey situations and risk management ….:)
LikeLike
Very true. In my limited experience, I like to think of putting the BA skill sets into 3 separate baskets.
1. Soft skills: Primary tool in the BA armoury, much of the tasks revolve around being an effective communicator. The importance of people skills cannot be stressed enough.
2. Problem Solving skills: This is where technical people already have an edge in that structured thinking is inherent to design/ coding. It is important that as a BA, I connect the dots, not necessarily in a relational way but atleast algorithmically so as to lend a defined business logic, while collecting requirements.
3. Domain knowledge: Without being firmly grounded in the industry’s practices, it is really not possible to see where a requirement is coming from. As you so adeptly put it, this is where the ‘treasure trove’ of reading implicit requirements lies.
Looking forward to your future posts!
LikeLike
Couldn’t agree more to what you said, Gaurav! Yes, I cannot emphasize enough on how important soft skills are for BA’s. Right from winning the customers’ confidence while getting the deal to winning their hearts while liaising with them on a day to day basis, there is no substitute for power of communication.
LikeLike
So far, quite captured by your generous idea of such blogging which helps people like us in the fraternity for reasons known/unknown, references, if not simply exchanging! Kudos!!!
Second, an admirer of language that I am, I love the knitting of words here, sticking to the contents and context (of ‘IT’) that is relatively less attractive on its own (you know what I mean!)
Will come back to peep and/or write in order we (or at least I) become more enlightened 🙂
Go Go Go! keep going!!
LikeLike
Good start Romit on a real time topic, and I am doing BA currently for my new domain in classical way and my long development experience helping me a lot formulating the cases.
Keep posted…and please share your experience with BA tools that are available in market.
LikeLike
Brilliant! BA job explained to the core! But what if the customer doesn’t know what he wants? Imagine a scenario where an organization has loads and loads of data – application logs, databases, flat files, etc. etc. and they want to find some value from within – in a sense building a Data Lake! Will the above steps still be valid in this scenario?
LikeLike