The PMI-PBA Certification

0:00All right, welcome to skill number one of the PMI PBA Professional Business Analyst course. I'm Bob Mailer. I don't know if you've trained with me before, but if you have, I appreciate you coming back. If you haven't, well, you're gonna find out I'm a little quirky. I like to have fun, but I'm not just gonna sit here and regurgitate information to you. That's not how I train. I've sat in plenty of bad training classes before, and I vowed I would never do that to you. So remember when I said I was quirky, because you will see some of them come out. I'm a project nerd. I love this stuff. I am a multi-credential holder from PMI. I have one or two from the Scaled Agile folks and the Scrum.org folks. I'm not a big fan of getting certifications just for the sake of getting them. I do pursue the ones that make sense, that can actually emphasize something else I've learned or perhaps plug in a gap, but I love project management in all of its various forms. It brings order to the chaos, and sometimes it takes a while, but we eventually get there. So this is skill number one, and I'm going to tell you right up

1:15front, this will last a while. Probably 40 plus skills, and it will constantly evolve as we go. I'm not one of those fixed people that says, all right, this is starting point A, and this is Z, and we will not deviate from that no matter what. I will deviate. I will go left. I will go right a couple of degrees just to make sure that you're having a fun course. It is informative. It is hitting all the marks you need so you have a clear understanding of what it takes to pass this cert, and so you aren't bored. I'm just not going to do that to you. So once again, welcome to the course, and before we start modeling workflows or eliciting requirements or building traceability matrices, we need to answer one simple question. What exactly is business analysis? Well, it's a discipline of understanding problems before organizations invest time and money building solutions. It's basically ensuring we don't put the cart before the horse. Done well, it prevents organizations from solving the wrong problem, but done poorly, projects deliver solutions that technically work but fail to deliver value. Think of it as the 90% solution. You solve most of it,

2:36and right now you're okay with that last 10%, but that right now moment only lasts so long, and eventually, and usually not very long, you realize you didn't solve all of the problem or maybe not even the root of the problem. So in this course, we're going to explore business analysis using a continuous case study called PulsePoint Medical. They are a healthcare technology provider facing operational and scheduling challenges across their network of clinics, and throughout this course, you are going to be the business analyst. You will be responsible for helping PulsePoint identify problems, define solutions, and measure business value. You're going to get case studies you need to read. You're going to get artifacts you need to digest and understand, and then you will be asked review questions based on that material. I was never going to just show up and give you the concepts, inputs, tools, outputs, and ideas of PMIs, PBA stuff without anchoring it in a case study, because I've been in all of those courses, and they stink.

3:48This one will start anchored in PulsePoint Medical, and trust me, this ain't my first rodeo. You're gonna love it.

0:00All right, let's jump into section one, what business analysis actually is. Now many people think business analysis is about writing requirements documentation, but that's only a small part of the job. It's really about understanding problems, identifying opportunities, and helping organizations make better decisions about solutions. And let's face it, there are usually multiple solutions, and the only real difference is time to implement and the cost.

0:31Business analysts act as the bridge between business needs and solutions that deliver value. So let's check out the graphic for just a moment. I told you we would talk about PulsePoint Medical. Here we are right here, and here we may see the hospital CEO who has mentioned to some sales people at some point that they're having a problem. And of course, they show up and they have a widget, and the widget does A, B, C, and through Z, and it sounds really good, but does it address the underlying root cause of the problem? And does it actually take them to the solution that they actually need?

1:13And the answer is, I have no idea, but I know who knows, and it's this guy, the business analyst. He's actually looking at the problems they are trying to solve before they ever look at solutions, because you can run into something called solution bias. It looks great. It looks shiny. It looks cheap. You can have it right now, and you can justify it on a motion and then try and validate it later on on data, but that doesn't mean it's going to do the trick. Business analysis starts with understanding the problem long before you get to the solution. So let's clear the board and hop into this. Now right out of the gate, I need you to track down the exam content outline so you can see the five domains. I'll drop it below so you have a copy of it, but here are the five domains.

2:05You have the needs assessment, which is about understanding the business problem, not potential solutions, the problem itself, and then you have planning. It's pretty easy. How can you do anything without a plan? And the answer is, you shouldn't, but you can, but then you can't measure your progress. So the plan is all about differentiating problems, symptoms, solutions, and trying to figure out how to get to it. Well, then you have analysis, understanding what's what. What are the needs? What are the opportunities? What are the threats? What are the potential solutions? And then how are we going to measure it? We can't measure it if we don't have a clear problem statement, and yes, I'm writing at a weird angle, so I apologize if my arrows look like spaghetti. It's not on purpose.

