The PMI-PBA Certification

0:00All right, welcome to skill number one of the PMI PBA Professional Business Analyst course.

0:08I'm Bob Mailer. I don't know if you've trained with me before, but if you have,

0:12I appreciate you coming back. If you haven't, well, you're gonna find out I'm a little quirky.

0:18I like to have fun, but I'm not just gonna sit here and regurgitate information to you. That's

0:24not how I train. I've sat in plenty of bad training classes before, and I vowed I would

0:29never do that to you. So remember when I said I was quirky, because you will see some of them come

0:35out. I'm a project nerd. I love this stuff. I am a multi-credential holder from PMI. I have one or

0:44two from the Scaled Agile folks and the Scrum.org folks. I'm not a big fan of getting certifications

0:51just for the sake of getting them. I do pursue the ones that make sense, that can actually

0:57emphasize something else I've learned or perhaps plug in a gap, but I love project management

1:03in all of its various forms. It brings order to the chaos, and sometimes it takes a while,

1:09but 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.

1:24I'm not one of those fixed people that says, all right, this is starting point A, and this is Z,

1:29and we will not deviate from that no matter what. I will deviate. I will go left. I will go right a

1:36couple of degrees just to make sure that you're having a fun course. It is informative. It is

1:41hitting all the marks you need so you have a clear understanding of what it takes to pass this

1:46cert, and so you aren't bored. I'm just not going to do that to you. So once again, welcome to the

1:53course, and before we start modeling workflows or eliciting requirements or building traceability

2:00matrices, we need to answer one simple question. What exactly is business analysis? Well, it's a

2:08discipline of understanding problems before organizations invest time and money building

2:14solutions. It's basically ensuring we don't put the cart before the horse. Done well, it prevents

2:21organizations from solving the wrong problem, but done poorly, projects deliver solutions that

2:28technically 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,

2:43and eventually, and usually not very long, you realize you didn't solve all of the problem or

2:50maybe not even the root of the problem. So in this course, we're going to explore business analysis

2:57using a continuous case study called PulsePoint Medical. They are a healthcare technology provider

3:03facing operational and scheduling challenges across their network of clinics, and throughout

3:09this course, you are going to be the business analyst. You will be responsible for helping

3:15PulsePoint identify problems, define solutions, and measure business value. You're going to get

3:22case studies you need to read. You're going to get artifacts you need to digest and understand,

3:28and then you will be asked review questions based on that material. I was never going to

3:34just show up and give you the concepts, inputs, tools, outputs, and ideas of PMIs, PBA stuff

3:42without 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.

3:56You're gonna love it.

0:00All right, let's jump into section one, what business analysis actually is. Now many people

0:07think business analysis is about writing requirements documentation, but that's only a

0:12small part of the job. It's really about understanding problems, identifying opportunities,

0:17and helping organizations make better decisions about solutions. And let's face it, there are

0:24usually 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.

0:38So let's check out the graphic for just a moment. I told you we would talk about PulsePoint Medical.

0:45Here we are right here, and here we may see the hospital CEO who has mentioned to some sales

0:51people at some point that they're having a problem. And of course, they show up and they have a widget,

0:57and the widget does A, B, C, and through Z, and it sounds really good, but does it address the underlying

1:05root 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

1:20actually looking at the problems they are trying to solve before they ever look at solutions,

1:27because you can run into something called solution bias. It looks great. It looks shiny. It looks

1:33cheap. You can have it right now, and you can justify it on a motion and then try and validate

1:39it later on on data, but that doesn't mean it's going to do the trick. Business analysis starts

1:45with understanding the problem long before you get to the solution. So let's clear the board and

1:51hop into this. Now right out of the gate, I need you to track down the exam content outline so you can

1:58see 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

2:12solutions, the problem itself, and then you have planning. It's pretty easy. How can you do anything

2:19without a plan? And the answer is, you shouldn't, but you can, but then you can't measure your progress.

2:27So the plan is all about differentiating problems, symptoms, solutions, and trying to figure out how

2:34to get to it. Well, then you have analysis, understanding what's what. What are the needs? What

2:41are the opportunities? What are the threats? What are the potential solutions? And then how are we

