Business Analysis Fundamentals — Step-by-Step Guide & Transcript

[00:08] business analyst professional 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

[00:20] of the most important skills you need to 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 projects. In this course, we will begin

[00:32] by understanding what business analyst really means, how organizations identify 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

[00:45] teams. From there we will dive into the international institute of business analysis sebap certification frameworks and understand the Babok guide which is a foundation for all this course. You will learn about its structure,

[00:59] knowledge areas, tasks and techniques that guide business analyst practices cover important concepts like business analysis, planning and monitoring, stakeholder identification, requirements gathering, elitation techniques, and

[01:14] also selecting the right approach for different types of projects such as predictive, adaptive, and hybrid models. We'll also explore business analysis governance where you'll learn how requirements are approved, prioritize,

[01:26] 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:38] 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:52] knowledge areas, stakeholder management, governance and performance improvement, business analysis and strategic decision-making roles. Before we start your career in data analytics and artificial intelligence to the next

[02:08] level, check out the simple 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 intelligence while building strong

[02:20] 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 like AI agents, automation, and cloud.

[02:34] You'll also dive deep into data visualization, predictive analytics, ETL are essential in today's datadriven industry. By le hands-on experiences through 11 plus real world projects

[02:46] campaigns, churn predictions and AIdriven business automation along with the final capstone project to showcase your skills. Upon completing this course, you'll earn a prestigious certificate from IIT Kpur and ICT

[03:00] 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

[03:13] and start 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:28] strategy analysis, elicitation and collaboration, solution evaluation or is it requirements life cycle management? Drop your answers in the comment section below. So let's get started. >> A person who is playing let's say

[03:42] intermediary role, right? A person who 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

[03:57] which is spoken in that country and 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

[04:12] can't you can't communicate to the 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

[04:27] language local language of that country 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 navigate through the different

[04:40] challenges. You'll be able to enjoy your trip to that country. Right? So that is 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

[04:52] that business guys different stakeholders operations compliance legal they they may not understand the tech part right how the solution will be

[05:04] built how it will look like uh they might not be able to do that on the other hand typical developers may not be able to understand the business language right what they are asking looking for us to build. What is the need for this

[05:20] 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 developers may not be able to understand that. So the problem is same business cannot understand dev

[05:32] developers language, developers cannot understand business language. And that is where we need a translator and that translator is the business analyst. And you know when I was starting my career around that time early 2000 or earlier

[05:46] than that the BA role was not that defined. It was not very properly defined. Mostly you would see that you know a person working as a a tech lead know a person working as a a tech lead or team lead. He would talk to clients.

[06:00] 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 project manager team lead or whatever he would engage with the customer and pass on the

[06:13] 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 this role

[06:25] 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 a business

[06:37] analyst. Okay. So this is 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:51] issues. He's able to translate the requirements, he able to gather the 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

[07:06] 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:19] right it's very important role in today's context from surveys is transactions support etc. They discovered poor mobile experience. They collaborate with it. They define support workflow etc etc. So

[07:36] 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. We'll we'll learn how to create data flow diagrams etc etc. Right? But all of

[07:49] 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 providing you supporting documents. I'll understand better. Right? So it's not just that I I translated what business

[08:06] said and I I just write I just wrote text and pass it on to developers. If 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

[08:20] let's say how to design a screen I'll not just talk about it verbally I'll 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

[08:35] we just discussed understanding enterprise problems goals requirements ments analyze those needs, analyze the solution, devising a strategies, facilitating a

[08:48] stakeholder collaboration, driving change. So all of these things we do. See, 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

[09:03] different projects, they play different roles. It 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

[09:17] also whether you are part of operations whether you are part of a bank or any other organization. So there are so many things and on the basis of these things the on the basis of combination of these things you will see different flavors of

[09:31] of a BA role right somebody will do things which are differently than other things which are differently than other BAS right so you may you should never think that you know all of you in different projects will play exactly

[09:43] same role okay sometimes you will do a lot of stakeholder collaboration sometimes you may not talk to stakeholder your focus is mostly on analysis and solutionizing right so all those var variables and

[09:57] I'll give you enough examples so that you can understand a BA who is who is less 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:11] 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:25] 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:40] 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 company we we all need all of these

[10:56] characteristics right they are not something very unique to a BA Agree or not? So, but why we are me talking about them for a BA? So, for example,

[11:10] 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 cream and he knows that he needs to pay. He he also needs to he he knows that you

[11:26] 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:38] 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:53] 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

[12:05] 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 much much better you will start understand for example I

[12:18] you will start understand for example I am working in banking so I know 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 card right so

[12:32] 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 say in a particular bank let's say JP Morgan now that person needs to have

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

[12:58] even more 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 services they offer and then finally if you are part of a particular application

[13:11] you are part of a 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

[13:25] industry you 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:39] 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 uh stakeholders to elicit the requirements.

[13:54] 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:10] 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:23] 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:36] 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:53] 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 so that is how and and then you run a lot of meetings right you are going to

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

[15:20] and you will have to run 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 different sessions. It will happen multiple times

[15:34] like if you are not good with with uh with this with these skills. People will 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

[15:48] outcome of that meeting. So that's where 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

[16:03] technology everyone needs like we are right now using zoom you we use teams, right now using zoom you we use teams, outlook, jira and in today's AI world we need to definitely use AI tools right there. It's not like it's it's no longer

[16:17] there. It's not like it's it's no longer a choice. it's uh it's uh enforced in organization it's enforced 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:33] 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 techni what tools and

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

[17:01] 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:15] conduct the interview and I'll collect the requirements but in real world it's not that easy some practice some uh experiences is always required. So try experiences is always required. So try to do that. Uh try to uh try to you know

[17:29] 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:45] so there is when I did there used to be only two certification CCBA and CBA certification in the competency of business analysis and certified business analysis professional. A few years back they added ECBA which

[18:00] 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 with without any experience right entry level or something entry certification for business analysis.

[18:13] 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 offered by IIBA

[18:28] that is international institute of business analysis. uh few years back they started uh you know talking about CA Certified Business know talking about CA Certified Business Analyst CBA TL thought leader certified

[18:42] 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 then they dropped the idea I don't know why they wanted to introduce it and then why they dropped I I I have no idea but

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

[19:08] 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

[19:20] think they were uh they launched the 2008 or 9 or something before that there 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

[19:35] existence when they launched this book Babok they try to standardize things. What is the role? How that role should be performed etc etc. So all these three

[19:47] exams they all are based on the same book business analysis body of knowledge. Similarly for PMP we have project management body of knowledge project management body of knowledge pimach here we have bebach all these

[20:01] 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 hours we will cover this entire book and that is why I was telling irrespective of your experience whether

[20:15] you are eligible for CCB or CBAP 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 will be you will be prepared for one of these exams

[20:29] will be prepared for one of these exams automatically. knowledge is a globally recognized standard guide that outlines the core

[20:41] knowledge areas, tasks, techniques and competencies. So the overall Babok is divided into knowledge areas, right? Uh have you ever reading Babok? It is 100% theory. 100 means

[20:59] 100%. 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

[21:14] example. No explanation with 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

[21:28] something like be. So first is enterprise. It is a system of one or more organizations and the solutions they use to pursue a shared set of common goals right and edtech enterprise decided to expon expand its digital

[21:44] decided to expon expand its digital presence. So they are like bigger companies bigger organizations. You already know that organization. It's an autonomous group of people under the management of a single individual. So

[21:56] management of a single individual. So like simply learn it's a company. Now 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

[22:10] kind kind of value that could be delivered if a requirement is fulfilled. delivered if a requirement is fulfilled. So requirement is a is a need that one of the stakeholders one of the person would have.

[22:23] would have. Okay. Um few basic questions. 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

[22:37] sheet, right? And in that time sheet, what do you do? You put your time against a 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

[22:51] working for, right? Or you are doing something for a client. You fill your time sheet for that project and that project on that basis your finance team will build your client and get the money. So who exactly is paying your

[23:04] salary then? Who exactly is paying your salary? client, right? How is your company making money?

[23:17] 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 that's on a high level that is how that that's how things work on the basis of multiple

[23:30] people multiple people like us who are working our company is able to produce something that's that product is sold or that service is sold company makes money and that they pay for our salary but India if you think about it at a high

[23:44] level company is also getting paid paid because we are working right and the client is the person who is paying. So how you should treat your client? You should treat your client accordingly right that they are the people who are

[23:59] paying. Now you tell me what is the difference between difference between uh a customer and end user? Is there any difference between a customer and uh this end user? See my handwriting is

[24:15] 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 you have to put efforts to understand my

[24:28] 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. Your company is the customer of HP

[24:43] 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 a phone. Let's say I want I want I bought a phone for my wife. So I am the

[24:58] 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 requirements both of them can have requirements. End users can have their

[25:13] 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. It focuses on understanding how a solution might realize.

[25:27] 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 are comfortable with terms and your understanding gets better. So if I tell

[25:40] 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 hungry, but what I want to eat is the solution, right? I'm thirsty and you

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

[26:08] will be fulfilled is the solution. I'm thirsty is the need. But what is the solution? Let's say I need uh a lemonade. Lemonade is the solution.

[26:20] Right? So as a business analyst your focus is not just to understand the need. Your focus is also to identify what kind of solution or that is a what kind of solution or that is a stakeholder may need or he should get

[26:35] 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 between the there is also a difference between the uh desires and actual needs. I can I can

[26:49] 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 deliver

[27:04] 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:18] 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:33] 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:47] 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

[28:02] happens, it will have some impact on your project, some impact on you. So that is the that is the risk and with risk there are two things prob probability of the risk and impact. So probability means whether it will happen

[28:17] 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 rupees cash in your pocket

[28:32] then that is the impact. If you don't carry anything there is a risk of rain impacted. Maybe I'll get cold or something but physically there will not be any impact on currency that I carry. Right? So we'll talk about risk and risk

[28:45] risk mitigation. How how we manage risk and how we mitigate risk. We'll talk about all of this. Now look at this this BACCM business analysis core concept model.

[29:00] You see there are these six core concepts need change solution context value and a stakeholder. What has or who is a stakeholder? A

[29:12] group 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:25] 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:41] 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:56] you are uh you have a problem, right? If I fix your problem, you will get some value. you will let's say uh you will feel uh you are able to do your business better you are able to deal with your clients

[30:11] better depending on the solution that I provided right so there is some value to and how you will 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

[30:26] fulfill that need I delivered a solution when that solution got delivered a stakeholder got some tell you right you had uh you you were hungry and that was had uh you you were hungry and that was your need I gave you a very nice drink

[30:41] and when you had that you felt happy you felt like you you you were not thirsty felt like you you you were not thirsty anymore so now what is the change in order to deliver that solution you will have to go through a change right

[30:56] so what is there are these two terms which you should know if which you should know if As is, what is your as is? As is, what is your as is? As is and to be. As is is also called

[31:10] your current state. And this is also called your future state. So current called 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

[31:25] into that. That is my future state. Right? Current state and future state. 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

[31:39] packers and movers to pack my stuff from my rented house, move to move me to a new house. So there is a complete transportation and everything. So this is called change, right? The process or act of transformation which will move

[31:54] 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

[32:07] solution. When that solution got delivered, stakeholders got the value. Right? Now what is context? All these five terms are easy to connect. What is the context here? Incope and out of scopes. Incope means things that you

[32:22] 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. Okay? And when we create requirement

[32:38] documents, we all also create sections where we clearly mention that you know these items are in scope, these items are out of scope. For example, you are [clears throat] you are going to construct your house

[32:53] 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 interior designing is out of scope. So whatever cost that you are paying this

[33:07] 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 that is why you have to mention that in document so that it's it's it remains

[33:22] clear what is in scope, what is out of scope. Now tell me now let's see who can answer this question. When you are creating this agreement for When you are creating this agreement for your houseport

[33:42] Is it in in in scope of your house project? project? No. Right. It's not building a hospital nearby. Is that part of your individual houses project?

[33:54] No. Right. Similarly, building a new school because you are talking about your own house. You're not talking about setting up a entire neighborhood. You are talking about building your personal

[34:07] 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 mention them in your document that you know I am building my house so

[34:20] walls, ceilings and everything is in scope but hospital, railway station and all of that is out of scope. Do you write that? We don't write. If you start writing all of these things, your project document

[34:32] will become encyclopedia. any everything in United States is out of scope. Everything is in in Australia is out of scope. Everything outside this city is out of scope. So everything on this planet is out of scope except this

[34:47] 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 write out out of

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

[35:15] 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:31] 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 school because that's not the context right

[35:45] because that's not the context right somebody like uh you know uh let's say Shivam says you know GV 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:59] 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:13] anything then 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 a that's not the context that's not in scope So that is how these these

[36:30] six terms are very much related and they are interdependent. I hope you are able to relate them. Now you know uh to relate them. Now you know uh stakeholders would have need or needs in

[36:43] order to fulfill their needs. You will 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

[36:59] right now current state and future state. So as is and to be these two terms are also very very important. All these terms are very important for BAS. Business analysts can use the core

[37:13] concepts to consider the quality and completeness of the work. Right? What kind of changes are we doing? What are the needs? What are the solutions? Who stakeholders consider to be of a value? Right? What are the context that we and

[37:28] solutions are in? So all this all these six terms, they'll help you ask right questions and complete the requirement work. Okay.

[37:45] earlier, this be 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

[38:00] the introd introduction bit. So that is fine. There is one chapter which is fine. There is one chapter which is called perspective. So IT perspective, agile perspective. So that particular chapter is not tested

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

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

[38:42] 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

[39:01] 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:16] 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:31] Elicitation. What is the meaning of elicitation? collecting the requirements. Right? Now, have you heard the term requirement

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

[39:57] 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:15] 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 do you think requirements are lying down on the floor or lying down on on a table

[40:27] where you go and just collect them so gathering means collection ction so gathering means collection ction right collection is not it's not like you just go and stakeholders are ready with their requirements and they'll hand

[40:39] it over hand them over to you that is not so from the process point of view requirement gathering is not a very appropriate word what is the meaning of elicitation to bring forward right to ask right

[40:54] questions and bring the requirements forward not not just because somebody is telling you But because you are probing, you are asking right questions, you are cross, you are crossqu questioning the needs, you are trying to assertain that

[41:09] actually you have these needs and things like that. Right? So instead of oneway you the requirements and you are just documenting them instead of that you are it's a proper session two-way communication, two-way probing, a

[41:24] discussion, debate and then you get the requirements. That is the English meaning of elicitation and English meaning of gathering we discussed right. So now once you understand the exact meaning

[41:37] then you you you know that elicitation is a better term because for requirement gathering you will not get the salary right you will not get enough salary for salary as a business analyst because you perform elicitation not just gathering

[41:52] anyhow people will keep using these 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

[42:07] and collaboration knowledge area you actually perform elicitation in the first business analysis you planned how you will perform elicitation here you actually perform elicitation then what what do you think will be the