2:59It's just the angle I'm trying to write at on this digital pad, so if it's confusing you, it's the pad. It's not me. And finally, we have evaluation. How do we know we've actually solved the problem? How do we know we've actually delivered value? I'm fond of saying if you can't measure it, you can't manage it. I'm also fond of saying that if you can't measure it, you can't determine the variance, and the variance is the difference between what you said you were going to do and what you actually did. Well, the variance in this case is identifying the problem, identifying the solution, and then actually determining if your solution took care of the problem or if it just created others or if it left residual nonsense somewhere in the background that you now have to deal with. So let's unpack this a little bit more and talk some more about business analysts. Let's go over here to the white board because I actually have one. Oh look, there it is. So business analysis focuses on understanding problems before implementing solutions. I think I said it earlier, but it's worth saying again.

4:12I can't even begin to count the number of times I've sat in meetings where we've started to pull at the root cause of a problem and someone pops up and says, oh my gosh, I know exactly what we should do to solve this, and we haven't fully unpacked it yet. We aren't even sure we are at the real root cause. There's something called Pareto's law, and 20% of your root causes result in 80% of your problems, but you can have multiple root causes resulting in a single effect. It goes both ways, and so jumping to the solution before you get to the real problem happens all the time, and it's very dangerous, and business analysis is trying to avoid building systems that don't solve real problems. How many times have we seen that? Oh wait, I can think of a great example.

5:02Not long ago, Boeing built the 787 or the 7800 or the 800 max jet. I'm forgetting the nomenclature right now, and two of them crashed, and upwards of three or four hundred people died. Well, they knew early on there was a design flaw. They didn't fix the design flaw. They came up with a solution that was supposed to counteract it, and it didn't. It made it worse, and for a couple of months, those jets were grounded. They couldn't sell any of them, and they're under investigation by the Department of Justice in the United States, and I may have gotten some of the small details wrong here, but I'm not wrong about what happened. They knew there was a problem. They clearly understood it, and instead of solving the problem, which would have taken longer and cost more, they did something different. The solution they came up with actually made things worse for them.

5:58One easy recent example. Business analysts help stakeholders understand exactly what they need. They help them define it, analyze it, and communicate it, because sometimes stakeholders don't know. They just have an idea, but when we help them, when we elicit information from them, we can help them figure it out, and the discipline exists across all kinds of projects, whether they are agile, hybrid, or predictive, as well as operational environments. Process flows. Doesn't matter. Business analysis is always going to be seeking the root cause of the problem before you start aiming towards a solution, and it happens all the time. Before, during, and after. It is continuous. Look at the life cycle of any given product these days. Do you really think they stop once they've delivered that product? No. How many iPhones are there?

6:55About 11. There are bunches of them. They're always analyzing what worked well, what we might improve on, what customers want, the size, the weight, the battery capacity, the range, and the list simply goes on and on, and the goal is always the same. Delivering measurable value. If you can't measure it, you can't manage it. You can't determine if you've actually achieved value, and value may not just be return on investment. It could be an increase in your public awareness for your particular brand. It really does depend on what game you're trying to play here, but let's keep going. I think I've got two more. There we go. Business analysts also make sure that technology and strategy stay aligned. It's really easy to go from here to here if you're paying attention, but if you don't keep your eye on the prize, it's really easy to drift off a couple of degrees, and again, you'll deliver something, but it may not be the something you need to actually solve the problem, and finally, good analysis reduces risk. The risk of rework, the risk of defects, the risk of unhappy customers, the risk of revenue loss.

8:10It improves decision making because it's gated opportunities to say, yay or nay, we're on the right path, and because of that, it should almost always increase your project success rate.

0:00So welcome to section two and let's talk about the role of the business analyst. Now it's a unique role. They're not typically responsible for building the solution or even managing the project. We've got other people for that. Instead, they help organizations understand what problem they are actually trying to solve and not just what they think it is and what the solution should actually accomplish. So let's take a quick look at the pulse point business analyst here and look at the interaction.

