Business Analysis Fundamentals: Full Breakdown & Transcript

[00:01] course by simply learn. If you want to build a career as a business analyst, product analyst, process analyst or even strengthen your skills in data and strategy roles, business analyst is one of the most important skills you need to

[00:13] master. But don't worry, we are going to break it down in simple and practical way so you can clearly understand how business analyst works in real world by understanding what business analyst really means. how organizations identify

[00:28] business needs, solve problems and deliver value to stakeholders. We'll also explore the role of a business analyst and how they act as a bridge between business teams and technical teams. From there we will dive into the

[00:40] international institute of business analysis seab certification frameworks and understand the Babok guide which is a foundation for all this course. You will learn about its structure, knowledge areas, tasks and techniques

[00:53] that guide business analyst practices globally. As we move ahead, we'll also cover important concepts like business analysis, planning and monitoring, stakeholder identification, requirements gathering, elitation techniques, and

[01:06] different types of projects such as predictive, adaptive, and hybrid models. governance where you'll learn how requirements are approved, prioritize,

[01:18] manage and control along with understanding change management and risk management in business analyst workflows. Finally, we'll be focusing on performance improvement. How to measure the quality of business analysis work,

[01:30] identify gaps, improve efficiency, and continuously optimize process for better project outcomes. By the end of this course, business analysis will no longer feel overwhelming. You'll have strong understanding of CBA framework, Babok

[01:44] knowledge areas, stakeholder management, governance and performance improvement, helping you move confidently towards business analysis and strategic with the course, if you're ready to take your career in data analytics and

[01:58] artificial intelligence to the next level, check out the simply professional certificate course in AI powered data analytics. This course is perfect for anyone who wants to become a job ready in data analytics, AI, and business

[02:10] intelligence while building strong hands-on skills in modern tools and technologies. You'll learn how to work with key tools and skills like SQL, Python, Excel, PowerBI, and machine learning along with cuttingedge concepts

[02:23] like AI agents, automation, and cloud. You'll also dive deep into data visualization, predictive analytics, ETL workflows, and statistic methods that are essential in today's datadriven industry. Pilate hands-on experiences

[02:36] including sales analysis, marketing campaigns, churn predictions and AIdriven business automation along with the final capstone project to showcase course, you'll earn a prestigious certificate from IIT Kpur and ICT

[02:51] Academy which can significantly boost your career and help you stand out to top employers. You'll also gain access to AI powered job assistance interview preparation and a 3-day campus immersion at IIT GPU. Check out the description

[03:05] your journey into AI powered data analytics today. Before we get started, here's a small question for you to answer. Which Babach knowledge area focus on gathering requirements and collaboration with stakeholders? Is it

[03:19] strategy analysis, elicitation and collaboration, solution evaluation or is Drop your answers in the comment section below. So let's get started. >> A person who is playing let's say intermediary role, right? A person who

[03:36] is sitting at the intersection of technology, business, different stakeholders. It's let's say if you go to a different country, right? And if you're not able to speak the language which is spoken in that country and

[03:52] people there are not able to understand your language how will you communicate and let's also assume that Google maps doesn't exist. So in case you want to travel from one place to other place you can't you can't communicate to the

[04:06] people. How will you deal with that situation? How will you survive in that condition right in that country? And that is where you if you if you if you get a translator who can translate the language local language of that country

[04:20] to your language and your language to their language. What will happen? Suddenly the the the the communication will become smooth. You will be able to challenges. You'll be able to enjoy your trip to that country. Right? So that is

[04:36] the exact role of a business analyst. You will see when you'll start working in the project and people who already who are already working they would know that business guys different stakeholders operations compliance legal

[04:49] stakeholders operations compliance legal they they may not understand the tech part right how the solution will be built how it will look like uh they might not be able to do that on the other hand typical developers may not be

[05:04] able to understand the business language right what they are asking us to build. right what they are asking us to build. What is the need for this system, right? What kind of other like legal cons considerations are going to be there? So

[05:18] developers may not be able to understand that. So the problem is same business cannot understand dev developers language, developers cannot understand business language and that is where we need a translator and that translator is

[05:31] the business analyst. And you know when I was starting my career around that I was starting my career around that time early 2000 or earlier than that the BA role was not that defined. It was not very properly defined. Mostly you would

[05:44] see that you know a person working as a a tech lead or team lead. He would talk to clients. He would document something and pass it on to de developers or a person who is sitting on site irrespective of his title whether he's a

[06:00] project manager a team lead or whatever he would engage with the customer and pass on the information to the offshore team right that is how it was done but slowly and steadily the role was defined properly people understood the need for

[06:15] properly people understood the need for this role and then when I came into this role and then when I came into picture got published The IIBA gets a lot of credit to formalizing this role of a business analyst. Okay. So this is

[06:28] a business analyst. Somebody who is a translator, who is a communicator, who is sitting who is sitting who is a mediator and who is you know sitting at that intersection where he is able to deal with different

[06:43] requirements, he able to gather the requirements etc etc. Right? It's a very requirements etc etc. Right? It's a very important role and uh obviously in today's world we'll talk about it later also but in today's world there is like

[06:58] any other role BA role is also going to get impacted by by AI and everything right so that is also we we need to take care but uh BA role is indispensable

[07:10] right it's very important role in today's context from survey PH transactions support etc. they discovered poor mobile experience.

[07:23] They collaborate with it. They define support workflow etc etc. So we'll go through all of these things one by one in different chapters like we'll learn how to create workflows. We'll learn how to create UI.

[07:36] We'll we'll learn how to create data flow diagrams etc etc. Right? But all of these things BA need to do so that it's like I am not just translating I am also

[07:48] providing you supporting documents. I'll create something which can make you understand better. Right? So it's not just that I I translated what business said and I I just write I just wrote text and pass it on to developers. If

[08:03] there is anything extra that I can do so that they can understand requirements better that all that is something I'll also do right if if I'm talking about let's say how to design a screen I'll not just talk about it verbally I'll

[08:17] create a diagram or what what we call it wireframe for that screen to make it easy right so all all of those things we'll we'll learn role of a business analyst that's what we just discussed understanding

[08:30] enterprise problems goals requirements ments analyze those needs, analyze the solution, devising strategies, facilitating a stakeholder collaboration, driving change. So all of these things we do see

[08:45] I'll also give you different examples. Don't think that every one of you will play exactly same role, right? BAS in different industries, in different projects, they play different roles. It

[08:58] depends whether you are sitting and working closer to the business or you are sitting and working closer to the tech whether you are actively participating in test cycles also whether you are part of operations

[09:11] whether you are part of a bank or any other organization. So there are so many things and on the basis of these things on the basis of combination of these things you will see different flavors of of a BA role right somebody will do

[09:25] things which are differently than other BAS right so you may u you should never different projects will play exactly same role okay

[09:37] stakeholder collaboration sometimes you may not talk to stakeholder your focus may not talk to stakeholder your focus is mostly on analysis and solutionizing right so all those var variables and variety of roles will also be there and

[09:50] I'll give you enough examples so that you can understand a BA who is who is le let's let's on the buyer side or a BA who is on the sell side somebody selling the product somebody buying the product and you will see there is a huge

[10:03] difference uh on the roles and responsibilities of those people so we'll I'll give you some detailed examples also to become a BA one should possess the following business knowledge,

[10:16] communication skills, tools, interaction skills, behavioral characteristics and analytical thinking and problem solving. Now tell me uh is there any role developer tester or a BA or anyone else project manager who doesn't need

[10:31] communication skill or who doesn't need interaction skill or who doesn't need analytical thinking problem solving or behavioralist characteristics right so everyone who is playing any role whatsoever in any corporate or in any

[10:46] company they we all need all of these characteristics right they are not characteristics right they are not something very unique to a BA Okay, agree or not? So, but why we are me talking about them for a BA?

[11:00] So, for example, what do you mean by business knowledge? Uh, even a kid who is like 8 to 10 years old kid that that person can go to the to the shop, buy a chocolate or ice

[11:12] cream and he knows that he needs to pay. He he also needs to he he knows that you know uh when he's paying he should get something in back uh something in return right so the basic transaction people who are not educated at all who has who

[11:30] schools they also know the basic transaction how to survive in this world right u so everyone is aware about that much so that is kind of knowledge much so that is kind of knowledge everyone needs to needs to have but Then

[11:45] if you are working let's say as a business analyst uh in in any of the pharmaceuticals don't you think that you need to know

[11:57] don't you think that you need to know finance better than other people who who knows who know them just to survive or just for day-to-day life so your understanding will be will be much much better you will start understand for

[12:09] better you will start understand for example I am working in banking so I know the normal transaction but on top of it now I know what is the meaning of credit in my account debit in my in my account what is the meaning of credit

[12:22] account what is the meaning of credit card right so then I have more in-depth card right so then I have more in-depth knowledge of my domain then somebody is working let's say in a particular bank let's say JP Morgan now that person

[12:34] needs to have even further even more detailed knowledge of that bank okay I I already knew credit cards but what kind of cards, JP Morgan offering, what kind of products we offer to our clients, right? So, you have even more

[12:50] understanding, granular, deeper understanding of the products of of your own company, what kind of what kind of clients they have, uh what kind of if you are part of a particular application, you are part of a

[13:04] particular project, you will have very detailed knowledge of that project, right? So, the business knowledge goes deeper in steps. Everyone would have some understanding then depending on your role depending on your industry you

[13:17] will have deeper and granular understanding and then of your product of your whatever you are working on you will have very in-depth knowledge similarly communication skills right everyone needs to have communication

[13:30] skills but why it is mentioned for BA because BA talks a lot talks a lot means not they don't talk I I didn't mean they talk nonsense but they they have to talk a lot they have to talk to you know uh stakeholders to elicit the requirements.

[13:46] They have to talk to developers and testers to explain the requirements. So there is a lot of engagement and lot of interaction. So that is why your communication skills and interaction skills are important. Also it's not

[14:02] skills are important. Also it's not always easy for uh your stakeholders to tell the problems. it. You might have noticed many times that we are feeling something but we are not able to express we are not able to tell we are not able

[14:15] we are not able to tell we are not able to you know uh speak about it and uh in the previous slide what did you see that it's important to understand problems and goals right how would you understand problem if somebody is not able to

[14:28] problem if somebody is not able to explain so that is why some like it's not just what what is being said but how it is being said the the uh you know uh what do you call it uh uh just uh so your verbal understanding and then

[14:44] non-verbal understanding right non-verb non-verbal communication also the body language the facial expression and all so that is how and and then you run a lot of meetings right you are going to run a lot of so many workshops to elicit

[15:00] the requirements uh to present the requirements to uh let's say you are doing a brainstorming coming session to find the solution of the problem and things like that. So you will have to engage people and you will have to run

[15:13] those sessions that is why interaction skills. So communication is like what you uh talk and all but interaction is more on the engagement side how to run multiple times like if you are not good with with u with this with these skills

[15:30] not even important in that meeting right so how you will make sure that people are sticking to the topic how you will make sure that you are able to get to the outcome of that meeting expected outcome of that meeting so that's where

[15:43] you need to have interaction skills behavioral characteristics then analytical thinking because you have to analyze things you have to solve problems right and tools and technology everyone needs like we

[15:56] are right now using zoom you we use teams outlook um Jira and in today's AI world we need to definitely use AI tools right there are it's not like it's it's

[16:09] no longer a choice it's it's uh enforced in different organizations even in my organization enforce that you have to use AI, you have to save time. So these are the now in this course we we will not cover communication skills,

[16:25] interaction skills, they all these all are soft skills that you need to develop not part of this particular course. Here we'll talk about business analysis, right? How to perform business analysis? What tools and technology what tools and

[16:39] techniques are available to you to use while performing business analysis. So the core agenda of this particular course is business analysis skills not course is business analysis skills not these soft skills but if you think you

[16:53] are you are already good at these skills then it's good otherwise you can try to you should try to improve them right uh because theoretically it looks very easy okay I'll go to that person and I'll conduct the interview and I'll collect

[17:07] the requirements but in real world it's not that easy some practice some uh experiences is always required. So try to do that. Uh try to uh try to you know

[17:20] improve on these soft skills as well along with your core business analysis skills. To become a certified BA one needs to pass one of the IIBAs needs to pass one of the IIBAs exam exams one of these exams. Uh

[17:36] so there is when I did there used to be only two certification CCBA and CBP certification in the competency of business analysis and certified business analysis professional. A few years back they added ECBA which

[17:51] A few years back they added ECBA which is uh what is the name elementary or uh something like that. So this is the exam for freshers where without any experience right entry level or something entry certification for

[18:04] business analysis we'll see the full full form. So they added it later on all three of them have different experience requirement which we will learn in coming slides but basically these are these three certifications which are

[18:18] offered by IIBA that is international institute of business analysis. uh few years back they started uh you know talking about CA Certified Business

[18:30] Analyst CBA TL thought leader certified business analyst thought leader and I was very keen that okay I'll do it I I am holding CB for quite a long time but why they wanted to introduce it and then why they dropped I I I have no idea but

[18:47] then for some for a few months it was there on their website you know coming soon coming soon CBA BATL but then it it went away and it never came back in last 3 four years. So these are the certifications right eligibility etc.

[19:01] certifications right eligibility etc. we'll just see in coming slides and uh so this is the organization IIBA is the organization right as I said they I think they were uh they launched the 2008 or 9 or something before that there

[19:17] was no IIBA these certifications were not there and that's why I was saying that the business analysis practice was not standardized when IIBA came into existence when they launched this book Babok they tried to standardize things

[19:32] what is the role how that role should be performed etc etc so all these three exams they all are based on the same book business analysis body of knowledge similarly for PMP we have project

[19:47] management body of knowledge pimok here we have beok all these exams are dependent on this or based on the same book so and this is what we are going to cover we in this course in 36 s we will cover this entire book and that is why I

[20:03] was telling irrespective of your experience whether you are eligible for CCBA or CBP or whatever out of these three you will still have to read the same book which I'm going to teach you here right so don't worry about that you

[20:18] will be you will be prepared for one of these exams automatically globally recognized standard guide that outlines the core knowledge areas,

[20:34] tasks, techniques and competencies. So the overall beck is divided into knowledge areas, right? Uh have you ever tried any one of you have you tried reading behor

[20:52] You will not see you will not find even a single example in this entire book. It's a good thick book. You read it cover to cover, front to back. I challenge you if you find even a single example. No explanation with

[21:09] examples, no mathematics, nothing. It's just complete theory and that is where I think these classes are important because it's not easy to read something like web. So first is enterprise. It is a system of one or

[21:24] more organizations and the solutions they use to pursue a shared set of they use to pursue a shared set of common goals right and edtech enterprise decided to expon expand its digital presence so they are like bigger

[21:39] companies bigger organizations you already know that organization it's an autonomous group of people under the management of a single individual so management of a single individual so like simply learn it's a company now

[21:52] Those two terms are very common. So that is fine. What is requirement? It is a usable representation of a need. Right? It focuses on understanding the kind kind of value that could be delivered if a requirement is fulfilled. So

[22:07] a requirement is fulfilled. So requirement is a is a need that one of the stakeholders, one of the person would have. would have. Okay. Um few basic questions.

[22:19] All of you are working. Not all of you, right? But people who are working you do you fill time sheet on a weekly basis or maybe monthly basis you fill a time sheet right and in that time sheet what do you do you put your time against a

[22:33] particular project right what why do you do that so that you can bill or your company can bill a particular client who you are something for a client you fill your time sheet for that project and that

[22:48] project on that basis your finance team will bill your client and get the money. then? Who exactly is paying your salary?

[23:04] client, right? How is your company making money? Whatever client pays the your company will take a cut and pass on rest of rest of the money to you as your salary. Right? on a high level that is how that

[23:18] that's how things work on the basis of multiple people multiple people like us who are working our company is able to produce something that that product is sold or that service is sold company makes money and that they pay for our

[23:33] salary but India if you think about it at a high level company is also getting paid because we are working right and the client is the person who is paying the client is the person who is paying so how you should treat your client

[23:48] accordingly, right? That they are the people who are paying. Now you tell me people who are paying. Now you tell me what is the difference between what is the difference between uh a customer and end user. Is there any

[24:01] difference between a customer and uh this end user? See my handwriting is very bad. I I keep writing because whenever there is something needs to be explained I'll I'll write on whiteboard or I'll just annotate on the screen but

[24:16] you have to put efforts to understand my handwriting. So if uh uh you are your company has given you a laptop let's say your company bought 1,000 laptops from HP.

[24:30] HP. Your company is the customer of HP right? Your company bought 10,000 laptops from HP. So your C company is the customer and you you guys are the end user because you are using I bought

[24:45] a phone. Let's say I want I want I bought a phone for my wife. So I am the customer. My wife is the end user or vice versa, right? Uh so that is the difference right? Customer and end users who will have uh

[25:01] both of them can have requirements. End users can have their own requirements and customers can have their own requirements. Now tell me uh one more thing we are talking about design. It's a usable representation of a solution.

[25:14] It focuses on understanding how a solution might realize. Uh is there any difference between requirement and solution? Some basic things we are talking about so that you are comfortable with terms and your

[25:28] understanding gets better. So if I tell you that I'm hungry, I'm telling you the problem, right? The requirement that I want to eat. I'm hungry. But what I want to eat is the solution, right? I'm thirsty and you

[25:44] give me something to eat may not uh may not help, right? Or you say I I say I am thirsty and you give me Coke and then I say I don't drink Coke. So requirement is something which can talk about the

[25:56] is something which can talk about the problem or the need and how that need will be fulfilled is the solution. I'm thirsty is the need. But what is the solution? Let's say I need a lemonade. Lemonade is the solution. Right? So as a

[26:13] business analyst your focus is not just to understand the need. Your focus is also to identify what kind of solution or that stakeholder may need or he

[26:25] should get right. So that is also you need to understand that there is a difference between requirement and the solution and there is also a difference solution and there is also a difference between the uh desires and actual needs.

[26:39] between the uh desires and actual needs. I can I can ask for anything and uh uh uh as a business analyst analyst it's your job to first of all identify my real need what actually I need instead of delivering whatever I ask you to

[26:55] deliver it's like when you when you want to buy a new car how many features you look for I want this in my car I want this in my car you know it should have cruise control sunroof moon roof ventilator ated seats.

[27:10] There are so many features these days in in cars. But when you actually own that car, how many of those features you are using? You may not be using all of those features and uh same goes for mobile, same goes for laptop. So customers can

[27:25] tell you so many different things but it's your job to help your customer understand what is their real need. Sometimes they may not be able to identify. So you help your customer identify what they need. You help your

[27:38] customer visualize what kind of solution will fulfill that need. Right? Both of these are your responsibilities. Risk is nothing but uncertaintity. Something uncertain that may happen or may not happen in future. But in case it

[27:54] happens, it will have some impact on your project, some impact on you. So your project, some impact on you. So that is the that is the risk and with risk there are two things probability of the risk and impact. So probability

[28:08] means whether it will happen or not and impact if it happens what will be the impact on you. So you want to go out and you just see on your phone that there is a probability of rain right 100% probability and you carry thousands of

[28:21] rupees cash in your pocket then that is the impact. If you don't carry anything that nothing will get impacted. Maybe I'll get cold or something but physically there will not be any impact on currency that I carry. Right? So

[28:35] we'll talk about risk and risk risk mitigation. How how we manage risk and how we mitigate risk. We'll talk about all of this. all of this. Now look at these this BACCM business

[28:49] analysis core concept model. You see there are these six core You see there are these six core concepts need change solution context value and a stakeholder. What is or who is a stakeholder? A group

[29:04] or individuals with a relationship to the change or the simplest possible definition of a stakeholder is a person who can get impacted by the project or a

[29:17] person who can impact the project. Anyone who can impact or who can get impacted both of them are your stakeholders. So if I ask you who will have a need, who will have a problem to solve, who will have a a requirement, a

[29:32] stakeholder will have, right? So a stakeholder can have a problem or opportunity to be addressed. A stakeholder will have that need. If let's say you are my stakeholder and uh you are

[29:48] uh you have a problem, right? If I fix your problem, you will get some value. your problem, you will get some value. you will let's say uh you will feel uh you are able to deal with your clients better depending on the solution that I

[30:05] provided right so there is some value to the and how you'll get the value when I'll deliver the solution right so all of these concepts are connected a stakeholder had a need in order to fulfill that need I delivered a solution

[30:21] when that solution got delivered a stakeholder got some value Right? You had uh you you were hungry. That was your need. I gave you a very nice drink. And when you had that, you felt happy. You felt like you you you were not

[30:38] thirsty anymore. So now what is the change? In order to deliver that solution, you will have to go through a change, right? So what is there are these two terms which you should know if uh as is what

[30:54] is your as is as is and to be as is also called your current state and this is also called your future state.

[31:07] your future state. So current state and future state I don't have a house that is my current state. Tomorrow I buy a house and shift into that. That is my future estate, right? Current state and future estate.

[31:21] In order to move from current estate to future estate, well, will it happen automatically? Obviously not. I'll have to transfer. I have to request a pack packers and movers to pack my stuff from my rented house, move to move me to a

[31:35] new house. So there is a complete transportation and everything. So this transportation and everything. So this is called change, right? the process or act of transformation which will move you move you from your current state to

[31:47] the future state. So that is called change. So stakeholders had needs. In order to fulfill those needs, we went through a change process and delivered a

[31:59] solution. When that solution got delivered, the stakeholders got the delivered, the stakeholders got the value. Right? Now what is context? All these five terms are easy to connect. What is the context here? In scope and

[32:12] out of scope. In scope means things that you will things that will be part of your project. Things that you will cover in your project. Right? Out of scope are the items that you will not touch in this project.

[32:27] Okay? And when we create requirement documents, we al also create sections where we clearly mention that you know these items are in scope, these items these items are in scope, these items are out of scope. For example, you are

[32:41] [clears throat and cough] you are going to construct your house and you tell the developers that you know obviously walls are in scope, ceiling is is in scope, flooring is in scope but he will also mention that

[32:55] interior designing is out of scope. So whatever cost that you are paying this is for walls, for ceilings, plaster etc. Maybe a coat of paint but no furniture is out of scope. Air conditions, conditioners are out of scope. Right? So

[33:09] that is why you have to mention that in document so that it's it's it remains scope. Now tell me now let's see who can answer this question. When you are creating this agreement for

[33:25] When you are creating this agreement for your house is that in scope? Is it in in scope of your house project?

[33:38] No. Right. It's not building a hospital nearby, is that part of your individual houses project? No. Right. Similarly, building a new school because you are talking about your own house. You're not talking about

[33:54] setting up a entire neighborhood. You are talking about building your personal house. How can airport, railway, station, hospital and school be in scope or out of scope, right? They that is they all are out of scope. But do you

[34:07] mention them in your document that you know I'm building my house so walls, ceilings and everything is in scope but hospital, railway station and all of that is out of scope. Do you write that?

[34:20] We don't write. If you start writing all of these things, your project document will become encyclopedia. Anything everything in United States is out of scope. Everything is in in Australia is out of scope. Everything