[42:21] output output of elicitation when you perform elicitation what you will get? Yes. So you get a lot of information, you get a lot of data, right? In order to convert that data or the information into proper

[42:36] requirements, you perform requirement analysis and design definition. Right? So outcome or output of elicitation is not like final requirements that is opinion of the user, information or inputs from the user, feedback from the

[42:51] 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

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

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

[43:31] identify the requirement their life cycle will start. So life cycle will start as soon as they are identified and till they are delivered and also after that uh for their maintenance similar to the humans

[43:47] 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 requirement can change. Requirement

[44:00] itself can change. Some of the other things related to requirements like priority right can change. So as a business analyst you gathered requirements your job is not done. Uh you have to maintain those requirements

[44:14] throughout their lives. So that is done in requirement life cycle management in requirement life cycle management and uh uh solution evaluation is what

[44:26] you deliver what is built that you need to evaluate whether it's performing as 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:42] 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:56] 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 repeatatively iteratively right that you

[45:11] 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:23] identified so solution evaluation 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 order you perform these knowledge areas or

[45:39] uh at a organ at at the organizational level a strategy analysis was was performed let's say where you did root cause let's say where you did root cause analysis or you performed uh

[45:52] analysis or you performed uh um what what what do we call it uh a strength weaknesses sort analysis and uh after that sort analysis you found out an opportunity and you launched a project. So you see a strategy analysis

[46:05] was performed then elicitation and planning is done. So depending on the nature of the organization and project these can be performed in different orders. Just remember that and you will understand it later slowly. Right?

[46:21] So these they all are interlin right? All six knowledge areas. Now one more 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

[46:37] remaining have five tasks each. So there are total 30 you can say 55 four and are total 30 you can say 55 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

[46:49] knowledge areas, right? All these knowledge areas have 30 tasks knowledge areas have 30 tasks and there are in total 50 techniques.

[47:06] There is between task and techniques there is many to many relationship symbols but let's say there is many to many relationship between task and techniques. One task can use one or more techniques. So let's say no

[47:22] uh elicitation right in order to perform for this knowledge area what could what can be the tasks prepare for elicitation

[47:34] prepare for elicitation conduct elicitation document elicitation result etc right so this task let's say conduct elicitation this task let's say conduct elicitation is a task under elicitation knowledge

[47:49] conduct elicitation task can be performed using multiple techniques like performed using multiple techniques like interview,

[48:12] 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:26] technique can be used in multiple tasks like conduct elicitation can use workshop. I want to review my requirements. I want to provide a walk through to stakeholders about my requirements to take this sign off. I

[48:39] want to evaluate these solutions. So in 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 and techniques. One task can be can be

[48:53] 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 is organized. Six knowledge areas, 30 tasks and 50 techniques. Okay.

[49:10] 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. So task is like

[49:22] name of the task 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

[49:35] see a description you can have a purpose. 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

[49:50] task, what are the key elements, what are the key elements, what exact what exactly is done, what exact what exactly is done, techniques used

[50:02] headings like additional inputs, additional something. So basically every task that you perform there will be some inputs which you will

[50:14] use. You will do some processing here inside this task. In order to do this processing you will use some techniques and then there will be output of that task. Right? So each and every task in Babok

[50:28] Babok is 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

[50:43] for each and every task 30 tasks right uh what you need to focus on do you need to remember everything no what you need 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

[50:56] which is here we focus on 50 techniques technique is something that you actually 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

[51:11] also to pass the exam and throughout this course every every time we'll not talk about you know what is the input what is the output you will after some time once we covered 15 20 tasks you will start guessing the input output

[51:25] 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 understanding the key elements of the task what exactly the task is doing.

[51:39] 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 have absolute clarity on 50 techniques. These two things we need to focus

[51:53] obviously I'll explain why these inputs, why this output, why this input to this this that particular task. All that we we'll discuss but you don't have to

[52:05] worry. So generally what happens people will say see sir there are 30 task in case there are four inputs so there will be 120 inputs and let's say there are 80 outputs how will I remember this all 50 techniques can be used by different

[52:20] different tasks so there can be 200 types of permutations combination how will I remember them so that is what I'm telling you you don't have to remember you don't have to memorize inputs outputs techniques stakeholders no you

[52:34] don't have to memorize exam you just need to focus on understanding key need to focus on understanding key elements of a task and in isolation all 50 techniques you need to understand rest everything will come automatically

[52:46] 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 there are

[53:02] 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 them in our content right from the babok

[53:18] 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 find them getting used in our material.

[53:35] Okay. Uh, answer this quickly. Which of the following is not a component of business analysis core concept model? We didn't discuss. Content was not there. So, content is the right answer.

[53:47] I think there was one more question on the previous slide. the previous slide. Yes. What does BACCM stand for? Yes. Business analysis core concept model. Which of the following is a business

[53:59] analysis knowledge area? Which of the following is a right not? It's not like not which is not. Correct answer is A. Right? Elicitation and collaboration. See if you consider the

[54:14] previous version of Babok 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 changed. So elicitation collaboration is there. So that is the correct answer.

[54:27] Enterprise analysis has become strategy analysis. Right? Solution assessment and val validation became solution evaluation and requirement analysis and life cycle management. Right? So these three B, C and D they used to be the

[54:42] 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 answer which of the following is a stakeholder in typical BA engagement

[54:55] all of them are your stakeholders. Next is IIBA stands for the international institute of business analysis a globally recognized

[55:07] professional association dedicated to supporting and advancing the discipline. It was founded in 2003 Ontario Canada based and publication major publication is Babok guide and how does it define the standard through the

[55:22] Babok guide identifies the skills necessary to be effective through the IIBA business analysis competency model and self- assessment tools and there are these three certifications that we discussed. So if you go to the website

[55:36] 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 available for members only. So you can use them like business analysis

[55:51] competency model or there is a self assessment tool. So you can use that uh IBA membership uh it provides access to exclusive content and support. So if you take the membership you can get access to career

[56:06] 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 free access to new versions of Babok as well. You can participate in different

[56:19] 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 Babok things like that. So at in those e

[56:33] in there also you can get some volunteer opportunities also that also there are many webinars that they run some webinars are public some webinars are members only. So that is also another benefit of taking

[56:49] is also another benefit of taking membership right now if you are planning 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

[57:02] think of not renewing it. That is fine because if you take membership the cost 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:15] are a member right we'll just see on coming slide. So see there are three first is entry certificate second is certification of capability and third analysis professional. So this is the basic one. This is the

[57:29] 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 CBA you

[57:41] Then what is the difference? For CBA you 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?

[57:56] 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:10] weekends uh 104 Saturday Sunday then you have 15 20 national holiday public holidays then you have your sick leave annual leave so I think if we reduce all that conservatively we work for

[58:26] roughly 200 days 200 days 220 days. So conservatively I 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 if I round it off let's safely

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

[58:51] prior business analysis experience. Five years So that is the expectation that is the eligibility criteria for CE experience into six knowledge area. So

[59:06] or 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

[59:20] training that we are conducting right now, the class that you are in right now, this will give you 36 or 38 hours or maybe 40 hours of PDUs, professional

[59:32] or maybe 40 hours of PDUs, professional development units. So this training that you are attending with me right now, this training is a prerequisite. You need to complete this training or from some other vendor that is fine. But at

[59:46] least there has to be at least one training which uh you attended at least for 35 hours, right? And that training completion certificate is important. So that is why I was telling you yesterday that from s from the portal LMS portal

[59:59] you need to download your completion training completion certificate and that certificate you have to upload when you apply for CWEP exam right. So you will get the PD. So this is the second important requirement. And third one is

[1:00:13] references. You have to provide two references. references. Now they can be uh your managers right current manager previous manager so that is fine if you are a fresher you

[1:00:26] don't have a manager or something then you can provide reference of anyone who is already CBP certified if somebody is your manager they don't have to be CEB certified right your manager without certification is fine but

[1:00:40] otherwise you can provide contact of anyone who is CE certified so what happens when you provide the me reference they will get email from IIBA

[1:00:52] 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 that so they need to respond so when whoever you provide as your reference whoever you

[1:01:07] 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 CBA web. So once when you get the email from IIBA, please respond to that email. Right? So these

[1:01:22] 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 attended a training 8 years back that will not be counted. So something which

[1:01:36] years that training and then your reference. These three are the main requirements. Now what happens when you if you don't have that experience so next certification is CCBA right so there

[1:01:51] certification is CCBA right so there this requirement will be just half 3750 hours so that means you can say 2 to 3 years of experience is enough right and then you can equally divide this by half this requirement will still be there but

[1:02:07] I think number of hours will be less 20 or 25 hours of training is required will I think you need to provide reference. Then for ECBA this is not required. No experience is required. Uh

[1:02:23] they are considering that you are fresher. You have no experience. So you might not have any professional references to provide. So for ECBA requirements are very very lenient and the question paper is also slightly

[1:02:37] simpler as compared to CC cap and CCBA obviously because you don't have that kind of experience. So what I would suggest the important part that go to iBA.org ORG portal. Okay. And

[1:02:53] check let me also tell you one more thing See this is the fee for ECB exam. Okay. this is the fee for ECB exam. Okay. Application fee none. Examination fee is

[1:03:08] $195 for members and $350 for non-members. How much is the difference? non-members. How much is the difference? almost 100 or not almost exactly $155 almost 100 or not almost exactly $155 is the difference in the fee for ECBA.

[1:03:28] 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:44] the total cost if you are a member is roughly $400, right? $395 and without roughly $400, right? $395 and without membership it will be exactly $550. membership it will be exactly $550. For CBA the fee is almost similar to

[1:03:56] For CBA 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:08] more. So total fee for CBAP if you don't have a membership is $650, have a membership is $650, right? And for a member it is $500, $495. Okay? So you save almost $155

[1:04:22] in the fee if you take membership. And 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 all the countries into three categories

[1:04:38] 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

[1:04:51] 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 the exam at the

[1:05:06] 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

[1:05:18] revised any prices earlier it used to be $50 $60 let's see region one 155 USD region 20 100 USD and region three 60 USD. So if you see countries this there

[1:05:30] USD. So if you see countries this there is a list of countries. So for example India is in region three. So you pay $60 and you save $155

[1:05:43] on your exam. So you will still end up saving $80. People who are in this uh in these countries they'll they'll still save. People who are in region one

[1:05:55] save. 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 same cost you will get the benefits of membership along with the exam. Okay. So

[1:06:09] this is on the membership. If you take if you look at the certification IIBA certifications so they are they they started offering other certifications on data analysis and others but from the BA point of view

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

[1:06:38] 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 so there are no requirements sorry uh

[1:06:53] this includes IBA membership. See this is fine. There is no eligibility criteria as such for ECBA right

[1:07:14] let's go back and check for CCBA. 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

[1:07:27] difference is in experience and trainings right and for CV I already 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:43] yourself make yourself comfortable with the portal and identify which certification certificate is more suitable for you right now what will happen after 3 years so all these certifications are valid for 3 years

[1:07:57] after 3 years you have to renew the certific certification in order to renew it it's not you have to pass the exam again you can just keep accumulating again you can just keep accumulating your PDUs like now we said professional

[1:08:11] development units Right after passing the exam, we call them continuous development unit. So you keep accumulating CDUs by reading something by uh by attending some trainings by volunteering

[1:08:26] 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

[1:08:38] go for CCBA. So that is how we need to manage this. manage this. So the first chapter proper chapter or the f second uh lesson number two is business analysis planning and

[1:08:53] 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 big for example planning and monitoring

[1:09:06] definition they are very big. So they are divided into two two one parts. Some of them are in one part. Some of them are are in two parts. Okay. So what did I tell you yesterday that there are six knowledge areas, right? And the business

[1:09:22] 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:36] 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:52] planning some bit of planning is always 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 always required right. Uh so that is

[1:10:08] what we cover in this particular knowledge area. The planning bit see there is this scenario given in 2016. What would phone UK ran into serious trouble while migrating its CRM system because of migrating the system without

[1:10:23] a structured validation approach not involving key stakeholders in planning and testing. weak governance, oversight and risk planning. This led to billing errors, customer complaints and 4.6 million fine from offcom. This this

[1:10:39] offcom must be a regulator. If you were leading the analysis effort in this project, how would you plan and manage your work to avoid such outcomes? So view, what do you think is wrong here or was went in in incorrect or wrong

[1:10:53] direction? See there was no validation approach approach not involving key stakeholders planning. All of these things are some of them are specifically for business

[1:11:06] 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:18] 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:31] 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:47] 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 we'll cover many of those things in this course and BA will interact with the

[1:12:00] for solution validation for writing acceptance criteria to take their help in supporting in testing etc etc. So BA's engagement is slightly different

[1:12:13] than the project manager engagement even though there will be some overlap 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

[1:12:25] Okay. Uh now why this is required? Uh we always say that you know if you identify 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

[1:12:39] project they get difficult and more expensive to to fix. So let's see uh if 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

[1:12:55] let's say point A and you want to go to point B but there is no map nothing so you start 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

[1:13:08] course I need to correct my path and I need to change and go to B. Now what difference in one more case? Let's say you moved further away and here you realized that it is wrong direction and you have to

[1:13:24] correct and go to point B. Now what do you think? What is the difference? If you talk about time, if you talk about money, both will change right here. it if it was supposed to take 1 hour and let's

[1:13:39] say 500 rupees in in in taxi now it because you have to travel this much it will take maybe one 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

[1:13:55] right time required is more fuel required is more so overall money required is also more so that is the main problem who will help with this main problem who will help with this direction. What exactly is required?

[1:14:09] What exactly do we need to build? Which direction do we need to move to? Those things are dependent on our nice business analyst, right? He is the collect the requirements, who will tell the requirements, who will have the idea

[1:14:25] what to build as a solution, right? So the overall road map etc. He'll have a 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.

[1:14:38] business analysis is very important. Otherwise if you start with wrong 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

[1:14:51] here. So business analysis is a structured approach used by business 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

[1:15:06] current state of business. Identify the needs or problems. Design the right solution and ensure solution delivers value. I told you yesterday what is the current state? Your current estate, right? Or your

[1:15:21] solution or application's current estate. I I live here that I live in Pune. That is my current estate, right? Uh I live in a particular apartment that

[1:15:33] is my current estate right. I have to move. I switch my job and I now I need to move to I need to go back to Guru Guruga where I lived for

[1:15:45] 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? is my current estate right? This is my future state.

[1:16:04] different problem that before covid uh it was manageable to live let's say in a two-bedroom apartment or one bed bedroom apartment if you were married you were living or maybe you were single but living with your parents did you

[1:16:19] notice that after co when we had to work from home study from home suddenly whatever apartment we were living living in whatever house you were living in it in whatever house you were living in it started you know feeling small because

[1:16:32] we had to work from home we had to study from home. So did you feel that 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

[1:16:47] home some of the days and then I used to take trainings also. So suddenly 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

[1:17:02] identification of need or problem that I because of the lack of space I need to 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:20] Right. So then what what could I do? 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 fourbedroom house depending on your