0:30And I previously told you that PulsePoint Medical is going to be our case study throughout this course. I've used them several times. They are fantastic. They are fictitious. They are made up. They are a great example for this. So you have the regional hospitals. They have three of them. Well, they're into remote patient monitoring, various devices for cardiac anomalies, alerts, stuff like that, interactive, in the clinic, at home. There are several touch points, really interesting tech and it actually does exist. If you don't believe me, I'm wearing some tech right here.

1:07You're Fitbit. If I can monitor my heart rate here, why can't they monitor someone with a heart condition? And the answer is they can and they actually do. And they've got plenty of data and metrics. Well, they've also got plenty of stakeholders and every stakeholder wants something different. A stakeholder is anyone who believes your project or your product might have a positive or negative influence on them. So you almost always have positive stakeholders, but you can have negative stakeholders, too. People actively working against you. People that want to see you fail because in some way, shape, or form your failure elevates them. But then we have the end users, the patients themselves. They also have a different need.

1:56Maybe it's time to delivery. Maybe it's freedom to go outside and live their life. Maybe it's simply cost. Maybe it's just so their insurance company will pay for it in this specific example. And trying to balance all of that out is the business analysis team. I may actually call them the BA team or maybe even the BAT. I don't know, but almost every organization that produces a product, a service, or a result has a business analyst somewhere. It really does depend what they're doing and what they actually call them. So let's go forward and dig into this role a little bit more. So here we go. They identify problems and opportunities. Now when I say opportunities, that's something good. Again, the easiest way is reactively. There's a problem. There's a business problem.

2:49So they help track down what it actually is. That one's easy, but the other one is a gap in the market. They see an opportunity because no one's fulfilling this particular role. No one is providing this service. So they go, wait a minute, we're already doing 85 percent of this, but if we just add this other 15 percent, I'm making sure I'm actually adding to 100 percent, we can actually move the market in our direction as the sole provider. They do that. That's actually really cool stuff and value add in any organization. So when there's a problem or an opportunity, they have to work with the stakeholders to understand their needs, their expectations, their desires, their demands, their wants.

3:34They also have to understand what is spoken and what is unspoken, sometimes referred to as supportive. If you tell me I need to have something sent to you by Thursday of next week, that's your need. Maybe that's your requirement, but the unspoken requirement is I need to actually mail it some way. Am I sending it through snail mail or UPS or FedEx or if it's really high-end, is there a courier? You may not tell me that.

4:05I might have to figure that out on my own, but unless I have the supportive requirements straight, there's no way the spoken requirements are going to be met. I know you understand that, but I like to say it anyway because I like to be very clear about the direction my mind is moving in. They define requirements for solutions. Requirements, things that are required. It must be less than this weight. It must be this wide. It must be this tall, this thick. It must have an input power of this.

4:36It must have a throughput speed of that, whatever it is. It really does depend, and there is no set rule for one set of requirements working for this device and the same set working for the one over here. It's different almost every single time, and in fact, I would say that in every case, it's different in some small way. So they translate the business needs into structured solution requirements. Notice it says structured. This is not haphazard. It is not made up. There is a very clear way to go from problem to solution to measuring to adjusting. In fact, you could actually think of this as the Deming cycle.

5:24Plan, do, check, act because the wheels on this bus go round and round in an iterative feedback loop fashion, and there's nothing wrong with that. I'm fully supportive of it. I love it. Now if I can just figure out where I went. All right. They analyze workflows. What works well, what's not working well. Systems and processes. Workflows. You might be wondering why. Well, think of the kinds of waste. The waste of waiting. The waste of overproduction. The waste of transportation. The waste of defects.

6:02The waste of skills, and I believe there are eight of them, and a couple of them are escaping me, but think of it this way. If you want your process to be lean and mean and taking the most efficient time to get anything done, that's where workflow analysis comes in, and they can also help you figure out if solutions really deliver business value. Easy example. Let's say you commute to work and you want to get a smaller car with a better mileage per gallon rating. You go to the dealership. You find one. Maybe it's new. Maybe it's used. Whatever it is, and it says 35 miles to the gallon on the highway, and so you buy it because you calculate that this is where you need to be for the best return on your money. You bought the car. It needs to actually achieve 35 miles to the gallon, but how do you know? Do you calculate how many gallons you put in? How many miles you've actually driven? Divide one by the other and see it, or can you actually measure it with some sort of device in your vehicle? Because in both cases, the answer is yes, and a business analyst can help you figure out what might seem like a good way to measure success and what might be a much better way, even scientifically, if you will,