[34:33] outside this city is out of scope. So everything on this planet is out of scope except this except that particular house. A tiny house, a small house is in a scope and everything else on this planet is out of a scope. Will you still

[34:49] write out out of scope items? You will create a huge encyclopedia, right? So why don't you write all of that in an out of out of scope section because they are not part of your context. That is the usefulness. That is

[35:07] the purpose of context. Context tells you what are the circumstances that can influence or influenced by our project. What is the ecosystem that we are working in right? What are the conditions that we are working in? So

[35:23] because the condition or the circumstances are related to individual circumstances are related to individual personal house, nobody's going to ask by default airport becomes out of scope because that's not the context, right?

[35:36] because that's not the context, right? Somebody like uh you know uh let's say Shivam says you know Gurv I'm not able to hear you properly and uh simply learn should also provide me a high bandwidth internet connection now what should I

[35:51] say Sham that is not part of the context right if you have any problems uh that is not in in scope because it's out of context if you have any problem with related to material or any questions

[36:05] anything And that that can be provided to you. But highspeed inter internet connection because uh because of this training that is not part of the context that's that's not the context that's not in scope. So that is how these these six

[36:22] terms are very much related and they are interdependent. I hope you are able to interdependent. I hope you are able to relate them. Now you know uh stakeholders would have a need or needs in order to fulfill their needs you will

[36:37] have to go through a change process or a transformation process you will deliver a solution solution will provide them with a value and all all of those things will be done in a particular context right now

[36:53] right now current state and future state. So as is very important. All these terms are very important for BAS. concepts to consider the quality and completeness of the work. Right? What

[37:09] kind of changes are we doing? What are the needs? What are the solutions? Who are the stakeholders? What do stakeholders consider to be of a value? Right? What are the context that we and solutions are in? So all this all these

[37:23] six terms they'll help you ask right questions and complete the requirement questions and complete the requirement work. Okay.

[37:36] earlier this beok is divided into six knowledge area or you can say six chapters. These are the six main chapters. Along with along with these six chapters what what do we have? We have the introd

[37:52] introduction bit. So that is fine. There is one chapter which is called is one chapter which is called perspective. So it perspective, agile perspective. So that particular chapter is not tested

[38:04] in the exam. It's completely theoretical and it's like we can read in just one hour. Now first one is business analysis planning and monitoring elicitation and collaboration requirement life cycle management solution evaluation

[38:20] requirements analysis and design definition and strategy analysis. So what is the first one business analysis planning monitoring I think instead of reading I'll just explain here. So this knowledge area is all

[38:34] about planning. Okay. How I will identify my stakeholder? How I will document the requirement? How I will conduct elicitation. So here you will just do the planning part and how I will monitor my progress. Here you will not

[38:52] conduct the elicitation. Here you will not meet the stakeholder. Here you are not meet the stakeholder. Here you are just planning. Okay. So first chapter is all about planning the project and your activities in that project. Okay. And as

[39:08] I said we will go in detail. We will spend two to three classes on each of each of these knowledge areas. Right? So don't think that we are just going very high level. I'm just introducing the names and we will go deeper in each of

[39:22] them. Second is elicitation. Elicitation. What is the meaning of Elicitation. What is the meaning of elicitation? collecting the requirements. Right? Now, have you heard the term requirement

[39:36] gathering? Why? Which term do you like more? Requirement elicitation or more? Requirement elicitation or requirement gathering and why? Which term do you think is more suitable and why? Requirements gathering is much

[39:51] and why? Requirements gathering is much better. Yes. So but you you are you all of you are thinking superficially right where what looks easy what sounds easy but think about it what is the meaning actual meaning of gathering

[40:06] there is a document on my desk I just gathered it right there is another envelope on my desk I just gathered it do you think requirements are lying down on the floor or lying down on on a table where you go and just collect them

[40:21] so gathering means collection Right? Collection is not it's not like you just go and stakeholders are ready with their requirements and they'll hand it over hand them over to you. That is not so from the process point of view

[40:36] requirement gathering is not a very appropriate word. What is the meaning of elicitation? to bring forward right to ask right questions and bring the requirements forward not just because somebody is

[40:51] telling you but because you are probing you are asking right questions you are cross you are cross questioning the needs you are trying to assertain that actually you have these needs and things like that right so instead of oneway

[41:05] you the requirements and you are just documenting them instead of that you are it's proper session two-way communication two-way probing uh discussion debate and then you get the requirements so that is the English

[41:21] meaning of elicitation and English meaning of gathering we discussed right so now once you understand the exact meaning then you you you know that elicitation is a better term because for requirement

[41:33] gathering you will not get the salary right you will not get enough salary for just for gathering you are getting a salary as a business analyst because you perform elicitation not just gathering. Anyhow, people will keep using these

[41:46] terms interchangeably. Even I'll I'll also maybe I'll I'll interchangeably use these words during this training. But you you need to know the purpose and the different. So here in this elicitation

[41:59] and collaboration knowledge area, you actually perform elicitation. In the first business analysis, you planned how you will perform elicitation. Here you you will perform elicitation. Here you actually perform elicitation.

[42:11] Then what what do you think will be the output? Output of elicitation when you perform elicitation what you will get? Yes. So you get a lot of information. Yes. So you get a lot of information. You get a lot of data right in order to

[42:23] convert that data or the information into proper requirements. You perform requirement analysis and design definition. Right? So outcome or output of elicitation is not like final requirements that is

[42:39] opinion of the user, information or inputs from the user, feedback from the user. So you collect a lot of data and lot of information out of elicitation. Then you come back at your desk and you compile all of the all of that data and

[42:54] information and you convert them into properly written properly arranged requirements and that part is done in requirement analysis and design requirement analysis and design definition. You perform the analysis,

[43:07] you create requirement document and you create all other design artifacts like if you want to create any uh uh flow diagrams, data flow diagrams, you create diagrams, data flow diagrams, you create UI uh mockups etc etc. Right? Once you

[43:23] identify the requirement their life cycle will start. So requirements life cycle will start as soon as they are identified and till they are delivered and also after that uh for

[43:35] their maintenance similar to the humans humans right you are born your life cycle starts till the person is dead. So requirement similarly you have a requirement life cycle. What can happen during that life cycle? The status of

[43:50] requirement can change. Requirement itself can change. Some of the other things related to requirements like priority right can change. So as a requirements your job is not done. Uh you have to maintain those requirements

[44:06] throughout their lives. So that is done in requirement life cycle management in requirement life cycle management and uh uh solution evaluation is what and uh uh solution evaluation is what you deliver what is built that you need

[44:21] to evaluate whether it's performing as per the expectation or not. So that is uh done in uh solution evaluation evaluate what is done and then estate

[44:33] analysis is what the at the organizational level as an organization what is the strategy what is the need organizational need. So that's how these six knowledge areas are arranged. Now I'll keep repeating it

[44:48] and you will understand it better later on that they are not performed in a particular sequence depending on the project they can be performed in different sequence again and again repetitatively iteratively right that

[45:02] you will understand when we go deeper but just understand it doesn't mean that first we'll do planning then we'll do elicitation then we'll do this there can be a project where the project is launched because there is a problem

[45:14] identified so solution ution evaluation is performed, problem is identified, is performed, problem is identified, then you do the elicitation to get uh details of the problem and then you plan the project. Right? So in a different

[45:27] order you perform these knowledge areas or uh at an organi at at the organizational level a strategy analysis was was performed let's say where you did root cause

[45:39] let's say where you did root cause analysis or you performed uh analysis or you performed uh um what what what do we call it uh a um what what what do we call it uh a strength weaknesses sort analysis and uh

[45:51] after that sort analysis you found out an opportunity and you launched a project. So you see a strate was performed then elicitation and planning is done. So depending on the nature of the organization and project these can

[46:04] be performed in different orders. Just remember that and you will understand it later slowly. Right? So these they all are interlin right? All six knowledge areas. Now one more thing under these knowledge areas there

[46:19] thing under these knowledge areas there are tasks. Okay. um one of them has six tasks, one of them has four tasks and remaining have five tasks each. So there remaining have five tasks each. So there are total 30 you can say 5 five four and

[46:33] are total 30 you can say 5 five four and six. So total 30 tasks and there are 50 six. So total 30 tasks and there are 50 techniques. Okay. So there are six knowledge areas, right? All these knowledge areas have 30 tasks

[46:49] knowledge areas have 30 tasks and there are in total 50 techniques. there is many to many relationship right I don't know if you know these

[47:03] many relationship between task and techniques. One task can use one or more techniques. One task can use one or more techniques. So let's say no uh elicitation right in order to perform elicitation

[47:19] for this knowledge area what could what can be the tasks prepare for elicitation prepare for elicitation conduct elicitation document elicitation result etc right so this task let's say conduct

[47:35] etc right so this task let's say conduct elicitation is a task under elicitation knowledge Conduct elicitation task can be Conduct elicitation task can be performed using multiple techniques like

[47:49] performed using multiple techniques like interview,

[48:04] under elicitation and collaboration knowledge area. This task can use one one or more than one techniques like this. Other way around workshop as a

[48:18] technique can be used in multiple tasks like conduct elicitation can use requirements. I want to provide a walk through to stakeholders about my requirements to take this sign off. I want to evaluate the solution. So in

[48:33] many places you can use workshop as a technique. So that's why I was saying there is one many to many relationship between tasks many to many relationship between tasks and techniques. One task can be can be

[48:45] can can use multiple techniques and one technique can be used in different technique can be used in different different tasks. Okay. So that is how webok is organized. Six knowledge areas, 30 tasks and 50 techniques. Okay.

[49:01] every task is also organized in a particular fixed template which I'll explain later u or let's we can talk about it now as well. about it now as well. So task is like name of the task

[49:16] right the order may differ or maybe I missed one or one point or two but you will get the purpose. So name and description of the task conduct elicitation what is the purp you will see a description you can have a purpose

[49:29] so it'll tell you what is the purpose of this task what inputs required to perform that task right what will be the output once you perform this task so input and output of that task

[49:43] what are the key elements what exact what exactly is done techniques used and uh there is there is one or more two

[49:55] headings like additional inputs, additional something. So basically every task that you perform there will be some inputs which you will use you will do some processing here inside this task. In order to do this

[50:11] processing you will use some techniques and then there will be output of that task. Right? So each and every task in beok beok is

[50:25] is planned like this right. There is a fixed format and fixed template which is repeated again and again again and again for each and every task 30 tasks right. what you need to focus on do you need to remember everything? No. what you need

[50:41] to focus on. See in your day-to-day life if once you become a business analyst we don't even talk about a lot of theory which is here we focus on 50 techniques right because techniques is some technique is something that you actually

[50:55] use in your project you don't have to talk about inputs outputs you know that uh with time you will know that uh and also to pass the exam and throughout this course every every time we'll not talk about you know what is the input

[51:10] what is the output you will after some time once we covered 15 20 tasks you yourself and I'll tell you I'll keep checking now can you guess and you will start answering the question what we need to focus we need to focus on

[51:25] understanding the key elements of the task what exactly the task is doing what are the key concepts key elements related to that task that is where you need to focus you should have absolute clarity on key elements and you should

[51:39] have absolute clarity on 50 tasks techniques these two things we need to focus uh obviously I'll explain why these inputs why this output why this input to this particular task why that output from this that particular task

[51:53] all that we we'll discuss but you don't have to worry some generally what happens people will say see sir there are 30 task in case there are four are 30 task in case there are four inputs so there will be 120 inputs and

[52:06] let's say there are 80 outputs how will I remember this all 50 techniques can be used by different different tasks. So there can be 200 types of permutations combination. How will I remember them? So that is what I am telling you. You

[52:19] don't have to remember you don't have to memorize inputs, outputs, techniques, stakeholders. No, you don't have to memorize them. You just need to focus on understanding key elements of a task and in isolation all 50 techniques you need

[52:34] to understand. rest everything will come automatically once we move ahead in this course. This is just the list of 50 techniques which are which we are going to go through all of them acceptance and evaluation criteria and all of these. So

[52:50] there are in total 50 techniques. See one page and second page. So two pages they are just listing down the techniques. So we will come uh we'll cover them as and when we come across uh

[53:07] them in our content right from the Babok point of view all 50 techniques are part of a separate chapter but when we study we'll try to cover them as and when we come across them instead of so I'll keep explaining you techniques wherever we

[53:22] explaining you techniques wherever we find them getting used in our material find them getting used in our material okay uh answer this quickly which of the following is not a component of business analysis core concept model

[53:35] we didn't discuss content was not there so content is the right answer I think there was one more question on the previous slide yes what does BACCM stand for yes business analysis core concept model

[53:49] analysis knowledge area which of the following is a right not it's not like not which is not correct

[54:01] answer is a right elicitation and collaboration. See if you consider the previous version of beok then you will say the rest of three are also correct. They used to be the names in the previous version but now they have

[54:14] changed. So elicitation collaboration is there. So that is the correct answer. Enterprise analysis has become strategy analysis. Right? Solution assessment and val validation became solution evaluation and requirement analysis and

[54:28] life cycle management. Right? So these three B, C and D they used to be the names in the previous versions of Babok but in present version and current version only A is correct. I'll just answer which of the following is a

[54:42] answer which of the following is a stakeholder in typical BA engagement. All of them are your stakeholders. Next is IIBA stands for the

[54:54] international institute of business analysis a globally recognized professional association dedicated to supporting and advancing the discipline. It was founded in 2003 Ontario Canada based and publication

[55:09] major publication is Babok guide and how does it define the standard through the Babok guide identifies the skills necessary to be effective through the IIBA business analysis competency model and self- assessment tools and there are

[55:23] these three certifications that we discussed. So if you go to the website discussed. So if you go to the website of IIBA you will see that there are some resources which are available for free and there are some resources which are

[55:37] available for members only. So you can use them like business analysis competency model or there is a self assessment tool. So you can use that uh IBA membership uh it provides access to exclusive

[55:53] content and support. So if you take the membership you can get access to career action guide etc etc. There is as I said there is a lot of material which you can get. When you take membership you get free access to new versions of Babok as

[56:07] well. You can participate in different networking and community events and sometimes they ask for volunteers as well. So let's say they want to create 20 new questions or 50 new questions or they want to create a new version of

[56:22] Babok things like that. So at in those in there also you can get some volunteer opportunities also the also there are many webinars that they run some webinars are public some webinars are members only. So that

[56:39] is also uh another benefit of taking membership. Right now if you are planning to write the exam whichever CBP or CCBA in that case taking membership is sensible. Maybe you next year you you

[56:54] think of not renewing it. That is fine because if you take membership the cost of membership is less than the discount you get on the exam fee if you if you are a member right we'll just see on

[57:07] coming slide. So see there are three first is entry certificate second is certification of capability and third and final one is certified business analysis professional. So this is the basic one. This is the

[57:21] middle one and then the final one. Okay. Now what is the difference? Uh as I told you the book is same content is same. Then what is the difference? For CBP you

[57:33] need to have a minimum 700 7,500 hours of business analysis work experience in the last 10 years. So there is this experience requirement that you need to fulfill. How do you calculate? If I try to simplify this for your

[57:49] If I try to simplify this for your understanding, let's say how many days understanding, let's say how many days there are there in a in a in a year 365 there are there in a in a in a year 365 right out of that there are uh holiday

[58:02] weekends uh 104 Saturday Sunday then you have 1520 national holiday public holidays then you have your sick leave annual then you have your sick leave annual leave so I think if we reduce

[58:15] all that conservatively we work for roughly 200 days 200 days 220 days. So conservatively I will say 200 days into 8 hours per day. will say 200 days into 8 hours per day. So again I if I round it off let's

[58:30] safely conservatively assume you work 1500 hours per year. 1500 hours per year. So for to get 7,500 hours of experience you need to have at least five years of prior business analysis experience. Five

[58:45] years So that is the expectation that is the eligibility criteria for CWEB that is fine that you divide this experience into six knowledge areas. So you can equally divide like 1,000 hours

[58:59] of 1500 hours in each of the knowledge area that is fine. So that is first at least five years of business analysis experience right and then professional development have a minimum 35 hours of professional development. So the

[59:13] training that we are conducting right now, the class that you are in right now, this will give you 36 to 38 hours or maybe 40 hours of PDUs, professional development units. So this training that you are attending with me right now,

[59:30] this training is a prerequisite. You need to complete this training or from some other vendor that is fine. But at least there has to be at least one training which uh you attended at least for 35 hours, right? And that training

[59:43] completion certificate is important. So that is why I was telling you yesterday that from s from the portal LMS portal you need to download your completion training completion certificate and that certificate you have to upload when you

[59:57] apply for CWEP exam. Right? So you will get the PD. So this is the second important requirement. And third one is references. You have to provide two references. Now they can be uh your managers

[1:00:12] right current manager, previous manager. So that is fine. If you are a fresher, then you can provide reference of anyone who is already CBP certified. If

[1:00:24] have to be CE certified, right? Your manager without certification is fine. otherwise, you can provide contact of anyone who is CEB certified. So what happens when you provide the me

[1:00:38] happens when you provide the me reference they will get email from IIBA that and they'll ask few questions. So it will be a simple five six question long form that I know you or how do I know you what is the relation and all

[1:00:53] that. So they need to respond. So when whoever you provide as your reference, whoever you mention as your reference, please uh align them, please inform them that I am providing your name with your email id as my reference to CBP. So once

[1:01:08] when you get the email from IIBA, please respond to that email. Right? So these are the main three requirements. Work experience, at least 5 years of B experience, 35 hours of minimum training in last four years. So it's not like you

[1:01:23] attended a training 8 years back that will not be counted. So something which you attended recently in last 3 four years that training and then your requirements. Now what happens when you if you don't

[1:01:37] have that experience so next certification is CCBA right so there certification is CCBA right so there this requirement will be just half 3,750 hours. So that means you can say two to three years of experience is enough

[1:01:52] right and then you can equally divide this by half. This requirement will still be there but I think number of hours will be less. 20 or 25 hours of training is required. References

[1:02:05] will I think you need to provide reference. Then for ECBA this is not required. no experience is required uh and no references are required because they are considering that you are fresher you have no experience so you

[1:02:20] might not have any professional references to provide so for ECBA requirements are very very lenient and the question paper is also slightly simpler as compared to CBP and CCBA obviously because you don't have that

[1:02:33] kind of experience so what I would suggest suggest the important part that go to iba portal Okay. And check

[1:02:46] let me also tell you one more thing before we move on. See before we move on. See this is the fee for ECB exam. Okay. Application fee none. Examination fee is $195 for members and $350 for

[1:03:02] non-members. How much is the difference? Almost Almost not almost exactly $155. not almost exactly $155. is the difference in the fee for ECBA.

[1:03:20] additional application fee $145 which is same for members and non-members. And same for members and non-members. And then $250 and$15. So again $155 you save if you take the membership. Okay, the total cost if you are a member is

[1:03:36] roughly $400, right? $395 and without membership it will be exactly $550. membership it will be exactly $550. For CBP the fee is almost similar to

[1:03:48] For CBP the fee is almost similar to $100 more. So $250 350 and this becomes so $200 more. So total fee for CBAP if you don't

[1:04:00] have a membership is $650, right? And for a member it is $500, $495. Okay? So you save almost $155

[1:04:14] in the fee if you take membership. And if you go to the IIBA portal, you can if you go to the IIBA portal, you can check how much is the membership fee. Membership fee is dependent on your country. So they have divided

[1:04:27] the all the countries into three categories and the fee is dependent on your region. If you are in India it will be less than uh other countries. Let me quickly give you some idea of that as well. I I have no problems if you take

[1:04:43] membership or no you you don't take that's completely up to you. The only difference is because for the first year you can get why I'm suggesting because for the first year you will get both the benefits right you will pay less fee for

[1:04:56] the exam at the same time you can get the membership benefits IBA if we go to the membership view pricing let's see if they have revised any prices earlier it used to be $50 $60 let's see region one 155 USD

[1:05:15] $50 $60 let's see region one 155 USD region 200 USD and region three 60 USD. So if you see countries, this is there is a list of countries. So for example,

[1:05:31] you save $155 on your exam. So you will still end up saving $890. People who are in this uh in these countries, they they will still save. People who are in region one, Australia,

[1:05:47] People who are in region one, Australia, Austria, USA, the UK, they'll not be able to save but still at the same cost you will get the benefits of membership you will get the benefits of membership along with the exam. Okay. So this is on

[1:06:01] the membership if you take if you look at the certification IIA certifications. So they are they they started offering and others but from the BA point of view

[1:06:14] they still have just three. So when you click on certification core certification right core business analysis certificates ECBA

[1:06:29] analysis certificates ECBA CCBA and CB. So let's check the criteria for ECBA just to make sure that whatever is mentioned in our slide is still have there is no change.

[1:06:41] So there are no requirements sorry uh this includes this includes IIBA membership. See this is fine. There is no eligibility criteria as such for ECBA. Right?

[1:07:06] See here you have 300 7 3750 hours of B experience, 21 hours of professional development instead of 35 for CBP. You need to provide references. Rest everything is same. So the only difference is in experience and

[1:07:21] trainings right and for CV I already explained. So please go through this explained. So please go through this portal spend some time try to understand I also told you how to calculate your work experience so that you can do it

[1:07:34] yourself make yourself comfortable with the portal and identify which certific certificate is more suitable for you right now what will happen after 3 years so all these certifications are valid for 3 years after 3 years you have to

[1:07:50] renew the certific certification in order to renew it it's Not you have to pass the exam again. You can just keep accumulating your PDUs like now we said

[1:08:02] professional development units right after passing the exam we call them continuous development unit. So you keep accumulating accumulating CDUs by reading something by uh by

[1:08:15] attending some trainings by volunteering on something you keep accumulating those CDUs right so you can renew after 3 years if you go for ECBA after 3 years instead of renewing your ECBA you can go

[1:08:30] for CCBA so that is how we need to manage this so the first Chapter proper chapter or the f second uh lesson number two is

[1:08:43] business analysis planning and monitoring part one. So from the slide or from the content point of view some of these uh knowledge areas are divided into two parts because some of them are really

[1:08:55] big. For example planning and monitoring requirement analysis and design definition they are very big. So they are divided into two one part. Some of them are in one part some of them are are in two parts. Okay. So what did I

[1:09:08] tell you yesterday that there are six knowledge areas, right? And the business analysis, planning and monitoring focuses on the planning part. Here we do not execute tasks, we do not perform task, we just plan. So and uh

[1:09:28] uh we always say as a project manager, program manager that failing to plan means planning to fail. So if you fail to plan or you are intentionally you are you are not planning that means you are planning to fail. So that is why

[1:09:44] planning some bit of planning is always required. Uh depending on whether you required. Uh depending on whether you are using waterfall or agile you plan differently you may plan iteratively at different levels but some planning is

[1:09:57] always required right. So that is what we cover in this particular knowledge area the planning bit. See there is this scenario given in 2016 what of Vodafone

[1:10:09] UK ran into serious trouble while migrating its CRM system because of migrating the system without a structured validation approach not involving key stakeholders in planning and testing weak governance

