Pass PMI PMI-ACP Exam in First Attempt Easily

PMI-ACP: Preparing to Pass the Exam

1. Course Overview

Welcome to Section One. In this course, we're going to talk all about the PMI-ACP exam. I'm going to look at the details of the course, and we'll have an introduction to a simple quiz. So we're going to begin by talking about the PMI-ACP exam. What are the agile approaches you'll need to know for the exam, what are the qualifications and your work prerequisites, what's the cost of the exam, how to complete the PMI-ACP exam application, and then what to do if you are randomly selected for an audit? We're going to talk all about the test experience, what you can expect at the testing center, how the test is scored, the timing of the exam, and what's going to happen when you go in to pass the exam. At the actual Pro Metric Testing Center, should you have to schedule, reschedule, or cancel an exam? There's a process there that we'll discuss and that you'll have to go through. So primarily, these are for emergencies. So who are the people that you'll call ProMetric and PMI, and what's that process like? the test results. At the end of the exam, you're going to get your test results. We'll talk about that, and we'll talk about your past-fail score and then how this course is structured. So the goals of this course, how you should use this course to help you pass the exam, resources in this course, and how to claim your official PMI-ACP Certificate of Completion, which you will only know you will need if you are selected for an audit, So, the exam details: we're going to look at the exam domains, the individual tasks, having an agile mindset for the exam, and then some agile principles that you should master. Also in this course, we're going to look at the official PMI documents and the exam objectives. I'm going to show you the ACP handbook, some PMI exam guidance, and then a list of resources should you want some other material outside of this course. These are some resources that the ACP exam is based on. It's a whole bunch. All right, let's go. Let's get started in this section. There's a lot to knock out. So have a positive attitude and a positive mindset—an agile mindset. You can do this. Don't get discouraged. Let's get moving. There's lots to learn, but I have confidence in you that you can get this done. You.

2. All About the PMI-ACP Exam Contents