[1:17:33] fourbedroom house depending on your family members etc etc. So in that case 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

[1:17:46] that you will identify it is going to impact them right or you you your if you have kids they might say I also need my separate room or your parents might say sure you shift to ground or first floor you don't go to 10th floor or 20th floor

[1:18:03] they have their own concerns they have their own requirements your spouse says that I want a better you know um a kitchen or I want test or I want a separate study. So you know suddenly because there is a project there is a

[1:18:17] there is a plan to move from our current estate stakeholders which are who are impacted or they can have their own requirements and on that basis we create the solution right and when you move right from one

[1:18:33] 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 the same building let's say across the hall uh do I need

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

[1:19:01] in this case I need so you see depending on the solution the approach will also 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:17] 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:31] 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

[1:19:43] to move from current state to the future 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

[1:19:55] myself. So there can be multiple solution options as well. But all these things I'll take uh I'll I'll explain in more detail in coming classes. Okay.

[1:20:07] 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 things we'll cover in greater depth in coming classes.

[1:20:22] areas. We already discussed uh six of them yesterday. and monitoring. So BAPM is the knowledge area that

[1:20:35] defines the tasks associated with organizing and coordinating the effort of business analyst and stakeholders. Right? So this is all about planning, organizing, coordinating. Here you do not perform the tasks. Here you do not

[1:20:50] actually start the elicitation. Okay. Now what happens when you so the primary Now what happens when you so the primary goal of BAPM to define the approach to identify and involve right stakeholders to establish governance

[1:21:04] mechanism for decision- making and change control to plan how requirements and related information will be managed to evaluate and improve business analysis performance. So these are the primary goals and these goals are

[1:21:17] divided in different tasks. So the first task will be about approach, second will be about identification of the stakeholder. So basically these five primary goals will convert themselves into tasks of this knowledge area. Okay,

[1:21:30] we'll see them one by one. So proper planning prevents poor performance is the key objective of this phase, right? The first phase of planning. Imagine being handed a project but not knowing what problems you are solving, who is

[1:21:43] affected, who decides what and how to structure your work. Without answering these questions, can you uh move ahead in your project? What do you think? If you have no idea what exactly is the problem, what will

[1:21:59] you fix? Right? Who are 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 to take the approvals, who is the authority, you can't work without that.

[1:22:12] Who will fund the project? Who will approve the budget? All those are structure your work, how to organize the information, uh depending on your depending on your uh organization, whether you are going to use Jira or you

[1:22:27] are going to use SharePoint etc etc all those things you need to have some idea right. It's not like you cannot start working without having answers to all the question. As a business analyst, as a

[1:22:41] program manager, we have to move ahead. If if all the information is not available, we make some assumptions and move ahead, right? But at least some idea has to be there. So this is the purpose of this knowledge area to get

[1:22:56] the idea or to get the answers to all of these questions which are mentioned here. Now as I explained you yesterday every Now as I explained you yesterday every task will have certain inputs

[1:23:10] they will tell what exactly is uh performed key elements and output. So performed key elements and output. So like for example this knowledge area has analysis approach plan stakeholder engagement governance and so on so

[1:23:27] forth. So these are the six five tasks in this knowledge area. Right? We'll go through them one by one. Outputs and inputs we'll also see for each and every task. This is a screenshot or picture from the

[1:23:41] This is a screenshot or picture from the book it book itself. So you see majorly the inputs to all of these tasks are needs and performance objectives. Output needs and performance objectives. Output are these five. Right? So uh in the

[1:23:55] beginning of every knowledge area you will see a collective snapshot like this where there are all the tasks mentioned of this knowledge area all the inputs and all the outputs. However we have to go through each and every task in detail

[1:24:11] and we will see input and output specific to that task. Okay. So out of these five that let's see the first task. It is the first core task of BAPM knowledge area in the Babok guide.

[1:24:26] Before identifying or writing requirements plan how how you will approach the work choose the right methodology define the detail level assign roles and set up progress reporting. So before we go into details

[1:24:39] reporting. So before we go into details let's see the different parts let's see the different parts or sections. As I told you, every task is uh every task has a fixed template, the same template which is used across

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

[1:25:10] 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:26] just to simplify uh I always call them additional and optional inputs. Right? So you can say guidelines and tools are additional

[1:25:38] inputs. You use them if they are available. For example, business policies. It's not mandatory that you will always have business policies. It some of these things. You will see different guidelines and tools

[1:25:52] 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 Inputs are mandatory. Uh this is the name of the task output and uh there are

[1:26:07] two things the input can. So what happens? Let's say there is input, right? This input is going into this task.

[1:26:26] 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:43] 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:58] 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:13] external coming from outside not they 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 uh when you read web

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

[1:27:43] 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 see in this knowledge area all the tasks

[1:28:00] are using this input. Next knowledge area prepare for elicitation, conduct elicitation, they are also using this output. Even manage stakeholder collaboration, analyze current state, define change

[1:28:13] strategy, assess risk. So many of the tasks in this overall web are using this output, right? So that is what you need to understand that every output will be used by multiple tasks right you will

[1:28:29] understand why when we'll when we'll go into task in detail you will understand into task in detail you will understand why that is important uh and important input to other tasks. Okay. Apart from that there are other headings like uh

[1:28:44] tools and guidelines we have covered bas main or uh main elements. So there you will they'll explain what exactly this task all about right. So the core element or basic elements will explain what exactly this task is all

[1:29:01] about and then there are uh stakeholders and techniques. So these are these are the headings or

[1:29:13] 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 stakeholders. You can just you read it but you don't try to memorize it. Okay.

[1:29:28] You have to focus on elements a lot. You need to be very clear about elements. You need to be very clear about techniques. Now which techniques are used in this particular task? You don't have to memorize. You will start

[1:29:41] understanding and guessing yourself. What are the inputs to this task? Again you don't have to memorize. You just need to understand the purpose of task. you will automatically start guessing if this is the task what kind of inputs

[1:29:54] 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 business analysis approach if you are planning something the output will be that something right

[1:30:07] so you know an approach is the output so you don't don't have to memorize if you understand the concepts if you understand elements and techniques you will start answering the questions without mugging up, without memorizing,

[1:30:22] especially when you see four options, then it becomes even easier to guess the then it becomes even easier to guess the right option, right? Right answer. Clear? So, the first task which talks about planning uh the business analysis

[1:30:37] approach. What is the approach in this context here? The approach that we are talking about is whether it is uh adaptive approach or productive approach. Now what is the meaning of

[1:30:52] productive and what is the meaning of adaptive? So the business analysis approach should align to the overall goals of the change aligned with the project approach. Right? You cannot have business analysis

[1:31:08] approach which is not aligned with overall project. Your business analysis is part of the overall project, right? It is just one phase of the overall project. So your BA approach, timelines, etc., they have to be aligned with

[1:31:22] etc., they have to be aligned with overall project. Now, uh you co you with the activities and deliverable of the overall change, right? Change and project. That's what I'm I just explained. So what is the adaptive

[1:31:35] approach? If we put it in more into project uh perspective, see uh predictive used to be we used to waterfall SDLC right development life cycle. Agile

[1:31:52] is called adaptive. So when I say 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

[1:32:06] project 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

[1:32:18] then you will start with requirements then then you will have design then you will have development then you will have multiple phases of testing then you can multiple phases of testing then you can have deployment or release then you can

[1:32:32] have deployment or release then you can have maintenance [clears throat] Right. These are the phases on a high level uh sequence will remain almost the same and they are called waterfall. Waterfall or sequential because they are

[1:32:46] in a particular sequence. This handovers are very well defined. Design will start only when requirements are completed. Right? When business analyst would say they they have they have completed the requirement, you can

[1:33:00] 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 this is called productive because planning is done almost everything is

[1:33:15] should be planned in the beginning of the project and the flexibility is not that much there right so this is called predictive and right so this is called predictive and what is adaptive adaptive is agile right

[1:33:30] 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 priority items comes from the backlog, you keep building them, delivering them, again

[1:33:43] you pick, again you build, again you deliver. So that is why adaptive is called iterative and incremental, right? Iterative means you do the same thing again, then again. So you are repeating the same thing. You pick items. So you

[1:33:59] perform requirement anal 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 requirements you pick requirements from here two three

[1:34:15] requirements from top of the pre backlog you keep picking you keep delivering and you keep taking feedback. So here the major difference the most important difference is that this is not sequential. So even the requirements are

[1:34:29] 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 requirement analysis for all 50

[1:34:44] 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 requirements three requirements depending on the capacity you work on

[1:35:00] them deliver them then you pick next four so the batch size is reduced 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

[1:35:15] in your master's program you would have a separate course on agile but why we 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 an approach whe

[1:35:29] whether you are taking productive or adaptive is going to have impact on your business analysis activities. Now you tell me if you talk about timing Now you tell me if you talk about timing of business analysis activity timing do

[1:35:43] you see any difference in waterfall or 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

[1:35:57] analyze all the requirements in case of agile it will be ongoing requirements ments. So that is the that is one of the most important impact on

[1:36:09] the business analysis work whether you analyze all of them or you will do in What is what is the impact on the formality create? Waterfall or traditional is very very

[1:36:26] Waterfall or traditional is very very formal. This is less formal. So in case of waterfall we used to create very extensive extensive BRD. It will go through a very uh you know

[1:36:39] It will go through a very uh you know proper 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

[1:36:54] create epics features user stories. You can still create documentation. It's not like but agile says you can do with less documentation as well. So that is fine. waterfall BRD if I wanted to create a screen wireframe I'll have to create a

[1:37:09] proper screen wireframe. I'll upload it 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

[1:37:23] etc. I take this snap a screenshot of this 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

[1:37:37] documentation that you create is also different. Right? So the point is the first the first task itself talks about what is the approach in your project. what is the project approach on that basis your

[1:37:54] approach will also be different so that 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

[1:38:08] using agile your business analysis 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

[1:38:21] with them slightly differently. In case of agile, you will do your work slightly 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,

[1:38:35] formality of the documentation and what about a stakeholder engagement is it same or different? So in case of waterfall where exactly stakeholders in the beginning of the project. So it's possible that for one

[1:38:51] month when you are performing your requirement elicitation 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 but you

[1:39:05] week to perform your requirement grooming sessions to complete your planning and you know review etc etc so a stakeholder should be informed that engagement is required in this project this kind of engagement is required

[1:39:19] this kind of engagement is required Now tell me is it like your decision as a business analyst which approach should be used in the project it's not your decision right it's collective decision maybe a sponsor can

[1:39:32] can they can take your inputs that's fine but it's not your decision so 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

[1:39:46] impacted so that is more for you to understand and work accordingly. Okay. So [clears throat] that is the

[1:40:01] depends upon case to case and the methodology it see what happens in the project whether it's waterfall and agile that is different thing what I'm saying

[1:40:14] 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 or FRD and in one case you might just create Jiraas. So as a business analyst

[1:40:30] you should be comfortable with both both creating creating accept uh you know uh extensive documentation or creating light documentation engaging with the stakeholders in the beginning to cover all the requirements or engaging with

[1:40:44] the stakeholders every now and then uh you know iteratively to collect the 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:56] depends on the project whether it's 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 I had to create BRD. Then for

[1:41:11] 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 right

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

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

[1:41:54] 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:10] Uncertaintity is high. This will always be very chaotic right a very problematic because here even you don't have clarity on requirements you don't have clarity on solution so this is the most problematic part here you need rapid

[1:42:24] 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:38] 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:53] 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:08] continue you are free to adjust these requirements change these requirements once I'm done then give me the clarity. So we are giving a lot more time to the clients. We are giving a lot more flexibility to the client to keep

[1:43:20] changing whatever we are not working on right now and give us clarity on just pure requirements. Right? So that is uh that is the benefit where you have you have uncertain requirements or unstable

[1:43:36] 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 for

[1:43:50] 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:44:03] 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

[1:44:15] of feedback from client. So in that case 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

[1:44:27] additional benefits of using agile in 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

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

[1:44:58] 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. So that is fine. Even in these projects you use agile no harm. But

[1:45:15] 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 the clarity on the solution etc etc

[1:45:29] 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 uh predictive is plan driven adaptive is change-driven and hybrid a combination

[1:45:45] of both. But as a business analyst, you should be able to work in both the environments. You should be able to create both kind of documentation and you should be comfortable with both uh engagements, more engagement and less

[1:45:57] engagements, more engagement and less engagement with with the client. engagement with with the client. So see there is a scenario a tax department is upgrading its income tax filing. So let me first do one thing.

[1:46:10] Let's first close that. Let's discuss 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

[1:46:22] shaped by the problem or opportunity faced by the organization. It is 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

[1:46:35] business needs. What is the need? Why we are doing this project? And that is all 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

[1:46:50] idea of the business needs. When you are starting a project uh when uh resources are allocated to the project, BAS and others are allocated to the project that means some bit of discussion already done. Right?

[1:47:05] Traditionally it was like project managers or sponsors they would have would have discussed the business need and it it is also possible that project business case to take the approval of the funding approval on the funding

[1:47:20] 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:33] 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:47] multiple times see whatever we are learning here is whatever is there in learning here is whatever is there in beok is pure theory it's purist approach right however in projects you will see practical things you will see practical

[1:48:01] scenarios you will see p different problems right here it's it looks like decision along with PM but you don't know what kind of organizational

[1:48:13] approach is there what kind of 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

[1:48:26] scenarios in project. So depending on the business need you decide what is the approach that is why business need is the only input to this available. Then we have key elements right planning

[1:48:40] 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:54] 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,

[1:49:08] requirement elicitation, process modeling, all of these things are performed in both but they might have slight variations. Right? In case of All all of them perform together in the beginning and things like that. So next

[1:49:23] point is timing of the analysis work. Clear? So these four things I explained that's why I said key elements are most important part of a task. In key elements they describe what exactly we are doing in this particular task. Okay.

[1:49:40] the level of complexity and risk associated with the initiative while you decide the approach. What is the complexity? What increases the complexity or risk of the project? Uncertaintity. If you if you don't have

[1:49:55] 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 complexity that that will add right and whatever is the approach you need to take the acceptance

[1:50:07] from these stakeholders they should be informed and they should be happy with the approach right because they need they also need to be engaged. After this you will see some guidelines and tools

[1:50:22] 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:34] 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 are anyway optional in nature. I mean

[1:50:46] sometimes they are available, sometimes they are not available. For example, business analysis performance assessment. What does that mean? This means nothing but lesson learned. We'll we'll have a diff different task

[1:50:59] only for this so you will understand better. But for now consider it lesson learned. What does that mean? Lessons that you might have learned from the that you might have learned from the previous project. So is it mandatory to

[1:51:12] always have lesson learned? It's not right. Maybe it's first project of that kind. So you might you might not even know uh if there are any u you know uh Similarly if there are lessons learned available you should learn that in this

[1:51:28] project in similar project I used waterfall or agile or these were the 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