[1:10:22] oversight and risk planning this led to billing errors customer complaints and 4.6 6 million fine from offcom. This this Ofcom must be a regulator. If you project, how would you plan and manage your work to avoid such outcomes? So

[1:10:39] view, what do you think is wrong here or was went in in incorrect or wrong direction. See there was no validation approach not involving key stakeholders, weak governance, oversight and risk

[1:10:54] planning. All of these things are some of them are specifically for business analyst like validation. How will you validate whether solution is working as per the requirements or not? Some of them like engaging stakeholders are

[1:11:09] there are overlap between responsibilities of business analyst and project manager. If we right now we're talking about typical traditional talking about typical traditional waterfall project management, right? So

[1:11:23] uh you talk to same stakeholder as a business analyst. Project manager also project manager. Then what is the difference? The agenda is different. Right? Project manager will talk to talk to them for let's say project budget,

[1:11:39] project cost, project schedule, project risks that they all are the accountabilities of project managers. We we'll cover many of those things in this course and BA will interact with the same stakeholders for the requirements

[1:11:53] for solution validation for writing acceptance criteria to take their help acceptance criteria to take their help in supporting in testing etc etc. So BA's engagement is slightly different than the project manager engagement even

[1:12:07] though there will be some overlap because the stakeholders are same. because the stakeholders are same. Okay. Uh now why this is required? Uh we Okay. Uh now why this is required? Uh we always say that you know if you identify

[1:12:21] problems earlier it's easier to fix it's cheaper to fix but if you end up identifying gaps etc later in the project they get difficult and more project they get difficult and more expensive to to fix. So let's see uh if

[1:12:35] expensive to to fix. So let's see uh if you if you just reached let's say uh you are at point A right now you are at let's say point A and you want to go to point B but there is no map nothing so you start

[1:12:51] moving in the wrong direction okay you reached to point C and then you realized oh I started moving in the wrong direction I need to correct my course I need to correct my path and I need to change and go to B. Now what what do you

[1:13:05] think what what will be the difference in one more case? Let's say you moved in one more case? Let's say you moved further away and here you realized that it is wrong direction and you have to correct and go to point V. Now what do

[1:13:18] you think? What is the difference? If you talk about time, if you talk about money, both will change right here. If it was supposed to take 1 hour and let's say 500 rupees in in in taxi now it because

[1:13:34] you have to travel this much it will take maybe 1 one and 1 hour 30 minutes and maybe 750 rupees in this case it may end you may end up spending 2 hours in taxi and maybe 1,000 rupees right time required is more fuel required is more

[1:13:51] so overall money required is also more so that is the main problem who will help with this direction. What exactly is required? What exactly do we need to build? Which direction do we need to move to? Those things are dependent on

[1:14:07] move to? Those things are dependent on our nice business analyst, right? He is collect the requirements, who will tell the requirements, who will have the idea what to build as a solution, right? So the overall road map etc. He'll have a

[1:14:21] good idea. So that is the person who is supposed to navigate the team in the right direction and save. So that is why business analysis is very important. business analysis is very important. Otherwise if you start with wrong

[1:14:33] requirements, incorrect requirements, the cost of fixing them later on in the project will be high. Right? And for this reason that I just uh mentioned here. So business analysis is a structured approach used by business

[1:14:47] analysts to understand, analyze and solve business problems. Think of it like a road map or toolkit that helps a business analyst. Right? Understand the current state of business. Identify the needs or problems.

[1:15:03] Design the right solution and ensure solution delivers value. I told you yesterday what is the current state? Your current estate, right? Or your solution or application's current state. I I live here that I live in Pune. That

[1:15:19] is my current estate, right? uh I live in a particular apartment that is my current estate right I have to move I switch my job and

[1:15:31] I now I need to move to I need to go back to Guru Guruga where I lived for back to Guru Guruga where I lived for last 12 12 15 years Guruga that will be my future estate so this is my current estate right

[1:15:47] my current estate right this is my future Right. What is the problem? Or let's say a different problem that before COVID

[1:15:59] uh it was manageable to live let's say in a two-bedroom apartment or one bedroom apartment. If you were married, you were living or maybe you were single but living with your parents. Did you notice that after COVID when we had to

[1:16:12] work from home and study from home suddenly whatever apartment we were living in whatever house you were living in it started you know feeling small because we had to work from home we had to study from home so did you feel that

[1:16:28] did you feel the same and suddenly there was a need to move to a bigger apartment so that we can have separate space and in my case I had to I I used to work from home some of the days and then I used to take trainings also. So suddenly

[1:16:43] it was like how could I work or operate from this house right my wife had to work and we have we didn't have enough space. So there this was the kind of identification of need or problem that I because of the lack of space I need to

[1:17:00] move to a bigger house. Don't you think it's a proper need? It's a it's a valid need. It's a genuine problem. Yes it is right. So then what what could I do?

[1:17:12] I could move to a bigger house right now. When you talk about these solutions, it could be like uh you need three-bedroom house, you need four bedroomedroom house depending on your family members etc etc. So in that case

[1:17:28] do you think your wife or your husband becomes your stakeholder? because the solution or the problem that you are dealing with or the solution that you will identify it is going to impact them right or you you your if you

[1:17:44] have kids they might say I also need my separate room or your parents might say that you know when you are shifting make sure you shift to ground or first floor you don't go to 10th floor or 20th floor they have their own concerns they have

[1:17:57] their own requirements your spouse says that I want a better you know a kitchen or I want this or I want a separate study. So you know suddenly because there is a project there is a there is a plan to move from our current estate

[1:18:11] stakeholders which are who are impacted or they can have their own requirements or they can have their own requirements and on that basis we create the solution and on that basis we create the solution right and when you move right from one

[1:18:25] house to another house if the house is just in the same building on the same floor do I need professional packers and movers if I'm moving in in the same building let's say across the hall uh do I need

[1:18:39] professional packers and movers maybe not right but if I'm moving to a different city do you think I need packers and movers packers and movers in this case I need so you see depending

[1:18:53] on the solution the approach will also be different so it's not like you always be different so it's not like you always move from this point to this point like this Right? Sometimes you need peckers and movers. You will move. So like we

[1:19:08] discussed yesterday, there can be different solution options also to reach to solve our problems. So we'll discuss about all these things in detail. But the point which I wanted to make right now that understand what is the meaning

[1:19:23] of current state, understand what is the meaning of future state, how they are you know different, how they are different and how you need how they are different and how you need to move from current state to the future

[1:19:38] state using some of these solution. I can move from my house to the next house using packers and movers or I can do it myself. So there can be multiple solution options as well. But all these things I'll take uh I'll I'll explain in

[1:19:55] more detail in coming classes. Okay. What is the meaning of current state? What is the meaning of future state? What are the options? What are the what is the meaning of change? All those things we'll cover in greater depth in

[1:20:09] things we'll cover in greater depth in coming classes. knowledge areas. We already discussed uh six of them yesterday.

[1:20:22] and monitoring. So BAPM is the knowledge area that defines the tasks associated with organizing and coordinating the effort of business analysts and stakeholders. Right? So this is all about planning,

[1:20:35] organizing, coordinating. Here you do not perform the tasks. Here you do not actually start the elicitation. Okay. Now what happens when you so the primary

[1:20:47] Now what happens when you so the primary goal of BAPM to define the approach to identify and involve right stakeholders to establish governance mechanism for decision-m and change control to plan how requirements and

[1:21:01] related information will be managed to evaluate and improve business analysis performance. So these are the primary goals and these goals are divided in be about approach, second will be about identification of the stakeholder. So

[1:21:15] basically these five primary goals will convert themselves into tasks of this knowledge area. Okay, we'll see them one by one. So proper planning prevents poor phase, right? The first phase of planning. Imagine being handed a project

[1:21:32] but not knowing what problems you are solving, who is affected, who decides what and how to structure your work. Without answering these questions, can you uh move ahead in your project?

[1:21:46] What do you think? If you have no idea what exactly is the problem, what will you fix? Right? Who all who all are affected? How will you connect with them? How will you fix their problems? If you don't know who you need to go to

[1:21:59] to take the approvals, who is the authority, you can't work without that. Who will fund the project? Who will approve the budget? All those are important questions. And how to structure your work, how to organize the

[1:22:11] information, uh depending on your depending on your uh organization, whether you are going to use Jira or you are going to use SharePoint etc etc all those things you need to have some idea right.

[1:22:26] It's not like you cannot start working without having answers to all the question. As a business analyst, as a program manager, we have to move ahead. If if all the information is not available, we make some assumptions and

[1:22:41] move ahead, right? But at least some idea has to be there. So this is the purpose of this knowledge area to get the idea or to get the answers to all of these questions which are mentioned here.

[1:22:55] Now as I explained you yesterday every task will have certain inputs task will have certain inputs they will tell what exactly is uh performed key elements and output. So like for example this knowledge area has

[1:23:11] these many tasks plan as business analysis approach plan stakeholder engagement governance and so on so forth. So these are the six five tasks in this knowledge area. Right? We'll go through them one by one. Outputs and

[1:23:26] inputs we'll also see for each and every task. This is a screenshot of picture from the book it book itself. So you see majorly the inputs to all of these tasks are needs and performance

[1:23:40] these tasks are needs and performance objectives. Output are these five. Right? So uh in the beginning of every knowledge area you will see a collective snapshot like this where there are all the tasks mentioned of this knowledge

[1:23:55] area all the inputs and all the outputs. However we have to go through each and every task in detail and we will see input and output specific to that task. Okay. So out of these five that let's see the

[1:24:10] first task it is the first core task of BAPM it is the first core task of BAPM knowledge area in the beog guide before identifying or writing requirements plan how how you will approach the work

[1:24:23] choose the right methodology define the detail level assign roles and set up progress reporting so before we go into details let's see the different parts

[1:24:35] or sections as I told you every task task is uh every task has a fixed template the same template which is used across all 30 tasks. So you have name of

[1:24:48] across all 30 tasks. So you have name of the task description the task description and you have inputs, you have outputs, you have guidelines and tools. Guidelines and tools are like optional.

[1:25:02] If they are available, we can use them. If they are not available, we can do without them. But input is important. Without input you cannot convert the you cannot get the output. Right? But guidelines and tools we consider as so

[1:25:17] just to simplify uh I always call them additional and optional inputs right so you can say guidelines and tools are additional

[1:25:30] inputs. You use them if they are available. For example, business policies. It's not mandatory that you will always have business policies. It is also possible that you may not have some of these things. You will see

[1:25:42] throughout the course. Some of them may not be available. So that is fine. So these are additional but optional. Inputs are mandatory. Uh this is the

[1:25:54] Inputs are mandatory. Uh this is the name of the task output and uh there are two things the input can. So what happens? Let's say there is input, right? This input is going into this task.

[1:26:18] output. Now this output can go to a different task T2. T2 can produce. So now for T2 this becomes input, right? T2 can produce

[1:26:34] output. Now this output is possible that it is going not into a task but to a external party. Basically it's external right not consumed or maybe used by a stakeholder

[1:26:50] consumed or maybe used by a stakeholder but not going into any any um any task. So here you will always see that some of the inputs are coming from another task like this and some of them may be external coming from outside not they

[1:27:05] are not output of any other task. So just be clear that some of the inputs can be the output of other task some inputs can be external. So you will always see here in when you read web that some of the inputs are external

[1:27:21] some of the inputs are output of other task and here also you see business analysis approach is the output I'll tell you what exactly we are talking about but first let's understand the structure so what is the output of this

[1:27:34] structure so what is the output of this task plan business analysis approach so task is plan the approach so what will be the output the approach business analysis approach is the output now this output is used by these many tasks. You

[1:27:48] see in this knowledge area all the tasks are using this input. elicitation, conduct elicitation, they are also using this output.

[1:28:00] Even manage stakeholder collaboration, analyze current state, define change strategy, assess risk. So many of the tasks in this overall are using this output. Right? So that is what you need to

[1:28:15] understand that every output will be used by multiple tasks right you will understand why when we'll when we'll go into task in detail you will understand why uh that is important uh and important input to other tasks okay

[1:28:31] apart from that there are other headings like uh tools and guidelines we have like uh tools and guidelines we have covered bas main or uh main elements so there you will they'll will explain what exactly this task all about. Right?

[1:28:47] So the core element or basic elements will explain what exactly this task is all about. And then there are uh stakeholders

[1:28:59] and techniques. So these are these are the headings or you know points which are covered consistently for each and every task. I told you yesterday you don't have to think too much about who are these

[1:29:13] think too much about who are these stakeholders. You can just you read it but you don't try to memorize it. Okay. You have to focus on elements a lot. You You need to be very clear about techniques.

[1:29:27] Now which techniques are used in this particular task? You don't have to memorize. You will start understanding and guessing yourself. What are the inputs to this task? Again you don't have to memorize. You just need to

[1:29:39] understand the purpose of task you will automatically start guessing if this is the task what kind of inputs I'll need right so that you will you will start guessing what will be the output that is also very easy to guess for example plan

[1:29:53] business analysis approach if you are planning something the output will be that something right so you know an approach is the output so you don't don't have to memorize if you understand the concepts if you

[1:30:07] understand elements and techniques you will start answering the questions without mugging up without memorizing especially when you see four options then it becomes even easier to guess the right option right right answer

[1:30:21] clear so the first task which talks about planning uh the business analysis approach what is the approach in this context

[1:30:33] here the approach that we are talking about is whether it is uh adaptive approach or productive approach. Now what is the meaning of productive and what is the meaning of adaptive? So

[1:30:49] the business analysis approach should align to the overall goals of the change and also I would add that it should be aligned with the project approach. Right? You cannot have business analysis approach which is not aligned with

[1:31:02] overall project. Your business analysis is part of the overall project. Right? Right? It is just one phase of the overall project. So your BA approach timelines etc. they have to be aligned with overall project. Now uh you co you

[1:31:18] with the activities and deliverable of the overall change right and project. That's what I'm I just explained. So what is the adaptive approach and what is the predictive approach? If we put it in more into project uh

[1:31:32] If we put it in more into project uh perspective see uh predictive used to be we used to call predictive the traditional waterfall SDLC right development life cycle agile is called adaptive so when I say

[1:31:46] predictive what will be the stages in the project in a typical project if you're talking about software development you will have requirements before that you can have some planning project planning doing

[1:31:59] pre-ro activities like you are creating business case, you are doing some pro uh uh you know uh presenting that case, getting the funding etc etc but mainly then you will start with requirements then then you will have design then you

[1:32:15] will have development then you will have multiple phases of testing then you can have deployment or release then you can have maintenance right these are the phases on a high uh sequence will remain almost the same

[1:32:32] and they are called waterfall. Waterfall or sequential because they are in a particular sequence. This handovers are very well defined. Design will start only when requirements are completed. Right? When business

[1:32:48] analyst would say they they have they have completed the requirement, you can start with design. So design will start. Similarly when design is done then development will start and same same thing so so on and so forth right. So

[1:33:02] this is called productive because planning is done almost everything is should be planned in the beginning of the project and the flexibility is not that much there right. So this is called predictive and

[1:33:17] right. So this is called predictive and what is adaptive? Adaptive is agile what is adaptive? Adaptive is agile right where you pick the work in small chunks. So the batch size will reduce and you then you keep picking items top

[1:33:31] priority items from the backlog. You keep building them delivering them again deliver. So that is why adaptive is called iterative and incremental right iterative means you do the same thing again then again then again. So you are

[1:33:48] repeating the same thing. You pick items. So you perform requirement and uh you perform dev and you perform test and then this cycle you keep repeating every two weeks every 3 weeks you keep repeating there is a pro list of

[1:34:02] requirements you pick requirements from here two three requirements from top of the pre backlog you keep picking you keep delivering and you keep taking keep delivering and you keep taking feedback. So here the major difference

[1:34:15] the most important difference is that this is not sequential. So even the requirements are done iteratively right instead of let's say in a project you had 50 requirements right so in waterfall in adaptive you perform the

[1:34:32] waterfall in adaptive you perform the requirement analysis for all 50 once that is done you do the design for all 50 then you develop all 50 you test all 50 so everything is done on entire project scope

[1:34:45] whereas in agile you pick two requirements three require requirements depending on the capacity you work on them deliver them then you pick next them deliver them then you pick next four so the batch size is reduced

[1:34:58] this is not agile course otherwise I would have explained a lot more what are the benefits what are the drawbacks of waterfall and agile etc etc but I'm sure in your master's program you would have a separate course on agile but why we

[1:35:11] have to discuss it is still a bit of it because this is the first task itself because this is the first task itself right which is the there and approach whether you are taking productive or adaptive is going to have impact on your

[1:35:24] business analysis activities. Now you tell me if you talk about timing of business analysis activity timing do you see any difference in waterfall or

[1:35:37] agile in case of predictive all the analysis should be done up front right in the beginning of the project you need to analyze all the requirements in case of agile it will be ongoing

[1:35:54] have to work on two to three requirements ments. So that is the that is one of the most important impact on the business analysis work whether you the business analysis work whether you analyze all of them or you will do in

[1:36:07] What is what is the impact on the formality of the documentation that you need to create? Waterfall or traditional is very very formal. This is less formal. So in case of waterfall we used to

[1:36:23] create very extensive extensive BRD. It will go through a very uh you know proper

[1:36:36] It will have a very very strict change management. In case of agile you you don't have to create huge or very heavy documents like BRDFRD. You can simply create epics features user stories. You can still create documentation. It's not

[1:36:51] like but agile says you can do with less documentation as well. So that is fine. If I want to create let's say in waterfall BRD if I wanted to create a screen wireframe I'll have to create a proper screen wireframe. I'll upload it

[1:37:03] into the document insert it into my document. In case of agile if I'm using a whiteboard I create something like to discuss with the clients. This is the login page. Here you have these fields etc. I take the snap screenshot of this

[1:37:17] or I take a photo of this whiteboard upload on the Jira. I think that is also acceptable. Right? So timing is very different, formality is very different. Then the kind of documentation that you create is also different. Right? So the

[1:37:34] point is the first the first task itself talks about what the first task itself talks about what is the approach in your project. what is the project approach on that basis your approach will also be different so that

[1:37:48] is why this is the first task so I hope you understood what exactly we're talking about if your project using waterfall your business analysis approach will be different if you are using agile your business analysis

[1:38:01] approach will be different now within the same project you can't use waterfall and agile right so if you are in your organization some projects are done in waterfall so they will you will deal with them slightly differently. In case

[1:38:15] of agile, you will do your work slightly differently, right? Also, the impact is on the stakeholder engagement, right? So, timing of the docu activity, formality of the documentation and what about the stakeholder engagement is it

[1:38:31] same or different? So in case of waterfall where exactly you will uh engage with the stakeholders in the beginning of the project. So it's possible that for one month when you are performing your requirement elicitation

[1:38:46] you need a lot more time from them right but that is only in the beginning but in case of agile it's possible that you don't need entire time in the beginning hours every week to perform your requirement grooming sessions to

[1:39:01] complete your planning and you know review etc etc. So a stakeholder should project this kind of engagement is required in this project this kind of engagement is required. Now tell me is it like your decision as a business

[1:39:14] analyst which approach should be used in the project it's not your decision right it's collective decision maybe a sponsor can can they can take your inputs that's fine but it's not your decision so

[1:39:29] that's why I was repeating that depending on the project approach you need to know that timing of your work formality and stakeholder engagement is impacted so that is more for you to understand and work accordingly.

[1:39:43] Okay. So [clears throat] that is the depends upon case to case and the methodology it see what happens in the

[1:40:00] project whether it's waterfall and agile that is different thing what I'm saying if depending on the project approach what is the impact on your work right you should be comfortable that in one case you have to create the entire BRD

[1:40:16] or FRD and in one case you might just create Jiraas. So as a business analyst you should be comfortable with both both creating creating accept uh you know uh extensive documentation or creating light documentation engaging with the

[1:40:32] all the requirements or engaging with the stakeholders every now and then uh requirements. As a business analyst, you should understand the difference and you should be comfortable with both. Okay. Rest obviously it's case to case. It

[1:40:47] depends on the project whether it's typical waterfall, typical agile. I also typical waterfall, typical agile. I also worked in projects where uh initially I created the BRD because stakeholders were not very comfortable with agile. So

[1:41:00] I had to create BRD. Then for development they wanted to create user stories. So I ended up creating BRD and user stories. So that all those exceptional and edge cases scenarios will will all come across in projects

[1:41:14] right u agile when the so yes if I create a a graph like this where I have uncertaintity

[1:41:32] and here I have uncertaintity of solution. are uncertain. Solution is uncertain. Which box

[1:41:46] I can use agile and in which box I can use waterfall. See waterfall is suitable here. That is clear. Here clear. Here agile. Here agile. Here agile.

[1:42:02] Uncertaintity is high. This will always be very chaotic right a very problematic on requirements you don't have clarity on solution so this is the most

[1:42:14] problematic part here you need rapid agile agile in even more powerful more agile agile in even more powerful more rapid agile here waterfall can be done requirements and you have clarity on the solution but here you need agile scrum

[1:42:30] whatever why because see if require requirements are not clear what will help if requirements are not clear what will help the batch rem reducing the batch size will help you are talking about 100 let's say 20 requirements in

[1:42:45] your backlog requirements are not stable they are not certain so what we will say to our clients that okay give us just two requirements where you have clarity and you can continue to change remaining right while I work on these two you

[1:43:00] continue you are free to adjust these requirements change these requirements So we are giving a lot more time to the clients. We are giving a lot more flexibility to the client to keep changing whatever we are not working on

[1:43:13] right now and give us clarity on just few requirements. few requirements. Right? So that is uh that is the benefit where you have you have uncertain requirements or unstable

[1:43:27] requirements. Same with the solution. In case of agile, you create a you create an increment and show it to the client. You take the feedback. So if client in the beginning didn't have enough clarity what kind of solution he was looking

[1:43:41] for, he can get that idea because you are quickly developing showing it to the client and then again taking the feedback showing it to the client. feedback showing it to the client. Right? So that is the benefit in case

[1:43:54] where you don't have you have clarity on solution you have clarity on the requirements requirements are fairly uh requirements are fairly stable solution is very clear you don't need that kind of feedback from client. So in that case

[1:44:10] waterfall can be done. Can we not use agile here in four? Yes, you can use agile here as well. But will you get any additional benefits of using agile in

[1:44:22] here? Maybe not. So it's possible that you may not get any additional benefit of using agile in in in this four quadrant number four. But it's not like agile cannot be used, right? Agile comes with its own overheads. A lot of

[1:44:36] meetings are done. You need a lot more time from clients. Client has to spend you know every week, every two weeks they need to spend time. So then it should be some additional benefits. But here that kind of engagement is not even

[1:44:49] required. So uh that is how now some of you asked some organizations are in in kind of a retrace that I want agile in all the projects. I want agile in all the projects. So that is fine. Even in these

[1:45:04] projects you use agile no harm. But ideally waterfall or agile that should be decided on the basis of nature of the project on the basis of these things whether requirements are stable whether uh requirements are not that stable or

[1:45:18] the clarity on the solution etc etc right so that is the first task why it is important I told you because it impacts the way you work okay now here