2:47going to measure it? We can't measure it if we don't have a clear problem statement, and yes, I'm

2:53writing 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.

3:05It's not me. And finally, we have evaluation. How do we know we've actually solved the problem?

3:14How do we know we've actually delivered value? I'm fond of saying if you can't measure it, you can't

3:21manage it. I'm also fond of saying that if you can't measure it, you can't determine the variance,

3:27and the variance is the difference between what you said you were going to do and what you actually

3:32did. Well, the variance in this case is identifying the problem, identifying the solution, and then

3:39actually determining if your solution took care of the problem or if it just created others or if it

3:45left residual nonsense somewhere in the background that you now have to deal with. So let's unpack

3:52this a little bit more and talk some more about business analysts. Let's go over here to the white

3:56board because I actually have one. Oh look, there it is. So business analysis focuses on understanding

4:05problems 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

4:17at the root cause of a problem and someone pops up and says, oh my gosh, I know exactly what we

4:23should do to solve this, and we haven't fully unpacked it yet. We aren't even sure we are at

4:28the real root cause. There's something called Pareto's law, and 20% of your root causes result

4:35in 80% of your problems, but you can have multiple root causes resulting in a single effect. It goes

4:43both ways, and so jumping to the solution before you get to the real problem happens all the time,

4:49and it's very dangerous, and business analysis is trying to avoid building systems that don't

4:55solve 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

5:10right now, and two of them crashed, and upwards of three or four hundred people died. Well, they knew

5:16early on there was a design flaw. They didn't fix the design flaw. They came up with a solution that

5:22was supposed to counteract it, and it didn't. It made it worse, and for a couple of months, those jets

5:29were grounded. They couldn't sell any of them, and they're under investigation by the Department of

5:34Justice in the United States, and I may have gotten some of the small details wrong here,

5:40but I'm not wrong about what happened. They knew there was a problem. They clearly understood it,

5:46and instead of solving the problem, which would have taken longer and cost more,

5:51they 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.

6:06They help them define it, analyze it, and communicate it, because sometimes stakeholders

6:12don't know. They just have an idea, but when we help them, when we elicit information from them,

6:18we can help them figure it out, and the discipline exists across all kinds of projects, whether they

6:24are agile, hybrid, or predictive, as well as operational environments. Process flows. Doesn't

6:31matter. Business analysis is always going to be seeking the root cause of the problem

6:37before you start aiming towards a solution, and it happens all the time. Before, during,

6:43and after. It is continuous. Look at the life cycle of any given product these days. Do you

6:49really 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

7:01improve on, what customers want, the size, the weight, the battery capacity, the range,

7:07and the list simply goes on and on, and the goal is always the same. Delivering measurable value.

7:15If you can't measure it, you can't manage it. You can't determine if you've actually achieved

7:21value, and value may not just be return on investment. It could be an increase in your

7:27public awareness for your particular brand. It really does depend on what game you're trying

7:33to play here, but let's keep going. I think I've got two more. There we go. Business analysts also

7:38make sure that technology and strategy stay aligned. It's really easy to go from here to here

7:46if you're paying attention, but if you don't keep your eye on the prize, it's really easy

7:51to drift off a couple of degrees, and again, you'll deliver something, but it may not be the

7:57something you need to actually solve the problem, and finally, good analysis reduces risk. The risk

8:05of 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

8:17right 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.

0:04Now it's a unique role. They're not typically responsible for

0:08building the solution or even managing the project.

0:11We've got other people for that. Instead, they help organizations understand what

0:16problem they are actually trying to solve and not just

0:19what they think it is and what the solution should actually

0:23accomplish. So let's take a quick look at the pulse

0:27point business analyst here and look at the interaction.

0:30And I previously told you that PulsePoint Medical is going to be our

0:34case study throughout this course. I've used them

0:37several times. They are fantastic. They are fictitious.

0:40They are made up. They are a great example for this.

0:44So you have the regional hospitals. They have three of them.

0:49Well, they're into remote patient monitoring,

0:52various devices for cardiac anomalies, alerts, stuff like that,

0:56interactive, in the clinic, at home. There are several touch points, really

1:01interesting tech and it actually does exist. If you don't