[1:51:43] says we need to use waterfall or we need to use agile then we have to use it right. Expert judgment. If there is expertise available who worked on

[1:51:55] similar projects they can also be provide inputs which approach to be provide inputs which approach to be taken in this project. Right? Methodologies and framework available in your organization. As I told you, if

[1:52:07] there are some approaches, some methodologies, frameworks already used it's mandate that everyone should use them, then obviously we'll have to take care of that. And stakeholders can also tell you tell you about their concerns,

[1:52:21] somebody sometimes it's possible that a stakeholder says I'm not available every cannot spend that much time every two weeks. Right? So, you need to take a weeks. Right? So, you need to take a stakeholder into considerations as well.

[1:52:36] 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 will take the make the decision without them. So there are some questions let's

[1:52:50] go through them there is a scenario a global healthcare provider is planning to implement a new digital system to manage patient data across its network of hospitals. The system must meet a strict regulatory and

[1:53:06] compliance standards, adherence to HIPPA privacy laws, support for external securities, audits, usability for a multilingual workforce and patient base. The project involves coordination between different teams.

[1:53:22] The goal is to ensure accurate documentation, data privacy and user-friendly experience for diverse stakeholders. Given the regulatory and compliance needs, what type of business analysis approach predictive, adaptive

[1:53:35] project? So this is the scenario and see the question itself wants us to say it's productive, right? Because it they're

[1:53:48] trying to emphasize that it's regulatory 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

[1:54:02] question like this it's like the answer 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 it's regulatory heavy documentation and

[1:54:18] in this question it's not mentioned that you know you have to hit and try and identify these the solution you might have to do a lot of PC's or uh spikes. have to do a lot of PC's or uh spikes. So we need to answer accordingly what

[1:54:33] 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 iterations required where you will users

[1:54:47] 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 PC's etc. Then obviously you'll have to go with uh agile right or adaptive. Next

[1:55:00] question. You are working on a national level transportation system initiative due to high criticality and government oversight. The documentation must be oversight. The documentation must be extensive and traceability is a must.

[1:55:13] define the structure and documentation 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 B

[1:55:27] effort for a low-risk internal HR dashboard where stakeholders are coll-located and feedback is continuous. The team follows agile sprints. What level of formality and documentation is

[1:55:40] most appropriate? They have already mentioned that stakeholders are coll-located, right? Uh they are following agile and it's a very lowrisk internal HR dashboard. Right? So there is no

[1:55:54] regulatory oversight. There is no audit requirement mentioned here. So correct answer is informal with lightweight documentation. If it would be for external clients maybe regulatory clients or if there is a formal audit

[1:56:09] it would be different but because it's internal and also stakeholders are 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

[1:56:24] arrangement where they get the status of the project but in this case they are 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

[1:56:38] stakeholders? Everyone who is impacted by the project and everyone who can 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:54] need to know uh who can give you the requirements, right? Depending on whether it's internal project, external projects, you can have different stakeholders. So who will give you the needs? Who will share with you

[1:57:07] the problem statements or the needs? 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

[1:57:23] say there is a new project uh and your project manager calls you 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

[1:57:38] stakeholders you need to engage with them but you can engage when you know who are your stakeholders. So considering this scenario, how will you start your activity? How will you identify your stakeholders? See, there

[1:57:53] cannot be one single answer to this, right? There can 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 that there can be

[1:58:06] few things which I can try, I believe it should be responsibility of PM to provide the list of stakeholders through organizational modeling. uh stakeholder accurate requirements. It should be responsibility of PM but it's not like

[1:58:21] he is the only person responsible for stakeholder 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 know because he needs to engage only for

[1:58:38] 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

[1:58:50] engage with more stakeholders right who are actual users of the system so 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

[1:59:03] all these stakeholders that is that is not the right thing so what else you can do so that is fine that first PM called you so it's possible that PM would have

[1:59:15] 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 can present it to the sponsor and can get the funding approved right most of the

[1:59:31] developers testers and sometimes BAS they get onboarded when project is approved so project is approved that means there would be some documentation available there would be some discussion done by the PM or by the sponsor so

[1:59:46] first question is always to ask PM himself that okay you are assigning with this project who are the stakeholders that you are already aware of right so first thing is fine he may give you some names and then that can be a good start

[2:00:00] second as Dina said you can use organizational modeling now what what is organizational modeling where you have the hierarchy in most of the bigger companies will have organizational hierarchy and that can be looked at in

[2:00:16] 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

[2:00:28] management then junior management then 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

[2:00:41] project was related to HR so it can give 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

[2:00:57] 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 modeling what else we can do if there is any other existing

[2:01:12] document 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

[2:01:24] sets of people. There are two lists which are 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 get the idea who are

[2:01:38] 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 your

[2:01:52] 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 take help. Similarly, if there are multiple vendors, uh, multiple different

[2:02:09] 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 vendor. So there also you can get some idea of the stakeholders. What else? I

[2:02:24] said existing documentation. If the sometimes it's like project similar project was done or this is the phase two of the project phase one was already done in that case you will get a list you might get a list from uh from

[2:02:38] list 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 process work uh pro process documentation like workflows or any

[2:02:51] 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 people who are right these are the people who are involved in this process these are the

[2:03:05] departments which are involved in this process so that can also give you a good idea all of these things can be used when they are available right and that's why I said there is no hard and fast fixed list of you know items step by

[2:03:19] 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? Now let's say I have only two stakeholders identify like in my current project that is what is going on. I'm in

[2:03:33] 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 that please feel free to forward this invite to anyone who can be helpful in this discussion. Right? So I provide the

[2:03:48] introduction of the project. This is what the purpose of this particular meeting. And if you think that somebody else can be useful then please forward them after the meeting within the within that meeting also you keep asking this

[2:04:03] thing right who else can help who else can help who else should I reach out to can help who else should I reach out to so that is also uh important right and that will help you keep identifying you will keep identifying more and more

[2:04:16] stakeholders when you keep asking people so that is also important what else can you think of anything which can help you with stakeholder identification. If you miss these stakeholder, what is the problem? We generally say unidentified

[2:04:30] stakeholders means unidentified requirements. Later on, there can be requirements which are which you are able to identify late in the project because those stakeholders were not identified. So, it's very very possible

[2:04:43] requirements because you couldn't identify all the stakeholders. And why it is important? We already know that. See first of all when when when I say a See first of all when when when I say a project a project is not just building

[2:04:57] application right project there is a term called system thinking like think about a system consists of people processes applications everything so if

[2:05:09] you are creating a new application it doesn't mean it will have only software related impact because that application is going to be used by stakeholders so people are get people are also impacted Sometimes you automate existing manual

[2:05:23] task people get impacted right so it's always not just systems but people processes everything so it's that is why it's important to identify that all

[2:05:35] 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 how should we interact with them to ensure success Right. So first part of

[2:05:51] this is there are two inputs needs where exactly needs are coming from the same needs which we identified and used in the first task. And now you see the additional input is

[2:06:06] business analysis approach. Where exactly you are getting this input from? Business analysis approach. This input [clears throat] where exactly we are getting from the first task. Now you tell me why this is important. Why the

[2:06:21] tell me why this is important. Why the approach is important as an input because what exactly we're talking about we are planning our stakeholder engagement how you will engage with the stakeholders how you will communicate

[2:06:33] 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 it's a very important input why business analysis approach is

[2:06:45] the input to plan stakeholder engagement uh when you You're a kid, you must be listening to bedtime stories from your mom, from your grandmom, maybe your father, grandfather. All of us, most of us would have listened to bedtime

[2:06:59] 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 keep saying h one thing that you know keep saying h yes something no so that I know that you

[2:07:14] are still awake and listening to this story. Otherwise I would never know you know I'm whether you you you are already sleeping and I'm talking to a wall. So that is the case here as well right that is uh the input. Now again similar to

[2:07:30] the first output of the first task this output will also be used in multiple different tasks. Let's see few of them. Uh for example prepare for illustration task number four. Do you think a stakeholder engagement approach is

[2:07:46] elicitation? Yes, because when you prepare for elicitation, you will set up send out meetings sorry uh meeting invites you, you will prepare for workshops, for brainstorming sessions. So whenever you

[2:08:01] do that, you would need your stakeholders and when you are planning what is the stakeholder engagement approach. Right? Similarly, if you see communicate 4.4, communicate business analysis information, who exactly you

[2:08:16] will communicate this information to to 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 realize why this input makes sense.

[2:08:31] realize why this input makes sense. Right? So these are the two input and output. Now there are three guidelines and tools. Business analysis performance assessment, change strategy and current state description. Why do you think

[2:08:46] is important? Because this is the lesson learned. So from your previous whatever you learned can give you the inputs here. Right? It's very simple.

[2:08:58] But what is change strategy? Change strategy tells you what is your in order to move from your current state to future state. You are going through a to future state. You are going through a change. This is called change.

[2:09:12] Now depending on this change, depending on the strategy of this change, you can on the strategy of this change, you can identify stakeholders, right? different house and you need packers and movers. So you know these they become

[2:09:28] your stakeholder. If you're moving within the same building they are not your stakeholder. So change strategy will also tell like if I'm migrating one application to a new application

[2:09:40] 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 you know that people who are or the team

[2:09:54] 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 beginning of the project and you don't have idea of the change strategy so that

[2:10:10] 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 diagrams what what do they tell you how as of now

[2:10:26] 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 UI is communicating to the back end as of now so if you have documentation

[2:10:43] available on current state it will tell you who are the teams or people involved in these processes like when I create flow diagram let's say this is the start it is moving to this then here you are

[2:10:59] performing a task and generally sometimes in your process flow diagrams 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

[2:11:14] this particular step is performed performed by the HR. This is performed the HR and then it goes back to let's say this uh let's say this is finance. Okay. So when you look at the current

[2:11:28] state description that can also give you a good idea who are your stakeholders. a good idea who are your stakeholders. So that is why that is also given as additional input. Right? So make sense all these three guidelines and tools as

[2:11:43] additional inputs. They are making sense if available they can help you in your stakeholder engagement state stakeholder identification right now why it is required obviously foster collaboration reduce resistance

[2:11:55] align stakeholder goals with initiative outcomes and ensure timely and accurate communication. So if you we know that project cannot be delivered in isolation right you have so many people who are impacted you have so many people who can

[2:12:09] impact your project you need developers you need testers you need u uh operations team and you need ultimate your end clients right otherwise how how can you deliver the project so stakeholder engagement is important

[2:12:25] right now if you don't talk to them it may become difficult First difficulty is unidentified requirements. Second, if you do not communicate to them, they you do not communicate to them, they will never know um what is the impact on

[2:12:40] them. What is the meaning 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

[2:12:53] something whether creating a case raising a ticket whatever some task that one person will do second person will check it. So it's not like the same

[2:13:05] 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 regulatory point of view from the legal point of view in many of the cases it's

[2:13:19] mandatorily required that maker and checker are two different person sometimes in my projects I have seen six I's six where somebody was the maker this person was just validating or checking

[2:13:33] and then approver was a different person so we had three different people working so we had three different people working on one thing. Now what happened when I

[2:13:45] we wanted to make some change in the process, right? So let's say there was uh onboarding team. So what is the what does that mean? that if you want to open a new account in any

[2:14:01] 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 earlier if this is the person who will collect my document he was able to

[2:14:16] perform everything I'm talking about 2012 13th but then there was one heard all of you might have heard of fatka these days it's mandatory Even all

[2:14:28] 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:41] 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

[2:14:56] discussing uh after this uh when we went ahead and discussed with operations that uh they started showing a lot of resistance because initially they were resistance because initially they were not very much engaged what they thought

[2:15:10] 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

[2:15:22] also approving the case right how you became my boss. Now what you 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

[2:15:36] another person who will approve the case. So people started resisting because they didn't have the full background and full understanding. So initially they misunderstood it and they started some resistance.

[2:15:50] Then we had to conduct couple of users 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

[2:16:06] case will be approved by you right only your manager the entire 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

[2:16:20] the purpose of this overall 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

[2:16:34] of the change. What are the benefits? 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

[2:16:48] the one who will talk a lot to those 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

[2:17:02] these stakeholders along sometimes your project manager right so that's why it's 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

[2:17:15] discuss with stakeholders that you know we are following waterfall or agile and what kind of engagement is required from your side okay so that they are also your side okay so that they are also align with with you as with your project

[2:17:29] approach and the overall purpose of the project. Okay. Um what else you need from stakeholders? You need there time commitment and

[2:17:43] resource commitment. Uh key elements perform stakeholder analysis, define a stakeholder collaboration. I'll just explain this and stakeholder communication needs. So first is perform

[2:17:56] a stakeholder analysis. The first step uh in this is identify right. First you need to identify the stakeholder who will be directly or indirectly impacted and their characteristics as well as

[2:18:11] analyzing the information once collected performed repeatedly as business analysis activities continue. Right? As I said, you will continue to ask who I said, you will continue to ask who else can be impacted, who else uh can

[2:18:23] you know give you more information. So that it has to be performed periodically or repeatedly. Also, it's possible that the person who you have been interacting with that person left the organization somebody else has joined right. So that

[2:18:36] is also you need to be careful that you know you're checking your stakeholder. If you created a register or list, you are keeping it updated all the time. So how do you identify? We discussed there are different ways which you have to try

[2:18:50] 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 and analyze your stakeholder. No. So one more thing is you can

[2:19:06] document it in different ways. First is simply creating a stakeholder list right you call it a stakeholder list or stakeholder register. Second uh another way is to create let's say uh

[2:19:23] let's say uh a matrix let's say authority of the stakeholder and interest of the stakeholder.

[2:19:40] stakeholder in these four categories. A person who has very high interest in 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

[2:19:55] that these people you have to manage very very carefully. You will have to take care of their know communication needs. what kind of communication they expect from you all that you have to you know you have to be very careful these

[2:20:10] 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:23] 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:37] that you want to use authority and interest in the project. Uh engagement 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:52] need to be careful that you should not end up adding this particular you know matrix in your project document or on your shareepoint where everyone can see right because what will happen this is not like if a

[2:21:08] 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 matrix in my formal project documents.

[2:21:25] 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 document that you one more diagram that

[2:21:38] 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:52] 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:22:08] Impacted department. Then this is your organization and every Then this is your organization and every anything that is outside is external right. So this diagram can be created just to mainly to identify who are your

[2:22:25] 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 the first question that you should ask

[2:22:39] where exactly is the boundary right by internal if you mean people who are part of the project then my boundary is here right but if you mean by by that if you mean that people who are internal to the organization that the boundary is here

[2:22:54] 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 creating something for HR department. So who are my client? HR. So in that case

[2:23:08] if you say that people who are outside my organization are external. In this stakeholder right? HR is part of the same organization. So internal and boundary. But I hope you understood the purpose of onion diagram. You can have

[2:23:24] two layers, three layers or four layers depending on the need and you can create such a diagram. Okay. So this is for the stakeholder identification and documentation of those stakeholders as a list as a matrix