[1:45:32] uh predictive is plan driven adaptive is changedriven and hybrid a combination of both. But as a business analyst, you should be able to work in both the create both kind of documentation and you should be comfortable with both uh

[1:45:47] engagements, more engagement and less engagement with with the client. So see there is a uh scenario a tax department is upgrading its income tax filing. So let me first do one thing. Let's first close that. Let's discuss

[1:46:04] inputs and outputs. Then we'll go to the scenario. So first let's complete the task. So the input to this is business need right. The business analysis approach is shaped by the problem or opportunity

[1:46:16] necessary to consider what is known about the need at the time of planning. So what exactly is the input? The some idea of the project some idea of the business needs. What is the need? Why we are doing this project? And that is all

[1:46:31] we can have. Right? So far did we perform detail elicitation? No. Right? elicitation. So we don't know what are the exact requirements but we have some idea of the business needs. When you are starting a project

[1:46:46] uh when uh resources are allocated to the project BAS and others are allocated the project BAS and others are allocated to the project that means some bit of Traditionally it was like project managers or sponsors they would have

[1:47:00] would have discussed the business need and it it is also possible that project manager might have already created a business case to take the approval of the funding approval on the funding

[1:47:12] the funding approval on the funding right. So when we start in the beginning mostly you will have some idea of the business need some idea of the requirement and that is why it is considered as the input on the basis of

[1:47:25] considered as the input on the basis of this you decide whether waterfall or agile right as that's what I I told you depending on the project type of the project we should decide now this is again I'll keep repeating this fact

[1:47:38] multiple times see whatever we are learning here is whatever ever is there learning here is whatever ever is there in Babok is pure theory. It's purist approach. Right? However, in projects you will see practical things. You will

[1:47:52] see practical scenarios. You will see pra different problems. Right? Here it's it looks like you know you are going to make that decision along with PM but you approach is there what kind of

[1:48:06] enforcement is there. So you will always have to think whatever we are discussing in two different ways. First what is the pure theoretical uh approach and what then what is the what can be the scenarios in project.

[1:48:20] So depending on the business need you decide what is the approach that is why business need is the only input to this task and nothing else is anyway available. Then we have key elements right planning

[1:48:32] approach will it be productive or adaptive? As we discussed formality and level of detail determine the degree of a structure and documentation required depending on risk level project criticality and regulatory audit. So

[1:48:46] that's what I explained what kind of formal documentation you create. It is dependent mostly on the approach right in waterfall you will have a lot more documentation business analysis activities requirement

[1:49:00] elicitation process modeling all of these things are performed in both but they might have slight variations right in case of waterfall we perform them differently all all of them performed together in the beginning and things

[1:49:13] like that so next point is timing of the analysis work clear so these four things elements are most important part of a task. In key elements, they describe

[1:49:26] what exactly we are doing in this particular task. Okay. And also complexity and risk. Consider the level of complexity and risk associated with the initiative. While you decide the approach, what is the

[1:49:40] complexity or risk of the project? Uncertaintity. If you if if you don't have clarity on the requirement, will that not add the complexity? If you do not not have clarity on the solution, will that not add on the comp

[1:49:54] complexity? That that will add, right? And whatever is the approach, you need stakeholders. They should be informed and they should be happy with the approach, right? Because they need they also need to be engaged.

[1:50:10] After this, you will see some guidelines and tools. Okay. Business analysis, performance assessment. So what I told you that uh uh these things uh guidelines and tools should be considered as additional

[1:50:26] inputs. If they are available, you can use them. If they are not available, then also you can move forward. So because these uh guidelines and tools sometimes they are available, sometimes they are not available. For example,

[1:50:42] business analysis performance assessment. What does that mean? This means nothing but lesson learned. We'll we'll have a diff different task only for this. So you will understand better. But for now consider it lesson learned.

[1:50:56] might have learned from the previous project. So is it mandatory to always have lesson learned? It's not right. Maybe it's first project of that kind.

[1:51:08] So you might you might not even know uh if there are any u you know uh lesson learned available or not. Similarly if there are lessons learned available you [clears throat] similar project I used waterfall or agile or these were the

[1:51:25] lessons which we learned. So in if available if such register is available let's use it. Business policies. If there is any business policy that says we need to use waterfall or we need to use agile then we have to use it right.

[1:51:42] Expert judgment. If there is expertise available who worked on similar projects they can also be provide inputs which approach to be taken in this project. Right? Methodologies and framework available in

[1:51:56] your organization. As I told you, if there are some approaches, some methodologies, frameworks already used and available in your organization and them, then obviously we'll have to take care of that. And a stakeholders can

[1:52:10] also tell you tell you about their concerns, their interest. If you use agile, somebody sometimes it's possible that a stakeholder says I'm not sprint review. I I cannot spend that much time every two weeks. Right? So,

[1:52:23] you need to take a stakeholder into considerations as well. So all these five if you look at them they don't they don't look mandatory inputs right if available you will use them if not available that's fine you

[1:52:37] will take the make the decision without them. So there are some questions. Let's them. So there are some questions. Let's go through them. There is a scenario. A global healthcare provider is planning to implement a new

[1:52:49] digital system to manage patient data across its network of hospitals. The system must meet a strict regulatory and compliance standards. Adherence to HIPPA

[1:53:01] privacy laws, support for external securities, audits, usability for a multilingual workforce and patient base. The project involves coordination between different teams. The goal is to ensure accurate

[1:53:15] documentation, data privacy and user-friendly experience for diverse stakeholders. Given the regulatory and compliance needs, what type of business analysis approach productive, adaptive or hybrid, would you choose for this

[1:53:28] or hybrid, would you choose for this project? So this is the scenario and see project? So this is the scenario and see the question itself wants us to say it's productive, right? Because it they're trying to emphasize that it's regulatory

[1:53:43] and a lot of accurate documentation is required. I think most of you would agree that it's productive given the given the situation given the scenario in the question right if you have a question like this it's like the answer

[1:53:56] cannot be just one hard and fast rule right depending on your project your industry we can decide considering the the the project which is mentioned here the the project which is mentioned here it's regulatory heavy documentation

[1:54:09] and in this question it's not mentioned that you know you have to hit and try and identify these solution you might have to do a lot of PC's or uh spikes so

[1:54:22] we need to answer accordingly what what information is available on in the question according to that we need to answer so given the information the answer seems to be predictive if we if they talk about you know multiple

[1:54:36] iterations required where you will users are not very clear on the requirements or users are not very clear on the solutions you might have to do some uh PC's etc. Then obviously you'll have to go with uh agile right or adaptive. Next

[1:54:52] question. You are working on a national level transportation system initiative due to high criticality and government oversight. The documentation must be extensive and traceability is a must. Which planning element will help you

[1:55:06] level required? It is a right. That's depending on the planning approach, rest of the things will be tailored accordingly. Next, you are leading a BA effort for a low-risk internal HR

[1:55:21] dashboard where stakeholders are colloccated and feedback is continuous. The team follows agile sprints. What level of formality and documentation is mentioned that stakeholders are coll-located,

[1:55:37] coll-located, right? Uh they are following agile And it's a very lowrisk internal HR dashboard. Right? So there is no regulatory oversight. There is no audit requirement mentioned there. So correct

[1:55:51] answer is informal with lightweight documentation. If it would be for external clients maybe regulatory clients or if there is a formal audit it would be different but because it's internal and also stakeholders are

[1:56:07] colllocated right? If a stakeholders are not coll-located in that case they might need different kind of reporting u they might need different kind of you know arrangement where they get the status of the project but in this case they are

[1:56:19] colloccated so minimum documentation would be enough. So that was the first task. Now second one is plan stakeholder engagement. Now tell me who are our stakeholders? Everyone who is impacted

[1:56:32] by the project and everyone who can impact the project. They all are all are impact the project. They all are all are our stakeholders, right? So why do you need to engage with them? First of all, you need to elicit the requirements. You

[1:56:46] need to know uh who can give you the requirements, right? project, external projects, you can have different stakeholders. So who will give you the needs? Who will share with you the problem statements or the needs?

[1:57:01] That is the first task, first aspect, right? But how do you identify your stakeholder? So practically think about a project. Let's say there is a new project uh and your project manager calls you

[1:57:18] and tells you that you know that this is a new project and you need to start working as a business analyst. So you just mentioned that in order to elicit the requirements you need to know these stakeholders, you need to engage with

[1:57:33] them. But you can engage when you know who are your stakeholders. So consider in this scenario how will you start your activity? How will you identify your stakeholders? See there cannot be one single answer to this. Right? There can

[1:57:48] be multiple things that you may perform parallelly to try to understand to try to identify your stakeholders. But what are those things? If you are thinking try. I believe it should be responsibility of PM to provide the list

[1:58:03] of stakeholders through organizational modeling. Uh stakeholder engagement is required to get accurate requirements. It should be responsibility of PM. But it's not like he is the only person responsible for a stakeholder

[1:58:16] engagement. Right? business analyst and PM they both engage with the stakeholders and uh it's possible that PM is engaging with some of them and you PM is engaging with some of them and you know because he needs to engage only for

[1:58:30] few things like risk resourcing budget costing and budget but it's possible that for requirements you may need to engage with more stakeholders right who engage with more stakeholders right who are actual users of the system So

[1:58:46] are actual users of the system So PM can help PM can help you to kickstart but we can't say that he is responsible to give us the list of complete list of all these stakeholders that is that is not the right thing. So what else you

[1:59:00] can do so that is fine that first PM called you. So it's possible that PM would have already created let's say a business case when he got to know about the project first he he would have created some documentation so that he

[1:59:17] can present it to the sponsor and can get the funding approved right most of the rest of the project team members like developers testers and sometimes BAS they get onboarded when project is approved so project is approved that

[1:59:31] means there would be some documentation available there would be some discussion done by the PM or by the sponsor. So first question is always to ask PM himself that okay you are assigning me this project who are the stakeholders

[1:59:44] that you are already aware of right so first thing is fine he may give you some first thing is fine he may give you some names and then that can be a good start second as Dina said you can use organizational modeling now what what is

[1:59:56] organizational modeling where you have the hierarchy in most of the bigger companies will have organizational hierarchy and that can be looked that in

[2:00:08] in your office you know company's portal or maybe in some other documentation but that will give you the complete hierarchy from CEO till senior management then junior management then all the everyone right so from top till

[2:00:23] all the everyone right so from top till leaf node from top to bottom the entire hierarchy is available in organizational modeling so how it will help let's say in the previous example we saw that the project was related to HR so it can give

[2:00:36] you some idea that you know if this project is related to HR then these are the people who are in the HR department so I can reach out to the to a team lead or let's say head of HR if I want to uh you know understand what is the impact

[2:00:50] on them or what are the requirements so that is the second point which is good these are two important uh inputs first from the PM second from let's say organizational model what else we can do if there is any other existing document

[2:01:04] that you can also read in most of the documents. If you talk about BRD, FRD, business case, project charter, all of those documents generally have two sets

[2:01:16] of people. There are two lists which are mostly there in the beginning of the mostly there in the beginning of the document. First list of approvers. So if there is any existing document you can read related to your project, you can

[2:01:29] get the idea who are the approvers and approvers are key stakeholders, right? Similarly, there is a distribution list that even though these people will not approve the document, they will get a copy of this document. So, they are also

[2:01:43] your stakeholders. So, if there is any existing documentation available, which may not be the case in all the projects, but if it is available, you can always but if it is available, you can always take help. Similarly, if there are

[2:01:57] take help. Similarly, if there are multiple vendors, uh multiple different parties involved in the project, you will also find a lot of contractual documentation, right? Agreements which are done with between a company and a

[2:02:10] vendor. So there also you can get some idea of the stakeholders. What else? I said existing documentation. Navin if the sometimes it's like project similar project was done or this is the phase two of the project phase one was already

[2:02:24] done in that case you will get a list you might get a list from uh from you might get a list from uh from previous document what else you can also try to find out if there are any let's say process documentation what is a

[2:02:38] process work process documentation like workflows or any other UML modeling etc where you You can get the idea that you know in this process these are the

[2:02:50] people who are involved right these are the people who are involved in this process these are the departments which are involved in this process so that can also give you a good idea all of these things can be used

[2:03:03] when they are available right that's why I said there is no hard and fast fixed list of you know items step by step that you do them and you will get list of stakeholders depending on your situation we have to try all of them. What else?

[2:03:19] Now let's say I have only two stakeholders identify like in my current project that is what is going on. I'm in the initial phase. So let's say I set up a call. I set up a meeting with the known stakeholder. I'll always mention

[2:03:33] that please feel free to forward this invite to anyone who can be helpful in this discussion. Right? So I provide the introduction of the project. This is what the purpose of this particular meeting. And if you think that somebody

[2:03:46] else can be useful then please forward them after the meeting within the within that meeting also you keep asking this thing right who else can help who else can help who else should I reach out to

[2:04:00] can help who else should I reach out to so that is also uh important right and will keep identifying more and more stakeholders when you keep asking people so that is also important what else can you think of anything else which can

[2:04:14] identification. If you miss the stakeholder, what is the problem? We generally say unidentified stakeholders means unidentified requirements. Later on there can be requirements which are

[2:04:27] which you are able to identify late in the project because those stakeholders were not identified. So it's very very possible that you will miss out on the requirements because you couldn't identify all the stakeholders and why it

[2:04:40] is important we already know that. See first of all when when when I say a first of all when when when I say a project a project is not just building application right project there is a term called system thinking like think

[2:04:54] term called system thinking like think about a system consists of people processes applications everything so if you are creating a new application it doesn't mean it will have only software related impact because that application

[2:05:07] is going to be used by stakeholders so people are get people are also impacted Sometimes you automate existing manual task people get impacted right so it's task people get impacted right so it's always not just systems but people

[2:05:22] processes everything so it's that is why it's important to identify that all these stakeholders so it is the second task in this knowledge area right it answers the questions who are these stakeholders what are their expectations

[2:05:37] how should we interact with them to ensure success Right. So first part of this is there are two inputs needs where exactly needs are coming from the same needs which we identified and used in

[2:05:52] the first task. And now you see the additional input is business analysis approach. Where exactly we are getting this input from? exactly we are getting this input from? Business analysis approach. This input

[2:06:05] where exactly we are getting from from the first task. Now you tell me why this the first task. Now you tell me why this is important. Why the approach is important as an input because what exactly we're talking about we are

[2:06:19] planning our stakeholder engagement how you will engage with the stakeholders how you will communicate with them etc etc and what I explained that the engagement approach is different in waterfall and agile so don't you think

[2:06:33] it's a very important input why business analysis approach is the input to plan stakeholder engagement uh when If you were a kid, you must be listening to bedtime stories from your mom, from your grandmom, maybe your father,

[2:06:46] grandfather. All of us, most of us would have listened to bedtime stories, right? have listened to bedtime stories, right? So the same was the case. My grandmother used to tell me bedtime stories. But she would also say one thing that you know

[2:07:00] would also say one thing that you know keep saying h yes yes something no so that I know that you are still awake and listening to the story otherwise I would never know you know I'm whether you you you are you you are already sleeping and

[2:07:14] I'm talking to a wall so that is the case here as well right that is uh the input now again similar to the first output of the first task this output will also be used in mult multiple different tasks. Let's see few of them.

[2:07:30] Uh for example, prepare for elicitation. Task number four. Do you think a stakeholder engagement approach is required when you prepare for Yes. Because when you prepare for elicitation, you will set up send out

[2:07:44] elicitation, you will set up send out meetings sorry uh meeting invites, you will prepare for workshops, for brainstorming sessions. So whenever you do that you would need your stakeholders and when you are planning these sessions

[2:07:57] you will think about what is the stakeholder engagement approach right similarly if you see communicate 4.4 communicate business analysis information who exactly you will communicate this information to to

[2:08:10] stakeholders. So again a stakeholder engagement approach is a very valid input to this particular task. So you can see all nine and you will be able to can see all nine and you will be able to realize why this input makes sense

[2:08:23] realize why this input makes sense right. So these are the two input and guidelines and tools business analysis performance assessment change strategy and current state description. Why do you think business analysis performance

[2:08:39] assessment is important? Because this is the lesson learned. So from your project whatever you learned can give you the inputs here right it's very simple but what is change strategy change strategy tells you what is your

[2:08:54] in order to move from your current state to future state you are going through a change this is called change now depending on this change depending on the strategy of this change you can identify stakeholders Right?

[2:09:15] different house and you need packers and movers. So you know the they become your stakeholder. If you're moving within the same building, they are not your So change strategy will also tell like if I'm migrating one application to a

[2:09:30] new application depending on the depending on that migration right it will tell you who can be your stakeholder. If I'm migrating let's say to one of my legacy application to AWS

[2:09:44] you know that people who are or the team who is taking care of AWS infrastructure they will become my stakeholder otherwise they are not my stakeholder right so change strategy now why it is optional because maybe you are in the

[2:09:57] beginning of the project and you don't have idea of the change strategy so that is why it is given as if available use it right and same is current state description what is current description existing let's say existing flow

[2:10:12] diagrams what what do they tell you how as of now at present how different process are working right that is what is current state description how things operate as of now how data is flowing as of now how

[2:10:29] UI is communicating to the back end as of now so if you have documentation of now so if you have documentation available on current state it will tell you who are the teams or people involved in these

[2:10:43] processes like when I create flow diagram let's say this is the start it is moving to this then here you are performing a task here you are performing a task and generally sometimes in your process flow diagrams

[2:10:56] you can also create swim lanes and on swim lanes on top of swim lanes we'll go through process diagrams in detail you can write that this is HR function so performed by the HR. This is performed the HR and then it goes back to let's

[2:11:11] say this uh let's say this is finance. Okay. So when you look at the current state description that can also give you a good idea who are your stakeholders.

[2:11:26] So that is why that is also given as additional input. Right? So make sense all these three guidelines and tools as additional inputs. They are making sense if available they can help you in your stakeholder engagement state stakeholder

[2:11:40] identification right now why it is required obviously foster collaboration reduce resistance align stakeholder goals with initiative outcomes and ensure timely and accurate communication. So if you uh we know that

[2:11:54] project cannot be delivered in isolation, right? You have so many people who are impacted. You have so many people who can impact your project. You need developers, you need testers, you need u uh operations team and you

[2:12:08] need ultimate your end clients, right? Otherwise how how can you deliver the Otherwise how how can you deliver the project? So stakeholder engagement is important. Right? Now if you don't talk to them, it may become difficult. First

[2:12:22] difficulty is unidentified requirements. Second, if you do not communicate to Second, if you do not communicate to them, they will never know um what is the impact on them. What is the meaning of two I and four I check maker and

[2:12:36] of two I and four I check maker and checker. So generally you say you see you call it four eyes check that one person will do something whether creating a case raising a ticket whatever some task that one person will

[2:12:52] do second person will check it. So it's not like the same person can create a case approve it and everything. No. Right. From the process point of view many regul regul from the regulatory point of view from the legal point of

[2:13:07] point of view from the legal point of view in many of the cases it's mandatorily required that maker and checker are two different person sometimes in my projects I have seen six eyes

[2:13:20] six where somebody was the maker this person was just validating or checking and then approver was a different person. So we had three different people working on one thing. Now what happened when I we wanted to make some change in

[2:13:38] the process, right? So let's say there was uh onboarding team. So what is the what does that mean that

[2:13:50] if you want to open a new account in any of the bank onboarding team will collect of the bank onboarding team will collect your documents validate them uh perform your background check your KYC etc and then they'll open your account right so

[2:14:04] earlier if this is the person who will collect my document he was able to perform everything I'm talking about 2012 13 but then there was one heard all of you might have heard of fatka these days It's mandatory even all

[2:14:19] Indian banks when you fill up the form you have to disclose you have to disclose whether you are US citizen or not. So uh when you fill up this form it was mandatory that the same person cannot

[2:14:33] approve the onboarding case. We so regulatory requirement was up to four I check but what did we do? We thought why four eyes let's implement six eyes check right. So we went ahead and implemented this. when we started discussing uh

[2:14:48] after this uh when we went ahead and discussed with operations that uh they started showing a lot of resistance because initially they were not very much engaged what they thought that you know let's say there is a

[2:15:03] that you know let's say there is a person sham you started telling me that you know girl till yesterday I was my own boss I was creating the case I was also approving the case right how How come you became my boss? Now what you

[2:15:19] are saying that whatever I'll do there will be a another person team lead or somebody who will make uh who will validate my case and there will be another person who will approve the case. So people started resisting

[2:15:32] because they didn't have the full background and full understanding. So initially they misunderstood it and they started some resistance. started some resistance. Then we had to conduct couple of users

[2:15:45] training and we had to explain that it's not like that you know all your cases will be approved by somebody. It is like if you are your case is getting approved by second person then second person's case will be approved by you right only

[2:16:00] your manager the entire man manager of the whole team they he will approve but maker and checker you can be a maker and you can you can be a checker when we explain the regulatory requirements and the purpose of this overall

[2:16:13] implementation then they understood and you will see that you will find it and you will face it multiple times whenever Ever your stakeholders are not fully engaged. They are not fully aware of the change. What are the benefits?

[2:16:29] What are the implications on them because of this change? You will always face resistance when you when you perform and why it is important for you as a business analyst because you are the one who will talk a lot to those

[2:16:42] people, right? Developer or tester is not going to go and explain them what why why we are implementing this, what is the purpose of this change. So it will be you all the time who will face these stakeholders along sometimes your

[2:16:55] project manager right so that's why it's important to engage now when we decided the approach whether it's adaptive or predictive it's our job to go and discuss with stakeholders that you know we are following waterfall or agile and

[2:17:10] what kind of engagement is required from your side okay so that they are also uh align with with you as with your project approach and the overall purpose of the

[2:17:23] approach and the overall purpose of the project. Okay. Um what else you need from stakeholders? You need there time commitment and resource commitment. Uh key elements perform stakeholder

[2:17:39] analysis define a stakeholder collaboration. I'll just explain this and stakeholder communication needs. So first is perform a stakeholder analysis. The first step

[2:17:53] uh in this is identify right. First you need to identify the stakeholder who will be directly and directly impacted and their characteristics as well as analyzing the information once collected performed repeatedly as business

[2:18:06] analysis activities continue. Right? So as I said you will continue to ask who else can be impacted who else uh can you know give you more information so that it has to be performed periodically or repeatedly also it's possible that the

[2:18:22] with that person left the organization somebody else has joined right so that is also you need to be careful that you know you are checking your stakeholder if you created a register or list you are keeping it updated all the time. So

[2:18:37] how do you identify? We discussed there are different ways which you have to try right and you have to keep trying uh so that you can identify more and more stakeholders. So that is the first part uh uh identify

[2:18:52] and analyze your stakeholder. No. So one more thing is you can document it in different ways. First is simply creating a stakeholder list. Right? you call it a stakeholder list or a stakeholder register. Second uh

[2:19:08] a stakeholder register. Second uh another way is to create let's say uh a matrix

[2:19:24] let's say authority of the stakeholder and interest of the stakeholder. stakeholder in these four categories. A person who has very high interest in