1:04believe me, I'm wearing some tech right here.

1:07You're Fitbit. If I can monitor my heart rate here,

1:11why can't they monitor someone with a heart condition? And the answer is

1:14they can and they actually do. And they've got plenty of data and metrics.

1:20Well, they've also got plenty of stakeholders and every stakeholder wants

1:24something different. A stakeholder is anyone who believes

1:28your project or your product might have a positive or negative influence

1:32on them. So you almost always have positive stakeholders,

1:37but you can have negative stakeholders, too. People

1:40actively working against you. People that want to see you

1:43fail because in some way, shape, or form your failure

1:47elevates them. But then we have the end users,

1:51the 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

2:00life. Maybe it's simply cost. Maybe it's just so

2:03their insurance company will pay for it in this specific example. And trying to

2:09balance all of that out is the business analysis team. I may

2:13actually call them the BA team or maybe even the BAT. I don't know,

2:19but almost every organization that produces a product, a service, or a result

2:24has a business analyst somewhere. It really does depend what they're doing

2:28and what they actually call them. So let's go forward and dig into this

2:33role a little bit more. So here we go. They identify problems and

2:38opportunities. Now when I say opportunities, that's

2:41something good. Again, the easiest way is

2:45reactively. There's a problem. There's a business problem.

2:49So they help track down what it actually is.

2:52That one's easy, but the other one is a gap in the market.

2:56They see an opportunity because no one's fulfilling this particular role.

3:01No one is providing this service. So they go, wait a minute, we're already doing

3:0585 percent of this, but if we just add this other

3:0815 percent, I'm making sure I'm actually adding to 100 percent,

3:13we can actually move the market in our direction as the sole provider.

3:17They do that. That's actually really cool stuff and value add

3:22in any organization. So when there's a problem or an opportunity,

3:26they have to work with the stakeholders to understand their needs, their

3:30expectations, their desires, their demands, their wants.

3:34They also have to understand what is spoken

3:38and what is unspoken, sometimes referred to as

3:41supportive. If you tell me I need to have something sent to you by

3:46Thursday of next week, that's your need. Maybe that's your requirement,

3:51but the unspoken requirement is I need to actually mail it some way.

3:56Am I sending it through snail mail or UPS or FedEx or if it's really high-end,

4:01is 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

4:09requirements straight, there's no way the spoken requirements

4:13are going to be met. I know you understand that, but I like to

4:16say it anyway because I like to be very clear about the direction my mind is

4:20moving in. They define requirements for solutions.

4:24Requirements, things that are required. It must be

4:29less than this weight. It must be this wide. It must be

4:32this tall, this thick. It must have an input power of this.

4:36It must have a throughput speed of that, whatever it is.

4:40It really does depend, and there is no set rule for

4:44one set of requirements working for this device

4:48and the same set working for the one over here.

4:51It's different almost every single time, and in fact,

4:54I would say that in every case, it's different in some small way.

4:59So they translate the business needs into

5:03structured solution requirements. Notice it says structured. This is not

5:09haphazard. It is not made up. There is a very clear way to go from

5:14problem to solution to measuring to adjusting. In fact,

5:20you 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

5:29iterative feedback loop fashion, and there's nothing wrong with that. I'm

5:35fully supportive of it. I love it. Now if I can just figure out

5:39where I went. All right. They analyze workflows. What

5:43works well, what's not working well. Systems and processes. Workflows.

5:49You might be wondering why. Well, think of the kinds of waste.

5:53The waste of waiting. The waste of overproduction. The waste of

5:57transportation. The waste of defects.

6:02The waste of skills, and I believe there are eight of them, and a couple of them

6:06are escaping me, but think of it this way. If you want

6:09your process to be lean and mean and taking the most efficient time to

6:13get anything done, that's where workflow analysis comes in,

6:18and they can also help you figure out if solutions really deliver business value.

6:22Easy example. Let's say you commute to work and you want to get a smaller car

6:27with a better mileage per gallon rating. You go to the dealership. You find one.

6:32Maybe it's new. Maybe it's used. Whatever it is, and it says

6:3535 miles to the gallon on the highway, and so you buy it because you calculate