[2:23:38] those stakeholders as a list as a matrix as a diagram or sometimes we also create as a diagram or sometimes we also create one more thing that is called persona. What is a persona? So basically persona is a fictitious character

[2:23:52] right? uh just think of a project where uh like 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

[2:24:07] like for example you are building the software for for your HR team you can directly talk to the HR and get their requirements but think about any bigger systems like Facebook or any other such systems where there are so many millions

[2:24:20] of users etc and you cannot cannot possibly take the requirements right so how will you then create application where you cannot directly take the requirements in such cases persona can be very helpful so you in in if I

[2:24:37] simplify it it's like you try to put yourself in the shoe of your user and try to imagine try to find out what kind of requirements that user would have with your system right what kind of usage that person would have with the

[2:24:52] system so So it's imaginary imaginary or fictitious character. You will still assign assign him or her a name and you will try to understand um uh you will

[2:25:04] put the demographic data to that person. Let's say age, gender, uh education and non-working maybe the whether he's living in a city or in a town etc etc.

[2:25:18] And then you will try to understand what kind of use case that person would have kind of use case that person would have with the system. Right? So in such cases because you cannot take directly requirement from the user, you can still

[2:25:31] 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 management platform. Okay. In this learning management uh uh platform who

[2:25:49] are the stakeholders? Who are basically who are these stakeholder? If simply learn is planning to build a new learning management system. Who all can learning management system. Who all can be the stakeholders? Students, trainers,

[2:26:01] train technical team, trainers, learners. Yes. Simple learn management, 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

[2:26:17] possible that I can have uh uh some requirements uh just for uh just uh as a trainer right and you can also have as learners right and you can also have as learners you can have your own requirements and

[2:26:31] uh for example I I can have a requirement that says I want a feature on LMS so that I can share them with the learners right very simple instead of you know sharing the Google drive etc if

[2:26:46] I could possibly upload all the additional documentation on the LMS so it's a valid requirement for for a trainer yes it is similarly uh as a

[2:27:01] requirements that I should be able to see my attendance on the platform I should be able to download the recorded sessions from the platform I should be able to download the additional material that trainer has shared from the

[2:27:13] platform. Right? All those requirements you can have. Now imagine that there is you can have. Now imagine that there is a uh there is a girl uh she also wants to attend some classes from simply learn but she knows that the network in her

[2:27:31] she's from a small town maybe a village and the network is always patchy in that and the network is always patchy in that village. So attending live classes may be very I mean there might be a lot of interruptions when she's attending live

[2:27:44] interruptions when she's attending live classes. Now if you think about her as a persona what kind of requirements you can think of that we would like to add in simply learns LMS as soon as you identified a persona of a person who is

[2:27:59] 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 the

[2:28:13] 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 requirement classification schema from the Babok point of view they

[2:28:28] schema from the Babok point of view they are divided as business requirements

[2:28:40] Okay. Then we have solution requirements which can be divided into functional and non-functional

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

[2:29:09] they can get the uh you know more revenue. That is the requirement where company wants to increase the revenue and in order to

[2:29:21] 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:36] 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:50] 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:30:07] 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 requirement should be aligned same as with the functional requirement

[2:30:22] nonfunctional requirement basically all your low-level requirement should be organizational requirements or highle business requirements so that is functional and non-functional requirements so uh like uh Allah

[2:30:39] 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 non-functional. So what is the difference between functional and

[2:30:51] non-functional functional requirements are the features functional requirements are the features functionalities of the system, right? And non-functional requirements are about performance, security,

[2:31:06] 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 particular website should I I should be able to open this

[2:31:22] should I I should be able to open this particular website in Chrome Mozilla Internet Explorer. Now in this requirement am I talking about what website would do what exactly is available on that website? Am I talking

[2:31:36] about any functionalities and features of of that website? No. Right? So then this is non-functional requirement because functionalities are not discussed in this requirement. Similarly, if I tell you that if I open

[2:31:50] your application, the application that you're building, if I open it in India, it should open by default it should open in Hindi. If I open it in the in the United States, it should translate to English. And if it is in let's say uh uh

[2:32:06] Italy it should be in Italian and things like that. Again I am I talking about what exactly is done on the website? How the user should login? What are the security? What are the uh you know what is required to login into the system?

[2:32:19] Nothing. I'm simply talking about the compatibility with different browsers. So that is a non-functional requirement. If I tell you that um concurrent users as he mentioned right uh right now let's say this zoom

[2:32:35] platform would allow 100 users but I want more revenue I want more people to join at a time again this is a non-functional requirement okay so I hope you're clear about the distinction between functional and non-functional

[2:32:51] requirements are more important than 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

[2:33:06] or more critical than other. For example, if you 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

[2:33:23] minute or 50 pages per minute. Now this is nonfunctional 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

[2:33:37] know functional are more 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

[2:33:50] requirement. So we always say that transition requirements are 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:34:06] 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

[2:34:18] packers and movers. Do you think packers 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

[2:34:32] one-time requirement. That requirement 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

[2:34:47] students that migration is required one time it's not you will 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:35:02] that is why training is also a transition requirement so Transition requirements one-time requirements required only for the transition period only for that change period not all the time functional

[2:35:16] 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:29] 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 your approach is important. What how

[2:35:43] much time you need stakeholders uh from stakeholders. In case of agile you need four to 6 hours every 2 weeks for a sprint uh for a sprint review maybe for

[2:35:55] requirement grooming uh sessions and uh 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 have that kind of time or not.

[2:36:11] Second is stakeholders communication needs. All stakeholders can have different type of communication needs. For example your project uh sponsor he

[2:36:23] or she cannot attend all these status meetings every week. So you 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 any

[2:36:36] progress and in case there are any problems right with tech teams 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

[2:36:50] whether written or verbal. So generally in [clears throat] all the projects I would create a 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

[2:37:03] stakeholders. On the other side I will have what kind of communication they want. So for example I'll send a weekly status email right I'll decide who all

[2:37:15] 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 technology teams, application teams to join this. There can be one weekly

[2:37:30] meeting with uh with with business stakeholders where we'll have just business, right? And maybe you can have one fortnightly meeting with everyone and things like that. So this is my communication plan. Who will tell me how

[2:37:45] need? I can obviously check with the stakeholders what kind of communication they are expecting from the project. In case of agile, some of these things are automatically decided if you're using a

[2:38:00] meetings which you need to run and stakeholders need to join those meetings. Clear? So, if I ask you to create a stakeholder communication plan, can you create it or do you think it's very difficult? It's very simple, right?

[2:38:15] List of a stakeholders, different ways of communication and the frequency. I say status email, a status email. All these stakeholders will receive frequencies month let's say weekly uh the full stakeholder connect let's

[2:38:29] uh the full stakeholder connect let's say frequencies uh fortnightly all these stakeholders uh you can have a steering steering committee steer co you can have right so all that is just two-dimensional

[2:38:43] data that we need to put on a spreadsheet and create plan right very simple and different stakeholders ers customers. We discussed yesterday who are your customers, who are your end users, who are the

[2:38:57] provide products or services that may influence or support the 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

[2:39:10] providing you human resources as well as well. Many time there are companies typical IT tech companies who are in body shopping also, right? So I need Java developers. I can re reach out to them and they can help me with 20

[2:39:25] developers. Right? So different kind of suppliers, vendors are there regulators. Who is the reging regulator in India? RBI, right? Who is the regulator for uh

[2:39:38] RBI, right? Who is the regulator for uh uh capital market in India? SB. M is for mutual funds. For insurance, it's IRDA. So these are the regulators, right? They will have a lot of requirements, lot of constraints on your requirements and

[2:39:51] that is why they become one of the key regulators especially on the on such projects where you have some regulatory uh requirements. A sponsor the person who is who has authority on the funding a person who is

[2:40:05] providing the funding to the project that is the sponsor. Project manager with no domain subject matter expert, technical subject matter expert, architects, they all are different technical people who and domain subject

[2:40:20] matter expert is a person who has that domain knowledge. Do you think uh BA needs to have domain expertise? Theoretically BA can be domain agnostic,

[2:40:33] right? Theoretically. Why? Because do you think BA is going to create requirements or BA is going to elicit requirements? BA is not going to create requirements himself. Right? So if BA is very good, he can ask right questions.

[2:40:49] He can use all the techniques. He can create 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

[2:41:05] So in a ideal world he he can do without having any domain expertise and that is having any 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

[2:41:17] expect that BA comes with some domain expertise so that you know there is no learning 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

[2:41:32] other uh job platforms they would expect a person 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

[2:41:49] business analysis governance. So when we say governance 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

[2:42:03] by that? Project project governance or overall business analysis uh governance what do you think is the meaning controls keeping track of all the activity monitoring and sharing the feedback. So

[2:42:18] the most important thing uh from the project point of view is how do we take 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

[2:42:34] need to be reached out to that is also part of governance. approval escalations uh uh the the distribution of the documents and uh authority from project

[2:42:48] decision-m point of view, design decision-m point of view as well as budget point of view. So and your escalation metrics of the project. So these are the things which are part of the business analysis governance. Now

[2:43:02] why do you need to identify this? Because in your project governance is required and every project governance is required. So again the same question it's it's uh your business analysis governance should be subset of project

[2:43:16] governance right. It cannot be like in project you have some some stakeholders project you have some some stakeholders which are identified and your in uh um in BA uh in business analysis governance you are asking for somebody else right

[2:43:31] that is that will not happen. So you whenever we talk about any plan any uh any governance approach or any other plan for example communication plan etc

[2:43:43] uh your business analysis plan will be subset of overall project plan in all subset of overall project plan in all the cases without any exception right so that is first thing that what all is considered under governance what all

[2:43:56] 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 many stages in the project where you

[2:44:09] 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:21] need to know who is that person and that is part of project governance. Uh who is going to provide the approvals? Let's on the design. In this case it may not be business stakeholder but at architect if in your organization there is a

[2:44:37] 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:52] 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 the project where you need different

[2:45:06] 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 right out of office message which tells

[2:45:20] you which tells everyone who is sending you 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 boss and you provide their email

[2:45:32] 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 the respective uh respective people who

[2:45:45] 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? Right? Most of the times escalations or

[2:46:00] 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 it depends on the project u uh approach

[2:46:14] it depends on the project u uh approach if it is let's say agile in that case the product backlog. So every requirement everything that is part of the backlog he will have final authority obviously obviously he will take inputs

[2:46:28] from different stakeholders but product owner owns the backlog. what goes into that backlog, what goes out of that backlog, the prioritization of the backlog, rep prioritization of the backlog, all of those things are the

[2:46:42] authority or the responsibility of the product owner. Right? So business analysts play a key role in establishing and maintaining a governance process ensuring uncertain uh ensuring that any uncertain

[2:46:58] uncertaintities within it are addressed. Now do you think we need to inform a stakeholder about the governance whatever approach that that you are taking whatever governance you are setting up do you think a stakeholder

[2:47:12] needs to be informed about it? Yes. Right. So that is why it is mentioned here you make the decisions you need to inform. There is one more important aspect of governance that is called change control. How the changes

[2:47:26] will be controlled in the project. how the changes change requests will be managed in the project. Earlier I think nowadays it's not that strict but earlier when I I was starting my career and until I think 10 years back

[2:47:40] especially in the in the traditional waterfall project there used to be this waterfall project there used to be this change control board CCB. Do you understand what is the meaning of baselining? Baselining

[2:47:55] is current status. So you can baseline your budget, your budget, you can baseline a scope and timelines also and requirements everything. So

[2:48:11] basically it is like something is going 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 let's say 1 million USD is the budget or

[2:48:28] 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 will

[2:48:41] 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:53] 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

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

[2:49:21] 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 to uh a particular email id, this will

[2:49:36] 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 or other stakeholders who are important. They'll be part of the CCB. Here they

[2:49:50] 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 this why their changes should be considered etc. etc. And depending on

[2:50:05] 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 considered and there could be three possible outcomes. What could be the

[2:50:19] possible outcomes out after discussion in CCB? either you accept the change request or you can reject the change request or you can just defer that okay

[2:50:32] 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:46] you are starting the project don't you think that this should be established how change requests will be entertained and how they will be analyzed, how the requests. Do you think this should be part of project governance? It is right.

[2:51:02] it should be informed to the stakeholders so that they are aware that I need to raise a change request. This is the process that I need to follow. Similarly u uh as I explained yesterday when whenever you create BRD or FRD or

[2:51:18] in fact Jiraas you need to create two tables mostly in the beginning of the documents. One is called list of approvers or approver called list of approvers or approver list.

[2:51:36] who are supposed to approve or sign off this document. Second list is called distribution list. Distribution it will have all the people who will receive a copy of this document. So even creating this is part

[2:51:51] of governance right who all should receive the copy even that is not that receive the copy even that is not that mandatory but this part approval part is very much part of the governance. So you see we do so many things practically

[2:52:03] which are part of overall project or business analysis governance. For business analysis governance. For example, this uh CCB setup, how the will provide the author, who will provide the approvers, approvals, that

[2:52:17] is on the requirement. Same thing will happen on 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

[2:52:31] in the input business analysis approach. Now I I am 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

[2:52:48] not applicable in agile. So if your project is agile that CCB approach is project is agile that CCB approach is completely different right the the uh take on BRD FRD that is completely different. So on the basis of business

[2:53:04] analysis approach your governance is 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

[2:53:18] previous two tasks. I'm sure you will be able to see that t 3.1 and 3.2. So previous two tasks produced these outputs and they are considered here because here we are talking about governance which has impact on the

[2:53:33] stakeholders as I told you who who you 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

[2:53:47] need to understand that when I say 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

[2:54:03] of the project or I am stakeholder 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

[2:54:17] agreed or maybe it's there in the emails or you you may create a proper document that's fine. proine 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

[2:54:31] it's agreed verbally sometimes it's over emails sometimes there may be a formal 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:47] 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 example up to 10,000

[2:55:04] team lead can approve but beyond 10,000 only manager can approve many such only manager can approve many such things right where you have uh approvals there can be some business policies that who can approve who can provide this so

[2:55:19] if there are any such policies we need to take care of current estate description Why? Because it will again it will explain you what is the who are it will explain you what is the who are the stakeholders uh and uh who all we

[2:55:31] about approvals etc. And same is for legal and regulatory if there are any legal requirements you can take care of them. So the purpose of this task is to identify how business analysis work will be approached and prioritized. Define

[2:55:45] the process for proposing changes. This change control board. This is the prioritization. As I explained you that in agile only PO is responsible otherwise you may have a prioritization board. Also clarify who has the

[2:55:59] authority and responsibility to propose changes. Determine who is responsible to analyze change requests. Establish who has the authority to approve changes. Specify how changes will be documented and communicated. Right. Implementation

[2:56:12] of an insurance claim processing system. Context. insurance company initiates a new claim processing system to improve efficiency, traceability and compliance.