7:18to measure it. They're almost always very different. They're also facilitators between business and technical teams. The business people are talking macro level. The technical teams are talking micro level. Good business analysts can bridge that gap because they can speak both languages, and trust me, if you've ever worked with diehard engineers, you know they're not good with macro language. They need it to be as clearly defined as possible, or they're just not going to have that conversation. And finally, they help you make better decisions. There are almost always multiple potential solutions for any particular problem, but which one is best? The answer is you probably need a business analyst to help you figure it out in some kind of measurable way.

0:00Okay, let's talk about the BA, the project manager, and the product owner. Because one of the most common sources of confusion is the relationship between the three. And I'm talking about the business analyst who determines the actual problem. And I'm also talking about the product owner who's going to determine which element of the solution delivers the greatest value. Maybe it is an iterative delivery. We have to figure out which is best to go out first, second, third, last, whatever it is. And then you have the project manager. Project manager actually delivers it.

0:42They may all three exist. It may be one person. It really does depend. And understanding the distinction helps clarify where business analysis fits within projects and product development. So there's a lot to unpack there. Let's keep going. Let's actually do that. So let's talk about the project manager. I am a project manager. In fact, I'm proud to say I am consistently an above average project manager. Being an excellent project manager is hard, but I can maintain above average almost indefinitely. So that's what I strive for. My job is delivering products within the triple constraints. And if you aren't familiar with the triple constraints, it's scope, schedule, and cost. And the triple constraints really means you can't adjust one without impacting the other two. In my opinion, that's absolutely true. In fact, I call them the triple complaints all the time.

1:44But here's the kicker as it relates to the triple constraints. Not all of those constraints are equal. You have cost. That's the money. You have schedule, which is time. And time is money. And then you have the scope, what they actually want. And the difference between what they want and what they actually need is money and time to deliver. So in my humble opinion, in my learned opinion, it is almost always the cost or the scope. The schedule is simply the gap between this is what I want and now I actually have it. But that's just my opinion and I may be a lunatic. I don't know.

2:29It depends on who you ask. Well, the analyst is focusing on defining and analyzing the actual need. And I said it a moment ago, there's what I think it is and what I want and there's what it actually is and what I need. There's a huge difference in cost between what I think it is and what it actually is. And sometimes I'm so focused on an individual solution that I become blind to everything else. I get so far into my own feelings and what I believe the impact is to my client, my business, my customers, my end users, that I can't think clearly. A business analyst normally keeps a very neutral space on the things they see and the things they recommend. And there's nothing wrong with that. You need people like that as a sanity check. Well, then you have the product owner. In an agile space, they're responsible for the product backlog. They decide what delivers the greatest value in the next iteration. And they can constantly change that backlog based on the feedback loop, the feedback they're getting from the clients, the end users, the stakeholders,

3:46the developers, depending upon who it is. So it's always evolving. And if you don't believe me, just think about Windows. I remember Windows 3.11 as an operating system and then 95 and then 98 and then 2000 and then NT and then XP and then 7, 8, 9, 10. I think we're on 11 right now. That product lifecycle has extended for decades and they keep actually trying to deliver value. And one of the greatest inserts I've seen lately, now the Windows operating platform can be AI-driven as well.

4:27Don't ask me how that works, but I saw it the other day and I thought it is just constantly evolving. Who has any idea what it will be in the next 20 years? And if the Windows operating system isn't working for you, just go back and think about the iPhone. Think about the iPad. Think about the iCloud. Think about the iWatch, the iEverything. Constantly evolving and constantly trying to deliver greater value in that particular environment. So PMs execute. We may help you with the requirements. We're likely going to help with the schedule. We're likely going to help you figure out the monies, but eventually when we go from thinking to doing, we are executing. We are doing the work or at least supervising the work in some manner, either directly or indirectly, to move you from where we are and where we are going. It should be controlled chaos, and most of the time it is, but not always. Analysts manage requirements and stakeholder understanding. The requirements can change. One of the requirements may have been red as a ridiculous example up front, but three iterations later, through the feedback loop from the end users, they prefer blue. And now we have