[2:19:38] person who has very high interest in your project and he has a he is a very senior person with uh you know a strong authority in your organization. You know that these people you have to manage very very carefully. You will have to

[2:19:51] take care of their know communication needs. what kind of communication they needs. what kind of communication they expect from you all that you have to you know you have to be very careful these people they are okay I mean you have to

[2:20:03] engage with them but you don't have to be on your toes all the time right so now you can create any such any any such you know uh gra what you say u metrics

[2:20:15] and you can have authority or you can have engagement have engagement you can have interest or uh uh uh something else. So you can create this on the basis of any two uh parameters

[2:20:29] that you want to use. Authority and interest in the project uh engagement uh interest in the project uh engagement uh break uh and uh interest also u couple of more points that we can add. [clears throat] Just one thing that we

[2:20:44] need to be careful that you should not end up adding this particular you know matrix in your project document or on your shareepoint project document or on your shareepoint where everyone can see right because

[2:20:57] what will happen this is not like if a stakeholder ends up finding himself here you know he say what do you think I I don't have any authority in the project right so this is slightly political so generally I do not create any such

[2:21:13] matrix in my formal project documents. If I want to create, I'll create it in my personal drive or in my personal spreadsheet and keep it in my personal uh uh computer, not as a shared project document. A stakeholder list. One more

[2:21:27] document that you one more diagram that you can create is called onion diagram, different layers similar to what we have onion. Onion has multiple layers right.

[2:21:44] onion. Onion has multiple layers right. So this is your internal project team. you can say this is the impacted department of the organization.

[2:21:59] department of the organization. Impacted department. Then this is your organization and every anything that is outside is external. anything that is outside is external. Right? So this diagram can be created

[2:22:14] just to mainly to identify who are your stakeholders internal, external etc. Right? And this is also dependent on where exactly is the boundary. If I ask you who are your internal stakeholder and who are your external stakeholder

[2:22:29] the first question that you should ask where exactly is the boundary right by internal if you mean people who are part of the project then my boundary is here of the project then my boundary is here right but if you mean by by that if you

[2:22:42] mean that people who are internal to the organization that the boundary is here projects you are working for external clients but in some of the projects you are working for internal clients like I part of technology but I'm working and

[2:22:55] creating something for HR department. So who are my client? HR. So in that case if you say that people who are outside my organization are external. In this case then there is no external uh stakeholder right? HR is part of the

[2:23:08] same organization. So internal and external depends where exactly is the boundary. But I hope you understood the purpose of onion diagram. You can have two layers, three layers or four layers depending on the need and you can create

[2:23:20] such a diagram. Okay. So this is for the stakeholder identification and documentation of those stakeholders as a list, as a those stakeholders as a list, as a matrix, as a diagram or sometimes we

[2:23:33] also create one more thing that is called persona. What is a persona? So basically persona is a fictitious character, right? uh just think of a project where uh like

[2:23:50] you are building any application where you can directly talk to the customer directly you can talk to the customer like for example you are building the software for for your HR team you can directly talk to the HR and get their

[2:24:04] requirements but think about any bigger systems like Facebook or any other such systems where there are so many millions of users etc and you cannot possibly take the requirements right so how will you then create application where you

[2:24:20] cannot directly take the requirements in such cases persona can be very helpful such cases persona can be very helpful so you in in if I simplify it it's like you try to put yourself in the shoe of your user and try to imagine try to find

[2:24:36] out what kind of requirements that user would have with your system right what kind of usage that person would have with the system. So it's imaginary imaginary or fictitious character. You will still assign assign him or her a

[2:24:51] will still assign assign him or her a name and you will try to understand um uh you will put the demographic data to that person. Let's say age, gender, uh education and whether that person is working or non- workinging. Maybe the

[2:25:06] whether he's living in a city or in a town etc etc. And then you will try to understand what kind of use case that person would have with the system. person would have with the system. Right? So in such cases because you

[2:25:19] cannot take directly requirement from the user, you can still try to identify the requirements. So for example, let's say you are there is a requirement that uh simply learns to build a new learning

[2:25:33] uh simply learns to build a new learning management platform. Okay. In this management platform. Okay. In this learning management uh uh platform who are the stakeholders? Who are basically who are these stakeholder? If Simply

[2:25:45] Learn is planning to build a new learning management system, who all can be the stakeholders? Students, trainers, training technical team, trainers, learners, yes, simply learn management, faculty, admin team, all of them are

[2:25:59] faculty, admin team, all of them are these stakeholders. Now think about these stakeholders. Now think about a situation where as a trainer I it's a situation where as a trainer I it's possible that I can have uh uh some

[2:26:12] requirements uh just for uh just uh as a trainer right and you can also have as learners you can have your own requirements and uh for example I I can have a requirement that says I want a feature

[2:26:28] uh I want to upload additional documents on LM MS so that I can share them with the learners right very simple instead of you know sharing the Google drive etc if I could possibly upload all the additional documentation on the LMS so

[2:26:42] that learners can download do you think it's a valid requirement for for a it's a valid requirement for for a trainer yes it is similarly uh as a requirements that I should be able to see my attendance on the platform I

[2:26:57] should be able to download the recorded sessions from the platform form I should material that trainer has shared from the platform. Right? All those requirements you can have. Now imagine that there is a uh there is a girl uh

[2:27:14] she also wants to attend some classes from simply learn but she knows that the network in her she's from a small town maybe a village and the network is

[2:27:27] always patchy in that village. So attending live classes may be very I interruptions when she's attending live classes. Now if you think about her as a

[2:27:39] persona what kind of requirements you can think of that we would like to add in simple learns LMS. As soon as you identified a persona of a person who is

[2:27:51] living in a remote village with patchy internet connection immediately you identified a requirement which is about recorded sessions right. It can be useful for people who are living in city and you know missing the session but at

[2:28:05] the same time that gives you a good idea right what kind of requirement she might right what kind of requirement she might have right. So that is the use of persona from the requirement classification schema from the Babok

[2:28:19] point of view. They are divided as business requirements,

[2:28:32] Okay. Then we have solution requirements and non-functional and then you have transition requirement

[2:28:48] business requirements and now and you can also see here why Simple would launch a project like this maybe like uh Ala mentioned that they want to increase Ala mentioned that they want to increase the enrollment by 30% so that they can

[2:29:01] get the uh you know more revenue. That is the business a very valid business requirement where company wants to increase the revenue and in order to increase the revenue they will have to

[2:29:14] uh increase the number of students number of enrollment and in order to do that they will have maybe more efficient system and a system which is more user system and a system which is more user friendly etc etc. So that is fine. Now

[2:29:27] when you talk about stakeholders like I told you as a trainer I want to upload additional documents that that's a very valid stakeholder requirement as a trainer I am also a stakeholder as a student as a learner you can also have

[2:29:41] student as a learner you can also have your own requirements right so the only point is that uh your stakeholder requirements should be aligned to the business requirement right we are talking about adding more revenue in

[2:29:59] gaining or getting more revenue. So if purpose is to have you know better c better user experience so that more enrollment etc etc your stakeholder with the functional requirement nonfunctional requirement basically all

[2:30:15] your low-level requirement should be aligned with the high level objective high level organizational requirements or high level business requirements. So what can be functional and non-functional requirements? So uh like

[2:30:30] Allah mentioned the platform must allow users to pay using UPI cards and net banking. These are functional requirements. The system should support 10,000 concurrent users without slowing down. That is non-functional. So what is

[2:30:42] non-functional? Functional requirements are the features functionalities of the system, right? and non-functional requirements are

[2:30:54] about performance, security, uh compatibility. So sometimes people get confused but you should ask a very basic question, right? Uh let's say I I I give you a requirement that this

[2:31:10] particular website should I I should be able to open this particular website in able to open this particular website in Chrome, Mosul, Internet Explorer. Now in this requirement am I talking about what website would do? What exactly is

[2:31:25] available on that website? Am I talking about any functionalities and features about any functionalities and features of of that website? No. Right? So then because functionalities are not discussed in this requirement.

[2:31:39] Similarly, if I tell you that if I open your application, the application that you're building, if I open it in India, it should open by default, it should it should open by default, it should open in Hindi. If I open it in the in

[2:31:51] the United United States, it should translate to English and if it is in let's say uh uh Italy, it should be in Italian and things like that. Again I am the website? How the user should login? What are the security? What are the uh

[2:32:08] you know what is required to login into the system? Nothing. I'm simply talking browsers. So that is a non-functional requirement. If I tell you that

[2:32:20] um concurrent users as he mentioned right uh right now let's say this zoom platform would allow 100 users but I want more revenue. I want more people to join my classes. So I want 200 people to join at a time. Again, this is a

[2:32:35] non-functional requirement. Okay. So I hope you're clear about the distinction between functional and non-functional. Nobody is saying that functional requirements are more important than non-functional. It's not the case. It's

[2:32:48] non-functional. It's not the case. It's just the theor theorical you know segregation or classification. It doesn't mean that one type of requirements are more important or more critical than other. For example, if you

[2:33:02] talk about a printer, right? A printer should be able to print uh white uh sorry colored and black and white uh pages. That is fine. Uh functional requirement. Uh I a printer should be able to print 20 pages per minute or 50

[2:33:17] non-functional requirement. But in case of printer that can be one of the most important requirement, right? the speed of the printer, performance of the printer that is one of the most important requirements. So never think

[2:33:30] important or non-functional are more important. They both are important. Sometimes a functional can be higher priority than non-functional or vice versa. Now somebody tell me what is the transition requirement? So we always say

[2:33:44] that transition requirements are temporary requirements. Once the system temporary requirements. Once the system is live, once you reach to the uh target state or your future state, they these requirements cease to exist. They don't

[2:33:58] exist after the after the uh transition, after the change. Basically, they are temporary requirements. Like for example, we were talking about shifting our house and we were talking about packers and movers. Do you think packers

[2:34:12] and movers you need one time or you will keep needing them again and again? Once your house is shifted, once your household items are shifted, you don't need them. So that requirement is one-time requirement. That requirement

[2:34:26] is transition requirement required only for the transition. Right? When you move from existing platform like LMS to new LMS, you migrate the existing data of uh data of existing students, that migration is

[2:34:40] required one time. It's not you will continue to migrate it on daily basis. continue to migrate it on daily basis. Similarly, if I launch a new software, I need to train the users. Now, that training is required once, right? Uh and

[2:34:54] that is why training is also a transition requirement. So, this is how you need to identify transition requirements. One-time requirements required only for the transition period only for that change period, not all the

[2:35:07] time. Functional nonfunctional requirement will remain there as long as you will use that system. Those requirements will remain with the system. Right? Now depending on the approach, you will have to define the

[2:35:20] collaboration. Right? Stakeholder collaboration is planned to ensure ongoing engagement in business analysis activities. Approach may vary by stakeholder type and activity. Key cons consideration include timing. See now

[2:35:32] your approach is important. What how much time you need stakeholders uh from stakeholders. In case of agile, you need four to six hours every two weeks for sprint for a sprint review maybe for requirement grooming uh sessions and uh

[2:35:50] in case of waterfall that is different. So it's not like you can decide in isolation right that's where you need inputs from a stakeholder whether they inputs from a stakeholder whether they have that kind of time or not.

[2:36:03] Second is stakeholders communication needs. All stakeholders can have different type of communication needs. For example, your project >> uh sponsor, he or she cannot attend all the status meetings every week. So you

[2:36:18] might have to set up separate 30 minutes just with your sponsor where you can walk her through the project status, project progress and in case there are project progress and in case there are any problems, right? With tech teams,

[2:36:31] you might need a different meeting. So point here is you need to identify what type of meetings what type of what type of communication your stakeholders need whether written or verbal. So generally in all the projects I would create a

[2:36:46] communication plan where the it's not like it's not a complicated something it's very simple I'll have on one side I'll have list of stakeholders on the other side I will have what kind of communication they want. So for example,

[2:37:00] communication they want. So for example, I'll send a weekly status email, right? I'll decide who all will receive this. I'll run one weekly workshop with all the technical teams who are impacted. And in this case, I'll I'll request only

[2:37:17] technology teams, application teams to join this. There can be one weekly meeting with uh with with business stakeholders where we'll have just business, right? and maybe you can have one fortnightly meeting with everyone

[2:37:31] and things like that. So this is my communication plan who will tell me how much how what kind of communication they need. stakeholders what kind of communication they are expecting from the project. In

[2:37:46] case of agile some of these things are automatically decided if you're using a scrum right you already have those meetings which you need to run and stakeholders need to join those meetings clear so if I ask you to create a

[2:38:00] stakeholder communication plan can you create it or do you think it's very difficult it's very simple right list of stakeholders different ways of communication and the frequency I say status email a status email all these

[2:38:13] stakeholders will receive frequencies is month let's say weekly the full stakeholder connect let's say frequencies fortnightly all these stakeholders uh you can have a steering steering

[2:38:27] committee steer co you can have planning meeting and things like that right so all that is just two-dimensional data that we need to put on a data that we need to put on a spreadsheet and create plan

[2:38:40] right very simple and different stakeholders customers we discussed yesterday who are your customers, who are your end users, who are the suppliers provide products or services that may influence or support the

[2:38:53] stakeholder engagement plan. So supplier can be of different types, right? They are providing you material, they are providing you software or maybe they are providing you human resources as well as well. Many time there are companies

[2:39:07] typical IT tech companies who are in body shopping also, right? So I need Java [clears throat] developers. I can re reach out to them and they can help me with 20 developers. Right? So different kind of suppliers, vendors are

[2:39:20] different kind of suppliers, vendors are there. Regulators. Who is the reging regulator in India? RBI. Right? Who is the regulator for uh uh capital market in India? SB. M is for mutual funds. For insurance, it's IRDA.

[2:39:37] So these are the regulators, right? They will have a lot of requirements, lot of constraints on your requirements and that is why they become one of the key regulators especially on the on such projects where you have some regulatory

[2:39:49] uh requirements. A sponsor the person who is who has authority on the funding. A person who is providing the funding to the project that is the sponsor. Project manager with no domain subject matter expert

[2:40:04] technical subject matter expert architects they all are different architects they all are different technical people who and domain subject matter expert is a person who has that domain knowledge. Do you think uh

[2:40:17] BA needs to have domain expertise? Theoretically BA can be domain agnostic right theoretically. Why? Because do you think BA is going to create requirements

[2:40:30] or BA is going to elicit requirements? BA is not going to create requirements BA is not going to create requirements himself. Right? So if BA is very good, he can ask right questions. He can use all the techniques. He can create

[2:40:43] questionnaire. He can run workshops. He can do brainstorming sessions. Then he needs he can elicit the requirements from the users. Right? So in a ideal world he he can do without having any domain expertise and that is correct

[2:41:01] domain expertise and that is correct also. But when we talk about you know practical things most of the companies most of the managers would expect that BA comes with some domain expertise. So that you know there is no learning

[2:41:14] curve. A person who I I hired today should start performing tomorrow. So practically uh all the job descriptions all the JDs on LinkedIn or other uh job platforms they would expect a person with domain background right but in in

[2:41:29] with domain background right but in in an ideal world BA can do without domain expertise. Let's start with the third third task of the first knowledge area. Now this is about plan business analysis governance. So when we say governance

[2:41:44] what do you mean by governance? Do you know what exactly do we do when we say I'm governing the project or there are project governance activities? What what do what do we mean by that project governance or overall business analysis

[2:41:59] uh governance? What do you think is the meaning? controls keeping track of all the activity monitoring and sharing the feedback. So the most important thing uh from the project point of view is how do we take

[2:42:16] the approvals who exactly who all will provide the approvals who have that authority to provide the approval right and uh in case of escalations who need to be reached out to that is also part of governance. So approval escalations

[2:42:32] uh uh the the distribution of the documents and uh authority from project decision-m point of view as well as budget point of view. So and your

[2:42:46] escalation metrics of the project. So these are the things which are part of the business analysis governance. Now why do you need to identify this? Because in your project governance is required and every project governance is

[2:42:59] required. So again the same question it's it's uh your business analysis governance should be subset of project governance right. It cannot be like in project you have some some stakeholders which are identified and your in uh um

[2:43:16] which are identified and your in uh um in BA uh in business analysis governance you are asking for somebody else right that is that will not happen. So you that is that will not happen. So you whenever we talk about any plan any uh

[2:43:28] any governance approach or any other plan for example communication plan etc uh your business analysis plan will be subset of overall project plan in all the cases without any exception right so that is first thing that what all is

[2:43:45] considered under governance what all will fall under governance why we need to identify because project will not be able to will not be able to execute ute the project without governance because there are so many steps, there are so

[2:43:58] many stages in the project where you need clarity on governance. For example, requirements are captured, requirements are documented. Now you need to take the sign off on the documents. Somebody should approve the documents, right? You

[2:44:13] need to know who is that person and that is part of project governance. Uh who is going to provide the approvals let's say on the design? In this case it may not be business stakeholder but at architect if in your organization there is a

[2:44:29] architecture review board in most of the bigger organization you will have ARB where every project will present their design their architecture uh and ARB board will have senior architects and they'll approve your uh your design uh

[2:44:43] they'll approve your uh your design uh in the project right similarly the test test cases test results who will provide the approval who will take the who will take the review session and provide the approval. So there are many stages in

[2:44:56] type of approvals from your stakeholders tech and business both same in case of escalations who they need to reach out to you. It's simple right like when you are out of office you leave that message

[2:45:09] right out of office message which tells you which tells everyone who is sending your email that say I'm on planned leave on from this date to this date in my absence please reach out to these people and for any escalation reach out to my

[2:45:22] boss and you provide their email ids or phone numbers that is part of the governance it's your responsibility or everyone's responsibility that if you are away set a proper out of office message so that people can reach out to

[2:45:34] the respect respective respective people who you mentioned in your out of office reply. These are the important uh points and also budget approvals. Who has the authority to approve the budget? Who has the authority to deal with escalations?

[2:45:49] Right? Most of the times escalations or conflict most of the time the sponsor of the project would have ultimate authority and sometimes depending on the requirements maybe somebody from the business side would have authority and

[2:46:02] business side would have authority and it depends on the project u uh approach if it is let's say agile in that case product owner would have authority on the product backlog. So every requirement everything that is part of

[2:46:15] the backlog he will have final authority obviously obviously he will take inputs from different stakeholders but product owner owns the backlog. What goes into that backlog what goes out of that backlog the prioritization of the

[2:46:30] backlog all of those things are the authority or the responsibility of the product owner. Right? So business analysts play a key role in establishing and maintaining a

[2:46:44] governance process ensuring uncertain uh ensuring that any uncertain ensuring that any uncertain uncertaintities within it are addressed. Now do you think we need to inform a stakeholder about the governance

[2:46:58] whatever approach that that you are taking whatever governance you are setting up do you think a stakeholder needs to be informed about it? Yes. Right. So that is why it is mentioned here. You make the decisions

[2:47:10] you need to inform. There is one more important aspect of governance that is called change control. How the changes will be controlled in the project. How the changes change requests will be managed in the project. earlier I think

[2:47:24] nowadays it's not that strict but earlier when I I was starting my career and until I think 10 years back especially in the in the traditional especially in the in the traditional waterfall project there used to be this

[2:47:38] waterfall project there used to be this change control board CCB do you understand what is the meaning of baselining baselining is current status so you can baseline your budget

[2:47:53] You can baseline a scope and timelines also and requirements everything. So basically it is like something is going

[2:48:06] on and I have created I have taken a snapshot that you know this is the version of the document. This is the version of the requirements or this is version of the requirements or this is let's say 1 million USD is the budget or

[2:48:20] let's say 6 months is the baseline timeline required for this project. After that everything will be considered as a change. So baselining is like a snapshot taken and considered as this is the final one and afterwards everything

[2:48:33] will be considered as change request. So earlier if there is a requirement change right uh I will tell all my stakeholders that there is a particular template in

[2:48:45] this template you have to fill certain details like uh what is the change why this change is requested what are the benefits of this change who is the requesttor is there any impact on other aspects of the project so you'll have to

[2:48:59] fill all these fields and you have to send this to a particular ular email id. You are not supposed to send this to me individually. There is a change uh there

[2:49:12] individually. There is a change uh there is a CCB email id created. You have to send this completed form to this email id only. Right? If this form is not submitted properly will not consider your change request. If this is not sent

[2:49:24] your change request. If this is not sent to uh a particular email id, this will not be considered. So the process was very strict. Now there will be people in this CCB maybe project manager, business analyst, somebody from the business side

[2:49:38] or other stakeholders who are important. They'll be part of the CCB. Here they need to attend the meeting. CCB will run monthly or bimonthly meeting where people will join and they'll explain this why their changes should be

[2:49:52] this why their changes should be considered etc etc and depending on many aspects like what is the impact on the timeline of the project what are the benefits of this particular change request many all of these things will be

[2:50:06] considered and there could be three possible outcomes what could be the possible outcomes out after discussion In CCB In CCB either you accept the change request or

[2:50:19] you can reject the change request or you can just defer that okay we we will do it but later so these could be the possible outcomes out of CCB meeting where all the changes are discussed right so now you are

[2:50:37] you are starting the project don't you think that this should be established how change request requests will be entertained, how they will be analyzed, how the decision will be made on those change requests. Do you think this

[2:50:50] should be part of project governance? It is right. This is part of project governance and it should be informed to the stakeholders so that they are aware This is the process that I need to follow.

[2:51:03] Similarly u u as I explained yesterday when whenever you create BRD or FRD or in fact Jiraas you need to create two tables mostly in

[2:51:16] the beginning of the documents. One is called list of approvers or approver called list of approvers or approver list. who are supposed to approve or sign off this document. Second list is called

[2:51:34] distribution list. Distribution it will have all the people who will receive a copy of this document. So even creating this is part of governance, right? Who all should receive the copy? Even that is not that

[2:51:47] mandatory. But this part approval part is very much part of the governance. So is very much part of the governance. So you see we do so many things practically which are part of overall project or business analysis governance. For

[2:51:59] business analysis governance. For example, this CCB setup, how the change provide the author, who will provide the approvers, approvals, that is on the requirement. Same thing will happen on the design, testing etc etc. So all

[2:52:13] the design, testing etc etc. So all those things together make project uh business analysis governance process. So let's see what is there in these slides. Now you see what is there in the input business analysis approach. Now I I am

[2:52:27] sure you are able to tell why this is as the in this is there as the input because the CCB which I explained is part of waterfall that strict change control board and the entire process is not applicable in agile. So if your

[2:52:42] project is agile that CCB approach is completely different right the the uh sign off and approval that you need to take on BRD FRD that is completely different. So on the basis of business analysis approach your governance is

[2:52:58] different right your governance is different and it depends on the approach that your project is taking. I hope you are clear about it and why stakeholder engagement. So these are the output of previous two tasks. I'm sure you will be

[2:53:12] able to see that 3.1 and 3.2. So previous two tasks produced these because here we are talking about governance which has impact on the stakeholders as I told you who who you

[2:53:27] need to reach out for the approver approvals who you need to reach out to for escalations etc. So that is why these two are the inputs right output will be governance approach also you need to understand that when I say

