CBAP Full Course 2026 [FREE] | CBAP Certification Tutorial For Beginners | CBAP Course | Simplilearn

Key Takeaways

Did you know that business analysts are in high demand and that CBAP certification is a game-changer for your career? Welcome to the Certified Business Analyst Professional Exam Prep Course by Simplilearn. Now, whether you're looking to boost your credentials or advance your skills, this course will guide you through the key concepts from the Business Analysis Body of Knowledge BABOK, and by the end, you will be fully prepared to ace that CBAP exam and apply your knowledge in real-world business analysis. So, let's look at the agenda now. First, we'll dive into the core business analysis concepts like the BACCM framework and the four levels of requirements like business, stakeholder, solution, and transition. Next, we will cover essential knowledge areas and tasks such as planning, monitoring, and managing requirements through the project life cycle. We'll also explore business analysis techniques like capability analysis, balanced scorecard, and estimation method to predict cost and time efficiently. Finally, we'll be applying everything you have learned into real-world use case studies from Unilever, Stanford, WhatsApp Pay, and Mayo Clinic. So, if you're interested in boosting your career in business analysis, do not forget to check out our AI-powered business analyst course by Simplilearn. Now, this course is perfect for professionals who are looking to enhance their skills with the latest tools like Power BI, Excel, SQL, all while gaining hands-on experience with real-world projects. You'll also learn how to leverage generative AI for smarter, faster decision-making. Now, our program is IIBA BABOK V3 aligned and it will help you prepare for certifications like CBAP and CCBA. We'll be engaging with 10+ industry projects, 40+ practical activities, and benefit from live online sessions led by experts. Plus, with Simplilearn's JobAssist, you will get the support you need to land your next big role. So, what are you waiting for? Hurry up and enroll now. The course link is mentioned below. Now, before we move on, here's a quick quiz question for you. Which of the following defines the required performance and security of a solution? Your options are business requirements, stakeholder requirements, solution requirements, or transition requirements. Let me know your answers in the comment section below. So, my name is Bijou Mani. I've been working in change management, business analysis, project management, product management, etc. Mostly in what is called the BFSI sector, which is the banking and financial services and insurance sector for over 18 years. I got certified in CBAP in 2019. I have been taking CBAP training for almost 5 years now. So, that's a quick introduction to myself. Let me now switch to the agenda for today. And what we will do is before I go through the actual material, so this is the the the lesson plan. We have total nine days. But the course material is is calibrated for eight day sessions, but we will use some of these sessions for talking through the projects, and sometimes some of these will take slightly more time, slightly less time. But as a guideline, this is the kind of lesson plan that we will follow. So, today's goal is to go through two topics. One is an introduction to the CBAP certification, and then introduction to what is known as the BABOK, Business Analysis Body of Knowledge, which is basically the the text based on which the the CBAP examination is is is designed. And before we get into the actual material, what we will do is let me give you a quick view of the the LMS portal of Simplilearn. Learn. I'm sure many of you will be already familiar with and what is it that you need to do in order to complete your Simply Learn certification. So, let's go back to the plan for today once again. So, we will now start off with an introduction to IIBA and the different certifications that IIBA provides. We will look at the eligibility for the IIBA CBAP certification. We will look at the exam application process, the blueprint of the exam and the outline of the exam. We will look at the recertification. Um so, that will be the first 1 hour of the um course uh today. In the second part, we will look at an introduction to BABOK. We will define what a business analyst is. We will look at some key concepts of business analysis. Uh we will look at the key skills or competencies that you should have as a BA. We will look at some techniques. We won't go through the We won't go through them in detail because we have We will go through them in detail during the rest of the course. Uh we will look at the business analysis perspectives. And that will complete the session today. Now, the key component of uh business analysis body of knowledge is what is known as the knowledge area. So, there are six knowledge areas, right? Um in the coming sessions, we will go through each of those knowledge areas. So, the knowledge areas are business analysis planning and monitoring, elicitation and collaboration, requirements life cycle management, strategy analysis, requirements analysis and design definition, and solution evaluation. So, that will be the next part of the session, um which will be the next few days. Um once we complete the knowledge areas, there are five perspectives. We will touch upon them today, but towards the end of the course, we will go through them in detail. The perspectives are Agile, business intelligence perspectives, information technology perspective, business architecture perspective, and business process management perspective. And then we will close the session. Uh if you do not understand any of these terms, do not worry. We will go through them in detail in the in the coming classes. Okay? Let's get along with the introduction to CBAP. What are we going to cover this here? We are going to cover talk about IIBA. Uh benefits of the IIBA professional uh criteria for CBAP certification, uh the exam application process, the exam outline, and recertification requirements. IIBA is stands for International Institute of Business Analysis business analysis. Uh it is the professional body which sets the standards for business analysis. They do that through what is known as the BABOK Guide. We will hear you will hear that term again and again. It stands for business analysis body of knowledge. Okay? Um IIBA also looks at a skill ma- matrix and defines the competency model for uh BAs. We will look at the competency model or the skills that you need to be successful as a BA later uh in the uh in the session today. It will also look at recognizing your knowledge and experience through certification. So, there are three certifications that IIBA provides. The entry level certification is called ECBA. The mid-level certification is called CCBA. And the professional level certification is called CBAP. Um so, we These are the three certifications that IIBA has implemented in order to recognize your knowledge and experience and expertise as a business analyst. There are um you need you can take an the membership. You can take membership with IIBA. Membership fee will depend on which part of the world you are in. There is a tiered membership fee structure for IIBA. If you take an take a membership, there are certain benefits that comes with it. You will get to volunteer with them. You will be able to develop your communication skills. There are some events that IIBA chapters conduct. You can uh participate in it. You can network with other BAs. You can learn from experts. Uh you will be getting access to all the knowledge materials within IIBA. You can use that to learn. Um so these are some of the benefits of the IIBA membership. Um what are the benefits of CBAP certification? I won't read through all of these things. It will give you a recognition as an individual. You can achieve uh a a career goal through CBAP certification. Typically certified analysts are paid slightly higher than those who are not um certified. So these are some of the benefits. You can read through the slides. You will get the slides in your LMS as um uh as the trainer slides. You can You can go through this. I won't go through each point by point. I think that's something which is self-explanatory. This is also another useful information for you. Many organizations will support or fund those who wants to certi- get certified as a a CBAP. Uh and the benefits of the organization are listed here. So they can showcase their uh the commitment to professional development, the level of uh maturity of knowledge of their staff. Um they can make sure that they follow standard processes. They can ensure that their deliverables have certain level of quality. So these are some of the key benefits to the organizations. Now the reason why we are telling you this is you can use this to negotiate with your employer to support or fund your your your examination and your certification. Okay, now comes I think the more critical part which is the eligibility criteria. In order for your CBAP certification by your IIBA, not from Simply Learn. From Simply Learn, we we already discussed the three criteria. From IIBA, you would need to have a minimum of total 7,500 hours of BA experience in the last 10 years. It roughly translates to if you are working as a full-time BA, 4 to 5 years of business analysis experience is what you need to in order for you to be eligible for CBAP certification from IIBA. Not only that, within that 7,500 hours, you need to have 900 hours in four of the six knowledge areas. So, we will go through the knowledge areas in um in detail. So, in any four of the six knowledge areas that are there, there needs to have a minimum of 900 hours that should be there. In addition to that, you need to have professional development for 35 hours, which is what we are going to get through the course. So, once you complete the course, you will get a certificate from Simply Learn, which is an endorsed education provider of IIBA. So, you will you can use that to claim You need to provide two references and then sign the code of conduct. So, these are the eligibility criteria for CBAP certification. Now, the obvious question is what if you don't have BA experience? Many of you are having zero BA experience. So, the first thing is that your title need not be BA. The work that you have done has to be that of a BA. So, for example, if you have worked as a QA in software industry, you might not have your designation might have been that of a tester, right? But, you have worked on, say for example, solution evaluation, what we call as the knowledge area solution evaluation. You can claim that, right? You might have done stakeholder management, that you can claim in as as business analysis planning and monitoring. So, there might be certain part of the work that you have done which could be considered as business analysis work that you can claim for your certification. If you have Even after that, if you do not have enough number of hours, you need to look at some of the more beginner-friendly certifications from IIBA. You can look at CCBA, you can look at ECBA, which does not require any experience whatsoever. Now, in order to land a BA job, what you need to do is you need to convince an employer that you have the skills that are necessary to perform as a BA. So, that is where the this course, the projects that you do, any volunteering opportunities that that you utilize in order to build those skills and actually implement them in real life will come into picture. So, these are some of the This is the eligibility criteria for the CBAP certification. Now, if you are going to apply for the CBAP exam, this is the process that you will follow. So, you will first apply for the exam for the certification and pay for the certification. When you are paying for the certification, you will document your experience. So, you will say I have worked in each of the knowledge area for so many hours. In total, I have worked in so many projects. These are the projects. When you are documenting your experience, you will provide contacts who will be then approached by IIBA to validate your experience, okay? So, that's the first step. The second step is you pay for the exam. Once you pay for the exam, you have up to 1 year in order to register for the exam and take the exam. So, once you pay for the exam, once you have done the preparations, you will register for the exam for a specific slot, and then you take the exam, okay? So, that is the application and exam process. The application fee uh if you are not a member of IIBA, the application fee is $145, $45, which is the same as that of a member, but the exam fee is um $505 for a non-member and $350 for a member. Now, even if you are not a member, check within your organization. Some of the organizations have memberships and tie-ups with IIBA, where you will get a discount on your IIBA uh exam fee, okay? So, that's the uh application fee. If you are uh getting recertified, so like I I did my certification in 2019, every 3 year you need to get uh recertified. I got recertified in 2022 and then again last year. So, when you get recertified, if you're a member, you need to pay $85. If you are not a member, you need to pay $120. The reason this is important is if you look at the difference between the fee for a member and a non-member, it is roughly $150, right? There are uh some places where the membership will be much cheaper, like in India, for example, where I was taking the exam, it was around $50 or $55 or something like that. So, it worked out cheaper for me to take the membership and then uh give the uh exam or give the certification. How do you prepare for the exam? So, we will go through the BABOK Guide throughout the course, but you need to read through the BABOK Guide. You should be very comfortable with the BABOK Guide. Uh there are some material available in the online library in the IIBA website. Go through that. Go through the FAQs in the IIBA website. There are some other resources that are suggested by IIBA. You can go through that. Um you can try to find a mentor. There are study groups that you can find within IIBA clubs. Um and then uh you review you the one step is I will definitely suggest is especially for those who are planning for CBAP exam is take the uh Simplilearn um test very seriously. Uh they are uh slightly on the tougher um side than the actual IIBA exam. So, if you if you do decently in the uh uh Simplilearn exams, you are likely to uh do well in the CBAP test. The exam consists of 120 questions. All of them are multiple choice. Uh it is a uh 3 and 1/2 hour test. Okay. Now, what does the exam has? There are like I said there are six knowledge areas. Each Each knowledge area has a certain weightage. You can see that on the screen. Uh you can see for example requirement analysis and design definition, which is a key knowledge area for uh business analyst has highest weightage weightage at uh 30%. Uh and then the rest is roughly equally distributed. Um but we we will go through each of the um uh domain or each of the knowledge areas in detail. Any questions on the certification before we pick up uh the pre-certification? I can see there are right here the assessment that we write here in Simplilearn and the IIBA affiliated CBAP are Um the assessment that you have within Simplilearn will give you the Simplilearn certificate. That is not the IIBA certificate. For the IIBA certificate is where you have to register within IIBA and provide the exam and pass it. That is when you will get the IIBA CBAP. If you like I said, there are two parts to that answer. I already, I think, covered that, Sultana. You need to check if you already have some experience, you need to see as we go through the knowledge areas. If part of those experience can be claimed as business analysis experience, that might be one way where you might have enough experience. But even then, if you don't meet the eligibility criteria, then obviously you cannot give the IIBA CBAP exam. You still If you still want to have the certification, you can look for CCBA or ECBA, depending on your level of experience. Or if you are looking for a job as a BA, you can use the Simplilearn certificate and the experience and the knowledge that you gain in order to in order to look for jobs where you can have an entry-level BA kind of a position. Uh who can be the referrer? Uh no, it could be somebody at somebody who have known you in a professional capacity, Nikit. Anybody who who has known you in a professional capacity can be a referrer for you. Our certification uh mandatory? No, certification is not mandatory. Take this point to talk about how I got into business analysis. So, I I joined um long time back, I think. I joined one of the software consulting companies based out of India. I worked there as a software engineer for 4 and 1/2 years. Then I did my MBA. Post MBA, I joined a banking company in their operations. I was working in their operations for close to 2 years. and there was a project that I was supposed to support which I supported for around 6 months. And I was using my domain knowledge to help provide requirements to the business analyst there. And then I asked the team they wanted to have a new BA there because I think the BA was leaving or something like that that I would like to take up that opportunity because I have the domain experience and I have like this past experience in software development. And then I convince them that they they they hired me as a BA and then that's how I got into BA. At that point I did not have a business analyst certification. I worked for as a BA for I think almost 6 years before I took the certification. So you don't have to be certification to get into a BA job. What you need is the knowledge and skills and you need to convince an employer that you have them in order to get into that job. Um if you have experience in QA Harris, you can use part of that experience as a BA. So that's what we call as transferable skill. Okay, now IIBA, once you get certified they want you to do a recertification, right? The the goal of recertification is that they want to make sure that you not only get certified, you continue to develop yourself as a BA, learn new new things, you work as a BA, you contribute to the BA community of practice. So that is why there is a recertification program, right? So every 3 year you need to get recertified recertified, right? The purpose is to make sure that there is ongoing professional development encourage learning, make sure that there is certain amount of standards that is being met. Um so all those things are the reason why we have recertification. How do you get recertified? You you have six CDU categories. It's formal academic education. You can attend some course. What is known as professional development, professional activities. There are self-learning. You can read some books. There are some online courses that you can attend. There are volunteers volunteer services, professional experience. Each of these might have limited CDUs that you can claim. But essentially, what you do is you list the number of hours that you spend in the last 3 years in each of these CDU categories and it should add up to 60 CDUs and you report that to uh IIBA. Yeah, and you provide contacts you can verify that you have completed these CDUs. And then you pay the fee. That's when you get the IIBA recertification completed. Okay, with that we complete our very first lesson. Thank you for your cooperation. Congratulations. What did we study? What did we learn? So, IIBA is the organization that sets standards for business analysts. Um it defines what is known as the BABOK. It defines the competency model and it also comes up with the set of certifications which will recognize your professional competence. If you have a membership with IIBA, there are some benefits. If you complete CBAP, there are some benefits both for you and for your organization. Uh in order to prepare for the CBAP exam, you need to be very familiar with the BABOK Guide. You need to review the FAQs on the IIBA website. You need to go through training, have a mentor, join a study group. We looked at how to apply for the exam. We looked at the exam eligibility criteria. We looked at the exam format, the exam blueprint, sorry, blueprint and the recertification process as well. With that, we completed our first lesson. So, what are we going to cover in the rest of the class today? We will look at what is business analysis. We will look at a definition of business analysis. Um we will look at what does a business analyst do. We will look at the business analysis core concept model. Uh we will look at the knowledge areas. Uh we will look at the different types of requirements. We will look at requirements and designs. We will look at a list of competencies that a business analyst should have. Uh we will we will not go through in detail. We'll we'll just look at the techniques. Right? There are 50 techniques. It will take us the entire course to cover all of them. So, we won't go through them in detail. We will take a look at the techniques just so that you know that there are 50 techniques. Uh we will look at the perspectives. We'll go through the perspectives briefly, but not in too much of detail. Because again, we will cover them in detail in uh in the future classes. Okay. Now, one of the biggest problem that we have, especially when it comes to developing and implementing software, is lack of clarity of what is it that we want to build. Right? You can see some statistics on the screen. A number of software projects are failed because the requirements are either poor, they are not clear, they were ambiguous. There is a large number of large amount of effort that is wasted because incorrect requirements were provided and they had to be corrected. A lot of money is being spent in fixing requirement errors, which becomes a major part of the rework that is involved in in in software development. Now, how can we fix these problems, which is where you need to do business analysis with a set of standards which are defined by the business analysis body of knowledge so that we have better business analyst who will then capture better requirements. Which means better software products are being created. Okay, we will look at the key concepts of business analysis. Who is a business analyst? Business analyst core concept model. Knowledge areas, requirements classification, requirements and design, and who is a stakeholder. First question, what is business analysis? Bridge between stakeholders and tech teams, analyzing requirements, forecasting through business artifacts, okay. Bridge between business and IT, that's that's a very good definition. Uh client and software people who helps to place the client requirement, yeah, exactly. Enable change, yes, BAs are the ones who enable change, define needs to solutions, enhance value, yeah. Identify business needs and recommend solutions, that's very good, Ashish. Uh business research, BAs do business research, finding the root cause of issue, find solutions for improvement, yes. Uh business needs and providing solutions to address business problems. Okay, a number of good responses. Uh the textbook definition, I think some of you almost gave the textbook definition, which is that a business analysis is the process through which you enable the change, right? So, there is a change that needs to happen, you enable that change. How do you enable that change? By defining the need and by recommending solutions that will address that need. Right? I'll repeat. Business analysis is when you are enabling a change by defining the needs and recommending solutions. But then the question is then what do we mean by change? What do we mean by need? And what do we mean by solution, right? We will see that in a minute. What do business analysts do? Business analysts perform the tasks that are described in BABOK Guide. They identify information. They speak with stakeholders. Many of you said they are the bridge between business and technology. So they speak with business teams in order to understand their business problems, their aspirations, their goals. They elicit these from their business stakeholders. Uh they will then Somebody gave the example of root cause analysis. They might investigate a little bit further to understand what is the underlying causes of the stakeholder um dissatisfaction or the stakeholder problems and then identify what needs to be done, right? That's what a business analyst do, right? So they basically try and understand what is the problem that we are trying to address or what is the opportunity that we are going to uh benefit from? How can we What What is the reason why that problem exist? What are the the root cause of that problem? What is the root cause of that opportunity? How can we implement a change or a solution in order to benefit from that opportunity or in order to address that problem? That is what a business analyst is. Okay? Now what we will do is we will try and go through the key terms or what is known as the business analysis core concept model so that we have a changes we have a common understanding of these terms that we will use throughout the entire course for the next 9 days. The first is change. Okay? The change is the act of transformation in response to a need. Okay? Let's take an example. Let's say I will use deliberately a non-technical example for for everybody to understand, right? Now, need is a problem or an opportunity. Let's take a very non-technical example to understand what a need is, right? I live in Bangalore, right? If you have been to Bangalore or if you know somebody in Bangalore, they will tell you one of the biggest problems in Bangalore is traffic, right? If you were to travel through traffic, if you were to travel through Bangalore, you are likely to get stuck in pretty bad traffic. So, that is a problem, right? The problem that we have is the bad traffic in Bangalore. So, we are unable to go to our office every day because it takes us 2 hours to cover 10 km of distance in Bangalore. So, the traffic problem is our need, right? We need to address the need. Now, what are the solution? What is the solution? Solution is a one way to satisfy the need, right? Now, what are the different ways in which you can address traffic problem in Bangalore? One is we can try and improve the public transport in Bangalore. Um so, we can So, they are building metro in Bangalore. So, the metro lines can be a way to address the the traffic problem. Uh they can improve the bus network. Uh they can Uh another solution can be they can charge a congestion charge for some of the highly crowded areas in in the more central areas. Uh another solution can be they can implement uh car pooling, right? Another solution can be the organizations in Bangalore can come together and agree that they will um they will provide more work from home options for their employees. So, each of these is a different solution that can address that particular need. Right? Now, let's say a one particular solution. Let's Let's say we go with public transport, right? What does that mean, right? So, today we have certain level of public transport. We need to go to a level of public transport where everybody can comfortably travel from one place to another easily, comfortably without having to use their personal transport. So, that requires a number of things to be put in place. So, you need to have metro lines, you need to have better bus transport, you need to have last mile connectivity, you need to have places where like if it is a short distance like a kilometer, you should be able to walk, right? That entire transformation of going from how the city is currently to how the city is to be in the future where you can essentially go anywhere either walking or through public transport is the change. It involves possibly multiple solutions. It involves adoption of the of that solution as well, right? It is one thing to say that, you know, you you implement say for example a metro line, but people are like, "Okay, everybody else go by metro. I will continue to go by car." Right? That is not going to solve the problem. So, you need to drive that awareness and that adoption as well. So, that's basically change or that is the act of transformation in response to the need. Okay? Now, there is three more things. The first is that we will cover is a stakeholder, right? Stakeholder is somebody who is related to the change, need, or the solution, right? So, if you take again the traffic problem in Bangalore, the need everybody is related to the need, right? The entire public of Bangalore the the entire The of Bangalore is related to that problem. So, they are the stakeholders. Solution, people who build metros, people who BMTC, which is the best operator in Bangalore, the metro operator in Bangalore, they are all stakeholders. The government, they are all stakeholders for the solution and for the change. Right? So, those are the stakeholders. Then, what is context? Context is the circumstances that influence the the decisions, the solutions. Like, in the case of Bangalore, the circumstances are that it is a very rapidly growing city, right? It is often called the Silicon Valley of India because of the large number of technology companies in Bangalore, and they are still growing, right? Because they are still growing, often what happens is that the infrastructure is unable to keep up with the pace of growth, right? So, when you plan for the future, that context should be kept in mind, right? You should keep in mind that this is a rapidly growing city. So, if you assume that the city will grow at a very like the the growth will stop. You cannot plan when you are planning for the infrastructure, you cannot plan for the current city. You have to plan for the city in 5 years' time, right? And in 5 years' time, it would be probably double or triple the size depending on what growth rate you are going to provide, right? So, that is the context. Okay? So, context are context is basically the circumstance that is going to impact the change that you're going to implement. The last is the value. Value is the usefulness of a change to a stakeholder within a context. So, in Bangalore, it could be the ability of people to save maybe 2 hours of travel every day, amount of reduction in pollution, it could be reduction in fuel expenses. So, number of different values can be attributed to a change. So, value is the worth of a change to a stakeholder in a context. We will look at a few more examples. But can you see a PDF document? Okay, let's look at a couple of more examples. So, we saw the core six core principles, right? Let's look at an example. So, there is a bank. The bank wants to launch a mobile banking app. Change. What is change? Change is a transformation from current state, which is the as-is state, to the future state, right? What will be the change? Moving from a branch-based service to a digital mobile banking. Replacing existing manual loan approvals with automated approval system. So, these can be examples of change. What is need? The customers of the bank are often waiting long hours in the queue in the branches. There is high operational cost because you need to maintain the branches. The competitors offer better digital services. So, you are better off going to a different bank than your current bank, right? So, these are the problems or opportunities that is motivating the change, which is moving from branch-based service to a digital mobile banking. What is the solution? Develop a mobile banking application and implement an automated loan processing system. So, these are solutions that you can implement. Who are the stakeholders? Customers, bank employees, IT team, compliance team, management. So, these are all stakeholders for the mobile banking example. What is the value? Customers will get 24/7 banking access, reduced operational costs, faster approvals like for things like loans, better customer satisfaction. These are all the value that the change can deliver. Now, what is the context of this, right? So, banking is often very highly regulated. So, you need to be in compliance with regulatory requirements. You need to make sure that the cybersecurity is taken care of. The fintech market is very competitive, so it is there is an opportunity cost if you do not implement the mobile application. Right? You might have an existing core banking system, so you might need to think of ways in which you can integrate with it without which you will not be able to have the solution adopted and implemented. Okay, we will look at one more example before moving on to the next topic, which is hospital hospital management system. We'll use these examples quite a lot in all of our in all of our sessions going forward. So, basically, imagine a hospital where you are using a paper record for maintaining patient information. They are moving to a digital system. The need is to reduce patient wait times and errors. Solution is the hospital management software. There are a number of stakeholders. Value is faster services, better care. Context is healthcare regulations and budget limits. Okay? Okay, so that is the business analysis core concept model. We will continue to see this in the future. We will see again these six terms. Make sure that you understand them. Okay, now we will take a look at the six knowledge area at a very high level. Okay, so the first knowledge area is called business analysis planning and monitoring. Before you do anything, you need to plan. Correct? Let's say you want to clear the CBAP certification exam. Right? What will you do? So, you will create a plan. How will you create a plan? You will look at okay, what are the things I need? I need you know, 7,500 hours of experience. Do I have that? Yes. Okay. I need to document the 7,500 hours. Okay. How much time is it going to take? Okay, it will take me a week. Okay. So, first is to document my experience. Then I need to get the the PDUs, the the professional development units. What do you do? I have to attend the Simply Learn CBAP course. Okay. So, let me sign up for that. The course will be from this day to this day. So, that's the second activity. The third is Okay, I need to read the BABOK Guide. So, I'll go it will take me you know, I don't know, 2 months to read through. Okay, so I'll read it from this day to this day. And then I will review the material from Simply Learn, which will take me this many times. So, it will go from this day to this day. And then I'll give some mock tests. And then I will do some revisions. So, you will basically create a plan, which might be, let's say, from 6 months from today, I want to give the CBAP exam. In order to make that happen, I need to take these steps. These are This is my plan. These are the activities. This is the support I need. This is the money I need. This is a the people whom I reach out to for mentoring or whatnot. Right? This is what you do before you take out take over take take up any activity, essentially, right? If you were to apply for a job, what you do is Okay, so this is my I need to get my CV ready. I need to realize what kind of job I want. I need to understand what skills I want I have. I need to maybe attend some sessions. So, these are the kind of planning that you do before any activity. You need to do that before business analysis as well. So, business analysis planning and monitoring is the knowledge area that talks about the organization and coordination of activities that needs to happen before you do business analysis, and the performance assessment that happens after you complete the business analysis. Okay? So, we will see a few tasks. There are five tasks. All of them are related to organizing and planning for the the business analysis activities as well as for getting the feedback once the activity is complete. Elicitation and collaboration, right? So, in business analysis, you need to get information from your stakeholders, right? It could be what is their problem, what is their need, it could be what are their goals, it could be what is what is that happening today, it could be what is it that they want to happen at the end of the change. So, you need to get a lot of information from your stakeholders. So, that involves certain tasks, some techniques, some some approaches, some tools. So, all those are covered under this knowledge area, which is elicitation and collaboration. It also talks about how are you going to communicate the information that you collected from your stakeholders and make sure that you engage with them on on an ongoing basis. Okay? That is elicitation and collaboration. Now, you collected you planned for your business analysis activities, you collected some information from your stakeholders. You need to document that information. You need to make sure that when you document, you document it in such a way that it is available throughout the life cycle of your project as well as the solution that you are going to build, right? And as long as the solution is is being used, your the information that you gathered should be maintained and should be available for people to refer to. The requirement life cycle management knowledge area covers the tasks that you are going to use in order to maintain that information throughout the life cycle of the of the solution. Right. Now, we we we looked at the three business planning, monitoring, elicitation, and requirement life cycle management. What you need to do is also look at the bigger picture, right? Why are you doing the change? What is the need? What is the current state? What is the future state? What needs to be done in order to go from your current state to future state? So, that big picture strategy is being done in strategy analysis. Okay? So, this is This is a set of tasks that you are going to perform in order to understand the business need better, the business goals better, the the strategy that you're going to go from current state to the future state, and to define the current and the future state. This will then lead you towards requirements analysis and design definition, where you will then break down the business need and the business goals into more detailed requirements that can be then modeled, specified, uh understood, validated, and verified, and then can be used by your development team to convert into solutions. And then finally, once some sort of solution is in place, you need to make sure that your solution is delivering the value it was expected to deliver. If it is not delivering the value it was expected to deliver, you need to understand why and come up with a set of recommendation in order to increase the level of value realization. Okay, I know I went through them slightly quickly, but we will cover each of them in a lot of detail. Um and and and we will we will um go through them in detail in in in the future session. But, I will take a look at Okay, let me cover the relationships between the knowledge areas, then I will uh take questions. Um the business analysis planning and monitoring, requirement life cycle management, and elicitation and collaboration are the overarching knowledge areas. So, they are used in all of the remaining three, right? The remaining three are iterative activities that basically kind of follows a sequence. So, you start with the strategy analysis where you define the need and the business goal. Then you break down that into detailed requirements, you model, specify these requirements. Then the solution is built. The solution when the solution is built, you actually some you have some actual value that is delivered. That actual value is then evaluated in the solution evaluation. That will result in further needs that will then feed to strategy analysis and then that will iterate until we have uh met the solution value that you you were expecting to meet. Elicitation and collaboration is used in strategy analysis to understand current state, future state, to understand the business need, all those kind of stuff. In requirement analysis and uh design definition, to go through the detailed requirements, to review the the the requirement models, the specifications, all those kind of stuff. Uh in solution evaluation to understand how users are using their um solution. Requirement life cycle management is used to store information that is gathered from all of these three um stages. Business analysis planning and monitoring is used to plan these activities and to get feedback once these activities are completed. Okay. So, I'll take questions before we move on to the requirement classification schema. Uh does context impact the solution more than the need or the solution can still the need when context is uh No, you need to consider both. So, the the goal of the solution is to address the need, right? You are going to um your need is the traffic in Bangalore. So, your solution should address the traffic in Bangalore, right? The context is that this that Bangalore is a growing city. So, you cannot use the context to define the solution. Bangalore is a growing city can result in a number of different solutions. That is not That is not the goal of the project. The goal of the project is to address the need. The goal of the change is to address the need. So, the solution should satisfy the need, but it should keep in mind the context, right? It It is It is like saying I I'm not sure if all of you are familiar with cricket, right? Um the goal, if you are playing cricket, is to score more runs than your opposing team, right? But, you will use different approaches when you are playing a test cricket versus a one-day 50-over match versus what is called a 20/20 or a T20 match, correct? Because that is the context, right? The kind of match is the context. But, the goal is always to score the maximum number of runs without losing as many as much wickets as as you can, right? Hopefully, that makes it clear. I know it's a little bit of a clumsy example. I'm not sure if all of you are familiar with cricket, but but essentially, context is what you bear in mind while you are trying to address the need, okay? Context is the environment, right? Goal or need is the specific thing that you are trying to address. It's a problem or it's an opportunity, right? Uh like for example, um a problem can be that you are You have an online portal where you are trying to sell t-shirts, let's say. You are not able to sell enough t-shirts. You People are coming to your site, but they are not buying t-shirts, right? That's a problem, right? So, you are trying to find out a solution to address that problem. Now, the context is that it's an online shopping uh portal. There is a lot of competition and people often browse without making a decision. Conversions are generally low. So, these are examples of the context that you need to keep in mind while you are coming up with the solution. Okay, we will move on to the next topic which is requirements classification. What do you understand by requirements? Information, okay. Written request with specification for change, okay. Need. Need is a requirement. Yes, that's correct, Vidya. Okay. So, requirements are basically what is that you want to achieve so that a certain goal can be met. Okay. So, there are different types of requirements. You have business requirements. Business requirements are the high-level goals or high-level objectives or the outcomes that you want to achieve. For example, I want to reduce the traffic in Bangalore would be a business requirement, right? I want to reduce the uh number of people or I want to increase the number of people using mobile application for transactions by 10%. That can be a business requirement. I want to reduce patient wait time by 10 minutes on an average. That can be a business requirement, okay. So, business requirement is the goal or the outcome that you're trying to achieve. Once you have the business requirements, you need to break that down into stakeholder requirements. Now, who are your stake We will look at what stakeholders are in later in the session, but stakeholders are basically people who are related to your change, need, or solution. So, if you take the example of traffic, your stakeholders are your travelers, your um your public, your uh bus operators, uh the metro operator, the government. Now, each of them will have different goals. What is the goal of the traveler or the uh the public? They want to travel uh comfortably uh at a cheap rate and quick. Right? So, that's their goal. What is the goal of a bus operator? They want to run uh an efficient and profitable business uh of running uh buses. Right? What is the goal of metro? They want to run a uh again, a profitable metro business. What is the goal of government? The government wants to provide the best services to the um people. Right? So, these are the stakeholder requirements. Then, you have what is known as solution requirements. The solution requirements define what should the solution do, okay? They can be two types. The first is called functional requirements. So, functional requirements are basically the behaviors of the solution or the system. Non-functional requirements are what are known as the performance indicators, okay? Behavior could be that I want to be able to walk to any place within 10 Sorry, within 1 km from where I am in Bangalore. At any place, 1 km from my place, I should be able to comfortably walk. Right? So, in order to achieve that stakeholder goal, you need You should have all all streets should have um well-laid sidewalks, right? Or footpaths, right? That's an example. Uh the street should be tree-lined so that you don't get uh exposed to too much of sunlight or you don't get, you know, hot. So, these are solution requirements. Now, you can have non-functional requirements as well, right? The street the sidewalks should be at least 3 ft wide, right? The the best transport should have this many number of seats or this kind of safety requirements. All buses should be equipped with a emergency door. So, these are not behaviors, these are performance attributes. And then finally, you have transition requirements. A transition requirement is when you go from your current state to your future state. Once you are in the future state, you don't need transition requirements. So, building bus depots is an example of transition requirements. Uh building uh bus lanes, building metro is again another example of a transition requirement. So, that's basically the three types of sorry, four types of requirements. Business requirements, stakeholder requirements, solution requirements, which includes functional and non-functional requirements, and transition requirements. Let's look at some more examples. Hopefully, you can see the PDF file. Business requirements, high-level statements that describe the business goals, objectives, outcomes that the organization wants to achieve. Examples, if you take a patient management system, we want to reduce patient wait times by 30% within 6 months, right? That's an example of a business requirement. Enable online appointment booking booking to improve patient experience. Ensure compliance with health care data privacy laws. HIPAA. HIPAA is an is a law, I think, in the United States, which deals with privacy laws on in in health care health care context. Right? So, these are examples in a hospital management system or a patient management system, um uh implementation. If you take an internet banking example, increase active users by 20%, provide 24/7 access to the banking services, reduce call center inquiries by 40%. So, these are examples of business requirement. Now, let's look at the same for um stakeholder requirements, right? So, stakeholder requirements are for specific stakeholders. If you take the patient management system, the receptionists need a fast way to register new patients without duplications. The doctors need access to their history. Patients want SMS reminders for appointments. Billing clerks need an automated bill generation. So, these are examples of stakeholder stakeholder requirements in this uh context. Intern- if you take an internet banking example, customers the uh banking app should be intuitive, right? They should be able to figure out how to use it without guides and stuff like that. Bank bank tellers should be able to verify things from back end. Security officers needs audit trails so that they can treat uh they can track in case of any issues. Uh customer service representatives might want a dashboard. So, these are examples of um stakeholder requirements. Now, we will look at solution requirements. You have functional requirements. In patient management system, you you are allowing patients to register through mobile app, web portal, or a kiosk. You're enabling doctors to update patient health records. You automatically send appointment reminders. Generate invoices. So, these are all things that the system should do or the solution should do. So, that is solution requirement. If you look at the non-functional requirement, the system should appro- support 500 current users. The data should be encry- encrypted. The system must have a certain percentage of uptime, right? If you look at the internet banking application example, users should be able to log in with multi-factor authentication. They should be providing fund transfer functionality. Real-time account balance should be there. Lock or unlock debit card or credit cards instantly. Non-functional requirements, load within three three seconds. 10 minutes of inactivity should result in sessions time out. 1 million daily transactions. So, these are non-functional requirements. What are transition requirements? Examples, if you are implementing a patient management system, the hospital staff should be trained on it before two weeks. Two weeks before go live. Existing patient records, which are in let's say in a book or in a paper and pen format, should be moved to the new system. Um there should be some kiosks for users to self-register at the hospital lobby. Uh set up a help desk. Okay. And then um if you take the internet banking example, you need to migrate existing customer accounts 24/7 customer support after six for six months. Security training for bank staff. Phased to launch beta users before full release. So, these are examples of transition requirements. So, in order to sum up, um business requirements are high-level goals. Stakeholder requirements are requirements for or needs of specific users. Functional requirements are system behaviors and features. Non-functional requirements are the performance and constraints of the system. Transition requirements are what you need to implement in order for you to go from your current state to your future state. But once you are in the future state, they are not relevant. Okay, so we are going to look at a business requirement document. Um so we are looking for the patient management system in a hospital. We are implementing a system for uh registering, tracking, booking, and all those kind of stuff. What do you have? So first you have an executive summary. The hospital so which basically talks about uh why you are implementing the project, what is the objective of the project, all those kind of stuff. Highlight business objectives. Right? You provide some background, what is happening currently. You define the scope. You provide what is out of scope. You identify the stakeholders. And then you call out each of the business requirement in detail. You might call out any assumptions, constraints, or risks. You will call out the success success criteria and then attach any appendixes that you might be there. So that is business requirements. Now the most important thing is the requirements that you have here would either be business requirements or stakeholder requirements. You do not have solution requirements in your BRD, okay? Now let's look at functional specification document for the same thing. A functional specification will more be focused on the system, not on the business requirement. So it will provide, you know, um details of what the system will do. It will provide details of users and accesses. It will provide the functional requirements. This is from the perspective of the system. Okay? And then you will you might have details like integration, you UI UX requirements, and any validations, any non-functional requirements, any assumptions, and any of the other details that is there. Okay? So, that's on the functional specification document. And last, you have what is called a software requirements specification. Yeah. So, the software requirements specification will focus on um functional and non-functional requirements or the solution requirements um where you will look at the scope uh which will be for your um specific audiences uh the definitions the details the roles and the uh details of the solution that you are going to build. Again, it will also focus on functional requirements. So, you will either create a FSD or an SRS, you won't create both. So, we have three documents. Uh you have what is known as a BRD, the business requirements documents uh which has both business and stakeholder requirements. You have the functional specification document or the solution requirements specification, which will have the actual solution requirements, both functional and non-functional requirements. We will cover this last topic. What are the What is the difference between requirements and and right? So, let's say you want to build a house. What do you do? You will hire an architect, and what will you tell him? You will basically tell him that I want to build a house. I need three bedrooms. I need a living room. I need a kitchen. I need a dining room. All my three rooms should be attached. It should be only a single floor. I need a car porch where I can park my car. Yeah, so that's my requirement, right? The room should be fairly big. You provide and then I want a room I want a house which is very airy, so there should be a lot of uh sunlight and wind and whatnot, right? So, it should be it should be the Those are your requirements, correct? So, you provided the number of rooms, the size of the rooms, uh the number of bathrooms, the the other specifications that you have. What will the uh architect do? He will draw a plan for your home, uh which will basically will have the number of bedrooms that you have asked for, the number of bathrooms, blah blah blah. And then he will show that. So, that is a design. What you first explained to your architect is the requirement. He will draw a plan and show it to you. That is the design. You will look at and you will say, "Okay, I need some changes. Okay, you have kept it like this. I want these these these these changes." So, he will make those changes. He will again show it to you. You will look at it and say, "Okay, no no no, I need few more changes." And eventually you both arrive at a final design, which is when you start building and um completing the house. The same thing is applicable for your requirements and design cycle, which is you first come up with the requirements. That requirements will be used to define the design. The design is then presented back to your stakeholders. They will then review it, and they might say, "Okay, I know I told you this requirement, but looking at your design, I now think that this is what you should do." So, you might tweak the design a couple of times, and that is when you finally arrive at the design. And this is not When When we say design, it is not a technical design. It's a business design, right? You have a problem. What is the business design that is going to solve that particular problem? The requirements are focused on needs, and the design is focused on the solution. They are done in a recursive fashion. So, you first create requirements, then you create design, then use the design to review the requirements, and then you probably update the design, change the requirements, go through this a few cycles. Finally, you agree on a particular set of requirements and designs. Okay? Okay. So, the next topic is stakeholders. Um So, a stakeholder is, like I said, the formal definition is that a stakeholder is someone who is related to the change, solution, or need. But, in essence, stakeholder is somebody whom are you are likely to interact with on a regular basis as part of your project or initiative or change. These are the common categories of stakeholders that you will you will encounter in in any project. You can see the first So, business analyst, that's yourself, is at the center of the whole thing. The five stakeholders in orange on the right-hand side of the slide, they are internal to the project. Then you have another five stakeholders who are represented in the light blue shade on the left-hand side, they are external to the project. Let's talk through what each of these are, right? So, if you look at domain SME. So, domain SME is SME stands for subject matter expert. So if you are implementing a project in which you are implementing let's say a mobile banking application, the domain is banking, right? So an SME or a subject matter expert is someone who is an expert in banking, right? So domain SME is somebody who is expert in the business that you are trying to solve a problem for. So in case of a patient management system, it is somebody who is familiar with hospital industry, right? In case of traffic management, there could be people who are experts in traffic management. So domain SME is somebody who is an expert in the business that you are trying to solve a problem for. Then you have tester. So tester is the person who will validate the solution to make sure that it meets the criteria that has been requested by the stakeholders. Okay? So tester does testing, right? I think somebody mentioned that they have been doing QA, which is another term for testing, quality assurance. We are making sure that the solution that we are going to build is having sufficient quality, that it work as per expected. So that is done by tester who's a stakeholder within the project. Then you have operational support. Once your solution is implemented, it needs an ongoing support. That is carried out by operational support. Can anyone tell me, why do you think the operational support is a stakeholder in a project, right? Okay. Then you have implementation SME. SME again here stands for subject matter expert. So what is implementation? Implementation is a is a solution implementation, right? So, you're implementing a solution. So, an implementation SME will be somebody who is an expert in the solution that you're implementing. So, it could be a lead developer, an engineering manager, an engineering project manager, a lead technical BA. So, they can have different titles, but essentially, the definition is somebody who is an expert in the implementation of the solution. And then you have a project manager. So, what does a project manager do? He is responsible for the end-to-end delivery of the project. So, he plans, organizes, assigns, manages stakeholders, manages budget, timelines, scope. All those things are done by the project manager. So, those are the five internal stakeholders for business analysis activity. For efficiency and reliability, operational support is needed. That is correct. Cuz they know the operation. That is correct to validate. Right. So, if you have a solution already in place, what happens is that operational support can provide you what are the most common challenges that users are facing when they are utilizing the solution. So, that can be invaluable input. So, operational support will have a lot of areas where they can provide a lot of input. Okay. Excellent. So, let's move on to the external stakeholder. Supplier. So, supplier is somebody who is providing an input into your project. Okay? So, this can be a solution supplier. So, for example, let's say you decide to implement what is known as an ERP or a CRM solution. So, ERP stands for enterprise resource planning and CRM stands for customer customer relationship management. So, ERP and CRM are already available off-the-shelf solutions that you can buy from the market. So, things like Microsoft or PeopleSoft or Oracle or provided SAP, they all provide ERP and ERP solutions. Let's take ERP as an example, right? So, for those ERP solutions, you need a supplier. So, the supplier is your your stakeholder who is an external party to your project. Then you have a customer. You have a customer and also an end user. What do you think is the difference between a customer and end user? Customers are clients, okay. For banking, customer can be a client and end user can be cashier, yes. End user is going to use the solution, yes. You are very much bang on point. So, customer is the one who uses the products and services of your organization and the one who is actually, you know, rewarding you most most of the times using money and sometimes in other ways. But essentially, they are the ones who are consuming your products and services. So, if you take a bank, customers are the ones who deposits money or takes loans or perform banking transactions. The bank clients are the customers. End users can be customers. So, for example, if you have an online banking solution, the customers and are the end users. But sometimes, the customers may not be the end users. So, if the system is being built like somebody mentioned for a cashier in the bank, the end user is the cashier, not the customer, okay? So, some in some scenarios, end user will be different from the customer. Who is an end user? End user, like many of you said, is the one person who is not the one person. End user is the one who is actually using the solution that we are going to build. Okay? So, customer and end user are two other external stakeholders. Then you have sponsor. Typically, in organizations, when you have a project, it requires what is known as a funding. What is funding? Funding is you need to allocate a certain amount of money for the project, right? Or the initiative, right? Um that funding or budget needs to be secured by a senior individual or senior executive, right? Because they need to present the case that if you implement this online banking solution, that will help the bank achieve, let's say, 20 million dollars of additional revenues in the next year. So, they need to make that case and get that money. So, those are the people who become sponsors. So, they are the ones who are sponsoring the project. Okay? So, they they support you in delivering the project. So, sponsor is the one who is providing the required organizational support in the form of budget, funding, uh senior management decisions, etc. for you to move forward with your project. The last is regulator. Now, regulator is an external stakeholder who regulates the industry in which you are operating. Okay? So, depending on the industry, there are a number of different regulators. So, for example, if you are somebody who is involved in the US stock exchange, there is a regulator called SEC. Okay? Securities Exchange Commission. So, you need to adhere to their regulatory requirements. If you do not, then you might be fined for breaching regulatory requirements, right? If you are an airline in the US, you need to adhere to the regulatory requirements put out by FAA, Federal Aviation Agency. So, if you do not, then your license could be revoked, you might be penalized, right? So, if you are going to implement a new change in a particular context, you need to make sure that you understand who is the regulator in that context and what are their regulatory requirements for the specific project that you are implementing. So, that is the last stakeholder who is external stakeholder. So, we have five internal stakeholders, stakeholder groups, and external five external stakeholder groups. Customer, so for any organization that you are doing the work for, there is one set of users who are using the products and services of the organization, not the specific solution that you are building, not necessarily the specific solution that you are building, but the products and services offered by the business. If you take the example of a hospital, customers are patients. Correct? Because they are the ones who are enjoying the benefits of the health care that is provided by the hospital, right? If you take the example of If you take the example of a of a bus operator, customers are the passengers, right? Because they are the ones who are enjoying the benefits of the product that is offered by the bus operator. If you are taking the example of a bank, the the customers who make deposits, withdrawals, loans, credit cards, debit cards, so they are the customers. Because they are the ones who are consuming the services and the the product and services offered by the the bank, right? That is the customer. Most of the time, they are the ones who essentially end up paying as well. Like if you are a if you are a patient in the hospital, you are the one who is paying, right? Now, the reason why that is important is end user is sometimes the customer. Like if you are using a bank internet application or a bank mobile application, you are an end user as well in addition to being a customer. But, there could be systems within a bank which are used by internal bank employees. So, those bank employees are effectively the end users. They are not the customers, they are the employees, but they are the end users, okay? Uh if you take the example of ERP, I might buy an ERP solution from you, so I am the customer. But, the ERP solution is used by either my clients or my employees. So, they are the end users. So, there can be different scenarios where customers and end users can be different. Okay, so there are six categories of competencies. So, the first is analytical thinking and problem-solving skills. Second is behavioral characteristics. Third is business knowledge. Fourth is communication skills. Fifth is interaction skills. And the last is tools and technology. So, we will look at each of these groups in detail. First is analytical thinking and problem-solving. Okay? So, this is so business analysis, as the name itself suggests, is an analysis activity. Now, what is analysis? Analysis is your ability to break something down into smaller chunks and understand what is happening and come up with ways to solve problems. Okay? So, that is a critical competency for a business analyst. Now, there are a number of sub skills. So, you should have creative thinking. You should understand how to generate new ideas and new approaches to solve the same problem, right? You should be quick to learn. Again, uh you should be uh able to absorb information fairly quickly. Most of the times what happens is that uh you are put in vastly different projects. I have done quite projects where I had Initially, I had no idea what about the domain that I was working on. So, you will you will be expected expected to learn uh the business and the domain fairly quickly. So, ability to learn is a key uh skill. Conceptual thinking. What is conceptual thinking? Your ability to uh look at uh information that is presented to you and understand what are the first principles uh and understand what are the different concepts that are related to this particular problem and think in that those terms is conceptual thinking. So, and you should be able to have that conceptual thinking. Decision making. Again, there is a um there is a standard way in which you make decisions, which is uh We will Again, we will cover some of those techniques later on. But effectively, you will look at, "Okay, this is the problem. What are the different ways in which I can solve this problem? And what are the different criteria that I will use to evaluate these options?" So, that's kind of decision making. Problem solving. Uh Visual. What is visual thinking? You should be able to represent uh problems, uh solutions, processes, uh everything in the form of a uh visual representation so that you can communicate that easily to your stakeholders. And finally, system thinking. System thinking is there are different systems or people's processes and technology that interact with each other to get things completed. You should be able to understand that interactions better and and communicate those interactions so that you understand what are the boundaries of these interactions. How can we visually represent the concepts? Let's take an example, right? I think we already discussed a patient enrollment process. Okay? So, you are working on implementing a solution for a hospital. You go there and you talk to the people who does the enrollment of patients. They explain to you how they are doing it, right? Now, they explain to you that the patient comes to the hospital, we give them a form, they fill up the form, they come and they fill it up, they give it back to us. We enter that into the system and then create a an invoice, they pay the invoice and we complete the registration. Right? So, this is a process that we have understood from the staff. Now, you can easily represent this in the form of a flowchart. You can represent this in the form of a process map. You can represent it in the form of a use case diagram. Some of these techniques we will discuss in our future sessions. But, you should be able to at the very least you should be able to put it in the form of a simple flowchart. Step one, customer comes in fills the form. Step two, the staff inputs information into the system. Step three, invoice is generated. Step four, the payment is done by the customer. Step five, the payment reference and the receipt and the and the registration ID is handed over to the customer. or the patient. Right? So, that's how you visually represent the concept. Buddha. So, for analytical thinking, do we need to represent in the form of any tools to stakeholders in case of um the tools are not necessarily the most important thing. The representation is, right? So, you can you can use something as simple as Word or a PowerPoint, or you can use more complicated tools like Visio, Figma, etc. But, the the story and the uh narrative that you are able to communicate with very simple diagrams is the important thing, right? The tools are are less important than what is it that you are trying to convey to your stakeholder. So, if you were to explain a process to somebody, you can do that in an easily in a PowerPoint or in a Word document, and people will be able to completely understand that. Only if it is a very complex project where you have I don't know, you know, 200 steps, right? Um then you need more advanced tools like Visio, because, you know, there are so many back and forths and stuff like that, which might become slightly complex for you to represent in in in some of the simpler tools. But, 90% of the time, the process flows or the the visual representation will be simple enough to do in in simple tools like Word, like Excel, PowerPoint, etc. Okay? Okay. So, the second set of characteristics is uh behavioral characteristics. So, the first is ethics, right? What is ethics? Ethics is your um ability to stick to commitments and rules. Um so, basically, if you say you will start a meeting at 10:00, be there at 10:00, be there at 9:55. If you say you will complete a document on Friday, try and complete it by Thursday. Uh if you say, um you know, um I will uh spend some time reviewing this. Make sure that you spend some time reviewing this. So, that is how you basically develop that work ethic. And this is I think behavioral characteristics are not just for business analysis. For any work that you do, this is extremely critical and this will make the biggest difference than you can imagine than any uh technical skill that you have, right? Uh your ability to uh build that relationship with your stakeholders by being trustworthy, where whatever you promise them, you deliver. You be accountable. So, you say that I'm going to complete a pro- documentation, you know, in in certain amount of time, make sure that you do that. You say I will send an update on Friday, make sure that you send an update on Friday. Make sure that So, it also involves high levels of organization and time management. Because, let's say you need to create a BRD, right? You need to be able to understand how much time it is going to take. And then make sure that you also put in some amount of buffer for unforeseen conditions. And then uh commit to it. And once committed, don't waver, right? Make sure that you look at correct priority. And then as a BA, you will work in various different environments, right? So, you might work in work with people who wants projects to move at pace. You might work with uh teams where things are a little bit more laid-back. You should be able to adjust and adapt yourself to the environment where you are uh working on. Okay? I think behavioral characteristics are fairly straightforward. Let me know if there are any questions. If not, we will move to uh business knowledge. Okay? Uh business knowledge is nothing but domain knowledge. Uh you should be uh you should try and develop uh business acumen. Um you can if you if you can undergo some uh business trainings, that would help. Uh so things like how what is a balance sheet, what is revenue, what is cost, what are the different business models. Um so if you can understand that, that will help uh you to understand the problem that you're trying to solve better. If you have specific industry knowledge, that will help as well. So for example, I have always been working in banking. I've always been work within the corporate side of banking, right? So there is always the retail side of banking. But I work more on corporate side of banking. So because of that, I'm more familiar with than that than anything else. So that's industry knowledge. Someone else I know has worked her entire career in um uh aviation. So that's another industry knowledge. So having understanding of your specific industry, somebody who might be working in e-commerce might be uh expert in e-commerce. So having that industry knowledge is going to help you uh as a BA. Having organizational knowledge, right? If you are already working in a own organization, knowing how that organization works, what kind of processes, policies they follow, what management structure they follow, that can be uh useful. Solution knowledge. Um if you are working on a specific product, let's say you are are you are not you're working in finance, right? You're working on a specific system, but you are not working it in in the sense of a project or a business analyst uh activity, yeah? You are an user of that system, but you are an expert user on that system. So that can help you to understand uh business analysis activities better. The last is methodology, so knowing what kind of different methodologies are being used, so we will cover Agile versus um waterfall or predictive versus adaptive as as the BABOK refers to it later, but having that methodology knowledge is also quite critical. Now, um I think one of the common questions that I get, especially on the introductory sessions, is "How do I with so-and-so experience will be able to move to so-and-so in in in so-and-so industry would be able to move to a business analyst role?" And the answer is always capitalize on your domain, your business, your industry, and your organizational knowledge, sometimes even your solution knowledge, to move to a BA role. Okay, the next set of um competencies are communication skills. Uh the first is verbal communication skills. It is extremely important. The biggest impact that you will make is in your interactions with your stakeholders. You should be able to get information out of them, and you should be able to uh communicate ideas to them. Nonverbal communication will help you build your uh relationship with your stakeholders, which will make things like getting information, getting sign-offs, etc. uh much more uh easy. Listening is equally important, probably even more important, because most of all most of us don't know how to listen properly. So, listening can uh help a BA to capture information accurately. Uh traditionally, written communication is extremely important, but I think it is now becoming slightly less thanks to all the generative AI tools that are available. Uh it you can essentially rely on them to tidy up what you are writing, but you should have some amount of written communication skills as well. So, next we will look at interaction skills. So, the first one is facilitation. So, facilitation is the ability of a business analyst to moderate discussions within a group. So, a lot of the business analysis requirement gathering will happen in what are called workshops. We will cover workshops as a technique, but you should be able to facilitate that uh discussion, right? What does it mean to facilitate? You should be able to steer them in the right direction. You need to stay on the topic of discussion, avoid uh side track, side conversations, avoid digressions. So, that ability to keep the group on that point is facility is the key skill of facilitation. Uh leadership and influencing. As a BA, you will have to influence a lot of people over whom you have no power whatsoever. In fact, a lot of the people from whom you need things will be significantly more senior than you are in the organization. So, typically, you will be working with fairly senior executives. They will have to provide you information. They will have to provide you sign-offs. You need need to manage uh their um uh you know, conflicts much better. So, your ability to influence them is going to be a critical skill. Uh teamwork. Uh business analysis is a team uh effort. You need to work closely with uh the business teams, technology teams, uh your own project team uh very well. Uh negotiation. Your ability to agree how the uh requirements are going to be prioritized, how the uh requirements are going to be uh implemented will involve significant amount of negotiation. And finally, you will be expected to do a lot of trainings. Uh your ability to teach is going to be a critical skill as well. That brings us to the last set of competencies, which is tools and technology skills, right? Uh so, the first set of tools is office productivity tool tools. If you go and check the job descriptions set out by uh employees em- employers for hiring business analysts, you will see you should be well versed in Microsoft Word, uh Excel, uh PowerPoint, etc. as a as a requirement in most of them. So, you should be quite comfortable using these productivity suite of applications. Uh and then there are business analysis tools, tools such as Visio, um Figma, uh CorelDRAW. Uh there's a number of different modeling tools that you can use. You should be comfortable using those as well. Um and then there are finally there are communication tools, uh email, um your messenger applications, uh collaboration applications like SharePoint, uh etc. Your level of comfort with that can also help you to be a good BA. Okay, that completes our um section on competencies. Okay. So, we will take a quick peek at the techniques because there are 50 techniques. We will go through each of these as part of our knowledge areas. Um we will look at what each of these technique is. Uh we spoke about, I think, decision analysis and decision modeling. We spoke about stakeholder analysis a couple of minutes back. We spoke about process modeling and process analysis. Yeah, so these are some of the ones which we already discussed in terms of some of the techniques that we will look at in the future. But we will go through all these in in due course. The last topic for lesson two is business analysis perspectives. Okay, so first good point is what is a perspective? What is a perspective? So perspective is this very specific context in which business analysis activities are being carried out. Okay, so these are so in general we will talk about in the first part of the course when we speak about the knowledge areas. We are going to speak about business analysis in general which covers all sorts of scenarios. And then towards the end we will look at perspectives. So perspectives are specific contexts in which the business analysis activities are carried out. They are not mutually exclusive. For example, Agile and business intelligence doesn't mean that if you are doing business intelligence you are not doing Agile. They often have overlaps. Okay, you could engage in more than one perspective at a time. There are five perspectives. So let's look at them and that will help you understand what perspectives are as well. Now, Agile. Now, what is Agile? I'm sure all of you have heard the term Agile. What do you understand by Agile? Hopefully you can see my paint screen. Um what used to happen in the past is you will do a detailed requirement for a project. Right? Then you will do a design for the entire project. You will then develop, test, and then go live. This is what used to happen in the past, uh which is also called the waterfall model. Now, what has changed is instead of doing this, what you do is you do the most critical few requirements. You will then design that, you will develop that, test that, and then you will go live. Parallelly, you will also collect the next set of requirements, design it, develop it, test it, and go live. And then repeat this again and again and again and again, right? Basically, the idea is there is a usable um solution significantly early for your customers, and then you continue to improve it until you reach your final solution. The problem with the first approach was that until you reach this particular point here, the users do not get any solution at all. They get documentation. Whereas, the focus in Agile is that you deliver working software early to your users, so that they can provide feedback, which can be implemented in the next cycles. Um so so that essentially, you you look at this in the form of cycles, right? So, you you have the first Agile cycle. I don't know why I have that. You have the first cycle, where you deliver the first iteration. Then you have the next cycle where you improve upon that delivery. Then you have the next cycle where you improve upon that. So thereby you evolve the product over a period of time. So this is called Agile. Okay? Now, in business analysis, the first perspective is Agile perspective. So the first thing is an Agile mindset. So Agile mindset is when you understand the focus of Agile um perspective or Agile delivery is to deliver incremental value early on working software so that the customers can provide feedback and that feedback can be iteratively implemented into the solution. There are a set of Agile values and principles. Uh you can go to the uh Agile Manifesto. It will give you the detailed uh values and principles. You elaborate the business requirements uh progressively. So like we saw in the uh picture, we will start with requirement for some uh some features. You design and develop and test that. Meanwhile, you will start picking up the next set of requirements. Um and then next set of requirements so so on and so forth. Okay? The question is how is business analysis going to be different if you are implementing it in an Agile perspective. We will see that when you are discussing the Agile uh perspective, right? A business analyst is a member of the Agile team. Okay. Second perspective is business intelligence. What is business intelligence? Business intelligence is the perspective in which insights are um provided to the business to make decisions in order to achieve their goals. So for example, let's say you are a bank and you want to decide what kind of loans should be approved. So, you can use past um loan data and the corresponding information from a new loan application and then make a recommendation that, "Okay, given these parameters, we should approve this loan or we should deny this loan." Or we can look at um clickstream data to say, uh in this particular page, the checkout button should be slightly higher for easy checkout for our customers. So, that kind of a project where the goal or the outcome is to provide to analyze a large set of data and based on that data, come up with a recommendation which is an business insight for the business to take action is called a business intelligence perspective project. This is the the decision could be either practical, so for example, should we increase the price or reduce the price? It could be strategic, like we want to introduce a new product into the market. Uh or it can be operational, where you make decisions like we should um change the process uh slightly. Okay, the next is information technology perspective. So, I think when we discussed what is a business analysis activities or or what is who is a business analyst, more the most common answer I think was a bridge between business and IT. Which is exactly the case in information technology perspective because this perspective deals purely with implementation of information technology projects. Which is the most common area where all BAs work. Now, some of these IT projects follow an agile methodology, so there is an overlap between between Agile and information technology. But, uh traditionally, information technology used to be the most common area where BAs used to work. Now, uh what kind of changes are happening here? What is the context here? So, every organization needs to often implement new information technology systems or upgrade existing information technology solution. And the role that a BA plays in this um perspective is that of a uh interpreter or a translator because the business talks business language, technology talks technology language, just to make sure that they are able to understand each other. The business analyst will um work in the middle to make sure that uh the project is delivered successfully. Okay. The next perspective is business architecture. Okay. What is business architecture? If you think of an organization, it has different components, right? So, it will have marketing. It will have operations. It will have sales. It will have uh financial financial management. Uh it will have um so, business architecture is basically, instead of looking at a part of the organization, it look at the entire enterprise to understand how various uh elements come together to deliver value and suggest strategic organizational or enterprise level changes which can increase the value that the organization is delivering uh and achieve its objectives. Okay. So, for example, you sometimes if those who have worked in organizations might have noticed that sometimes organizations will restructure slightly differently. So, for example, uh there is an organization which was always structured by geographically. So, you had Americas, Asia, India, UK, etc. They do an analysis and they realize a better organizational structure would be if we do it by product. So, they decide that they are going to target specific products. So, they are going to structure the organization according to their product. Products that they are going to deliver. That's an example of a business architecture initiative and the outcome that we are trying to look for. Okay. So, what is business architecture? Business architecture is when you look at people, process, technology end to end at an enterprise level and come up with recommendations as to what to change in order to achieve the strategic goals of the organization. Imagine you want to start a new business. Okay. So, let's say you want to Let's say you want to start a new laundry business. Okay. Where you collect clothes from your customers. You take it to a centralized centralized what do you call go down where you launder it, dry clean it, whatever and then you send it back to the customers. Now, what are the things that should be in place for this? You should have a marketing in place. You should have operations in place to collect the clothes, launder it, respond to send it back. You should have some sort of financial management. You need to make sure that you have sufficient money to run the operations, to pay the employees. Are you going to collect it all yourself or are you going to come up with a franchise model where different people can collect it for you and you simply centrally run the the laundry. So, that kind of a question as to how are you going to implement this service end to end at an enterprise level is a question that needs to be addressed through a business architectural review. Okay. So, you are not looking at one part of the organization. You are not looking at one problem. You are looking at an organization as a whole and looking at what all changes should be made in various parts in order for the organization to achieve it achieve its goal. It might involve restructuring. It might involve new technical platform. It might involve new processes. It might involve new business model itself. So, excellent. That takes us to the the last perspective, which is business process management. So, business process management is when you are purely looking at a process, right? There is no technology change involved. You look at a specific process. So, let's say you are working in Amazon and you are looking to reduce the average time taken to deliver the products that are ordered by customers. Okay? What will you do? You will look at the end-to-end process. I as a customer places an order. The order goes to a team. That team will then, depending on the right what do you call category, will send to um a particular go-down or a fulfillment center. They will then take the product, send it to a different fulfillment center, which is in route to the place where I am, and they will then send So, so you will map this whole thing out and then you will you will ask, "Okay, what is it that we can do so that we can reduce the time taken to deliver this?" So, it could be that instead of somebody forwarding it, you automate it. That would result in faster delivery of the instructions. It could be that you build, you know, 10 new go-downs in places where these products are getting ordered very frequently. So, these kind of changes are called business process management changes. Okay, in this perspective, the business analyst will evaluate the business processes and come up with recommendations on how to change or improve the business process. And then we will start, right? So, you will get a question in that link. You will have four options. You need to select the option which you think is correct based on the topics that we covered. Okay, we will start now. The first question. Which of the following is not a component of business analysis core concept model? Change, solution, content, stakeholder. 7 seconds to give your answer. Okay, time up. Okay, most of you got it correct, I believe. It's contend, right? Change, solution, and stakeholder are components of business analysis core concept model. Okay, moving to the next question. Dash are focused on needs and dash are focused on solution. Problems, requirements, requirements, designs, solutions, requirements, designs, requirements. Okay, again most of you got this correct. We'll move on to the next question. Which of the following is a business analysis knowledge area? Elicitation and collaboration, enterprise analysis, solution assessment and validation, requirement analysis and management. 8 seconds. 6 seconds, 5 seconds. Right, again most of you got it right. Good job. Last question, I think. Which of the following is not a category of business analysis competencies as defined in the BABOK. Analytical thinking and problem solving, communication, organizational knowledge, interaction. 3 seconds. Okay, I think only around 40% coded correct. It's organizational knowledge. Everything else is a category. Organizational knowledge is uh within the business skills, one of the uh the the uh detail skills within that, not a category. Okay, let's look at the leaderboard. With that, we complete our second lesson, which is which is the uh introduction to business analysis body of knowledge version three guide. Uh we started by defining who is what is business analysis. We said that business analysis is enabling change by defining needs and recommending solutions. Then we moved on to the business analysis core concept model. There were six concepts in the business analysis core concept model, which were change, which is an act of transformation in response to a need, need, which is a problem or an opportunity, solution, which is a way of satisfying one or more needs, context is the environment in which the solution or the need is being addressed, stakeholder is somebody who is related to the change, solution, or the need, and finally value is the worth of a particular um solution in a context. And then we took a look at the knowledge areas. We learned that there are uh six knowledge areas. So, the first is business analysis planning and monitoring, where we plan the overall business analysis activities as well as the performance assessment of business analysis. The second is requirements life cycle management, which is used to manage information collected throughout the life cycle of the solution. Then there is elicitation and collaboration, which is used to gather information from stakeholders and manage the ongoing collaboration with them. There is strategy analysis, which defines the need and the business goals, and also focuses on defining the current and the future state. Requirement analysis and design definition will help us to specify and model requirements, as well as validate and verify them. Finally, solution evaluation helps us to evaluate the solution against the expected benefits, and then recommend solutions, sorry, recommend actions to improve the value of the solution. Then we looked at the requirement analysis, the requirement schema. We learned about business requirements, which is the high-level goals and objectives that you're trying to achieve. Then we looked at the stakeholder requirements, which are the business requirements broken down from the perspective of the various stakeholders. Then we looked at the solution requirement, which included both functional and non-functional requirements. Functional requirements are the behaviors of the system. Non-functional requirements are related to performance. And and then finally, we learned about transition requirements, which are used when we are moving from the current state to the future state. Then we also learned about requirements and designs. We learned that requirements are focused on need and designs are focused on the solution. We looked at the stakeholders. We learned about the 10 different stakeholders. We then went through the competencies. There were six different groups of competencies. We then had a glance at the um the techniques, uh the 50 techniques which we will cover through the course. We also took a look at the five perspectives. The perspectives are Agile, Business Intelligence, Information Technology, Business Architecture, and Business Process Management. With that, we completed our lessons, lesson number two, which is an introduction to BABOK version three. Right. Now, we are going to get into the um the knowledge areas. Now, in each knowledge area, there is a set of tasks. We will cover each task one by one, but before we do that, I just want you to be comfortable with the format, right? So, for each task, we will start with a purpose. So, we will explain why we are doing that particular task. We will explain what that task is, what is going to happen in that particular tasks. We will look at inputs into that task. We will look at the various elements of that task. What are the different components, activities of that particular task. There are what are called guidelines and tools which you can use for that partic- particular task. We will look at the specific business analysis techniques. We will look at the key stakeholders who will be involved in the task. And then finally, the outputs of the task. So, these are the eight standard elements of each task under a knowledge area. So, for example, business analysis planning and monitoring has five tasks. For each task, we will go through each of those eight elements. Yeah? Okay. So, we are going to start with the first one the first knowledge area, which is business analysis planning and monitoring. So, we will look at five things basically in this. The first is how to plan what is called business analysis approach. Second is how to plan stakeholder engagement. Third is how to plan business analysis information management and governance. Information management, then how to plan BA governance. Finally, how to identify business analysis performance improvements. We will also cover some techniques as part of uh these these tasks. Okay. What We already spoke about this. Before you do any activity, you will plan, right? Let's say you want to go on a vacation to Italy, right? What will you do? You will plan. How will you plan? So, you will decide, okay, when should you go? You cannot go during December because it will be very cold. You need to go during a time when the weather is pleasant. So, you decide maybe June, July, whatever. You decide that. Then, you need to make sure you will get leaves from your office. So, you arrange that leaves. So, you decide a date, and then you need to get all the stuff done. You need to, you know, uh you need to get your tickets booked. You need to get your accommodation booked. You need to sort out your visa. All those kind of stuff, right? Uh you need to decide what all attractions, what all places you need to go. So, the first step in any endeavor is planning and the same applicable for business analysis as well. So, the question is what are you going to do as part of business analysis for a particular initiative? You are given a problem. So, let's say the problem is that you the the business there is a hospital, which is your business, they want to implement a patient management system uh so that they can reduce patient wait times, they can create better MI uh etc. etc. So, they have given you a list of requirements. So, what kind of approach are you going to do? Uh what take what kind of techniques are you going to use? Who are your stakeholders? All these things needs to be decided up front, which is done in your business business analysis planning and monitoring knowledge area. Now, how does the knowledge area uh impacts the the various uh elements of the business analysis core concept model, right? So, in planning you are basically deciding the nature and scope of the change that you are going to implement, okay? So, you will also decide what type of approach you are going to take. Are you going to use an agile approach? Are you going to use waterfall approach or are you going to use a hybrid approach? Right? For example, if the change is organization-wide, you need to follow a formal governance, right? But if it is a small uh change in a in a team, that might be uh less formal in terms of governance, okay? So, first is look at the nature and scope of the change and the approach that you will follow follow for business analysis to support the change. That's the change angle of business analysis planning and monitoring. The second is the need. What is need? Need is a problem or an opportunity. The need will drive the business analysis activities, right? So, depending on the need, you will decide what type of uh techniques, what type of uh approaches to take for addressing that particular need. So, for example, if the need is a regulatory compliance, right? Uh you would probably need to adhere to the dates that is provided by your regulator. So, that will impact your overall stakeholder involvement and the overall timeline. So, the need will drive the business analysis activities. Then you have solution. Now, at this point, when you are planning, generally, a solution may not be completely defined, right? But, the type of solution would be indicated. So, for example, you might know that uh it is going to be a technical solution. Or you might know that we don't have funding for a technical solution. It is going to be a process thing. The the the best we can do is a process thing, right? So, that will inform the kind of planning and approach and techniques that you are going to use. Uh stakeholder engagement is a core part of uh the planning. So, you need to first identify the stakeholders, understand their roles, their responsibilities, analyze them, and engage, understand their engagement levels. Okay? Uh then you have value and context. So, context mean you need to understand. So, like we said, if it is a regulatory driven project, that might impact that is the context that might impact the overall planning. If and then the value is understanding the benefit that the change is going to uh deliver so that you can appropriately make decisions. Okay? So, all these um uh concepts are uh impacted in the business analysis planning and monitoring as we discussed. Now, what are the inputs? So, the inputs are needs and external to the business analysis inputs and outputs, the performance objectives. Okay? So, we have two inputs, performance objectives and needs. Okay? Needs are basically the problem or opportunities that we are trying to address. Then, what are the tasks? There are five tasks like I mentioned. The first is plan business analysis approach. The output of that is business analysis approach. Second is plan stakeholder engagement. Output is stakeholder engagement approach. Third is plan business analysis governance. The output is governance approach. Fourth is plan business analysis information management. Output is information management approach. And the final one is to identify performance improvements. And that's the output as well. That takes us to the first task, which is plan business analysis approach. The goal of planning business analysis approach is to define the overall methodology that we are going that we are going to follow in order to conduct the business analysis activity. Okay? Let's look at what are the inputs. Need is the input into this particular task. The output, business analysis approach, which will contain what is the methodology that you are going to do follow, who will be performing the business analysis, at what time, what is the sequencing of the activities that you are going to follow. The elements are creation or selection of a methodology. So, you need to decide whether to use agile or waterfall or anything else. Need to identify what are the key deliverables. You need to define the task and activities. So those are the elements of planning the business analysis approach. Okay, so the very first thing is planning falls between predictive and adaptive approaches. So predictive in this context stands for agile or traditional methodologies. Predictive in this in this context stands for the traditional methodologies or waterfall methodologies. Adaptive in this context stands for agile methodology. Okay. So the first decision that we have to make while you are doing a business analysis approach is to decide whether you are going to go with predictive approach or adaptive approach. Okay. We already discussed the difference between uh predictive approach and adaptive approach or agile or waterfall method when we were discussing the agile perspective. So I'm not going to repeat that. But what we will do is we will take a look at how do you decide whether to whether to follow an agile approach or a waterfall approach or a predictive approach or a or an adaptive approach. Okay. So predictive approach. Predictive approach also called waterfall or also the traditional approach that was always used is also called a plan-driven approach. Now it is used when you are very clear about the requirements and they are unlikely to change. The scope is clearly defined and the scope is fixed. There is a preference for formal documentation and structured process. There is low tolerance for change. The solution is similar to past projects or the solution is of low risk, the organization uses waterfall or sequential methodologies. The The What are the key characteristics? The requirements are defined early, focus on documentation and sign-off, and changes are managed through a change control process. It is much more difficult to make changes when you are following a predictive approach, okay? Whereas, you will use an adaptive approach when the requirements are not clear, it is evolving, they are uncertain, and they are not known completely up front. The project is complex or the project is innovative. I don't think you can build something like a Facebook using a adapt predictive approach because you don't even know like Mark Zuckerberg didn't know what he was creating when he started working on Facebook. So, that's something when it is innovative and complex, you don't use a predictive approach. Now, one key consideration is in order for adaptive approach or agile approaches to work, you need constant engagement with your stakeholders. Now, sometimes your stakeholders may not have that much time to spare. In that scenario, it might be difficult for you to go with an agile approach. The solution will be developed incrementally. So, I think we already agreed incrementally and iteratively, there are a number of different sub methodologies that we can follow. Requirements are continuously discovered and defined. The focus is on um the minimal documentation and working solutions and continuous delivery, right? So, according to the BABOK, you should look at the organizational process needs and context, evaluate the complexity and risk, engage stakeholders, and then tailor the approach. Right? So, this is the summary of how you arrive at a decision whether to use an adaptive or a predictive approach. The reason why I kind of highlight that is you will get questions in the CBAP exam as to when to use predictive and when to use adaptive. Okay. So, that is the first part of your business analysis approach. So, you already decided when requirements keep changing. Agile Yeah, that's a good rule of thumb to follow, Akanksha. There are a few more criteria that we can use, but yeah, okay. Formality and level of details of BA deliverables will depend on the planning approach. So, if we agree if we decide to go with a predictive approach, then you will go with a more formal BA deliverables. So, for example, you might have a BRD, you might need an FSD, etc. If you decide to go with an adaptive approach, you probably need some user stories to be defined. Then you identify the activities. Okay, I need to do a current state analysis. I need to do a review of the preferred future state. I need to identify the requirements. I need to document the requirements in the form of a BRD. So, you will basically break down the entire business analysis activity into specific tasks. And then you assign timing to it. Okay, I'm going to do the current state analysis in the first 2 weeks. And then the next 4 weeks are focused on the future state. And then the next 2 weeks for documenting the requirements. And then another 2 weeks for reviews and sign-off. The complexity of the change can impact the approach. The size of the change can impact the approach. The risk of the change. If If is a very critical change, we might prefer keeping higher levels of governance in it. And once you prepare the business analysis approach, it is then reviewed and agreed by the stakeholders. Okay, so that is the business analysis approach. So we are talking about a fashion retailer, somebody who sells clothes. They sell trendy clothing and accessories. It's called StyleCart. Let's say it's our company, all of us together. All the I don't know, 43, 44, I don't know what the number is right now. All of us together we built a company called StyleCart. It has some physical stores, right? They have reasonable sales. But we are not able to get good amount of digital sales, right? So we have a website which we have built some 7 years back, but it is no longer suitable for the needs of today's online shoppers. What is the current state? The website is outdated. It has a slow user interface and the design doesn't reflect the brand image of the company. It's not mobile-friendly because 60% of the visitors access the site through smartphone or tablets, which is a problem. The site lacks secure and modern checkout process. Often people leave abandon their carts. There is some amount of mistrust. There is no support for user accounts. So if they have to have a a a returning user, they have to re-enter their entire information like address, email address, and all those kind of stuff again. The product search and filtering options are limited. It the inventory is not properly integrated. So for example, if you you might have a a particular trousers in blue in size, I don't know, 34 available 10 units, but the system might show it's not available, so inaccurate stock visibility. Marketing features like promotions, discount codes, um personalized recommendations, these are all difficult to manage. There are performance issues, page uh page load slow, frequent downtime during high traffic. Uh security vulnerables one vulnerabilities, sorry. Hard time pronouncing it. Okay. Business concerns, declining revenue despite increased investment in digital marketing. Poor user feedback and reviews regarding the website's usability and performance. Competitors with more modern and feature-rich platforms. Current platform is difficult and expensive to maintain. There is no scalability. Goals of the new initiative, deliver a fast, modern, and mobile-friendly experience. Improve the online conversion rate and reduce cart abandonment abandonment. Enabling user account creation and order tracking. Support real-time inventory updates. Integrating with secure payment gateways. Providing features such as wish list, product reviews, promotions, and personalized recommendations. Ensuring that the platform is scalable, secure, and easy to maintain. So, this is the case study. Now, tell me, based on what we just went through, what would you say is the business requirement? To increase the revenue? Yeah, so you need to be a little bit more specific there, Sema, because they all they have a retail store where they are able to increase the revenue, correct? So, if you say increase the revenue, that is not accurate. What they are trying to do is they want to increase the digital revenue, correct? So, um so the the goal is to increase the digital revenue or the revenue that get they get from digital sales by uh let's say 10% in a period of 24 months, right? That can be a um a business requirement. Website is outdated Mahendra. Is that that's a problem that's a need essentially. But what is a business requirement? Website is outdated so what? Right? To increase the online yes. So that that's a very good phrasing of the requirement Ashish. To increase online sales by X percent in Y months or Y years as the case may be. Create a digital app with user-friendly that is a solution. Requirement Ashish. So you you could decide that I don't I don't mind not having a digital solution. Right? So that's that could be a solution requirement. Online increase online shopping yes online sale and revenues. Online presence and engagement by X percent that can be a good requirement. Existing enhanced yeah enhancing the existing application is a solution requirement. You could build a completely new application as well. Right? But the the the the remaining part is correct Shruti to increase the revenue. Increase revenue through e-commerce efficient platform for e-commerce user-friendly more yeah. So these are all solution requirements Dinesh. So you need to think of business requirements. Right. So other examples of So basically we we discussed that online sales needs to increase. Other examples of your business requirement could be that uh increased or decrease in the cart abandonment in the what you call um in the online on the in the website by 50% or 25% or whatever in one year period. Right? Basically what happens is that people comes they add they like the the the trouser or the t-shirt or whatever. They add that to the cart but then they need to fill way too much information at that point they lose interest and they exit, right? That is what they want to avoid. The other requirement could be to increase the conversion ratio. Now, what is a conversion ratio? Which is Let's say there are 1,000 people visiting the the site and only let's say 10 of them uh orders um new products. So, that's a conversion ratio of 1%, right? So, they might want to increase the conversion ratio to 10% in 1 year or whatever. So, these are some of the examples of the business requirements for uh the uh for the case study. To increase the footfall to the online platform by X percent. That is That is correct. That can be a good um requirement. So, the number of people visiting needs to increase. Um right? Okay. Revamp the website to drive more users. Revamp the website is a solution requirement. Okay? All right. Um we will move on. Uh so, yesterday when we stopped, we were talking about the elements of planning a business analysis approach, right? So, before you do the actual business analysis, you will make a few decisions, which are what planning method to follow? Are you going to follow a predictive approach or an adaptive approach? I.e., are you going to use the traditional waterfall approach or and the more agile approach? What kind of deliverables are required from a business analysis perspective? Um break down those deliverables to activities and tasks. And when are you going to do that activity? What is the complexity and size of the change? And what is the risk? And finally, you need to present all these things to your stakeholders and get their agreement or sign-off. Now, let's think about the the case study once again, right? If you think about the So, Tirthankar remind the question in a minute? I'll I'll I'll I'll um I'll I'll give you time for questions, but let me just end my thought. So, uh what I was saying is um the Let's think about the case study, the Style Card case study. What approach should they follow for business analysis? Should they follow a predictive approach or an adaptive approach? What do you think? And why? Give a small rationale as to why. Okay, now the next one is what kind of deliverables should you as a business analyst, what kind of deliverables should be created for this particular problem? What do you think? Obviously, we have just started, so you may not If you're not able to answer, that's fine. But, any thoughts? Business process? Yes. Um I think the best way to uh express that is the current state business architecture. Okay, we can we can say business architecture. Business Yeah, so the first thing would be we will create a plan for business analysis, right? Which is basically the business analysis approach. Uh the second would be a current state analysis. Then you could think of requirements. So, customer feedback is already available, right? You are not It's not a deliverable from the perspective of business analyst, right? What is the most important deliverable from a business analyst? Yeah, FRD BRD FSD BRD same as so, you can think of BRD or business requirements. It need not always be in the form of a document. But, uh the requirements uh business requirements uh stakeholder requirements and and and uh system requirements or solution requirements as the case may be. You know, functional specifications, any anything else, non-functional requirements, so everything that they have to identify, right? So, that's basically what you have to deliver. Then you need to define what are the activities that needs to be completed in order to uh deliver these things and then in what timeline. So, effectively, business analysis approach for the Style Kart problem will look like this, right? Your approach type, we agreed that it is adaptive or which is agile or iterative. Rationale, requirements are not fully defined up front. Uh the initiative aims to deliver incremental improvements. So, there will be uh what is known as an MVP. So, some of you might know this term. MVP stands for minimum viable product followed by additional features. So, basically, what you do is you start with one or two features. I don't know if you if you have seen the movie Social Network when they launched Facebook for the very first time, they had very little uh features. In fact, they did not have their What is that called? Uh whether you are single or uh relationship status. Even relationship status was not there in uh in it just before launch. And and you know, there is a there is a uh there is a scene in the movie where uh you know, the the guy who plays Mark Zuckerberg, he realizes that that's a interesting feature and he runs to add that feature into the tool. So, my point is that uh MVP is basically the minimum amount of features that you need in order to roll your um tool out or your product out. So, uh you will uh deliver incremental improvements. You will look to in in um keep the stakeholders continuously involved to get um validations and feedback. Uh and we can get more user feedback loops, thereby improving usability and flexibility. Then you will decide what techniques to use. These are some of the techniques that you can use. So, we will cover some of these through the course. So, let's not worry about that right now. We talked talked about the deliverables. So, we need to have the the analysis plan, which is this document. Then the current state analysis, um benchmarking because this is a online solution, so we need to make sure that we are um benchmarked against other uh people who are providing similar services. Uh BRD, user stories, FSD, um non-functional requirements, and traceability matrix. We'll cover traceability matrix later, so don't worry about that. And then you have a final kind of a uh timeline. So, we are saying uh so obviously since this is like a fictitious example, we have used week one to two. In reality, what you do is you provide dates, right? You will say say March uh it will start on 1st of March. Um sorry, let's say 3rd of March and then it will go till 17th of March. Um and then competitor benchmarking maybe from uh 10th of 3rd of March to 17th of like like that. So, 10th of March to 24th of March something like that, right? So, that's how you create a business analysis approach or a plan, basically. Okay. So, with that, we'll move on um from business analysis approach. Uh you can use these guidelines. So, business analysis um performance uh assessment will provide you feedback from the past, which will help you to um make better approaches or better planning. Stakeholder engagement approach will tell you who needs to be involved in business analysis approach. Um business policies, so there could be existing policies that might be guiding you. So, for example, there are some organizations where if the if the the the budget of the project is more than a certain value, then you have to follow certain approach or a certain uh delivery plan, etc. Uh there might be ex- existing um uh directions around methodologies within the organization. And then there is expert judgment, which is basically you need to based on your experience, you need to pick up which um approach or which methodology to follow. So, these are the guidelines and tools that you can follow while you are defining the business analysis approach. And there are a number of techniques that you can use. Um I won't read through, but uh you have uh some of these techniques we will cover In fact, all of these techniques we will cover later in the class. Uh but for now, let's take a look at one of the techniques, which is lessons learned. Okay. When you are running a project, what you do is as often as you can, at the very least once at the end of the project, sometimes more frequently, sometimes maybe at the end of an iteration if you follow a agile uh process, what you do is you do something known as a lessons learned. In agile, it is also called retrospective. Both are exactly the same. What do you do when you do a lessons learned or a retrospective? You are basically having a conversation with your um stakeholders to identify what went well, what are the things that went really well, what are the successes in the last period that you are discussing, what are the areas where we probably need to do better, and what are the things that went really bad, and what are the recommendations that we have in order for us to, you know, implement these projects or iterations better in the future. Right? So, that is the idea of a lessons learned um session. Okay. Um the uh it is also known as a retrospective. Like I said, in agile it is called retrospective. It can be a formal um lessons learned where you document everything and uh you know, everything is uh properly uh completed and and and and stuff like that. Or it can be very informal where you have a very casual conversation where you discuss, "Okay, what what are the things that we can do better?" Uh Uh, it One one key point is that it should not always um focus purely on what went wrong. It should um focus both on positive experiences and successes as well. So, that you can continue to do uh what went right. Now, one challenge that you have is that some people may be very reluctant to say things that didn't go well. Some people uh may too eager to share uh things. Okay? So, that's uh basically uh the uh the lessons learned uh technique. Um and how are you going to do uh the lessons learned technique? So, lessons learned can be on the business analysis activities. So, you did a requirement gathering session. You did an elicitation session. You can do a lessons learned on that. It can be on the deliverables. So, you created a BRD. You can get feedback on that. It can be on the final solution. So, you created a new website for StyleCart. Um so, you after that you have a con- uh conversation with uh your stakeholders to understand what went well and what what needs to be improved. Uh it can have an impact to the organizational processes. So, for example, you might agree that, "Okay, going forward, we will define requirements much more in a detailed fashion and get that agreed with the stakeholders so that there is no um ambiguity in that." There might be It might impact your performance expectation and performance as well. It could have a positive or a negative variance. So, you were expecting the requirements to be complete. It was much better than what you expected or it could be worse than you expected. Wherever there is an impact on performance, you will evaluate the root cause and then you will provide recommendations for improvement. So, that's the lessons learned technique. Okay. So, to sum up lessons learned is a technique where what you do is you ask your stakeholders what is it that about the project or the deliverable or the the iteration that went well, what are the areas where we might require some improvements and you document them and provide recommendations as to how to address those areas of improvement. Okay. The stakeholders who are involved in planning business analysis approach are domain SME, project manager, sponsor and regulator. So these are the stakeholders that you need to engage in order to complete your business analysis approach. So we learned who are stakeholders. Now one thing which often people do not give enough stress to, the success of your project depends on how engaged are your stakeholders. So their engagement and their contributions will drive the success or failure of your project. And as as a BA your ability to engage with your stakeholders will define how good of a BA you are. Okay, so planning stakeholder engagement is the task in which you look at your stakeholders and understand who are your stakeholders, identify your stakeholders and then you plan an approach so that you can maintain an effective relationship with your stakeholders. Okay, so the inputs into this task are the needs which is basically what you are trying to achieve. So in our Stylekart fundamental need is is to increase the digital sales or the online sales for Stylekart. The BA approach we already agreed we are going to do adaptive etc. etc. etc. So you take both those and then you look at, "Okay, who are uh my stakeholders, and what are their characteristics?" Okay? Those information, when represented in the form of a document, will become what is known as a stakeholder engagement approach. Okay? Which is the output of this particular task. Right, let's look at the elements. So, the first is you you will perform what is known as a stakeholder analysis. Right? How do you do a stakeholder analysis? You identify who all are the stakeholders. Right? So, we discussed who all are the stakeholders in our Unilever canteen order management system, right? Employees are some stakeholders. So, what category of stakeholders are they? They are the end users of your product, right? Canteen staff are another set of stakeholders. They are also your end users of your product. Uh management, the Unilever management, they are a stakeholder, but they are more likely on the sponsor side of the uh role, right? You might have a project manager. You might have a domain SME. So, that could be a senior staff within the canteen. So, they they might work as a domain SME because they are familiar with how the entire ordering is happening today. So, they might act as a domain SME. You might have some developers or lead developers or IT project managers who might work as the implementation SME. You might decide that instead of implementing a website up front, you might procure some sort of a workflow tool from a vendor. So, they might become your stakeholders, like a supplier. You might have a support team that supports your current system, or you might want to implement a support team in the future. So, that becomes the operational support. Uh you might you might need testers, so they become your uh testing team. So, the testers will become your stakeholders. So, you identify all the stakeholders that you need to uh involve in your um in your project, right? Then, you look at their attitudes. What do you What do you mean by attitude? So, some of these people might have a very positive attitude towards uh your um your your project, right? So, the management might be very eager to get the whole thing implemented. But, your canteen staff may be Okay, that this will result in lesser staff or uh you know, uh this will the the project might include additional work for me. So, they may not be that eager. The current system is working. Why do I Why do we need all these kind of things? So, they may not be that eager. So, they might have a very negative attitude towards the uh the project. So, you will do that analysis to understand, okay, what what they think about the project, what they think about the business analysis activity. Then, there is decision-making authority. So, some of these people can make decisions. So, management is probably having the highest level of decision-making um power. So, they can say, "Okay, we are going ahead with the project." Or, "We are not going ahead with the project." Or, uh "We will go ahead, but with limited amount of funding. We will go ahead, but we won't enforce certain parts of it." So, all those kind of decisions lie with some stakeholders. So, you need to identify that. And each stakeholder will have a level of influence or a level of power. Uh employees, if you take the average employee will have limited power. The management, on the other hand, will have high amount of power. Within the management, there could be different teams. There could be uh an operations team. There could be an HR. So, each of them will have certain levels of um influence. We need to identify that. So, that's the first task or the first component of the first element of stakeholder engagement, which is to perform stakeholder analysis. Okay, once you do the stakeholder analysis, you need to decide what are the stakeholder communication needs, right? Now, you decide to go ahead with building the the application or canteen order management system. Um what do you think are the stakeholder communication needs for employees? How frequently should you provide an update on this order management system to employees? Any thoughts? You are building an order management system for employees to order their food for their lunch in your in your company in your organization. Would you, like for example, once the requirements are complete, would you send out a communication to all the employees saying that, "Okay, we are building this These are the requirements. Please review and let us know." No, correct? Because that is not required, right? Because they don't They only would probably require once you are launching it, they need some training, and they need to know that we are we are going to go ahead with this. There might be a representative from the employees who might provide you requirements, but beyond that, so that they may work as a like a default domain SME kind of thing. Other than that, you don't have to engage with all the employees. Uh the same again with canteen staff, you don't need to inform them about the progress, etc. So, there might be some representative who will act as a domain SME. They will be involved in stakeholder uh updates. Now, will you walk the management through the detailed solution um requirements? No, correct? Because they don't need to know uh Okay, Sultana is saying yes. Uh Unless they are micromanaging management, you don't have to, right? Because they don't need to know the details. As long as the canteen staff representative and the employee representative agree on the requirements, The management is okay. What you need to provide the management is in terms of your status update, right? So, you need to tell them that your requirement is like 20% complete or 50% complete or we are planning to complete it by end of March or end of February or whatever be the case. So, you see my point that I'm trying to convey through these examples is depending on the stakeholder, they will expect different information uh to to be sent or to be communicated to them. So, you need to identify that, right? Because you cannot include everybody and send everything to everyone. That will be a very inefficient way of communication. So, the second task, second element of uh this task of planning stakeholder engagement is identify stakeholder communication needs. And then the final one is to plan an ongoing stakeholder collaboration. What does that mean? So, for the people who are actively involved, like the domain SME, uh the sponsor, etc., you might have maybe a working group every 2 weeks where you provide updates, where you say, you know, this is where we are, these are the problems, these are the risks, these are the issues, all those kind of stuff. The the active team, like for example, the domain SME, the business analyst, uh etc., might meet every day so that they can go over the requirements, the current state, the future state, all those kind of stuff. So, you will decide, okay, who needs to be engaged at what stage, and then you will document that. So, that becomes your stakeholder engagement approach. For stakeholders, do we keep meetings bi-weekly or milestone basis? Okay. So, what did we just say? We need to first identify the stakeholders. What was our second um uh plan, second step? Uh define stakeholder communication needs. and then plan the stakeholder collaboration, right? When you do this, Diksha, you will have to decide how frequently should you meet which stakeholder. For employees, you're never going to meet them. The canteen staff, you're never going to meet them. The management, you probably needs to meet once every 2 weeks, like you said, right? The employees, you probably need to train them once the tool is ready to be deployed, so that's milestone basis. The domain the employee representative and the canteen representative and the development team, you are likely to meet every day so that you can make progress on the project. So, this is exactly what you are deciding. You're you're The answer to that question is what you are going to define when you are defining a stakeholder engagement approach. You are going to decide as a BA until my deliverables are complete, including product owner and product manager, how frequently should I meet with them, right? So, for a PO, what do you think should be the frequency? Daily is probably not needed, right? Probably once in a week, maybe even once in 2 weeks. Uh the project manager, you probably need to send updates more frequently, maybe weekly, but you only need to meet once in 2 weeks, I think, right? So, that's something you need to decide based on their ask. So, you can you can ask them also when you are having engagements with them, you can talk to them. You know what? Okay, so this is what I think you need, right? You need like if you're talking to your project manager, he might need updates every week, right? So, that he can send those updates to his senior management, right? So, he you will tell him that, "Okay, let's let me send you a status update at the end of every week. Every 2 weeks, we will have a conversation where I will flag any risk, any issues, and I will also update you about what is happening. So, you agree that with them before you implement that so that you can document. Yes, you can discuss the means of communication, right? Somebody might only require Somebody might say, "I don't want to be in meetings and all. You send me the update in an email." So, that communication requirements, you agree, and then you uh plan it. The The problem what happens, you know, these days is um if you do not think about at the beginning of the project, one of two things can happen. Either you will end up sending everything to everybody, which they don't need, which they have no interest in, so thereby resulting in over-communication, which is probably okay because people can ignore emails, or you will end up under-communicating, which is a horrible problem because people are not aware which about things that they should be aware, right? Which is why you deliberately need to think about how much amount of communication needs to happen for each of the stakeholders, and document it, and, you know, communicate that documentation to them so that they are aware, and then follow that documented approach. Now, the The whole point is to follow a very structured, organized approach rather than doing this in a half-hazard manner, okay? So, for our StyleCart example, this is how a stakeholder engagement approach could look like. So, you start with stakeholder identification. So, the stakeholder, let's say CEO, CFO, they are project sponsors and budget holders. They have high influence, high impact. Uh the expectations from their side would be having return of return on investment, brand alignment, online revenue growth, those kind of things. Marketing team, they drives the campaigns, brands, and promotions. Um their influence, impact, their expectations. So, you do this kind of an analysis, right? So, you have IT team uh, who will be focused on technical build and maintenance, uh, sales and operations who will be involved in inventory order fulfillment, customer support who will be managing the customer queries, end customers, new and repeat users, right? Uh, warehouse and logistics team, legal and compliance, design, uh, external vendors, board of directors, they will be invested in strategic oversight. So, these are your stakeholders and this is your stakeholder identification. Then you agree So, we have the the interest uh, power, right? So, we have that view as well. Then you look at the engagement strategy. So, executive leadership, there could be what is known as steering committee meetings, progress reports, communication frequency is bi-weekly, communication method is through dashboards, reports, and strategy reviews. Marketing team, you might provide updates in a weekly fashion. Uh, IT development team, daily possibly, uh, and using Jira or DevOps tools. Sales and operations, maybe bi-weekly. Now, this is not an exact science, right? This is something where you kind of think about it, brainstorm with your stakeholders, and agree um, with them the the engagement strategy that you're going to follow. And then you will come up with an engagement plan and that will be end of your stakeholder engagement approach. All right? Um, the guidelines and tools, uh, we will use business analysis performance assessment to guide um, and address any any problems that we may might might have faced in the past. We will use change strategy which will tell us um, what uh, change strategy are we following, uh, and current state description will tell you which parts of the organization is being impacted by the change and which stakeholders should be involved. Okay, so there are a number of techniques that we can use. What but let's take a look at organizational modeling and stakeholder list map or personas. Okay. So, what is an organizational model, right? So, basically what you do is let's take an take a look at an example and then we will come back to the theory. All right. So, those who have worked those who have worked in an organization would have some sort of a would have seen some sort of a organizational model or an organizational chart like this, right? So, you have the overall business unit head and then you have leads of program management, development, operations, etc. And there is people reporting to each of them, right? So, this kind of a representation of the entire organization is called an organizational model. Right? If you think of our Style Kart, you will have the CEO at the head and then you have the marketing team. You have the sales team. You have the operations team. Uh, you have the strategic programs team, let's say. And then you have the HR team, okay? And below the marketing team, there could be marketing managers, social media marketing team, there could be traditional media marketing team. You know, so those kind of structure and then under sales you might have area sales leads, you know, retail store heads, etc. Under the operations, you might have the logistics team. Uh, under the strategic initiatives, you might have you know, offline retail store strategy, you might have the online strategy team. Uh, HR, Uh, So, you that kind of a representation is called an organizational model. Let's look at what are the elements. So, organizational modeling it explains the roles, uh, responsibilities, and uh, reporting structure. It aligns these structures within the organizational goals. The organizational model shows the boundaries of a group, formal and informal relationships between members, role of each person, and interfaces between the unit or stakeholders. Okay? The elements are There are different types of organizational models. There are what is known as functionally oriented uh, organizational model, market-oriented organizational model, and matrix organizational model. Let's look at what does that mean, right? We discussed an organizational model which is functionally oriented, where you have uh, marketing, sales, operations, HR, uh, strategic initiatives. So, it is uh, uh, it is structured by functions. Okay? That's one way of having an organizational model. Another organizational model is based on markets. So, it could be geographies. So, for example, you might have one head for, let's say, uh, Americas, one head for Europe, one head for what is known as uh, Middle East, one head for Asia. Uh, so, that kind of a structure is called market-oriented. Now, market-oriented can also be based on the the market segmentation, which is uh, high net worth individuals, you know, uh, corporate organizations, uh, etc. So, based on the type of customer that you're dealing with. So, uh, those are the market-oriented structure. Matrix model is when you have a combination of these two. So, you have uh, say, for example, a global head of HR, uh, a global head of uh, marketing, a global head of sales, and then you have a head of uh, let's say, uh, US, a head of uh, UK, ahead of um China. Uh and under the head of UK, you will have a uh head of Sorry, under the head of UK, you will have a head of marketing UK. So, he will report to both head of UK and head of marketing globally, right? So, that kind of a structure where everybody will have two reporting lines is called a matrix model, which follows both functional and marketing market-oriented form. Okay. So, organizational unit will have a number of roles and it will interface with the other organizational units. Okay. Let's move to the next one, which is um stakeholder list, map, or personas. Okay. So, stakeholder um list is basically when you identify the stakeholder, uh then you do a stakeholder analysis, and then create a list of stakeholders. So, stakeholder characteristics that you are going to look at is the level of authority. So, we discussed about decision-making power uh or or influence, uh attitude towards the change, right? So, if you take the canteen ordering system, uh are we are we having a positive attitude towards it? Are you having a negative attitude towards it? Attitude toward business analysis activities. Do they think that the BA activities are um useful? Do they think it's a waste of time? And and the level of decision-making authority. What kind of decisions are they uh allowed to make? So, you represent your stakeholders in the form of different um representations. So, the first is a stakeholder map, which includes either a matrix or an onion diagram. So, we will look at both, right? A stakeholder map is when you categorize your stakeholders on the basis of both influence and interest. Okay. So, there are some stakeholders who will have a very high interest and a very high impact or influence. So, once you when you have the high influence and high interest, then you need to make sure that they are effectively engaged. Some stakeholders will have high influence but low interest. I don't I don't really particularly care about this particular project. But, I am very senior. I have a lot of influence. So, you just need to make sure that they they are happy. They don't create problems for you. There are some stakeholders who have high interest but low influence. So, for example, an individual employee in our candy ordering system will have high interest because he will be able to order stuff automatically, but he cannot actually influence your project in any way. And then there are people who might have very low influence and low interest, right? So, you need to to make sure that you identify their interest and influence and engage your stakeholders according to their interest and influence. So, matrix and market are interconnected. So, matrix is a combination of your market-oriented and your functional representation, right? So, you have So, so, so, functionally oriented and market-oriented are two different ways in which you structure your organization. Matrix is when you combine both. So, you have both market-oriented. So, you have US, UK, and China, let's say. And then you also have functionally oriented. So, you have a head of marketing, head of sales, and head of operations. Now, if you look at the head of US marketing will report to two people. Head of US and the head of global head of marketing. So, that kind of a structure is called a matrix model. Okay. So, stakeholder onion diagram is a way of representing your stakeholders in the level of in in accordance to the level of interest or the level of involvement in the solution or or the change delivery, right? So, the project team will be at the center of the onion diagram. So, if you think about like an onion, it has the layers, right? So, this is basically representing stakeholders in various layers, which is why it's called an onion diagram. So, you have at the core of the onion uh the project team who is involved in delivery, and then any affected organizational unit will be the next layer. The overall organization will be the next layer, and anybody who is external would be the the final layer. So, the it represents stakeholders according to the level of involvement in the delivery of the the the the the the change or the solution. That is stakeholder onion diagram. Okay, which takes us to the RACI diagram or the RACI matrix. Now, RACI stands for responsible, accountable, consulted, and informed. Okay? Responsible, accountable, consulted, and informed. Now, what does each of this mean? Accountable means they are accountable for what is happening. Okay? So, an example Let Let me explain responsible also, and I will explain give examples for both together, which will be easier. Responsible means you are responsible for doing it. Okay? Now, what is the difference between accountable and responsible? Let's say you are the head of police in a particular city. Okay? You are the head of police in a particular city. Now, if a crime happens, you are accountable for investigation and resolution of that crime. Correct? You are accountable for it. Which means if that is not done or if the investigation does not successfully complete, you are going to be held accountable for it. You have to answer the media, the the superiors, etc. But you are actually not going to investigate the crime, right? It will be a detective who reports to you, who is going to actually investigate the crime. So he is responsible for doing it, right? So accountable is the person who is finally um going to be held liable for that particular activity. Responsible is the person who is expected to do it, okay? Right? I'll give you another example, right? If you have a company which is publicly listed in an exchange, you are mandatorily required to publish your annual reports, okay? I'll repeat again. If you are a publicly listed company, meaning you have raised money from the public and you have listed on an exchange, the listing requirements requires you to to publish your financial accounts, which is your balance sheet, your income statement, and and your cash flow statement every quarter, I think. Every quarter. Yeah, yes. Every quarter, right? Now, the accountability of this lies with the CEO and the CFO, right? So the CEO, who is chief chief executive officer, and CFO, the chief financial officer, they are accountable for it, okay? If there is willful misstatement of it, they are liable to go to jail. Right? And it has happened. Like Enron in US, Satyam in India. These are examples where the the the the statements were doctored and that resulted in senior executives going to jail effectively, right? But you cannot expect the CEO to literally, you know, sit and create the annual reports, right? That will be done by their finance teams, finance analysts, and finance reporting analysts. Right? So, they are responsible for doing it. But, the accountability still lies with the senior CEO or the CFO. Okay, hopefully that makes it clear. Now, what does consultant means? Consultant is when in order to do this activity, you might seek their inputs. Okay? Informed means you will provide an inform an update to them, right? So, if you take our canteen order management system, a project manager could be accountable for the delivery of the solution. Now, the various tasks under that deliver delivery, there could be people who are responsible for carrying it out. Or, it could be that the sponsor is accountable, and the project manager is responsible for on behalf of the sponsor to implement the canteen order management system. Now, the canteen order management system implementation might consult HR, might inform employee if there is a employee trade union, they might be informed, right? But, that doesn't mean that they are accountable or responsible. So, that's the four um kind of elements of RACI. So, what you do is you take each task, and then you say, "Okay, this particular person is accountable or responsible or informed or consulted about this particular task." So, if you take in in order to to identify a problem or an opportunity, the accountability is with the BA, but it is done by the sponsor, project manager, and operations team. The implementations team is consulted, and the regulators are informed. Similarly, for each task you can see the accountable, responsible, and consulted, and informed. Yes, accountable is answerable, liable. When do we create this RACI? It's It's RACI, R A C I. So, listen, responsible, accountable, consulted, and informed. So, you create a RACI when you start a project so that everybody is clear of their roles and responsibilities. You can create a RACI in a number of scenarios when you want to make sure that a group of people are collectively delivering something and you know, and and they need to make sure that the outcome is being achieved. So, that is when you create a RACI. I mean, we can create a RACI for our course, right? So, for example, if we were to So, so, who is responsible Who is accountable for delivering the class? It is me, right? But, in order to deliver the class, I need your attendance, you need to pay attention, etc. So, you are responsible to an extent. I am accountable for delivering the class. To pay attention, who is accountable? You are accountable. But, there is a certain amount of responsibility with me, which is to make sure that you are able to pay attention. We might consult Amal for questions around LMS or questions around certain policy, etc. We might inform Amal. So, for example, if you want to you know, extend the session or we want to cut short the session, we we have to inform Amal. So, that's basically what when you create a RACI. You create a RACI when a group of people are coming together and they have to deliver a certain set of task or a certain project or a certain activity and you need to define what is the role of each person in the delivery. Okay? I think we will move on to persona. So, persona is basically for your stakeholder in order to understand the stakeholder better, what you do is you will create a persona for your stakeholder. What it This is more than just their roles and responsibilities. This is more about who they are, right? So, things like their age, their gender, their um ambitions, their concerns, their challenges, their background, all of this becomes critical in the persona. So, the persona you create in order to understand your uh your customer or your stakeholder better. So, you create that in a fictionalized fictionalized or generalized way. So, for example, uh if you were to uh build a solution for farmers in India, let's say, you cannot create that solution without understanding the persona of a typical farmer. How much education does he's does he have? How much uh how much how many language language does he speak? Which uh what are his goals? What are his dreams? What kind of uh family he has? So, only when you understand those things, will you be able to create a solution which uh helps him to use it, right? So, helps him to achieve a certain goal, right? Could be to market his product or whatever, right? So, that's where you create a persona. The goal of a persona is not to identify stakeholders, but to understand the drivers and motivations of your stakeholders better. Okay? So, that completes our stakeholder engagement. The stakeholders who will be involved for creating a plan uh so, planning stakeholder engagement are customer, end user, supplier, regulator, project manager, and domain SME. So, these are the stakeholders that you will work with to create this. Okay. What is your understanding of governance in a corporate environment? Obviously, there is there is the political governance. I'm not talking about that. The understanding of governance in a corporate environment. Rules and regulations, yes, that's one way of looking at it. Regulations, okay. Policies, ethics, okay. SOPs, SOPs as in standard operating procedures, okay. Mandates, okay. Compliance regulations, okay. Responsive system, mm. Okay. See, governance is fundamentally about decision-making, okay? So, in an organization, there has to be an established uh structure or process or level of authority for making decisions. Okay? Let's say you are working in an organization and you have to travel somewhere on business, okay? Now, your travel is for, let's say, 1 month and it is going to cost, let's say, 10,000 US dollars, okay? Now, it might be that the governance that is put in place could be that if an expenditure of 10,000 or less is incurred, it can be approved by a manager. So, you can go to your manager and your manager will be able to approve. So, they he is making a decision that you can go on your business trip because the cost of the trip is below 10,000. Next month, you're going somewhere else. This time, however, you're going for 2 months and the total cost is around 30,000. Now, you cannot have your manager approve it because it is beyond his decision-making authority. So, it has to go to somebody who is more senior, maybe a director or somebody like that, who will then approve your travel, right? Why do this happen? Because the organization has designed its governance system such a way that any decisions which incur a cost of up to $10,000 can be taken by managers. But if the cost goes beyond 10,000 up to let's say 100,000, it can be taken by say a director. If it goes up up from 100,000 to say a million, it can be a vice president. So that kind of a setup is called governance. Okay? Now, we are not talking about the general governance. We are talking about project governance. And in in project governance itself, we are talking specifically about business analysis governance. So business analysis governance is about what decisions can be made made by who uh and what is the process for making those decisions. Okay? So let's get into it. So the decisions that we are dealing with since it is about business analysis are about requirements and designs, including their changes to requirements, changes to designs, and their approval, and their prioritization. So these are the elements that we are going to deal with. So change the the decisions about So let's say you created some requirements. So those requirements need to be signed off or approved. Who can approve those requirements? Okay? You created on the back of the approved requirements, you created designs. Who can approve those designs? Who can review designs and and requirements? Let's say you created the requirements and designs and everything is approved and etc. Now, you need to make a change to the requirements. Somebody has requested a change to the already signed off requirements. How are you going to manage that change request? What is the change control process? And what is going to be the approach for prioritization? So all these things will be covered as part of the governance. So let's look at it. So the inputs are B business analysis approach and stakeholder engagement approach. The output is a governance approach for uh business analysis. The goal or the purpose is how decisions are being made on requirements and designs including their reviews, change control approval and prioritization. What are the elements? So, the first is a change control process where you establish a process for uh making changes to your requirements, right? So, if your requirements are changing, who is going to create that change request? What information should be there in that change request? Who is going to review it? Who is going to perform the impact analysis? And who is going to approve that change control uh that that change request so that either we you agree to go ahead with the change or you say, "Okay, we are not taking this change up." Second is around decision-making. Who is going to approve your requirements? Who is going to approve your uh designs? Who is going to approve changes to your requirements and designs? And then finally, you will have a prioritization approach. What is the approach that you are going to follow when you have to decide the priority of your requirements and your designs? And finally, once you have completed the governance approach that needs to be agreed with your stakeholders and approved so that it can be followed in future scenarios. Okay? So, if we take um as an example our Style Kart, right? So, the business analysis governance approach defines how business analysis decisions are made including how approvals are obtained, who has the authority over requirements, and how to change business and how changes to business analysis deliverables are managed. So, this is the governance approach for our Style Kart project. So, the decision-making authority. So, business requirements approval will be by the product owner and the business sponsor. Functional design validation by the BA, UX designer, and lead dev lead. And then scope prioritization is by the steering committee and change request approvals is by the change control board. Okay. Approval process, requirements approval workflow is the requirements are drafted by the BA. It's reviewed by the stakeholders and then approved by the product owner and then tracked in the requirements traceability matrix. Document approvals, BRD, FRS and process flows require sign off from product owner, product manager and technical lead. Change control process, change request will be initiated by the stakeholder or BA. Documented in a change request form, reviewed by the BA and PM for impact analysis and decision made by the change control mode board and it will be maintained in the requirement traceability matrix. You will use MoSCoW prioritization for all requirements, features and enhancements. And then for conflict resolution, you will try be a facilitation, if not escalate to PM and steering committee, document conflicts and resolutions in the project log. So that's your governance approach for the Style Cart project. If not, we will move to the guidelines and tools. So the guidelines and tools, business analysis performance assessment which is guideline for all the tasks that we saw so far in this knowledge area, business policies which will define decision making authority and governance. Current state description which will explain which what is currently in place and in some scenarios there might be legal and regulatory requirement for us to adhere to. Can we take one more example briefly? Sure. Let's take our other case study which is the canteen ordering system in in in Unilever. So who will be creating Let's Let's start with requirements, right? So, who will be creating the requirements? That will be a BA. Who will be reviewing the requirements? All stakeholders, which includes your domain SME, your implementation SME, uh and um maybe even the sponsor. Who will sign off the requirement? It could be the sponsor or it could be the um the senior the maybe the CEO, right? So, that will be who they will be signing off the requirements. Um who will What happens if there are changes to the requirements? The changes to the requirements should be initiated by the stakeholder or by the BA. It will be completed using a change request form. The form has to be defined up front. Once the change request form is completed, the BA and the project manager will perform an impact assessment. What is an impact assessment? So, they will review the change and explain, "Okay, if we accept this change, that will result in some positive benefits, but it will result in increasing the the the timeline of the project by 1 month and the cost of the project by 50,000 US dollars. And they will present that impact analysis to something like a change control board, and the change control board will review it and approve it. You document this process so that when there is a change coming through, you will decide that, "Okay, this We just need to follow this process." That is the governance approach. Okay. Any other questions on the governance approach? So, we we went through the guidelines and tools. Then we have a set of techniques that we can use. Um I won't read through, but these are the techniques that you can use for planning the governance and uh business analysis governance. Uh the stakeholders who will be involved are domain SME, sponsor, project manager, and regulator. That takes us to the next one, which is uh business analysis information management. Okay, so we will move to the next one which is uh information manage plan business analysis information management. So, when you are performing the business analysis activities, you will end up collecting a lot of information. Uh this includes current state analysis, um business analysis uh requirements, uh BRDs, or um requirements and designs, you know, uh operating procedures. All this information will end up either being collected or created, right? Now, the problem is that we need to make sure that these information that you collect are stored in a way that is accessible for all the stakeholders until the retirement of the solution that you are building. That approach of how you are going to store this information is defined using the business analysis information management approach. Okay, so let's get into it. So, inputs are business analysis approach, the stakeholder engagement approach, and governance approach. The output is the business analysis information management approach, and the purpose is to develop a plan for managing the information that is either created or gathered during the uh business analysis activities. Okay, so that's the input and output and the purpose. Now, let's look at the elements. So, the first is um we need to make sure that we collect the information, and we make sure that you organize it in a fashion that is easy for us to uh understand. So, one way could be you have the business requirement, and then the corresponding stakeholder requirement, and then the corresponding solution requirements. For each requirement, you need to decide which requirement attributes are you going to maintain along with the requirement. What is an attribute? So, for example, along with the requirement, you might say, "Okay, this is the requirement reference number. Uh this is the priority of the requirement. Uh this is the source of the requirement. Uh this is the There is any risk on that requirement, you might want to call call that out. So, there is a list of attributes that you can capture along with the requirement, right? The second element Sorry, the next element is the level of abstraction. So, the business requirements will be at a higher level of abstraction. So, for example, to take the the example that we discussed in the morning, we want to increase online sales by 10% in 6 months time. So, that's uh the business requirement. When you are presenting to somebody like a sponsor or a senior executive, you will use that level of abstraction. Whereas, when you are presenting to the technology team, you might say, "Okay, the the the website should load within 3 seconds or 7 seconds or whatever the case may be." Yeah. So, that's your level of abstraction. Then, you look for traceability approach. What does What is traceability approach? When you are defining requirements, you will trace the requirements from your business requirements all the way up to your business solution component and test cases. So, you have your business requirements, which will be broken down into stakeholder requirements, which will be then broken down into solution requirements, which will then become solution components, and those solution components will be verified using solution test cases. Now, you link all these things together in a matrix that becomes your traceability matrix. So, when you are defining your information management approach, you need to decide what kind of traceability do you want, right? In some cases, you need to follow 100% strict traceability. It could be a regulatory requirement. It could be based on organizational policy. In some scenarios, it is a much more relaxed, informal traceability. Okay? Then you will decide on the storage and access. So, you need to store your requirements in some place and also plan for reuse of your requirements until the solution is being demised. Now, when you perform this So, so traceability, for example, there is a separate task for traceability. We will discuss that in more detail at that point in time. At this stage, you are simply defining the approach for each of those elements, right? Uh hopefully we can take a look at an example of the StyleCart again. I think let's we share this. Okay. So, the business analysis information management approach will define how requirements and other BA information are stored, accessed, reused, and maintained. So, the purpose is to establish a structured process for managing the business analysis information. Business requirements, which is high-level goals and objectives, functional requirements, detailed user stories, use cases, non-functional requirements or NFRs, stakeholder analysis, process models and workflows, traceability matrix, and change requests. So, these are the information types that we will maintain for StyleCart e-commerce project. We We store We will use Confluence as the central documentation for things like BRD, FRS, etc. The access will be role-based access. We will use Jira for storing user stories, tasks, as well as traceability. We will use SharePoint for formal approvals and signed documents. We will use um Miro or Figma for visual modeling and wireframes. Uh there will be a backup policy defined. There is a version control defined. There will be standard naming conventions that we will follow. They will be tagged by the status. It should be searchable and traceability is maintained in Jira. These templates can be used for future projects. Lessons learned are logged in project insights document. And common requirements are tagged for reuse. Which are the attributes that you are going to capture? Requirement ID. So, the example could be requirement search 001. Priority. It could be using MoSCoW. Must have, should have. Status. It is draft, approved, implemented. Source. Name of the stakeholder or based on market research. Owner. And related features, dependencies. And then finally maintenance. The BA is responsible for the review. Uh obsolete or superseded information is archived quarterly. Stakeholder feedback prompts review update of artifacts. So, this is the approach that we have defined for our Style Guide project. Guidelines and tools for planning information management is um business analysis performance assessment, which becomes input into all the tasks so far. Business policies. Uh information management tools. So, there are some uh tools where you can manage and store business analysis information. And then there might be legal requirements or regulatory requirements for you to follow a certain approach for information management, you need to follow that as part of your process. Techniques that can be used are these. I won't read through that but that's these are the techniques that you can use. And then finally the stakeholders who will be involved are domain SME, regulator, and sponsor. For priority we give must have, then should have, and then good that's correct. So So there is it is called MoSCoW, right? It is written like this, right? M small o s c capital again small o w. So M is must have, that's the highest priority. S is should have, that is the next highest priority. C is could have, that is the next priority, and W is won't have, that is the least priority. Yeah, we will cover this in in as part of prioritization. That's one of the prioritization techniques most commonly used in Agile implementations. Okay, that brings us to the last task in this knowledge area which is identify business analysis performance improvements. So once you complete your business analysis activities, you need to have a review of how well the business analysis activities went so that you can identify those areas where we can implement improvements which will help help us to perform the business analysis activities better in the future initiatives. Okay? So that is the goal of identifying business analysis performance improvements. The inputs are the business analysis approach because it talks about what was the approach that we are following in business analysis and performance objectives which will set the baseline against which we are performing the improvement assessment. The output is business analysis performance assessment. The purpose is to assess the work done by business analysis team to identify areas in which you can implement improvements so that we perform better business analysis in the future. Okay, the elements of business analysis performance improvement. So, what do we do? We first have a review of what happened, right? So, we talk to stakeholders, we look at the data that is available to us and we do a performance analysis how the business how well the business analyst has captured the requirements, was there any missed requirements, were there any delay in identifying requirements, what is the feedback from the stakeholders, were they correctly engaged? All those things will become part of the performance analysis. And the results that are coming out of those analysis would ideally have a set of measures. So, we would look at say for example, no missed requirement or no requirement defects or the stakeholder engagement score of you know, 80%. So on and so forth. So, you can define those assessment measures. Then you will analyze the results to understand okay, that which are the areas where we did well, which are the areas where there are opportunities for improvement and then there will be a list of actions for improvement which will then become the action item for us to uh, Okay? So, basically we look look at how well the business analysis activities went through and compare it against the expected outcomes and measures, analyze it, and then come up with the list of improvement areas, which will be then implemented in the future. Guidelines and tools you use organizational performance standards to evaluate, uh, the business analysis performance, uh, in a particular initiative. Uh, the techniques that we can use are um, listed here. We will take a look at the technique, metrics, and key performance indicators next. Um, but before that, since we are almost at our 2-hour mark, okay. So, you use metrics and KPIs. KPI stands for key performance indicators in order to measure anything that is of interest to the stakeholders. Okay? Now, what is a metric? A metric is a measurable, uh, indicator, or a measurable level of an indicator, right? Can anyone give me an example of a metric that we discussed so far in the class today? Retention ratio, okay. We did not discuss it, but retention ratio is a is a measurable, uh, indicator. So, retention ratio is uh, basically the opposite of attrition ratio. Uh, it could be for customers, it could be for, um, employees. So, if you're talking about customer retention ratio, how many customers uh, order from you or buy from you again and again is the retention ratio. So, a retention ratio signifies customer loyalty. So, you can say, "I need to maintain a retention ratio of 50% or above." That is an example of a indicator uh, or a metric. Uh, CSI, I'm not sure what do you mean by CSI, customer success I I am very happy with your answer with your percentage of wastage in the canteen, okay? So, how much food is wasted in canteen, right? Let's say we we kind of weigh it up and we say X kg of food is wasted in canteen, right? The amount of food wasted in canteen can be Okay, can be a good indicator or a good metric. Customer satisfaction index, okay? Net promoter score, it is also called. That is another good indicator of or metric. Increase Yes, percentage sale of online sales is a metric, okay? We will come to the increase part and the reduction part of wastage later. For now, we we are talking about a metric or an indicator, right? That indicator tells you how you are performing. Now, that increase part will come in KPI. I I I I'll come to that in a minute, right? Operation cost is an indicator, okay? Percentage of reduction, we'll come to that. So, let's take a few examples. So, we spoke about wastage in canteen in kg, the total wastage of food in canteen in kilograms, customer satisfaction index, retention ratio, percentage of online sales of StyleCart, as a the percentage of online sales as a percentage of total sales of StyleCart, operation cost and conversion ratio. So, that we have five metrics that we have identified, yeah? Okay, so, that's metrics. Now, what is a key performance indicator? Key performance indicator measures the progress towards a strategic goal or objective, okay? So, KPI is metric with a goal attached to it, right? So, if you take wastage in canteen as an indicator, right? Your KPI is percentage of wastage reduction in canteen, right? So, your goal is to reduce wastage by 30%. So, currently on an average on in a day, you waste, let's say, 1,000 kg of food. So, the goal is to reduce it to 700 kg. So, your kg of food wasted is your indicator or your metric. Your KPI is the percentage reduction in wastage of food. Customer satisfaction index, let's say, is currently at 75%. Right? So, customer satisfaction index is 75%. Your your KPI could be an increase of customer satisfaction in index by 10 percentage points. So, you want to increase it to 85%. Right? Uh the current um percentage of online sales to total sales is, let's say, at 10% and your KPI, so that's your indicator. Your KPI is to increase it to 25%. So, that is basically uh your KPI. Percentage of increase in Yeah, so the increase in percentage of online sales to total sales or total revenue. Okay, so that's KPI. So, KPIs uh measure So, KPIs measure what you want to measure, right? Suppose you want to measure the effectiveness of marketing. Okay? That is when you measure the number of people visiting your website as an example, right? If you are running a marketing campaign and people visit your website, that basically tells you that your marketing campaign is successful. Then you want to um increase the ease of using your website. And what measures it? Conversion ratio. If your easy your web- your is easy to use, people are likely to buy products from your website. So, that is your conversion ratio. So, similarly you define KPIs to measure the effectiveness of what you want to improve. If you want to measure the effectiveness of business analysis, you need to define KPIs to to measure that, right? So, for example, it could be number of missed requirements or number of requirement defects identified. Or it could be a stakeholder satisfaction index, right? So, those is those are examples of measures for business analysis KPI. Then there is reporting, which is when you are informing your stakeholders about the metric and the KPIs and how they have performed in various intervals, okay? So, that is metrics and key performance indicators. Now, what are the elements? So, there are a few characteristics for an indicator or a for a for a indicator for a for a metric, it has to be clear. There should be no ambiguity. It should be relevant. You cannot measure like there is a very interesting book called Measure What Matters. But anyway, so it should be relevant. You should measure what is what you are trying to improve. It should be economical. What does that mean? You should be able to gather that metric without too much of effort. It should be adequate. It should be enough to tell you that you are making progress. It should be quantifiable. You should be able to measure it, otherwise you cannot quantify it. It should be trustworthy. You should be able to rely on it accurately, right? There is this anecdote that I think the founder of Amazon, Jeff Bezos, gives in one of his interviews where he says there was this issue where customers were basically complaining that it takes a long time for them to them to connect to the customer service representative. So, they call the customer service in Amazon and it takes them a long time for anyone to pick it up and respond to their query. But, the Amazon management was tracking the time taken to complete a call and those numbers were were very small. So, the anecdotal feedback from customers was not agreeing with the metric that they were getting from what they were measuring. So, they were discussing this in the meeting. Apparently, Jeff Bezos called up the customer service on his phone and it took a long time to connect thereby proving that the customer was correct and the metric was was wrong. So, we should want to avoid such scenarios. We want to validate that the metric is actually trustworthy and credible. Now, your metric can be a specific point or it can be a threshold or it can be a range, right? So, you it could be that, right? It could be, I want to achieve a certain sales. So, you want to increase your sales by let's say 10%. So, that is a very specific point that you want to achieve or you want a threshold, right? If you take, say for example, your blood sugar levels, the threshold is you want to keep it below a certain threshold. As long as it is below, it doesn't matter what the number is. You don't want to reduce it further or any of such things. You just want to keep it below a certain threshold so that you you are healthy, right? Or it can be a range, right? It can be within, you know, a value of say 10 to 15, but it should not go below 10 or above 15. Again, medical metric is an example. You don't want your sodium to go very high or very low, but it should be in a very very specific range. So, depending on your scenario, your metric could be a specific point, a threshold, or a range. You need to continuously monitor your metric and report the baseline and the new targets, right? So, that's basically about metrics and key performance indicators. So, KP I don't know what KPA is. Metric is food wastage. KPI is reduction in food wastage by 10%. Okay. Metric metric is uh food wastage and KPI is reduction in food wastage. Okay. Now, stakeholders involved in business analysis performance improvement uh domain SME, sponsor, and project manager. Okay. So, let's look at a case study. Okay. So, we are talking about a company called Betonix Pharma company. So, they specialize in pediatric medicine. The company is facing problems meeting product delivery deadlines, which results in some customers switching to competitor products. So, you are working as a business analyst and you are asked to provide solution to the business problem. You have identified the business analysis deliverables, which is documentation of existing supply chain management process, root cause analysis, solution options, recommendation of tools and technologies, and recommended optimal solution. So, these are the deliverables that you are going to deliver as part of your work with Betonix Pharma company. There are There are many areas of improvements, and you have decided to progressively plan activities based on the priority of the improvements. Stakeholders involved in the process have been identified and analyzed. You have also reviewed existing documents. You had some meetings with subject matter experts and people involved in this process and come up with the activities required. You have also estimated the activities and identified those who are involved in performing them. The process of decision making, change control, prioritization, and approval process has been established. You have also determined how you are going to store and retrieve business analysis information. You have had meetings with key stakeholders to review and get approval on the business analysis approach. Okay, so you have completed all these things. Now, let's look at a few questions. Okay, we will start. First question, right, here we go. Which document is created to define decision making, change control, prioritization, and approval process? Information management approach? BA governance approach? 4 seconds, 3 2 1. Okay, most of you got it correct. It's BA governance approach. You define information management approach to identify um areas of uh how you are going to manage the information collected as part of business analysis activity. Okay, next question. Which methodology is used to define business analysis approach in our Betonix Pharma case? Predictive? Adaptive? Okay, again most of you got it right. It is adaptive because the details the the reasons I mean the requirements are not very clear. You need to do it incrementally and iteratively. Next question, question number three. Which document specified specifies the level of responsibility expected from each stakeholder. RACI metrics or stakeholder metrics, the level of responsibility expected from each stakeholder. 5 seconds. Okay, most of you got it correct. It is RACI metrics. Next question, which technique is used to identify roles and responsibilities within the organization? Organizational modeling BA performance assessment. 7 seconds. Okay, almost all of you got it right. Good. Next question, which is which document shows how stakeholder is involved with the solution? Stakeholder metrics or stakeholder onion diagram. 10 seconds. Okay, half of you said stakeholder metrics. Stakeholder metrics doesn't show the level of involvement with the solution. It is the onion diagram that shows how close you are to the solution delivery. Next question, which task is performed to identify and analyze the stakeholders? Plan stakeholder engagement personas. Um, to identify and personas is not a task. It is a technique. The answer is plan stakeholder engagement. Okay, among stakeholders, who are not likely to get involved in this initiative? Regulators or domain SME? Okay, majority of got it right. It's regulators. Now, I think the questions are more general, not based on the case study. What does RACI stand for? 9 seconds. That's correct. Most of you got it correct. Good. Uh the next highest one is this one. Uh it's not collaborate, it is consulted, which is there. Two more questions. Which of the following is not a characteristic of indicator? Relevant, economical, transparent, adequate. 5 seconds, 4 seconds. Okay, most of you got it right. It is transparent. Uh relevant, economic, and adequate are indi- characteristics of a good indicator. Last question. Which of the following is not an input to business analysis information management approach? Business analysis governance approach, business analysis approach. Uh bus- uh stakeholder engagement approach, and business analysis traceability approach. 3 seconds. Okay, most of you again got this right. It is business analysis traceability approach. Okay, let's look at the leaderboard. Nikith, good job. Purva, Sema, Lena, Anshuma. Excellent. Okay, with that oh, link was not loading for you. Sorry. Sorry, Sultana. We'll check again. Should load, but not sure what happened. Okay. Um with that, we come to the end of the business analysis planning and monitoring knowledge area. So, business analysis appro- approach, uh or plan documents business analysis approach, stakeholder engagement approach, BA governance approach, and be a information management approach. Uh the BA approach is uh is for is developed based on need, methodology, complexity, size, and risk. Uh stakeholder engagement, governance, information uh management will explain how stakeholders are engaged, governance is managed, and and information is maintained. The business analysis planning and monitoring area governs the entire rest of the knowledge areas. Uh we looked at some techniques, lessons learned, organizational modeling, stakeholder list, RACI matrix, metrics, and key performance indicators. Uh business analysis performance assessment is used for evaluating the work of a BA. That's basically it. With that, we complete business analysis planning and monitoring, which is our second knowledge area, which is elicitation and collaboration. So, what are we going to cover here? We will look at prepare for elicitation, which is the first task. Then conduct elicitation, which is the second task. Confirm elicitation results, which is the third task. Communicate business analysis information, which is the fourth task. And manage ongoing stakeholder collaboration, which is the fifth task. That is the goal of this particular um lesson. Um let's look at business analysis core concept model and how the concepts are impacted in this particular knowledge area. Um the goal of this knowledge area is to get information from stakeholders. So, elicitation is when you go to stakeholders to get information. It could be for current state analysis, it could be for root cause analysis, it could be for business requirements, stakeholder requirements, or solution requirements. In this knowledge area is where this knowledge area is where we identify what are the characteristics that are going to define the change. We identify the concerns of our stakeholders and uh the extent of uh elicitation requirement in order to implement the change. From a need perspective, in this this knowledge area the tasks in this knowledge area are used to get information from stakeholders as well as to confirm that back with them and to communicate uh that with the stakeholders. The solution will be defined by discussions with stakeholders. So, we should first get solution requirements from the stakeholders and then communicate back how the solution is going to uh be designed to the stakeholders. Uh the collaboration with stakeholders is key in this particular uh knowledge area because we are interacting with them in all the tasks and the context is also identified critically in this knowledge area. Uh we also will look for identifying value from uh elicitation and collaboration. So, the whole overall the goal is to manage interactions with stakeholders to get information from them. So, there are five tasks. Uh the first three are sequential. Prepare, conduct, and confirm elicitation results. Okay. So, at this stage I need three volunteers who are ready to come on come on uh on on audio. I will unmute you. Uh but the criteria is is you should be you should have gone through the canteen order management system case study that I had asked you to go go yesterday. I need three volunteers who has gone through it. I'll pick them. If you can mention in the chat box, I will if you are okay to do that, I will unmute you and then we will have a quick exercise which will demonstrate how uh business uh elicitation actually take place. No volunteers. Don't don't worry about it. I'll will help you through that. Okay? So, the first activity that you do when you are performing an elicitation is to prepare for elicitation, right? So, that is exactly what I did. So, I asked you to read through the case study. I asked for people who actually have read through the case study and asked them to volunteer. I unmuted them. So, all these things are basically what you do when you are preparing for elicitation. You will define the scope of your elicitation activity. You identify your stakeholders. You arrange the logistics for the elicitation activity to take place. Okay? Then you conduct elicitation, which is where you let your stakeholders speak about the topic that we are interested in. In this specific instance, we were interested in the requirements from an employee perspective for streamlining the the lunch process in Unilever canteen. The next is confirm uh So, when you conduct the elicitation, you will also make a note of the requirements. So, you saw that in my Word document, I was noting down the requirements that Sema was giving me. Then we confirm the elicitation results, which is once you complete the requirement uh gathering or the elicitation activity, we send it back to our stakeholder who were involved in that activity and make sure that uh what we captured is accurate. So, the inputs for those are the needs and the business analysis information. The inputs for communicate business analysis information and manage stakeholder are stakeholder engagement approach and business analysis performance assessment. These three are sequential tasks as we discussed. The outputs are elicitation activity plan, elicitation results that are unconfirmed, elicitation results that are confirmed, business analysis information that is communicated, and stakeholder engagement. Let's go through the first task, which is prepare for elicitation. So, preparing for elicitation involves understanding scope of the elicitation activity. So, just the example we just saw as we as we had the kind of role play, the scope was identify requirements for the lunch streamlining of at Unilever canteen from the perspective of employees. Select appropriate technique. The technique that I was trying to do was workshop with three employees, but unfortunately we couldn't get the other two unmuted. So, the actual technique that we ended up using was what we what we call as interview. We will see that technique later on. So, obviously in this scenario, the supporting material was the case study. So, we shared that ahead, but in actual scenarios, what will happen is that there will be things like operating procedures, existing documentation, previous business analysis information, all those supporting materials will be sourced by the BA so that they can go through it so that they can get the background of the the elicitation activity. Now, the inputs to this activity are the business needs. So, we know the business needs for the canteen ordering system and the stakeholder engagement approach, uh, which we will use for deciding which stakeholders should be involved for uh, requirement analysis. The output is what is called an elicitation activity plan, where we will have the logistics of the uh, elicitation activity. So, here obviously since we are all in a meeting, we I could just unmute her. But, in in several scenarios, what you would require is you need to arrange a Zoom call or you need to arrange a room uh, a meeting room. You need to make sure that they are free at that time. Right? They they might have their own other work, so they need to be available at that time. So, we need to take care of logistics. You need to define the scope of the elicitation activity. You need to select the technique that you are going to use and prepare any supporting material. So, that's basically the output of the prepare for elicitation task. Uh, for preparing for elicitation task, understand the scope again. The scope was the employee perspective for um, the canteen order management system. Selected a technique, which was interview. Set up logistics by uh, unmuting and or using the the Zoom functionality. Any supporting material, we sent across the case study. And prepared the stakeholders. I explained uh, Sema that, you know, what we're trying to do is get the employees concerns and challenges and the requirements uh, as part of requirement uh, analysis. Guidelines and tools, we use business analysis approach as a overall guidance when to do elicitation. Uh, so that is one. Business objectives will provide how are we going to move towards future state. So, the goal is to reduce wastage and to reduce uh, employee time, which is sent unproductively. That will help guide that elicitation activity. Uh, existing business analysis information will help you to understand the scope better. And potential value will explain what value are we trying to realize from the uh, activity. Uh, techniques that you can use for preparing for elicitation are stakeholder map list or personas. We'll tell you who needs to be consulted. You can brainstorm and mind map to identify techniques uh, and business analysis information for the the the elicitation activity. Uh, you can use document analysis to go through the previous or the supporting material. Data mining is a technique that you can go do where you use a lot of data to derive derive insights from it. You can use estimation to identify how much time it will take for the elicitation activity. You can use interviews and risk analysis and management. So, these are the techniques uh, that you can use. Uh, stakeholders who are involved are domain SME, sponsor, and project manager. So, domain SME can provide supporting material and guidance. Sponsor will approve or denies the uh, elicitation activity plan. And project plan uh, manager make sure that the resources are available for elicitation. So, that is on the prepare for elicitation. Fairly simple. Uh, you define the scope of elicitation activity. You arrange the logistics. You pick a you pick a technique. Uh, you inform the stakeholders, get them ready, prepare the stakeholders for the elicitation activity. Okay, here one employee was present how we make sure it is a need of the majority. So, generally what happens is that we identify somebody as a domain SME in this scenario. So, the employee that you select will not generally be any random employee. It will be somebody who can represent the rest of the employees. And we try and have more representation. So, that's why I was trying to have two, three people so that there can be multiple uh, um, options coming through. But, obviously in these scenarios we cannot have the entire 1,200 employees or even a majority of them represented. So, what you will do is you will pick and choose specific people who has been there for some time, who are much more well networked, who So, the management will generally help you do that. Who is more articulate as well, who can contribute. So, you identify these people based on some amount of expert judgement. But obviously we cannot have a majority participate in the requirement. We can conduct a survey. We will cover the survey as a technique later on. It is one of the techniques that you can use for elicitation results, but the problem is obviously when when you have a lot of subjective information, it is often much difficult. Like for example, if you send out a a questionnaire where you have very very very detailed descriptions given by 1,000 employees, how are you going to then analyze that in order to get results out of it, right? We can always once we decide a solution, we can always ask that we can always ask employees from that solution as to whether that solution will be acceptable to them using a survey. But that is not easy, especially when you are trying to gather information at the outset about requirements. Okay? Let's look at then conducting elicitation. Okay. Why do we say elicit? Why don't we say gather, right? Because elicitation the word means to draw out. So, you actually make your stakeholder speak, right? You explore with them what are the different requirements that they have and identify those requirements. So, that's basically requirement elicitation or conducting elicitation. The inputs into conducting elicitation are the activity plan that we prepared for the the previous in the previous task and the resources and the supporting material that we have collected. The output is unconfirmed elicitation results. Now, there are three ways in which you can perform elicitation. So, the first is collaborative, which is when you interact with stakeholders, which is what we did in our example. You rely on the stakeholders experience. So, the stakeholder has to be So, now obviously the the the employee the employee example or the canteen ordering example is a very simple case, right? Imagine we have something more complicated like banking or insurance. I think somebody was mentioning yesterday they work on insurance. So, if you have an insurance use case, the requirement can be fairly complex. So, the stakeholder cannot be anybody, right? You cannot pick any employee working in insurance and get requirements for a problem in insurance. It has to be an SME, right? Domain SME. So, you interact with a an SME who has a lot of experience and your outputs will be dependent on the level of experience of your stakeholder. The second way is research where you go through a lot of documents and you uncover information which your stakeholders themselves may not know. So, this is particularly effective especially in what we call as regulatory projects, right? So, every now and then regulators come up with a set of requirements that everybody has to adhere to. It could be laws, it could be requirements. So, uh you are I think many of you are based out of India. I don't know if you are if there are people not based off India, but in India for example, there is there are some laws that are changing where the salary structure has to be has to be in a certain way for example. That means that all HR departments will have to re-look at how their employees salaries are structured and they need to make changes for that. Now, obviously nobody knows about this, right? So, you if you refer to the regulations text that will help you better than any stakeholder probably. So, that is where research can be a good way of conducting elicitation. The last one is experiments, okay? So, this is especially used when you have to get feedback from a large number of um stakeholders, okay? So, one easy example that always you I I always use is called AB testing, okay? This is when you have two options. So, you you Let's say you have a checkout page and there are two places where you can keep this checkout button. Okay, there is a button that says checkout. You can keep it either at the bottom of the page or you can keep it on the right-hand side and it will be visible at every point when you scroll through the page, okay? You need to decide where to place it. Now, whom are you going to ask? Your customers are probably thousands or if if not millions of people. So, you cannot go and ask millions of people. So, what you do is you roll out both options. So, there will be a page where you have this button on the right-hand side which scrolls with the page or and there will be another page where it will be at the bottom of the page. Then you roll this out to let's say two sets of users and evaluate how they respond to it. If they respond to favorably to option A, which is the one on the right-hand side, you will go with that. If they are responding favorably to the option B, which is the one where it is on the bottom, you