6:41that this is where you need to be for the best return on your money. You

6:45bought the car. It needs to actually achieve 35 miles to

6:49the gallon, but how do you know? Do you calculate how

6:53many gallons you put in? How many miles you've actually driven? Divide

6:57one by the other and see it, or can you actually measure it with some sort of

7:02device in your vehicle? Because in both cases, the answer is yes,

7:06and a business analyst can help you figure out

7:09what might seem like a good way to measure success

7:13and what might be a much better way, even scientifically, if you will,

7:18to measure it. They're almost always very different.

7:21They're also facilitators between business and technical teams.

7:26The business people are talking macro level. The technical teams are talking

7:30micro level. Good business analysts can bridge that

7:34gap because they can speak both languages,

7:36and trust me, if you've ever worked with diehard engineers,

7:40you know they're not good with macro language. They need it to be as clearly

7:44defined as possible, or they're just not going to have that

7:47conversation. And finally, they help you make better

7:50decisions. There are almost always multiple

7:55potential solutions for any particular problem, but which one is

7:59best? The answer is you probably need a

8:02business analyst to help you figure it out in some kind of

8:05measurable way.

0:00Okay, let's talk about the BA, the project manager, and the product owner. Because one of the most

0:06common sources of confusion is the relationship between the three. And I'm talking about the

0:14business analyst who determines the actual problem. And I'm also talking about the product

0:20owner who's going to determine which element of the solution delivers the greatest value. Maybe

0:28it is an iterative delivery. We have to figure out which is best to go out first, second, third,

0:34last, 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

0:48distinction helps clarify where business analysis fits within projects and product development.

0:57So there's a lot to unpack there. Let's keep going. Let's actually do that. So let's talk

1:03about the project manager. I am a project manager. In fact, I'm proud to say I am consistently an

1:10above average project manager. Being an excellent project manager is hard, but I can maintain above

1:18average almost indefinitely. So that's what I strive for. My job is delivering products within

1:24the triple constraints. And if you aren't familiar with the triple constraints, it's scope, schedule,

1:29and cost. And the triple constraints really means you can't adjust one without impacting the other

1:36two. 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

1:51equal. You have cost. That's the money. You have schedule, which is time. And time is money. And then you

1:59have the scope, what they actually want. And the difference between what they want and what they

2:05actually need is money and time to deliver. So in my humble opinion, in my learned opinion, it is

2:14almost always the cost or the scope. The schedule is simply the gap between this is what I want

2:23and 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.

2:38And I said it a moment ago, there's what I think it is and what I want and there's what it

2:45actually is and what I need. There's a huge difference in cost between what I think it is

2:52and what it actually is. And sometimes I'm so focused on an individual solution that I become

3:01blind to everything else. I get so far into my own feelings and what I believe the impact is to my

3:07client, my business, my customers, my end users, that I can't think clearly. A business analyst

3:14normally keeps a very neutral space on the things they see and the things they recommend. And there's

3:21nothing wrong with that. You need people like that as a sanity check. Well, then you have the product

3:27owner. In an agile space, they're responsible for the product backlog. They decide what delivers

3:33the greatest value in the next iteration. And they can constantly change that backlog based on

3:40the 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,

3:53just think about Windows. I remember Windows 3.11 as an operating system and then 95 and then 98 and

4:02then 2000 and then NT and then XP and then 7, 8, 9, 10. I think we're on 11 right now. That product

4:11lifecycle has extended for decades and they keep actually trying to deliver value. And one of the

4:19greatest 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

4:32evolving. Who has any idea what it will be in the next 20 years? And if the Windows operating

4:39system isn't working for you, just go back and think about the iPhone. Think about the iPad.

4:44Think about the iCloud. Think about the iWatch, the iEverything. Constantly evolving and constantly

4:52trying to deliver greater value in that particular environment. So PMs execute. We may help you with

4:59the requirements. We're likely going to help with the schedule. We're likely going to help you figure

5:04out the monies, but eventually when we go from thinking to doing, we are executing. We are doing

5:12the work or at least supervising the work in some manner, either directly or indirectly, to move you

5:18from where we are and where we are going. It should be controlled chaos, and most of the time it is,