5:45to figure out what kind of blue. Maybe we need a hex code blue, whatever that is. And if you've ever gone to Lowe's or Home Depot in the U.S. and looked at paint chips, every one of those colors, and there might be five different shades of white, they all have a different hex code. Well, the business analysts can help us figure out exactly what hex code we need and why. And the product owners manage product priorities and backlog decisions. And if you aren't familiar with product owners, the backlog is all about the product. What are the requirements, the needs, the ideas, technical debt, and so many of those backlog items make it into the next iteration, the sprint backlog, if you will, that the developers work on. The product owner works with developers to figure out what is the greatest priority and value to the stakeholders, and he or she helps move it into the sprint backlog. They work very closely together. But in many organizations, the product owner makes the final decision on that because the last thing you need is a committee making decisions on what's providing the greatest value specific to the agile space. Now in smaller organizations, you could be an army of one.

7:04You're wearing many hats, but it's just you. You are the project manager. You are the analyst. You might be the product owner. Who knows? It really depends on the kind of product and industry and the money involved and the risk involved and the location, the country. It really does depend. There are a hundred variables that can change that. And in more complex organizations, they are very distinct, but they are also very collaborative. They must work together. And I've been on several projects where we had a project manager, a project team, a business analyst, and we would work together very closely to figure out what the requirements were, how to control them, how to change them, how to update them, and how to keep stakeholders happy. It's actually pretty nice to have these as three distinct roles because then you're not trying to wear three different hats because sometimes when you do that, you forget who you are.

0:00Okay, in section four, it's all about predictive versus agile business analysis, because it exists in both spaces. Business analysis activities occur in both traditional predictive projects, like you see at the top, and modern agile environments, as well as what they're calling hybrid, where you have a mix of the two. Now, the core purpose remains the same, but the approach may change, and understanding the differences is important for the exam, because the certification covers multiple delivery approaches, and if you look at just the layout here, call it the life cycle, if you will. In the predictive space, the requirements are typically defined up front, but that usually happens in heavy engineering environments.

0:51Think of a building, or a road, or some complex technical solution, or especially one under some sort of federal or governmental oversight. There will always be heavy regulation in those kinds of projects, in some manner, if the requirements must be defined up front, and they're usually defined well in advance of execution. So, think about Legos. Anytime you've picked up a box of Legos for a kid, or perhaps even yourself, you see the final product on the box. In fact, that's probably why you picked it up, because they have fantastic marketing, and if they're upset that I mentioned them, let's just call it buildy blocks, so I don't have to worry about copyright infringement, but you get the point. In the predictive space, you would go from one buildy block all the way to the final buildy block, just to see if what you delivered matches what's on the box. The agile space doesn't do that. It starts right here, and the requirements evolve over time. You may only put 10 blocks together for sprint one, and see if you're on the right path. Think incremental delivery, and

2:08then you put 10 or 15 more together, and you're on the right path, and then you put some more together, and eventually you make it to the final sprint, where you put the final blocks on, and then you can very clearly see that for the last five or six sprints, it looked like you were going to deliver what was on the box. So, you have one big delivery in the predictive space, and incremental delivery in the agile space. Both of them work. It just depends on what you're doing as an analyst, based on the product you're trying to deliver, based on the problem you're trying to solve. Is it a problem?

2:48Is it an opportunity? And the project environment will change the way you work very quickly. So, let's dig a little bit further into this concept, and then shut this section down, Jackie Brown. I'm pretty sure I said this. In the predictive space, most of your requirements are defined up front. In fact, in some industries and some projects, unless you have clearly defined requirements, you can't get budgeting to actually begin execution, but that just makes sense. I'd hate to think that they would start building a bridge from two sides of a river without having clearly determined how they were going to meet in the middle, and that sounds a little hyperbolic, but I guarantee you I can find at least a half dozen cases in the past when bridge building was in its infancy and transitioning from wood to metal where they actually had that problem. So, let's just leave that one alone for now and keep going. Now, in the agile space, they typically refine them iteratively over time. You might say as a user story, as a user, I want to be able to change my password for my iPhone and my Android phone. That may be the initial requirement, and it's broad, but then we have to figure out how

4:06to actually do that. What are the technical requirements that support that particular user story, and we may have to figure that out. We may actually say, okay, for the first iteration, we can do it on an iPhone. For the second iteration, we can do it from an iPhone and an Android phone. For the third iteration, if we're still in Canada, maybe we can use a BlackBerry, and I'm not picking on the Canadians or BlackBerry because I had a Pearl for a long time. All I'm saying is, iteratively is the name of the game here. Predictive approaches rely heavily on formal documentation, requirements traceability matrix, a statement of work. Maybe there's a federal contract with 570 pages related to the federal acquisition regulations. I don't know, but on every predictive project I've worked on, there's been a stack of paperwork. On the agile projects, not so much.