[2:56:25] The project is spans spans several departments including legal claim processing and IT all of which have a stake in requirement approval and process compliance challenges. Multi-EP

[2:56:38] department approvals were necessary for all requirement documentation. Regulatory framework mandated strict audit trails and version control for all previous project led to delays,

[2:56:50] compliance issues and ambiguous approvals. If there is no governance 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 BD FRD

[2:57:05] 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 changes on that on that document what exactly do

[2:57:20] 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 thing right to maintain the different to maintain

[2:57:35] different versions of your document. If it is if you are um doing it on Jira automatically your changes will be captured or you are using let's say

[2:57:48] 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 as on Confluence. But in case you are

[2:58:03] you created a a word document or a spreadsheet or something, you can always 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:17] 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:31] then you have u some description about that change and also you will have version number version number it will be like for first version you can have one like for first version you can have one or then you can have 1.1 1.2 1.3 and

[2:58:45] or then you can have 1.1 1.2 1.3 and then you can have 2.1 2.2 two 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:58] means there is a bigger change right 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 changes you can move this and then this

[2:59:12] 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:25] 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:38] creating formal documents right and then as I explained in Jira in sh on shareepoint and of confluence change control is I mean Version control is maintained by the system itself. Obviously when you upload document on

[2:59:51] 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?

[3:00:06] Now you see the governance structure here for this scenario. A steering approve high level business requirements. A change control board was set up for evaluating and approving

[3:00:22] all change requests. All documents and requirements were maintained in SharePoint with versioning enabled and access control implemented. Stakeholder roles and escalation paths were clearly defined using racymetric.

[3:00:37] So asymmetric is also very important part of governance approval workflow. E- signature workflows ensure timely and traceable approvals and governance cadence. Weekly governance meeting were scheduled with representatives from each

[3:00:51] 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 part of governance. What does that mean?

[3:01:05] part of governance. What does that mean? who can access right so on sharepoint 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:18] 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:31] 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:44] 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 in

[3:02:00] 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:16] 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:28] approvals 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

[3:02:41] any nobody can say that no planning should be done right even it's agile rapid agile whatever no planning is is not the solution. You can simply not the solution. You can simply eliminate collab. Nobody in any of the

[3:02:54] collaboration whether it's waterfall agile rapid agile can lean nobody 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

[3:03:08] different features to be delivered different requirements to be delivered. So same documentation cannot work for every sprint. every sprint. So the correct answer is uh C combining

[3:03:20] formal approvals. Next, what technique works best to identify all stakeholders in a large identify all stakeholders in a large complex project?

[3:03:36] change fatigue. How should the BA respond? 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

[3:03:50] status report. In a typical agile project there is nothing like end of 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

[3:04:04] you don't even exist in typical agile setup right only sprint demo is the valid option next question when should the change control process be established at

[3:04:18] requirements are finalized only for low low priority task after the release correct answer is B see if I if I ask you let's play a game right and uh once

[3:04:30] 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 you I am the winner of that game would you I am the winner of that game would you like it so generally it's always

[3:04:44] 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 everyone is aware so that nobody can complain you know uh uh I if I had I

[3:04:59] known this then I would have done that differently right so to avoid such differently right so to avoid such conflicts it's better to set up your rules governance etc etc in the beginning towards the first phase of the

[3:05:12] of the project in a productive approach what ensures traceability of requirements because approach is productive so anyway burndown charts daily standups they don't they are not valid options

[3:05:25] correct What does stakeholder analysis helps the What does stakeholder analysis helps the BA determine? Stakeholder analysis. BA determine? Stakeholder analysis. What does it help us with?

[3:05:39] Yes. Communication preferences, influences and engagement risk. So the fourth task is plan, business analysis, information management. Now what do you what do you understand reading the name on the basis of this

[3:05:55] 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 this particular task just to reiterate for example in the previous task we

[3:06:09] 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 anything out for approval Right? It was just the the understanding and and

[3:06:24] 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 information during the project that is what is decided here. So, how the

[3:06:37] information is stored and managed, management of information, who will manage, how it will be managed, getting information, how to handle collection, right? All that all of that. Right? First of all, tell me what all

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

[3:07:04] any diagrams, wireframes. So any traceability metrics, racy metrics, sort analysis, so whatever you perform, right? All of those things are information. What is the purpose of this information?

[3:07:20] 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 what do you think can be the input to this task.

[3:07:35] 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? Because I just explained

[3:07:47] 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:08:00] So that is the BA information. And what else will be the input? So this BA information and the stakeholder engagement approach. Why do you think a stakeholder engagement approach can be the input? Because all that we are doing

[3:08:14] 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:26] 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:40] 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 stakeholders. So that may be that is also the input

[3:08:56] right. This task is about defining how you will create organize store access and 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

[3:09:12] So access management access control of that information and sharing also like that 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:25] Now it's 50 MB and your organization does not allow 50 MB documents to be do? You want to take the approvals from the stakeholders on this BRD. How will you share the BD and take the approval

[3:09:38] approach sharepoint 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:50] 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:10:05] BA approach because in waterfall you will create different documents different information in agile you will create different information different documents because this information is supposed to be shared with the

[3:10:17] stakeholders to take their approvals to take their sign offs 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

[3:10:33] were not comfortable with 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

[3:10:49] management right again the same things if there is any policies information management tool right this is a new guideline which was not there

[3:11:02] with previous task but it is making perfect sense because if there is 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:19] 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:32] 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 sharepoint confluence whatever and if there is any

[3:11:45] 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:59] dedicated document that this is the information management approach right it's just discussed agreed verbally maybe over email sometimes if it it is really formal your project environment is really formal you can create a

[3:12:12] document with just one table that these 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 Organization of business analysis

[3:12:27] information. Business analyst is structure 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

[3:12:41] folder structure? So for example, I created a project sharepoint. Let's say project one. So this is my shareepoint. Here I can create folder structure that

[3:12:53] this is for BRD. All different versions of the BRD will be here. Here I have let's say all the approvals which I need to store for the approvals which I need to store for audit purpose. I can have all the um

[3:13:07] whatever um if I have created any other documents I can create put it here let's say test signoffs. like even in our laptops we do that

[3:13:20] right you create a proper structure so that it's easy for you to fetch the information later refer to that information later um okay uh so that is the organization of information and then this is also

[3:13:34] important level of abstraction because not every stakeholder can consume the not every stakeholder can consume the information at same level your sponsor information at same level your sponsor might need just one slide, right? One

[3:13:48] slide to understand the status of the project. Your um uh your tech team might need a detailed BR, detailed FRD, maybe detailed design documents, right? So you

[3:14:01] cannot have same meeting or same document for all your stakeholders. So when you create document you may have to take care of the role of the stakeholder the complexity of the information and what kind of document they are they are

[3:14:15] they are you know they can consume and how do you know 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

[3:14:29] let's say sponsor for the first time I can request I can ask 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

[3:14:43] other projects, other stakeholders. So you create different 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

[3:14:57] two pager plan traceability. We discussed that requirements are captured at different levels, right? You have your business requirements which are high level business requirements or purpose the main objective of the

[3:15:11] project. Then you capture stakeholder requirements. Then you capture requirements. Then you capture functional non-functional requirements functional non-functional requirements right and then you create your tra test

[3:15:24] right and then you create your tra test cases to test the requirements. You have releases to release them in production things like that. So basically the work that we do in a project the stakeholder requirements that that we implement or

[3:15:39] functional nonfunctional requirements that we implement they all should support our business objective right why should I work on something that is not supporting the business objective of the project so basically that is the main

[3:15:52] purpose that all the work that we are doing here any stakeholder requirements non-functional requirements that are here they all are aligned to at least one or they they must be aligned to some business purpose some business

[3:16:08] So that is the main purpose of traceability matrix. You write business requirements to deliver this business requirement you you create functional non-functional requirement. So basically the alignment is required. Basically you

[3:16:23] should be able to trace trace uh in both the direction. So if you are tracing in this direction this is called forward traceability. in this direction, this is called backward traceability. So basically they

[3:16:38] answer two different questions. The uh the the business requirement or this is stakeholder requirement. Is it getting delivered? Is it getting coded? the requirements? It is is it getting tested properly? So that is how you look

[3:16:55] on on forward side right that okay yes this particular business requirement functional non-functional requirement these are the test cases which will test this requirement and this will be part of release one

[3:17:10] 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 this particular test case why I'm

[3:17:23] this functional or non-functional requirement exist. So if you want to understand the background and the purpose of the work that you're doing coding testing whatever so if you want to understand the purpose if you want to

[3:17:37] 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 traceability matrix is very very very

[3:17:51] useful. If you have this properly created, properly documented, it gives you information in both the directions. Okay. R stand for release.

[3:18:05] 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 against each and every requirement. So that will make sure your test coverage

[3:18:20] all the requirements are getting tested 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 inputs from testers from developers to

[3:18:33] 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 lot of insights right that is why I

[3:18:47] 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 trace decent matrix I there is this uh trace decent matrix I create I'll create it here.

[3:19:00] So there are business requirements let's say 1 2 and three I'll capture here just for the simplicity and there we have test cases

[3:19:14] and releases so against if if any if against any of these business requirement this column is blank what does that tell you don't nonfunctional requirement what does that tell you obviously your traceability

[3:19:29] 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 nothing is there in

[3:19:42] What does that tell you? This tells you that maybe this particular business requirement is not covered. This is not getting developed because this is not linked to any of the functional nonfunctional requirement. Right?

[3:19:56] Similarly, if this field is blank, it tells you that this functional requirement whatever is here or this business requirement, they are not getting tested. They are not part of test coverage. Right here, if you see

[3:20:09] everything is populated here properly, but this field is blank. You know that 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:24] 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

[3:20:38] cases. 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:53] 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:11] you see how many different 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 you think your developers and testers react?

[3:21:24] Whenever a business analyst reaches out 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:40] first of all, very rarely they are happy with a change request. Right? Whenever you go to your team with a change request, they just resist it that okay

[3:21:52] then what is the second point? So first point is the resistance, right? They'll 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

[3:22:07] do everything all over again. There is a huge impact. Now I'll have to rewrite the 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

[3:22:19] normal or not? Normal. That is the normal reaction that you get from them. 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

[3:22:33] negotiate where you can have a 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

[3:22:46] cases are impacted so basically it gives you some background some information which can put you in a situation where you can you know question cross question right again it's not to fight with them but to get some background right

[3:23:01] otherwise they think BA or PMS they don't have technical background so we can tell everything is impacted and they'll agree right do you agree or not proper trace matrix will give you so many different inputs which are required

[3:23:15] many different inputs which are required in the project okay now one more layer in the project okay now one more layer so in my in my recent projects development team. Okay. Uh let's say there is a big regulation coming up a

[3:23:30] big regulatory requirement or any big project where you have few very high project where you have few very high level big requirements. Okay. So first requirements and let's create let's say I create a BRD. Okay.

[3:23:46] Where I detail them down and I create some business requirements. Then I'll create this traceability matrix where in this column I'll list down the impact

[3:24:06] generally because this these projects are very big it's possible that they will have impact on multiple applications right this application has some impact because these projects are impacting front to back of complete

[3:24:18] 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 application two and application three

[3:24:33] for example okay this requirement which is here this will have impact on is here this will have impact on application four 3 and 1 and two now in the next column here I'll write down the exact impact

[3:24:49] So application one this is what you need to do. Application two this is what you need to do. Application three this is what you need to do and then the remaining thing will remain same that you know code or test cases and releases

[3:25:01] etc. So I've added one more layer of complexity where I'm tracking the changes or the impacts on multiple applications because of my requirements. And then the responsibility I can add

[3:25:15] 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 are multiple applications which are impacted. In those applications they

[3:25:28] 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 have to read uh go back and read all those regulatory documents etc. For them

[3:25:43] 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 out all the requirements on the basis of application one and they can see the

[3:25:59] application one and they can see the exact impact on their applications right then they create respective Jiraas they create test cases and assign them to [clears throat] releases so if I want to check all my BD requirements are

[3:26:12] getting uh getting developed I will simply say if see if all the requirements have Jiraas is assigned to them. So if requirement number four does not have any Jira here, I'll talk to

[3:26:25] that B 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 requirements are getting properly tested. So you see from simple metrics

[3:26:41] it becomes a very very useful tool not just for me but for the application BAS right so this is just one layer of added complexity where you have multiple different applications impacted. So I always create this document in all my

[3:26:57] projects. This template is like you can create if you it depends how complex you want to create this because in in this example in my example it can get very very complex because I'm talking about here if you have 50

[3:27:11] requirements right and you have like in my previous project 15 applications were impacted and uh you can imagine number of rows which I'll have in this

[3:27:23] 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:35] 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:49] 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:28:03] 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:15] requirement? You as a learner, you want to see your attendance in the LMS. How how will you implement it? There has to be some functional requirement. functional requirement will will be uh the navigation on LMS on this page there

[3:28:30] 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 this is how it will be implemented

[3:28:44] 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 that you want like only 10 MB document

[3:28:59] can be uploaded not not bigger than that all those things now they are captured 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:11] 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:27] 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:40] through some functional nonfunctional requirements and they are getting 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:53] 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

[3:30:05] 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

[3:30:17] everyone 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

[3:30:32] your family they can easily find it out right because that is the purpose here right 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:45] structured accessible requirement 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:59] 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:11] 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:24] 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:38] 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:53] 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:10] 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:26] 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:42] 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:55] 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:10] 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 uh admin I will go in in set settings and I'll change that only I'll select

[3:33:26] only 20 fields. So when the user will click on create they will see only 20 click on create they will see only 20 fields in that in that. So basically it is up to the up to us and up to the project what all requirement attributes

[3:33:38] you want to capture for each and every requirement. Right? So requirement linking key information to individuals or group grouped requirements. They help team assess trade-offs, identify

[3:33:50] 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, downstream systems. So a lot of fields

[3:34:03] 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:16] capture for those requirements, where we will store those requirements, how we'll have the access control for those requirement documents, right? And output requirement documents, right? And output is the document strategy. How, where and

[3:34:32] 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:48] archival retirement timelines methods. 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 process. The business analyst is working

[3:35:03] with the admin staff, teachers and IT providers to gather and manage all registration requirements and design ideas. What is your information management plan? All information requirements notes in saved in Google

[3:35:15] Drive folders with clear labels like student requirements, teacher suggestions, system design ideas. The school principal and admin have full access. Teachers can view only the requirements. The IT provider can

[3:35:28] comment but not change the requirements. Right? So this is what we try to achieve. The BA decides to reuse parts of the older registration form like parent contact information fields. Right? The BA dates each document

[3:35:41] version and saves them as requirement version one, version two and so on. Old versions are moved to archive folder. Then retention and archival also

[3:35:53] clear the outcome. Time is saved by reusing past documents. The IT provider 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

[3:36:07] analysis information saves time. Fifth and last one is identify business analysis performance improvement. So what is the what is the meaning of business analysis performance? In order