[2:53:41] business analysis approach or stakeholder engagement approach do not always expect there that there will be a fancy document created and that document will say I am business analysis approach of the project or I am stakeholder

[2:53:57] engagement approach of the project or I am the governance approach right sometimes you don't create a document separate document just for this. It's like you know or you discussed you agreed or maybe it's there in the emails

[2:54:11] or you you may create a proper document that's fine what I but what I'm saying that it's not mandatory that for each and every such things you have a very formal document created right sometimes it's agreed verbally sometimes it's over

[2:54:25] email sometimes there may be a formal document also so it all depends but the document also so it all depends but the purpose is clear that why we need these two inputs so that you can identify the governance approach. Okay. Now you see

[2:54:38] guidelines and tools. Again the same thing from your previous projects. You might have created such things like governance approach. So you can take that uh you can use that if there are any business policies that says for

[2:54:51] any business policies that says for example up to 10,000 example up to 10,000 team lead can approve but beyond 10,000 only manager can approve. many such things right where you have uh approvals

[2:55:04] where you have authoritative decisions there can be some business policies that who can approve who can provide this so if there are any such policies we need to take care of current estate description why because it will again it

[2:55:16] will explain you what is the who are the stakeholders uh and uh who all we need to consider when we are talking about approvals etc and same is for legal and regulatory if there are any legal requirements you can take care of

[2:55:30] So the purpose of this task is to identify how business analysis work will be approached and prioritized. Define the process for proposing changes. This change control board. This is the prioritization. As I explained you that

[2:55:43] in agile only PO is responsible. Otherwise you may have a prioritization board. Also clarify who has the authority and responsibility to propose changes. Determine who is responsible to analyze change requests. Establish who

[2:55:57] has the authority to approve changes. Specify how changes will be documented and communicated. Right? Implementation of an insurance claim processing system. Context. Insurance company initiates a new claim processing system to improve

[2:56:12] efficiency, traceability, and compliance. The project is spans spans several departments including legal claim processing and IT all of which have a stake in requirement approval and

[2:56:26] process compliance. challenges. Multi-EP department approvals were necessary for all requirement documentation. Regulatory framework mandated strict audit trails and version control for all artifacts. Lack of governance in

[2:56:40] [clears throat] compliance issues and ambiguous approvals. If there is no governance, it uh I mean project will get impacted right multi- department approval. This is what we do in your BR on your BRD,

[2:56:56] FRD, all departments, everyone who is impacted, they should provide the approval. You created a document, right? BRD. Uh from audit point of view, what exactly do you maintain? If there are

[2:57:08] changes on that on that document, what exactly do you what exactly you do to manage those changes and you know make sure to make sure that audit trail is maintained. So this is the main point that this is also very very important

[2:57:24] thing right to maintain the different to maintain different versions of your maintain different versions of your document. If it is if you are um doing it on Jira requirements are captured on Jira automatically your changes will be

[2:57:37] captured or you are using let's say shareepoint so when you upload the document it gives you option to override the existing version or create a new version. So there also automatically your version control is happening. Same

[2:57:51] as on confluence. But in case you are you created a a word document or a spreadsheet or something, you can always create a table in the beginning of that uh uh in the beginning of that document where you can have simple things like uh

[2:58:09] where you can have simple things like uh date what cho changes and you will have date what cho changes and you will have who uh uh sorry the change ID so basically three four things the change number let's say 1 2 3 4 whatever and

[2:58:22] then you to have uh some description about that change and also you will have version number. Version number it will be like for first version you can have be like for first version you can have one or then you can have 1.1 1.2 1.3 and

[2:58:36] one or then you can have 1.1 1.2 1.3 and then you can have 2.1 2.2 into why when you move like this number minor number 1 2 after after point you are moving 1 2 3 that means a minor change minor version change when you move this number that

[2:58:50] means there is a bigger change right larger change in the document so larger change in the document so sometimes you can have even 3 1.1.1 and you keep moving this for very minor changes trivial changes for medium

[2:59:02] changes you can move this and then this for bigger changes right so you can have a proper table and it depends if you want to create it very detailed you can explain the change you can have uh other things which were part of your change

[2:59:17] control change request format right who who requested the change what is the impact and everything then you can document in this table so practically you will have to have this table in all your documents BRDs FRDS if you are

[2:59:30] creating formal documents right and then as I explained in Jira in sh on shareepoint and our conference change control is I mean Version control is maintained by the system itself. Obviously when you upload document on

[2:59:43] SharePoint, it gives you option right whether to create a new version and then it asks you to provide your comments. So it's like you can always provide detailed comments so they are so that they are part of the audit trail. Clear?

[2:59:57] Now you see the governance structure here for this scenario. A steering committee was was formed to review and approve high level business requirements. A change control board

[3:00:12] was set up for evaluating and approving all change requests. All documents and requirements were maintained in SharePoint with versioning enabled and access control implemented. Review and escalation process.

[3:00:25] Stakeholder roles and escalation paths were clearly defined using racy metrics. So AC metrics is also very important part of governance approval workflow. E- signature workflows ensure timely and traceable approvals and governance

[3:00:39] scheduled with representatives from each department to prevent bottlenecks. All of these points has to be discussed. There is I think one uh point that is access control right? So that is also

[3:00:55] part of governance. What does that mean? who can access right so on shareepoint I mean every project can create their own shareepoint and then they can control the access if I need access I may have to request that request that so it's not

[3:01:09] like sharepoints are not public documents where anyone can come and have access right so project managers or PMOs they will maintain the access only project people or relevant stakeholders will have the access to that shareepoint

[3:01:23] what are the outcomes all documentation was audit ready regulators commended the traceability weekly meetings and clear clearly defined decisions the defined governance model ensured clarity of responsibilities and the CCB

[3:01:36] successfully handled changes with minimum disruption. So these are the minimum disruption. So these are the benefits of this uh governance. What is the best governance mechanism to handle this? See change control board.

[3:01:52] In a complianceheavy project, how does a business analysis governance plan help ensure audit readiness? Again, the correct answer is C. By tracking decisions, approvals and changes formally. In an adaptive approach, when

[3:02:07] formally. In an adaptive approach, when is planning typically finalized iteratively throughout the project? Which of the following is an appropriate activity in hybrid approach? Fixed documentation for every sprint, no

[3:02:20] approach with iterative feedback, avoiding collaboration with developers. Now in in some some of the questions like this, uh elimination is the best approach. If you are confused, you know any nobody can say that no planning

[3:02:35] should be done, right? Even it's agile, rapid agile, whatever, no planning is is not the solution. So you can simply eliminate collab. Nobody in any of the collaboration whether it's waterfall, agile, rapid agile, canman, lean, nobody

[3:02:51] would say that avoid collab collaboration. So these two options are gone and fixed documentation for every sprint is is impossible. Right? Every sprint will have different features to be delivered, different requirements to

[3:03:03] be delivered. So same documentation cannot work for every sprint. cannot work for every sprint. So the correct answer is uh C combining formal approvals. Next, what technique works best to

[3:03:18] identify all stakeholders in a large complex project? change fatigue. How should the BA respond?

[3:03:32] Correct. C. Yes. What type of meeting is most useful for continuous stakeholder input in agile projects? So in agile projects, there is nothing like weekly status report. In a typical agile project, there is nothing like end of

[3:03:45] project feedback sessions or mid-phase approvals. So in fact out of four if you have if you have basic understanding of agile you know that these three things you don't even exist in typical agile setup

[3:04:01] right only sprint demo is the valid option. Next question when should the change control process be established at the end of the project before requirements are finalized only for low low priority task after the release.

[3:04:15] Correct answer is B. So if I if I ask you let's play a game right and uh once you let's play a game right and uh once we are I mean in between or towards the end I say now I'll tell you the rules and as per the rules which I just told

[3:04:30] you I am the winner of that game would you like it so generally it's always good that if you want to set up governance if you want to set up any rules any practices we should do it beforehand in the beginning so that

[3:04:45] everyone is aware so that nobody can complain you know I so that nobody can complain you know I if I had I known this then I would have done that differently right so to avoid such conflicts it's better to set up

[3:04:59] your rules governance etc etc in the beginning towards the first phase of the of the project in a productive approach what ensures traceability of requirements because approach is productive so anyway burndown charts

[3:05:12] daily standups they don't they are not valid options S correct is C. What does stakeholder analysis helps the What does stakeholder analysis helps the BA determine? Stakeholder analysis.

[3:05:26] BA determine? Stakeholder analysis. What does it help us with? Yes. Communication preferences, influences and engagement risk. So the fourth task is plan, business analysis, information management.

[3:05:41] Now what do you what do you understand reading the name on the basis of this name information management what do you understand do you get any idea by the name itself what do you think will be the purpose of

[3:05:55] this particular task just to reiterate for example in the previous task we established the governance right it was not like we executed the governance at that time we were not escalating at that time we were not setting sending

[3:06:10] anything out for approvals, right? It was just this the understanding and and setting up the process governance process. Similarly, here it's not like you will start managing the information. It's like how you will manage the

[3:06:24] information during the project that is what is decided here. So, how the management of information, who will manage, how it will be managed, getting information, how to handle collection, right? All that, all of that, right? Uh

[3:06:40] first of all tell me what all is considered as business analysis information. What all can be considered as BA information? All your requirement documents BRD FRD Jira whatever you create in fact minutes of the meetings

[3:06:56] any diagrams wireframes. So any traceability metrics, racy metrics, sort analysis. So whatever you perform right, all of those things are considered your business analysis information.

[3:07:10] What is the purpose of all these all these documents ultimately? You will stakeholders, get their approvals, etc. Like we discussed. So now you tell me

[3:07:23] this task? We just discussed what is the purpose of this task. In order to perform this task, what do you think can be the inputs to this task? So basically let's say business analysis information right

[3:07:36] because I just explained requirements are not only the B information. There are many other things like diagrams, minutes, racy traceability all of them are information. So any information that that is supposed to be managed.

[3:07:52] So that is the BA information. And what else will be the input? So this BA else will be the input? So this BA information and the stakeholder stakeholder engagement approach can be the input because all that we are doing

[3:08:06] managing and sharing of the information that is done for the stakeholder and that is done for the stakeholder and with the stakeholder right so now you do you think it's difficult to guess once you start understanding what is the

[3:08:18] purpose of this task many times most of the times you will be able to guess inputs all right? And output if in some cases where where this where it is confusing you will still be able to give the

[3:08:32] answers when you see the options right like in this case I you can guess that the information so first of all information has to be the input and why we are managing for the stakeholder so that maybe that is also the input right

[3:08:48] this task is about defining how you will create organize store access and manage manage all business analysis information. So this is this will also cover how you who all can have access so access management access control of that

[3:09:04] information and sharing also like tell me one thing you created a huge BRD now that BRD is let's say because of the screenshots because of the pictures etc

[3:09:16] now it's 50 MB and your organization does not allow 50 MB documents to be shared over the email so what would you do you want to take the approvals from the stakeholders on this BRD how will you share the BRD and take the approval

[3:09:29] you share the BRD and take the approval approach shareepoint drive confluence approach shareepoint drive confluence repository right and then you can simply share the link of that shareepoint to all your stakeholders that this is the

[3:09:42] BRD uploaded at this location please review it and provide your sign off right so now do you think that stakeholder engagement is playing some stakeholder engagement is playing some role here so now see what all inputs are

[3:09:57] will create different documents different information in agile you will documents because this information is supposed to be shared with stakeholders to take their approvals to take their sign offs

[3:10:12] to take their inputs that's why they are also that is also there and also you will discuss with the stakeholders right what kind of documentation they they are expecting like I told you some of my stakeholders were not comfortable with

[3:10:27] Jira. So I had to create BRD and third is governance approach because we are again talking about approval signups etc. So all three inputs make perfect sense when you talk about business analysis, information management, right?

[3:10:42] Again the same things if there is any lesson sorry lesson learned business policies information management tool right this is a new guideline which was not there with previous task but it is making perfect sense because if there is

[3:10:58] shareepoint which is used consistently in your organization and the mandate is every team will use it so then you will use it. So see whenever there are you

[3:11:10] know decisions made by the organization for example which tools to be used I think it's it gets easy for us in most most of the scenarios right the less decisions I need to make the better I feel and uh especially the bigger

[3:11:24] decision which tool to be used and all right so if there is any information management tools which are you know mandated or some prescribed by your organization it's good shareepoint confluence whatever and and if there is

[3:11:37] any legal regulatory information that is required. So you see very easy to guess guidelines and tools very easy to guess inputs and output is information management approach. Now again as I said earlier you may not have to create a

[3:11:50] dedicated document that this is the information management approach right it's just discussed agreed verbally maybe over email sometimes if it it is is really formal you can create a document with just one table that these

[3:12:06] are the documents I'll produce this is how I'll store them and this is how I'll share them for the approval so a simple table can be created key elements ments organization of business analysis information business analyst structure

[3:12:21] information for easy access considering data type stakeholder needs and change complexity while ensuring clarity so how would you store it's like it's like how will you create a folder structure so for example I created a project

[3:12:36] shareepoint let's say project one so this is my shareepoint here I can create folder structure that this is for BRD all different versions of the BRD will be here. Here I have let's say all

[3:12:52] the approvals which I need to store for audit purpose. I can have all the um whatever um if I have created any other documents I can create put it here. Let's say test sign offs. So basically the simple

[3:13:09] organization like even in our laptops we do that right? you create a proper structure so that it's easy for you to fetch the information later, refer to fetch the information later, refer to that information later. Um,

[3:13:21] okay. Uh, so that is the organization of information. And then this is also information. And then this is also important level of abstraction because not every stakeholder can consume the information at same level. Your sponsor

[3:13:36] might need just one slide, right? one slide to understand the status of the project. Your um uh your tech team might need a detailed BRD, detailed FRD, maybe detailed design documents, right? So you

[3:13:52] cannot have same meeting or same document for all your stakeholders. So to take care of the role of the stakeholder, the complexity of the information and what kind of documents they are they are they are, you know,

[3:14:08] which document you are supposed to create for different stakeholders? You will discuss and agree that in previous task a stakeholder engagement approach. So when I talk to let's say sponsor for the first time, I can request I can ask

[3:14:23] him or her that you know I'll do this meeting on weekly basis. I'll create this document. Do you are you okay with this? Do you need something else? Right? Same goes with um other projects, other stakeholders. So you create different

[3:14:39] documents for different stakeholders because not everyone can consume 100 pages of documents. Somebody needs 100 pages. So they are not they cannot be okay with two pager plan traceability. We discussed that requirements are

[3:14:53] captured at different levels. Right? You have your business requirements which are high level business requirements orational purpose. The main objective of the project then you capture stakeholder requirements. Then you capture

[3:15:07] requirements. Then you capture functional non-functional requirements functional non-functional requirements right and then you create your tra test cases to test the requirements you have releases to release them in production

[3:15:23] things like that. So basically the work that we do in a project the stakeholder functional nonfunctional requirements that we implement they all should support our business objective right why should I work on something that is not

[3:15:39] supporting the business objective of the project so basically that is the main purpose that all the work that we are doing here any stakeholder requirements that are here or any functional non-functional requirements that are

[3:15:52] here they all are aligned and to at least one or they they must be aligned to some business purpose some business requirement. So that is the main purpose of traceability matrix. You write business

[3:16:05] requirements to deliver this business requirement you you create functional non-functional requirement. So basically the alignment is required. Basically you should be able to tra trace uh in both the direction. So if you are tracing in

[3:16:20] traceability. Forward traceability. If you are moving in this direction this is called backward traceability. So basically they backward traceability. So basically they answer two different questions.

[3:16:33] The uh the the business requirement or this is stakeholder requirement is it getting delivered? Is it getting coded? Is it getting delivered through any of the requirements? It is is it getting tested properly? So that is how you look

[3:16:47] on on forward side right that okay yes this particular business requirement will be delivered through this functional non-functional requirement these are the test cases which will test this requirement and this will be part

[3:16:59] of release one so this is forward you are making sure all your requirements are getting covered they are getting coded they are getting tested they are getting released so forward traceability why I'm doing

[3:17:13] writing ing this particular test case why this functional or non-functional requirement exist. So if you want to understand the background and the purpose of the work that you are doing coding testing whatever. So if you want

[3:17:27] to understand the purpose if you want to link it back to the business objective that is called backward traceability right so you can trace back to the business objective that is back backward traceability. So that's where

[3:17:40] traceability matrix is very very very useful. If you have this properly created, properly documented, it gives you information in both the directions.

[3:17:52] you information in both the directions. Okay. R stand for release. Also, it's like uh for business analyst, you will create like first four columns. Then test cases. You can request your testers to full to you know capture here

[3:18:08] against each and every requirement. So that will make sure your test coverage from development team. You can get the idea on releases. So it's not like obvious obviously you own this document. It's your document but you can take the

[3:18:22] inputs from testers from developers to full to fill these last two three columns. Right? So this is is the purpose of traceability forward and backward. Now the same document can provide you a

[3:18:36] lot of insights. Right? That is why I consider it very important. A lot of insights you can get just by looking at the traceability matrix. So let's say there is this uh traceability matrix. I have I'll create it here.

[3:18:51] So there are business requirements. Let's say 1 2 and three. I'll capture here just for the simplicity. There we have test cases and

[3:19:06] releases. So against if if any if against any of these business requirement this column is blank. What does that tell you? You nonfunctional requirement. What does that tell you? Obviously your

[3:19:20] traceability matrix will not be as s simple as this looks right now. You might have multiple rows under each and every business requirement for each and every functional nonfunctional requirement. So this situation where

[3:19:33] nonfunctional requirement. What does that tell you? This tells you that maybe not covered. This is not getting developed because this is not linked to any of the functional non-functional requirement. Right? Similarly, if this

[3:19:48] field is blank, it tells you that this or this business requirement, they are not getting tested. They are not part of test coverage. Right here, if you see everything is populated here properly,

[3:20:03] but this field is blank. you know that maybe the developers have not included this particular requirement in this release. So you get a lot of insights right whether your requirements are getting properly coded whether they are

[3:20:16] getting properly tested whether they are part of the release or not right all of this is very valid information. Now if you see that here you have one or two test cases here you have three test cases but here you have 20 test cases.

[3:20:30] Do you see any problems with this this row? What is the problem here? That maybe this requirement is too big. Maybe this requirement is very complex. Maybe it will make sense to you know split this into smaller requirements because

[3:20:45] something which is too big is always that will create a lot of complexity. So when you have requirements which can get tested within five to 10 test cases but here it's too big. Maybe it's time to split it into smaller ones. Right? So

[3:21:02] you see how many different in in inputs you get. Now what happens when you go to your team and you tell them that there is a change in the requirements? How do react? Whenever a business analyst reaches out

[3:21:17] to the team with a change request, what is the first reaction? Why this change? Right? This business analyst is so stupid. He keeps coming back with change requests. Right? then they resist. So

[3:21:32] first of all very rarely they are happy with the change request right whenever you go to your team with a change request they just resist it that okay uh then what is the second point so first point is the resistance right they'll

[3:21:48] tell you so many things but what is the second point second input that comes from their side that this change request means I have to do everything all over again there is a huge impact Now I'll have to rewrite the

[3:22:02] code. I have to test everything all over again. Right? So they try to tell you that everything is impacted. Everything has to be redone. Is it normal or not? Normal. That is the normal reaction that you get from them. Now if you have a

[3:22:16] very properly documented traceability metrics do you think it can see it's not like we are going to fight with developers and testers but do you think it it will put you in a situation where you can negotiate where you can have a

[3:22:28] reasonable debate that you know requirement I am changing one functional requirement and this is the impact on test cases why are you saying that hundreds of test cases are impacted so basically it gives

[3:22:40] you some background some information which can put you in a situation where you can you know question crossqu question right again it's not to fight with them but to get some background right otherwise they think BA or PMS

[3:22:55] they don't have technical background so we can tell everything is impacted and they'll agree right do you agree or not proper traceability matrix will give you so many different inputs which are required in the project okay now one

[3:23:10] required in the project okay now one more layer so in my in my recent I'm not part of any particular development team. Okay. Uh let's say there is a big regulation coming up a big regulatory requirement or any big

[3:23:23] project where you have few very high level big requirements. Okay. So first thing that I do I interpret these requirements and let's create let's say requirements and let's create let's say I create a BRD. Okay.

[3:23:38] Where I detail them down and I create some business requirements. Then I'll create this traceability matrix I'll create this traceability matrix where in this column I'll list down the

[3:23:52] where in this column I'll list down the impact are very big it's possible that they will have impact on multiple applications right this application has some impact because these projects are

[3:24:07] impacting front to back of complete flow. So here for each and every requirement let's say this is my requirement for this requirement I'll create multiple rows there is impact on application one

[3:24:22] application two and application three for example okay this requirement which is here this will have impact on application four 3 and 1 and two now in

[3:24:34] application four 3 and 1 and two now in the next column here I'll write down the exact impact So application one this is what you need to do application two this is what you need to do application three this is

[3:24:47] remaining thing will remain same that you know code or test cases and releases etc. So I've added one more layer of complexity [clears throat] where I'm tracking the changes or the impacts on multiple

[3:25:01] applications because of my requirements and then the responsibility I can add one more field here that is the application Jiraa. So now you think about a situation where I'm working on a big program and there

[3:25:16] are multiple applications which are impacted in those applications they would have their individual BAS working for that particular application. So now those BAS they don't have to read the regulatory text of 100 pages they don't

[3:25:29] have to read uh go back and read all those regulatory documents etc. For them this traceability becomes traceability matrix becomes source of truth. They come to this matrix they filter out on this column that if they are from

[3:25:45] out all the requirements on the basis of application one and they can see the exact impact on their applications right then they create respective JAS

[3:25:57] they create uh test cases and assign them [clears throat] to releases so if I want to check all my BD requirements are getting uh getting developed I will simply say if see if all the requirements have Jiraas assigned to

[3:26:11] them. So if requirement number four does not have any Jira here, I'll talk to that BA and say why this requirement is not getting coded. Where is the Jira? Where are the test cases? Right? How you are testing? I can get a walk through of

[3:26:25] the their test cases to make sure all my requirements are getting properly tested. So you see from simple metrics it becomes a very very useful tool not just for me but for the application BAS right. So this is just one layer of

[3:26:41] added complexity where you have multiple different applications impacted. So I always create this document in all my projects. This template is like you can create if you it depends how complex you want to create this because

[3:26:55] in in this example in my example it can get very very complex because I'm talking about here if you have 50 requirements right and you have like in my previous project 15 applications were impacted and uh you can imagine number

[3:27:12] of rows which I'll have in this traceability matrix. So uh if you want your entire project document sing uh this can become your entire project document because when I'm talking about requirement number one I can mention the

[3:27:27] entire requirement here right so there is no BD I can create I can convert this document because I'll mention requirement here itself they can write Jira here they can write test cases here itself but then it will become so heavy

[3:27:41] and very very difficult to maintain because understand also that if you create too any columns and make it very complex. There is a change request, this and maintain it throughout the project. So, it's better to keep it