5:26but not always. Analysts manage requirements and stakeholder understanding. The requirements can

5:32change. One of the requirements may have been red as a ridiculous example up front, but three

5:39iterations 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

5:50gone to Lowe's or Home Depot in the U.S. and looked at paint chips, every one of those colors, and there

5:56might be five different shades of white, they all have a different hex code. Well, the business

6:02analysts can help us figure out exactly what hex code we need and why. And the product owners manage

6:08product priorities and backlog decisions. And if you aren't familiar with product owners, the backlog

6:15is all about the product. What are the requirements, the needs, the ideas, technical debt, and so many

6:24of those backlog items make it into the next iteration, the sprint backlog, if you will, that

6:31the developers work on. The product owner works with developers to figure out what is the greatest

6:37priority and value to the stakeholders, and he or she helps move it into the sprint backlog. They

6:44work very closely together. But in many organizations, the product owner makes the final decision on that

6:51because the last thing you need is a committee making decisions on what's providing the greatest

6:56value 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

7:10might be the product owner. Who knows? It really depends on the kind of product and industry and

7:16the money involved and the risk involved and the location, the country. It really does depend. There

7:22are a hundred variables that can change that. And in more complex organizations, they are very

7:28distinct, but they are also very collaborative. They must work together. And I've been on several

7:35projects where we had a project manager, a project team, a business analyst, and we would work

7:43together very closely to figure out what the requirements were, how to control them, how to

7:48change them, how to update them, and how to keep stakeholders happy. It's actually pretty nice to

7:53have these as three distinct roles because then you're not trying to wear three different hats

7:58because 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

0:07in both spaces. Business analysis activities occur in both traditional predictive projects,

0:14like you see at the top, and modern agile environments, as well as what they're calling

0:20hybrid, where you have a mix of the two. Now, the core purpose remains the same,

0:26but the approach may change, and understanding the differences is important for the exam,

0:32because the certification covers multiple delivery approaches, and if you look at just

0:38the layout here, call it the life cycle, if you will. In the predictive space, the requirements

0:45are 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

0:58sort of federal or governmental oversight. There will always be heavy regulation in those kinds

1:05of projects, in some manner, if the requirements must be defined up front, and they're usually

1:12defined well in advance of execution. So, think about Legos. Anytime you've picked up a box of

1:19Legos for a kid, or perhaps even yourself, you see the final product on the box. In fact, that's

1:27probably why you picked it up, because they have fantastic marketing, and if they're upset that I

1:32mentioned them, let's just call it buildy blocks, so I don't have to worry about copyright infringement,

1:39but you get the point. In the predictive space, you would go from one buildy block all the way to

1:45the final buildy block, just to see if what you delivered matches what's on the box. The agile

1:53space doesn't do that. It starts right here, and the requirements evolve over time. You may only put

2:0110 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,

2:14and eventually you make it to the final sprint, where you put the final blocks on, and then you

2:19can very clearly see that for the last five or six sprints, it looked like you were going to deliver

2:26what was on the box. So, you have one big delivery in the predictive space, and incremental delivery

2:34in the agile space. Both of them work. It just depends on what you're doing as an analyst, based

2:41on 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

2:54dig a little bit further into this concept, and then shut this section down, Jackie Brown. I'm pretty

3:01sure I said this. In the predictive space, most of your requirements are defined up front. In fact, in

3:08some industries and some projects, unless you have clearly defined requirements, you can't get

3:14budgeting to actually begin execution, but that just makes sense. I'd hate to think that they would start

3:20building a bridge from two sides of a river without having clearly determined how they were going to

3:26meet in the middle, and that sounds a little hyperbolic, but I guarantee you I can find at least

3:33a half dozen cases in the past when bridge building was in its infancy and transitioning

3:38from wood to metal where they actually had that problem. So, let's just leave that one alone for

3:44now and keep going. Now, in the agile space, they typically refine them iteratively over time. You

3:53might say as a user story, as a user, I want to be able to change my password for my iPhone and my

4:00Android 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

4:13story, and we may have to figure that out. We may actually say, okay, for the first iteration, we can

4:20do it on an iPhone. For the second iteration, we can do it from an iPhone and an Android phone.