[3:36:22] 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 meaning of what exactly is the meaning of business analysis performance? Build

[3:36:39] 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 framework as per our understanding of

[3:36:55] 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 near to your house. How will you say

[3:37:09] 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 that shop is always crowded so you can say that you know whenever I pass that

[3:37:25] 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 similarly for business analyst what kind similarly for business analyst what kind of parameters you can use so first thing

[3:37:39] let's say you created a BRD and it took five cycles to get it approved. Do you think it's good or bad? How will you judge the skills and the basis of few things that we need to identify, right? Like number of review

[3:37:56] identify, right? Like number of review cycles required in order to get the 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

[3:38:10] judge a judge a business analyst performance on the basis of you know how 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

[3:38:23] performance. Right? What are the relevant metrics? What are the relevant indicators? Number of cycles required

[3:38:35] to get the sign off on the document. Number of requirement related number of requirement related defect identified right generally whenever we talk about

[3:38:47] KPIs or performance indicators we try to quantify them so that it becomes easier right but sometimes you can also have some qualitative indicators like the feedback from the reviewers of the document if they are happy with the

[3:39:01] document if they are happy with the document or not right so all these three four five indicators are good indicators to to uh see the performance of business analyst. Also please note that we are not talking about the annual performance

[3:39:17] of as an you know the annual performance of the person. We are talking about the performance as a business analyst. How the business analysis work went into this project. Right? How many how how

[3:39:32] was the document? How was the uh how many review cycles required? How many defects identified? We are not talking about individual here. We are talking about the business analysis as a deliverable as a the documents that we

[3:39:45] need to produce the process that we had to follow. Right? Obviously these things can be tied back to the individual's annual performance. That is a different thing. But here we are not talking about did you complete all your trainings? Did

[3:39:58] you did you fill your time sheets on time? Did you you know behave properly? That is not individual's performance. Here we are talking about business analysis performance not business analysts performance. Okay. It focuses

[3:40:11] on assessing the effectiveness of business anes work and identifying opportunities for improvement to enhance future performance and outcomes. Right? So examine the performance of past and ongoing business analysis

[3:40:26] tasks. Highlight inefficiencies, misalignments or recurring issues that hinder analysis outcomes. Suggest adjustments to methods, tools and communication. Ensures B effort align with business goals and performance data

[3:40:40] to lesson learned. So let's see. So the first part is inputs. First input is business analysis approach and second is performance objectives. What kind of objectives we can set for a business analyst for business analysis work? Why

[3:40:56] it is mentioned external? Some of the inputs coming from the output of other tasks. Right? So for example, it is mentioned clearly here 3.1. That means this particular input is the output of task

[3:41:10] number 3.1 which was the identify the project business analysis approach for project business analysis approach for your project. This input not coming from the reason there is no number mentioned 3.1 or 3.2. into

[3:41:25] instead of that in the bracket it's mentioned external. So this input is coming from outside. Okay. And also you see additional guidelines organizational performance standards. So if there are any standards already specified by your

[3:41:40] organization for all the business analysis work then that can be utilized. Okay. Output is obviously performance 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

[3:41:57] that this input is the output of one of the task from the same knowledge area. Right? So here you can see that the lesson learned that you are learning lesson learned that you are learning here is used by other tasks. Now you can

[3:42:12] question that those tasks were performed earlier than this task. How can they use earlier than this task. How can they use the per output of this task? Right? Does that question come to your mind or you know the answer already? So the see

[3:42:25] first of all these things are not 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

[3:42:40] tasks are performed iteratively, 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

[3:42:55] initially the input uh which was available was partial. So initially you had partial input and you started working as per that partial you started working as per that partial input and later you more and more data

[3:43:10] or more input became available more data right so you then again you perform the task. So that is why it every task may be done iteratively multiple times

[3:43:22] initially with the partial data. So in for example we discussed about stakeholder identification right identify your stakeholders can you perform a stakeholder identification confidently in one go can

[3:43:36] you confirm after whatever efforts you put in early that I have identified 100% stakeholder even if you feel don't you think it's fairly possible that you will identify two more stakeholders after one month

[3:43:52] because somebody else might come to and tell you that you know there 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

[3:44:07] stakeholder right? So initially you you identified 10 stakeholders. So you went ahead and started interviewing them. So you started the elicitation right in the first go. Then you identified two more

[3:44:24] stakeholders. So you performed elicitation for them as well. So you see what happened stakeholder identification was done in iterations requirement elicitation was also done multiple times. It could not be

[3:44:38] completed in one go. So that is the reason if you think about any of these reason if you think about any of these tasks like uh a stakeholder engagement we just discussed you you will identify more stakeholders. So this particular

[3:44:51] task will be performed again and again iteratively right. It's also possible that some new issues identified and you have to add something to your existing have to add something to your existing business analysis governance right uh so

[3:45:06] this document or whatever the approach is also going to be a live approach. It's 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

[3:45:20] additional attributes for the requirements. So here also it it can change right. So that is the point that initially let's say when you started initially let's say when you started performing uh these tasks maybe this

[3:45:34] past assessment was not fully available but you still went ahead and perform but you still went ahead and perform these tasks. Later on when this was available you can go back and perform these tasks again. Also it's possible

[3:45:49] that this performance assessment is coming from the previous project right so the performance assessment from previous project was already available when you started with 3.1 3.2 into 3.3 right so that can be one more reason how

[3:46:04] this output was already available when you were performing these tasks either because it came from the previous project or the input was partially available or you started the tasks without that approach assessment and you

[3:46:17] 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 tasks or any knowledge areas They are performed in the exact sequence in which

[3:46:32] they are mentioned in Webok. That is not true. You will perform them in different orders depending on the project. In fact, the order of knowledge area itself can change. Order of task within each and every knowledge area will definitely

[3:46:46] change. Okay. And most of those things will be performed iteratively multiple times. Now the key elements. So it's like very similar to uh you know our performance appraisal. Initially what you will have

[3:47:01] 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 some of the measures right number of review cycles required number of defects

[3:47:16] requirement related defects identified. The qualitative feedback from your The qualitative feedback from your customers. the quality of of of your requirement uh document, right? There can be many such things that can be

[3:47:29] 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. What is the process? In the beginning of

[3:47:44] the year, we all create self objectives. You set up your self goals, self-objectives. You get them reviewed with your boss. You both agree. You say my goal is to let's say complete these two projects. And your boss may

[3:47:59] negotiate with you. No, you have to complete three 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 sheet filing. There

[3:48:13] should be zero escalation against any training uh you know completion. So both of you would agree that these are the objectives. Now throughout the year you your performance against those same goals. Right? Then end of the year you

[3:48:32] 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 one to five. I deserve one being one being the best. And boss would say you

[3:48:46] discussion happens and all and you finally get one rating and salary hike process that we follow. Right? You even for our individual uh performance appraisal same thing is here you identify the assessment measures first

[3:49:02] then you uh check your the performance against those measures and analyze the results and you will collect data to find trends, patterns and root causes find trends, patterns and root causes for poor performance. any issues which

[3:49:16] are identified you will propose practical improvements that can enhance practical improvements that can enhance performance moving forward right so it's very very I mean it's exactly the lesson learned you had objectives you compared

[3:49:30] 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 work practically in project it looks simple that you had some objectives. You

[3:49:46] the year on these those objectives and finally you will see whether you are able to meet those objectives or there's a gap. If there is a gap, what is the reason for the gap, right? How we will fix it? For example,

[3:50:01] fix it? For example, you identified in the uh the project was you identified in the uh the project was slightly delayed and when you uh sit as slightly delayed and when you uh sit as a uh as a team, you identified that the

[3:50:13] 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 sign off on your requirements, let's say on 15th of May, but it was completed on

[3:50:25] 30th of May. Now, what could be the reason? Can you think of any reasons reason? Can you think of any reasons that can that can be there? If you talk about the proper cycle that we generally we should follow. What is that cycle?

[3:50:37] we should follow. What is that cycle? You create the document, right? You you document, what what is next that you do? Do you send it to your stakeholder for for the signup or is there anything that you do once

[3:50:52] elicitation, you got a lot of information from stakeholders. You properly organize that information into properly written requirements. You created a very nice requirement document. Now what exactly you do as a

[3:51:06] requirements, what do you do? Elicitation is done. That's why you are Final requirement document. Right? So when I send the requirement document with the stakeholders, maybe I uploaded the document on a shareepoint and share

[3:51:21] the link because that's how we discussed about information management or maybe I uploaded the document over the email itself and shared with the stakeholder. So we followed whatever was agreed for information management and accordingly

[3:51:33] be shared. Now stakeholder had so many questions and they came back to me. I came up came up with more follow-up questions. I again answered them. So they had more questions and that is the

[3:51:46] 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 trying to do the lesson learn session and we identified requirement sign off took two weeks

[3:51:59] extra. What is the issue that you see here? Once you are ready with ready with your requirement document 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

[3:52:15] a workshop where you will walk them through the requirements one by one. You'll make sure that they all of their questions are answered. They all have the same understanding common understanding of the requirements

[3:52:29] or you basically all of you are on the same page in terms of requirements. Right now after that you send out that email that as per our walkthrough session I have answered you all your questions in case you have any more

[3:52:43] questions please feel free to ask otherwise please see the attached document for your sign off right please kindly provide your sign off now do you think it will have a very big difference as compared to the first scenario where

[3:52:56] you simply send the requirement document for the approval without the walkthrough walkthrough session do you think you will expect you know difference different different outcomes. So that is how you need to

[3:53:10] 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 talking about individual we are talking about the process that we followed the

[3:53:24] process which was followed there one step was completely missing we identified that yes there was this gap in the process and this time we'll fulfill we'll fill that gap and we'll make sure first walkthrough sessions are

[3:53:36] 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 learn that you know walk through should always be done before you send anything

[3:53:50] 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 next time. Similarly, you can identify

[3:54:03] 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:16] test uh test cases and all. For example, uh uh let's say you uh you initially when you were capturing the requirements instead of in this time you discuss walk

[3:54:29] 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:43] 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:56] 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 developers would testers would say there

[3:55:10] is a defect as per their understanding of the requirements. Okay. So what happens when when a tester goes to a developer and says there is a goes to a developer and says there is a defect what do you think how a developer

[3:55:23] responds generally what is the first response from develop developer this is my code right it can't have any it can't have any defect maybe you are mistaken

[3:55:35] go back and test it again my code cannot have a defect right that is the first uh have a defect right that is the first uh and then the the second is my as per my understanding this is working fine. Tester will say as per my understanding

[3:55:49] the reason? They have different understanding of the requirements. Now can you say that no it's not my role. It is definitely your role to make sure understanding of the requirements so that during testing there are no such

[3:56:05] conflicts. Right? So what will you do again the same thing as as you start 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

[3:56:21] available testers available already in your team in your project you should 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

[3:56:33] right so that there are there there will be less lesser conflicts during test execution. Second, from the feasibility point of view, you are a business analyst. You may not know all tech technical knowhow of your project. It's

[3:56:48] getting you 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

[3:57:03] of view whether 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

[3:57:16] that you will learn. Now if you read webok you will not web will not talk about all these instances that we are just talking about. uh Beok will simply say that identify the measures, measure your performance against those

[3:57:29] measures and document the lesson learned and move on. Right? That is all you will and move on. Right? That is all you will see in Babok. So you understood how on what basis business analysis performance can be measured. I give you two three

[3:57:43] examples where there can be gaps and how you will fill 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

[3:57:58] performance. Identify the root cause of variance and proposed approaches to address issues. Metrics for monitoring the effectiveness of implemented improvements. And whatever is these metrics, whatever is the outcome, you

[3:58:11] will document it as a lesson learned so that you can refer it 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

[3:58:27] similar that we do in agile retrospective. Right? A sprint retrospective. So what is the purpose of retrospective? The last meeting that we last day last meeting of the sprint that is called retrospective. And that is the

[3:58:42] purpose of retrospective. What went 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

[3:58:56] project would be agile this discussion the entire discussion on performance improvement would be done in that retrospective itself not separately retrospective itself not separately right so this is the last task okay

[3:59:09] let's see one scenario context a BA team is a large in a large organization observed recurring delays in getting requirements approved which frequently led to missed project timelines and stakeholder frustration.

[3:59:22] Issues identified stakeholders were not clear on who should approve, when to approve and how to communicate their feedback. Requirements documents varied from project to project lacking consistent structure and details. See

[3:59:37] how many things can go wrong. You are using different template, different requirement document structure in every time and they are getting confused. Right? Your project communication plan itself is not very clear. How they are

[3:59:52] supposed to communicate the feedback, how they're supposed to approve and you how they're supposed to approve and you so you see many very simple problem. so you see many very simple problem. If you send out an email and it happens

[4:00:04] all the time. If you send out emails and you simply write hi all 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

[4:00:18] happen? Do you think everyone will approve or do you think nobody will approve? What is more common? What is more common scenario? Generally when you send email like this nobody will respond nobody

[4:00:31] will approve because your email itself is so poorly written you have so many people in two list and then you are saying hi all nobody will have any idea who exactly you are requesting be it sign off be it anything. So it's very

[4:00:48] important that you clearly mention the uh the names of the people who you are asking or you are keeping only one or two people in your tool list so they them. It's still it's better to just clearly name the people and if you send

[4:01:04] out email how soon you can chase you cannot chase same day right maybe you will send a chaser next day or maybe what 2 days after that because if you senior stakeholders you cannot chase on daily basis so let's say you chased

[4:01:20] 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:35] can get delayed and you see this this is also a very good example that the way 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

[4:01:47] and approves which sections timeline expectation for each each stakeholder. 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:02:02] 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 protocol for rejection or feedback.

[4:02:18] How it helped? Made everyone involved aware of their role, deadline and responsibilities, reduced confusion, created transparency and build stakeholder trust. The team introduced a structured

[4:02:30] requirement templates, clear sections for functional and non-functional requirements, define fields for priority, dependencies and traceability, visual elements like user story maps, etc. Now this is what I told you when we

[4:02:42] 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 right and I told you that you will create one table and you will repeat

[4:02:56] 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 this table again and again in your document to capture all the

[4:03:11] requirements. I also told you like in Jira you have multiple fields but you will generally you will standardize that template consistently for all your JAS right so that is the point mentioned here exactly the same thing how it will

[4:03:26] help made documents easy 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

[4:03:40] template consistently across all the projects and that is where you uh you might see PMOs are playing important role. PMOs play different roles in different organization. Sometimes they have the responsibility of standard

[4:03:55] documentation. So if you need any templates for BRD, FRD or any other document they you can reach out to them and they'll give you the exact template that should be used across all the projects to maintain that you know

[4:04:07] 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 approval time by 40%. Very good improved stakeholder satisfaction a qualitative

[4:04:21] documentation in the process that you are following for business analysis timeline. Right? All that what we wanted to achieve. Clear? So we have just

[4:04:33] 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, Jiraa and

[4:04:45] 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. Your

[4:04:59] 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 this? Storage

