Transcript.txt

(183 KB) Pobierz
Course Overview
Hi, I'm Casey Ayers, and welcome to my course Planning For Business Analysis. I'm a project manager and strategic consultant with experience in a variety of fields. I'm also the author of Pluralsight's series of PMP Prep courses, and now it's my pleasure to explore the world of business analysis with you. Business analysis is increasingly vital to today's business environment by identifying problems and opportunities, discovering and recommending solutions, and fostering a comprehensive understanding of stakeholder requirements. Business analysts can help organizations choose and structure projects and initiatives more effectively. This course is the second in a five course series on business analysis. Some of the major topics that we will cover include identifying and analyzing stakeholders, the relationship between project management and business analysis, creating a comprehensive business analysis plan that sets your team up for success, and earning approval to move ahead with the important work of business analysis. By the end of this course, you'll know what questions to ask and what topics to consider in creating a plan for successful business analysis. Before beginning the course, you should have an interest in business analysis, and at least a bit of exposure to project management or business analysis within your organization. This course and others in the series can help you not only learn more about business analysis, but also prepare for business analysis certifications like the CBAP or PMI-PBA, or to earn continuing education credit towards certifications like the PMP. I hope you'll join me on this journey to learn more about business analysis with the Planning for Business Analysis course at Pluralsight.

Planning Business Analysis
Course Introduction
Hello and welcome. I'm Casey Ayers, and this is Planning for Business Analysis. In this course we're going to take you through different components related to the planning process, to ensure that our business analysis efforts are going to be successful. First, we'll look at what you should expect to include in the business analysis planning process, and what you might expect to see in your final analysis plans. After that, we'll take a look at analyzing stakeholders. Stakeholders, of course, are critical to the business analysis process, as it's their preferences and requirements that we seek to compile in order to create whatever the final solution or proposal for the solution might end up being. After that, we'll look at the relationship between business analysis planning and project management planning, how we should work together with project management leadership in order to ensure a smooth transition from the important work that we're doing, to the important work that they'll do based on the requirements that we help to create. Then we'll look at creating a business analysis plan, how we take the information we've put together, and all of the different preferences and structures that we've created up until this point, and put them together into a workable plan that we can move forward with. Then we'll look at specifying business analysis plans. In other words, adding specifications and details that we're going to need to that structure in order to better understand how we're going to seek out and elicit these requirements from stakeholders, and make those into some sort of meaningful document and path forward for the project management team in the future. Finally, we'll look at moving those business analysis plans forward, getting that buy-in from stakeholders, project sponsors, and others that allow us to move forward with our plans, and begin the important work of business analysis. This is the second course in a five course series on business analysis. The first course in this series is Introduction to Business Analysis and Needs Assessment. If you haven't seen that one yet, I'd encourage you to go and check it out, and make sure that you're familiar with some of the foundational concepts of business analysis before moving forward. In this course we're going to focus on the planning aspect of business analysis, and in the courses to come, we're going to look at discovering information through elicitation, taking these plans that we've set, and moving forward to interview stakeholders and to gather information necessary to then move forward into conducting business analysis, and developing a list of requirements for our work. Then in the final course we're going to look at monitoring requirements and evaluating business analysis solutions. Some of that important retrospective work we do, either near the end of our analysis process, while project work underway, or even once project work is complete, to understand how we did in terms of outlining requirements versus what our objects were, and how well those fit the business need, and to learn more about how we can continue to improve in the future. This learning path is helpful for those who are considering business analyst certifications, such as the PMI-PBA, as well as the CBAP. It's also useful for those seeking continuous education credits, such as those who might already have a PMP certification, and want to learn more about the business analysis process. In this module we're going to begin by looking at the value of planning business analysis, why we take the time to think this through before moving ahead with elicitation and definition of requirements. Then we'll look at the difference between planning for business analysis and planning for project management. Finally we'll look at the scope of business analysis, and what we seek to achieve, and therefore have a better idea of what we need to plan for. Let's get started.

Value of Planning Business Analysis
When we introduced business analysis in the previous course, we said that it really consisted of four key steps. First among these is to determine problems and to identify business needs. That's some of what we try to accomplish during needs assessment. Moving forward, we then identify and recommend viable solutions in order to meet these needs. Following that, we want to elicit, document, and manage stakeholder requirements in order to meet business and project objectives. So up until this point we've identified our needs, we have come up with some solutions that might be able to meet those needs, and now we've begun to develop, and document, and gather the requirements to make those solutions come to life. After that the final step is to facilitate the implementation of the product, service, or end result of either the program or project that typically follows a business analysis process. Now each of these four different components can potentially suffer if we don't take the time to effectively plan our business analysis activities. When it comes to determining problems and identifying business needs, we may not fully understand what the business requirements are if we don't plan properly for our business analysis. We might not have the correct amount of time with stakeholders to understand the issue at hand, we may not have gathered the information necessary to fully understand the issue at hand, furthermore, even if we believe we have a full understanding, we might actually have a misunderstanding regarding what our business needs are. This can lead to mistranslation of problems into needs, where we think we understand what the problem is, but we really haven't figured it all the way out. In some cases, this may truly be a misinterpretation. In other cases, this may be a failure for root cause analysis to dive deeply enough, to get past symptoms, and to understand what the true underlying issues might be. When it comes to identifying and recommending viable solutions in order to meet needs, we may not fully solve the underlying problems or meet all needs if we don't plan properly up front. We may also lead to an over-engineered or costly solution. So in either case, we really haven't done our job very effectively. If we don't plan properly, perhaps the solution that we recommend doesn't really consider all aspects of the problem at hand, or we may end up thinking that we need a very complex overhaul of a wide number of systems in order to solve the problem, when in fact there was a more pragmatic and elegant solution available to us, if only we had been able to dive a little deeper, or understand the root problem a little more clearly. When it comes to eliciting, documenting, and managing stakeholder requirements in order to meet those business and project objectives, poor planning may result in us not being clear on which priorities are truly most important. We may think that the ones that we hear about most often are the ones that should be highest on the list, but if we are hearing about certain requirements being absolutely critical from some of our most value stakeholders, the ones who truly understand the problem best, or need the solution the most, then we really need to consider their feedback more strongly, and weight it more heavily than those who might be interested in the project, but not actually have a direct stake. Furthermore, we may have a lack of support from our stakeholders, given a lack of contextual understanding of the project that's taking place. If we don't build the solution in order to properly address their needs, then it won't be supported. Just the same if we don't build that support by helping them understand how we are meeting their needs, and why this is important, than we may not be able to move forward successfully either. Finally when it comes to facilitating the implementation of the product, service, or end result of the project or program that follows up on our business analysis, we may not have a complete implementa...
Zgłoś jeśli naruszono regulamin