5:05Very lean, very clean, and the risk level is different on them as well. The feedback loop is different on them as well. Again, I cannot stress how your business analysis techniques are going to change based on the project environment you are in because both of those environments, or well at least three, predictive agile hybrid, they're trying to deliver normally very different products and solutions, so you have to adapt to that. Agile also promotes continuous collaboration and refinement. It must be so for iterative, continuous delivery. Predictive, one big delivery, usually at the end, no matter how long it takes, but agile, the goal is to deliver something of value in every single sprint, and most of the time, if done properly, they nail it.

6:03So let's keep going. I previously mentioned this as well. The product owner may know the user story they are trying to achieve, but may not understand the technology, and I would say most often does not understand all of the technology enough to actually figure out which solution is best, and that's where the business analyst is going to come in. The product owner is going to tell them what direction they are going in. The business analyst is going to help them figure out the best way to get there by plane, by train, by car, by bicycle, and I'm just using a transportation metaphor to help you understand that. There are a lot of ways to go from point A to point B. The business analyst can help you figure out how to do that, and I said they may be user stories. Happens all the time, and Epic is usually a collection of features, and features are usually a collection of user stories, and I have no idea why I'm using my magic hands, but I am. It makes me feel special as we go through this, and moving on, regardless of approach, the goal is to deliver business value, and not what you think it is, what it actually is to your

7:18clients, your end users, your customers, your stakeholders, and preferably for the 15th time already, something that's actually measurable, and the best business analysts adapt their approach to the project type, which is why it's also very important to determine right up front what kind of project environment are we actually in.

0:00All right, now that I've laid the foundation of what business analysis is and what it is not, let's talk for a minute about the actual certification itself. Now, the PMI professional with business analysis recognizes professionals who demonstrate experience and knowledge in business analysis practices. It's all about the activities required to identify business needs, define solutions, and evaluate the outcomes. Now, the exam is structured around five domains representing the lifecycle of business analysis work. They are needs assessment or assessing the need as I like to say it. Let me switch the color. I think that one's a little better. Well, then you have planning because you can't do anything without a plan and the plan may include your particular approach. Then you have analysis followed by traceability and monitoring and then evaluation. Notice these are all interactive and interchanging continuously through what I previously said was the Deming cycle. Now, each domain represents a critical stage in understanding and delivering solutions and the CERT test emphasizes both technical knowledge and real

1:21world experience. The goal is to ensure that analysts help organizations deliver business value so be very careful about how you view this. It's not how you do work wherever you work. It's how PMI says you could be and should be doing work for purposes of the exam. Sometimes there's a gap between what you're doing and what they think you should be doing so let's dig into this a little bit more and not too far from now we're going to talk about the resources we're going to use for this course. The CERT validates your experience like my risk CERT validates my risk experience like my PMP validates my project experience like my PBA validates my analysis experience.

2:12I've lived for a very long time which is probably why I'm holding multiple credentials from multiple disciplines. I think I'm on my fifth or sixth life and if I were a cat I'd have a few more. I already said there's five domains so definitely grab the ECO below and the reason that's important is let me just go ahead and click up to it and the reason I jumped ahead is because there are 28 tasks across five domains. For example, if you go to domain one needs assessment there are five tasks and then there are five distinct descriptions for each one of those tasks. This thing is important.

2:52If you don't have the exam content outlined you're going to have a more difficult time filling out your application and you're going to have a more difficult time truly understanding if you can do these tasks because if you can't it's going to be problematic on the exam and I know that sounds like a thank you Captain Obvious moment but if I'm telling you to grab the ECO definitely grab it, save it, print it, have it handy. So back to the show. I already said the five domains represent the life cycle and once again they are needs assessment, planning, analysis, traceability, and monitoring as well as evaluation. Your real issue is right here. 28 total tasks. That's a lot. There weren't that many for the risk exam and I don't believe there were for the PMP. It's different for every cert but this is very specific to business analysis. We already know that each of the five domains represents a critical stage in understanding and delivering solutions so I'm just going to leave that one alone for now. Now you need technical knowledge based on how PMI says you should be doing it to pass the exam and you need real world experience anchored in something real,

4:11not academic, not theoretical to actually fill out the application. I've got a great resource coming up to help you build your application and we're going to talk about that shortly and finally nothing has changed and I'm going to say it over and over and over until you're sick of it. The goal is delivering meaningful and measurable business value and of course I have my big fat head over it so let me just go ahead and remove it.

