[Music] okay hello friends and nikhil is again with us friends you might be surprised by seeing the thumbnail of this video because the last time we have done a one session with nikhil on scrum master interview question and kind of session which we have done with nikhil and this time we are doing business analyst interview with nikhil so friends uh nikhil has we had a lot of different uh caps in his career business analyst master project manager and this interview with hsbc i think he's given five to six months back and we are just having
a conversation and then this thing came up and then i told him to let's shoot one more session on business analyst because we are getting lot of requests on business analyst as well and nikhil agreed on that so thank you nikhil and welcome one more time nikhil on our channel and yeah glad you are here again one more time yes and then thank you for the opportunity again you know uh i can't find words thank you the work that you're doing yes friends if you've not seen that video scrum master i think that was a
fabulous uh session which you have done with nikhil with deloitte and i think uh that session already hit i think eight to nine thousand views by now i think so that's good nikhil and uh let's start with this session now without uh taking more time shall we yeah yes yes we can okay thank you okay so uh what is your role in responsibility as a business analyst so that was the first question rules and responsibility as a business analyst you know um as a business analyst i have comprehensive experience in requirements gathering and analysis creating
context and technical documents project management techniques testing and deployment areas of the project i have strengths or on you can say knowledge in finance banking insurance and investment banking domains one of my recent projects with the compass bank as a business analyst the project aimed at integrating and customizing the cio system for the bank [Music] i was responsible for designing analyzing and writing all the specifications and business requirements for this project i was also responsible for managing back-end system as well as piloting other sub-models of this project my key responsibilities included conducting meetings jazz sessions
with stakeholders analyzing and documenting requirements in terms of a solution that means we come up with i was involved in creating a business requirement document documents wireframes mockups uml diagrams test cases user acceptance testing plans as part of the document deliverables for this project i used different business and software applications such as you know ms word microsoft excel visio mspgo sharepoint access sql i was involved in all the major phases of the system development right from initiation and redeployment i closely work with fellow business analysts project managers quality analysts throughout my role as a business
analyst i also have experience in business square my elicitation and analysis and uh you know technical documentations your uat managing change requests as part of the post go live support for the fund again at the same time i have i also have extensive experience in creating solutions to complex business problems through process analysis and design process re-engineering process automation [Music] i have experience in conducting workshops facilitating workshops and sessions with you know which now also have helped me now that i'm working as a scum master sessions with the subject matter experts for product integration upgrades
or enhancement that need to be done continuous improvement initiatives using linseed six sigma and uml toolkit i also have in-depth understanding of the complete software development lifecycle and end-to-end project delivery process in various environments including you know waterfall agile scrum lean xp okay okay thanks a lot nikhil for your detailed explanation about role and responsibility great okay so uh tell me like what exactly the business analyst is going to solve so what problem you are going to solve as a business analyst can you just share one or two examples with that yes see as a
business analyst you could say is a bridge between the client and the itt so a business analyst solves multiple business and stakeholder problems starting from identifying the requirements analyzing those requirements designing and implementing uh you know have some kind of implementation done that suffices what stakeholders are requesting business analyst solves the business clients or problems or defines solutions in terms of requirements and provides a functional solution uh to the itt which is you know easier for them to grasp uh business analysts again is also responsible for managing change requests throughout the project say in an
agile frame agile or scrum framework you know if uh change requirements uh are you know are in increased often so you know the role of a ba is i mean you can't really compare different methodologies but you know the way you go about the handling those change requirements in a certain methodology is different again business analyst is responsible for creating scenarios or narratives and there are various business strategies and processes for successful implementation of the project business analyst uh also micromanages the project deliverables and manages uh the team which eventually leads to a project success
so i could an example could be you know one of the projects that i worked on uh the client uh was requesting uh sorry you know i have a kitty that's uh playing with me right now anyway at the bottom so i'm kind of distracted but um yeah it was a loan management system that the client wanted the changes done to the existing loan management uh system that they had for the bank uh so i had to you know do an analysis of how the current loan management system was working and then what need you
know what stakeholders wanted to implement it uh so i had gathered the requirements analyze those created wireframes and mockups for the team so it's and uh so the requirements to them are easily uh visible or you know you could say and make him understand better of what needs to be achieved as a team and what are the different uh documents our business analysts prepare normally uh see the documents if it's waterfall uh like in a waterfall methodology or you have a business requirement document uh uh so it's brd srd and frd brd is a business
requirement document intended to provide a high level business and stakeholder requirements is generally created by the business business analyst during the initiation phase of a project whereas software uh requirement specifications uh which is srs is intended to provide a detailed log of functional and non-functional requirements the company with use cases uh and can be developed uh by either the business analyst or you know i mean business service or if there's a role specific to if you know the client or the one who has the requirements if they have somebody who can provide us that document
it can be worked on by them uh again an srs document is usually worked upon during the planning phase a functional requirement specifications alternately also called as a functional requirement document fid is created with the comprehensively taking into consideration the provided the functional requirements to the end user uh it is often accompanied by uml diagrams including data flows entity relationship diagrams or you know activity or how the flow works usually an implementation uh can lead to you know uh i mean va works with the developers and then ba is the one seeing the documents uh
see this is the one who works on these documents again uh brd can be prepared even when a ba may only have access to high level project requirements however an srs or an frd can only be prepared uh when low level uh solution requirements have been fleshed out um in an agile environment uh we usually if it's come we you know uh a business analyst you know he works on user stories and acceptance criteria with the product owner there's not a lot of documentation emphasis on you know in an agile framework but again uh to
be a you know would work on uh user stories or features and also have you know provide wireframes or mockups you have the team uh understand those requirements better okay sorry i get confused now with the i'm the scum master and ba so i was just you know pardon me if i go uh talking about uh so you can stop me there if i do that that's okay that's okay okay so uh nikhil uh do you know about this jade joint application development or design sometimes it's called yes uh jd stands for joint application development
or design again gad is requirement design and software development methodology in which uh stakeholders or subject matter experts uh the end users software architects uh and the project team attend these meetings to get an outline uh of say a system's high level scope or requirements a jazz session focuses on business problems rather than technical details a harmonized group synergy effective leadership and excellent coordination skills of the facilitator are you know key for a successful jazz system the purpose of that session is to bring together the itn business community in a structured way uh in a
structured workshop setting in order to accept a high level system scope requirements uh giant sessions are usually connected during uh the initiation phase of uh a project however they can uh be held on a regular basis in if the stakeholders and you know if there's a need can they can be heard in the key participants uh in the jed session include the project managers business and stakeholders the development team you know the stakeholders that are concerned or have interest in in the project generally jet sessions are laid by a project manager accompanied by a business
analyst although business analysts can also facilitate jet sessions on an ongoing basis depending on the availability and how again session leverages uh group dynamics extensive use of visual aids documentation prototypes and organized process designed to gather and define departments in a short shorter time frame again jad also reduces the amount of time needed to gather requirements shortening in the overall development or you know the duration of gabriel in uh effective jazz station could get a lot of requirements uh and you know i mean then business analyst job to get those requirements and get them you
know we check with the stakeholders if there's a need as to what needs to be done okay thank you nikhil okay so thanks nickel for that and would you like to tell us about the different requirement gathering technique which we have used so far in the past yes uh in my experience uh multiple requirement uh gathering techniques can be used uh in a single workshop session together requirements uh from stakeholders uh we just spoke about uh jack jack sessions workshops that can also you know help us uh get the requirements like a lot of requirements
can be gathered in one uh one workshop uh i would like to explain interviews and brainstorming techniques that i've you know used in my you know throughout my experience interviews are the most common approach used to gather requirements this technique establishes one-on-one relation relationship between the facilitator that would be the business analyst and the stakeholders interviews can be structured or non-structured on software uh structure requirements are the ones where a business analyst prepares questions prior to the meeting in an unstructured interview session questions can be formed spontaneously depending on you know how the session goes
and so you can have a counter question based on the meeting discussion both techniques can be used simultaneously or separately in a session before conducting interview sessions i prepare the meeting agenda questions topics that need to be discussed and have a checklist of tasks that need to be accomplished in in that session i started my questions to be open-ended and close-ended uh the other technique that i want to talk about is brainstorming again brainstorming is an excellent requirement uh requirement scaling technique which promotes innovative thinking uh for a given problem in my last job i
conducted several uh brainstorming sessions with the focus on extracting uh as many stakeholder views and opinions as possible uh on any given uh scenario or requirement in this approach i aim to acquire require uh comprehensive understanding of a requirement by encouraging the stakeholders to provide uh you know a pool of ideas rather than just giving you know limiting their those ideas this technique again helps to gather multiple ideas which can later be evaluated according to the importance of the project and can be further distributed to the statements okay thanks uh nikhil for that okay so
what is your experience in conducting uat so you guys are also present during the uat phase uh user acceptance testing yes um i have remarked i mean i have remarkable experience in preparing and conducting uat sessions with the stakeholders typically uhd sessions are conducted with users prior prior to system deployment in my recent project we deployed system releases every three months and i conducted the uat sessions before each release [Music] in preparation for the uip sessions i prepared the uad plan document which mainly covers project delivery deliverables change requirement requirements management plan test cases and
test data you know once prepared i shared this document with the stakeholders prior to the meeting and so you know if there's like any clarification that needed that can be done before meeting uh and schedule a kickoff meeting when uh when it's required when an efforts are required um while in a uh t session i provide a system walkthrough and encourage stakeholders perform testing testing of the product by executing major test cases i generally offer relevant test data or training manuals that they can use to support the testing the ultimate objective of this activity is
to get the approval of the stakeholders on you know this session with your user acceptance testing change requires derived from the sessions are analyzed carefully within projecting with the project thing and i usually conduct a follow-up session to resolve if there are any issues that come up during the session with the stakeholders hey thanks uh nikhil for that okay and uh what about business case can you just share like what is business case and what is your experience in creating one sure yes a business case uh in is a proposal document created by the project
team to convince the decision makers of the project or the project sponsors to approve the project or give us the funding necessary to open a well-crafted business case explores all feasible approaches to a given problem and allows business owners to select the option that uh you know tends to what the ideal uh organization case offers uh strategic solutions and benefits for the proposed problems uh that you know [Music] team might be facing it contains the problem statement objective uh also the proposed solutions uh and analysis of uh where you know i've used techniques like swat
market pest risk um thank you for uh cost benefit uh finance uh etcetera can i'm professional in creating i have experience in creating a business case document both for my new project or change management activities or initiatives that can be taken in my last role i was part of a project team that created a business case document during our project initiation phase i was the lead business analyst responsible for conducting the market and financial analysis for this particular business case document okay okay thanks thinking and uh what are the different ways by which you identify
your risk or how you manage your risk in your project uh nikhil yes uh again risk management is one of the most important aspects of business analysis it is uh you could say it is one of the core responsibilities that a business analyst is expected to perform throughout you know the project life cycle um overhanging requirements uh hybrid approach to software development or scope creep or wake requirements can all lead to you know requirement risk and the project can you know get detailed so business analysts handle such risk by maintaining risk registering a risk register
includes a risk id risk details the consequences that uh you know that might have the impact it might have on the project priority of that uh or you know even the probability or the risk you know some kind of risk level or risk modification plan and also in the information of the risk owner something like that that uh can be handled by uh or is handled by the va i believe a competent business analyst performs risk analysis by identifying areas that may adversely affect the solution by understanding their impact community communicating those consequences to the
people or that need to be i mean communicate to the concerned authorities or persons and developing a risk mitigation plan for that for the management it is recommended to communicate new risks or stack statuses uh on existing risk to the stakeholders which is you know something that needs to be done um i have confidently and effectively demonstrated these practices or fixed management in all my you know previous projects this approach has led me to deliver the projects successfully and manage you know risk components efficiently you know okay thank you uh nikhil for that okay so
let's move on uh the other aspect is about the stakeholder management so there are a lot of stakeholder business people within and outside your project right so uh how you deal with all those stakeholders nikhil uh so you mean uh like some kind of conflict uh that i had uh encountered with stakeholders no i'm asking about how you identify that which stakeholder is important for you you do do some kind of analysis stakeholder part things like that yes yes stakeholder individuals who are part of the project team with a vested interest in the project development
the term stakeholder generally refers to clients users customers or subject matter experts um analyzing stakeholders stakeholder analysis techniques uh technique or defines how the stakeholders or stakeholder may impact the solution for a given project or be impacted by you know how they can impact by themselves business analysts carry out a stakeholder analysis to determine what the interests are uh what kind you know how their behavior is or you know what kind of level of involved involvement they have in the project again stakeholder analysis can also be used to identify potential project risks in early stage
you know of the project project development i have used different types of race stakeholder analysis techniques including stakeholder matrix uh the ac matrix which is uh you know identify them in one who is responsible uh someone who's accountable uh someone who can be consulted or someone who needs to be informed again power to interest ratio is also one of the techniques that i have used but usually in a racy matrix is most widely used uh stakeholder analysis technique which correlates to the relations with predefined project deliveries uh again like i spoke about a power to
interest or it's also known as uh influence green is another stakeholder analysis technique that classifies stakeholders stakeholders power and interest in a given project um it is represented in four quadrants uh and each quadrant denotes uh power versus the uh the interest ratio uh so for example uh high power high interest uh high power low interest low power high interest or you have low power low interest so each stakeholder or stakeholders or position is added to each of the quadrants as per the uh the pi distribution in in the organization so you know these are
the techniques that i've used okay thanks uh nikhil for that and you just talk about uh conflicts right uh within the team and outside so what is your take on that let's say for some of your business uh you know want to do something which is not in line with what is your thought process or if there can't be any kind of conflict right within your within inside or outside your team so how you manage your all those kind of conflicts nikki um i would like to talk about my recent project where i had to
deal with the conflicting views of stakeholders during the requirements gathering workshop uh our workshop was intended to finalize the requirements related to various roles associated with the staff management model of the project the subject matter experts and technical stakeholders had uh you know dissenting views of the domain and how the project uh the functionality for the product um and their uh request was accommodated uh uh was to accommodate uh ten generic rules in order to manage various hierarchies in the organization furthermore these roles were not defined by the domain group which led to the technical
team to question the implementation of such an incomplete information that was brought up um i use my analytic i use my analytical and problem solving skills to evaluate the entire situation and decided to gather information separately from these groups [Music] for the moment or temporarily at that time this approach allowed me to focus on both groups uh what they were thinking what the rationale was from differing you know the requirements using my technical skills i created the wireframes to demonstrate the system design based on further discussion with the group i suggested uh four master roles
uh one for an advisor one for uh supervisor one for the manager and an additional role for you know access this this additional role uh met the domain group's need for having the flexibility to create uh multiple roles within the system as in when required um both the groups accepted the solution and we were able to proceed the you know with only uh with these well-refined uh requirements this again uh this solution also allowed the technical team to easily incorporate uh with the back-end system uh design by channeling effective stakeholder management and communicating uh you
know communication communicating with them i wasn't i was able to identify the right business requirements and resolve the conflict uh and create an uh workable environment uh from all my past experience i can conclude that conflicts are in you know are bound to happen in any project but it is their thoughtful management that can harmonize relationships without you know risking the timely implementation of you know what needs to be achieved okay okay thank you nikhil for that okay and uh if you could just uh tell us uh or if you can describe any time in
the past if you have introduced any new idea or process to your project and how that particular idea has improved your project situation so that will be great if you can just share some of your real life examples yes yes certainly arsenal um i'd like to talk about uh um from while i was working uh at hibernian national bank i was a lead ba on a cots project uh quartz uh is commercial off the shelf or commercially available off the shelf project uh implementation that was needed to be done um as under my business process
management perspective the first and foremost issue at hand uh was to standardize and streamline many similar similarly aimed processes into something which reduces you know dependencies or further defines the process [Music] i started the project by inheriting many such redundant and time-consuming processes as it had been a few years since any business process re-engineering had been done in the organization i initiated a discussion with the key internal partners and drew people's attention to features that required updates uh i formed a mid-sized team of eight participants and created a gap analysis document for it i geared
the review approach on items that had the most important you know most impact on courts software uh implementation and gradually worked my way through areas that had less impact on it again uh regular process review meetings offered members a chance to brainstorm ideas design [Music] ideas designed it i also designed at improving the current processes and [Music] have a plan to develop new processes that that need to be done by clearing uh defining roles and uses and outlining uh associated tasks it gave a way to eliminate unnecessary requirements uh a pilot launch of the new
initiative was undertaken for a six month uh six month period and adjustments were made to fine uh you know ongoing review and monitoring the activities that uh you know on a regular basis um i i'm confident to say that the organization truly benefited from you know this approach and i was credited uh to be a significant reason for the success of this project so that's something that you know i could say was something that i brought up and was able to improve the situation at hand okay okay thank you nikhil okay okay so as a
business analyst how you guys handle failure if any and if you want to share anything with respect to failure and how you come up strongly on that um see i consider even a small issue in a project like not meeting the client's requirement on time as a failure i like to be professional and proactive in terms of my work commitments regardless of the methodologies of processes having that are being followed this this strategy allows me to stay on top of my tasks and also strike balance between the project scope and the timeline without getting failures
affect my performance for a long time in my last project uh we had missed the implementation day by uh say a few days which was mainly actually you know was attributed to unexpected personal issues faced by two of my key members in my team i was the business analyst uh you know as a business analyst i didn't foresee such situation that would you know have adverse consequences on the project or the delivery of the project as anyone going through a tough time may do the performance of the team members started deteriorating my mistake being i
failed to flag the situation to the senior management uh early on and have a plan to mitigate that nevertheless uh as we missed one scheduled date after that i was quick to it [Music] quick enough to realize where we had gone wrong and asked for additional resources looking back i can say really finding the scope and asking for the timely help were my two biggest you know learnings i take pride in knowing that a calm and composed head and determination uh to strike by uh to strike back with improved uh zeal uh you know can
handle failure and you know so that's you know that's one of the ways that you could handle failure uh as a business and not you know not make it a habit okay okay again okay and if i ask what is your one greatest strength and one gauge's weakness while working as a ba all these years uh i've sharpened my analytical thinking or problem solving along with the competent business and you know analyst skills i've also developed project management skills including time and resource management this has allowed me to you know manage project deliverables even under
tight timelines and limited resources [Music] i thrive on new challenges and look for avenue to gain as much knowledge as i can i thoroughly enjoy reading business articles and connecting with industry experts to gain you know their insights i have you know domain specific expertise in areas of banking retail insurance you know and along with technical skills you could say you know this you know these or this would be my strengths and as far as weakness uh you could say sometimes i spend more than you know more time that than that's necessary on a single
task or take on tasks personally that could easily be assigned to someone else although i strive not to miss a deadline it is all you know it is still an effort for me to know uh when to move on to the next task uh to overcome this i've started assigning uh priorities to my tasks and organize uh project deliverables accordingly um then at times i struggle with delegating tasks team members due to trust and performance reason uh that they might you know they may not be able to accomplish the tasks uh within the given time
frame and with uh the same quality to get rid of this uh you know i have started defining milestones and deliverables uh before handling work uh you know work to anyone this up this again this approach has usually benefited me and others in my team as you know the trust and you know working relationship has improved so not much but you know okay thank you nikhil and i think we are now at end of our uh session we have covered lot of questions today and i really thank you uh you have taken your time and
explained in detail all these questions so again thank you nikhil and i hope to see you again in future in uh some more sessions you i know you are quite busy but then yes i'm not an issue we'll connect again yes sure sure okay thank you nikhil thank you once again and i hope friends you have uh learned something new from this session if yes please give a big thumbs up and yeah see you in one more session so bye everyone thank you for watching thanks