[3:27:54] project. So, it's better to keep it simple and uh and manageable. Okay. Now, how will you implement this requirement? You as a learner, you want

[3:28:06] requirement? You as a learner, you want to see your attendance in the LMS. How be some functional requirement. Functional requirement will will be uh

[3:28:18] the navigation on LMS on this page there should be a table where you can see your attendance right you can have a UI wireframe attached to that requirement. Similarly for my requirement there will be a functional requirement explaining

[3:28:33] this is how it will be implemented. Functional requirement will tell you how right a stakeholder requirement is simply I want to upload but how it will be uploaded that part the screen the buttons uh how you know any controls

[3:28:48] that you want like only 10 MB document can be uploaded not not bigger than that all those things now they are captured in functional requirements right and uh these requirements are supposed to be tested when implemented so now when you

[3:29:03] look at the traceability matrix You will see that functional require the stakeholder requirement was to have a feature to upload document. This feature this particular requirement is implemented using these two solution

[3:29:19] requirements or functional requirements. One is related to UI, one is related to the UI control and these two requirements are getting tested by these requirements are getting tested by these 20 test cases. So you can make sure all

[3:29:31] your requirements are getting developed through some functional non-functional properly tested. So this is the main purpose of traceability to make sure everything is covered. Okay. What is the meaning of plan for

[3:29:45] requirements reuse? See uh if you are living alone right in your house you come back from somewhere you put your car keys on your desk maybe on on the um

[3:29:57] on on your dining table maybe on your sofa is that okay or not because you are living alone. So it doesn't matter if you are a very organized person or you are not very organized it's fine. But if you're living in a family and everyone

[3:30:09] in your family use the same car. Now do you think it becomes more important to organize properly? Yes. Then once you are back you are supposed to put your key at a fixed place so that when somebody else needs the same key in your

[3:30:24] family they can easily find it out right because that is the purpose here of plan because that is the purpose here of plan for requirements reuse. Reusing if your organization works on similar projects right so reusing well

[3:30:37] structured accessible requirements saves time and cost. So that is the purpose you are anyway you know managing your requirements you are creating the drives you are properly organizing your structure but if you

[3:30:50] think they can be reused then it becomes even more important right to properly organize to properly label your folder so even if as as as a outsider if I come

[3:31:02] and you know uh I want to check your requirements etc you give me the shareepoint link I should be able to navigate through different folders myself because they are labeled properly and uh they are organized properly. So

[3:31:16] that is the purpose of reuse your information how exactly you are storing it in various ways depending on the needs depending on the conditions right which tools you want to use like sharepoints uh confluence even these

[3:31:30] normal hard drives where you are storing in the documents like BRD FRD and traceability metrics. So that is the storage and access. Then requirement attributes. What are requirement attributes? Anyone any idea? So see how

[3:31:44] do you capture requirements? Let's say what are the main attributes that you capture? requirement ID requirement let's say name description

[3:32:02] requesttor current status of that requirement things like that right any supporting document any supporting diagram so you capture requirements in a particular template using fixed attributes right is

[3:32:17] that correct or not even when you create FRD or BRD. This is like you have some common sections and then for requirements you create this table and requirements you will repeat the same table 10 times and every table will have

[3:32:33] table 10 times and every table will have these standard fields. Right? Even when you create requirements in Jira, Jira has the same template. When you create click on create, it will open up a window where you have multiple fields.

[3:32:47] Some of them are optional, some of them are mandatory. you will have to fill all these fields and save then your Jira gets created. So these that these fields are called requirement attributes. So again uh if you have admin access and

[3:33:01] you check in Jira you have hundreds of fields which are available. As an admin I can choose out of 100 that I want these 20 fields to be captured. So as an

[3:33:13] u admin I will go in in set settings and I'll change that only I'll select only 20 fields. So when the user will click on create they will see only 20 fields on create they will see only 20 fields in that in that. So basically it is up

[3:33:26] to the up to us and up to the project what all requirement attributes you want to capture for each and every requirement. Right. So requirement linking key information to individuals or group grouped requirements. They help

[3:33:39] team assess trade-offs, identify impacted stakeholders and evaluate change impact. So here you can have a status, you can have impacts, you can have impacted application, supporting application, upstream systems,

[3:33:52] downstream systems. So a lot of fields can be captured here. So here again just to reiterate, we are not creating requirement document. We are just deciding what kind of requirements we'll create. How many attributes we'll

[3:34:08] capture for those requirements, where we will store those requirements, how we'll manage the access control, how we'll have the access control for those requirement documents, right? And output is the document strategy. How, where and

[3:34:23] how information is housed or stored. Who can view, edit and share those documents? Version management of those documents. if uh any guidelines for reuse reusing of those documents and any archival retirement timelines methods.

[3:34:40] So simple as a BA this is what you want to achieve. So a school is planning to introduce an online student registration system to replace replace its paperbased

[3:34:52] process. The business analyst is working with the admin staff, teachers and IT registration requirements and design ideas. What is your information management plan? All information requirements notes in saved in Google

[3:35:07] Drive folders with clear labels like student requirements, teacher suggestion, system design ideas. The school principal and admin have full access. Teachers can view only the requirements. The IT provider can

[3:35:20] comment but not change the requirements. Right? So this is what we try to achieve. The BA decides to reuse parts of the old registration form like parent contact information fields. Right? The BA dates each document version and saves

[3:35:34] them as requirement version one, version two and so on. Old versions are moved to archive folder. Then retention and archival also. Clear the outcome. Time is saved by reusing past documents. The IT provider

[3:35:49] always works from the most recent version. No feedback is lost. Everyone knows where to find latest files. So this even though it's a small school project, planning how to manage business analysis information saves time. Fifth

[3:36:02] and last one is identify business analysis performance improvement. So what is the what is the meaning of business analysis performance? In order to improve something, first of all, you

[3:36:15] have to measure that thing, right? then only you can know that whether it is working as per the expectation or some performance improvement is required. So how do you measure what exactly is the meaning of what exactly is the meaning

[3:36:28] of business analysis performance? Build or use the existing KPI framework. What do you mean by KPI framework? Key performance indicator framework for business analysis performance. So what will be the key indicator in this

[3:36:43] framework as per our understanding of the business analysis role? What will be the key indicators that you would like to track? For example, when you talk about a successful business, let's say there is a grocery store in uh

[3:36:58] near to your house. How will you say whether they are going doing good or not whether they are going doing good or not on the basis of their daily sales? If on the basis of their daily sales? If you see people who are you know uh that

[3:37:11] that shop is always crowded so you can say that you know whenever I pass that say that you know whenever I pass that shop I go through that shop it's always crowded so on that basis I can say that their sales is going good right so

[3:37:24] similarly for business analyst what kind of con parameters you can use so first thing let's say you created a BRD and it took five cycles to to get it

[3:37:37] approved. Do you think it's good or bad? How will you judge the skills and efficiency of the business analyst? On the basis of few things that we need to identify, right? Like number of review cycles required in order to get the

[3:37:51] document signed off. Do you think it's a relevant metrics? Can you judge a business analyst on the basis of uh defect identified in a code? No. Can you judge judge a business analyst performance on the basis of you know how

[3:38:05] well he's dressed how well he he's able to run whether he has done any marathon or not or not no all these factors are irrelevant to a business analysis irrelevant to a business analysis performance right what are the relevant

[3:38:20] metrics what are the relevant indicators number of cycles required to get the sign off on the document number of requirement related ated

[3:38:32] number of requirement related defect identified right generally whenever we talk about KPIs or performance indicators we try to quantify them so that it becomes easier right but sometimes you can also have

[3:38:46] some qualitative indicators like the feedback from the reviewers of the document if they are happy with the document or not right so all these three document or not right so all these three four five indicators are good indicators

[3:39:00] to to see the performance of business analyst. Also, please note that we are not talking about the annual performance of as an you know the annual performance of the person. We are talking about the

[3:39:15] performance as a business analyst. How the business analysis work went into this project. Right? How many how how was the document? How was the uh how many review cycles required? How many defects identified? We are not talking

[3:39:30] about individual here. We are talking about the business analysis as a deliverable as a the documents that we need to produce the process that we had to follow. Right? Obviously these things can be tied back to the individual's

[3:39:44] thing. But here we are not talking about did you complete all your trainings? Did you did you fill your time sheets on time? Did you you know behave properly that is not individual's performance.

[3:39:56] Here we are talking about business analysis performance not business analysts performance. Okay. It focuses on assessing the effectiveness of business analysis work and identifying opportunities for improvement to enhance

[3:40:10] opportunities for improvement to enhance future performance and outcomes. past and ongoing business analysis tasks. Highlight inefficiencies, misalignments or recurring issues that hinder analysis outcomes. suggest

[3:40:25] adjustments to methods, tools and communication. Ensures B effort aligned with business goals and performance data to lesson learned. So let's see. So the first part is inputs. First input is business analysis approach and second is

[3:40:40] performance objectives. What kind of objectives we can set for a business analyst for business analysis work? Why it is mentioned external? Some of the inputs coming from the output of other tasks. Right? So for example it is

[3:40:55] mentioned clearly here 3.1 that means this particular input is the output of task number 3.1 which was the identify the project business analysis approach the project business analysis approach for your project this input not coming

[3:41:10] from any other tasks right there is that is the reason there is no number mentioned 3.1 or 3.2 too. Instead of that in the bracket it's mentioned external. So this input is coming from outside. Okay. And also you see

[3:41:24] additional guidelines organizational performance standard. So if there are performance standard. So if there are any standards already specified by your organization for all the business analysis work then that can be utilized.

[3:41:37] Okay. Output is obviously performance assessment and this output is already assessment and this output is already used. We have seen it right in 3.1 3.2 3.3 3.4 before and I was telling you that this input is the output of one of

[3:41:52] the tasks from the same knowledge area. Right? So here you can see that the lesson learned that you are learning here is used by other tasks. Now you can

[3:42:04] question that those tasks were performed earlier than this task. How can they use the output of this task? Right? Does that question come to your mind or you know the answer already? So the see first of all these things are not

[3:42:19] performed in a particular sequence right the sequence in which they are mentioned it's not necessary that you perform them in the same sequence. So that is the first reason. Second reason, all these tasks are performed iteratively,

[3:42:34] right? It's not like you did them, you perform them once and they are done. Also, uh why they are done iteratively that because it's possible that initially the input uh which was

[3:42:49] initially the input uh which was available was partial. So initially you had partial input and you started working as per that partial input and later you more and more data or more input became available more data

[3:43:05] right so you then again you perform the task. So that is why it every task may be done iteratively multiple times initially with the partial data. So in for example we discussed about stakeholder identification right

[3:43:21] identify your stakeholders can you perform a stakeholder identification confidently in one go can you confirm after whatever efforts you you confirm after whatever efforts you put in early that I have identified 100%

[3:43:34] stakeholder even if you feel don't you think it's fairly possible that you will identify two more stakeholders after one month because somebody else might come to group and tell you that you know there

[3:43:47] is uh these are two more stakeholders which can be impacted. So now what will you do? Will you not go ahead and perform the uh elicitation with these two stakeholder right? So initially you you identified

[3:44:05] 10 stakeholders. So you went ahead and started interviewing them. So you started interviewing them. So you started the elicitation right in the stakeholders. So you performed elicitation for them as well. So you see

[3:44:19] what happened a stakeholder identification was done in iterations and similarly because of that your requirement elicitation was also done multiple times. It could not be completed in one go. So that is the

[3:44:32] reason if you think about any of these tasks like u stakeholder engagement we just discussed you you will identify more stakeholders. So this particular task will be performed again and again iteratively

[3:44:47] right. It's also possible that some new issues identified and you have to add something to your existing business analysis governance right uh so this document or whatever the approach is also going to be a live approach it's

[3:45:02] not like a static all the time same here you identified something which is very new identified for the first time or you decided that you know starting tomorrow attributes for the requirements so here also it it can change Right? So that is

[3:45:18] the point that initially let's say when you started performing uh these tasks maybe this past assessment was not fully available but you still went ahead and available but you still went ahead and perform these tasks later on when this

[3:45:33] was available you can go back and perform these tasks again also it's possible that this performance assessment is coming from the previous project right so the performance Performance assessment from previous

[3:45:48] project was already available when you started with 3.1 3.2 to 3.3. Right? So that can be one more reason how this output was already available when you because it came from the previous project or the input was partially

[3:46:03] available or you started the tasks without that approach assessment and you will perform them later when uh when this become available. Right? Clear? So that is how you need to think about it. Never think that any

[3:46:19] tasks or any knowledge areas they are performed in the exact sequence in which they are mentioned in webok. That that is not true. You will perform them in different orders depending on the project. In fact the order of knowledge

[3:46:33] area itself can change order of task within each and every knowledge area will definitely change. Okay. And most of those things will be performed iteratively multiple times. Now the key elements so it's like very

[3:46:48] similar to uh you know our performance appraisal initially what you will have you will have the assessment measures the focus is on establishing clear criteria to quantify and qualify the performance of a BA work we discussed

[3:47:02] some of the measures right number of review cycles required number of defects requirement related defects identified the qualitative feedback from your customers the quality of of of your requirement uh document, right? There

[3:47:18] can be many such things that can be identified and documented. Then you will analyze your outcomes against these measures. So you have objective set. It's like typical to our annual performance appraisal as well.

[3:47:33] What is the process? In the beginning of the year, we all create self objectives. You set up your self goals, self objectives. You get them reviewed with objectives. You get them reviewed with your boss. You both agree. You say my

[3:47:47] goal is to let's say complete these two projects. And your boss may negotiate projects. In addition to that, you have to complete at least one certification. And uh there should be zero escalation. There should be zero escalation for time

[3:48:02] sheet filing. There should be zero escalation against any training uh you escalation against any training uh you know completion. So both of you would agree that these are the objectives. Now throughout the year you review

[3:48:17] your performance against those same goals. Right? Then end of the year you evaluate yourself. Maybe you will give some ratings to yourself. And then finally you will have a discussion with boss. You will say I deserve one out of

[3:48:33] one to five. I deserve one being one being the best. And boss would say you discussion happens and all and you finally get one rating and salary hike accordingly. So this is the normal process that we follow. Right? Even for

[3:48:47] our individual uh performance appraisal same thing is here you identify the assessment measures first. Then you uh check your the performance against those check your the performance against those measures and analyze the results and you

[3:49:01] will collect data to find trends, patterns and root causes for poor performance. any issues which are identified you will propose practical improvements that can enhance performance moving forward right so it's

[3:49:16] very very I mean it's exactly the lesson learned you had objectives you compared your performance against those objectives you may be able to identify some areas of improvement so you will work on them right I mean how will it

[3:49:32] work practically in project it looks simple that you had some objectives. You will compare your performance throughout the year against those objectives and able to meet those objectives or there is a gap. If there is a gap, what is the

[3:49:47] reason for the gap, right? How we will fix it? For example, you identified in the uh the project was slightly delayed and when you uh sit as

[3:50:00] slightly delayed and when you uh sit as a uh as a team, you identified that the a uh as a team, you identified that the uh review took longer than expected, right? So, you were supposed to get the sign off on your requirements let's say

[3:50:13] sign off on your requirements let's say on 15th of May but it was completed on 30th of May. Now, what could be the reason? Can you think of any reasons that can that can be there? If you talk about the proper cycle that we generally

[3:50:27] we should follow. What is that cycle? You create the document, right? You you have once you are ready with your document, what what is next that you do? Do you send it to your stakeholder for for the signup

[3:50:40] or is there anything that you do once you are ready? So you performed elicitation, you got a lot of information from a stakeholders, you properly organized that information into properly written requirements, you

[3:50:54] created a very nice requirement document. Now what exactly you do as a requirements, what do you do? Elicitation is done. That's why you are ready with your requirement document. Final requirement document, right? So

[3:51:06] when I send the requirement document with the stakeholders, maybe I uploaded the document on a shareepoint and shared the link because that's how we discussed about information management or maybe I uploaded the document over the email

[3:51:19] stakeholders. So we followed whatever was agreed for information management and accordingly be shared. Now a stakeholder had so many questions and they came back to me. I tried to answer those questions. They came up came up

[3:51:32] with more follow-up questions. I again answered them. So they had more questions and that is the reason that is the exact reason why it took two more weeks than expected. Now what went wrong here? So now we are sitting we are

[3:51:46] trying to do the lesson learn session and we identified requirement sign off took two weeks extra. What is the issue that you see here? Once you are ready with ready with your requirement document

[3:51:59] it's not that you send it for the sign off. That is not the right approach. What you should do? You should set up a a workshop where you will walk them through the requirements one by one. You'll make sure that they all of their

[3:52:14] questions are answered. They all have the same understanding common understanding of the requirements or you basically all of you are on the same page in terms of requirements. Right now after that you send out that

[3:52:28] email that as per our walkthrough session I have answered all your questions in case you have any more questions please feel free to ask document for your sign off right please kindly provide your sign off now do you

[3:52:42] think it will have a very big difference as compared to the first scenario where you simply send the requirement document for the approval without the walkthrough walkthrough session do you think you will expect

[3:52:56] you know difference different different outcomes. So that is how you need to find out the gaps. This is just one example where you could find out the gap and again this is we are not saying that you know it's your respon we are not

[3:53:12] talking about individual we are talking about the process that we followed the process which was followed there one step was completely missing we in the process and this time we'll fulfill we'll fill that gap and we'll

[3:53:26] done and maybe you can put it in your project documentation so that it's always there. Now when you start a new project, if you look at this documentation, don't you think you can

[3:53:38] always be done before you send anything for the approval. That is why these lessons learned you will keep looking back at that lesson learned register, right? So that you will not repeat the same mistakes when you do the same work

[3:53:52] next time. Similarly, you can identify you can you will see so many examples around you where maybe a different process was followed and that led to a delay in requirements or maybe in requirement approvals or with testing

[3:54:07] requirement approvals or with testing test uh test cases and all. For example, uh let's say you uh you initially when you were capturing the requirements instead of this time we discussed a walk

[3:54:21] through which was not done for the business stakeholders. Similarly, you didn't do the walk through for let's say testers. So you wanted to discuss solution for the feasibility analysis and all. So you involve the developers

[3:54:34] in the initial discussions but you didn't involve the testers. Now can that have some impact? That can also have some impact. Right? Testers who are not very uh clear on the requirements that can have impact on the acceptance

[3:54:48] criteria that they sorry the test uh scenarios or test cases that they scenarios or test cases that they prepared. Later on when test execution started uh developers would testers would say

[3:55:01] there is a defect as per their understanding of the requirements. Okay. Okay. So what happens when when a tester goes to a developer and says there is a defect what do you think how a developer responds generally what is

[3:55:17] the first response from de developer this is my code right it can't have any it can't have any defect maybe you are mistaken go back and test it again my code cannot have a defect right that is the first uh and then the the second is

[3:55:35] my as per my understanding this is working fine. Tester will say as per my what could be the reason they have requirements. Now can you say that no it's not my role. It is definitely your

[3:55:49] role to make sure both of them have the common and shared understanding of the requirements so that during testing there are no such conflicts. Right? So what will you do again the same thing as as you start

[3:56:03] collecting the requirements you can even you shouldn't wait to finalize the requirements you should start involving your team if you have your developers available testers available already in your team in your project you should

[3:56:17] involve them as early as possible now there are multiple benefits of this first this thing that they have the common understanding of the requirements right so that there are there there will be less lesser conflicts during test

[3:56:29] be less lesser conflicts during test execution. Second, from the feasibility point of view, you are a business analyst. You may not know all technical knowhow of your project. It's possible that you may end up kept getting, you

[3:56:42] know, documenting a requirement which may not be feasible at all technically. So once you involve your technical minds early in your requirement sessions, you get a very good feedback from the technology point of view whether

[3:56:56] something is feasible or not, how long it will take so that you or your manager will not not end up committing something which is not achievable. Right? So these are the practical things that you will learn. Now if you read

[3:57:10] webock you will not talk about all these instances that we are just talking about. uh be will simply say that identify the measures, measure your performance against those measures and document the lesson learned

[3:57:23] and move on. Right? That is all you will see in so you understood how on what basis business analysis performance can be measured. I gave you two three examples where there can be gaps and how you will fill

[3:57:38] those gaps. We discuss the inputs. We discuss the key elements. You are clear on the task. Output. Now you know what is the output. It is the comparison of planned versus actual performance. Identify the root cause of variance and

[3:57:54] proposed approaches to address issues. Metrics for monitoring the effectiveness of implemented improvements. And whatever is these metrics, whatever is the outcome, you will document it as a lesson learned so that you can refer it

[3:58:07] back in your next project or in the same projects later on. Right? So this is called lesson. What do we call it in agile? Here I'm calling it lesson learned. But in agile what does it call something similar that we do in agile?

[3:58:22] retrospective. So what is the purpose of retrospective? The last meeting that we do, last day, last meeting of the sprint that is called retrospective and that is the purpose of retrospective. What went

[3:58:36] well, what did not go well and any areas of improvement. So that is the exact thing that we just do for business analysis work, right? And it's very much possible that this was done if the project would be agile this discussion

[3:58:50] improvement would be done in that retrospective itself not separately retrospective itself not separately right so this is the last task okay let's see one scenario context a BA team is a large in a large organization

[3:59:06] observed recurring delays in getting requirements approved which frequently led to missed project timelines and stakeholder frustration issues identified side stakeholders were not clear on who should approve, when to

[3:59:19] approve and how to communicate their feedback. Requirements documents varied from project to project. Lacking consistent structure and details. See how many things can go wrong. You are using different template, different

[3:59:34] requirement, document structure in every time and they are getting confused, right? Your project communication plan itself is not very clear how they are supposed to communicate the feedback, how they're supposed to approve and you

[3:59:48] how they're supposed to approve and you so you see many very simple problem. If you send out an email and it happens all the time. If you send out emails and all the time. If you send out emails and you simply write hi all

[4:00:02] and whatever you want to do and then please approve and there are 10 people in the approver in two list of your email. Now what will happen? Do you think everyone will approve or do you think nobody will approve? What is

[4:00:16] more common? What is more common scenario? Generally when you send email like this nobody will respond, nobody will approve because your email itself is so poorly written you have so many people in two list and then you are

[4:00:30] saying hi all nobody will have any idea who exactly you are requesting be it who exactly you are requesting be it sign off be it anything. So it's very important that you clearly mention the uh the names of the people who you are

[4:00:44] asking or you are keeping only one or two people in your tool list. So they know that you know you are addressing the still it's better to just clearly name the people and if you send out email how soon you can chase

[4:00:58] you cannot chase same day right maybe you will send a chaser next day or maybe what 2 days after that because if you are sending email for the approval to daily basis so let's say you chased

[4:01:12] after 2 days and they say who exactly you asked we have no clue now you wasted 2 days right so there Can be many such scenarios where because of some gaps because of some you know missing you missed something on your part anything

[4:01:26] can get delayed and you see this this is also a very good example that the way you wrote your email was not correct. So what was done the BA team designed a visual flowchart outlining who reviews and approves which sections timeline

[4:01:41] expectation for each each stakeholder. This is also very important. Uh see an action without ETA is not an action. So when we say