0:00So before we get to PulsePoint Medical and introduce the case study, I want to be very clear about the resources I believe you need to be successful throughout this course and successful on the actual exam. The first one is the exam content outline. I've mentioned it several times. I've dropped it in the course here, rather the skill. Make sure you grab it. Now, other books. PMI has published the PMI Guide to Business Analysis. And yes, you can buy this from Amazon. It's pretty cheap. And also, yes, I covered up their logo because PMI has a rule.

0:38You can't reproduce anything and claim it as your own. And there's some logo and copyright infringement. So I just covered it up. But this is PMI's book. And this thing is money. This is the global standard. Well, as a companion document, you have a practice guide. This is the good practices stuff. But this one, this is the exactly how to do it stuff. The tools, the techniques, the artifacts, the documents. These two together, along with the ECO, are fantastic. And if you shortchange yourself throughout this course and you don't track them down, it's going to be problematic for you to keep all of this stuff straight. In fact, if you're linear minded, I would recommend that after every one of the skills in this course, you go to one of these and maybe read five to ten pages. You can hear me say it in one way. You can read it another way. And you'll find that sometimes there's a gap between the two. But when you hear the same concept two different ways, you can lock it down harder. So do yourself a favor, find the resources, and get ready for what's arguably a marathon course. This isn't a sprint. Slow and steady is going to win this race.

1:56I think that'll do that for now. Let's take a look and see who PulsePoint Medical is, and then we're going to shut this skill down.

0:00Let's talk about PulsePoint Medical, and before you start freaking out, no, you do not need to memorize this graphic. You do not need to understand their operating model right now, but they do have one within the five domains. So let's just look. Over here for needs assessment, you have the business problems and stakeholders and the business case and BA planning, and then you simply follow the process into planning. There's analysis, which goes back and forth. That would be the plan to check ACIT cycle, the Deming cycle, along with traceability and monitoring over to evaluation, and you can see it again right here. They are a mature organization, but that doesn't mean that they don't have problems or problems develop or they see opportunities, and they have key stakeholder groups over here on the bottom right, patients and clinicians and nurses and the IT team, maybe the business analysts, maybe end users, maybe investors, and they also need to integrate their solutions together. They have wearable devices and a monitoring platform and an EH&R system. There is a lot of stuff going on. There's a requirements

1:21hierarchy for what's more important than something else, business requirements and stakeholders, solution transition, and how do you measure success. So the whole point of this slide is not to confuse you. It's to make you understand that there is a systematic way to actually do this using a structured approach, and that's what this course is largely being built around and anchored in. PulsePoint Medical, excuse me, a bug just hit me in the face. So they operate multiple health care clinics. That's piece number one, and they rely heavily on a digital scheduling system. When you have multiple locations, having some sort of digital or cloud-based system is probably just going to make the most sense, but here's where we start to get into the problem.

2:14For now, patients are experiencing long wait times for appointments. I guess we have to define what long is. Is it a day? Is it a week? Is it a month? I don't know. For example, I took my doggy, my Yorkie Poo, to my vet for a checkup and said, hey, when is your groomer available? Oh, they have a slot in three weeks. That, in my opinion, is a long wait time, but it could be months in the context of this particular example, and we will learn more throughout this course. Along with patient issues, the clinical staff reports ineffective scheduling workflows, which means they suffer from the waste of waiting, the waste of someone needing to make a decision, the waste of rework, the waste of transportation, the waste of movement, and that list simply goes on and on as well, and now you have two distinct issues here, problems with long wait times and workflow issues that need to be worked out as well. Maybe they're tied together. Maybe they aren't. We'll find out, and so leadership looks at this. They look at the complaints. They look at the feedback. They look at any number of sources, and they determine they need a new technology to solve this problem. Maybe it's to solve one of the

3:34problems. Maybe it's to solve all the problems. Best case is it solves all of them, but they don't really understand the real problem. Not yet. They have a surface-level understanding of what's going on here, so you, the business analyst, must investigate the situation, and throughout this course, you're going to help analyze whatever's going on with PulsePoint Medical. You're going to help with documentation. You're going to help build artifacts. You're going to help pilot this ship in the right direction. Together, we are going to design a solution throughout this entire course, so get ready. I'm looking forward to it, and I hope you are too.