Now the PMI-ACP exam, it's 100scored test questions, 20 unscored test questions. So you have 120 total questions. Now, these 20 unscored questions, which are sometimes referred to as "seated test questions," What are those? PMI throws these 20 unscored test questions into every exam. So based on how the population of ACP candidates answers those 20 questions, if everybody gets those 20 questions correct, then that's too easy of a question. If everybody gets them wrong, then that's a really poor question. So it is a determination of whether those 20 questions will become real questions that go into their exam pool. So you don't know if you're answering a live or a seated test question. You have 3 hours to complete the exam, from when you start to when you're done. I really doubt it's going to take you 3 hours. It took me about an hour and ten minutes. Now, other people—maybe you want to labour over every question. I didn't feel like the questions were terribly difficult. So I don't think you're going to be done in 3 hours, but plan accordingly. You have up to 3 hours to answer 120 questions. The pretest tutorial now demonstrates how to use the software, including how to strikethrough answers you don't want to select, highlight keywords, and use the calculator. So it's a nice little tutorial. It takes 15 minutes. Some people use that time to write down their notes in the testing centre as they get ready to start the test. But you don't have to take it if you don't want to. It's very easy to use their software. If you've never taken a PMI exam, you might want to buzz through it. But it's not difficult. Once you complete your exam, then the survey pops up before you see your exam score, and that's always aggravating because you're ready to see how you did. But the survey pops up and you have to answer some questions, and then once you finish the survey, it'll score your exam. So that's a long survey. So, what are you being tested on? We'll be looking at all of these throughout this course. On the exam blueprint, you can see there are seven domains: agile principles and mindset, value-driven delivery, stakeholder engagement, team performance, adaptive planning, problem detection and resolution, and continuous improvement. So as you can see, the first four domains are all pretty close. Obviously, value-driven delivery is the big one there at 20%. But those first four are really the heart of the exam. Now the others—yes, they're important, but they're not worth as much. You're not going to see as many questions on the others. And this blueprint is what we'll be talking about. all of these in detail for the remainder of the course. The testing centre details its all-computer-based exam. Yes, there are paper-based tests that you can take, but you have to live at least 300 miles from a parametric testing center, and you can go on to the Parametric site and see if you qualify for a paper-based exam. If you're taking a paper-based exam, though, there has to be at least ten people taking the paper-based exam. I recommend you schedule your exam as soon as you qualify because it can be difficult to get a seat in your Pro Metric testing center. So pick a date, get on the Pro Metrics website, which we'll look at right now, and then you begin to schedule. You go out to the website, prometric.com. You decide to make an appointment. PMI will give you a code in the email that says you qualify, and then you'll search for testing sites in your area. And then if a day is available, it's going to show up as blue. Of course, days that aren't available are greyed out. You'll confirm your contact information and give me a valid email address. And then you'll also provide your examination confirmation with a 16-digit unique confirmation number, and that's the sync between PMI and Pro Metric. What if you have to cancel your test? Well, if you cancel within 30 days, it's $70; after 30 days, it's $70.If you cancel within two days, you lose all the money. A no-show is a forfeit, so you lose all the money. If there is an emergency and you can't make it, call the Permetric Testing Center and let them know. PMI will also need to be informed that it's an emergency, but they will determine if the emergency qualifies for an opportunity to reschedule. Schedule emergencies do not qualify as an emergency. There has to be a medical emergency or someone in a car wreck or something terrible, but simply saying, "Well, we had someone who had to go to work, and we had an emergency meeting," is insufficient. Doesn't count. It has to be a real emergency. When you get to the testing center, you have to provide a valid government-issued ID. So you need English characters or a translation of what's on that ID. It must include your photograph. If your government-issued ID does not include a photo, you need a secondary ID with your name and a photo. Now, your name must match the name that you used on the PMI application. So if you go by your middle name and you don't like your first name as Herbert, well, you have to use whatever name is on your ID when you register with PMI, so don't make that mistake. Keep your name the same on all of your documents, including your course certificate. You can't use a Social Security card and a library card, or your card from your comic book collection. I mean, it has to be a real ID when you go to register. Now in the testing center, you want to get to Prometric about 30 minutes before your exam start time. And then, when you arrive, they'll give you a locker, a small cube locker. You have to put all your belongings in it. Your phone, your wallet, your keys Everything that is on your person, you have to put in the locker. You cannot take anything into the testing centre with you. You can wear sweaters and coats into the testing center, but you can't take them off once you're go in. So dress comfortably, but it's going to be in an office environment. It's not going to be terribly hot or terribly cold. So just be comfortable because you cannot take off that sweater or coat once you're in the testing center. Before you go into the testing center, there will be an administrator, and the administrator will ask you to turn your pockets of your pants or whatnot inside out to prove there's nothing in your pockets. And then they're going to wave a wand over you to see if you have any metal in your pockets or hidden somewhere on your person. So it's pretty secure. It's like you're boarding a flight or something. When you're clear, when they say, "Okay," you can put your pockets back in your pants, and you can begin to walk into the testing center. What they're going to give you when you go into the actual room to be tested is a little booklet that has about six sheets of scratch paper and two pencils. Or they'll give you a dry erase board, a little eight by eleven dry erase board, a marker, and a little dry erase pin. I don't like that. But they didn't ask me what I liked. I was fortunate enough when I took my exam that I was able to get scratch paper. I didn't have the dry-erase board. You don't get to choose which one you want. It's the testing centre determination you will get to make, though. Do you want a calculator? Now, there's a calculator in the software. I'm a low-tech, high-touch guy, so we'll talk about it later. So I wanted to calculate. I didn't want to use the software. I wanted a calculator, but I really didn't need it in the exam, as it turns out. So you can choose: do you want to use the one in the software, or do you want to use theirs? When you get into your little cubicle to take your exam, it's a little half-cube and a tiny little thing, with just enough room for your monitor, keyboard, and mouse. You'll see that there are some earplugs or headphones that you can put on to block out any noise. Because in this testing center, there will be other people taking tests. And in some of those tests, people have to type in answers. So just be aware that you won't have to type in answers on your test. But people might be taking a real estate exam or a nursing exam, or who knows? But you can put on these headphones if you don't want to hear that noise. And I took advantage of that because people were coming and going, and the door was squeaky and so on. So I didn't want any distractions. You can, if you feel like it. Take a break. You've got 3 hours. I can't sit still for 3 hours. So I finished my test, and then I took a break. I came back in, did a little reviewing, and I decided it was fine. But when you take a break, that timer keeps running. You can't pause it. When you take a break, you cannot open your locker. You're not allowed to open your locker until the test is over. So if you take a bottle of water or a little snack or something else that can't fit in your locker, you have to wait till the test is over. You can get kicked out of the testing centre for any type of disruptions. Obviously, if you're trying to cheat or try to keep that scrap paper, even if you tear off a little piece of it, they can kick you out. You are not allowed to eat or drink in the testing room. If you try to tamper with a computer in any way, or if you're just being an idiot, they're going to kick you out of there. So just be professional. Go in and pass your exam, and get out. You don't want to call any attention to yourself. You don't want to do anything stupid. So use common sense here, or they're going to kick you out. You certainly don't want to be a disruption to anybody else in the room, because those people are trying to pass exams as well. Now, the examination report. As soon as you're done, you will receive a pass. Fail immediately after you complete that survey. Now, this is for our paper-based exam, not our computer-based exam. If you live more than 300, you're doing a paper based exam. It's graded a little differently, but if you're taking the CBT, you know immediately if you passed or failed. So you don't really get a score. So don't ask me what the passing score is. PMI doesn't say what the passing score is. How they determine if you pass is based on these three levels of proficiency. Are you proficient or above average? You're proficient. Are you moderately proficient? So are you average, or are you below proficient? So are you below average? Now, these are ranked for each one of those seven domains we looked at earlier. So at the end, you'll get your score. Report it'll. Say what? Are you proficient, modelling proficient, or below proficient in your score? All right, that's that's the big scoop on the mechanics of how to pass the exam.