4:25For the third iteration, if we're still in Canada, maybe we can use a BlackBerry, and I'm not picking

4:31on the Canadians or BlackBerry because I had a Pearl for a long time. All I'm saying is, iteratively

4:38is the name of the game here. Predictive approaches rely heavily on formal documentation,

4:45requirements traceability matrix, a statement of work. Maybe there's a federal contract with 570

4:52pages related to the federal acquisition regulations. I don't know, but on every predictive

4:58project 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

5:12is different on them as well. Again, I cannot stress how your business analysis techniques

5:19are going to change based on the project environment you are in because both of those

5:24environments, or well at least three, predictive agile hybrid, they're trying to deliver normally

5:31very different products and solutions, so you have to adapt to that. Agile also promotes continuous

5:38collaboration and refinement. It must be so for iterative, continuous delivery. Predictive,

5:49one big delivery, usually at the end, no matter how long it takes, but agile, the goal is to deliver

5:56something 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

6:09user story they are trying to achieve, but may not understand the technology, and I would say

6:15most often does not understand all of the technology enough to actually figure out which

6:21solution is best, and that's where the business analyst is going to come in. The product owner

6:27is going to tell them what direction they are going in. The business analyst is going to help

6:31them figure out the best way to get there by plane, by train, by car, by bicycle, and I'm just

6:37using a transportation metaphor to help you understand that. There are a lot of ways to go

6:42from point A to point B. The business analyst can help you figure out how to do that, and I said they

6:48may be user stories. Happens all the time, and Epic is usually a collection of features, and features

6:57are usually a collection of user stories, and I have no idea why I'm using my magic hands, but I

7:03am. It makes me feel special as we go through this, and moving on, regardless of approach,

7:11the 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

7:25already, something that's actually measurable, and the best business analysts adapt their approach

7:32to the project type, which is why it's also very important to determine right up front

7:38what 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,

0:07let's talk for a minute about the actual certification itself. Now, the PMI professional

0:12with business analysis recognizes professionals who demonstrate experience and knowledge

0:19in business analysis practices. It's all about the activities required to identify business needs,

0:25define solutions, and evaluate the outcomes. Now, the exam is structured around five domains

0:32representing the lifecycle of business analysis work. They are needs assessment or assessing

0:40the need as I like to say it. Let me switch the color. I think that one's a little better. Well,

0:46then you have planning because you can't do anything without a plan and the plan may include

0:52your particular approach. Then you have analysis followed by traceability and monitoring and then

1:00evaluation. Notice these are all interactive and interchanging continuously through what I

1:08previously said was the Deming cycle. Now, each domain represents a critical stage in understanding

1:14and 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

1:30so be very careful about how you view this. It's not how you do work wherever you work. It's how

1:38PMI says you could be and should be doing work for purposes of the exam. Sometimes there's a gap

1:45between what you're doing and what they think you should be doing so let's dig into this a little

1:50bit more and not too far from now we're going to talk about the resources we're going to use for

1:55this course. The CERT validates your experience like my risk CERT validates my risk experience

2:03like 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

2:18disciplines. I think I'm on my fifth or sixth life and if I were a cat I'd have a few more.

2:25I already said there's five domains so definitely grab the ECO below and the reason that's important

2:32is let me just go ahead and click up to it and the reason I jumped ahead is because there are 28 tasks

2:38across five domains. For example, if you go to domain one needs assessment there are five tasks

2:45and 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

2:57your application and you're going to have a more difficult time truly understanding if you can do

3:02these tasks because if you can't it's going to be problematic on the exam and I know that sounds like

3:09a thank you Captain Obvious moment but if I'm telling you to grab the ECO definitely grab it,

3:16save it, print it, have it handy. So back to the show. I already said the five domains represent the

3:23life cycle and once again they are needs assessment, planning, analysis, traceability, and monitoring

3:30as well as evaluation. Your real issue is right here. 28 total tasks. That's a lot. There weren't

3:39that many for the risk exam and I don't believe there were for the PMP. It's different for every

3:44cert but this is very specific to business analysis. We already know that each of the five domains

3:52represents a critical stage in understanding and delivering solutions so I'm just going to leave