[4:05:14] 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 are you dealing with? discontinued

[4:05:28] 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 archive that document. Right? So the correct answer is right D. Two analysts

[4:05:43] 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? Correct answer is C.

[4:05:57] 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. Your manager asks for a quarterly report

[4:06:12] on the number of requirements defects that occurred due to incomplete analysis. Which aspect of this task you are addressing? Yes. B. Multiple testing. You review how requirements were elicited and documented to find the

[4:06:28] issue. What technique are you applying here? What we are saying saying that problems are identified and you you're trying to find out the and document to issue? So that is why root cause analysis which help us to identify the

[4:06:43] 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 documentation standards. Which performance improvement element

[4:06:57] does this represent? Mentoring will fall under which which of these uh options? development. All right. So the next knowledge area,

[4:07:11] the second knowledge area is elicitation and collaboration. Elicitation means gathering information from stakeholders to understand what they need and expect. with them to reach a shared goal. So that is the uh name of this knowledge

[4:07:28] area. Elicitation and collaboration as I have been telling you elicitation as I have been telling you elicitation and collaboration or any other knowledge area or other task for that matter. They are not one time, right? they are they

[4:07:42] they continue throughout the business analysis process. So some elicitation you will do now maybe you will have to do some elicitation more later when you identify a new stakeholder. So never assume that you will continue any of

[4:07:55] 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 conduct elicitation.

[4:08:10] confirm elicitation results, communicate business analysis information and manage stakeholder collaboration. Now this uh the tasks of this knowledge area are previous knowledge area, they are very straightforward.

[4:08:25] And when I say none none of them are performed in sequence, there is just one performed in sequence, there is just one exception which is these three tasks. So whenever you perform elicitation these three tasks are the

[4:08:39] only tasks in knowledge area in in Babok which are performed in sequence. You which are performed in sequence. You will always prepare you will always just after that you will conduct and then you will confirm elicitation results. So

[4:08:53] these tasks are performed in sequence. This is the only exception. Right This is the only exception. Right now let's quickly learn let's quickly try to understand what exactly we are discussing here in this knowledge area.

[4:09:06] So you understand what is elicitation right you meet stakeholders in different right you meet stakeholders in different ways you maybe online or in person maybe onetoone maybe in a group setting. So you do that meeting part and you ask

[4:09:23] questions you uh you probe your stakeholders you try to understand what 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

[4:09:37] we'll prepare before conducting the elicitation so in conduct you will actually perform that task right but before that you are saying there is a different task which Just prepare for elicitation. What kind of preparation do

[4:09:51] you need? So let's say you want to 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

[4:10:04] questions whom to reach prepare the questionnaire. Yes. And whenever we think think from very very basic the most basic normal thing that you will

[4:10:16] most basic normal thing that you will have to do right there is no there 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

[4:10:30] that you need to do what 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?

[4:10:44] project? What exactly I'm going to ask? Who are the stakeholders? Uh then you 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

[4:10:57] need to run a workshop or interview, you will prepare other training material. If documents, you will collect those documents. Right? So, uh if there is any

[4:11:09] to run a workshop or brainstorming session, there might be a requirement 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

[4:11:23] want to do a bigger workshop over lunch, then you may have to arrange for those things. There are many other things that we need to take care of. Like if there is a senior stakeholder sitting on a different floor and you sit on a

[4:11:35] 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 they don't have to walk to your floor. So there are many basic things that you

[4:11:49] 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's um there there are problems related to language communication then you will

[4:12:04] also have to take care of that. So basically consider your stakeholders their preferences in terms of timings, time zones, the location and then you prepare the other things like we discussed all the uh all the additional

[4:12:20] documentation with respect to meeting rooms and then one more important part. So we discussed what you need to prepare I'm sure you would agree that you need to prepare your stakeholder also right

[4:12:38] to get to the maximum benefit to achieve the maximum benefit out of this meeting. 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

[4:12:53] agenda with them. agenda of the meeting and what will happen so that they know what exactly are you going to ask otherwise what will happen if you go and ask questions and he says or she says I don't know you will not say you know I

[4:13:08] caught you you will not start celebrating see I knew that you wouldn't know the answers that is the purpose is not to you know making a point that you know even your stakeholders don't know the answers that is not the point the

[4:13:20] purpose of this meeting the the ultimate goal of of the meeting is to get the your 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

[4:13:35] agenda in detail you provide the project background right and also if possible 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

[4:13:50] practice that I always follow that I'll 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

[4:14:06] you might have heard that term multiple times in different context that repo building repo building that this is where it will be very useful what I do where it will be very useful what I do almost in all my projects that if I I'm

[4:14:19] working with that stakeholder for the first time I'll just simply say hi over teams over chat and maybe if there is possibility I'll just quickly connect with them say hi hello I'm part of this project I I joined this project as a PM

[4:14:32] or BA whatever and I'll be working with you I'll start setting up meetings uh to conduct the elicitation 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

[4:14:47] stakeholder and trust me it will help you a lot. Okay. So you prepare 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

[4:15:00] supporting things and you prepare your stakeholders also. All these things you do before conducting the elicitation. Right. So this is the first task of this knowledge area. Second task is about

[4:15:14] actually conducting the elicitation. So here in uh also one more thing which we forgot in during prepare prepare for elicitation you will also choose which technique you will use right like you will do a workshop

[4:15:31] you will do a workshop or you will conduct interviews right or you will use questionnaires or surveys

[4:15:43] techniques that we need to cover. So you will decide which one of these 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

[4:15:56] accordingly you need to finalize the technique also. Now tell me practically on what basis you will finalize the technique. What is the most important criteria which will help you decide which techniques to use

[4:16:09] in your project for elicitation? What are the criterias? what are the important points that you will consider in order to decide which technique should be used in this project. So the most important factor, the most

[4:16:22] important uh point is number of stakeholders. Tell me if there are 100 stakeholders, can you possibly conduct interview? If there are 30 40 stakeholders we cannot possibly even for 30 40 it's

[4:16:35] 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 conduct it's possible that when you reach 15th stakeholder he says something

[4:16:48] 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 in endless loop right. So when number of stakeholders are number of stakeholder

[4:17:05] 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 have 30 40 stakeholders what would you what what techniques uh what techniques

[4:17:18] will will you use let's say workshops let's say workshops right maybe uh brainstorming but when you have thousands of let's say 500 stakeholders can you do workshops

[4:17:32] even workshops will not be possible in with that number of stakeholders so maybe in that case you can send out surveys questionnaire stakeholder will also play important role. Do you think it's possible to

[4:17:46] always tell what exactly is the requirement? Is it possible to always express especially people who are not very techsavvy, people who are not very are very very introvert. So it's

[4:18:00] you not you do you do you do not get all the answers. So what techniques can you use in that case? So in that case you can send out surveys or you can do things like have you heard the term job [clears throat] shadowing active and

[4:18:14] passive job shadowing. So what is the purpose of job shadowing is to to you purpose of job shadowing is to to you know to to to actively or passively look at the person uh when he's while he's performing his job right so when you are

[4:18:31] doing what you do I'll come and spend time with you 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

[4:18:46] can have a firsthand experience looking at you 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

[4:19:00] that they'll not be able to explain because 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

[4:19:16] which we can utilize but it depends on mainly on 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

[4:19:32] maybe you will have to job shadow them to find out. 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

[4:19:45] shadow them? The preparation of the stakeholder bit becomes even more important when you are going to conduct job shadowing. Do you think everyone is job shadowing. Do you think everyone is comfortable when you know somebody's

[4:19:58] performing their jobs? Do you think everyone will be comfortable? I don't think so. Right? Even if my wife says can I come and if she says she asks me mean doing this training I'll not be comfortable it it gets very weird right

[4:20:14] them you might have to take the permission from their bosses that you 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

[4:20:29] of two types passive and active in passive you do not ask questions you do not interrupt but in case of active job shadowing you can ask questions you can then and there so in that case it

[4:20:42] becomes even more disturbing so in that case it's even more important to prepare your stakeholders before you come and you know have observed them so it is called observation or job shadowing both so that is preparation and then you

[4:20:56] conduct the elicitation now conduct elicitation is simple whatever you decided along with the material you will conduct that right? So you prepared for workshops, you send out the you sent out the invites and everything. Here the

[4:21:11] purpose is just to meet the stakeholder arrange uh you know and facilitate that discussion and conduct that session irrespective of what the technique was. interview, it was workshop it will conduct you it will you will conduct the

[4:21:25] conduct you it will you will conduct the workshop. The only difference is uh uh difference is that in workshop you may have support like somebody who is taking your notes. What do you call that person? A scribe and uh in case of

[4:21:40] interview also you may have to take notes. So uh and the difference main 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.

[4:21:54] On the other hand, you may have to conduct them quite differently. Right? So what happens especially when you have senior stakeholders, sometimes your direction. Somebody will start talking about something else and that's where

[4:22:08] your facilitation skills, we discussed about these skills on day one. That's 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:25] need to learn things like how you will make sure everyone is speaking but just make sure everyone is speaking but just imagine that you want to run workshop or focus group and you invited 20 people how do you select those 20 pe people

[4:22:38] there are two types of group right grouping homogeneous groups and heterogeneous homogeneous means same kind of background same kind of expertise heterogeneous means different backgrounds coming from different

[4:22:50] 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:23:04] 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 bathroom, I know I'm dealing with a specific problem. I need only the

[4:23:17] plumbers, not other expertise. Right? So, uh this is where you decide what kind of a stakeholders you are invited. Now, during the meeting also,

[4:23:29] now tell me one scenario. If you notice that out of 10 people, there are eight people who are speaking a lot or 10 six people is speaking a lot because maybe they are senior or something. Four people are not able to speak and you

[4:23:42] think they can also have some valuable inputs to provide to you. How will you will you do? We are doing this to get the requirement for the project. How job should I doing will help? So what what do you mean by project?

[4:23:57] When I when you say project, what do you mean by a project? What kind of project generally we work on? What is your understanding of project? Uh Jacqueline, right? Have a separate call to check on the on them or so. Basically the point I

[4:24:12] was trying to make you will always do you will always utilize more than one 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

[4:24:28] with them separately in onetoone interview or during interview you 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

[4:24:43] you send out questionnaire and you've liked one of the answers that you and you think that this user can give you a lot more details. So after that questioner you set up an interview in interview with that person. So you see

[4:25:00] it's very very possible that one single technique will not give you everything 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

[4:25:15] shadowing. So first of all projects are not always development projects right fresh requirements and you need to develop a software or something. Don't can you imagine a project where

[4:25:28] application was already running somebody 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

[4:25:42] task of a business your your task as a business business analyst is to go identify the problem identify the root cause of the problem and then propose a the purpose of this project is to solve that specific problem from the existing

[4:25:58] 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:13] something which is existing but it is not working as per the expectation. When you have uh knowledge areas like strategy analysis, a strategy analysis will always give you a strategy of the organization. What kind of you know what

[4:26:30] organization. What kind of you know 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 project that

[4:26:42] 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

[4:26:56] possible that the project which is getting initiated is coming out of this evaluation. Some problem was identified and that's why you are launching a for two reasons. there is an opportunity that you want to

[4:27:09] 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:23] right? What is the problem with job shadowing? The biggest problem with job shadowing is it is not uh you know very helpful when mind are there. Right? Something is mechanical. It's

[4:27:39] 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 be very useful. One more important uh

[4:27:55] point if I tell you that I'm coming to your house for lunch or dinner today or you ask me that go 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 because especially when you have habit

[4:28:09] 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 happens when you ask for job shadowing

[4:28:24] 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 work, how I function on day-to-day

[4:28:37] basis. So he will try to give you the perfect picture of the situation and in the real problem you might not be able to get. So obviously with all these techniques there are some pros there are some cons right so that is where you

[4:28:52] need to apply more than one technique at a time. Okay. So this is where you the information out of those stakeholders. You use your facilitation

[4:29:04] stakeholders. You use your facilitation skills. Okay. Just after that what happens when you conduct elicitation? You get a lot of information, right? You receive a lot of data. Whatever you call them, you receive a

[4:29:18] lot of inputs from these stakeholders. What is the immediate next thing that you do? Immediately you document all of this and maybe you will send out minutes

[4:29:31] 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? Status more important than that. Yes. To keep everyone on the same page. Status

[4:29:45] and action act points. Evidence. Yes, that is also important and keep record of agreed requirement responsibility. And the most important one is to save yourself. Right? It is possible that during the meeting somebody was not

[4:29:59] listening, somebody didn't pay enough attention and maybe the responsibility attention and maybe the responsibility then is with you. But when you send uh minutes, it means you have documented the discussion and mostly what is the

[4:30:13] 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 misstated anything. Right? So

[4:30:28] when you do this now who is responsible now collectively everyone is responsible. So that is the main purpose why we send out minutes so that we can document the discussion. All the points are covered. All the action items are

[4:30:42] documented and now everyone whether you listen during the meeting or not can give excuse. Now we have the shared accountability of whatever was discussed in this meeting. Everyone is in agreement. So that is why we send out

[4:30:56] 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 stakeholder engagement will be input to this task? Tell me which of these task

[4:31:11] will take stakeholder engagement as input. Which of these tasks? All of them input. Which of these tasks? All of them or one of them? All three. What if I or one of them? All three. What if I just use it in this and then because

[4:31:23] 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:37] and now I'm using this planning for next steps. So why do I need to keep looking back to you know enga stakeholder engagement when that input was taken care within this planning and now I'm using this planning right then uh that

[4:31:49] using this planning right then uh that is confirm elication result what is next information you know what is business analysis information every document that you produce right all these minutes that

[4:32:04] you create metrics traceability 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

[4:32:19] stakeholders. So that is the fourth task here. What will be the input? So basically the information that you need to communicate and the stakeholders that the only two inputs right information and you are communicated communicating

[4:32:34] them this 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:52] 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:33:06] a stakeholder. This is the output of this particular knowledge area. You confirm these elicitation results only where exactly you will conf convert them into a proper requirement documents in requirement

[4:33:21] analysis and design definition. A different knowledge area, right? And design definition. So in that knowledge area you will convert this information these results into properly documented well-written requirements

[4:33:37] that's where we create BRD FRD design documents different diagrams that's 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 with

[4:33:50] 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 there is no sequence. You perform these three tasks in sequence. You communicated the

[4:34:05] a different knowledge area where you created let's say BRD or you created a with stakeholders you you will come back knowledge area because you this is about communication of your document to

[4:34:22] stakeholders and then final task is manage stakeholder collaboration so that you can achieve the common goal of the project. So these are the five tasks. Prepare for elicitation, conduct elicitation, confirm elicitation

[4:34:35] results, communicate business analysis information. Very simple four task. And stakeholders throughout the project. >> And with that we have come to the end of our CBA business analysis course. If you have any doubts or question, ask them in

[4:34:50] team of experts will be happy to help you as soon as possible. Until next time, thank you for watching and keep learning with SimplyLearn.