[00:40] Analysis Professional full course by Simply Learn. If you're a business analyst looking to strengthen your requirements management, stakeholder collaboration, and strategic analysis skills, this course is designed for you.
[00:53] business analysis planning and monitoring, elicitation and collaboration, and requirements life cycle management. You'll also cover strategy analysis, requirements analysis, and design definition, and
[01:09] solution evaluation. These are among the major knowledge areas covered in the BABOK Guide version version 3. By the end, you'll understand how to prepare end, you'll understand how to prepare for the IIBA CBAP exam and manage
[01:22] confidence. Let's look at today's agenda. Business analysis planning and collaboration and stakeholder management, requirements life cycle management, strategy
[01:36] analysis, requirements analysis, and design definition, solution evaluation, agile perspective, business intelligence perspective, and business architecture perspective. Now, here's a small quiz question to test your understanding.
[01:51] Which BABOK knowledge area focuses on tracing, maintaining, prioritizing, and approving requirements? Option A, strategy analysis. Option B, solution
[02:03] evaluation. Option C, requirements life cycle management. Option D, elicitation cycle management. Option D, elicitation and collaboration. Simplilearn CBAP training with an IIBA endorsed BABOK version 3 curriculum and
[02:20] live online classes. Get exam application assistance, real-world case studies, simulation assessments, and over 900 practice questions to prepare confidently for the CBAP exam.
[02:32] >> playing, let's say, intermediary role, right? A person who is sitting at the intersection of technology, business, different stakeholders. It's, country, right? And if you're not able to speak the
[02:48] 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
[03:02] place to other place, you 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
[03:14] you get a translator who can translate the language, local language of that country, to your language and your language to their language, what will happen? Suddenly, the the the the communication
[03:27] will become smooth. You will be able to navigate through the different challenges. You will 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 will
[03:39] start working in the project, and people who already who are already working, that business guys, different stakeholders, operations, compliance, legal, they they may not understand the tech part, right? How the
[03:54] solution will be built, how it will look like, uh they might not be able to do that. On the other hand, typical developers may not be able to understand the business language, right?
[04:06] What they are asking us to build, what is the need for this uh system, right? What kind of uh other uh like legal considerations are going to be there.
[04:18] understand that. So, the problem is same. developers' language, developers cannot understand business language. And that is where we need a translator, and that
[04:30] translator is the business analyst. And you know, when I was starting my career around that time, early 2000, or earlier than that, the BA role was not that defined. It was not very properly defined.
[04:43] Mostly, you would see that, you know, a person working as a a tech lead or team lead, he would talk to clients, he would document something and pass it on to dev developers. Or a person who is sitting on site,
[04:57] irrespective of his title, whether he's a project manager, team lead, or whatever, he would engage with the customer and pass on the information to the offshore team, right? That is how it was done. But,
[05:09] slowly and steadily, the role was defined properly, people understood the need for this role, and then when IIBA came into picture, BABOK was published.
[05:21] The IIBA gets a lot of credit to formalizing this role of a business So, this is a business analyst, somebody a translator, who is a communicator, who is sitting who is sitting who is a
[05:35] and who is uh you know, sitting at that intersection where he is able to deal with different uh uh issues, he's able to translate the requirements, he's able to gather the requirements, etc., etc. Right? It's a very important
[05:49] And uh obviously, in today's world, we'll talk about it later, also, but in today's world, there is, like any other role, BA role is also going to get impacted by by AI and everything. Right? So, that is
[06:05] also we we need to take care. But, uh BA role is indispensable, right? It's BA role is indispensable, right? It's very important role in today's context.
[06:17] from surveys, transactions, support, etc. They discovered poor mobile experience. They collaborate with IT. They define support workflow, etc., etc. So, we'll go through it all of these things one by
[06:30] 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 these things
[06:42] BA need to do so that it's like I'm not just translating. I'm also providing you supporting documents. I'll create something which can make you understand better. Right? So, it's not just that I I
[06:56] translated what business 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 better, that all that is something I'll also do. Right? If uh if I'm talking
[07:11] about, 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.
[07:26] we just discussed, understanding enterprise problems, goals, requirements, analyze those needs, analyze the solution. Devising strategies, facilitating
[07:39] change. So, all of these things we do. examples. Don't think that every one of you will play exactly same role. Right? BAs in different industries, in
[07:55] roles. It depends whether you are sitting and working closer to the business or you are sitting and working closer to the tech. actively participating in test cycles also, whether you are part of
[08:10] bank, or any other organization. So, there are on the basis of these things, on the basis of combination of these things, you will see different flavors of of a BA role. Right? Somebody will do things
[08:25] which are differently than other BAs. Right? So, you may uh you should never different projects will play exactly same role. Okay? Sometimes you will do a lot of
[08:39] may not talk to a stakeholder. Your focus is mostly on analysis and solutionizing. Right? So, all those very variables and variety of roles will also be there. And I'll give you enough examples so that you can understand.
[08:53] A BA who is who is let's on the buyer side somebody selling the product, somebody buying the product, and you will see there is a huge difference um on the roles and responsibilities of
[09:06] those people. So, we'll I'll give you some detailed examples also. To become a BA, one should possess the following: business knowledge, communication skills, tools, interaction skills, behavioral characteristics, and
[09:21] 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 communication skill, or who doesn't need interaction skill, or who doesn't need
[09:35] analytical thinking, problem-solving, or behavioral characteristics, right? So, everyone who is playing any role whatsoever in any corporate or in any we all need all of these characteristics, right? They are not
[09:50] characteristics, right? They are not something very unique to a BA. Agree or not? So, but why we are talking about them for a BA? So, for example, what do you mean by business knowledge?
[10:04] 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 knows that, you
[10:17] know, uh when he's paying, he should get something in back something in return, right? So, the basic transaction, people who are not educated at all, who has who have never gone to this to any of the
[10:31] schools, they also know the basic transaction. How to survive in this so, everyone is aware about that much. So, that is kind of knowledge everyone needs to needs to have.
[10:44] But then, if you are working, let's say, as a business analyst, in in any of the sectors, let's say, telecom or pharmaceuticals, don't you think that you need to know finance better than other people who who
[11:00] who knows who know them just to survive or just for day-to-day life? So, your understanding will be will be much much better. You will start For example, I am working in banking. So,
[11:13] top of it, now I know what is the meaning of account, what is the meaning of credit card, right? So, then I have more
[11:25] in-depth knowledge of my domain. Then somebody is working, let's say, in a particular bank, let's say JP Morgan. further
[11:37] even more detailed knowledge of that bank. Okay, I I already knew credit cards, but what kind of cards JP Morgan are offering? What kind of products we offer to our clients? Right? So, you have even more
[11:50] understanding, granular, deeper understanding of the products of of your What kind of what kind of clients they have? Uh what kind of services they And then finally, if you're part of a particular application, you're part of a
[12:03] particular project, you will have very detailed knowledge of that project, right? So, the business knowledge goes deeper in a steps. Everyone would have some understanding, then depending on your role, depending on your industry,
[12:17] you will have deeper and granular understanding. And then of your product, of your whatever you're working on, you will have very in-depth knowledge. Similarly, communication skills, right? Everyone needs to have communication
[12:30] but why it is mentioned for BA? Because BA talks a lot. Talks a lot means not they don't talk I'm I I didn't mean they talk nonsense, but they they have to talk a lot. They have to talk to, you know, uh stakeholders to elicit the
[12:45] requirements. 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
[12:59] 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
[13:13] We are not able to, you know, uh speak about it. And in the previous slide, what did you see? That it's important to understand problems and goals.
[13:25] Right? How would you understand 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 you know, what do you call it? Uh
[13:40] what do you call it? Uh Uh just so your verbal understanding and Non-verbal non-verbal communication also, the body language, the facial expression and all. So, that is how and
[13:52] and then you run a lot of meetings, right? You are going to run a lot of so requirements, to present the requirements, to
[14:04] let's say you are doing a brainstorming session to find the solution of the problem and things like that. So, you will have to engage people and you will have to run those sessions. That is why interaction skills. So,
[14:16] communication is like what you talk and all, but interaction is more on the engagement side, how to run different sessions. It will happen multiple times like if you are not good with with
[14:28] talk about things which are not even important in that meeting, right? So, how you will make sure that people are sticking to the topic, how you will make sure that you are able to get to the outcome of that meeting, expected
[14:41] where you need to have interaction skills. then analytical thinking because you have to analyze things, you have to solve problems, right?
[14:54] And tools and technology everyone needs like we are right now using Zoom, you like we are right now using Zoom, you you use Teams, Outlook, Jira, and in today's AI world, we need to definitely use AI tools, right?
[15:06] There are It's not like it's it's no longer a choice. It's It's uh enforced in different organizations, even in my organization it's enforced that you have to use AI. You have to save time.
[15:19] So, these are the now in this course, we will not cover communication skills, interaction skills. They all These all are soft Not part of this particular course. Here, we'll talk about
[15:32] business analysis, right? How to perform business analysis. What tools and technology What tools and techniques are available to you to use while performing business analysis. So, the core agenda of this particular course is business
[15:47] of this particular course is business analysis skills, not these soft skills. But, if you think you are you are already good at these skills, then it's good. Otherwise, you can try to You should try to improve them. Right?
[16:01] Because theoretically, it looks very easy. Okay, I'll go to that person and collect the requirements. But, in real world, it's not that easy. Some practice, some experiences always required. So, try to
[16:16] uh Try to you know, 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 IIBA's
[16:31] pass one of the IIBA's exam exams, one of these exams. Uh So, there is When I did, there used to be only two certifications, CCBA and CBAP. Certification in the competence of
[16:44] and certified business analysis professional. is uh What is the name? Elementary or something like that. So, this is the exam for freshers with without any
[17:00] Entry-level or something, entry certification for business analysis. We'll see the full full form. So, they added it later on. experience requirement, which we will learn in coming slides. But, basically,
[17:15] these are the three certifications which are offered by IIBA, that is Analysis. Uh few years back, they started uh you know, talking about CA C Certified Business Analyst CBATL Thought Leader.
[17:32] Certified Business Analyst Thought Leader. And I was very keen that, okay, I'll do it. I I'm holding CBAP 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
[17:45] I I have no idea. But then for some uh for few months it was there on their website, you know, coming soon, coming soon CBATL. But then it it went away and it never came back in last 3-4 years.
[17:58] So, these are the certifications, right? Eligibility, etc. we'll just see in And uh So, this is the organization. IIBA is the organization, right?
[18:10] As I said, they I think they were uh they launched the 2008 or 9 or something. Before that, there was no IIBA. These certifications were not And that's why I was saying that the business analysis practice was not
[18:23] standardized. When IIBA came into existence, when they launched this book, they tried to standardize things. What is the role? How that role should be
[18:35] performed, etc. etc. So, all these three exams, they all are based on the same book, Business Analysis Body of Knowledge. Similarly, for PMP, we have Project Management Body of Knowledge, PMBOK.
[18:49] Here we have BABOK. All these exams are dependent on this or based on the same book. So, and this is what we are going to cover. We in this course in 36 hours, we'll cover this entire book. And that is why I was
[19:03] telling, irrespective of your experience, whether you are eligible for CCBA 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.
[19:17] You will be You will be prepared for one of these exams automatically. Business Analysis Body of Knowledge is a globally recognized standard guide
[19:31] that outlines the core knowledge areas, tasks, techniques, and competencies. the overall BABOK is divided into knowledge areas, right? Uh have you ever tried any one of you have a you tried reading
[19:46] It is 100% theory. 100 means 100%. You will not see You will not find even a single example in this entire book. It's a good thick book.
[20:00] back. I challenge you if you find even a single example. No explanation with examples, no mathematics, nothing. It's just complete theory. And that is
[20:14] where I think these classes are important because it's not easy to read something like BABOK. So, first is enterprise. It is a system of one or more organizations and the solutions they use
[20:27] to pursue a shared set of common goals, right? EdTech Enterprise decided to expan- expand its digital presence. So, they are like bigger companies, bigger
[20:40] organizations. You already know that organization, it's an autonomous group of people under the management of a single individual. So, like Simply Learn. It's a company.
[20:52] Now, those two terms are very common, so that is fine. What is requirement? It is that is fine. What is requirement? It is a usable representation of a need, right? It focuses on understanding the kind kind of value that could be
[21:04] delivered if a requirement is fulfilled. So, requirement is a is a need that one of these stakeholders, one of the person would have. Okay, um few basic questions.
[21:18] All of you are working? Not all of you, right? But people who are working, you do you fill timesheet on a weekly basis or maybe monthly basis? You fill a timesheet, right? And in that timesheet, what do you do?
[21:31] You put your time against a particular project. Right? What Why do you do that? So that you can bill or your company can working for, right? You are doing something for a client.
[21:46] You fill your timesheet for that project and that project on that basis, your finance team will bill your client and get the money. So, who exactly is paying your salary then? Who exactly is paying your salary?
[22:04] client, right? How is your company making money? Whatever client pays, the your company will take a cut and pass on rest of rest of the money to you as your salary, right? On a high level,
[22:16] that is how it That that's how things work. Uh on the basis of multiple 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
[22:31] money and that they pay for our salary. But if you think about it at a high company is also getting paid because we are working, right? And the client is the person who is paying. So, how you should treat your client?
[22:48] accordingly, right? That they are the people who are paying. Now, you tell me difference between a a customer end user? Is there any difference between a
[23:01] customer and uh this end user? See, my handwriting is very bad. I I keep writing because whenever there is I'll write on whiteboard or I'll just annotate on the screen.
[23:15] But, you have to put efforts to understand my handwriting. So, if uh uh you are your company has given you a laptop, let's say your company bought
[23:27] 1,000 laptops from HP. Uh the your company is the customer of HP. Right? Your company bought 1,000 laptops from HP, so your customer company is the customer. And you you guys are the end
[23:42] user because you are using. I bought a phone, let's say I I bought I bought a phone for my wife. So, I'm the customer, my wife is the end user or Right? Uh So, that is the difference, right?
[23:57] Customer and end users. Who will have requirements? users can have their own requirements and customers can have their own requirements. Now, tell me one more thing. We are
[24:11] talking about design. It's a usable representation of a solution. It focuses realize. Uh is there any difference between requirement and solution? Some basic things we are talking about
[24:25] so that you are comfortable with terms and your understanding gets better. So, if I tell you that I'm hungry. I'm telling you the problem, right? The requirement. That I want to eat, I'm
[24:38] hungry. But, what I want to eat is the solution, right? I'm thirsty and you 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.
[24:54] So, requirement is something which can talk about the problem or the need and how that need will be fulfilled is the solution. I'm thirsty is the need. what is the solution? Let's say I need uh a lemonade.
[25:09] Lemonade is the solution. Right? So, as a business analyst your need. Your focus is also to identify what kind of solution or uh that is stakeholder may need or
[25:25] he should get. Right? So, that is also you need to understand that there is a difference between requirement and the solution. And there is also a difference between the uh desires and actual needs.
[25:39] the uh desires and actual needs. I can I can ask for anything. And uh uh as a business analyst list, it's your job to first of all identify my real need. What actually I need instead of
[25:53] delivering whatever I ask you to deliver. It's like when you when you want to buy a new car how many features you look for? I want this in my car, I want this in my car. You know, it should have cruise control,
[26:07] sunroof, moonroof, ventilated seats. 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
[26:21] uh same goes for mobile, same goes for laptop. So, customers can 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
[26:35] customer identify what they need. You help your customer visualize what kind of solution will fulfill that need. Right? Both of these are your responsibilities. Risk is nothing but uncertainty.
[26:48] Something uncertain that may happen or may not happen in future. But in case it 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-
[27:04] probability of the risk and impact. So probability means whether it will happen or not. And impact, if it happens, what will be the impact on you. So you want that there is a probability of rain. Right? 100% probability. And you carry
[27:20] thousands of rupees cash in your pocket. Then that is the impact. If you don't carry anything, there is a risk of rain, but you know I'll get cold or something, but physically there will not be any impact
[27:33] on currency that I carry. Right? So we'll talk about risk and risk risk mitigation, how how we manage risk, and how we mitigate risk. We'll talk about how we mitigate risk. We'll talk about all of this.
[27:48] Now, look at this this BACCM, Business Analysis Core Concept Model. concepts. Need, change, solution, context, value, What is or who is a stakeholder? A group or
[28:04] change. Or the simplest possible definition of a stakeholder is project.
[28:16] Or a person who can impact the project. Anyone who can impact or who can get stakeholders. So if I ask you, who will have a need? Who will have a problem to solve? Who
[28:29] will have a a requirement? A 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
[28:46] you are uh have a problem, right? If I fix your problem, you will get some value. You will let's say you will feel you are able to do your business better.
[29:01] better depending on the solution that I provided, right? So there is some value to the end deliver the solution. Right? So all of these concepts are
[29:14] connected. A stakeholder had a need. In order to fulfill that need, I delivered a solution. When that solution got delivered, a stakeholder got some value. delivered, a stakeholder got some value. Right? You had you you were hungry. That
[29:28] was your need. I gave you a very nice drink. And when you had that, you felt happy. You felt like you were you you were not thirsty anymore. So now what is the change? In order to
[29:43] deliver that solution, you will have to go through a change, right? So what is there are these two terms which you should know if as is. What is your as is?
[29:57] As is and to be. As is is also called your current state state. So current state and future state.
[30:11] I don't have a house. That is my current state. Tomorrow I buy a house and shift into that. That is my future state. Right? Current state and future state. In order to move from current state to future state, well, will it happen
[30:25] automatically? Obviously not. I'll have to transfer. I have to request a pack packers and movers to pack my stuff from my rented house, move to move me to a new house. So there is a complete transportation and everything.
[30:39] So this is called change, right? The process or act of transformation which will move your move you from your current state to the future state. So, that is called change. So, a stakeholders had needs.
[30:53] In order to fulfill those needs, we went through a change process and delivered a solution. When that solution got delivered, the Right? Now, what is context? All these five
[31:07] terms are easy to connect. What is the context here? In a scope and out of scope. In a scope means things that you will project. Things that you will cover in your
[31:19] project. Right? Out of scope are the items that you will not touch in this project. Okay? Uh when we create requirement documents, we all also create sections where we
[31:32] 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
[31:45] and you tell the developers that, you know, obviously walls are in scope, in scope, but he will also mention that interior designing is out of scope. So, whatever cost that you are paying, this is for
[31:59] walls, for ceilings, plaster, etc., maybe a coat of paint, but no furniture. conditions conditioners are out of scope. Right? So, that is why you have to mention that in documents so that it's it's it remains clear what is in a
[32:15] scope, what is out of scope. Now, tell me question. When you are creating this agreement for When you are creating this agreement for your house,
[32:30] airport of your city, is that in scope? in scope of of your house project? No, right? It's not. Building a hospital nearby, is that part of your individual house's project?
[32:46] No, right? Similarly, building a new school, because you are talking about your own house. You're not talking about setting You are talking about building your
[32:58] personal house. How can airport, railway station, hospital, and school be in scope or out of scope? Right? They That is They all are out of scope. But, do you mention them in your document?
[33:10] so walls, ceilings, and everything is in scope, but hospital, railway station, write that? We don't write. If you start writing all
[33:22] of these things, your project document will become encyclopedia. States is out of a scope. Everything is in In Australia is out of a scope. Everything outside this city is out of a scope. So, everything on this planet is
[33:37] out of a scope except this except that particular house. A tiny house, a small house is in a scope, and everything else on this planet is out of a scope. Will you still write out out of
[33:50] a scope items? You will create a huge encyclopedia, right? So, why don't you write all of that in a in out of out of scope section? Because they are not part of your context. And that is the
[34:06] 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
[34:20] working in? So, because the condition or the circumstances are related to individual personal house, nobody is going to ask. By default, airport becomes out of
[34:33] scope. Well, that's not the context. Right? Somebody like uh you know, uh let's say Shivam says, "You know, Gaurav, I'm not able to hear you properly." And uh Simply Learn should also provide
[34:47] me a high-bandwidth internet connection. Now, what should I say? Shivam, 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
[35:02] related to material or any questions, anything, then that that can be provided connection because uh because of this training, that is not
[35:14] part of the context. That's uh that's not the context. That's not in scope. not the context. That's not in scope. So, that is how these these six terms are very much related, and they are interdependent. I hope you are able to
[35:27] You know, uh stakeholders would have need in order to fulfill their needs, you will have to go through a change process
[35:39] or a transformation process. You will deliver a solution {slash} solution will provide them with a value, and all all of those things will be done Right? Now,
[35:53] 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. concepts to consider the quality and completeness of the work. Right? What
[36:09] the needs? What are the solutions? Who are the stakeholders? What do stakeholders consider to be of a value? Right? What are the contexts that we and solutions are in? So, all this all these six
[36:23] terms, they'll help you ask right questions and complete the requirement work. Okay?
[36:36] earlier, this BABOK 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?
[36:51] bit. So, that is fine. There is one chapter which is called perspective. So, IT perspective, agile perspective. So, that particular chapter is not tested in the exam. It's completely
[37:06] theoretical and like we can read in just 1 hour. Now, first one is business analysis planning and monitoring. Elicitation and collaboration, requirement life cycle management,
[37:19] solution evaluation, requirements analysis and design definition, and So, what is the first one? Business analysis planning monitoring. I think instead of reading, I'll just explain here.
[37:32] 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.
[37:47] And how I will monitor my progress. Here Here, you will not conduct the elicitation. Here, you will not meet the stakeholder. Here, you are just planning. Okay? So, first chapter is all about
[38:02] planning the project and your activities in that project. And as I said, we will go in detail. We will spend two to three classes on each each of these knowledge areas, right? So, don't think that we are just going
[38:16] very high level. I'm just introducing the names and we will go deeper in each of them. Second is elicitation. Elicitation, what Second is elicitation. Elicitation, what is the meaning of elicitation?
[38:32] collecting the requirements, right? Now, have you heard the term requirement Why which term do you like more? Requirement elicitation or requirement Requirement elicitation or requirement gathering? And why?
[38:47] And why? Requirements gathering is much better. Yes. So, but you you are you all of you are thinking superficially, right? But what looks easy, what sounds easy. But think about it. What is the meaning
[39:03] actual meaning of gathering? There is a document on my desk. I just gathered it, right? There is another envelope on my desk. I just gathered it. Do you think requirements are lying down on the floor
[39:16] or lying down on on a table where you go and just collect them? So, gathering means collection, right? Collection is not it's not like you just go and stakeholders are ready with their
[39:29] requirements and they'll hand 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?
[39:42] To bring forward, right? To ask right questions and bring the requirements forward. Not just not just because somebody is telling you, but because you are probing. You are asking right questions. You are
[39:56] cross You are cross-questioning the needs. You are trying to ascertain that like that, right? So, instead of one-way communication requirements and you are just documenting them,
[40:10] instead of that, you are it's a proper session, two-way communication, two-way session, two-way communication, two-way probing, a discussion, debate, and then you get the requirements. So, that is the English meaning of
[40:23] And English meaning of gathering we discussed, right? So, now once you understand the exact meaning, then you you you know that elicitation is a better term because for requirement gathering you will not get the salary.
[40:35] Right? You will not get enough salary for just for gathering. You are getting you perform elicitation, not just gathering. Anyhow, people will keep using these terms interchangeably. Even I'll I'll
[40:49] 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 and collaboration knowledge area area, you actually
[41:01] 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 output output of elicitation? When you
[41:14] perform elicitation, what you will get? Yes, so you get a lot of information. You get lot of data. Right? In order to convert that data or the information into proper requirements,
[41:29] you perform requirement analysis and design definition. 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
[41:43] 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 all of that data into properly written, properly arranged requirements. And that
[42:01] part is done in requirement analysis and design definition. You perform the analysis, you create requirement document, and you create all other design artifacts like if you want to create any uh
[42:13] uh uh flow diagrams, data flow diagrams, you create UI uh mock-ups, etc., etc. Right? Once you identify the requirement, their life cycle will start. So,
[42:27] requirements 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 humans, right?
[42:39] You were 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
[42:52] itself can change. Some of the other things related to requirements like right? They can change. So, as a business analyst, you gathered requirements, your job is not done. Uh you have to maintain those requirements
[43:06] throughout their lives. So, that is done in requirement life And uh uh solution evaluation is what you deliver what is built that
[43:20] performing as per the expectation or not. So, that is uh done in uh solution evaluation. Evaluate what is done. And then is strategy analysis is what do
[43:35] you 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, you I'll keep repeating it and you will understand it
[43:49] that they are not performed in a particular sequence. Depending on the project, they can be performed in different sequence again and again, repetitively, iteratively, right? That you will understand when we
[44:03] go deeper. But, just understand it doesn't mean that first we'll do then we'll do this. There can be a project where the project is launched because there is a problem identified. So, solution evaluation is
[44:16] performed. Problem is identified. Then you 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.
[44:29] Or uh at a organi- at at the organizational level, strategy analysis was was performed. root cause analysis. Or you performed uh
[44:43] 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 the project. So, you see,
[44:56] strategy analysis 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
[45:09] later slowly. Right? So, these they all are interlinked, right? All six knowledge areas. Now, one more thing, under these knowledge areas, Okay? Um
[45:22] One of them has six tasks. One of them has four tasks and remaining have five tasks each. So, there are total 30. You can say five five five, four and six. So, total 30 tasks. And there are 50 techniques.
[45:38] So, there are six knowledge areas. Right? All these knowledge areas have 30 30 tasks.
[45:52] And there are in total 50 techniques. there is many-to-many relationship. Right? I don't know if you know these symbols, but let's say there is many to many relationship between task
[46:06] and techniques. One task can use one or more techniques. uh elicitation, right? In order to perform elicitation, for this knowledge area, what could what
[46:21] can be the tasks? Prepare for elicitation. Prepare for elicitation. Conduct elicitation. Document elicitation result, etc. Right? So, this task, let's say conduct
[46:35] So, this task, let's say conduct elicitation, is a task under elicitation knowledge area. Conduct elicitation task can be performed using multiple techniques like
[46:49] like interview,
[47:01] conduct elicitation is a task under elicitation and collaboration knowledge This task can use one one or more than one techniques like this.
[47:15] Other way around, workshop as a technique can be used in multiple tasks. workshop. to provide a walk-through to stakeholders about my requirements to
[47:29] I want to evaluate the solution. 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
[47:44] can be can can use multiple techniques, and one technique can be used in different different tasks. Okay? So, that is how BABOK is organized. Six knowledge areas, 30 tasks, and 50 techniques. Okay?
[48:01] Every task is also organized in a particular fixed template, which I'll explain later. Uh or let's we can talk about it now as well. So, task is like name of the task.
[48:16] The order may differ or maybe I miss one or one point or two, but you will get So, name and description of the task. Conduct elicitation. What is the a purpose. So, it'll tell you what is the purpose
[48:30] of this task. What inputs required to perform that Right? What will be the output once you perform this task? So, input and output of the task.
[48:43] What are the key elements? What exact What exactly is done? And uh there is there is one or more two headings like additional inputs,
[48:57] So, basically, every task that you perform, there will be some inputs which you will You will do some processing here inside this task. In order to do this
[49:10] techniques. And then there will be output of that And then there will be output of that task. Right? So, each and every task in BABOK is
[49:22] 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. Uh what you need to focus on. Do you need
[49:38] 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 which is here. We focus on 50 techniques.
[49:51] Right? Those techniques is some technique is something that you actually You don't have to talk about inputs, outputs. You know that uh with time you Uh and also to pass the exam and throughout
[50:05] 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 yourself. And I'll tell you, I'll
[50:18] 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? What are the key concepts, key elements
[50:33] related to that task? That is where you need to focus. You should have absolute And you should have absolute clarity on 50 techniques. These two things we need to focus. Uh obviously, I'll explain why these
[50:46] Uh obviously, I'll explain why these inputs, why this output, why this input from this that particular task. All that we will discuss. But you don't have to people will say, "See, sir, there are 30 tasks. In case
[51:02] there are four inputs, so there will be 120 inputs. And let's remember this? All 50 techniques can be used by be 200 types of permutations combination.
[51:16] 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 don't have to memorize them. You just need to focus on
[51:29] understanding key elements of a task. And in isolation, all 50 techniques you need to understand. Rest everything will come automatically once we move ahead in this course. This is just the list of 50 techniques
[51:43] which are which we are going to go through, all of them acceptance and evaluation criteria and all of these. So, there are
[51:55] in total 50 techniques. See, one page and second page. So, two pages, they are just listing down the techniques. So, we'll come we'll cover them as and when we come across them in our content, right? From the
[52:09] BABOK point of view, all 50 techniques are part of a separate chapter. But, when we study, we'll try to cover them as and when we come across them instead of So, I'll keep explaining you techniques wherever we find them getting
[52:23] used in our material. Okay. 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.
[52:37] there was one more question on the previous slide. Yes, what does BACCM stand for? Yes, business analysis core concept Which of the following is a business analysis
[52:52] 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 previous version of BABOK, then you
[53:08] correct. They used to be the names in the previous version. But, now they have changed. So, elicitation and collaboration is there, Enterprise analysis has become a strategy analysis.
[53:21] Right? Solution assessment and validation became solution evaluation. And requirements analysis and life cycle management, right? So, these three, B, they used to be the names in the previous versions of BABOK. But, in
[53:37] present version and current version, only A is correct. I'll just answer. in typical BA engagement? All of them are your stakeholders. Next is
[53:52] IIBA stands for the International Institute of Business Analysis, association dedicated to supporting and advancing dedicated to supporting and advancing the discipline. It was founded in 2003,
[54:06] Ontario, Canada based, and publication major publication is BABOK Guide. And how does it define the standard? Through the BABOK Guide. Identify the skills necessary to be effective through the IIBA Business
[54:19] Analysis Competency Model and self-assessment tools. And there are discussed. So, if you go to the website of IIBA, you will see that there are some resources which are available for
[54:33] free. And there are some resources which are available for members only. So, you can use them like in Business Analysis Competency Model or there is a self-assessment tool. So, you can use
[54:46] that. Uh IIBA membership uh it provides access to exclusive content and support. So, if you take the membership, you can get access to career action guide, etc., etc. There is as I
[54:59] you can get. When you take membership, you get free When you take membership, you get free access to new versions of BABOK as well. You can participate in different networking and community events. And
[55:12] 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 they want to create a new version of BABOK, things like that. So, at in those
[55:25] in there also you can get some volunteer opportunities. It's is also there also there are many webinars that they run. Some webinars are public, some webinars are members only. So, that is also
[55:39] another benefit of taking membership, right? Now, if you are planning to write the exam, whichever CBAP or CCBA, in that case, taking membership is sensible. Maybe you next year you you
[55:53] think of not renewing it, that is fine. Because if you take membership, the cost of membership is less than the discount you get on the exam fee if you if you're a member. Right? We'll just see coming slide.
[56:08] So, see there are three. First is entry certificate, second is certification of capability, and third and final one is certified business analysis professional. So, this is the basic one. This is the
[56:21] middle one, and then the final one. Okay? Now, what is the difference? As I told you, the book is same, content is same. Then, what is the difference? For CBAP, you need to have a minimum 700 7,500
[56:36] hours of business analysis work experience in the last 10 years. So, there is this experience requirement that you need to fulfill. How do you calculate If I try to simplify this for your
[56:49] understanding, let's say how many days there are there in a in a in an year? 365, right? Out of that, there are holiday weekends,
[57:03] uh 104 Saturday, Sunday. Then, you have 15 20 national holiday public holidays. Then, you have your sick leave, annual Then, you have your sick leave, annual leave. So, I think if we reduce
[57:15] all that, conservatively, we work for roughly 200 days. 200 days, 220 days. So, conservatively, I'll say 200 days into 8 hours per day. So, again, if I round it off, let's safely conservatively assume you work
[57:32] 1,500 hours per year. So, for to get 7,500 hours of experience, you need to have at least 5 years of prior business analysis 5 years of prior business analysis experience. 5 years.
[57:49] expectation, that is the eligibility criteria for CBAP. That is fine that you divide this experience into six knowledge areas. You can equally divide like 1,000 hours of 1,400 hours in each of the knowledge
[58:01] area. That is fine. So, that is first. At least 5 years of business analysis experience, right? And then professional development. Have a minimum 35 hours of professional development. So, the training that we
[58:14] are conducting right now, the class that you are in right now, this will give you you are in right now, this will give you 36 to 38 hours or maybe 40 hours 36 to 38 hours or maybe 40 hours of PDUs, professional development units.
[58:26] So, this training that you are attending with me right now, this training is a You need to complete this training or from some other vendor, that is fine, but at least there has to be at least one training which uh you attended at
[58:41] training completion certificate is yesterday that from from the portal, LMS portal, you need to download your completion training completion certificate. And
[58:55] that certificate you have to upload when you apply for CBAP exam. this is the second important requirement, and third one is references. You have to provide two references.
[59:08] Now, they can be uh your managers, manager. So, that is fine. If you are a fresher, then you can provide reference of anyone who is already CBAP certified.
[59:23] have to be CBAP certified, right? Your manager without certification is fine. otherwise you can provide contact of anyone who is CBAP certified.
[59:36] So, what happens when you provide the reference? They will get email from IIBA that and they'll ask few questions. So, it will be a simple five, six question long form
[59:49] 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 mention as your reference, please uh align them. Please inform them that
[01:00:03] I'm providing your name with your email ID as my reference to CBAP. So, once when you get the email from IIBA, please respond to that email, right? So, these are the main three requirements. Work experience, at least 5 years of BA
[01:00:18] experience, 35 hours of minimum training in last 4 years. So, it's not like you attended a training 8 years back. That will not be counted. So, something which four years, that training and then your reference. These three are the main
[01:00:33] requirements. Now, what happens when you if you don't have that experience? So, next certification is CCBA, right? So, there this requirement will be just half, 3,700
[01:00:46] 50 hours. So, that means you can say two to three years of experience is enough. Right? And then you can equally divide this by half. This requirement will still be there, but I think number of
[01:00:59] hours will be less. 20 or 25 hours of training is required. References will I think you need to provide reference. Then for ECBA, this is not required. No
[01:01:11] Uh and no references are required because they are considering that you are fresher. You have no experience. So, So might not have any professional references to provide. So for ECBA
[01:01:24] requirements are very very lenient. And the question paper is also slightly the question paper is also slightly simpler as compared to CCBA obviously. experience. So what I would suggest
[01:01:37] the important part that go to iiba.org portal. And check Let me also tell you one more thing before we move on.
[01:01:50] See this is the fee for ECBA exam, okay? Application fee none. Examination fee is $195 for members and $350 for
[01:02:02] How much is the difference? Almost $100 or not almost exactly $155
[01:02:18] CCBA there is additional application fee $145 non-members. And then 250 and 105. So again $155 you save if you take the membership. Okay? The total
[01:02:32] you take the membership. Okay? The total cost if you're a member is roughly $400, right? $395. And without membership it will be exactly $550.
[01:02:44] For CBAP the fee is almost similar to $100 more. more. So total fee for CBAP if you don't have a membership is
[01:03:01] $650. Right? And for a member it is $500, $495. Okay? So you save almost $155 in the fee if you take membership. And
[01:03:16] 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 the all the countries into three categories.
[01:03:29] categories. And the fee is dependent on your region. than uh other countries. Let me quickly give you some idea of that as well. I I have no problems if you take
[01:03:43] membership or no you you don't take, that's completely up to you. The only difference is because for the first year you can get Why I'm suggesting is for the first year you'll get both the benefits, right? You will
[01:03:55] pay less fee for the exam. At the same time, you can get the membership benefits. IIBA, if we go to the membership Let's see what if they have revised any prices earlier.
[01:04:09] It used to be 50, 60 dollars. Let's see. Region 1, 155 USD. Region 2, 100 USD. And Region 3, 60 USD. is a list of countries. So, for example,
[01:04:30] dollars and you save 155 dollars on your exam. So, you will still end up saving 80, 90 dollars. People who are in this still save. People who are in Region 1, Australia,
[01:04:47] Austria, USA, the UK, they'll not be able to save, but still at the same cost, you will get the benefits of membership along with the So, this is on the membership. If you take
[01:05:02] If you look at the certification, IIBA certifications, so they are they are they started offering other certifications on data point of view, they still have just three.
[01:05:15] three. So, when you click on certification, Now, let's go to the core certification, right? Core business analysis
[01:05:27] certificates, ECBA, CCBA, and CBAP. So, let's check the criteria for ECBA. Just to make sure that whatever is mentioned in our slide is still There is no change.
[01:05:41] So, there are no requirements. Sorry, uh this includes this includes IIBA membership. See, this is fine. There is no eligibility criteria such for ECBA, right?
[01:06:09] 21 hours of professional development instead of 35 for CBAP. Rest everything is same. So, the only difference is in experience and Right? And for CBAP, I already explained.
[01:06:25] 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 make yourself comfortable with the portal, and identify which certification
[01:06:39] certificate is more suitable for you right now. What will happen after 3 years? So, all these certifications are valid for 3 years. After 3 years, you have to renew the certification certification.
[01:06:53] In order to renew it, it's not you have to pass the exam again. You can just keep accumulating your PDUs. Like Now, we said professional After passing the exam, we call them continuous development unit. So, you
[01:07:09] keep accumulating CDUs by reading something, by by attending some trainings, by volunteering something. You keep accumulating those CDUs. Right? So, you can renew after 3 years.
[01:07:24] If you go for ECBA, after 3 years instead of renewing your ECBA, you can go for CCBA. So, that is how we need to manage this.
[01:07:39] lesson number two monitoring part one. So, from the slide or from the content point of view, some of these uh knowledge areas are divided into two
[01:07:53] big. For example, planning and monitoring, requirement analysis and design definition, they are very big. So, they are divided into two two one part some of them are in one part, some of them are are in two parts.
[01:08:07] there are six knowledge areas, right? monitoring focuses on the planning part. Here, we do not execute tasks. We do not perform task. We just plan.
[01:08:25] and uh 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
[01:08:39] planning, that means you are planning to fail. So, that is why planning some bit of planning is always required. Uh depending on whether you are using waterfall or agile, you
[01:08:51] plan differently. You may plan iteratively at different levels, but some planning is always required, right? Uh so, that is what we cover in this knowledge area, the planning bit. See, there is this scenario given. In
[01:09:06] See, there is this scenario given. In 2016, Vodafone UK ran into serious trouble while migrating its CRM system because of migrating the system without a structured validation approach. Not involving key stakeholders in
[01:09:19] planning and testing. Weak governance oversight and risk planning. This led to billing errors, customer complaints, and 4.6 million fine from Ofcom. This this Ofcom must be a regulator.
[01:09:33] in this project, how would you plan and manage your work to avoid such outcomes? view, what do you think is wrong here? Or was went in in incorrect or wrong
[01:09:45] direction? See, there was no validation approach. Not involving key stakeholders. Weak governance oversight and risk of them are specifically for business analyst.
[01:09:59] whether solution is working as per the requirements or not? Some of them, like engaging stakeholders, are There are overlap between
[01:10:11] project manager. If we If we right now we're talking about typical traditional waterfall project management, right? So, uh you talk to same stakeholder as a
[01:10:25] talk to the same stakeholder as a 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, project cost,
[01:10:39] project schedule, project risks. That they all are the accountabilities of project managers. We We'll cover many of those things in this course. BA will interact with the same stakeholders for the requirements, for
[01:10:53] solution validation, for writing acceptance criteria, to take their help in supporting and testing etc. etc. So BAs engagement is slightly different than the project manager's engagement even
[01:11:07] though there will be some overlap because the stakeholders are same. Okay. Uh now why this is required? Uh we always say that you know, if you identify
[01:11:21] problems earlier, it's easier to fix. It's cheaper to fix. But if you end up identifying gaps etc. later in the project, they get difficult and more expensive to to fix. So let's see uh if you
[01:11:36] reached, let's say uh you are at point A right now. You are at, let's say point A and you want to go to point B.
[01:11:48] 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 correct my course. I need to correct my
[01:12:01] path and I need to change and go to B." Now what what do you think? What What will be the difference? In one more case, let's say you moved further up away and here you realized that it is wrong direction and you have
[01:12:16] to 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
[01:12:30] and let's say 500 rupees in in in taxi, now it because you have to travel this much, it will take maybe 1 1 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,
[01:12:46] 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 direction? What exactly is required? What exactly
[01:13:01] 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 person who will tell the who will collect the requirements, who will tell
[01:13:14] the requirements, who will have the idea what to build as a solution. Right? So, good idea. So, that is the person who is supposed to navigate the team in the right direction and save. So, that is why
[01:13:27] 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
[01:13:41] I just mentioned here. So, business analysis is a structured approach used by business analysts to understand, analyze, solve business problems. Think of it like a road map or toolkit
[01:13:54] that helps a business analyst. Right? Understand the current state of business, identify the needs or problems, design the right solution, and ensure solution delivers value.
[01:14:07] I told you yesterday what is the current state? Your current state, right? Or your solution or application's current state. solution or application's current state. I I live here. The I live in Pune. That
[01:14:19] Right? Uh I live in a particular apartment. That I live in a particular apartment. That is my current state.
[01:14:31] back to Gurgaon where I lived for last Gurgaon where I lived for last 12 12 15 years, Gurgaon. is my current state. Right?
[01:14:47] current state. Right? This is my future state. different problem that before COVID uh it was manageable to live, let's say,
[01:15:02] in a two-bedroom apartment or one-bedroom bedroom apartment. maybe you were single, but living with your parents, did you notice that after COVID when we had to work from home, study from home, suddenly whatever
[01:15:16] whatever house you were living in, it is started, you know, feeling small because we had to work from home, we had to study from So, did you feel that? Did you feel the same?
[01:15:30] And suddenly there was a need to move to a bigger apartment so that we I I had to the days and then I used to take trainings also. So, suddenly it was
[01:15:43] like, how could I work or operate from this house, right? My wife had to work and we have we didn't have enough space. So, there this was the kind of identification of need or problem that I, because of the lack of space, I need
[01:15:59] 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?
[01:16:12] move to a bigger house, right? Now, when you talk about the solutions, it could be like you need three-bedroom house, your family members, etc., etc.
[01:16:27] 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 that you will identify, it is going to
[01:16:40] Right? Or you you your if you have kids, they might say I also need my separate room. Or your parents might say that you know, shift to ground or first floor. You don't go to 10th floor or 20th floor.
[01:16:55] They have their own concerns. They have their own requirements. Your spouse says that I want a better, you know, a kitchen or I want this or I want a separate study. So, you know, suddenly because there is
[01:17:07] a project, there is a there is a plan to move from our current state, the stakeholders which are who are impacted or they can have their own requirements. And on that basis, we create the solution.
[01:17:20] Right? And when you move, right? if the house is just in the same building on the same floor, do I need building on the same floor, do I need professional packers and movers?
[01:17:35] let's say across the hall, uh do I need professional packers and Maybe not, right? But if I'm moving to a different city, movers? In this case, I need. So, you see,
[01:17:52] 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 packers and movers. You will move. So,
[01:18:08] like we 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,
[01:18:21] that understand what is the meaning 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
[01:18:34] to move from current state to the future estate using some of the solution. I can move from my house to the next packers and movers, or I can do it myself. So, there can be multiple
[01:18:48] solution options as well. But, all these things I'll But, all these things I'll take uh I'll I'll explain in more detail in coming classes. Okay? What is the meaning of current estate? What is the
[01:19:00] meaning of future estate? What are the options? What are the What is the meaning of change? All those things we'll cover in greater depth in coming we'll cover in greater depth in coming classes.
[01:19:13] knowledge areas. We already discussed uh six of them yesterday. First one is business analysis planning and monitoring.
[01:19:27] defines the tasks associated with organizing and coordinating the effort of business analysts and stakeholders, right? So, this is all about planning, organizing, coordinating. Here, you do not perform the tasks.
[01:19:40] Here, you do not actually start the elicitation. Okay? Now, what happens when you So, the primary goal of BAPM to define the approach, to identify and involve right
[01:19:53] stakeholders, to establish governance mechanism for decision making and change control, to plan how requirements and related and improve business analysis performance.
[01:20:06] So, these are the primary goals. And these goals are divided in different approach, second will be about identification of the stakeholder. So, basically, these five primary goals will convert themselves into tasks of this
[01:20:20] knowledge area. Okay? We'll see them one by one. So, proper planning prevents poor performance is the key objective of this planning. Imagine being handed a project but not knowing what problems you are
[01:20:33] solving, who is affected, who decides what and how to structure your work. you uh move ahead in your project? What do you think?
[01:20:47] If you have no idea what exactly is the problem, what will you fix? Right? Who are Who all are affected? How will you their problems? If you don't know who you need to go to
[01:20:59] to take the approvals, who is the authority, you can't work without that. Who will fund the project? Who will approve the budget? All those are important questions. And how to structure your work, how to organize the
[01:21:11] information, uh depending on your depending on your organization, whether you are going to use Jira or you are going to use SharePoint, etc., etc. All those things you need to have some idea. Right?
[01:21:26] It's not like you cannot start working without having answers to all the question. As a business analyst, as a program manager, we have to move ahead if if all the information is not
[01:21:38] 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 the idea or to get the answers to all of these
[01:21:51] questions which are mentioned here. Now, as I explained you yesterday, Now, as I explained you yesterday, every task will have certain inputs. They'll tell what exactly is uh performed, key elements, and output. So,
[01:22:07] like for example, this knowledge area has these many tasks. Plan as business analysis approach, plan stakeholder engagement, governance, and so on so forth. So,
[01:22:19] these are the six five tasks in this knowledge area. Right? We'll go through them one by one. Outputs and inputs we'll will see for each and every task. This is a screenshot of picture from the
[01:22:33] book it's book itself BABOK. So you see majorly the inputs to all of these tasks are needs and performance objectives. Output are these five, right? So uh in
[01:22:46] the 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
[01:23:01] in detail and we will see input and output as specific to that task. Okay? So out of these five that let's see the first task. It is the first core task of BA PM knowledge area in the BABOK Guide.
[01:23:17] 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 progressive reporting. So before we go
[01:23:30] into details, 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 all
[01:23:45] same template which is used across all 30 tasks. So you have name of the task 30 tasks. So you have name of the task description you have guidelines and tools. Guidelines and tools are like optional.
[01:24:01] 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 right? But guidelines and tools we consider as
[01:24:17] uh I've always call them additional and optional inputs, right? So, you can say guidelines and tools are additional
[01:24:29] You use them if they are available. For example, business policies. It's not mandatory that you will always have business policies. It is also possible that you may not have some of these things. You
[01:24:41] will see different guidelines and tools throughout the course. Some of them may not be available, so that is fine. So, these are additional but optional. mandatory. Uh this is the name of the task output
[01:24:56] and uh there are two things. The input can there are two things. The input can So, what happens? Let's say there is input, right? This input is going into this task.
[01:25:14] Task one. This task one is producing output. Now, this output can go to a different T2. T2 can produce So, now for T2, this
[01:25:28] becomes input, right? T2 can produce Now, this output is possible that it is going not into a
[01:25:40] is possible that it is going not into a task but to external party. Basically, it's external, right? Not consumed. Or maybe used by stakeholder but not going into any any um any task. So, here
[01:25:54] 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 are not output of any other task. So, just be
[01:26:09] clear that some of the inputs can be the output of other task. Some inputs can be external. So, you will always see here in when you read BABOK that some of the inputs are external, some of the inputs are output of other task.
[01:26:24] And here also you see business analysis approach is the output. talking about, but first let's understand the structure. So, what is the output of this task? Plan business analysis approach.
[01:26:37] 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 are
[01:26:51] using this input. Next knowledge area, prepare for elicitation, conduct elicitation, they are also using this output. Even manage a stakeholder collaboration, analyze current state, define change
[01:27:04] strategy, assess risk, so many of the tasks in this overall BABOK are using this output. Right? So, that is what you need to understand that every output will be used by
[01:27:18] multiple tasks. Right? You will understand why when we'll when we'll go why that is important and important input to Okay? Apart from that, there are other
[01:27:33] headings like tools and guidelines we have covered, base main or main elements. So, there you will they'll explain what exactly this task all
[01:27:46] about, right? So, the core element or basic elements will explain what exactly this task is all about. And then there are stakeholders and techniques.
[01:28:01] So, these are these are the headings or, you know, points which are covered consistently for each and every task. I told you yesterday you don't have to think too much about
[01:28:13] who are the stakeholders. You can just You read it, but you don't try to memorize it. Okay? You have to focus on elements a lot. You You need to be very clear about techniques.
[01:28:26] Now, which techniques are used in this particular task? You don't have to memorize. You will start understanding and guessing yourself. What are the inputs to this task? Again, you don't have to memorize. You just
[01:28:39] the purpose of task. You will automatically start guessing. If this is the task, what kind of inputs I'll need, right? So, that you will you will start guessing. What will be the output? That is also very easy to
[01:28:52] guess. For example, plan business analysis approach. If you are planning something, the output will be that something, right? So, you know, approach is the output. So, you don't don't have to memorize.
[01:29:04] If you understand the concepts, if you understand elements and techniques, you will start answering the questions without mugging up, without memorizing. then it becomes even easier to guess the right option, right? Right answer.
[01:29:21] Clear? So, the first task, which talks about planning uh uh the business analysis approach. What is the approach in this context here?
[01:29:34] is whether it is adaptive approach or predictive approach. Now, what is the meaning of predictive? And what is the meaning of adaptive?
[01:29:48] So, the business analysis approach should align to the overall goals of the change. And also, I would add that it should be aligned with the project You cannot have business analysis approach which is not aligned with
[01:30:01] 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, with overall project. Now,
[01:30:16] you co- you coordinate the business analysis task with the activities and right? Change and project. That's what I'm I just explained. So, what is the adaptive approach and what is the predictive approach?
[01:30:29] If we put it in more into project perspective, see, uh predictive used to be we used to call predictive the traditional waterfall SDLC, right? Development life cycle.
[01:30:42] Agile 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.
[01:30:57] project planning, pre-project activities like you're creating business case, you are doing some pro- uh uh uh you know, uh presenting that but mainly then you will start with requirements. Then Then you will have
[01:31:13] requirements. Then Then you will have design. Then you will have development. Then you will have multiple phases of testing, then you can have deployment or testing, then you can have deployment or release. Then you can have maintenance.
[01:31:25] Right? These are the phases on a high level. sequence will remain almost the same. And they are called waterfall waterfall or sequential because they are in a particular sequence.
[01:31:39] This handovers are very well defined. Design completed. Right? When business analyst would say they they have they have completed the requirement, you can start with design.
[01:31:53] 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 predictive because planning is done almost everything is
[01:32:07] the project and the flexibility is not that much there. Right? So this is called predictive. And what is adaptive? Adaptive is agile,
[01:32:21] right? Where you pick the work in a small chunks. So the batch size will reduce and you then you keep picking items, top priority items from the backlog. You keep building them, delivering them. Again
[01:32:35] deliver. So that is why adaptive is called iterative and incremental, right? Iterative means you do the same thing again, then again, then again. So you're repeating the same
[01:32:48] thing. You pick items, so you perform requirement and requirement and you perform dev and you perform test. And then this cycle you keep repeating every 2 weeks, every 3 weeks you keep
[01:33:00] repeating. There is a pro list of requirements, you pick requirements from here. Two, three requirements from top of the backlog you keep picking, you keep delivering and you keep taking feedback.
[01:33:12] So here the major difference, the most important difference is important difference is that this is not sequential. So even the requirements are done iteratively, right? Instead of
[01:33:24] requirements, right? So in waterfall, in adaptive, you perform the requirement analysis for all 50. Once that is done, you do the design for all 50. Then you develop all 50, you
[01:33:40] test all 50, so everything is done on entire project scope. Whereas in what agile, you pick two requirements, three requirements depending on the capacity. You work on them, deliver them, then you pick next
[01:33:53] four. So the batch size is reduced. This is not a child course, otherwise I would have explained a lot more. drawbacks of waterfall and a child, etc., etc. But I'm sure in your master's
[01:34:07] on a child. But why we have to discuss it? It's still a bit of it because this is the first task itself, right? Which is the there and approach whether you are taking predictive or
[01:34:22] adaptive is going to have impact on your business analysis activities. business analysis activities. Now, you tell me if you talk about timing of business analysis activity, timing. Do you see any difference in
[01:34:35] waterfall or a child? 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 a child, it will be ongoing.
[01:34:54] requirements. So that is the that is one of the most analysis work. Whether you analyze all of them or you will do in chunks.
[01:35:08] What is What is the impact on the formality create? Waterfall or traditional is very, very formal. This is less formal.
[01:35:21] So in case of waterfall, we used to create very excellent extensive extensive BRD. It will go through a very It will go through a very you know, proper
[01:35:36] It will have a very, very strict change management. In case of a child, you you don't have to create huge or very heavy documents like BRD, FRD. You can simply create epics, features, user stories. You can still
[01:35:49] create documentation. It's not like but a child says you can do with less If I want to create, let's say in waterfall BRD, if I wanted to create a screen wire frame, I'll have to create a proper screen wire frame. I'll upload it
[01:36:03] into the document, insert it into my document. In case of Agile, if I'm using a whiteboard, I create something like to discuss with the client, this is the Here you have these fields, etc. I take this snap screenshot of this or I take a
[01:36:18] photo of this whiteboard, upload on the Jira, I think that is also accepted. Right? So, timing is very different. Formality is very different. Then create is also different, right?
[01:36:33] 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,
[01:36:45] your 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
[01:36:57] different. If you're 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
[01:37:09] projects are done in waterfall, so they will be you will deal with them slightly differently. In case of Agile, you will do your work slightly differently, right? Also, the impact is on the stakeholder
[01:37:22] engagement, right? So, timing of the document activity, formality of the documentation, and what about a stakeholder engagement? Is it same or different? So, in case of
[01:37:35] So, in case of waterfall, where exactly you will beginning of the project. So, it's possible that for 1 month when you are performing your requirement elicitation, you need a lot more time from them,
[01:37:48] beginning. But, in case of Agile, it's possible that you don't need entire time in the beginning, but you need 2 hours every week, 4 hours every week to perform your requirement
[01:38:00] planning and, you know, review, etc., etc. that, you know, in this project, this kind of engagement is required. In this Now, tell me, is it like your decision as a business
[01:38:14] analyst which approach should be used in the project? It's not your decision, right? It's collective decision. Maybe a sponsor can can make They can take your inputs, that's fine. But, it's not your
[01:38:28] 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 a stakeholder engagement is impacted. So, that is more for you to understand and work
[01:38:41] accordingly. Okay? So, that is the not be a repetition of work? So, it depends upon case to case and the
[01:38:56] See, what happens in the project, whether it's waterfall and Agile, that is different thing. What I'm saying, if depending on the project approach, what is the impact on your work?
[01:39:11] 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 Jiras. So, as a business analyst, you should be comfortable with both both. Creating
[01:39:25] Creating accept, you know, extensive documentation, or creating Engaging with the stakeholders in the beginning to cover all the requirements, or engaging with the stakeholders every now and then,
[01:39:38] 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 depends on the project whether it's typical waterfall, typical agile. I also
[01:39:52] uh initially I created the BRD because stakeholders were not very comfortable with agile. So I had to create BRD. for development they wanted to create user stories. So I ended up creating BRD
[01:40:07] and user stories. So that all those exceptional and edge cases scenarios will will all come across in projects, right? So yes.
[01:40:21] create uh a graph like this where I have uh a graph like this where I have uncertainty of requirements and here I have uncertainty of solution.
[01:40:40] are uncertain. Solution is uncertain. Which box I can use agile and in which box I can use waterfall? See, waterfall is suitable here. That is clear.
[01:40:55] Here agile, here agile, here agile. Uncertainty is high. This will always be very chaotic, right? A very problematic. Because here even you don't have clarity
[01:41:09] on requirements, you don't have clarity on solution. So this is the most problematic part. Here you need rapid agile. Agile and even more powerful, more rapid agile. Here waterfall can be done because you
[01:41:23] have clarity on the requirements and you have clarity on the solution. But here you need agile, scrum, whatever. Why? Because see, if help? If requirements are not clear, what will
[01:41:37] The batch remove reducing the batch size will help. You are talking about 100 or backlog. Requirements are not stable. They are not certain. So, what we will say to our clients that okay, give us just two
[01:41:52] And you can continue to change Right? While I work on these two, you continue you are free to adjust these requirements, change these requirements.
[01:42:04] So, we are giving a lot more time to the clients. We are giving a lot more clear flexibility to the client to keep changing whatever we are not working on right now. And give us clarity on just few requirements.
[01:42:18] clarity on just few requirements. Right? So, that is uh that is the benefit where you have you have uncertain requirements or unstable requirements. Same with the solution. In case of Agile, you create a you create
[01:42:33] an increment and show it to the client. You take the feedback. So, if client in what kind of solution he was looking for, quickly developing, showing it to the client, and then again taking the
[01:42:48] feedback, showing it to the client. Right? So, that is the benefit. In case where you don't have you have clarity on solution, you have clarity on the requirements, the requirements are fairly
[01:43:00] uh requirements are fairly stable, solution is very clear, you don't need that kind of feedback from client. So, in that case, waterfall can be done. Can we not use Agile here in four? Yes,
[01:43:15] you can use Agile here as well. But, will you get any additional But, will you get any additional benefits of using Agile in here? Maybe not. So, it's possible that you may not get any additional benefit of using
[01:43:28] Agile in in in this four quadrant number four, but it's not like Agile cannot be used, right? Agile comes with its own overheads. A lot of meetings are done. You need a lot more time from clients. Client has to spend, you know, every
[01:43:41] time. So, then it should be some additional benefit. There should be some additional benefits. But here, that kind of engagement is not even required. uh that is how now some of you asked, "Some organizations
[01:43:56] are in in kind of in kind of a rat race that I want Agile in all the projects. I want Agile in all the projects." So, that is fine. Even in these projects you that is fine. Even in these projects you use Agile, no harm. But ideally,
[01:44:08] decided on the basis of nature of the project. On the basis of these things, whether requirements are stable, whether requirements are not that stable, or the clarity on the solution, etc. etc., right?
[01:44:21] solution, etc. etc., right? So, that is the first task. Why it is important, I told you because it impacts the way you work. here, uh
[01:44:33] change-driven, hybrid a combination of both. But as a business analyst, you environments. You should be able to create both kind of documentation, and you should be comfortable with both engagements, more engagement and less
[01:44:49] engagement with with the client. tax filing. So, let me first do one thing. Let's
[01:45:01] first close that. Uh 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
[01:45:14] 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 business needs. What is the need? Why we
[01:45:29] are doing this project? And that is all we can have, right? So far, did we perform detail elicitation? No. Right? We have not performed detail elicitation. So, we don't know what are the exact requirements. But we have some
[01:45:41] idea of the business needs. When you are starting a project, when resources are allocated to the project, BAs and others are allocated to the project, that means some bit of discussion already done. Right?
[01:45:56] 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 manager might have already created a business case to take the approval of
[01:46:10] 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.
[01:46:24] On the basis of this, you decide whether waterfall or agile, right? As that's what I I told you, depending on the decide. Now, this is again, I'll keep repeating
[01:46:38] this fact multiple times. See, whatever we are learning here is whatever is pure theory. It's purest approach, right? things. You will see practical scenarios. You will see prac- different
[01:46:55] problems, right? Here, it's it looks like, you know, you are going to make don't know what kind of uh organizational approach is there, what kind of enforcement is there. So, you will always have to think
[01:47:09] whatever we are discussing in two different ways. First, what is the pure theoretical uh approach, and what then what is the what can be the scenarios in project. So, depending on the business need, you
[01:47:22] decide what is the approach. That is why business need is the only input to this available. Then, we have key elements, right? planning approach, will it be predictive or adaptive, as we discussed.
[01:47:37] the degree of a structure and documentation required depending on risk regulatory audit. So, that's what I explained, what kind of formal documentation you create. It is dependent mostly on the approach,
[01:47:53] right? In waterfall, you will have a lot more documentation. Business analysis activities, requirement elicitation, process all of these things are performed in both, but they might have slight
[01:48:06] variations, right? In case of waterfall, we perform them differently, all the all of them perform together in the beginning, and things like that. So, work. Clear? So, these four things I
[01:48:19] elements are most important part of a task. In key elements, they describe what exactly we are doing in this particular task. Okay?
[01:48:31] And also complexity and risk, consider 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?
[01:48:43] [clears throat] If you don't have clarity on the requirement, will that If you do not not have clarity on the solution, will that not add on the complexity? That That will add, right? And whatever is the approach, you need
[01:48:58] stakeholders. They should be informed, and they should be happy with the approach, right? Because they need They also need to be engaged.
[01:49:11] and tools. Okay? Business analysis performance assessment. So, what I told you that uh uh these things uh guidelines and tools should be considered as additional
[01:49:26] If they are available, you can use them. If they're not available, then also you can move forward. So, because these uh in nature. I mean, sometimes they are available, sometimes they are not
[01:49:39] available. For example, business analysis mean? This means nothing but lesson learned. We'll We'll have a diff- different task only for this, so you will understand
[01:49:52] better. But for now, consider it lesson learned. What does that mean? Lessons that you might have learned from the previous project. So, is it mandatory to always have lesson learned? It's not, right? Maybe it's first uh
[01:50:07] project of that kind. So, you may you might not even know uh if there are any uh you know uh lesson learned available or not. Similarly, if there are lesson learned available, you should learn that in this
[01:50:20] 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.
[01:50:33] says we need to use waterfall or we need to use agile, then we have to use it, right? Expert judgment. If there is expert who is available who worked on similar projects, they can also be
[01:50:48] provide inputs which approach to be taken in this project, right? S- Methodologies and framework available in your organization, as I told you. If there are some approaches, some methodologies, frameworks already used
[01:51:02] and available in your organization, and it's mandate that everyone should use care of that. And uh stakeholders can also tell you tell you about their concerns, their interest. If you use Agile somebody
[01:51:15] stakeholder says, "I'm not available every 2 weeks for your sprint review. I I cannot spend that much time every 2 weeks." Right? So, you need to take a well. So,
[01:51:28] 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. without them. So, there are some questions. Let's go
[01:51:41] So, there are some questions. Let's go through them. 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
[01:51:57] and compliance standards, adherence to HIPAA privacy laws, support for external securities audits, usability for a multilingual workforce The project involves coordination
[01:52:12] between different teams. 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 is
[01:52:25] hybrid would you choose for this project? So, this is the scenario and see the question itself wants us to say it's predictive, right? Because it they're trying to emphasize that it's
[01:52:41] regulatory and a lot of accurate documentation is required. I think most of you would agree that it's predictive given the given the situation given the scenario in the question, right? If you have a question like this, it's
[01:52:54] 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
[01:53:08] in this question it's not mentioned that, you know, you have to hit and try and identify the solution. You might have to do a lot of POCs or spikes. So, we need to answer accordingly. What the
[01:53:24] 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
[01:53:38] clear on the requirements or users are not very clear on the solutions, you some POCs etc., then obviously you'll have to go with Agile. Right? So, adaptive. Next question,
[01:53:52] you're working on a national level transportation system initiative. oversight, the documentation must be and traceability is a must. Which planning element will help you define
[01:54:06] required? It is A, right? That's what we And depending on the planning approach, rest of the things will be tailored accordingly. Next, you are leading a BA
[01:54:19] dashboard. Where stakeholders are co-located and feedback is continuous. The team follows Agile sprints. What level of formality and documentation is most appropriate? They have already
[01:54:34] co-located. Right? They are following Agile. And it's a very low-risk internal HR Right? So, there is no regulatory oversight, there is no audit requirement
[01:54:49] 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, extensive documentation is required, then it would be different,
[01:55:03] but because it's internal and also if stakeholders are co-located, co-located, in that case, they might Uh they might need different kind of uh you
[01:55:15] know, arrangement where they get the status of the project. But in this case, they are co-located, so you minimum documentation would be enough. So, that was the first task. Now, second one is plan a stakeholder engagement.
[01:55:29] Now, tell me who are our stakeholders? Everyone who is impacted by the project and everyone who can impact the project, they all are all are our stakeholders, So, why do you need to engage with them? First of all, you need to elicit the
[01:55:45] 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
[01:55:57] give you the needs? Who will share with you 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.
[01:56:11] Let's 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
[01:56:24] business analyst. So, you just mentioned that in order to know these stakeholders. You need to engage with them, but you can engage when you know who are your stakeholders.
[01:56:37] So, considering this scenario, how will you start your activity? How will you identify your stakeholders? See, there cannot be one single answer to this, right? There can be multiple things that you may perform parallelly to try to
[01:56:51] understand, to try to identify your stakeholders, but what are those things? If you are thinking that there can be few things which I can try, I believe it should be responsibility of PM to provide the list of stakeholders.
[01:57:04] Through organizational modeling, uh stakeholder engagement is required to gather accurate requirements. It should be responsibility of PM, but it's not for stakeholder engagement, right? Business analyst and PM, they both
[01:57:19] 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 few uh few things like risk, resourcing, budget costing, and budget.
[01:57:34] But it's possible that for requirements, you may need to uh engage with more stakeholders, right? Who are actual users of the system. So,
[01:57:46] PM can help. PM can help you to kickstart, but we can't say that he is responsible to give us the list of com- complete list of all these stakeholders. That is That is not the right thing.
[01:57:59] So, what else you can do? So, that is fine that first PM called you. So, it's possible that PM would have already created, let's say a business case when he got to know about the project
[01:58:12] 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 re- rest of the project team members like developers, testers, and
[01:58:25] sometimes BAs, they get on boarded 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 uh by the
[01:58:37] sponsor. So, first question is always to ask PM himself that, "Okay, you are Who are the stakeholders that you are already aware of?" Right? So, first names. And then that can be a good start.
[01:58:52] 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 organizations, almost all the companies will have organizational hierarchy. And
[01:59:05] will have organizational hierarchy. And that can be looked at in 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
[01:59:19] 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 see in the previous example,
[01:59:32] HR. So, it can give you some idea that, you 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
[01:59:46] head of HR if I want to, you know, understand what is the impact on them or what are the requirements. So, that is the second point, which is good. These are two important inputs. First from the PM, second from,
[01:59:59] else we can do? If there is any other existing 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
[02:00:14] all of those documents generally have two sets of people. There are two lists which are mostly there in the beginning of the document. First, So, if there is any existing document, you can read related to your project,
[02:00:28] you can get the idea who are the approvers. And approvers are key stakeholders, right? Similarly, there is a distribution list that even though these people will not approve the document, they will get a
[02:00:40] copy of this document. So, they are also your stakeholders. So, if there is any existing documentation available, which may not be the case or in all the projects, but if it is available, you can always take help. Similarly, if
[02:00:55] there are multiple vendors, different parties are involved in the project, you will also find a lot of uh Agreements which are done with between a company and a vendor. So, there also you
[02:01:11] can get some idea of the stakeholders. What else? I said existing documentation of in if the Sometimes it's like project similar project was done or this is the space two of the project, phase one was already done. In that case, you will get
[02:01:26] a 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
[02:01:40] uh process documentation like workflows or any other you UML modeling, etc. Where you can get the idea that, you know, in this process, these are the people who are involved. Right?
[02:01:54] this process. These are the departments which are involved in this process. So, that can also give you a good idea. All of these things can be used when they are available, right? And that's why I said there is no hard and fast fixed uh
[02:02:09] that you do them and you will get list of uh 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
[02:02:22] current project that is what is going on. I'm in the initial phase. So, let's with the known stakeholder. I'll always mention that please feel free to forward this invite to anyone who can be helpful
[02:02:36] in this discussion, right? So, I provide the introduction of of project. This is what the purpose of this particular meeting. And if you think that somebody else can be useful, then please forward them.
[02:02:50] After the meeting within the within that meeting also, you keep asking this thing, right? Who else can help? Who else can help? Who else should I reach out to? So, that is also uh important, right?
[02:03:03] identifying you will keep identifying more and more stakeholders. Uh when you keep asking people. So, that is also important. What else help you with I stakeholder identification? If you miss this
[02:03:17] stakeholder, what is the problem? We generally say unidentified stakeholders means unidentified requirements. Later on, there can be requirements which are which you are able to identify late in the project
[02:03:30] because those stakeholders were not identified. So, it's very very possible identify all these stakeholders. And why it is important, we already know that. See, first of all, when you when when I say a
[02:03:45] project, a project is not just building application, right? Project There is a term called system thinking. Like think about a system. System consists of people, processes, applications,
[02:03:59] So, if 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 people are also impacted. Sometimes you
[02:04:13] automate existing manual task, people get impacted, right? So, it's always not just uh systems, but people, processes, everything. So, it's That is why it's important to identify that all these stakeholders.
[02:04:28] 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?
[02:04:41] So first part of this is there are two inputs. Needs. Where exactly needs are coming from? The same needs which we identified and used in the first task. And now you see the additional input is
[02:04:57] business analysis approach. Where exactly you're getting this input from? Business analysis analysis approach. This input where exactly we are getting from? From the first task. Now you tell me why this is important.
[02:05:10] Why the approach Because what exactly we're talking about? We are planning our stakeholder engagement. How you will engage with the
[02:05:23] stakeholders? How you will communicate with them? Etcetera, etcetera. 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
[02:05:37] engagement? When you were 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 stories, right? So the same was
[02:05:52] the case. My grandmother used to tell me bedtime stories. But she would also say one thing that you know, keep saying "Mhm, yes, something, no." So that I knew that you were still awake
[02:06:06] and listening to the story. Otherwise, I would never know you know, you you are you are already sleeping or and I'm talking to a wall. So that is the case here as well, right? That is the input. Now again, similar to the
[02:06:21] first output of the first task, this output will also be used in multiple them. For example, prepare for elicitation, task number four. Do you think a stakeholder engagement
[02:06:36] approach is required when you prepare for elicitation? Yes, because when you prepare for elicitation, you will set out uh send out meetings uh many uh sorry uh meeting invites. You will prepare for workshops,
[02:06:49] for brainstorming sessions. So, whenever you do that, you would need your uh stakeholders. And when you are planning these sessions, you will think about what is the uh stakeholder engagement approach. Right? Similarly, if you see
[02:07:03] communicate 4.4, communicate business analysis information, who exactly you will communicate this information to? To a stakeholder. So, again, a stakeholder engagement approach is a very valid input to this particular
[02:07:15] task. So, you can see all nine, and you will be able to realize why this input Right? So, these are the two input and output.
[02:07:27] Now, there are three guidelines and tools, business analysis performance assessment, change strategy, and current state description. Why do you think business analysis performance assessment is important?
[02:07:40] Because this is the lesson learned. So, from your previous learnings, from your previous project, whatever you learned can give you the inputs here. Right? strategy? Change strategy tells you what is your
[02:07:54] In order to move from your current state to future state, you are going through a This is called change. Now, depending on this change, depending on the strategy of this change, you can identify stakeholders. Right?
[02:08:14] you need packers and movers. stakeholder. If you're moving within the same building, they are not your stakeholder. So, change strategy will also tell
[02:08:27] if I'm migrating one application to a new application, depending on the depending on that migration, right? It will tell you who can be your stakeholder. If I'm migrating, let's say
[02:08:40] stakeholder. If I'm migrating, let's say to one of my legacy application to AWS, who is taking care of AWS infrastructure, they will become my stakeholder. Otherwise, they are not my stakeholder. Right? So, change of
[02:08:53] strategy. Now, why it is optional? Because maybe and you don't have idea of the change of strategy. So, that is why it is given as if available, use it. Right? And same is current state
[02:09:07] description? Existing, let's say existing flow diagrams. What What do they tell you? How as of now, at present, how different processes are working, right? That is
[02:09:22] 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 available on current state, it will tell you
[02:09:38] who are the teams or people involved in these diagram, uh let's say this is the start, it is moving to this, then here you are performing a task, here you are
[02:09:52] 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
[02:10:05] function. So, this particular step is performed by the HR. This is performed say, this. Uh let's say this is finance. Okay?
[02:10:18] So, when you look at the current state description, that can also give you a who are your stakeholders. So, that is why that is also given as additional input, right? So, make sense all these three guidelines
[02:10:33] and tools as additional inputs, they are making sense. If available, they can help you in your stakeholder engagement stakeholder identification. Right? Now, why it is required? Obviously, foster collaboration, reduce
[02:10:46] resistance, align stakeholder goals with initiative outcomes, and ensure timely communication. So, if you we know that project cannot be delivered in isolation, right? You have so many people who are impacted, you
[02:10:59] have so many people who can impact your project. You need developers, you need testers, you need operations team, and you need ultimate your end clients, right? Otherwise, how how can you deliver the project? So,
[02:11:14] right? Now, if you don't talk to them, it may become difficult. First uh difficulty is unidentified requirements. if you do not communicate to them, they will never know um
[02:11:30] what is the impact on them. What is the meaning of two I and four I check? Maker and checker. So, generally you say you see you call So, generally you say you see you call it four eyes check, that one person will
[02:11:44] whether creating a case, raising a ticket, uh whatever. Some task that one person will do. Second person will check it. So, it's not like the the same
[02:11:56] person can create a case, approve it, and everything. No, right? From the process point of view, many regular regular from the regulatory point of view, from the legal point of view, in many of the cases, it's mandatorily
[02:12:11] required that maker and checker are two different person. Sometimes, in my projects I have seen six eyes. Six where somebody was the maker, this person was just validating or checking
[02:12:24] person. So we had thing. Now what happened when I we wanted to make some change in the
[02:12:38] process, right? So let's say there was onboarding team. So what is the what does that mean that if you want to open a new account in any
[02:12:52] of the bank, onboarding team will collect your documents, validate them, perform your background check, your KYC, etc. and then they'll open your account, So earlier if this is the person who
[02:13:06] perform everything. I'm talking about 2012-13. But then there was one regulation that came, you might have heard, all of you might have heard of FATCA these days, it's mandatory. Even all Indian banks,
[02:13:20] disclose whether you are US citizen or not. whether you are US citizen or not. So mandatory that the same person cannot approve the onboarding case.
[02:13:35] We So regulatory requirement was up to four eyes check. four eyes? Let's implement six eyes check, right? So we went ahead and implemented this. When we started discussing after this
[02:13:49] when we went ahead and discussed with operations that they started showing a lot of resistance much engaged. What they thought that, you know, let's
[02:14:02] say there is a person, Shivam used to started telling me that, you know, girl, till yesterday I was my own boss. I was creating the case, I was also approving the case, right? How come
[02:14:16] 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 who will and there will be another person who will approve the case. So, people
[02:14:31] have the full background and full understanding. So, initially they misunderstood it and they started some resistance. Then we had to conduct couple of users training, and we
[02:14:46] you know, all your cases will be approved by somebody. It is like if you are your case is getting approved by second person, then second person's case will be approved by
[02:14:58] you. Right? Only your manager, the entire approve, but maker and checker, you can be a maker and you can you can be a checker. When we explained the regulatory requirements and the purpose
[02:15:12] of this overall implementation, then they understood. And you will see that you will find it and you will face it multiple times. Whenever your stakeholders are not fully engaged, they are not fully aware of the
[02:15:26] change, what are the benefits, what are the implications on them because of this change, you will always face resistance when you when you And why it is important for you as a business analyst? Because you are the
[02:15:40] 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 the
[02:15:53] stakeholders along sometimes your project manager, right? So, that's why it's important to engage. Now, when we decided the approach, whether it's adaptive or predictive, it's our job to go and discuss with the
[02:16:07] following waterfall or agile and what side. Okay? So, that they are also aligned with with you as with your
[02:16:20] project approach and the overall purpose of the project. Okay? Um What else you need from the stakeholders? You need their time commitment and
[02:16:36] Uh key elements perform a stakeholder analysis, define a stakeholder collaboration. I'll just explain this and the stakeholder communication needs. So, first is perform a stakeholder
[02:16:48] analysis. The first step The first step uh in this is identify, right? First, you need to identify the stakeholder who will be directly or indirectly impacted
[02:17:00] analyzing the information once collected. Performed repeatedly as business analysis activities continue. Right? As I said, you will continue to ask who else can be impacted? Who else uh can, you know, give you more
[02:17:15] information so that it has to be performed periodically or 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 is also
[02:17:28] 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. there are different ways which you have to try,
[02:17:42] right? And you have to keep trying uh so that you can identify more and more stakeholders. So, that is the first part uh stakeholder. No. So, one more thing is you can
[02:17:57] document it in different ways. First is simply creating a stakeholder list, right? You call it a stakeholder list or a stakeholder register. a stakeholder register. Second, uh another way is to create
[02:18:11] let's say uh a matrix.
[02:18:24] Let's say authority of the stakeholder and interest of the stakeholder. stakeholder in these four categories, a person who has very high interest
[02:18:37] in your project and he has a he is a very senior person with uh you know, a strong authority in your organization, you know that these people you have to manage very very carefully.
[02:18:50] You will have to take care of their no communication needs, what kind of communication they expect from you, all that you have to you know, you have to be very careful. These people, they are okay. I mean, you
[02:19:02] have to 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 such, you know, what do you say? Matrix and you can have authority or you
[02:19:17] can have engagement, you can have interest or something else. So, you can create this on the basis of any two parameters that you want to authority and interest in the project, uh
[02:19:32] and interest in the project, uh engagement break and interest. Also, uh add just one thing that we need to be careful.
[02:19:46] That you should not end up adding this particular, document or on your share SharePoint where everyone can see. Right? Because what will happen? This is not like
[02:19:59] if a stakeholder ends up finding himself here, you know, have any authority in the project." Right? So, this is slightly political. Right? So, this is slightly political. So, generally I do not create any such
[02:20:13] metrics in my uh formal project documents. If I want to create, I'll create it in my personal drive or in my personal spreadsheet and keep it in my personal uh lap uh computer, not as a shared project document. A stakeholder
[02:20:26] list. One more document that you one more diagram that you can create is more diagram that you can create is called onion diagram.
[02:20:38] have onion. this is your internal project team.
[02:20:53] you can say this is the impacted department of the organization. Impacted department. Then this is your organization. And every anything that is outside is
[02:21:07] And every anything that is outside is external. So, this diagram can be created just to mainly to identify who are your stakeholders, internal, external, etc. Right? And this is also dependent on
[02:21:22] If I ask you who are your internal stakeholder and who are your external the first question that you should ask where exactly is the boundary. Right? By internal if you mean people who are part of the project, then my boundary is
[02:21:37] here, right? But if you mean by by that if you mean organization, then the boundary is here. clients. But in some of the projects you are
[02:21:50] for internal clients like I am part of something for HR department. So who are my client? HR. So in that case if you say that people who are outside my organization are external, in this case
[02:22:04] then there is no external stakeholder, right? HR is part of the So internal external depends where exactly is the boundary, but I hope you understood the purpose of onion diagram. You can have two layers, three layers or
[02:22:17] four layers depending on the need and you can create a such diagram. So this is for the stakeholder identification and documentation of those stakeholders as a list, as a matrix, as a and in diagram.
[02:22:32] Or sometimes we also create one more thing that is called persona. So basically persona is a fictitious character.
[02:22:44] Right? Uh just think of a project uh like you are building any application customer. Then who will give you the requirement? Directly you can talk to
[02:22:57] building this software for for your HR team. You can talk 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
[02:23:11] many millions of users etc. And you 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
[02:23:26] you in in if I simplify it, it's like you user and try to imagine, try to find out what kind of requirements that user would have with
[02:23:39] your system, right? What kind of usage that person would have with the system. So it's imaginary imaginary or fictitious character. you will still assign assign him or her a name. And you will try to understand uh
[02:23:54] you will put the demographic data to that person. Let's say age, gender, uh education, non-working, maybe the whether he's living in a city or in a town, etc. etc.
[02:24:10] And then you will try to understand what kind of use case that person would have Right? So, in such cases, requirement from the user, you can still try to identify the requirements.
[02:24:24] So, for example, let's say you are there's a requirement that Simply Learn wants to build a new learning management platform. Okay?
[02:24:36] uh platform, who are the stakeholders? Who are basically who are the stakeholder if Simply Learn is planning to build a new learning management system? Who all can be the stakeholders? Students, trainers,
[02:24:52] train technical team, trainers, learners, yes. Simply Learn management, faculty, admin team, all of them are the stakeholders. Now, think about a situation where
[02:25:05] as a trainer, I it's possible that I can have uh some requirements uh just for just have as learners, you can have your own requirements.
[02:25:20] And uh for example, I I can have a uh for example, I I can have a requirement that says I want a feature I want to upload additional documents on LMS, so that I can share them with the
[02:25:33] learners, right? Very simple. Instead of, you know, sharing the Google Drive, etc., if I could possibly upload all the additional documentation on the LMS, so that learners can download. Do you think it's a valid requirement for
[02:25:45] Yes. It is. uh as a learner, you can have different requirements that I should be able to see my attendance on the platform. I
[02:25:57] should be able to download the recorded sessions from the platform. I should be that trainer has shared from the platform, right? All those requirements platform, right? All those requirements you can have. Now, imagine that there is
[02:26:10] a uh there is a girl uh from Simplilearn. But, she knows that the network in her she's from a small town
[02:26:24] maybe a village and the network is always patchy in that village. always patchy in that village. So, attending live classes may be very I interruptions when she's attending live classes.
[02:26:37] Now, if you think about her as a persona, what kind would like to add in Simplilearn's LMS? As soon as you identified a persona of a person who is
[02:26:51] living in a remote village with patchy internet connection, immediately you identified a requirement which is about recorded sessions. Right? It can be useful for people who are living in city and you know, missing
[02:27:04] the session, but at the same time, that gives you a good idea, right? What kind Right? So, that is the use of From requirement classification schema from the BABOK point of view, they are
[02:27:19] divided as business requirements,
[02:27:32] Okay? Then we have solution requirements, functional and non-functional
[02:27:44] and then you have transition requirement. Business requirements and now and you can also see here why simply learn would launch a project like this. Maybe like uh Allah mentioned that they want to
[02:27:56] uh Allah mentioned that they want to increase the enrollment by 30% so that they can get the uh you know more revenue. That is the business very valid business requirement where company wants to increase the
[02:28:10] revenue and in order to increase the revenue they will have to 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
[02:28:23] system and a system which is more user-friendly etc. etc. So that is fine. Now when you talk about a stakeholders like I told you as a trainer, I want to upload additional documents. That that's a very valid stakeholder requirement. As
[02:28:36] a trainer, I am also a stakeholder. As a student, as a learner, you can also have your own requirements, right? So the only point is that uh your
[02:28:48] stakeholder requirements should be aligned to the business requirement. Right? We are talking about adding more revenue in gaining or getting more revenue. So if purpose is to have uh you know
[02:29:04] better customer better user experience so that more enrollment etc. etc. Your aligned. Same as with the functional requirement, non-functional requirement. Basically all your low-level requirements should
[02:29:17] objective, high-level organizational requirements or high-level business So that is stakeholder requirement. Now what can be functional and So uh
[02:29:29] like uh Allah mentioned the platform must allow users to pay using UPI, functional requirements. The system should support 10,000 That is non-functional. So, what is the
[02:29:42] non-functional? Functional requirements are the features, functionalities of the system, right? And non-functional requirements are about performance, security,
[02:29:57] uh compatibility. So, uh sometimes people get confused, question. Right? Uh let's say I I I give you a requirement that this particular website
[02:30:12] 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
[02:30:25] Am I talking about any functionalities and features of of that website? right? So, then this is non-functional requirement because this requirement.
[02:30:39] Similarly, if I tell you that if I open your application, the application that you're building, if I open it in India, it should open by default it should open in Hindi. If I open it in the in the United United
[02:30:52] States, it should translate to English, and if it is in let's say uh Italy, it should be in Italian and things like that. Again, am am I talking website? How the user should log in? What are the security What are the
[02:31:08] uh you know, what is required to log in into the system? Nothing. compatibility with different browsers. So, that is a non-functional requirement. If I tell you that
[02:31:20] concurrent users as he mentioned, right? Uh right now let's say this Zoom platform would allow 100 users, but I want more revenue. I want more people to join my classes, so I want 200 people to join at a time.
[02:31:34] Again, this is a non-functional requirement. Okay? So, I hope you're clear about the dis- distinction between functional and non-functional. requirements are more important than non-functional. It's not the case. It's
[02:31:48] theoretical uh you know, uh segregation or classification. It doesn't mean that one type of requirements are more important example,
[02:32:02] if you talk about a printer, right? A printer should be able to print uh white sorry, colored and black and white uh pages. That is fine. Uh functional requirement. Uh I A printer should be able to print 20 pages per
[02:32:16] is non-functional requirement, but in case of printer, requirement, right? The speed of the printer, or performance of the printer. That is one of the most important requirement. So, never think that, you
[02:32:30] 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 a transition requirement? So, we always say that
[02:32:44] transition requirements are temporary requirements. Once the system is live, requirements. Once the system is live, once you reach to the uh target state or your future state, the these requirements cease to exist. They don't
[02:32:58] exist after the after the uh transition, after the change. Basically, they are temporary requirements. Like, for example, we were talking about shifting our house, and we were talking about packers and movers.
[02:33:11] 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 need them. So, that requirement is one-time
[02:33:24] 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
[02:33:37] data of existing 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
[02:33:51] training is required once, right? And that is why training is also a So, the this is how you need to identify requirements required only for the transition period, only for that change
[02:34:05] period, not all the time. Functional and non-functional requirement will remain there as long as you will use that system. Those requirements will remain with the system, right?
[02:34:17] you will have to define the collaboration, right? Stakeholder ongoing engagement in business analysis activities. Approach may vary by stakeholder type and activity. Key consideration include timing. See, now
[02:34:32] your approach is important. What how much time you need the stakeholders from stakeholders? In case of Agile, you need 4 to 6 hours every 2 weeks for sprint review, maybe for requirement grooming
[02:34:48] sessions. And in case of waterfall, that is different. So, it's not like you can decide in isolation, right? stakeholder whether they have that kind of time or not.
[02:35:02] Second is stakeholders communication needs. All the stakeholders can have different type of communication needs. For example, your project sponsor, he or she cannot attend all these status
[02:35:16] meetings every week. So, you might have to set up separate 30 minutes just with Where you can walk her through the project status, project progress, and in case there are any problems. Right? With tech teams, you might need a
[02:35:32] different meeting. So, point here is you need to identify what type of meetings, what type of what type of communication your stakeholders need, whether written or verbal. So, generally in all the projects, I would
[02:35:45] 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 stakeholders. On the other side, I will have what kind of communication they
[02:35:58] want. So, for example, I'll send a weekly status email. Right? I'll decide who all will receive this. I'll run one weekly workshop with all the technical teams who are impacted.
[02:36:13] And in this case, I'll I'll request only technology teams, application teams to join this. There can be one weekly meeting with with with business stakeholders, where we'll have just business. Right? And
[02:36:28] fortnightly meeting with everyone and things like that. So, this is my communication plan. Who will tell me how my how what kind of communication they need? I can obviously
[02:36:41] check with stakeholders what kind of communication they are expecting from In case of Agile, some of these things are automatically decided if you're using a Scrum. Right? You already have those meetings which you need to run,
[02:36:54] meetings. Clear? So, if I ask you to create a can you create it? Or do you think it's very difficult? It's very simple, right?
[02:37:06] List of stakeholders, different ways of communication, and the frequency. I say status email. A status email, all these stakeholders let's say weekly. Uh
[02:37:18] the full stakeholder connect let's say frequencies fortnightly all these stakeholders. Uh you can have a steer steering committee planning meeting and things like that, right? So, all that is just
[02:37:33] two-dimensional uh data that we need to put on a spreadsheet and create plan. Right? Very simple. And different stakeholders customers we discussed yesterday who are your customers, who are your end users.
[02:37:48] Who are the suppliers? Uh provide products or services that may influence or support the stakeholder engagement plan. So, supplier can be of providing you material, they are providing you software, or maybe they
[02:38:02] are providing you human resources as well as well. Many time there are uh typical IT tech companies who are in body shopping also, right? So, I need Java developers I can reach out to them and they can help me
[02:38:15] with 20 developers, right? So, different kind of suppliers vendors are there. Regulators Who is the banking regulator in India? Who is the banking regulator in India? RBI, right? Who is the regulator for uh
[02:38:30] capital market in India? SEBI. AMFI is for mutual funds. For insurance, it's right? They will have a lot of requirements a lot of constraints on and that is why they become one of the key regulators especially on the on such
[02:38:47] projects where you have some regulatory requirements. A sponsor, the person who is who has authority on the funding. A person who is providing the funding to the project. That is the sponsor. Project manager we
[02:39:02] know domain subject matter expert technical subject matter matter expert architects they all are different technical people who and domain subject matter expert is a person who has that domain knowledge.
[02:39:15] Do you think uh BA needs to have domain expertise? Theoretically, BA can be domain agnostic. Right? Theoretically. Why? Do you think BA is going to create requirements or BA is going to elicit
[02:39:31] requirements? BA is not going to create requirements himself, right? So, if BA is very good, he can ask right questions, he can use all the techniques, he can create questionnaire, he can run workshops, he
[02:39:45] questionnaire, he can run workshops, he can do brainstorming sessions, then he needs he can elicit the requirements from the users, right? So, in a ideal world, he he can do without having any domain expertise.
[02:39:59] correct also. But, when we talk about you know, practical things, most of the companies, most of the managers would expect that BA comes with some domain expertise so that, you know,
[02:40:13] 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 other uh job platforms, they would expect a person with domain
[02:40:27] background, right? But, in in a ideal world, BA can do without domain expertise. Let's start with the third third task of Now, this is about plan business
[02:40:41] 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 by that? Project
[02:40:56] business analysis uh governance? What do you think is the meaning? Controls? Keeping track of all the activity? Monitoring and sharing the feedback? So, the most important thing from the
[02:41:12] project point of view is how do we take the approvals? Who exactly who all will provide the approvals? Who have that authority to Right? And in case of escalations, who need to be
[02:41:26] reached out to? That is also part of governance. So, approval, escalations, uh the the distribution of the documents, and authority from project decision-making
[02:41:40] point of view, design decision-making point of view, as well as budget point and your escalation metrics of the project. So, these are the things which are part of the business analysis governance. Now, why do you need to
[02:41:54] identify this? Because in your project, governance is required. In every project, governance is required. So, again the same question. It's It's your business analysis governance should be subset of project
[02:42:07] governance, right? It cannot be like in project, you have some some stakeholders project, you have some some stakeholders which are identified, and you're in which are identified, and you're in in BA in business analysis governance,
[02:42:20] you are asking for somebody else. Right? That is that will not happen. So, Right? That is that will not happen. So, whenever we talk about any plan, any any governance approach, or any other plan, for example, communication
[02:42:32] plan, etc. Uh your business analysis plan will be subset of overall project plan in all the cases without any exception. So, that is first thing that what all is considered under governance,
[02:42:47] what all will fall under governance. Why we need to identify? Because project will not be able to will not be able to execute the project without governance. Because there are so many steps, there are so many stages in the project where
[02:43:01] you need to have a clarity on governance. For example, requirements documented. Now you need to take the sign-off on the document. Somebody should approve the documents, right? You need to know who is that person.
[02:43:15] Uh who is going to provide the approvals, let's say on the design? In this case, it may not be business stakeholder, but an architect if in your organization there is a architecture review board. In
[02:43:30] will have ARB. Where every project will present their design, their architecture, uh and ARB board will have senior your design uh in the project, right? Similarly, the
[02:43:45] uh in the project, right? Similarly, the text 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
[02:43:57] different 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? Uh like when you are out of office, you leave that message, right?
[02:44:09] Uh out of office message, which tells you which tells everyone who's sending your email that say I'm on planned leave on from this date to this date. In my people and for any escalation, reach out to my boss and you provide their email
[02:44:23] IDs or phone numbers. That is part of the governance. It's your responsibility, everyone's responsibility that if you are away, set a proper out of office message so that people can reach out to the respective
[02:44:35] uh respective people who you mentioned in your out of office reply. These are the important uh points and also budget approvals. Who has authority to approve the budget? Who has the authority to deal with escalations, right? Most of
[02:44:50] most of these time uh sponsor of the project would have ultimate authority. And sometimes, depending on the requirements, maybe have authority. And it depends on the project
[02:45:05] approach. If it is, let's say, Agile, in that case, product owner would have authority on the product backlog. So, every requirement, everything that is authority, obviously. Obviously, he will take inputs from
[02:45:20] different stakeholders, but product owner owns the backlog. What goes into backlog, the prioritization of the backlog, re-prioritization of the backlog, all of those things are the authority or the
[02:45:34] responsibility of the product owner. Right? So, business analysts play key role in establishing and maintaining a governance process, ensuring uncertain
[02:45:46] ensuring that any uncertainty uncertainties within it are addressed. Now, do you think we need to inform a stakeholder about the governance? Whatever approach that you are taking,
[02:46:00] whatever governance you are setting up, do you think a stakeholder needs to be informed about it? Yes, right? You make the decisions, you need to inform. There is one more important
[02:46:13] aspect of governance that is called change control. How the changes will be controlled in the project. How the changes change requests will be managed in the project. Earlier, I think nowadays, it's not that
[02:46:25] starting my career and until I think 10 years back, especially in the in the traditional waterfall project, there used to be this
[02:46:38] change control board, CCB. baselining? Baselining is current status. So, you can baseline your budget.
[02:46:53] You can baseline a scope and timelines, also. And requirements, everything. So, basically it is like
[02:47:05] 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,
[02:47:19] or 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 snapshot taken and considered as this is the final one. And afterwards,
[02:47:32] request. So, earlier, if there is a requirement change, right? Uh I will tell all my stakeholders that there is a particular template. In this template, you have to fill
[02:47:46] certain details, like what is the change, why this change is requested, what are the benefits of this change, who is the requester, is there any impact on other aspects of the project? So, you will have to fill all these
[02:48:00] 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 is a CCB email ID created. You have to
[02:48:15] send this completed form to this email ID only, right? If this form is not submitted properly, we'll not consider your change request. If this is not sent to uh a particular email ID, this will not
[02:48:28] be considered. So, the process was very strict. Now, there will be people in this CCB, maybe project manager, business analyst, somebody from the are important, they'll be part of the CCB.
[02:48:41] Here, they need to attend the meeting. CCB will run monthly or bi-monthly meeting where people will join and they'll explain this why their changes should be considered etc. etc. And depending on many aspects like what
[02:48:58] 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 possible outcomes
[02:49:12] after discussion in CCB? Either you accept the change request or you can reject the change request or you can just differ that okay we we will do it but later.
[02:49:26] So these could be the possible outcomes out of CCB meeting where all the changes are discussed, right? So now you are you are starting the project, don't you
[02:49:39] think that this should be established? How change requests will be entertained, how they will be analyzed, how the decision will be made on those change requests. Do you think this should be part of project governance?
[02:49:52] This is part of project governance and it should be informed to the so that they are aware that I need to raise a change request, this is the process that I need to follow. Similarly um
[02:50:04] uh as I explained yesterday when I whenever you create BRD or FRD or in fact JIRA's you need to create two tables mostly in the beginning of the documents. One is
[02:50:17] called list of approvers or approver list. who are supposed to approve or sign off this document.
[02:50:32] Second list is called distribution list. people who will receive a copy of this document. So, even creating this is part of governance, right? Who all should receive the copy? Even that is not that
[02:50:47] mandatory, but this part approval part is very much part of the governance. So, you see, we do so many things practically which are part of overall project or business analysis governance. For
[02:50:59] business analysis governance. For example, this CCB setup, how the change provide the who will provide the approvers approvals. That is on the requirement. Same thing will happen on the design,
[02:51:11] testing, etc. etc. So, all those things together make project business analysis governance process. So, let's see what is there in these slides. Now, you see what is there in the input business
[02:51:24] analysis approach. Now, I I am sure you are able to tell why this is as the this is there as the input. Because the CCB which I explained is part of waterfall. That is strict change control board and the entire process
[02:51:39] is not applicable in Agile. So, if your project is Agile, different, right? The take on BRD FRD that is completely different.
[02:51:53] So, on the basis of business 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.
[02:52:06] And why stakeholder engagement? So, these are the output of previous two tasks. I'm sure you will be able to see that team 3.1 and 3.2. So, previous two tasks produced these outputs and they are considered
[02:52:19] here. Because here we are talking about governance which has impact on the 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,
[02:52:33] right? Output will be governance approach. Also, you need to understand that when I say business analysis approach or stakeholder engagement approach, do not always expect there that there will be a
[02:52:48] always expect there that there will be a fancy document created and that document will say, I am business analysis approach of the project or I am stakeholder engagement approach of the project or I am the governance approach,
[02:53:01] right? Sometimes you don't create a document, separate document just for this. It's like you know or you discussed, you emails. Or you you may create a proper document,
[02:53:13] that's fine. What I'm What What I'm saying that it's not mandatory that for each and every such things you have a very formal document created, right? sometimes it's over email, sometimes
[02:53:26] there may be a formal document also. So, it all depends. But, the purpose is why we need these two inputs so that you can identify the governance approach. Okay? Now, you see guidelines and tools again
[02:53:39] the same thing from your previous projects, you might have created such things like governance approach, so you can take that you can use that. If there are any business policies that says, for example, up to
[02:53:53] 10,000, team lead can approve, but beyond 10,000, only manager can approve. Many such things, right? Where you have approvals, where you have authoritative
[02:54:05] decisions, there can be some business policies that who can approve, who can provide this. So, if there are any such policies, we need to take care of. Current state description, why? Because it will again, it will explain you what
[02:54:17] is the who are the stakeholders uh and uh who all we need to consider when etc. And same is for legal and regulatory. If there any legal them. So, the purpose of this task is to
[02:54:32] identify how business analysis work will be approached and prioritized, define the process for proposing changes, the change control board. This is the prioritization as I explained you that in Agile only
[02:54:44] PO is responsible, otherwise you may have a prioritization board also. Clarify who is the authority and responsibility to propose changes, determine who is responsible to analyze the change requests, establish who has
[02:54:57] the authority to approve changes, and specify how changes will be documented and communicated, right? Implementation of an insurance claim processing system. Context: Insurance company initiates a new claim processing system to improve
[02:55:11] efficiency, traceability, and compliance. The project expands expands several departments, including legal, claim processing, and IT, all of which have a stake in the
[02:55:25] compliance. Challenges: Multi-department approvals documentation. Regulatory framework mandated a strict artifacts. Lack of governance in previous project
[02:55:40] ambiguous approvals. there is no governance, it I mean, project will get Multi-department approval, this is what we do in your Yeah, on your BRD FRD, all
[02:55:56] 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
[02:56:09] that on that document, what exactly do you what exactly you do to manage those changes and you will know make sure to make sure that audit trail is maintained. So, this is the main point that
[02:56:22] this is also very very important thing, right? To maintain the different to document. If it is doing it on Jira, requirements are captured on Jira,
[02:56:35] captured. Or you are using, let's say, SharePoint. So, when you upload the document, it gives you option to override the version. So, there also automatically your
[02:56:50] Confluence. But, in case you are you created a Word document or spreadsheet or something, you can always create a table in the beginning of that uh uh in the beginning of that document,
[02:57:05] where you can have simple things like um uh uh date, what change So, date, changes, and you will have who uh sorry, the change ID.
[02:57:17] basically three, four things. The change number, let's say, 1 2 3 4, whatever. And then you have uh some description about that change. And also you will have version number. Version number. It will be like for first
[02:57:31] version you can have one. Or then you can have 1.1, 1.2, Or then you can have 1.1, 1.2, 1.3, and then you can have 2.1, 2.2. Why when you move like this number, minor number, 1 2 after after point you're
[02:57:44] moving 1 2 3, that means a minor change, minor version change. When you move this number, that means there is a bigger change, right? Larger change in the document. So, sometimes you can have even three 1.1.1, and you
[02:57:58] keep moving this for very minor changes, trivial changes. For medium 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
[02:58:11] you can have uh other things which were part of your change control, change request format, right? Who Who requested the change? What is the impact? And everything then
[02:58:23] you can document in this table. So, practically you will have to have FRDs, if you are creating formal documents, right? And then as I in share on SharePoint and on Confluence, change control is I mean
[02:58:37] version control is maintained by the system itself. Obviously, when you 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
[02:58:51] comments so they are so that they are part of the Clear? Now you see the governance structure here for this scenario. A steering committee was was formed to
[02:59:04] review and approve high-level business requirements. A change control board was set up for evaluating and approving all change requests. All documents and requirements were
[02:59:18] maintained in SharePoint with versioning enabled and access control implemented. stakeholder roles and escalation paths were clearly defined using RACI matrix. part of governance.
[02:59:33] Approval workflow, e-signature workflows ensured timely and traceable approvals. governance meeting were scheduled with representatives from each department to just we discussed. There is I think one
[02:59:49] point that is access control, right? So, that is also part of governance. What does that mean? Who can access, right? So, on SharePoint, I mean every project can create their own SharePoint and then
[03:00:04] they can control the access. If I need access, I may have to request that SharePoint's are not public documents where anyone can come and have access. Right? So, project managers or PMOs,
[03:00:16] they will maintain the access. Only project people or relevant stakeholders will have the access to that SharePoint. What are the outcomes? All documentation was audit ready, regulators commanded the traceability,
[03:00:28] weekly meetings and clearly defined decisions. The defined governance model ensured clarity of responsibilities and the CCB successfully handled changes with minimum disruption. So, these are the benefits of
[03:00:41] the benefits of this uh governance. handle this? C. Change control board. In a compliance-heavy project, how does a business analysis governance
[03:00:56] plan help ensure audit readiness? Again, the correct answer is C. By tracking decisions, approvals, and changes formally. In an adaptive approach, when is planning typically finalized?
[03:01:11] Iteratively throughout the project. Which of the following is an appropriate activity in hybrid approach? Fixed documentation for every sprint, no planning at all, combining formal approvals with iterative feedback,
[03:01:23] avoiding collaboration with developers. Now, in in some some of the questions elimination is the best approach. If you are confused, you know, any nobody can say that no planning should be done. Right? Even it's agile, rapid agile,
[03:01:38] whatever, no planning is is not the solution. So, you can simply eliminate. Collab- Nobody in any of the approach would say that avoid collaboration, whether it's waterfall, agile, rapid agile, Kanban, lean. Nobody would say
[03:01:51] that avoid collab- collaboration. So, these two options are gone. And fixed documentation for every sprint is is impossible, right? Every sprint will have different features to be delivered, different requirements to be
[03:02:03] delivered. So, same documentation cannot work for every sprint. uh C, combining formal approvals.
[03:02:18] identify all stakeholders in a large complex project? respond?
[03:02:32] Correct, C yes. What type of meeting is most useful for continuous stakeholder input in agile projects? So, in agile projects, there is nothing like weekly status report. In a typical agile project, there is
[03:02:44] sessions or mid-phase approvals. So, in fact, out if you have if you have basic understanding of agile, you know that these three things you don't even exist in typical agile setup.
[03:03:02] option. Next question, when should the change be established? At the end of the project, before requirements are finalized, only for low low priority task, after the release. Correct answer
[03:03:15] See, if I if I ask you, let's play a game, right? game, right? And once we are I mean, in between or towards the end, I say, "Now I'll tell you the rules and as per the rules which
[03:03:29] I just told you, I'm the winner of that game." Would you like it? So, generally, it's always good that if you want to set up governance, if you want to set up any rules, any practices, we should do it
[03:03:43] beforehand in the beginning so that everyone is aware. So that nobody can complain, you know, I if I had I known this, then I would have done that differently, right? So, to avoid such
[03:03:56] conflicts, it's better to set up your rules, governance, etc., etc., in the beginning towards the first phase of the of the project. In a predictive approach, what ensures traceability of requirements? Because
[03:04:09] approach is predictive, so anyway burn down charts, daily stand ups, they won't they are not valid options. Correct is C. What does stakeholder analysis helps the BA determine?
[03:04:24] A stakeholder analysis. What does it help us with? influences, [clears throat] and engagement risk.
[03:04:36] So, the fourth task is plan business analysis information management. Now, what do you What do you understand reading the name? management, what do you understand? Do you get any idea by the name itself?
[03:04:53] What do you think will be the purpose of this particular task? Yeah, just to reiterate, for example, in the previous task, we established the governance, right? It was not like we executed the governance. At that time, we were not
[03:05:06] escalating. At that time, we were not setting sending anything out for approvals, right? It was just this the understanding and and setting up the process, governance process. Similarly here, it's not like
[03:05:20] 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 information is stored and managed, management of information, who
[03:05:32] getting information, how to handle collection, right? All the all of that, right? First of all, tell me what all is considered as business analysis information. What all can be considered
[03:05:46] as BA information? All your requirement documents, BRD, All your requirement documents, BRD, FRD, Jira, whatever you create. In fact, minutes of the meetings, any diagrams, wireframes.
[03:05:58] So, any traceability matrix, RACI matrix, sort analysis. So, whatever you perform, right? All of those things are considered your business analysis What is the purpose of this information? What is the purpose of all these all
[03:06:13] Ultimately, you will have to share them with these stakeholders, get their approvals, etc. like we discussed. So, now you tell me, what do you think can be the input to this task?
[03:06:26] 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
[03:06:38] requirements are not only the BA information. There are many other things like diagrams, minutes, RACI, traceability. All of them are information. So, any information that is supposed to be managed.
[03:06:51] So, that is the BA information. What else will be the input? So, this BA information and the risk stakeholder engagement approach. Why do you think a stakeholder engagement approach can be the input?
[03:07:04] Because all that we are doing, managing, and sharing of the information, that is stakeholder. Right? So, now you Do you think it's difficult to guess? Once you start understanding
[03:07:17] what is the 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
[03:07:31] options. Right? Like in this case, I you can guess that because we are talking about managing the information, so first of all, information has to be the input. And why we are managing? For the
[03:07:44] stakeholder. So, that may be That is also the input, right? This task is about defining how How will create, organize, store, access, and manage all business analysis information. So, this is this will also
[03:07:59] cover how you who all can have access to access management, access control of that information, and sharing also. Like tell me one thing, you created a huge BRD.
[03:08:11] Now, that BRD is let's say because of these screenshots, because of the pictures, etc. Now, it's 50 MB. And your organization does not allow 50 MB documents to be shared over the email. So, what would you do? You want
[03:08:24] stakeholders on this BRD. How will you share the BRD and take the approval? Approach, SharePoint Drive, Confluence repository. Right. And then, you can simply share the link of that SharePoint to all
[03:08:39] your stakeholders that this is the BRD uploaded at this location. Please review it and provide your sign-off. Right? So, now do you think that a stakeholder engagement is playing some role here?
[03:08:53] what all inputs are there. BA approach, because in waterfall you different information. In Agile, you will create different information, Because this information is supposed to be shared with the stakeholders to take
[03:09:09] their approvals, to take their sign-offs, to take their inputs. That's sign-offs, to take their inputs. That's why they are also that is also there. And also, you will discuss with your stakeholders, right? What kind of
[03:09:22] documentation they they are expecting? Like I told you some of my stakeholders to create BRD. And third is governance approach, because we are again talking about approval, sign-off, etc. So, all three
[03:09:35] inputs make perfect sense when you talk about business analysis information Right? Again, the same things. If there is any lesson Sorry, lesson learned business policies.
[03:09:49] Information management tool, right? This is a new guideline which was not there with previous task. But it is making perfect sense. Because if there is SharePoint, which is used consistently in your organization
[03:10:02] and the mandate is every team will use it. So then you will use it. So see, whenever there are you know, decisions made by the organization, for example, which tools to be used, I think it's it gets easy
[03:10:16] right? The less decisions I need to make, the better I feel. And especially the bigger decision, which tool to be used and all, right? So if there is any information management tools which are, you know,
[03:10:30] mandated or some prescribed by your organization, it's good. SharePoint, Confluence, whatever. And if there is any legal regulatory information that is So you see, very easy to guess guidelines and tools, very easy to guess
[03:10:43] And output is information management approach. Now again, as I said earlier, you may not have to create a dedicated document that this is the information management approach, right? It's just discussed, agreed verbally, maybe over
[03:10:57] email. Sometimes, if it is really formal, your project environment is really formal, you can create a document with just one table that these are the documents I'll produce. This is how I'll store them.
[03:11:10] And this is how I'll share them for the approval. So a simple table can be Key elements. Organization of business analysis Business analyst structure information for easy access considering data type,
[03:11:24] stakeholder needs, and change complexity while ensuring clarity. So how would you store? It's like it's like how will you create a folder structure? So for example, I created a project SharePoint. Let's say
[03:11:39] project one. So this is my SharePoint. Here I can create folder structure. That this is for BRD. All different versions of the BRD will be here. Here, I have, let's say, all the approvals, which I
[03:11:53] need to store for audit purpose. I can have all the whatever um if I have created any other documents, I can create put it here, let's say, test
[03:12:05] sign-offs. So, basically, the simple organization, like even in our laptops, we do that, right? You create a proper structure, so it's easy for you to fetch the information later, refer to that
[03:12:17] information later. Um Okay. information. And then, this is also important, level of abstraction. Because not every stakeholder can consume the
[03:12:31] information at same level. Your sponsor might need just one slide. Right? One slide to understand the status of the project.
[03:12:44] uh your tech team might need a detailed BRD, detailed FRD, maybe detailed design documents. Right? So, you cannot have same meeting or same document for all your stakeholders. So, when you create document, you may have to take care of
[03:12:59] the role of the stakeholder, the complexity of the information, and what kind of documents they are they are they are you know, they can consume. are supposed to create for different stakeholders?
[03:13:13] You will discuss and agree that in previous task, stakeholder engagement So, when I talk to, 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
[03:13:27] create this document. Do you Are you okay with this? Do you need something else? Right? Same goes with um other projects, and stakeholders. So, you create different documents for
[03:13:40] different stakeholders because not everyone can consume 100 pages of Somebody needs 100 pages, so they are not or they cannot be okay with two-pager plan traceability. We discussed that requirements are captured
[03:13:53] at different levels, right? You have your business requirements, which are high-level business requirements or mission purpose, the requirements or mission purpose, the main objective of the project. Then, you
[03:14:05] Then, you capture functional non-functional requirements. Right? And then, you create your trade test cases to test the requirements. You have releases to
[03:14:20] release them them in production. Things like that. So, basically, the work that we do in a project the is a stakeholder requirements that that we implement or functional non-functional requirements that we implement. They all should
[03:14:34] 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 purpose that all the work that we are doing here, any
[03:14:47] stakeholder requirements that are here, or any functional non-functional requirements that are here, they all are aligned to at least one or business purpose, some business requirement.
[03:15:01] 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.
[03:15:14] trace uh in both the directions. So, if you're tracing in this direction, this is called forward traceability. If you are moving in this direction, this is called backward traceability.
[03:15:28] So, basically, they answer two different questions. questions. The the the business requirement or the stakeholder requirement, is it getting delivered? Is it getting coded? Is it
[03:15:40] getting delivered through any of the requirements? It is Is it getting tested properly? So, that is how you look on on forward side, right? That okay, yes, this particular business requirement will be
[03:15:52] non-functional requirement. These are the test cases which will test this requirement. And this will be part of release one. So, this is forward. You are making sure all your requirements are getting
[03:16:06] are getting tested. They are getting released. So, forward traceability. Why I'm doing this particular test case? Why I'm writing this particular test case? Why this functional non-functional requirement exist? So, if you want to
[03:16:20] 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 objective, that is called backward traceability,
[03:16:33] right? So, you can trace back to the business objective. That is backward traceability. So, that's where traceability matrix is very very very useful. If you have this properly created
[03:16:46] properly documented, it gives you information in both the directions. Okay? R stand for release. it's like for business analyst, you will create like first four columns.
[03:17:02] Then test cases, you can request your testers to full to you know, capture So, that will make sure your test coverage, all the requirements are getting tested. From development team, you can get the idea on releases. So,
[03:17:17] obvi- obviously, you own this document. It's your document, but you can take the inputs from testers, from developers to full to fill these last two three columns, right? So, this is is the purpose of
[03:17:30] traceability forward and backward. Now, in the same document can provide you a lot of insights. Right? That is why I consider it very important. A lot of insights you can get just by looking at the traceability
[03:17:43] matrix. So, let's say there is this traceability matrix. I've I'll create it traceability matrix. I've I'll create it here. So, there are business requirements. Let's say one, two, and three.
[03:18:00] non-functional I'll capture here just for the simplicity. And there we have test cases and releases. So, against if if any if against any of these business requirement, this column is blank, what does that tell you? You
[03:18:15] non-functional requirement. What does that tell you? Obviously, your traceability matrix will not be as simple as this looks right now. You might have multiple rows under each and every business requirement for each and
[03:18:28] requirement. So, this situation where nothing is requirement, what does that tell you? This tells you that maybe this particular business requirement is not covered. This is not getting developed
[03:18:42] because this is not linked to any of the functional non-functional requirement. Right? Similarly, if this field is blank, it tells you that this functional requirement, whatever is here, or this
[03:18:54] getting tested. They are not part of test coverage. Here, if you see everything is populated here properly, but this field is blank. You know that maybe the developers have not included
[03:19:07] release. So, you get a lot of insights, right? Whether your requirements are getting properly coded, whether they are getting properly tested, whether they are part of the release or not. Right? All of
[03:19:20] 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 Do you see any problems with this this row? What is the problem here? That
[03:19:34] 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 something which is too big is always that will create a lot
[03:19:48] 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 split it into smaller ones, right? So, you see how many different in in in
[03:20:04] in inputs you get. Now, what happens when you go to your team in the requirements. How do you think your developers and testers react? to the team with a change request, what is the first
[03:20:21] business analyst is so stupid. He keeps coming back with change requests, right? Then they resist. So, first of all, very rarely they are happy with a change request.
[03:20:35] analyst, whenever you go to your team with a change request, they just resist it. That okay, uh then what is the second point? So, first point is the resistance, right? They'll tell you so many things, but what is the second
[03:20:50] point? Second input that comes from their side. That this change request means I have to do everything all over again. There is a huge impact. Now, I'll have to rewrite the code. I have to test
[03:21:04] they try to tell you that everything is impacted. Everything has to be redone. Is it normal or not? Normal. That is the normal reaction that you get from them. documented traceability matrix, do you think it can See, it's not like we are
[03:21:20] going to fight with developers and testers. But, do you think it it will negotiate, where you can have a reasonable debate that, you know, requirement I am changing one functional
[03:21:32] requirement and this is the impact on test cases. cases are impacted? So, basically, it gives you some background, some information which can put you in a situation where you can you
[03:21:45] know, question, cross-question, right? Again, it's not to get some background, right? Otherwise, they think BA or PMs, they don't have technical background. So, we can tell everything is impacted and
[03:21:59] they'll agree. Right? Do you agree or not? Proper traceability matrix will give you so many different inputs which are required in the project. Okay? are required in the project. Okay? Now, one more layer. So, in my in my
[03:22:13] recent projects, I'm not part of any particular development team, okay? Let's say there is a big regulation coming up, a big project, where you have few very high-level, big requirements.
[03:22:28] Okay? So, first thing that I do, I interpret these requirements and let's create Let's say I create a BRD. Okay? Where I detail them down and I create some business requirements.
[03:22:43] Then, I'll create this traceability matrix, where in this column, I'll list down the impact
[03:22:57] 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 flow.
[03:23:11] 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.
[03:23:24] For example, okay? This requirement which is here, this will have impact on application four, three, and one, and two. Now, in the next column, here I'll write down the exact impact.
[03:23:40] 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. same that you know, code or test cases and releases, etc.
[03:23:54] complexity where I'm tracking the changes or the impacts on multiple applications because of my requirements. And then the responsibility I can add one more field here, that is the
[03:24:08] application Jira. So, now you think about a situation where I'm working on a big program and there are multiple applications applications, they would have their individual BAs working for that
[03:24:22] 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 documents, etc. For them, this traceability becomes
[03:24:36] truth. They come to this matrix. They filter on this column that if they are from application one, they'll simply filter out all the requirements on the basis of application one.
[03:24:50] And they can see the exact impact on their applications. Right? Then they create respective Jiras. They create test cases and assign them So, if I want to check all my BRD requirements are getting
[03:25:04] getting developed, I will simply say if see if all the requirements have Jira's to them. So, if requirement number four does not I'll talk to that BA and say why this requirement is not getting coded. Where
[03:25:19] is the Jira? Where are the test cases? Right? How you are testing? I can get a walk-through of the their test cases to make sure all my tested. So, you see from simple metrics,
[03:25:32] 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
[03:25:47] document in all my projects. This template is like you can create if create this. Because in in this example, in my example, it can get very very complex because I'm
[03:26:00] talking about Here, if you have 50 requirements, right? And you have like in my previous project, 15 applications were impacted. And you can imagine number of rows
[03:26:13] matrix. So, if you want your entire project document sing this week, this can become your entire project document because when I'm talking about requirement number one, I
[03:26:26] can mention the entire requirement here. Right? So, there is no BRD. I can create into a single document because I'll mention requirement here itself. They can write Jira here They can write test cases here itself. But then it will
[03:26:40] to maintain. You must understand also that if you create too many columns and make it very complex, there is a change to update this and maintain it
[03:26:52] to keep it simple and Okay? Now, how will you implement this requirement? You as a learner, you want to see your
[03:27:07] attendance in the LMS. How How will you implement it? There has to be some functional requirement. Functional requirement will will be the navigation on LMS. On this page,
[03:27:21] there should be a table where you can see your attendance. Right? You can have requirement. will be a functional requirement explaining this is how it will be
[03:27:34] implemented. Functional requirement will tell you how. simply I want to upload. But how it will be uploaded? That part, the screen, the buttons, uh how you know, any controls
[03:27:48] that you want like only 10 MB document can be uploaded, not not bigger than that. All those things. Now, they are captured in functional requirements. Right? And uh these requirements are supposed to be
[03:28:00] tested when implemented. So now, when you look at the traceability matrix, functional requirement the stakeholder requirement was to have a feature to upload document. This feature, this particular requirement is
[03:28:16] solution requirements or functional Uh one is related to UI, one is related to the UI control. And these two requirements are getting tested by these 20 test cases.
[03:28:29] you can make sure all your requirements are getting developed through some functional non-functional requirements, and they are getting properly tested. So, this is the main purpose of traceability to make sure everything is
[03:28:41] What is the meaning of plan for 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
[03:28:56] 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
[03:29:09] 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
[03:29:23] out. Right? Because that is the purpose here of plan for requirements reuse. Reusing if your organization works on similar projects, right? So reusing well
[03:29:36] structured accessible requirements saves time and cost. So that is the purpose. You are anyway you know on managing your requirements, you are creating the drives, you are properly organizing your structure.
[03:29:49] But if you think they can be reused, then it becomes even more important, then it becomes even more important, right? To properly organize, to properly right? To properly organize, to properly label your folder. So even if as as as a
[03:30:01] I I want to check your requirements etc. You give me the SharePoint link. I should be able to navigate through different folders myself because they are labeled properly and they are
[03:30:14] organized properly. So 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
[03:30:26] SharePoint, Confluence, even these normal hard drives where you are storing in the documents like BRD, FRD and traceability matrix. So that is the storage and access. Then requirement attributes. What are
[03:30:40] requirement attributes? Anyone any idea? So see how do you capture requirements? what are the main attributes that you Requirement ID, requirement let's say name.
[03:30:55] requirement let's say name. Description. Requester. Current status of that requirement.
[03:31:07] Things like that, right? Any supporting document, any supporting diagram. So, you capture requirements in a particular template using fixed attributes. Right? Is that correct or not? Even when you create FRD or BRD, this is
[03:31:22] like you have some common sections and then for requirements you create this have 10 requirements, you will repeat the same table 10 times and every table Right? Even when you create requirements in
[03:31:38] Jira, Jira has the same template. When you create, click on create, it will open up a window where you have multiple fields. are mandatory. You will have to fill all these fields
[03:31:51] and save, then your Jira gets created. So, these that these fields are called requirement attributes. So, again, if you have admin access and you check, in Jira you have hundreds of fields
[03:32:04] which are available. As an admin, I can choose out of 100 that I want these 20 choose out of 100 that I want these 20 fields to be captured. So, as an admin, I will go in in settings and I'll change that only I'll select only 20 fields.
[03:32:18] So, when the user will 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 capture for each and every requirement, right? So, requirement attributes
[03:32:34] key information to individuals or group group requirements. They help team assess trade-offs, identify impacted evaluate change impact. So, here you can have a status, you can have impacts, you
[03:32:48] can have impacted application, supporting application, upstream systems, downstream systems. So, a lot of fields can be captured here. So, here again, just to reiterate, we are not creating requirement document.
[03:33:02] We are just deciding what kind of requirements we'll create, how many attributes we'll capture for those requirements, where we will restore those requirements, how we'll manage the access control, how we'll
[03:33:14] have the access control for those requirement documents, right? And output is the document strategy. How, where and how information is housed or stored, who can view, edit, and share
[03:33:28] version management of those documents, if any guidelines for reuse reusing of those timelines methods. So, simple, as a
[03:33:41] BA, this is what you want to achieve. So, a school is planning to introduce an online student registration system to replace replace its paper-based process.
[03:33:53] The business analyst is working 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
[03:34:05] saved in Google Drive folders with clear labels like student requirements, ideas. The school principal and admin have full access. Teachers can view only the requirements. The IT provider can
[03:34:20] requirements, right? So, this is what we try to achieve. The BA decides to reuse parts of the old registration form like parent contact information fields, right? The BA dates each document version and saves them as requirement
[03:34:35] version one, version two, and so on. Old versions are moved to archive folder. Then retention and archival also. Clear? The outcome time is saved by using past documents. The IT provider
[03:34:49] version. No feedback is lost. Everyone knows where to find latest files. So, this even though this is a small business analysis information saves time. Fifth and last one is identify
[03:35:03] improvement. So, what is the what is the meaning of business analysis performance? In order have to measure that thing, right? Then
[03:35:17] working as per the expectation or some performance improvement is required. how do you measure what exactly is the meaning of what exactly is the meaning of business analysis performance? Build or use the existing
[03:35:32] KPI framework. What do you mean by KPI framework? Key performance indicator framework for business analysis performance. So, what framework? As per our understanding of the business
[03:35:47] 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 near to your house, how will you say
[03:36:00] not? On the basis of their daily sales. If you see people who are you know, uh the that's that shop is always crowded, so you can say that, you know, whenever
[03:36:14] that shop, I go through that shop, it's always crowded. So, on that basis, I can say that their sales is going So, similarly for business analyst, what kind of
[03:36:27] parameters you can use? So, first thing, let's say you created a And it took five cycles to get it approved. Do you think it's good or bad? How will you judge the skills and efficiency of
[03:36:42] the business analyst on the basis of few things that we need to identify, right? Like number of review cycles required in order to get the document signed off. Do you think it's a relevant metrics? Can you judge a business analyst on the
[03:36:57] basis of uh defect identified in a code? No. Can you 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
[03:37:09] marathon or not or not? No, all these factors are irrelevant to a business analyst performance, right? What are the relevant metrics? What are the relevant indicators? Number of
[03:37:24] cycles required to get the sign off on the document. Number of requirement related number of requirement related defect identified. Right? Generally, whenever we talk about
[03:37:38] 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
[03:37:52] the document. If they are happy with the document or not, right? So, all these three, four, five indicators are good indicators to to see the performance of business analyst. Also, please note that we are not talking
[03:38:05] please note that we are not talking about the annual performance of as an you know, the annual performance of the person. We are talking about the performance as a business analyst. How the business analysis work
[03:38:20] went into this project, right? How many how how was the document, how was the many defects identified? We are not talking about the business analysis as a deliverable, as a the documents
[03:38:36] that we 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 talking about did you complete all your trainings, did you did you fill your
[03:38:51] timesheets on time, did you, you know, behave properly? That is not individual's performance here. We are talking about business analysis performance, not business analyst's performance, okay? It focuses on
[03:39:03] analysis work and identifying opportunities for improvement to enhance future performance and outcomes. Right? So, examine the performance of past and ongoing business analysis
[03:39:17] tasks, highlight inefficiencies, misalignments, outcomes, suggest adjustments to methods, tools, and communication, ensures BA effort align with the
[03:39:30] business goals and performance data to lesson learned. So, let's see. So, the first part is inputs. First input is business performance objectives. What kind of objectives we can set for a
[03:39:43] business analyst before business analysis work? Why it is mentioned 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
[03:39:58] particular input is the output of task number 3.1, which was the identify the project business analysis approach for your project. This input not coming from any other tasks, right? There is
[03:40:12] That is the reason there is no number mentioned 3.1 or 3.2. Instead of that, in the bracket, it's mentioned external. So, this input is from outside. Okay? And also, you see additional
[03:40:25] standards. So, if there are any standards already specified by your analysis work, then that can be utilized. Okay?
[03:40:38] 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. And I was telling you that this input is the output of one of the tasks from the
[03:40:52] same knowledge area. Right? So, here you can see that the here is used by other tasks. Now, you can question that those tasks were performed
[03:41:06] earlier than this task. How can they use the output of this task, right? Does that question come to your mind? Or you know the answer already. So, the see, first of all,
[03:41:18] these things are not performed in a particular sequence, right? mentioned, it's not necessary that you perform them in the same sequence. So, Second reason,
[03:41:31] iteratively. Right? It's not like you did them you performed them once and they are done. Also, why they are done iteratively? That
[03:41:45] because it's possible that initially the input input which was available was partial. you started working as per that partial input and later you
[03:42:00] available. More data, right? So, you then again you perform the task. So, that is why I it it every the task. So, that is why I it it every task maybe done iteratively multiple
[03:42:13] Initially with the partial data. So, in for example, we discussed about a stakeholder identification, right? Identify your stake Holders, can you perform a stakeholder identification confidently in one go?
[03:42:28] Can you confirm after whatever efforts you put in early that I have identified 100% stakeholder? Even if you feel that you will identify two more stakeholders after 1 month? Because
[03:42:43] somebody else might come to you and tell you that, you know, there is these are two more stakeholders which can be impacted. So now what will you do? Will you not go ahead and perform the
[03:42:57] ahead and perform the elicitation with these two stakeholder? Right? So initially you would you identify 10 stakeholders, so you went ahead and started interviewing them. So you started the elicitation, right?
[03:43:12] Then you identify two more stakeholders, for them as well. So you see what happened? Stakeholder identification was done in iterations.
[03:43:24] And similarly because of that your requirement elicitation was also done completed in one go. So that is the reason if you think about any of these tasks like uh
[03:43:37] discussed you you will identify more stakeholders. So this particular task iteratively. Right? It's also possible that some new issues identified and you have to add something
[03:43:53] to your existing business analysis governance, right? Uh so this document or whatever the approach is also going to be a live time. Same here, you identified something
[03:44:06] first time. tomorrow we will capture some additional attributes for the requirements. So here also it it can change, right? So that is the point that initially let's say when
[03:44:20] you started performing these tasks, maybe this past assessment was not fully available, but you still went ahead and performed these tasks. went ahead and performed these tasks. Later on, when this was available,
[03:44:35] again. Also, it's possible that this performance assessment is coming from the previous project, right? So the performance assessment from previous project was
[03:44:48] already available when you started with 3.1, 3.2, 3.3, right? So that can be one 3.1, 3.2, 3.3, right? So that can be one more reason how this output was already tasks. Either because it came from the previous project or the input was
[03:45:02] partially available or you started the tasks without that approach assessment and you will perform them later when when this become available. Clear? So that is how you need to think about it. Never think that any tasks or
[03:45:20] any knowledge areas they are performed in the exact sequence in which they are mentioned in BABOK. That is not true. You will perform them in different orders depending on the project. In fact, the order of knowledge area itself
[03:45:33] Order of task within each and every knowledge area will definitely change. Okay? And most of those things will be performed iteratively multiple times. Now the key elements, so it's like very
[03:45:48] uh you know our performance appraisal. Initially what you will have, you will have the assessment measures. The focus is on establishing clear criteria to a BA work. We discussed some of the measures,
[03:46:04] right? Number of review cycles required, number of defects identified, requirement related defects identified, the qualitative feedback from your customers, the quality of of of your requirement document, right? There can
[03:46:18] be many such things that can be identified and documented. Then you will analyze your outcomes against these measures. So, you have objective set.
[03:46:30] performance appraisal as well. What is the process? In the beginning of the year, we all create self objectives. You set up yourself a goal, self objectives. You get them reviewed with your boss.
[03:46:44] You both agree. You say, "My goal is to, let's say, complete these two projects." And your boss may negotiate with you. "No, you have to complete three projects. In addition to that, you have to complete at least one certification.
[03:46:58] And there should be zero escalation. There should be zero escalation for filing. There should be zero escalation against any training, you know, completion." So, both of you would agree that these are the objectives. Now,
[03:47:13] throughout the year you review your performance against those same goals, right? Then, end of the year, you evaluate ratings to yourself. And then, finally, you will have a
[03:47:29] deserve one out of one to five. I deserve one." Being one being the best. And boss would say, "You discussion happens and all. Then you finally get one rating and salary hike
[03:47:43] accordingly. So, this is the normal process that we follow, right? Even for our individual performance appraisal. Same thing is here. You identify the Same thing is here. You identify the assessment measures first. Then you
[03:47:55] measures and analyze the results. And you will collect data to find trends, patterns, and root causes for poor performance. Any issues which are identified,
[03:48:09] that can enhance performance moving forward. Right? So, it's very very I mean it's exactly the lesson learned. You had objectives, you
[03:48:21] compared your performance against those objectives, you may be able to identify some areas of improvement, so you will work on them. Right? I mean, how will it work practically in project? It looks simple
[03:48:35] that you had some of objectives, you will compare your performance throughout the year against those objectives, and finally you will see whether you are able to meet those objectives or there is a gap. If there is a gap, what is the
[03:48:47] reason for the gap? Right? How we will fix it? For example, Right? How we will fix it? For example, you identified in the uh the project was slightly delayed, and when you uh sit as a
[03:49:01] as a team, you identified that the uh review took longer than expected. Right? So, you were supposed to get the on 15th of May, but it was completed on 30th of May.
[03:49:18] Now, what could be the reason? Can you think of any reasons that can that can be there? If you talk about the proper cycle that we generally we should follow, what is that cycle? You create the document.
[03:49:31] Right? You You are Once you are ready with your document, what is What is next that you do? Do you send it to your stakeholder for for the sign-off? Or is there anything that you do? Once you are ready, so you performed
[03:49:44] elicitation, you got a lot of information from a stakeholders, you properly organized that information into properly written requirements, you created a very nice requirement document. Now, what exactly you do as a
[03:49:57] requirements, what do you do? Elicitation is done. That's why you are ready with your requirement document, final requirement document, right? So, when I send the requirement document to the stakeholders, maybe I uploaded the
[03:50:10] document on a SharePoint and share the link, because that's how we discussed about information management, or maybe I uploaded the document over the email stakeholders. We followed whatever was agreed
[03:50:23] for information management and accordingly we shared. Now, stakeholder to me. I tried to answer those questions. They questions. I again answered them, so they had more
[03:50:36] questions. And that is the reason that is the exact reason why it took two more weeks than expected. Now, what went wrong here? do the lesson learned session and we identified requirement sign-off took two
[03:50:50] weeks extra. What is the issue that you see here? Once you are ready uh ready with your requirement document, sign-off. That is not the right approach. What you should do
[03:51:04] you should set up a a workshop where you will walk them through the requirements one by one. You'll make sure that they all of their questions are answered, they all have the same understanding, common
[03:51:18] understanding of the requirements, or you basically all of you are on the right? Now, after that you send out that email as per our walk-through session, I have answered you all your questions. In case
[03:51:33] you have any more question, please feel free to ask. Otherwise, please see the 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
[03:51:47] you simply send the requirement document for the approval without the the walk-through session, do you think you will expect you know, difference? different outcomes. So, that is how you
[03:52:00] need to find out the gaps. This is just one example where you could find out the gap. And again, this is we are not saying that, you know, it's your response We are not talking about individual. We are
[03:52:13] followed. The process which was followed, there one step was completely missing. We identified that yes, there was a this gap in the process and this time we'll fulfill we'll fill that gap and we'll make sure first walk through
[03:52:27] sessions are done. And maybe you can put it in your project documentation so that it's always there. Now, when you start a new project, if you look at this documentation, don't you think you can learn that you know,
[03:52:39] approval? That is why these lesson learns 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.
[03:52:53] Similarly, you can identify you can you will see so many examples around you where maybe a different process was followed and that led to a delay in requirements or maybe in requirement approvals or with testing, test test
[03:53:08] For example, uh initially when you were capturing the instead of uh this time we discussed a walk through which was not done for the
[03:53:22] 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 involved the developers in the
[03:53:34] initial discussions, but you didn't involve the testers. Now, can that have That can also have some impact, right? Testers were not very uh clear on the requirements. That can have impact on the acceptance criteria
[03:53:48] Sorry, the test uh scenarios or test cases that they prepared. Later on, when test test execution started, uh developers would testers would say
[03:54:01] there 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 defect? What do you think how developer responds
[03:54:15] generally? What is the first response from develop developer? any it can't have any defect. Maybe you you are mistaken. Go back and test it again. My code
[03:54:28] first uh and then the the second is my as per my understanding, this is working fine. Tester will say, "As per my understanding, this is working fine." Now, what could be the reason? They have
[03:54:43] different understanding of the requirements. Now, can you say that no, it's not my role? It is definitely your role to make sure both of them have the requirements, so that during testing there are no such conflicts,
[03:54:57] right? So, what will you do? Again, the same thing. As as you start get collecting the requirements, you can even you shouldn't wait to finalize the your team. If you have your developers available,
[03:55:13] 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 understanding of the requirements, right? So, that there are there are
[03:55:26] there will be less lesser conflicts during test execution. view, you are a business analyst, you may not know all tech technical know-how of your project. It's possible that you may end
[03:55:40] up get getting uh you know, documenting a requirement which may not be feasible So, once you involve your technical minds early in your requirement minds early in your requirement sessions, you get a very good
[03:55:53] 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
[03:56:07] things that you will learn. Now, if you read BABOK, you will not BABOK will not talk about all these instances that we are just talking about. Um BABOK will simply say that identify the measures, measure your performance against those
[03:56:21] measures, and document the lesson learned, and move on. Right? That is all So, you understood how how on what basis measured, I gave you two three examples where
[03:56:36] those gaps. We discussed the inputs, we discussed the key elements, you are clear on the task, output. Now, you know what is the It is the comparison of planned versus actual performance,
[03:56:51] identify the root cause of variance, and proposed approaches to address issues. of implemented improvements. And whatever is these metrics, whatever is the outcome, you will document it as a
[03:57:04] 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
[03:57:18] something similar that we do in Agile. Retrospective, right? A sprint retrospective. So, what is the purpose of retrospective? The last meeting that last day, last meeting of the sprint, that is called
[03:57:32] retrospective. And that is the 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
[03:57:46] be agile, this discussion, the entire discussion on performance improvement would be done in that retrospective itself, not separately, right? So, this is the last task. Okay, let's see one
[03:58:01] 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.
[03:58:14] Issues identified: Stakeholders were not clear on who should approve, when to feedback. Requirements documents varied from project to project, lacking consistent structure and details. See how many
[03:58:29] things can go wrong. You are using different template, different requirement or document structure in every time, and they are getting confused, right? Your project communication plan itself is not very
[03:58:42] How they are supposed to communicate the feedback, how they are supposed to approve, and you so you see many very simple problem. If you send out an email, and it happens all the time.
[03:58:56] 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
[03:59:09] will 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
[03:59:21] respond. Nobody will approve. Because your email itself is so poorly written. You have so many people in two list, and Nobody will have any idea who exactly you are requesting.
[03:59:35] Be it sign-off, be it anything. So, it's very important that you clearly asking or you are keeping only one or two
[03:59:47] that, you know, you're addressing them. It's still it's better to just clearly name the people. And if you send out email, how soon you can You cannot chase same day, right? Maybe you'll send a chaser next day
[04:00:03] 2 days after that because if you are sending email for the approval to senior stakeholders, you cannot chase on daily basis. So, let's say you chased after 2 asked? We have no clue." Now, you wasted 2 days,
[04:00:16] right? So, there can be many such scenarios where because of some gaps, you know, missing you missed something on your part, anything can get delayed. And you see this this is also very good example that the way you wrote your
[04:00:31] email was not correct. So, what was done? The BA team designed a visual flowchart outlining who reviews and approves which sections. stakeholder.
[04:00:44] This is also very important. See, an action without ETA is not an action. So, when you say that I have created, I have noted down the actions, they will make no sense until
[04:00:57] unless you have action owners assigned and expected turnaround time assigned to sense. Right? Communication protocol for rejection or feedback. How it helped? Made everyone involved
[04:01:11] responsibilities. Reduced confusion. Created transparency and built a stakeholder trust. requirement templates. Clear sections for functional and
[04:01:24] non-functional requirements. Defined fields for priority, dependency, and traceability. Visual elements like user story maps, etc. Now, this is what I told you when we learned about the in the previous section itself that you
[04:01:38] need to identify the attributes that you will capture, right? And I told you that you will create one table and you will repeat that table consistently throughout your document. You will
[04:01:52] 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 requirements. I also told you like in Jira you have multiple
[04:02:06] fields, but you will generally you will standardize that template right? So, that is the point to mention here, exactly the same thing. How did How it will help? Make documents
[04:02:19] easy to follow and evaluate. Reduced ambiguity and save time in formatting and in short. Generally, you should follow the same template consistently, consistently across all the projects. And that is where you
[04:02:35] role. PMOs play different roles in different organization. Sometimes they have the responsibility of a standard documentation. So, if you need any templates for BRD, FRD, or any other
[04:02:51] 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, consistency. So, reduced approval time. This was the
[04:03:03] success. And this is reduced approval time by 40%. Very good. Improved stakeholder satisfaction, a receive on your documentation in the process that you are following for
[04:03:16] business analysis. Achieve the adherence to the project timeline, right? All that is what we wanted to achieve. Clear? So, we have just completed the first knowledge area.
[04:03:28] Business analysis planning and monitoring. Your team is collecting requirements from multiple stakeholders using different tools, Excel, Jira, and Confluence. There is a confusion about which version is the latest. Which task
[04:03:40] should you focus on to eliminate such version control issues? In which task did we discuss about this? Yes, plan business analysis. Your organization has strict confidentiality rules for
[04:03:54] You must ensure that business analysis information follows compliance rules. Which element of the information management plan addresses this? management plan addresses this? Storage and access.
[04:04:10] requirements for a discontinued project should be retained in the system. Which part of the information management plan are you dealing with? Discontinued project, that means project is already done. It should There is no need to keep
[04:04:23] So, what you will do with that document? You will just archive that document, right? So, the correct answer is right. D. Two analysts are working on related features. One makes an update in the
[04:04:38] shared document, but the other is unaware and continues with outdated information. What should have What could have prevented this? Correct answer is C. You're asked to define naming
[04:04:51] conventions and format for use cases and user stories before gathering more requirements. Which component of information management is this? information management is this? A, right? Your manager asks for a
[04:05:03] quarterly report on the number of requirements defects that occurred due to incomplete analysis. Which aspect of this task you are addressing? Yes, B. Multiple requirement gaps were discovered during testing. You review
[04:05:16] how requirements were elicited and documented to find the issue. What technique are you applying? Here what we are saying that problems are identified and you you're trying to find out the and document to find the issue. What
[04:05:29] exactly was the issue? So that is why root cause analysis which help us to identify the root cause of the problem. Right? We'll go through all these clearer. A senior BAs mentoring new analysts on
[04:05:43] best practices and documentation standards. does this represent? Mentoring will fall under which which of options? It is B, right? Training and
[04:05:57] All right. So the next knowledge area, the second collaboration. Elicitation means gathering information from stakeholders to understand what they need and expect. Collaboration
[04:06:12] means working together with them to reach a shared goal. So that is uh name of this knowledge area elicitation and collaboration. As I've been telling you, elicitation and collaboration or
[04:06:27] for that matter, they are not one time, right? They are business analysis process. Some elicitation you will do now. Maybe you
[04:06:39] will have to do some elicitation more later when you identify a new stakeholder. So never assume that you will continue any of these tasks in just one go. You may have to do them again. Now when you talk about the tasks which
[04:06:53] are part of this knowledge area, there are five tasks. Prepare for elicitation. Conduct elicitation. Confirm elicitation results. Communicate business analysis
[04:07:05] information and manage stakeholder collaboration. Now this the tasks of this knowledge area are very simple. If you compare it with the previous straightforward. And when I say none none of them are
[04:07:19] performed in sequence, there is just one exception, which is these three tasks. So, whenever you perform elicitation, these three tasks are the only tasks in knowledge area in in BABOK
[04:07:34] 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, these tasks are performed in sequence. This is the only exception.
[04:07:48] Right? Now, let's quickly learn Let's quickly try to understand what exactly we are discussing here in this knowledge area. right? You meet stakeholders in different ways.
[04:08:04] You maybe online or in person, maybe one-to-one, maybe in a group setting. one-to-one, maybe in a group setting. So, you do that meeting part and you ask questions. You You probe your stakeholders. You try to
[04:08:19] are their requirements. Right? is the meaning of prepare preparation? What do you think we'll prepare before conducting the
[04:08:32] elicitation? So, in conduct, you will actually perform that task, right? But before that, you are saying there is a different task, which is prepare for elicitation. What kind of preparation do you need?
[04:08:44] So, let's say you want to conduct interview of four five stakeholders to requirements. What kind of preparation you are required You You need to do? Going through the needs, prepare questions,
[04:08:56] whom to reach, prepare the questionnaire. Yes. And whenever we think Think from very very basic. The most basic normal thing that you will have to do.
[04:09:09] Right? There is no There shouldn't be any hesitation saying meeting room. Because that is something we'll have to do. So, some start from very basic. What all things that you
[04:09:21] need to do? What will be output? Who will be benefited with the solution? yourself. What is this project all about? What is the scope of this project? What exactly I'm going to ask? Who are the
[04:09:36] then you will prepare the questions. You will uh perform other things like booking the meeting room if you are uh if if you if
[04:09:48] you need to run a workshop or interview. You will prepare other training material. If you need to carry any additional documents, you will collect those documents, right? So, uh if there is any stationery
[04:10:01] required, let's say you plan to run a workshop or brainstorming session. There might be a requirement for a whiteboard. Uh in some cases, it's already there in your meeting rooms, right? In your offices. But sometimes, you may have to
[04:10:13] request. Let's say you 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 senior stakeholder sitting on a different floor
[04:10:25] and you sit on a different floor, which floor would you like to book a meeting room on? It makes sense to book a meeting room on his floor, right? On their floor. So, that they don't have to walk to your
[04:10:38] floor. So, there are many basic things that you will have to take care when you prepare. Like time zone differences. If somebody is in different time zone, you will have to take care of time zone. If somebody is uh
[04:10:51] there there are problems related to language, communication, then you will also have to take care of that. So, basically, consider your stakeholders, their preferences in terms of timings, time
[04:11:03] zones, uh the location, and then you prepare the all the additional material respect to meeting rooms and then one more important part so we
[04:11:19] discussed what you need to prepare and I'm sure you would agree that you need to prepare your stakeholder also to prepare your stakeholder also right to get to the maximum benefit to
[04:11:32] meeting you need to prepare your stakeholder now what do you mean by preparing your stakeholder before this what do you think we should do sharing the agenda with them agenda of the
[04:11:46] 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
[04:11:59] you will not start celebrating see I knew that you wouldn't know the answers point that you know even your stakeholders don't know the answers that meeting the the ultimate goal of the meeting is
[04:12:15] to get the answers so that you can move forward in your project not to prove right so it's very very important that you share the agenda in detail you provide the project background right and also if
[04:12:29] possible share the questions also in advance so that is how you will prepare the stakeholder so that they come prepared in that meeting also what else you can do that I mean a very very important practice that I
[04:12:42] 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
[04:12:56] to build that rapport right you might have heard that term multiple times in rapport building. That this is where it will be very useful. What I do almost in all my projects that
[04:13:09] if I'm I'm 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
[04:13:23] project as a PM or BA, whatever, and I'll be working with you. I'll start setting up meetings uh to conduct the elicitation, etc. So, I'll try to break the ice before the first formal event that I'm going to run with that
[04:13:36] stakeholder. And trust me, it will help you a lot. Okay? So, you prepare yourself, you prepare any uh stationary, any other material, rooms,
[04:13:49] etc. that is required. So, you prepare for any supporting things, and you prepare your stakeholders also. All these things you do before conducting Right? So, this is the first task of this
[04:14:03] knowledge area. Second task is about actually conducting the elicitation. So, in uh also one more thing which we forgot, in during prepare prepare for elicitation, you will also choose which technique you will use.
[04:14:18] which technique you will use. Right? Like you will do a workshop, Right? Like you will do a workshop, or you will conduct interviews, right? Or you will use questionnaires or surveys,
[04:14:34] 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 questionnaire. In case of interviews, you'll have to
[04:14:47] prepare accordingly. You need to I finalize the technique also. Now, tell me practically on what basis you will finalize the technique. What is the most important criteria which will
[04:14:59] help you decide which techniques to use in your project for elicitation? What are the criteria? What are the important points that you will consider in order to decide which technique should be used in this project. So, the
[04:15:11] important point is number of the stakeholders. 100 stakeholders, can you possibly conduct interview? If there are 30 40 stakeholders, we cannot possibly Even for 30 40, it's
[04:15:26] 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 reach to 15th stakeholder, he says something
[04:15:40] which is in conflict with what first stakeholder said. Now, what will you do? back to 15th. So, you can you may stuck in endless loop, right? So, when number of stakeholders are
[04:15:55] number of stakeholder is high, you cannot possibly take interviews because it will take a lot of time. When number of stakeholders are Let's So, what will you do when you have 30 40 stakeholders? What would you What What
[04:16:08] techniques What techniques will will you use? Let's say workshops, right? Maybe uh brainstorming. But when you have
[04:16:20] thousands of Let's say 500 stakeholders, can you do workshops? Even workshops will not be possible in with that number of stakeholders. So, maybe in that case, you can send out surveys, questionnaire, right? Knowledge and information of the
[04:16:33] role. Do you think it's possible to always tell what exactly is the requirement? Is it possible to always express, especially people who are not very tech-savvy, people who are not very
[04:16:47] good at talking? There are people who are very very introvert. So, it's you not 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
[04:17:00] you can do things like Have you heard the term job shadowing, active and passive job shadowing? So, what is the purpose of job shadowing? Is to to you know, what to to
[04:17:15] actively or passively look at the person when he's while he's performing his job. 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
[04:17:30] questions. And I'll try to see what exactly you are doing. So, instead of you explaining me verbally, I can have a first-hand experience looking at you while you perform your job. Right? So, this is
[04:17:43] also decided on the basis of what kind of stakeholders you have. Sometimes people who do some you know, mechanical work uh and you know that they'll not be able to explain because it's not easy to
[04:17:55] explain. So, in that case you go and job shadow them. Right? So, there are many techniques, workshops, interviews, questionnaires, workshops, interviews, questionnaires, surveys, market research, job shadowing
[04:18:07] surveys, market research, job shadowing which we can utilize. But, it depends on Number of stakeholders and how what kind of stakeholders they are. Can they help you Can Do you think they will have clarity
[04:18:22] you will have to job shadow them to find out. Now, imagine that this preparation when we discussed about prepare your Do you think you need to prepare them more when you
[04:18:36] want to job shadow them? The preparation of the stakeholder bit becomes even more important when you are going to conduct job shadowing. Do Do think everyone is comfortable when you know somebody is
[04:18:49] performing their jobs? Do you think everyone will be comfortable? I don't think so, right? Even if my wife says, "Can I come in?" If she says she asks me, "Can I come here and sit when you are
[04:19:01] be comfortable. It It gets very weird, right? So, you need to take the permission from them. You might have to take the know I'll spend one day with that person. I'll keep looking at what he or
[04:19:14] she is doing. And also that gets very disturbing also. So, job shadowing for example can be of two types, passive and active. In you do not ask questions, you do not interrupt. But in case of active job
[04:19:27] shadowing, you can ask questions. You can if you have any doubts, you can confirm then and there. So, in that case it becomes even more disturbing. So, in that case it's even more important to prepare your stakeholders before you
[04:19:40] come and you know have observed them. So, it is called observation or job shadowing both. So, that is preparation and then you conduct the elicitation. Now, conduct elicitation is simple. Whatever you decided along with
[04:19:53] 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 purpose is just to meet the stakeholder, arrange
[04:20:05] uh you know and facilitate that discussion and conduct that session irrespective of what the technique was. If it was interview, you will conduct conduct you It will you will conduct the workshop.
[04:20:17] uh uh difference is that in workshop you may have support like somebody who is taking your notes. What do you call that person? Scribe. And uh
[04:20:31] in case of interview also, you may have to take notes. So, uh and the difference main main difference is these things that in case of stakeholders. In case of interview, you may have just one or two stakeholders.
[04:20:46] 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
[04:20:59] 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
[04:21:16] you need to learn things like how you'll make sure everyone is speaking. But just that you want to run [clears throat] workshop or focus group, and you invited 20 people. How do you select those 20 people? There
[04:21:30] grouping homogeneous groups and heterogeneous. Homogeneous means same kind of background, same kind of expertise. Heterogeneous means different backgrounds coming from different backgrounds and variety of skill sets.
[04:21:44] 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, I'm designing a new house, I will want everyone to be there, right?
[04:21:58] Electrician, plumber, and everyone. But if I'm The leakage in my bathroom, I know I'm dealing with a specific problem. I need only the plumbers, not other expertise,
[04:22:11] uh this is where you decide what kind of stakeholders you are invited. Now, during the meeting also, now tell me one scenario. If you notice that out of 10 people, there are
[04:22:25] eight people who are speaking a lot or 10 six people are speaking a lot because maybe they are senior or something. Four people are not able to speak, and you think they can also have some valuable inputs to provide to you.
[04:22:37] How will you make sure they are able to speak? What will you do? We are doing this to get the requirement for the project. How job shadowing will help? So, what what do you mean by project? When I When you say project, what do you
[04:22:50] What kind of projects generally we work project, Jacqueline? Right? Have a separate call to check on Or So, basically the point I was trying to
[04:23:04] make, you will always do you will always you 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 with them
[04:23:20] separately in one-to-one 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
[04:23:33] You send out questionnaire, and you liked one of the answers that you and you think that this user can give you a lot more details. So, after questionnaire response to that questionnaire, you set up a interview in
[04:23:49] So, you see, 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
[04:24:05] are saying job shadowing. So, first of all, projects, right? Where somebody will give you a brand new fresh requirements, something. Don't Can you imagine a project where
[04:24:19] 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, the software or whatever product they are using, they
[04:24:32] are not happy with it. Now, the 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 solution, and then the project will be
[04:24:46] the purpose of this project is to solve that specific problem from the existing solution. You are not building something new. Right? Now, in this case, do you think job shadowing will be helpful? So, basically, the
[04:24:58] purpose of a project is not always to build something new. The purpose of the project could be to fix something which is existing, but it is not working as per the expectation. When you have uh
[04:25:11] knowledge areas like strategy analysis a strategy analysis will always give you kind of you know, uh uh what is the business what is the long-term uh uh
[04:25:25] uh vision of the organization? In order to fulfill that vision, what kind of projects can be launch launched? So, it's possible that the project that you are getting is initiated from a strategy analysis knowledge area.
[04:25:38] But, there you also have a knowledge area which is evaluation. Which keep evaluating the solution which are in use. Right? So, it is also possible that the project which is getting initiated is
[04:25:50] coming out of this evaluation. Some problem was identified, and that's why projects are launched mainly for two reasons. grab in the market, so that's where you
[04:26:03] launch something new. Or, there is a problem that you want to fix. Uh some uh stakeholders, some customers are continuously complaining about something, and you want to you want to fix it. Right? What is the problem with
[04:26:15] The biggest problem with job shadowing it is not uh you know, very helpful when activities are there. Right? Something is mechanical, it's
[04:26:30] 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
[04:26:43] useful. One more important point, if I tell you that I'm coming to your house for lunch or dinner today, or you ask me that, "Gov, I'm coming to your house." What I'll do? The first thing,
[04:26:55] I'll do I'll we'll try to clean up, right? Because especially when you have habit of reading, you have a small kids, it's possible that things are your house So, you will try to fix it up before somebody is coming, any guest is coming.
[04:27:11] And that's exactly what happens when you ask for job shadowing. What that person will try to do? That person will try to show show or demonstrate the best version of himself, right? He will feel like, you
[04:27:24] know, somebody is coming, he will notice how I work, how I function on day-to-day 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
[04:27:39] techniques, there are some pros, there are some cons. Right? So, that is where you need to apply more than one technique at a time. So, this is where you conduct the elicitation, you try to get the
[04:27:51] information out of those stakeholders, you use your facilitation skills. Okay? Just after that, what happens when you conduct elicitation? You get a lot of information.
[04:28:05] Right? You receive a lot of data, whatever you call them, you receive a whatever you call them, you receive a lot of inputs from the stakeholders. What is the immediate next thing that you do? Immediately, you
[04:28:18] document all of this, and maybe you will send out 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?
[04:28:31] The status more important than that. Yes, to keep everyone on the same page. The status and action act points evidence. Yes, that is also important. And keep record of agreed requirement responsibility. And the most important
[04:28:45] one is to save yourself. Right? It is possible that during the meeting somebody was not listening. Somebody didn't pay enough attention. And maybe the responsibility then is with you. But when you send
[04:29:00] um um minutes, it means you have documented the discussion. And mostly what is the last line that you mention? That I hope in case I have missed anything or misstated anything, please correct me.
[04:29:12] Please feel free to add. Please feel free to update. That in case I have missed or misstated anything, right? So when you do this, now who is responsible? Now collectively everyone is responsible.
[04:29:25] 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 documented. And now everyone, whether you listened during the meeting or not,
[04:29:38] nobody can give excuse. Now we have the shared accountability of whatever was in agreement. So that is why we send out minutes. And then this is the third task. So confirm elicitation
[04:29:51] results. Who you will send this back to? The same stakeholders who joined this. will be input to this task? Tell me which which of these task will take a stakeholder
[04:30:04] engagement as input? Which of these tasks? All of them or one of them? All tasks? All of them or one of them? All three? What if I just use it in this and then because after this I What is the output
[04:30:16] 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 steps.
[04:30:30] So, why do I need to keep looking back to, you know, engage stakeholder engagement when that input was taken care within this planning and now we I'm using this planning. Right? Then that is confirmed elicitation result. What is
[04:30:42] next? Communicate business analysis You know what is business analysis information? Every document that you right? All these minutes that you create, RACI matrix, traceability
[04:30:57] 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
[04:31:10] So, that is the fourth task. Here, what will be the input? So, basically, the information that you need to communicate and the stakeholders are the only two inputs, right? Information and you are communicated
[04:31:24] communicating them this information to stakeholders. So, stakeholder engagement approach and information. I told you in this knowledge area, what do you get?
[04:31:38] Do you get final requirements? No. Right? area? Output of this knowledge area is called elicitation results.
[04:31:52] Right? Or you can say data that you received or info that you received from a stakeholder. This is the output of this particular knowledge area. You confirm these
[04:32:04] elicitation results only. Where exactly you will convert convert documents? In requirement analysis and design definition, a different knowledge area, right?
[04:32:17] And design definition. So, in that knowledge area you will convert this information, these results into properly documented, well-written requirements. That's where we create BRD, FRD, design documents,
[04:32:32] all that. But, you see the BRD which you will create in this knowledge area if you want to share it with a stakeholder, where exactly you will come? Back to this task in this
[04:32:45] Why I'm telling you this again? So that you can see clearly there is no sequence. You perform these three tasks in sequence, you But, then you are working in a different knowledge area where you created, let's
[04:33:00] say, a BRD or you created a flow diagram. stakeholders? You you will come back to this particular task in this knowledge area. Because you this is about communication of your document to a
[04:33:13] stakeholders. And then final task is manage a stakeholder collaboration so that you can achieve the common goal of the project. So, these are the five tasks: prepare for elicitation, conduct elicitation,
[04:33:26] communicate business analysis information, very simple four tasks, and stakeholders throughout the project. That brings us to the end. Like, share, and subscribe for more business analysis and CBAP tutorials.
[04:33:42] business analysis and CBAP tutorials. Happy learning.