3:57that one alone for now. Now you need technical knowledge based on how PMI says you should be

4:03doing 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

4:18up to help you build your application and we're going to talk about that shortly and finally

4:24nothing has changed and I'm going to say it over and over and over until you're sick of it.

4:30The goal is delivering meaningful and measurable business value

4:38and 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

0:05clear about the resources I believe you need to be successful throughout this course and

0:11successful on the actual exam. The first one is the exam content outline. I've mentioned it

0:18several times. I've dropped it in the course here, rather the skill. Make sure you grab it.

0:24Now, other books. PMI has published the PMI Guide to Business Analysis. And yes, you can buy this

0:31from 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

0:43infringement. So I just covered it up. But this is PMI's book. And this thing is money. This is

0:51the global standard. Well, as a companion document, you have a practice guide. This is the good

0:58practices stuff. But this one, this is the exactly how to do it stuff. The tools, the techniques,

1:06the artifacts, the documents. These two together, along with the ECO, are fantastic. And if you

1:13shortchange yourself throughout this course and you don't track them down, it's going to be

1:18problematic for you to keep all of this stuff straight. In fact, if you're linear minded, I

1:24would recommend that after every one of the skills in this course, you go to one of these and maybe

1:29read five to ten pages. You can hear me say it in one way. You can read it another way. And you'll

1:36find that sometimes there's a gap between the two. But when you hear the same concept two different

1:41ways, you can lock it down harder. So do yourself a favor, find the resources, and get ready for

1:48what'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

2:01we'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

0:05memorize this graphic. You do not need to understand their operating model right now,

0:12but they do have one within the five domains. So let's just look. Over here for needs assessment,

0:20you have the business problems and stakeholders and the business case and BA planning,

0:25and then you simply follow the process into planning. There's analysis, which goes back

0:32and forth. That would be the plan to check ACIT cycle, the Deming cycle, along with traceability

0:39and monitoring over to evaluation, and you can see it again right here. They are a mature

0:46organization, but that doesn't mean that they don't have problems or problems develop or they

0:52see opportunities, and they have key stakeholder groups over here on the bottom right, patients

0:59and clinicians and nurses and the IT team, maybe the business analysts, maybe end users, maybe

1:06investors, and they also need to integrate their solutions together. They have wearable devices and

1:14a 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,

1:27solution transition, and how do you measure success. So the whole point of this slide is

1:34not to confuse you. It's to make you understand that there is a systematic way to actually do this

1:41using a structured approach, and that's what this course is largely being built around

1:48and anchored in. PulsePoint Medical, excuse me, a bug just hit me in the face. So they operate

1:55multiple health care clinics. That's piece number one, and they rely heavily on a digital scheduling

2:03system. When you have multiple locations, having some sort of digital or cloud-based system is

2:09probably 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

2:20what long is. Is it a day? Is it a week? Is it a month? I don't know. For example, I took my doggy,

2:28my Yorkie Poo, to my vet for a checkup and said, hey, when is your groomer available? Oh, they have a

2:34slot in three weeks. That, in my opinion, is a long wait time, but it could be months in the context of

2:41this particular example, and we will learn more throughout this course. Along with patient issues,

2:48the clinical staff reports ineffective scheduling workflows, which means they suffer from the waste

2:55of waiting, the waste of someone needing to make a decision, the waste of rework, the waste of

3:02transportation, the waste of movement, and that list simply goes on and on as well, and now you have two

3:09distinct issues here, problems with long wait times and workflow issues that need to be worked

3:15out as well. Maybe they're tied together. Maybe they aren't. We'll find out, and so leadership looks at

3:22this. They look at the complaints. They look at the feedback. They look at any number of sources,

3:28and 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

3:40really understand the real problem. Not yet. They have a surface-level understanding of what's going

3:47on here, so you, the business analyst, must investigate the situation, and throughout this

3:54course, you're going to help analyze whatever's going on with PulsePoint Medical. You're going to

4:00help with documentation. You're going to help build artifacts. You're going to help pilot this ship

4:06in the right direction. Together, we are going to design a solution throughout this entire course,

4:13so get ready. I'm looking forward to it, and I hope you are too.