3. Agile Mindeset: PMI-ACP Exam Domain Details

Let's talk about what is on the exam. We're going to review the exact exam objectives. These are from the PMI website. You can go up to PMI.org and download these. So you probably should do that as well. Because PMI is its own exam, they have the option to change these objectives whenever they want. Now, if they change the objectives, I'll update this course. But I'm just saying it's always a good idea to go and check the source for what you're going to be tested on. So the PMI exam objectives are current as of today's recording, and if they change, then I will update this lecture. Now, in the exam objectives, there are two things you're going to be tested on. We have domains, and then we have tasks. Now, a domain is just a category of knowledge, like value-driven delivery is a domain or adaptive planning is a domain. Now, within that domain, there are specific activities that you'll lead as a project manager. So in these next several lectures, we're going to look at each domain and then at the tasks within that domain. You'll be seeing this slide a lot over the next few lectures. This is your exam blueprint. This is really a key to your study efforts. So the Agile Principles and Mindset are what we're going to look at first, and you can see that they make up 16% of the exam, followed by value-driven delivery at 20%. So these first four, also including stakeholder engagement and team performance, are the most significant ones that you really need to pay attention to for your exam. Yes, these others are important. There's just not as many test questions on domains five, six and seven as the first four. So we'll jump in here, and you'll see what's in each of these domains, as well as the tasks you'll be tested on. The first is the agile mindset and principles. There are nine tasks with agile principles and mindset, and we're going to look at those. Now you explore, embrace, and apply Agile principles and the Agile mindset within the context of the project, team, and organization. Now, this represents 16% of your exam. So, roughly, 19 ow, this represent If you master this, it will have an impact on all of your other objectives and task domains. So I encourage you to pay special attention to being agile. So that means having the mindset and the approach. So what are the agile principles and mindset? Well, then you're an advocate for agile principles by modelling those principles and discussing agile values in order to develop a shared mindset across the team as well as between the customer and the team. So as an agile project manager with an agile mindset, what you want to do is communicate, discuss, and share how great agile is, why it works, and what the approach is. A lot of this is about communications, so having that mindset is communicating why Agile is so good for your organization. The next point is to help ensure that everyone has a common understanding of the values and principles of agile and common knowledge around the agile practises and terminology being used to work effectively. So again, it's about communication, but you're communicating not just why agile is great, but how agile works, what are the values of agile, and ensuring that people have a common understanding that they have to know what you're talking about. When you talk about a sprint or a scrum or a stand-up or a cycle or leadtime, they have to understand that terminology. So part of the Agile Project Manager's role is to teach and educate your team, but also to support change at the system or organisational level by educating the organisation and influencing processes, behaviors, and people to make the organisation more effective and efficient. So again, communication, working with stakeholders, and educating. So you're teaching why Agile is great and how it works. But notice that it's also influencing. So we have some emotional intelligence that will come into play and that we will discuss later. So influencing processes, behaviors, and people practise visualisation by maintaining highly visible information and showing real progress and real team performance in order to enhance transparency and trust. Well, that's the first time we've seen this term, an information radiator, and we'll see it a couple more times in this course. Basically, an information radiator is Imagine a big whiteboard that has how many activities are happening right now, how many requirements are in queue, what's coming up next, what's been delivered, who's working on what, what's your risk in the project, and how many activities are left until you're done with the current phase or cycle or iteration or sprint, whatever terminology you want to use. So it's about visualizing, though. And I know it rattled off a bunch of different terms there, but I'm trying to keep it just kind of high-level right now. An information radiator communicates what's happening in the project. And so it's not all hidden away in a report or a Microsoft project or Visio; it's out in the open. And notice I said it's a big whiteboard. It could be a big computer screen. But typically we want what's called, as I mentioned earlier, "low tech, high touch." So it's really easy, anybody can access it, and I don't have to know Microsoft Project to look at your project files. But the point here is that you're visualizing and communicating what's happening in the project out in the open, good and bad, because that builds trust and is transparent. And those are two principles of agility. And having this agile mindset, you want to contribute to a safe and trustful team environment by allowing everyone to experiment and make mistakes so that each can learn and continuously improve the way he or she works. This is an important exam objective that your team needs to feel that it's okay to fail as long as they learn from that failure. They need to experiment. And some experiments are not going to work out, but that's okay because some are. So you want people to feel empowered and trusted to experiment, to try to improve the work, to make it faster, to make it more reliable, whatever the case may be. We'll talk more about failing and failing fast coming up. But basically, if someone tries to do the work a different way because they think it might be better and it doesn't work out, you don't reprimand them because the rest of the team is not going to try to do things differently than what they've always done. So it's also that people, and the development team in particular, who are the engine of the project, enhance creativity by experimenting with new techniques and processing ideas in order to discover more efficient and effective ways of working. So it's a continuation of what we were just discussing here, that people should feel that it's safe to experiment to improve upon how they do their work. So yes, you want people to do that, you get out of the way as the agile PM. If the team has an idea that they want to try, they should try it; they should have a feeling that they're allowed to, but also encouraged to do so. So encourage team members to share knowledge by collaborating and working together in order to lower risk around knowledge silos and reduce bottlenecks. So a "knowledge silo" is the idea where there's one developer and he's working on one portion of the app that you're creating or the database or what have you, and he owns that portion of the project. Nobody else knows what's going on in there but that one guy. That's a knowledge silo. We don't want that. We want people to collaborate and feel like they share ownership of the code. And often those silos then become bottlenecks because we don't know what's happening with them or we have to wait for that one individual to interact with them. We do not want that. So we want the team members to share knowledge and collaborate with each other. We also encourage emergent leadership within the team by establishing a safe and respectful environment in which new approaches can be tried in order to make improvements and foster self-organization and empowerment. So emergent leadership means that it's not always the same leader and that different leaders emerge over the life of the project. And the leader isn't always—in fact, it's often not the project manager, it's someone from the development team. So you want to allow for that struggle and for different people to emerge as leaders, rather than appointing someone as leader and allowing it to naturally evolve. And this helps if we have that respectful environment in a safe environment; then new approaches can be tried. And so again, you are allowing the team to try to figure out the best way to do the work. If we're going to build a gazebo and we have ten different teams and they all have the same amount of wood and tools and so on, and he says, "Go to it, make a gazebo," you would have ten different approaches to getting that work done. Not that one is superior to the other, but which is the most efficient and truly enjoyable way to create and complete that construction project? The same thing is true with this exam point: the teams become self organized. They figure out how to get the work done that we don't command and control. That's something we avoid in Agile. We allow the team members to work forward. very important point for your exam ok done that Servant leadership entails encouraging and supporting others in their endeavours so that they can perform at their best and continue to improve against some emotional intelligence by encouraging and supporting others. but a new term, "servant leadership." Servant leadership means that you give the team what they need to do their work, that you get things out of the way, that any impediments are removed for the team, and that you support and encourage the team. It's the opposite of a predictive project management approach. Well, yes, you might be the project manager, and you're helping to organize, but you take more of a servant leadership approach in that you give the people doing the work what they need to get things done. So, according to the Agile principles and mindset, those are the nine tasks. Explore and embrace Agile principles and mindset within the context of the project, team, and organization. This represents 16% of your exam, or about 19 questions.