[4:01:53] that I have created I have noted down the actions they will make no sense until unless you have action owners assigned and expected turnaround time assigned to those actions. They will not make any sense. Right? Communication

[4:02:06] protocol for rejection or feedback. How it helped? Made everyone involved aware of their role, deadline and responsibilities, reduced confusion, created transparency and build stakeholder trust.

[4:02:20] The team introduced a structured requirement templates, clear sections for functional and non-functional requirements, defined fields for priority, dependencies and traceability, visual elements like user story maps

[4:02:32] etc. Now this is what I told you when we learned about the in the previous section itself that you need to identify the attributes that you will capture right and I told you that you will create one table and you will repeat

[4:02:48] that table consistently throughout your document you will create a table where you will have things like requirement ID name etc etc etc and you will repeat document to capture all the requirements. I also told you like in

[4:03:05] Jira you have multiple fields but you will generally you will standardize that template consistently for all your Jiraas right so that is the point to mention here exactly the same thing how the how it will help made documents easy

[4:03:19] to follow and evaluate reduced ambiguity and save time in formatting and in short generally you should follow the same template consistently same requirement document template consistently across all the projects and that This is where

[4:03:34] you uh you might see PMOs are playing important role. PMOs play different roles in different organization. Sometimes they have the responsibility of standard documentation. So if you need any templates for BRD, FRD or any

[4:03:51] them and they'll give you the exact template that should be used across all the projects to maintain that you know consistency. So reduced approval time this was the key parameter key indicator for BA success and this is reduced

[4:04:08] approval time by 40%. Very good improved stakeholder satisfaction a qualitative documentation in the process that you are following for business analysis. Achieved adherence to the project timeline. Right? All that what we wanted

[4:04:22] to achieve. Clear? So we have just completed the first knowledge area business analysis planning and monitoring. Your team is collecting requirements from multiple stakeholders using different tools Excel, Jira and

[4:04:36] Confluence. There is a confusion about which version is the latest. Which task should you focus on to eliminate such version control issues? In which task did we discuss about this? Yes, plan business analysis.

[4:04:51] Your organization has strict confidentiality rules for storing customer data. You must ensure that business analysis information follows compliance rules. Which element of the information management plan addresses

[4:05:03] information management plan addresses this? Storage and access. You need to determine how long the requirements for a discontinued project should be retained in the system. Which part of the information management plan

[4:05:17] are you dealing with? Discontinued project that means project is already done. It should there is no need to keep a live document. So what you will do with that document? You will just archive that document. Right? So the

[4:05:31] correct answer is right D. Two analysts are working on related features. One makes an update in the shared document but the other is unaware and continues with outdated information. What should have what could have prevented this?

[4:05:46] Correct answer is C. You are asked to define naming conventions and format for use cases and user stories before gathering more requirements. Which component of information management is this? A right.

[4:06:01] Your manager asks for a quarterly report on the number of requirements defects that occurred due to incomplete analysis. Which aspect of this task you are addressing? Yes. B. Multiple requirement gaps were discovered during

[4:06:15] testing. You review how requirements were elicited and documented to find the issue. What technique are you applying here? What we are saying that problems are identified and you you're trying to find out the and document to find the

[4:06:29] that is why root cause analysis which help us to identify the root cause of the problem. Right? We'll go through all these techniques. So that time it will be clearer. A senior BA is mentoring new analysts on best practices and

[4:06:45] documentation standards. Which performance improvement element does this represent? Mentoring will fall under which which of these uh options? It is B, right? Training and development.

[4:06:59] All right. So the next knowledge area, the second knowledge area is elicitation and collaboration. Elicitation means gathering information from stakeholders to understand what they need and expect. Collaboration means working together

[4:07:14] with them to reach a shared goal. So that is the uh name of this knowledge area. Elicitation and collaboration as I have been telling you elicitation and collaboration or any other knowledge area or other task for that matter they

[4:07:31] are not one time right they are they they continue throughout the business analysis process some elicitation you will do now maybe you will have to do some elicitation more later when you identify a new stakeholder so never

[4:07:45] assume that you will continue any of these tasks in just one go you may have to do them again. Now when you talk about the tasks which are part of this knowledge area, there are five tasks. Prepare for elicitation,

[4:07:59] conduct elicitation, confirm elicitation results, communicate business analysis information and manage stakeholder collaboration. Now this uh the tasks of this knowledge area are very simple. If you compare it with the

[4:08:14] straightforward. And when I say none none of them are performed in sequence there is just one exception which is these three tasks. So

[4:08:26] whenever you perform elicitation these three task are the elicitation these three task are the only tasks in knowledge area in in beok which are performed in sequence. You will always prepare you will always just

[4:08:39] after that you will conduct and then you will confirm elicitation results. So these tasks are performed in sequence. This is the only exception. Right now

[4:08:51] let's quickly learn let's quickly try to understand what exactly we are discussing here in this knowledge area. So you understand what is elicitation right? You meet stakeholders in different ways. You maybe online or in

[4:09:06] person maybe onetoone maybe in a group setting. So you do that meeting part and setting. So you do that meeting part and you ask questions you uh you probe your

[4:09:18] are their problems what are their requirements right so that is the requirements right so that is the purpose here now what is the meaning of prepare preparation what do you think we'll prepare before conducting the

[4:09:32] elicitation so in conduct you will actually perform that task right but before that you are saying there is a different task which is prepare for elicitation. What kind of preparation do you need? So let's say you want to

[4:09:45] conduct interview of four five stakeholders to capture the requirements to discuss the requirements. What kind of preparation you are you you need to do? Going through the needs prepare questions whom to reach prepare the

[4:09:58] questionnaire. Yes. And whenever we think think from very very basic the most basic normal thing that you will have to do right there is no there

[4:10:11] shouldn't be any hesitation saying that you know we may have to book a meeting room because that is something you'll have to do so some start from very basic what all things that you need to do what will be output who will be benefited

[4:10:24] will be output who will be benefited with the solution. So yes, first you need to prepare yourself. What is this project all about? What is the scope of this project? What exactly I'm going to ask? Who are the stakeholders? Uh then

[4:10:39] ask? Who are the stakeholders? Uh then you will prepare the questions. You will perform other things like booking the meeting room. If you are if you if you need to run a workshop or interview, you will prepare other training material. If

[4:10:53] documents, you will collect those documents. Right? So, uh if there is any to run a workshop or brainstorming session, there might be a requirement

[4:11:06] for a whiteboard. In some cases, it's already there in your meeting rooms, right? In your offices, but sometimes you may have to request. Let's say you then you may have to arrange for those things. There are many other things that

[4:11:21] is a senior stakeholder sitting on a different floor and you sit on a different floor, which floor would you like to book a meeting room on? It makes sense to book a meeting room on his floor, right? On their floor so that

[4:11:37] they don't have to walk to your floor. So there are many basic things that you will have to take care when you prepare like time zone differences. If somebody is in different time zone, you will have to take care of time zone. If somebody

[4:11:50] is um there there are problems related to language communication, then you will also have to take care of that. So basically consider your stakeholders, their preferences in terms of timings, time zones, u the location and then you

[4:12:07] prepare the other things like we discussed all the uh all the additional material with with respect to documentation with respect to meeting documentation with respect to meeting rooms and then one more important part

[4:12:19] so we discussed what you need to prepare and I'm sure you would agree that you need to prepare your stakeholder also right to get to the maximum benefit to achieve the maximum benefit out of this meeting

[4:12:35] you need to prepare your stakeholder now what do you mean by uh preparing your stakeholder before this what do you think we should do sharing the agenda with them agenda of the meeting and what will happen so that they know what

[4:12:49] exactly are you going to ask otherwise what will happen if you go and ask questions and he says says or she says I don't know you will not say you know I caught you will not start celebrating see I knew that you wouldn't know the

[4:13:04] answers that is the purpose is not you know making a point that you know even your stakeholders don't know the answers that is not the point the purpose of this meeting the the ultimate goal of the meeting is to get the answers so

[4:13:17] project not to prove that even they don't know the answers right so it's very very important that you share the agenda in detail you provide the project agenda in detail you provide the project background right and also if possible

[4:13:30] share the questions also in advance. So that is how you will prepare the stakeholders so that they come prepared in that meeting also. What else you can do that uh I mean a very very important practice that I always follow that I'll

[4:13:45] I'll make sure that this event whatever I'm doing workshop interview whatever this event is not the first time I'm talking to that stakeholder. So it's very very important to build that repo right you might have heard that term

[4:14:00] multiple times in different context that repo building repo building that this is where it will be very useful what I do almost in all my projects that if uh I the first time I'll just simply say hi over teams over chat and maybe if there

[4:14:17] is possibility I'll just quickly connect with them say hi [snorts] hello I'm part of this project I I joined this project as a PM or BA whatever and I'll be working with you. I'll start setting up meetings uh to conduct the elicitation

[4:14:30] etc. So I'll try to break the ice before the first formal event that I'm going to run with that stakeholder and trust me it will help you a lot. Okay. So you

[4:14:43] it will help you a lot. Okay. So you prepare yourself, you prepare any u stationary, any other material rooms etc that is required. So you prepare for any supporting things and you prepare your stakeholders also. All these things you

[4:14:57] do before conducting the elicitation right. So this is the first task of this knowledge area. Second task is about actually conducting the elicitation. So here in uh also one more thing which we

[4:15:12] forgot in during prepare prepare for elicitation you will also choose elicitation you will also choose which technique you will use right like you will do a workshop or you will conduct interviews

[4:15:27] right or you will use questionnaires or surveys techniques that we need to cover. So you will decide which one of these

[4:15:39] techniques you will use and accordingly also you need to prepare in case of prepare surveys or questionaire in case of interviews you'll have to prepare accordingly you need to finalize the technique also. Now tell me practically

[4:15:53] on what basis you will finalize the technique. What is the most important criteria which will help you decide which techniques to use are the criterias? what are the important points that you will consider

[4:16:07] in order to decide which technique should be used in this project. So the most important factor the most important uh point is number of stakeholders. Tell me if there are 100 stakeholders can you possibly conduct interview.

[4:16:22] If there are 30 40 stakeholders we cannot possibly even for 30 40 it's difficult to conduct interview in individually of all these stakeholders because let's say even if you try and conduct it's possible that when you

[4:16:36] conduct it's possible that when you reach 15th stakeholder he says something which is in conflict with what first stakeholder said. Now what will you do? You'll go back to the first you'll come back to 15th. So you can you may stuck

[4:16:51] in endless loop right. So when number of stakeholders are number of stakeholder is high you cannot possibly take interviews because it will take a lot of time. when number of stakeholders are let's say so what will you do when you

[4:17:06] have 30 40 stakeholders what would you what what techniques uh what techniques will will you use let's say workshops let's say workshops right maybe uh brainstorming

[4:17:18] right maybe uh brainstorming but when you have thousands of let's say 500 stakeholders can you do workshops even workshops will not be possible in maybe in that case you can send out surveys questionnaire

[4:17:31] Right. Knowledge information of the stakeholder will also play important role. Do you think it's possible to always tell what exactly is the requirement? Is it possible to always express especially people who are not

[4:17:44] very techsavvy, people who are not very good at talking. There are people who are very very introvert. So it's possible that you conduct interview but you not you do you do you do not get all the answers. So what techniques can you

[4:17:57] use in that case? So in that case you can send out surveys or you can do can send out surveys or you can do things like have you heard the term job shadowing active and passive job shadowing. So what is the purpose of job

[4:18:09] shadowing. So what is the purpose of job shadowing is to to you know to to actively or passively look at the person uh when he's while he's performing his job right so when you are doing what you do I'll come and spend time with you

[4:18:26] maybe I'll just stand there without disturbing you or maybe I'm allowed to ask questions and I'll try to see what exactly you are doing so instead of you explaining me verbally I can have a firsthand experience looking at you

[4:18:40] while you perform your job. Right? So this is also decided on the basis of what kind of stakeholders you have. Sometimes people who do some you know mechanical work uh and you know that they'll not be able to explain because

[4:18:54] it's not easy to explain. So in that case you go and job shadow them right. So there are many techniques, workshops, interviews, questionnaires, surveys, market research, job shadowing which we can utilize but it depends on mainly on

[4:19:12] two things. Number of uh stakeholders and how what kind of stakeholders they are. Can they help you? Can do you think they will have clarity to tell you the requirements or maybe you will have to job shadow them to find out.

[4:19:27] Right now imagine that this preparation when we discussed about prepare your stakeholder. Do you think you need to prepare them more when you want to job shadow them? The preparation of the stakeholder bit becomes even more

[4:19:41] important when you are going to conduct job shadowing. Do you think everyone is comfortable when you know somebody's is standing on their heads while they're everyone will be comfortable? I don't think so. Right? Even if my wife says

[4:19:56] can I come and if she says she asks me can I come here and sit when you are I mean doing this training I'll not be comfortable it it gets very weird right them you might have to take the permission from their bosses that you

[4:20:10] know I'll spend one day with that person I'll keep looking at what he or she is doing and also that gets very disturbing also so job shadowing for example can be of two types passive and active in passive you do not ask questions you do

[4:20:25] not interrupt but in case of active job shadowing you can ask questions you can then and there so in that case it becomes even more disturbing so in that case it's even more important to prepare your stakeholders before you come and

[4:20:40] you know have observed them so it is called observation or job shadowing both so that is preparation and then you conduct the elicitation now conduct elicitation is simple whatever you decided along with the material you will

[4:20:54] conduct that right? So you prepared for workshops, you send out the you sent out the invites and everything here the purpose is just to meet the stakeholder arrange uh you know and facilitate that discussion and conduct that session

[4:21:09] irrespective of what the technique was. If it was interview you will conduct conduct you it will you will conduct the workshop. The only difference is uh uh

[4:21:21] difference is that in workshop you may have support like somebody who is taking your notes. What do you call that person? Scribe and uh in case of interview also you may have to take notes. So uh and the difference main

[4:21:37] main difference is these things that in case of workshop you will have multiple stakeholders in case of interview you may have just one or two stakeholders. On the other hand, you may have to conduct them quite differently. Right?

[4:21:50] So what happens especially when you have senior stakeholders, sometimes your direction. Somebody will start talking about something else and that's where your facilitation skills. We discussed about these skills on day one. That's

[4:22:04] where your facilitation skills come to play. How you can make sure that your meetings are going as per agenda. they are not getting derailed and also you

[4:22:16] need to learn things like how you'll make sure everyone is speaking but just imagine that you want to run workshop or focus group and you invited 20 people

[4:22:28] how do you select those 20 pe people there are two types of group right grouping homogeneous groups and heterogeneous homogeneous means same expertise heterogeneous means different backgrounds coming from different

[4:22:41] backgrounds and variety of skill sets. So how do you decide what kind of people or group you need? Right? It depends what kind of problems you are trying to solve. If in my house um I'm designing a new house, I will

[4:22:55] want everyone to be there, right? Electrician, plumber, painter and everyone. But if I'm the problem is that there is a there is a leakage in my specific problem. I need only the plumbers, not other expertise.

[4:23:11] plumbers, not other expertise. Right? So, uh this is where you decide what kind of stakeholders you are invited. Now, during the meeting also, now tell me one scenario. If you notice that out of 10 people, there are eight

[4:23:26] people is speaking a lot because maybe they are senior or something. Four people are not able to speak and you think they can also have some valuable inputs to provide to you. How will you make sure they are able to speak? What

[4:23:40] will you do? We are doing this to get the requirement for the project. How job shadow doing will help? So what what do you mean by project? When I when you say project, what do you mean by a project? What kind of projects generally we work

[4:23:54] on? What is your understanding of project? Uh [clears throat] Jacqueline, right? have a separate call to check on the on them or so basically the point I was trying to make you will always do you will always utilize more than one

[4:24:09] technique. It is possible that during workshop you found that somebody could give better inputs but they were not able to speak. So maybe you can engage with them separately in onetoone interview or during interview you

[4:24:25] identified that there is a bigger group who can also give you more requirements. So after interview conduct a workshop or after workshop you conduct an interview you send out questionnaire and you've liked one of the answers that you and

[4:24:40] you think that this user can give you a lot more details. So after that questionnaire you set up an interview in interview with that person. So you see it's very very possible that one single technique will not give you everything

[4:24:56] that you need and you may have to use more than one technique okay to get all your requirements. Now coming to the question that why we are saying job shadowing. So first of all projects are

[4:25:10] not always development projects right where somebody will give you a brand new fresh requirements and you need to develop a software or something don't can you imagine a project where application was already running somebody

[4:25:22] is already using that and there are so many complaints about it and people are not happy with the ongoing uh you know software or whatever product they are using they're not happy with it. Now the task of a business your your task as a

[4:25:36] business business analyst is to go identify the problem identify the root cause of the problem and then propose a solution and then the project will be the purpose of this project is to solve that specific problem from the existing

[4:25:50] solution. You are not building something new right now in this case do you think job shadowing will be helpful. So basically the purpose of a project is not always to build something new. The purpose of the project could be to fix

[4:26:05] something which is existing but it is not working as per the expectation. When you have uh knowledge areas like a strategy analysis, a strategy analysis will always give you a strategy of the organization. What

[4:26:18] a strategy of the organization. What kind of you know uh what is the business what is the long-term uh uh vision of the organization in order to fulfill that vision? what kind of projects can be launched. So it's possible that the

[4:26:33] project that you are getting is initiated from a strategy analysis knowledge area but there you also have a knowledge area which is evaluation which keep evaluating the solution which are in use right so it is also possible

[4:26:48] initiated is coming out of this evaluation some problem was identified project. So projects are launched mainly for two reasons. There is an opportunity

[4:27:00] that you want to grab in the market. So that's where you launch something new or there is a problem that you want to fix. Some stakeholders, some customers are continuously complaining about something and you want to you want to fix it.

[4:27:14] Right? What is the problem with job shadowing? The biggest problem with job shadowing? The biggest problem with job shadowing is it is not uh you know very helpful when mind related or thinking related activities

[4:27:27] are there right something is mechanical it's good to see it's easy to see and you know notice what exactly that person is doing but if that requires a lot of thinking brain activities you know decision making and all then it will not

[4:27:43] be very useful. One more important uh point. If I tell you that I'm coming to your house for lunch or dinner today or you ask me that girl I'm coming to your house, what I'll do the first thing I'll do I'll we'll try to clean up right

[4:27:58] because especially when you have habit of reading you have a small kids it's possible that things are your house is slightly messy. So you will try to fix it up before somebody is coming any guest is coming and that's exactly what

[4:28:12] happens when you ask for job shadowing. what that person will try to do that person will try to show show or demonstrate the best version of himself right he will feel like you know somebody is coming he will notice how I

[4:28:27] work how I function on day-to-day basis so he will try to give you the perfect picture of the situation and in that case it's possible that you know the real problem you might not be able to get so obviously with all these

[4:28:40] techniques there are some pros there are some cons right so that is where you need to apply more than one technique at a time. Okay. So this is where you conduct the elicitation. You try to get the information out of those

[4:28:53] stakeholders. You use your facilitation skills. Okay. Just after that what happens when you conduct elicitation? You get a lot of information,

[4:29:05] right? You receive a lot of data. Whatever you call them, you receive a Whatever you call them, you receive a lot of inputs from the stakeholders. What is the immediate next thing that you do immediately? You document all of

[4:29:19] you do immediately? You document all of this and maybe you will send out minutes and that is what is called confirm elicitation result. What is the purpose of this? Why do we send minutes? What is the main purpose of sending out minutes?

[4:29:31] Status more important than that. Yes, to keep everyone on the same page. Status and action points. Evidence. Yes, that is also important. and keep record of agreed requirement, responsibility. And the most important one is to save

[4:29:47] yourself. Right? It is possible that during the meeting somebody was not listening, somebody didn't pay enough attention and maybe the responsibility then is with you. But when you send uh minutes it means you have documented

[4:30:02] the discussion and mostly what is the last line that you mention that I hope in case I have missed anything or misstated anything please correct me please feel free to add please feel free to update that in case I have missed or

[4:30:18] misstated anything right so when you do this now who is responsible now collectively everyone is responsible so that is the main purpose why we send minutes so that we can document the discussion. All the points are covered.

[4:30:32] All the action items are documented and now everyone whether you listen during the meeting or not. Nobody can give excuse. Now we have the shared accountability of whatever was discussed in this meeting everyone is in

[4:30:45] agreement. So that is why we send out minutes and that this is the third task. So confirm elicitation results. Who you will send this back to? The same stakeholders who join this. Do you think a stakeholder engagement will be input

[4:30:58] a stakeholder engagement will be input to this task? Tell me which of these task will take a stakeholder engagement as input. Which of these tasks? All of them or one of them? All three. What if I just use it in this and then because

[4:31:14] after this I what is the output of this elicitation preparation? So maybe that is also enough that because we were doing another level of planning here. During this planning, I took one input and now I'm using this planning for next

[4:31:29] and now I'm using this planning for next steps. So why do I need to keep looking engagement when that input was taken care within this planning and now I'm using this planning right? Then uh that is confirm elication result. What is

[4:31:43] next? Communicate business analysis You know what is business analysis information? Every document that you produce, right? All these minutes that you create, racy metrics, traceability

[4:31:58] metrics, all of those things that you produce, they all will be communicated to the stakeholders and that is the purpose of this task. Whatever documents you produce, communicate them to business stakeholders. So that is the

[4:32:12] fourth task here. What will be the input? So basically the information that stakeholders that you need to communicate that these are the only two inputs right information and you are communicated communicating them this

[4:32:26] information to stakeholders. So stakeholder engagement approach and information. Now you see I told you in this knowledge area what do you get? Do you get final requirements? No. Right? What is the

[4:32:43] output of this knowledge area? Output of this knowledge area is called elicitation results, right? Or you can say data that you received or info that you received from

[4:32:58] a stakeholder. This is the output of this particular knowledge area. You confirm these elicitation results only. Where exactly you will conver convert them into a proper requirement documents in

[4:33:12] definition a different knowledge area right and design definition. In that knowledge area you will convert this information these results into properly documented well-written

[4:33:28] requirements that's where we create BRD FRD design documents different diagrams FRD design documents different diagrams that's where we do all that but you see the BRD which you will create in this knowledge area if you want to share it

[4:33:41] with a stakeholder where exactly you will come back to this task in this knowledge area why I'm telling you this again so that you can see clearly that these three tasks in sequence. You communicated the information but then

[4:33:57] you are working in a different knowledge area where you created let's say BRD or you created a flow diagram now you want to share it with stakeholders you you in this knowledge area because you this is about communication of your document

[4:34:13] to stakeholders and then final task is manage stakeholder collaboration so that you can [clears throat] achieve the common goal of the project. So these are the five tasks. Prepare for elicitation, conduct elicitation, confirm elicitation

[4:34:27] results, communicate business analysis information. Very simple four task. And fifth one is collaborate with your stakeholders throughout the project. >> And with that we have come to the end of our CBA business analysis course. If you

[4:34:40] the comment section down below and a team of experts will be happy to help time, thank you for watching and keep learning with Simply Learn.