4. Value-Driven Delivery: PMI-ACP Exam Domain Details

In this lecture, we're going to examine the largest domain that you'll be tested on the PMI-ACP exam, and that's value-driven delivery. If you have the opportunity to improve value or simply select anything that is good for value on your exam, you should probably take advantage of it. So let's look at what constitutes value-driven delivery in this domain. First off, with value-driven delivery, there are four subdomains in this one exam domain, and there are 14 tasks that constitute value-driven delivery. It's 20% of the exam. So roughly 24 questions deliver valuable results by producing high-value increments for review early and often based on stakeholder priorities. Have the stakeholders provide feedback on these increments, and use this feedback to prioritise and improve future increments. So basically, what we're talking about with value-driven delivery is high-value increments for review early and often. That's a key point in Agile. What is the priority for our backlog? Our queue of work is always based on what's most valuable, and we do that early in the project so that value comes early. We don't have to wait all the way to the end to have value. We attack the most valuable requirements, or what's called "user stories." We'll talk more about whatever is on our backlog. First, value-driven delivery. Here's one of these subdomains defining positive value: So within defined positive value, we have some activities that we do as the Agile PM to find the deliverables by identifying units that can be produced incrementally in order to maximise their value to stakeholders while minimising non-value-added work. Let's break this down. So, we've defined deliverables, and those are the things we have to create for the customer. So what deliverables can be broken down into smaller units? So we take that requirement and decompose it. And then based on the priorities, we can produce those incrementally. So it maximises value to stakeholders. You don't have to wait until the end to get something back. Now, non-value-added work is anything that is not part of our requirements. So we only work on what's in scope refinement requirements by gaining consensus on the acceptance criteria for features on a just-in-time basis in order to deliver value, and we don't do any gold plating or scope creep that's nonvalue add. So, first off, requirements So what does it mean to be done? What's the definition of done for not only the project but for each requirement? So what's the acceptance criteria? And we have this idea you'll hear a lot about: just in time, the last possible moment, or a minimally marketable feature. So, it's the idea that we don't continue to define and rehash and so on. What information do we need exactly in order to create this thing? This is a requirement. So it's on a just-in-time basis. So when do I need the information? When is it due? And then we deliver it. We select and tailor the team's process based on project and organisational characteristics as well as team experience in order to optimise value delivery. We'll talk about process tailoring in this course. Basically, if you're new or your team is new to Agile, you want to try things that have been proven. And as you become a little bit more experienced, you can move to a process or adapt or create a process that is a little bit more comfortable for your team and your environment. This doesn't mean you can't experiment, but it's just that we don't want to get too crazy right from the start on processes. If we're new to it, let's stick with what works and what's been proven, and then over time we can grow and evolve at different rates. So this helps us. Our approach and how we develop and deliver are based on proven information. And so that helps us to have a standard or something that's proven so that we can focus on creating the deliverables to provide value to the customer. We want to avoid potential downsides. So the idea here is that where there is risk or an opportunity for failure, we obviously want to avoid those, so we want to avoid potential downsides. So one way we implement this plan is to organise requirements into minimally marketable features or minimally viable products in order to allow for early recognition and delivery of value. And I hinted at this a little bit early. So the idea here is to take our requirements and break them down smaller and smaller into the smallest thing we can create while still adding value. because it's easier to create a smaller item than it is a larger item. And by developing the smallest or most minimally marketable feature or the most minimally viable product, value is recognised early. So we do this early in the project. If we consider building a house, there is no point in doing so until it is completely demolished. You can't move into the house just when they have the framing done. You have to wait until everything's done before you can move in. But with software, we don't have to wait till the end to get some return on the investment. So if we find the most needed features upfront—the minimally viable product, the minimally marketable features upfront—and we make those a priority and deliver those, we have value early in the project, limit increment size, and increase review frequency with appropriate stakeholders in order to identify and respond to risk early on and at minimal cost. So limit the increment size. We're talking about: how long will an increment last? Typically, two to four weeks. And then increase the review frequency. So we want stakeholders involved in these reviews because we want consensus; we want buy-in; we want validation that what was created is what was delivered. also gives us an opportunity to respond to risk early on and at minimal cost. And this is something we'll talk about coming up: when we examine our project for risk events, we often put the riskiest items first in our backlog because that gives us an opportunity to attack those high-risk deliverables or high-risk events early in the project and make a determination of whether this project is feasible based on the risks that may be lurking in the project. If we wait until the very end of the project to examine these risks or to try to see what happens with these risks and the risk happens and they call our project a failure, then we've wasted all that time, money, energy, and effort to get to that point. So we do the inverse. We take the risk early and attack it early. And then that keeps us at the idea of a minimal cost—if the project doesn't work or the approach doesn't work because of this risk, we haven't spent a tonne of money and a lot of time to find out late in the project. Solicit customer and user feedback by reviewing increments often in order to confirm and enhance business value. So, pretty straightforward, right? Get your customers and users involved, and they'll look at what you've created in an increment. And so that helps them to say, "Yes, this is what we want." It helps them to be excited about what you're creating, and it helps to enhance business value. Prioritization. I've hinted at prioritisation a couple of times in this conversation. Let's just be really clear on what it is. You prioritise the units of work in collaboration with stakeholders in order to optimise the value of the deliverables. So you take the project requirements or the deliverables that you promised in the project and decompose them. Often those are your use case or user stories or the backlog. And then you say, "Okay, what are the most important things here?" What's the priority of these items?" And that's what you deliver first. And so you do that with the customer, sometimes called the product owner, and you attack those first. In your iteration, that sprint was two to four weeks. You perform frequent review and maintenance of the work results by prioritising and maintaining internal quality in order to reduce the overall cost of incremental development. What this is basically telling us is you review your work, you do some testing, you do refractoring so that you ensure that mistakes, you don't have an escaped defect out to where the customer can see it. So internal quality, and I'm talking about quality control, really is the inspection of the work before the customer sees it. So you don't want the customer to see mistakes. So you do that frequent review and maintenance, which is your refactoring, you clean up the code, and then you prioritise and maintain quality control because you don't want the customer to see the mistakes continuously identify and prioritise the environmental, operational, and infrastructure factors in order to improve the quality and value of the deliverables. So this is saying, one, the environment—where are we going to work? We'll talk about being colocated versus noncolocated operational. How do we check in and check out code? How do we do the integration of code? What about collective ownership or team programming? So there are some items that we can do to help us prioritise the quality, which directly affects the value of what we're creating. Incremental Development: There are many tasks on incremental development here. Now this will be an important topic for your exam, obviously. You can see there are five activities that you do in incremental development. Conduct operational reviews and or periodic checkpoints with stakeholders in order to obtain feedback and corrections to the work in progress, sometimes called the "whip" and "planned work." So what you do at the end of an increment is provide an opportunity for the stakeholders to talk about what's been created. So these periodic checkpoints are a way to say, "Hey, what worked and what didn't work?" Are we on track? And you do this throughout the project; you just don't wait till the very end. And this is an opportunity as well, before you start the next sprint or iteration, to reprioritize the backlog of requirements, user stories, and so on. You balance development of deliverable units and risk reduction efforts by incorporating both value-producing and risk-reducing work into the backlog in order to maximise the total value proposition over time. This ties back to our conversation just a few minutes ago in our backlog. Now the backlog, just to be clear, is all of the things that we have to create. So we have this long list of prioritised items. If we do not include items that are high-risk until the very end of that backlog, that could be a risk in and of itself, that it causes the whole project or portion of the project to fail. So you incorporate both the high-priority items—those that are value-producing—and those that are laden with risk so that you can mitigate those risky events and prevent the risk from happening. So the backlog includes both value-producing and risk-reducing items as we go into each iteration, with the goal being to take the highest-risk and highest-value items first. You don't spread it out evenly, you detect those first, getting your value up front. To maximise value, you will reprioritize requirements on a regular basis to reflect changes in the environment and stakeholder needs or preferences. This happens before each sprint or iteration, where the product owner will look at the requirements. And so you and the product owner of the project team will look at reprioritizing the backlog. and sometimes that's called grooming the backlog. But you reprioritize those so that you go on to the next iteration or sprint. You're attacking what's most valuable to your customer—elicit and prioritise relevant non-functional requirements such as operations or security by considering the environment in which the solution will be used in order to minimise the probability of failure. So you think beyond just the functional requirements. So that's all it's telling us here--don't forget to address non-functional issues so that you are doing some risk mitigation here. You don't want the thing to fail once it goes into production. A great example here in the States is that there's some medicine now that you have to go up to the pharmacist to get, like allergy medicine and so on. In some stores, there's a little lock right over the medicine, with just a glass panel that comes down and someone has to open it so you can reach in and get the medicine, and they get it for you. Well, a great example here of how they didn't prioritise nonfunctional requirements is that the glass shelf was down, but you could easily reach behind the glass shelf because it was open on the end of the shelf and get the medicine yourself. So they didn't think about the whole solution all the way through. They had some probability of failure there. All right, moving forward, conduct frequent reviews of work products by performing inspections, reviews, and testing in order to identify and incorporate improvements into the overall process, the product, or the service. So of course you're going to do inspection, reviews, and testing, but you don't wait till the end of the project before you incorporate that into your sprint or iteration—or as you finish, you enter some type of unit testing or J unit testing to confirm that it's valid and good and can pass the test. So here's what we just looked at: the Agile Principles and Mindset (16%), and then we looked at value-driven delivery. The big one in this domain is at 20%, so you can see those two alone are 36% of your exam. So these first two objectives are very important, and the next one we'll talk about is stakeholder engagement, which is also very important.

5. Stakeholder Engagement: PMI-ACP Exam Domain Details

Welcome back to our discussion on the exam objectives and the different domains and tasks. We're now ready to talk about stakeholder engagement. and stakeholder engagement, there are nine tasks that you'll do, and those are spread across three subdomains. Now stakeholder engagement is 17% of your exam. So, roughly, 20 questions. So what is stakeholder engagement from the exam point of view? Engage current and future interested parties by building a trusting environment that aligns their needs and expectations, balances the request with an understanding of the cost and effort involved, promotes participation and collaboration throughout the project lifecycle, and provides the tools for effective and informed decision making. Let's break down stakeholder engagement, let's break this down. So current and future interested parties. So current is pretty self-evident. The people who are involved from day one in your project are stakeholders. Now, future interested parties may be customers or end users, or who knows, right? Because it's in the future. So current and future interested parties that you can begin to identify. You want to identify stakeholders as early as possible in any project, but especially in an agile-driven project. And then how do you engage them? You build a trusting environment. So you listen to people, you try to understand their needs and what do they want, and you confirm that you understand their needs and expectations. Now that we understand someone's needs and expectations, there has to be some collaboration that they have to understand, okay? To create that thing, this is what it's going to cost, and this is how long it's going to take. So the cost and effort involved need to be communicated within the project. You promote participation and collaboration. So you just don't start the project and walk away from the customer. They continue to be involved, but it's also your team that's involved. They help make decisions. The team owns local decisions, meaning they decide how they do their work and who does what. the idea of emergent leadership. You also have to provide the tools for effective and informed decision making. So you have to provide information on time, cost, and any risks to show how the project is going. You don't hide information if you're open and honest, and that allows stakeholders to make informed decisions. Let's look at the first subdomain, which is to understand stakeholder needs. So think of this as the point of view of the stakeholder. Identify and engage effective and empowered business stakeholders through periodic reviews in order to ensure that the team is knowledgeable about stakeholder interests, needs, and expectations. So you, the project manager, are going to work with the stakeholders that you want to understand periodically, typically at the end of an iteration, and before you start the next iteration, you have this periodic review. But you really want to understand and make certain that you understand what the definition of done is, what should this look like, and what are they really trying to say? And that's the idea behind communicating the vision over. As a result, you receive some confirmation that your new understanding is in line with what the stakeholder desires, and you communicate this to and with the project team. So the team understands what's important to the stakeholders and what they are expecting. Next point. Identify and engage all stakeholders current and future by promoting knowledge sharing early and throughout the project to ensure the unimpeded flow of information and value throughout the lifespan of the project. So, stakeholder engagement, very important, very important topic for your exam. It's so important that in this course I have a section lecture, several lectures just on what the Pinbock has to say about stakeholder engagement. If you're a PMP or if you've ever read The Project Management Body of Knowledge, Fifth Edition, there's a new chapter on stakeholder management. Now, while that chapter is more towards predictive life cycles, it has a lot of overlap with the Agile domain and stakeholder engagement. So this is something that you want to pay attention to and really embrace. The idea of stakeholders being involved throughout the project—not just at the end but also in the beginning and in some periodic reviews—is a good one. It's important that your team talk to business stakeholders every day throughout the project. Next domain. Ensure stakeholder involvement. Establish stakeholder relationships by forming a working agreement among key stakeholders in order to promote participation and effective collaboration. So what is this working agreement? It's basically the rules of how the project will operate, the reviews and the timeline for reviews, keeping the stakeholder involved and coming to the appropriate meetings, and then the stakeholder making decisions on time so that both parties are collaborating. But both parties have responsibilities for the project. Maintain proper stakeholder involvement by continually assessing changes in the project and organisation in order to ensure that new stakeholders are appropriately engaged. So this is always being on the lookout to identify stakeholders. And so should a new stakeholder be recognized. You take action, and you get that stakeholder engaged as quickly as possible. Think about it. In the real world, you don't want to be in the middle of a project and suddenly realize that you forgot a whole group of stakeholders. That entire group of stakeholders is not going to be pleased with you and your decision to move forward with the project without consulting with them. So if this happens, you have to take immediate action and get those people involved, and then you can move on to the project. Establish collaborative behaviours among the members of the organisation by fostering group decision-making and conflict resolution in order to improve decision quality and reduce the time required to make decisions. So we want collaboration. That's really a key part of the whole exam: that we collaborate with stakeholders and our team, and our team collaborates with one another but also with the stakeholders. And so we have group decision making. And a great example of this is the idea of the backlog that we have an individual, the product owner or the business owner, whatever approach you're using, that they look at this backlog and then they determine what's most important next. Now they don't do it alone. Often they do this or usually should do this with the project team to help them sort the backlog items by priority. And so it's a group effort; it's collaborative, and we want collaboration. That's a key thing on your exam. If you can choose collaboration, especially if it contributes to value, that's a given right there. Our last one here. Manage stakeholder expectations. Establish a shared vision of the various project increments so products deliverables releases iterations by developing a high level vision and supporting objectives in order to align stakeholders' expectations and build trust. Okay, that's a lot, but basically what we're saying here is to get the shared vision. So how do you get a shared vision? You begin with a high-level vision. So if you and I say we're going to make a piece of software where I'm the PM and you're the customer, and we want a piece of software that shows me all the restaurants where I physically am and what's their special, what's on sale, or what events are happening, that's the high-level vision on which you and I agree. That's the thing we want to create. So then what are the supporting objectives? So we drill down a little bit and again and again and again. But we have to start with consensus of the share dvision and that follows us through the whole project. Next, establish and maintain a shared understanding of success criteria. deliverables and acceptable trade-offs by facilitating awareness among stakeholders in order to align expectations and build trust. So just to follow up on that first one, we have a high-level vision, a shared vision, but we also need a shared understanding of what constitutes success and then the idea of acceptable trade-offs so we can deliver a particular feature, but it's going to take more time or more money. So that would be a trade-off. Do you want it? If you do, we just need more time to create it and you got to pay for that labor. And so we're open and honest about that and that helps us to align expectations and build trust. Provide transparency regarding work status by communicating team progress, work quality, impediments, and risk in order to help the primary stakeholders make informed decisions. So when we talk about how the team is moving along, are they on track or are they behind schedule? It's not a secret if we're not doing great, we're not doing great. That's just the way it is. But we need to be honest about that so that stakeholders can make good decisions about what's happening in the project. Provide forecasts at a level of detail that balances the need for certainty and the benefits of adaptability in order to allow stakeholders to plan effectively. So it kind of goes along with that idea of transparency, that we don't keep things too high, but we also don't make them too detailed, but we need to give enough information that stakeholders can say, "All right, this is the way that we need to move." Or, these requirements aren't as valuable now because we have lost less time to get the work done. So it's a way of looking into the project with enough detail to make educated decisions.

Hide