Complete PMP Mindset 50 Principles and Questions

When it comes to passing a PMP exam, it is critical to understand the PMP mindset. In this video, I'm going to be going over the 50 PMP mindset principles that you need to know for your exam and we're going to do a practice question

with each one of these principles. That means this is about to be a really long video because we're going to be doing 50 questions and we're going to be explaining all of the mindset to you. Now, these principles, where did we get them from? Well, I created them when I

wrote the first version of my study guide, PMP Exam Prep Simplified. I'm Andrew Ramial, and my my book, PMP Exam Prep Simplified, is the number one bestselling PMP study guide in the entire world. I'm also the creator of UDMI's bestselling PMP course with

hundreds of thousands of students enrolled and they're all passing their exam. You can check the links below to find my book and my courses. You can also take this course on our platform. Now, let's just talk about this. There's a video that a lot of you guys have been asking me to make. There's a lot of

other videos on YouTube that talks about the mindset. I want to point out something. I created the PMP mindset when I wrote the first version of my book. In fact, most of the other YouTubers are just repeating some of the things that I've already taught you guys. So, this is your going to be the original and I'm going to call it the

Andrews official official PMP mindset. Now, this mindset, most of it is already taught to you if you have my 35 hour course. By the way, my 35-hour course, again, you can get it on UDMI or tiaexams.com, or you can get it if you

get a copy of the book. That's free or in the live class. All the links again below. Now, this is going to be an expanded version of that mindset that I taught you in the 35 hour class as this includes practice questions. while that did not uh I highly recommend that you guys do

this after your 35 hour class. Don't watch this video until you do the 35 hour class cuz I'm on I am under the assumptions that you did. I'm not going to go in-depth explaining everything because I'm assuming you already know that. So, please watch that before doing

this video. Some of these principles will be repeated slightly. I did that because I wanted to either emphasize it or just to do more practice questions on it. So while it says 50 principles, some of them are pretty pretty close to

to each other. Now, if you want a PDF copy of these principles so you can study individually or without the video and you want to just practice the questions, it's attached to the videos in the courses. So make sure you get the course. Uh if you have it on the UDI

platform, you'll see it's attached to the lecture. It probably gave you a link to this. Uh so you can go go to the Udemy platform. It's going to say PMP mindset video on YouTube. You also have it in the TI exams platform. You can also get the PDF there. So make sure you

get the PDF of this so you can study these principles. And with that guys, let's go ahead and get started uh with these principles. So let's get to the first principle here.

Okay. So principle number one, continuously identify and analyze stakeholders, not just at the beginning of the project. You see, throughout the project life cycle, stakeholders come and go. Mary is working in the

accounting department for that new accounting application you're making. Well, Mary got fired yesterday and she's replaced by Jane. Now Jane is a new stakeholder and she prefers communications differently. A project manager just doesn't identify and analyze stakeholders once on a project.

They do it consistently throughout the project as stakeholders come and go. A couple months ago, a new regulator was introduced to manage your type of projects or to regulate projects that you're currently doing. Now that's a brand new stakeholder on a project. In

the world of traditional project management, the term identify stakeholders is one of those 49 processes and is done in the initiating part of the project. But I want to point out that that process, even though it's listed in initiating, it's something that you're going to do

throughout the entire project. So keep that in mind. Let's do a practice question on it. Practice question number one. Now, I want to point out before I get into this question is that I'm just going to be reading it and answering it. So if you want to practice it, the best thing you can do is pause the video. the moment you see the question and you try

to answer it. Okay, so question number one, you're managing a software development project that is 60% complete. During a sprint review, the marketing team mentions that the new chief marketing officer who started who started last month has expressed

concerns about the user interface design and wants to be involved in the upcoming decision. What should you do first? Couple key words in here is that we know that we have a brand new person. notice the new CMO and what should you do first? A inform the marketing team that

the designs is already approved by the stakeholders during initiation and cannot be changed without a formal change request. Schedule a meeting with the new CMO to understand their concerns and update the stakeholder to register update the stakeholder register to

include them. Ask the marketing team to have new the new CMO submit their feedback through an existing project communication channel. continue with the current sprint as planned and address the CMO's concern during the next project phase. So remember the remember principle one was to cons continuously

identify and assess these stakeholders as the project is progressing. What answer does that? Well, the best answer here is going to be B. That's right. What we want to do is we want to meet with this new CMO. We want to understand

their concerns and we want to update that stakeholder register. The stakeholder register is a document that is consistently updated throughout the project. It's not something that's just updated once on the project. And once again, even though the process of identify stakeholders is in the

initiating phase, it's something that's done consistently throughout the project. Anytime you have a brand new stakeholder on a project, you must assess what they want. And the best way to do that is to meet with them. generally best way face to face understand what they're looking for,

what is their concerns, what's their impact on the project, how does the project impact them, and then update your stakeholder register with that information. And then you can make the communication management plan and stakeholder engagement plan to keep them engaged. All right, let's take a look

here at principle number two. Engage stakeholders regularly via various channel various channels. Now I want to point out that this is a really important principle because you see when you identify the previous principle is

to always identify and consistently identify your stakeholders. We want to keep our stakeholders engaged. I've always told my classes this. I've told my students this and I've told my team members that I work with this. The worst thing that can ever happen in

the world of managing a project is a stakeholder that loses interest in your project. A good project manager will keep their stakeholders consistently engaged on the project. How do we do that? It might be meeting with

them. It might be giving presentation, taking feedback, positive, negative feedback from them, showing them a demo of a particular product. So always consistently engage your stakeholder on a regular basis. Some stakeholders may

be engaged maybe once a week, maybe daily like team members, once a week like a sponsor, once a month like a CEO. Different stakeholders, different engagement, different times of engagement, different types of engagement. Let's take a look at a practice question with this one.

Practice question number two. You're managing a construction project for a new community center with stakeholders including city council members, local residents, environmental groups, contractors, and a project sponsor. You have been sending weekly status emails to all stakeholders for the past 3

months. But email response rates have dropped significantly and several key decisions are being delayed because stakeholders not providing timely feedback. What is the best approach to improve stakeholder engagement? Now before I get into this question, I want to point out that very common on a

project, you're going to have things like this. And if you notice these particular things, you have many many different kinds of stakeholders here. If you notice, we have city council members, right? We have uh local residents, we have environmental groups, we have contractors, sponsors. And what

you're doing here that's wrong is you're basically doing one kind of communication or engagement methods for all of these stakeholders. And this this is probably going to be incorrect. What is the best approach to improve engagements? Let's see the answers.

Increase the frequently frequency of emails to twice a week and request read receipts to ensure stakeholders are receiving the information. implement a multi- channelannel communication approach including face-to-face meetings, site visits,

online dashboards, and phone calls based on stakeholder preference. Now, I think this is a better answer so far, better than this here because if you look at A, A is not doing much. What A is doing is just increasing your inefficiencies

with just those emails. You're just making them more and you're annoying people by having read receipts. Not the best thing to implement. Schedule a mandatory monthly meeting for all stakeholders um to discuss project status and issue in the issue issues in person. Problem

here is going to be it's one communication methods to all of them. Maybe not all of them can attend the mandatory meeting. Create a more detailed email template with charts and graphics to make the status report more engaging and informative. While this does sound good, once again, you're basically doing one

communication methods for every stakeholder. Remember, different stakeholders should have different forms of communication. Better forms of communication means they're going to probably be more engaged. Let's take a look at the next

principle. Oh, where is that? Here we go. Principle number three. Use emotional intelligence to assess and respond to stakeholders needs. When issues occur with one person, address them with that person only. Now, I want to talk about EI.

Emotional intelligence is really, really big on your on your exam. You see, emotional intelligence, what this means is understanding your emotions, how your emotions impact how you're feeling and how it impact others. and the ability to

read other people's emotion. So, imagine you're engaging with a stakeholder and you're telling them some kind of status on the project. Can you emotionally detect if they're really upset with you or if they're really happy with you? Do

you understand how your persona, your emotions is making them feel? You ever talked to a boss before and you're like, "Man, that guy doesn't know how to talk to people." That's basically emotional intelligence. emotional intelligence. If you are a master at it, you'll be able

to master your own emotions. You'll be able to understand how your emotions impact others, and you'll be able to understand other people's emotion. Emotional intelligence is called out on your exam objectives. Another point here with this uh principle

is you're going to have to deal with all different uh stakeholders out there. And I want to point out that a lot of times on this exam, you can have questions where one person is causing a problem. Maybe this person is really loud and

makes a lot of fuss during meetings. Maybe this person is a dominant force in meetings. Maybe this person is demoralizing other people, especially on a team. Anytime mindset, anytime you have one person doing something bad on

the project, don't confront this person in front of everybody else. Meet with them uh in a one-on-one setting and see why they have this. Don't give them solutions right away. Understand the root cause of their problem. Why are you like this in private? That's the main

point here. Let's go do practice question on this one. Practice question number three.

During a status meeting, you notice the marketing director, who's usually very engaged and talkative, has been unusually quiet and appears frustrated. When you present the timeline for the marketing campaign launch, she briefly responds, "Fine, whatever works."

without her typical detailed questions or suggestions. What should you do next? Now, I want to point out that this is this is going to be with that principle three mindset and notice this is a problem with just this particular person. So, what should we do? All

right, let's see here. Continue with your plan work since you said the timeline was acceptable. Put on my pen here. And you have and you have urgent deliverables to complete. probably not the best answer here because what you're

doing is you're just doing nothing. Part of the mindset is never do nothing. In this one, you're not really helping this person. You know they're upset. You notice they appear upset, unusually quiet. So, you're detecting this is good emotional intelligence. You detect that

whenever they say fine, whatever works, your emotional intelligence, your EI is telling you this person is really upset. Just don't leave the stakeholders like that, especially since they're a director and they're probably a senior stakeholder. So, I wouldn't do it. Send a follow-up email to all attendees

asking if there are any concerns about the timeline that weren't addressed. Not a good answer here. Also, here's why. You're sending a follow-up email to all attendees. You know, the problem is with one of the attendees, not all of them. So, let's address it with that person,

not all. This the question doesn't say everybody else was upset. Reach out privately to the marketing director to check if everything is okay. I understand if there are any other there any uh underlying concerns. I like this answer. So I'm going to leave this one.

I'm not going to put X on it. D. Schedule another meeting with all stakeholders to revisit the timeline discussions and ensure everyone is truly aligned. The only person that's not truly aligned here is the marketing director. So I think we need to keep our

discussions with that marketing director. In this question, we used our emotional intelligence to detect, hey, this person was not happy with what's going on on the project. And then we reached out. We used that principle of, hey, you know what? Let's go ahead and

just engage that single person in there. All right, let's take a look here, guys, at principle number four. Document all impacted individuals as stakeholders. Even if their involvement is indirect. If someone is impacted

positively or negatively, they're a stakeholder. One of the things we have to understand is who are stakeholders on a project. On a project, anyone and I mean anyone or groups of people that are positively and or negatively impacted

our stakeholders. We want to document them in our stakeholder register and we want to analyze them. We want to tailor our communications to them. We want to tailor, for example, progress reports or um project reports to them. Now, I

really put this principle here because I want you guys to understand that when people are positively impacted, they're a stakeholder and negatively. A lot of people think that if you're positively impacted, for example, you're working in a company and there's a new AI software coming out and it's going to help make

your work a lot easier. Most people think those are stakeholders. What people forget is that Bob who is losing his job because of your new AI software. Bob is also a stakeholder. So keep in mind not just people that are positively

impacted or stakeholder. It's people that are negatively impacted. Let's say they're building a highway next to your house. Well, you're not happy about that. The noise, the pollution, but you know what? you're going to be negatively impacted, but you're also

going to be positively impacted because now you can use the highway to get to work 10 minutes earlier. So, always remember positive and negatively impacted are cons folks that are positively negatively impacted are considered stakeholders. Let's take a look at take a look at a question on

this. Question four. You're managing a project to implement a new CRM, customer relation management system for the sales

department. During a requirement gathering session, you learned that the new CRM will automatically generate reports that the finance team uses for commission calculations and will integrate with the customer service system that tracks warranty claims. What should you do regarding the finance and

customer service teams? A keep them off the stakeholder register since they wouldn't directly use the CRM system but ensure the integration requirements are documented in scope. I wouldn't do this because remember what the principle says positively and or negatively impacted

directly and indirectly impacted those are all stakeholders. So let's not do this. Add both team to the stakeholder register and include them in the project communications even though their involvement is indirect. I think this is a decent answer because we're adding

them to the stakeholder register which means we're going to be analyzing their needs. We're going to be communicating with them. We're going to probably be giving them updates. Contact the finance and customer service team only if the integration issues arise during the implementation to avoid unnecessary project complexity. No, I

would put them in the stakeholder register. Ask the sales director to coordinate with finance and customer service teams on your behalf since they understand the business relationship better. So I wouldn't do this. All right? Uh I wouldn't give away the work. Part of the mindset is never to give

away your work like that. So, I think the best answer here, guys, is going to be B. Add them to that stakeholder register because even though they're somewhat indirectly impacted while it's going on, they're going to be directly impacted when the project is finished and they're

using the applications. So, remember indirect or directly impacted, they're a stakeholder. Positive, negatively impacted, they're still a stakeholder. All right, let's take a look here, guys, at the next principle. Principle five.

Principle number five, don't dismiss customer requests prematurely. Evaluate each one carefully. Don't do nothing when someone has asked for for any for anything. I added this here right before this video. I always

tell my students this. If you get a question where a stakeholder has some kind of a problem or they have some kind of issue with something or they're asking some kind of question and the there's a choice to like not do anything

or not help this person or ignore this person, it's never the answer. A good project manager is proactively engaging, speaking and communicating with the stakeholders on a cons consistent basis. So keep that in mind. Don't push people

off. So, in this one, never dismiss a customer request. Anytime a customer asks something, at least tell them something. Assess something for them. Give them feedback on what they're asking. And never do nothing. If there's a choice, uh, one of the four choices

that says, uh, let it be and you'll talk about it later, it's probably not the answer. Let's take a look at a practice question on this principle. question.

You're managing a website redesign project that is 75% complete and on track to finish on time and within budget. That's good. The client calls you with a request to add a new chatbot feature that they saw on a competitor's website, which would require significant

additional work and potentially delayed a project by three to four weeks. What should you do first? All right. So they want to add something that's going to significantly increase the schedule. What are we doing first here? Meet with the client to understand the business value and urgency of the

chatbot feature. Then analyze the impact across all the knowledge area scope, schedule, quality before making any decisions. I like that answer. It's not bad. Why? Because you're addressing the customer concerns. You're not just pushing it away. Inform the client that adding a new feature at this stage would

cause significant delays and cost overruns and suggest they consider it for a future phase. Well, I don't like this answer. You know why? Because you're just dismissing the client. You're not really understanding why this client wants this. You know, I want to point out something.

We do projects not for us. We do projects for our clients. We do it for our customers. When the customer wants something, just don't dismiss them and say, "Hey, we're not going to do that for you." Remember, we're not doing these for us. We're doing it for them. Ask the development team to provide a

detailed estimate for the chatbot feature so you can present the client with accurate cost and schedule impacts. Oo, that's a good one, too. So, A and C, decent answers, right? Because we didn't dismiss them, but we tell them we're going to assess it for them.

D. Explain to the client that the scope is already approved and any changes would require going through a formal change control procedure. Oh, this is a good one. So, we're we're telling them, hey, if you want this, fill out this change request. Uh, A is meet with the client to

understand the business value. Uh, D is tell them, hey, follow this particular change. What answer would you go with? Okay, the key word to get this one correct is going to be notice it says first. That

arrow should be pointed first by the way is a before you tell this person, hey, go fill out a change request or before you have the team go ahead and um before you have the team assess the feature to

really see how much it's going to increase the scope and the time and cost and all that. Before you do all of that, why don't you meet with this person first? Why don't you understand the business value? So that way you and your team can then have a good understanding of exactly what they want. So before you

have this person um go through the formal change control process, before you have your team do anything, let's meet with the client and let's go ahead and understand what they want.

All right, let's take a look here at the next principle. Now, these principles here are going to be change management. Let's cut off a little there. We got six principles on change management. All right, principles number six. Now,

we're talking about changes. All right, change changes is important. Uh on a project, you are going to be asked to change things. They're going to ask you, you're managing a project, somebody's going to

come to you, can you add this to the scope? Can you remove this to the scope? Can you make it cheaper? Can you make it faster? These are common changes that you should expect. The question is, how are you going to manage these particular changes? That's the main that's the main

key here. And the way we manage changes is going to be different depending on whether you're doing that agile project or that traditional project. Let's see. Let's see what this principle is about. Traditional. So if you're managing a

traditional project, you want to follow the plan. Do not allow changes without an approved change request. Whenever you can, always follow the plan. Now what do I mean by that? On a traditional project, you have this giant hopefully

you studied your you watch your 35 hour class with me. You remember me talk a lot about this giant project management plan. It has all these components, all those 18 plans and the baselines and everything like that. Your objective when that project execute is to follow the plan. If it's not in the plan, don't

do it. If somebody wants to add something to the scope, they first need to go through an entire change control process and get it approved by maybe the sponsor or the change control board. So if it's not in the plan, you don't do it. You must have them submit it as a

change request and then add it to the plan. Now any changes to the PM plan must follow a detailed change management process and never implement a change without assessing it. One of the common questions you get on your exam is

somebody wants a change or one of the choices is going to say implement the change to keep the pro project on track. It's never the answer on a traditional project. Never implement the change without assessing it. Now this of course will change drastically. The whole

change management process will change drastically when we come to agile project management. Just a quick review in agile project management the scope itself is managed in the product backlog. In traditional project the scope is on the scope

baseline. So here we have the uh on on the agile project here we have um the product backlog which is man managed by the product owner. On an agile project, change is welcome and managed through backlog prioritization and sprint

planning rather than formal change control processes. Only the product owner can add to the product backlog. What do we mean by that? Well, on an agile project when somebody wants a change, when somebody wants to add something, for example, to the scope, basically it's told to the product owner

and the product owner really decides if we should add it to the product backlog, which is like their scope statement. And then the product owner determines how to prioritize it. Does it go to the top of the backlog? Does it go to the bottom, middle, and so on? This is outside the control of the project manager. So keep

that in mind. Traditional, somebody wants a change to something, they got to follow the change control process. We have to assess it before we approve it. In agile, they want a change. They talk to the product owner. The product owner decides whether to add it into the product backlog or not. So, keep that in

mind. When somebody wants a change on a project, let's do a question on this. Question number six. A project manager is leading an agile software development project when the product owner requests

to add a new feature that would enhance user security. The feature was not in the original requirements and would require significant development effort. The team is currently in a middle of a twoe sprint with committed deliverables. What should the project manager do? So I

want to point out that this is a practice question that deals with agile projects. You got to remember the agile project principle. What should the project manager do? Submit the new feature through a formal change control process for approval. Probably not. Why? Because remember what

I said. This is an agile project and they don't have a formal change control system. Work with the product owner to add the security feature to the product backlog for prioritization. I like that. Okay. Remember, you're not adding it. The only person that can add something to the product backlog is a product

owner, not the project manager, not the project team. immediately incorporate the feature into the current sprint to address security concerns wrong. You can't just add something in.

At no point is a project manager allowed to add to the scope. Traditional and or agile. Keep that in mind, okay? Because in a traditional project, it has to go through a formal change control process which is generally going to be approved by the sponsor. In an agile project,

it's a product owner. At no point should the project manager be adding anything to the scope statement and or the product backlog. Reject the request since it wasn't part of the original project scope. I want to point this out again. You never ever

reject a change on a project. It's not your authority to reject changes. Anybody that wants to change goes through the change control process and or they will go through the product owner. So keep in mind that the best answer here is of course going to be B.

Let's work with the product owner. Somebody wants to add a feature. Work with the product owner to get that done. Now I do expect quite a few questions on this particular topic because on this topic changes is something that all project managers will deal with. Let's

take a look at the next principle. Principle number seven. Any stakeholder requesting changes to the project management plan must submit a change request. This is common. If you are on a traditional project and somebody comes to you and says, "Hey,

Andrew, I want to um add some work to your scope. The best thing you can do is well, if you really want this, you know, meet with them, understand why they want this, but for it to go through, they got to submit a formal change request. This is going to be a document where they document the

change so you can assess it. Agile is going to be different. Agile handle changes through direct collaboration with the product owner who prioritize a request in a product backlog without a formal change request.

So this is very very similarly related to the other principle is that hey when somebody wants to change make sure to submit a change request and in agile there's really nothing there with change requests. They just give it to the product owner. Let's take a look at a question on this.

Question seven. During your weekly status meeting, the sponsor mentions that due to new regulatory requirements, the project timeline needs to be accelerated by one month to meet a compliance deadline. The sponsor states, "This is critical for

the business and needs to happen. What should you do next?" Now, I want to point out that this, you can see right off the bat, is a traditional project. And you're asking, how does he know that? Well, notice it doesn't really say product owner. It says product sponsor, right? Project sponsor. So, this it's

not a this is more than likely not a agile project. So, we're going to follow those traditional rules. What you do next? Begin working with a team immediately to develop a compressed schedule that meets the sponsor's requirement. See, this is probably not

right. Now, the reason for that is because notice you implemented the change right away. Ask sponsor submit a form of change request detail and regulatory requirements and timeline changes before proceeding. Okay. Analyze the current schedule to identify opportunities for compression and

present options for the sponsor. Here you're you're doing something without getting the formal change request. Schedule a follow-up meeting and key take discuss the impact of the accelerated timeline. Let them submit it. let's analyze it before we doing this. The next thing you should do is hey sponsor calls you up and says hey

can you get this done and you're like your next response should be okay let's get that change request let's detail exactly what you're looking for making be the best answer on this one and that's something that you want to consistently point out that I should point out on a consistent basis is that

you have to always assess changes before implementing them on a traditional project. I know I said that 500 times, but it's important. Let's take a look at the next principle, guys. Principle number eight. Now, principle number eight here is a

traditional thing. All changes must be reviewed and assessed. I want to point that out in particular. You know, this something we just talked about. Anytime somebody submit a change, and more than likely for your exam, it's going to be a scope change. As we see

here, you want to assess it. A scope change must be assessed across all the other knowledge areas. And that's going to be when somebody changes scope, assess to see how that affects time or schedule, budget, quality requirements,

people requirements, right? How many more people or physical materials you need, communication requirements? Is that going to change? How much risk does it add or remove? Does it do you need new contractors? Does it change the way stakeholders are engaging? So keep that

in mind that anytime a scope somebody wants to change a scope, more than likely it's going to affect almost all aspects of the project and you really need to assess that. Let's do a question on this.

Question number eight. You receive a change request from the marketing team to add a social media integration feature to your mobile app project. The request seems straightforward and your lead developer mentions it would be easy to add an

estimates about two days of work. Okay, not too bad, right? Somebody's asking to add something in. This is definitely a scope change. Two days of work. What should you do? A approve the change immediately since it's low risk and a team has done similar work. Well, first of all, the

project manager doesn't have the authority to just approve work. So, I'm going to eliminate it. Ask the marketing team to wait until the next change control board meeting to maintain proper governance. Never ask people to wait. That's part of the mindset. Don't tell people to wait or push things off. So, let's not go with this one at all here.

Conduct a thorough assessment of the change change request on scope, schedule, cost, quality, and risk before making any decisions. Okay, that's that's good. So notice that you're assessing this change against lots of different aspects of the project. I like that. Since it's urgent and seems simple, implement the feature now and

document the changes. No, you'll notice that D, which is just implement the change right away. And A, approve the change yourself basically is basically the same answer. Best answer here guys is just like the the the mindset is telling us make sure

we assess how these changes affects the entire project. And this is a question that you're going to see a lot of. All right. A lot of people would ask questions. You're probably going to get three or four questions on the exam that talks about asking for changes. Remember, don't approve of a change

until you've assessed that change. All right, let's go ahead and take a look here at the next series of principles. We got quite a few principles 9 to 17 deals with decision- making and problem solving. Now, I want

to point out that your exam, more than half of it is going to be dealing with problems. I wouldn't be surprised 180 questions, 90 to 100 questions is some kind of problem. Problem with a vendor, problem with a customer, problem with a team member,

problem with regulators, problem with senior management, problem with equipment. Your your your exam has a lot of things that deals with problems. So how are we going to deal with this? Let's take a look at these principles. Now principle number nine.

Now traditional how do we deal with problems? First of all never act without a plan. Planning is done once for the entire project. This is important. Anytime a problem arise

and problems are more than likely are issues, right? So what's an issue? An issue is something that has occurred that is negative on your project that has to be fixed. The reason why we have plans in place, the reason why you have that giant

project management plan in place is that when an issue arise, a problem, some something happens on a project, the plan tells you how to fix it. For example, let's say you're working on a project and there's a problem that's going to delay the project. Well, how do you deal

with schedule issues? Well, read the schedule management plan. That's why you have it in the first place. There's a problem with uh Mary having an issue with Jane. Well, read your resource management plan. That tells you how to manage and

manage conflicts on a project because the resource management plan tells you how to manage resources. Those management plans are there to tell you how to manage your project. So before you actually take an action against something, review your plans and see if

the plans will tell you how to fix your problem. So never act without a plan. See if there's a plan in place for it. Again, that's why in tradition you have this giant plan. I want to point out that in a tradition of project planning is done once. So you make this giant project management plan. You execute the whole project and hopefully you never

need to change it. Agile is a little different. Agile embraces iterative planning where plans are created just in time for each sprint. So remember in agile they do sprint after sprint after sprint. Each

sprint does a certain amount of work. What they do is they plan right before the sprint for just that amount of work. This is done during the sprint planning meeting. Don't forget you can replace the word sprint with word iteration. So it's basically you know people say isn't

a tradition isn't an agile project like a traditional project where chop up the work somewhat yes but not really but I do want to point out that in agile we do have we do do planning for the work that we're about to do in the sprint planned

meeting all right let's see a practice question on this question nine your data migration project is scheduled to begin the database transfer this weekend when you

discover on Friday afternoon that the backup verification process failed and the backup files are corrupted. Oh, that sounds bad guys. The project has already announced the system downtime to users vendors has been scheduled and the migration team is standing by. What

should you do? Okay, so the backup failed. We got a problem here. uh they announce it to the the to the users. What do you mean? So this is obviously the problem. What should you do? Hey, immediately start working on alternative

backup solutions as directed while the IT director develops the evolve strategy. All right. Postpone the migration until a complete backup recovery plan can be developed and tested. All right. Call emergency planning session to develop comprehensive approach for addressing

backup issues before taking any corrective actions. Okay, I like this. I like this. This is not a bad answer immediately. I wouldn't do a You know why? Because a you're working here without a plan. You just start doing things. I don't want to postpone until all until a complete backup. I think

before we do this, I think we may want to, you know, have a good plan in place to fix it. Begin the migration of schedule, but implement additional monitor. I think we should come up with a plan first and address this. This is a major issue. All right. Not having backup files. Something is overwritten.

and you'll never get the data back. So I think the best answer here guys is going to be C, which is you know what, let's create a plan. Remember, don't act without a plan. Let's have that plan in place before we move forward. And now on your exam, they're probably

going to mention something, but management plans. Always make sure you follow those management plans because that's what they're there for. All right, let's go in here to principle 10. Principle 10, consult the team before making decisions. They often have

practical insights and expertise. Don't act alone. So this is both traditional and agile. The best people to make the decisions on a project is your team. The best people to give you estimates, the best people to solve problems, to solve issues are the experts. And by

definition, the team is your experts. So let's work with the team on getting this done. So, always remember if there's a problem on a project, try to meet with your team to solve those problems. Let's take a look at a practice question on this

question. Question 10. You're managing a software development project and need to choose between two technical architecture approaches for the new system. As the PM, you have researched boat options thoroughly and have a clear preference based on your analysis of cost,

timeline, and alignment with business requirements. What should you do? Make the architectural decision based on your research. Present it to the sponsor, then inform the team of decision afterwards to avoid disrupting their current work. Well, this one goes against the principal, doesn't it? The principal says, "Let's work with the

team here." This one here is just you doing it on your exam. Don't do things by yourself. Just don't make decisions. The project manager is there to facilitate everyone so decisions are made, not just to make all the decisions by yourself.

Present both options to the sponsor with your recommendation and let them make the final decisions since they have business authority. Although I do agree that sponsors does have the final authority, I do want to point out that hey, you know what? um we don't want

them we we don't want to just push it upon them and because we did the analysis we feel it's best. I think we're missing the experts here. Delay the decision until the development teams complete the current sprint and

can give the architectural choice their full attention. Okay, not too bad. I don't like this delay thing, but it does involve the team. Consult with the development team about both ar about both architect options before making your final recommendation. I think this is going to be our best answer. We don't want to

delay anything. Now I want to point out that the question did state two technical architectural approaches. A PM is not going to be the subject matter expert on everything that we do. So as the PM you have to research both options. making D here the best answer

because remember it is technical and even though you did the research let's get the team involvement to give us a much much better understanding of this. We just finished 10 of those principles and 10 practice questions. If you're enjoying this video, did you give the

video a like? Did you subscribe to the channel? It helps us out immensely. If you guys don't like the videos and you don't subscribe to the channel, we don't make more content like this as we don't know how relevant it is. So, just takes a second, just a little tap. I know we got to beg, but we got to feed the algorithm its uh its food this morning.

Let's go back to the principles. Okay, next principle. Principle 11. Choose actions that best serve project objective and deliver the highest value to the stakeholders. I mentioned this earlier. We do projects for

stakeholders. We don't do projects for us. We don't do projects for the team member. The by definition the customers are the ones that will gain the benefits of the project. So we should do what's

right for them. Couple scenarios of this would be when the team uh the customer wants a feature but the team is like that feature is too hard. We don't want to do that. That's probably not right. All right. The customer is who we're doing this for. Do

it for what's best for the customer. Do it what's best for the overall project. Right? So then you're going to at that moment the team has got to take a backseat. We got to get it done because the customer is the most important one. If something is going to if you have to make a decision on this exam that satisfy Jane or satisfies the project

objectives Jane being a team member satisifi satisfy your project objectives first. Let's do a practice question on this one. Question 11. your e-commerce platform

project that has three critical issues that needs immediate attention, but you have but you only have resources to address one this week. A security vulnerability that could potentially expose customer data. Okay. A performance issue uh causing slow

checkout times that are reducing sales. All right. And a cosmetic bug that the CEO noticed and specifically acts to be fixed. The development team is waiting for your prioritized decision. Now, in this question, they're specifically

asking you to choose it. So, what do you choose? Well, you only have resources to do one this week. What are we doing? Well, hey, fix the security to prevent potential data breaches and protect customer information even though it hasn't been

exploited yet. I like this one. I'm a security guy. I like that answer. You know why? Because in the long run for the overall objectives if there is a massive security flaw customer data is lost. This can of course have a drastic negative impact on the project and the business

resolve the performance issue. Now since it's actively impacting customer experience and business revenue right now although this is bad this is more shortterm right even though they're going to lose a little bit of money now they're not going to lose their whole business. So I would do A before I do B. Address the cosmetic bug first is the

CEO. Now, even though the CEO is a senior stakeholder, we're not denying it. We'll probably fix it later. But in this one here, this is just a cosmetic bug and it's not going to affect the entire project. Split the team's time. This is not an option because it's literally telling you you can only do one. So, don't go

against the question. If a question says you you only have one guy to do one task, then just do one task. Don't don't tell a guy to work three tasks. So the best answer here guys is to do what's right for the entire project. Not just what's right for salespeople or what's

right for the CEO. This particular thing was right for the entire project. So always try to satisfy what's right for your entire project. Next principle principle 12. Understand the root of conflict before

resolving it. Don't attempt to resolve a conflict without understanding the main cause. In the Penach guide, and this is by the way both agile and traditional in the Penach guide, one of they have this conflict management series of steps. And the first thing is to understand the

conflict. You could never totally solve conflicts or problems unless you really understand what is the main cause of the problem. For example, let's say you have Bob and

Mary having an issue and Bob says we should put this uh application in the cloud. Mary says we should keep it on site and they're going back and forth and back and forth and you you listen to the issue. The main thing you should understand is why do you guys want why

are we fighting over cloud versus onsite? What is the root cause of this? And after Jordan, you came to understand that they are fighting over performance problems. So then the the way to actually fix this problem is to choose the answer that best resolves the

performance issues. Things like this we have to keep in mind. Never solve a problem until you actually understand it. On this exam you're going to get questions where they're going to say what should you do next? And the thing you should do next when it comes to problems is to understand what's causing

that problem. Let's take a look at a question on this. Question 12. During your weekly team meeting, a heated argument breaks out between the lead developer and the QA manager about

testing timelines. The developer insists that QA is being unreasonable by demanding too much time for testing, while the QA manager argues that the developer is rushing the code and creating quality problems. By the way, this seems like a really

common thing. What should you do first? Stop the argument immediately and remind both members about professional behavior and expect expectations and meet it. One of the things we want to do is not to be mean. Part of the mindset, don't be mean. Don't come off as a tyrant.

Hey, you guys need to stop and be professional. Probably not the best answer. Schedule a separate one-on-one meetings with each team member to understand their underlying concern and perspective before attempting resolution. Okay, it's not bad. All right, just trying to get to the cause. Implement a new process that allocates

specific time for development and testing to prevent future. This is no good. In this one, you are not really coming to understand the problem. You're just going out on fixing the problem. D. Facilitate a discussion between both team members to find a compromise on the

testing timeline that works for everyone. Now, this is a good answer. You got two choices. You got B, where your one-on-one meetings with each member, and you got D, you're scheduling discussion between the members to find a compromise on the

test and timeline. I like both answers. But remember, before we solve the problem, we really have to understand what's going to what's the main cause. What's the underlying cause here of these problems before attempting some

kind of resolution? Uh I would do B then I would do D. All right? So let's do B. Let's meet oneonone and then let's do D. Now we understand now we can better facilitate. It's hard to facilitate a discussion between people if you really don't understand what the problem is. So

let's do B then let's do D. Always remember for your exam never ever solve problems without understanding the root cause of those problem. Next principle. Principle 13. When an

issue happens, enter it into the issue log. Check the risk register for responses to issues. Now, what exactly is an issue versus a risk? Let's break this down first in this principle. A risk is something that's positive or

negative that has not happened yet. It has a probability. It it is uncertain if this event will take place. For example, having bad weather during the winter, that's a risk. But if you are in a storm right now and it's a blizzard, well,

that's considered an issue. An issue is something that has happened and is generally negative that's affecting your project. Risk, we'll talk about later on a few more principles down. In this one, I want to concentrate on issues. So, when an issue occurs, I want you right

away to put it in the issue log. We have an issue log for a reason. The moment it happens, put it in the issue log. One thing that confuses students is when I say, "Well, where, you know, where do we find a resolution to the to the issue? Where do we come up with how to solve it?" Check the risk register. That

sounds kind of weird, right? The risk register has a resolution to the issues. Yeah. Here's why. Because before it was an issue, you should have anticipated this issue and documented as a risk. For example, let's say you're going to

build a house during the winter. You know that during the winter there are blizzards that can delay the project. So what you do is you put in your risk register blizzards and you put well stop the project on till the snow is cleared. That's your response. Now you're

building the house and it's January and there's a blizzard that just happened. What you do is you take out the word blizzard, you copy it from the risk register and you put it into the issue log. The response to the blizzard you already thought about, right? The response to this issue that's happening

right now, you already thought about it's to delay a project by a few days. So what do you do? You take the response from the risk register and you put it next to the issue or you start enacting that potent potential response. So I want you guys to remember that before

you come up with resolution to issues, you if one of the choices is like check the risk register for the responses, it's probably going to be the answer. Let's do a practice question on this. Question 13. During a new software

project, a team member newly written code is crashing a few modules that was written a few weeks ago. This will cause this will cause a major delay if not fixed right away and the team member is uncertain of how to fix it. What should the project manager do first? Add this

code to the issue log and assign an owner. Okay, I like that. It's it is an issue. add this risk to the risk register and work with the team to fix it. No, this is not a risk because you notice is crashing a few module that means that this is happening right now.

It's not something that's uncertain or something that's potential that would be a risk. Assign a senior coder to fix it. Well, you shouldn't just come up with a resolution just like that. Let's put it in issue lock first. Discuss a facilitation disc facilitate a

discussion between team members to fix a code in error. I like D. D is not a bad answer, but you know what it wants to what do you do first? Let's do A first and then we'll do D. Make an A the best answer on this particular one. So I want

you guys to remember anytime there is an issue, make sure you put it in that issue log first. Check that risk register. If that's not an answer, right? If adding it to the issue log is not an answer, if A wasn't there, I would have probably then gone with D

because that would have been the first thing to do is discuss it with the team members. But if that's an answer, make sure you select that one first. Next principle when confused, refer to subject matter experts, lesson learned register from past projects or your

organizational process assets. I want to point out uh something here. Project managers are not subject matter experts. All right? That's not who we are. We're not subject matter experts. We are good

facilitators. A good project manager is not an expert programmer. The greatest project managers have great people skills and they can facilitate well. Not somebody that is a massive programmer or somebody that is a super construction engineer or

something. I'm not saying those people can't be good project managers but people's skill is more value. Lesson learned register from from past projects is of course going to be important. Lesson learn registers is what this is something that we document throughout the project. As the project is

progressing we are documenting all of the lesson learned throughout the project and then we give it to all the project managers when the project is done throughout the project. So one of the best ways to learn from or to fix things is just to look back on previous lessons.

Sometimes organizations may have templates or knowledge bases that we can look at. Those would all be considered an OPA. Many organizations have encountered some types of problems like regulatory fixes and so on. So this is a good place to look. The point of this one here is that we are not subject

matter experts and we should always look for help. Let's let's do a question on this. Question 14. You're managing your first healthcare IT project involving HIPPO compliance

requirements when a complex technical issue emerges regarding data encryption standards. You've researched online and found conflicting information about the specific requirements and your team is waiting for guidance with a decision needed by tomorrow. What should you do?

Make the decision. Make the make the best decision you can based on your research and move forward. Adjust and later if needed to show decisive leadership. No, I don't want you to make this decision. It says your

first IT project involving HIPPA. So you've probably never done this. Probably not your best decision. Escalate decision to your sponsor since complex compliance issues are above your authority. Your sponsor is probably not a subject matter expert on this. Let's

not go over this. Call a team brainstorm to collectively research encryption and reach a consensus. Although I like this answer. Let's put on back burner. Let's see what he says. It's not a bad answer. Consult with the company's HIPPA compliance officer. This is better.

Review lesson learns for previous healthcare and check the organizational uh compliance procedures. This is definitely a better answer because this indeed we know we're meeting with the subject matter expert versus a we're not sure if the team is always seek out the

advice of the subject matter expert before moving forward on a project. Never assume you are. That's the point of that principle. Let's take a look at the next principle 15. Always investigate and consult before acting

especially when the questions asks what the PM should do first or next any you should never fix things first you should never act first review your plan meet with people talk to people before doing something first in real life you do this

when something happens you review your plans in your head and review your documents before you actually go out and fix things you're just doing randomly just go start doing random actions Right? You think about the actions before you do them. Never choose to fix an issue without analyzing that issue first. This

something we said, make sure to analyze that issue. Let's see a practice question on this. This going to be a really common one on your on your exam. Question 15. You arrive at work to find an urgent voicemail from a key client stating that they're

extremely disappointed with the latest deliverable and are considered terminating the contract. The client demands an immediate response and the team is asking what's happening as word has spread quickly. What should you do first? So now I like this question

because this question is like forcing you to do it right away, right? It's like hey do this right now. What should you do first? Call the client immediately to apologize for the dis disappointment and assure them that you'll personally resolve whatever the issues they have. In real life, that

might be a decent answer, but personally resolved, I don't like that answer. Review the deliverable that was submitted. Check the acceptance criteria. Gather information about what specifically disappointed the client before pro responded. I like this one here. You're checking, you're reviewing,

you're analyzing. I like this schedule emergency meeting with your sponsor because how to respond to the clients. One of the part of the mindset you'll learn later is never give away your work. Just don't go to the sponsor. Contact your sponsor to inform them of

the client's threat and get guidance on how to proceed. Yeah. Don't ask for help on a project. You should never just go out and ask, especially when something is within your jurisdiction to fix. Ask for help. Okay, I want to point this out clearly. Ask for help on subject

matter stuff like programming, HIPPA compliance. Don't ask for help on project management stuff like managing your stakeholders. That's project management stuff. That's project management task. But when it

comes to like if there's a problem with a regulation, there's a problem with a uh coding error, there's a problem with a building, something like that, go get the right subject matter expert. But in the world of project management here, you're dealing with a stakeholder. This

is your jurisdiction. You got to fix this. So what exactly is the best answer? Well, the best answer here is going to be to review it. Don't take an action against it. Let's review it first. And that's going to be a theme of this exam because this principle is going to apply to many many of those

questions. Next principle, show progress through tangible outputs such as minimum viable products, MVPs or prototypes. As you're progressing through the

project and you're making decisions, right? Customer says they like this, they don't like this. The best thing we can do is give them something to use. Customers have a weird way of saying what they want. When you give them what they want, it's not what they really

want. You see, what's in my head for me to explain what I wanted, what I want, and I tell it to you, there's a little bit that's lost between my explanation to you and how you understand it. The best way to really see if you designed or built what I wanted is to actually

give me something that's usable, tangible, that I can physically use it and actually gain benefit from it. And that's an MVP, right? So an MVP, a minimum viable product is something that we can release into production that you guys can start using and gaining value from. Prototypes are things that you may not be able to use, but you'll be able

to experience it. You're not going to gain much value in terms of making money from it. um it's more like a demo product versus an MVP you can use in production and do your work with. So a prototype is something that you may be able to touch and feel and give good feedback on. In

both of these scenarios, you're actually the customer is actually having hands-on with whatever is it that you're making. Let's do a question on this number 16. Question 16. The mobile app development project is now 50% complete

according to the schedule, but stakeholders are expressing concerns about the project's progress and questioning whether the final product will meet their expectation. The development team has been following agile practices but hasn't yet delivered

any work and functionality that stakeholders can see or test. What should you do to address the stakeholders concern? So, let's redo this. They're expressing concern, right? So, what is the main concern? They're concerned about the progress whether it

will meet their expectations. Well, they haven't seen it yet. Um, you have been following agile but haven't delivered any work in functionality. Maybe this is the problem. All right. What should you do to address these concerns? Create a detailed status report showing percentage completion for each features

and present them to the stakeholders. Completion report. You telling stakeholders things are done doesn't really give them much other than verbal com verbal or written confirmation that something is done.

Organize a demonstration session where the development team can show stakeholders the working components and core core functionality. I like that. Now we can actually show them what we're doing. Schedule a weekly meeting to provide verbal updates on development progress and address their concerns. I

don't like this answer. In fact, I think A is probably better than C in this scenario. In this one, once again, you're just telling them it's updated versus showing them. Reassure stakeholders a project is on track according to the schedule and ask them just to ask them to trust it. The best

thing here we can do is to meet with the stakeholders to show them what was done. I want to point out that on your exam, you will get questions that will deal with the answer being minimum viable products. It's one of the hot topics on

your test. It's in the exam objectives. Make sure you really understand it. It's one of the best ways for customers to give you feedback and to get early value from the products we're delivering on agile projects. Next principle. Principle 17.

Resolve issues at your level. Don't ask your sponsor senior stakeholders for help solving problems on your project. They hire you for that. I added this in here. Remember guys, don't go out, you know, don't go one of one of the popular

choices of the four choices on your test is always to ask your PMO or ask your sponsor for help. Never ask your sponsor for help to solve people problem, vendor problems, basically most problems,

you're not going to actually very rarely that thing is ever the answer. when it is the answer when will you ask your sponsor your senior managers your CEO for help is generally for an approval

escalate only for approvals or authority limits in other words push it up if there's an authority limit that's met in other words you need an approval to get this done to add this to the project that's a point sponsors senior managers

particularly sponsors are just there really to approve things. They're there to say whether they like this or dislike, not to solve problems on a project. It's no question on this one. Question 17.

Your project team has been experiencing low morale due to unclear roles and responsibility and frequent miscommunications between development and testing teams. Team members has been coming to you with complaints about each other. Productivity has declined and you

can see tensions during team meetings. Your sponsor mentions during the latest status meeting that they have heard some concerns about team dynamics. All right, they're complaining. All right, the productivity is declining.

Hey, ask your sponsor to step in and clarify roles and expectations since they have more authority. First of all, don't do this. Managing the team is on you. This is within your authority limits.

Facilitate team meetings to clarify roles, establish communication protocols, and address interpersonal issues as a project manager. I think this is good. I like that. Recruit your sponsor to bring in HR represent to mediate. Once again, you're going outside. You're asking for help here. Escalate to senior leadership. No, this

is problems within the team itself. This is something that you should be fixing. You shouldn't have to give it away to other people. Now I want to point out to you guys here guys you know when it comes to managing when it comes to your exam anything that

manages the team is within your authority problems on the team team fighting with each other that's on you don't escalate that up now speaking about the team let's get into the next set of um principles team leaderships

and collaboration here we get 18 to 27 principles. Got quite a lot here. Let's go into this. And the first principle is principle 18 here guys. What are we talking about? Principle 18. Be a servant leader. This

is the theme of the PMP exam is to be a servant leader. Now, this video is not to go over all the specifics of servant leadership. I want you to take my 35 hour course and watch that there. But being a servant leadership is, you

know, one of the phrases I use is fetch food and water. Being a servant leadership is is about giving the team they need to be successful, providing and supporting them. So when I say fetch food and water is giving them the resources, I mean you could get them

coffee and donuts. That's food and water somewhat. Uh get get them the resources they need and support them. Don't dictate to them. A servant leader is very different than a traditional leader that's more dictative. They are very like do it my way or the highway type.

Servant leadership values the team opinion, lets them work, stays away from them while shielding them from interruptions. Make sure you review servant leadership principles in the course. What are we doing? Once again, we're empowering. We're supporting the three.

We're going to be listening. We're going to be coaching them and encouraging them. We're not dictating to them. Maybe we will value their opinions. Let's do a question on this one. By the way, be a central figure, not a dictator. Said that. Now, I do want to point out something to

you that we mentioned quite a few times is always allow a team to resolve problems. Don't you should never select a an option like if there's a problem on a team and there's like multiple options, work with the team, but you shouldn't be

the one just selecting it. And again, don't be a dictator. All right, practice question here. Question 18. Your development team has been struggling with complex technical challenge for the past week and team

morale is low. You notice that junior developers seem hesitant to speak up during technical discussions and one team member mentions that they feel out of their league with the current requirements. What should you do? Take charge of the technical challenge

yourself by researching solutions and providing specific direction to each team on how they should implement your finding. No good. This is more of being a dictator than it is being a good project manager here. Uh be that being a servant leader because you're dictating everything. You're

fixing it further. Bring in senior consultant to solve the technical problems quickly and show the team the correct approach. This is not good. If you're bringing in something, you're not empowering the team. you're empowering somebody else to tell the team what to do.

Organize peer programming sessions between senior junior developers. Schedule individual coaching sessions to understand each other's concern and celebrate small technical wins along the way. I like this. This is not bad. Peer programming is when you put people together to work

together. One writes the code, one checks the code. You are coaching them individually. It's not a bad answer. reassigned complex or once again you're totally solving it to senior while given simpler task you know C is not the best best answer but is the best here you A B and D

you're taking charge and you're fixing the problem for them and this one here you're more working with the team to solve the issue making that one the best answer now we want to understand that this here is this is going to be a common thing throughout this exam servant leadership can't emphasize this

enough make you know the principles of it. Review the course for that. Principle 19. Act as an integrator, not just a functional lead. You have to integrate all the different components of a project. Understand this. A project

is not just all about the scope or all about the budget, all about the schedule. Finishing something too quick might lead to quality issues. Finishing the entire scope may cause massive overruns. finishing something really cheap can cause components of the scope to be out or comp or the time to just be

compressed for too long. So keep in mind as an integrator you're just not looking at one component of the project you're looking at many components of the project. So keep this in mind as you go through the questions question. Let's take a look at a question on this question 19.

Your enterprise software implementation project involves multiple work streams, data migration, business process redesign, user training, and system configuration. Each team is progressing well individually, but you're noticing

potentials potential integration issues, timeline conflicts, scope misalignments, and missing requirements, dependencies. What should you do first? Hey, focus on the areas that's farthest behind schedule and help

the team catch up before addressing the integration issue. All right, so notice you're focusing on areas that's far behind. All right, convey an integration plan with all works uh all work stream leads to identify start that again.

Convene an integration planning session with all work stream leads to identify dependencies, resolve conflicts, and align timeline across all areas. Okay. Okay, that's not bad because you're looking at all areas working with everybody. Delegate the integration

issue to each functional team and ask them to coordinate directly with each other to resolve conflicts. This is not a good answer in this one. You're pushing it off and telling the team to solve it without you being one of that central figure. A is also not a good answer because you're just concentrating on one thing.

Escalade to the sponsor. Never give away work to the sponsor. We say that I'm just done reading that. The best answer here is going to be to bring everybody together. Work with everybody and prioritize everything instead of one. Remember, don't concentrate on one. Concentrate on

many things because a project is not just a single component. It's many many components. Before I get into this principle, uh, if you guys are enjoying this video, can you give the video a like? Did you subscribe

to the channel yet? I'm going to ask you every 10 principles. It would greatly appreciate it. Does take a lot of work to put this together and my legs are hurting right now. I've been standing up for more than an hour. So, if you don't if if you like the work I'm doing, I would love if you could

give this video a like. By the way, share it in your network. Would be amazing, too. Principle 20. The team is best suited to break down work. Not much more to say here. The team are subject matter experts. They know the work better than all of us. They're the best ones to tell us, for

example, what are the steps to paint in this room. The team ask a painter that your team. They're going to they're better to better equipped and knowledgeable to tell you the steps to paint a room. A painter is the best person to ask to paint a room. what are

the steps than anybody else. So ask them to break down work. Let's do a question on this. Your project has received approval to proceed with the next phase. Developing a new inventory management module. You

have the highle requirements and need to create a detailed work breakdown structure for planning and estimation purposes. But your development team wouldn't be available for detailed planning discussions for another week. What should you do? Wait for the development team to become available and

then have have them create the WBS together even though it will delay the planning process by a week. Create a detailed WBS based on your previous experience with similar modules to keep the project moving forward. Then

review it with the team when they become available. Now, I don't like this option here because you're breaking down work by yourself. Who says you have enough experience to do this, right? All you have is high level. Assign the W. A is not bad here. Wait for the team to

become available. Okay, A is not so bad. Assign the WBS creation to the technical lead since they have both technical expertise and familiar with the current system. Okay, not not too bad. Create a high level WBS based on UX and then then have the team provide detail as uh when

they're available. Very good answers. We got to break it. We got to come down. We got to start eliminating choices here. What are we going to go with guys? So we got assign to a technical lead. We're just giving this away. I think the team would be best just than the

technical lead. So now we e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e either we're going to create a side of a framework on your experience and then have the team provide the detail or we're going to wait for the team. What are we doing? I think the best thing here is let's leave it to the team, right? Let's make sure the team is best. Uh

it's you know what's good for us is not to get involved especially breaking down work. Notice in this one here we're doing the high level framework and then have the team provide detail. But what if our highle framework is wrong? What if we didn't put provide the high level

framework correctly, right? Why don't you have them review it instead of having them just break it down? Okay, have them create the WBS together even though it will delay the planet because the team knows best. Make it a the best answer. Always remember guys, the team

is the subject matter experts, not us. All right, principle 21. The team should should determine the activity timing. So the team determines how to break down the work, but the team

also can tell you how long work should take. The best person to tell you how long to paint a room is the painter. They'll know, they're the best person to tell you that, you know what, 200 foot room like this or 4,000 foot room, this

is how long it takes to paint. So always ask your team for the duration estimates. They're the best ones to give you that. Let's take a look at a practice question on this. You are developing the project schedule

for a website based on your experience with similar projects and discussions with the client. You believe the optical sequence would be design mockups then content creation followed by development and finally testing. What you do regarding the activity sequencing? So

activity sequencing if you remember from the course is part of schedule management. So what should we do first? Should we do the design then content development testing? All right. What would be the best regard to sequence? Identify which of these delayed activities are on a critical path and

would actually impact the end date. Then prioritize those. Seems to me like you're doing the work there. Present your proposed sequence to the team and then ask and provide D time estimates for each phase based on your recommended approach. Okay. All right.

You're going to the team a little bit. Share the project requirements with the team and ask them to determine the sequence and time it. I like this one better. Not giving them the work. Let them do it. All right. You're giving them the work so they can use their expertise. Create the schedule based on your experience but remain flexible to

modify the sequence if the team identifies any technical constraints. I think the best answer here, guys, is of course going to be work with the team to do it. In this one, you're doing all the work. In this one, you're doing half of the work. Uh, in this one, you're doing still some of the work. Let the team do

it. They're the best ones to determine how long work should take. Next principle is going to be understand team motivations to inspire performance. A demotivated team is one of the best

ways to kill your project. A demotivated team is one of the best ways to tank your entire project and go down the gutter. So, you don't want that. We have to consistently on a consistent basis motivate the team. We did cover

different types of motivational theories in the course. Make sure to review them like Maslo's hierarchy of needs, McGregor's theory, XR. Make sure you know those theories for your exam. But on your practice questions, on your scenario questions, on your exam, make sure to keep your team motivated. Let's

do a practice question on this. Your team's your project team's performance has been declining over the past month. You've noticed that Sarah, usually your most productive developer, seems

disengaged and is producing lower quality work, appearing quiet and distract distracted during team meetings. What should you do first before implementing performance measures? All right, so this is not good. All right, Sarah, usually

productive, very disengaged. What are we going to do? Implement the performance measurement improvement measurements immediately since decline in performance affects the entire project and waiting could make things worse. This is just forcing things. Schedule a private conversation

with Sarah. Discuss what's affecting her motivation and and engagement with the project. I like that. Let's talk with her. Assign Sarah to less critical task until her performance improves to minimize project risk while she works through her issues. Help her. First thing to do is just don't reassign. Just

don't fire people like that. Work with them first. Discuss Sarah performance decline with the team. So, this is a problem here with Sarah and you don't want to just go to the team to do it, right? Uh the best answer is of course going to be meet with her. You don't want to just

discuss her. It's her performances. Talk with her. Don't take away her work. We're not sure why she's having this. And just don't ignore her and just keep on going. So, always work with the team there. Team motivation is important not just for your exam, but it's also important in real life.

Not much to say here. Don't lie. Don't cheat. Don't steal. Don't break the law. I want to point out something to you. Part of the mindset, and I'm telling you guys a principle here. Don't stop projects. Never stop a

project unless you're breaking the law. Unless you're committing something illegally. Okay, that's the key here. Ethics stands above everything. Everything. Okay, following the law, for example, stands

above what your company is doing. If you're working on a project and you notice this project will be breaking the law, stop the project. All right? Because the you shouldn't be breaking the law. Always be truthful. Even if that truth means that you're probably

going to be fired, even if the truth means that you're probably going to be kicked off the project or the project is going to have major issues going forward, the test will test you on this. Ethics is a topic on the exam objectives and you will get questions on it. So even though and they're not going to

make this easy because what they're going to do is they're going to give you choices where it seems like well if I stay ethical the whole world is going to end. Well, let the world end and you stay ethical. That's the point of the question to test your ethics. Let's do a practice question on this.

During your software implementation project, you discover that a team member has been inflating their time reports, claiming eight hours of work on days when they're only presenting four to five. This is actually against the law by this stealing from company's time.

This has been going on for about three weeks and your manager hints that major time and your manager hints that major time sheet issues are common. What should you do? So the manager does tell you that this is probably a common thing. I don't know if that's minor or not. I mean that's

about 3 hours they're building for him. What should you do? Address the time sheet issue directly with the team member and establish clear expectations going forward while documenting the issues and corrective actions. Not like this. Okay, you're taking you're taking action against it. Overlook the time she

discrepancies. Team member is technically competent and the project can't afford here. You're letting the ethical problems keep on going. That's the problem here. Quietly discuss the solution with other members to verify the information before taking any

actions. This is a problem with one person. Don't bring it to everyone. Focus on the team member's deliverable quality and productivity rather than time tracking since the results matter more than no there is a ethical problem going on. This person is literally lying on their time sheet and you have to take

it you have to fix this on your project and the best answer here is going to be a it's the best of the four choices. So always stay ethical. Remember something guys your objective in this exam is to be ethical at all times. Again, doesn't mean if the project gets stopped,

doesn't mean if you lose your job or somebody loses a job at the world ends, always be ethical. Next principle, create a safe environment for disagreements. Conflict can be constructive, not just destructive. Most people see conflict as

a destructive thing. And while that is true, conflicts tells me something. Let me tell you guys something. For two people to have an argument, it tells me something interesting about them. They

care about the problem. They care about the issue at hand. I'll give you an example. When me and my wife were remodeling our kitchen and the color of the cabinets,

in the center of the kitchen, she put like this island. She has like this blue island. All right. Now, she came to me and she's like, "Well, we're going to have white cabinets and she's going to have put a blue island." And I'm like, "Okay, sure." Cuz I don't care. But she cares a

lot. Was there any arguments on the color? No, because I really don't care about the color of cabinets. Like, that to me doesn't matter. I don't know why this doesn't m but my daughter and my wife had many discussions on the back

and forths of what was the best color and then the two of them came up and they got this like light blue thing makes it happy. The point of this is when there are disagreements on this

don't look at it as a negative thing. Sometimes the best solutions, the the optimal solutions comes from when people have disagreements between each other because that's when a person that believes this is the right way, another person believes this is not the

right way. This is when they puts their head together and create the best solutions generally for the project or in my project the color of the cabinet. But when you have stakeholders that are disengaged and ah I don't care about that. No, that shows this stakeholder is not particularly engaged in this. This

is not something you want in particular, especially on senior stakeholders. So remember that conflicts, yes, I know, can be disruptive. Your job as a project manager is to create a safe environment. In other words, we want conflict. We want people to care. The problem here is

if you have conflict and you crucify them or you punish people, then they will never have conflict. For example, if you see two team members having a disagreement and you penalize both of them, they will never nobody will ever fight again on your project and there wouldn't be much conflict to come up

with good solutions. So create this safe environment to let them know disagreements are welcome and we want to hear it and we want to manage it. Your objective is to make sure that the conflict stays at level one, level two. In other words, it's very manageable.

Information is flowing freely, everybody understands everybody. Not to level five. And your job is to make sure it never hits level five. You know, level five conflict is when people physically want to kill each other. So, you don't want that. Good one. Highly on your exam. Many questions on it. Let's do a

practice question on this question. During a design review meeting, you notice that whenever the senior architect presents ideas, the junior team members remain silent and simply not in agreement. even when you

can see puzzles expression on their faces. After the meeting, you've heard two junior developers privately express concern about the proposed architecture. All right. What should you do to improve team dynamics? So, they're not speaking up like here like during the meeting here. All right. So, what are we going

to do? Schedule individual meetings with the junior members to gather their technical input privately. Then present their concerns anonymously in future meetings. All right. Establish ground rules for meetings that encourage questions and alternative viewpoints and model constructive disagreements by

respectfully question ideas yourself. I like this because now you're bringing them in. Now you're encouraging questions. In the previous one, you see in a I don't like this because what you're doing in a here is you're keeping it to the back burner again. You're meeting them privately and then you're

doing anonymously. You're not having much disagreements here. Ask the senior architect uh to to be more open to questions and input from junior members during design. Okay, I like that. That's not bad. Rotate the

meeting and leadership. So the junior team members take turns presenting their ideas and leading technical discussion. Now the best answer here is definitely going to be B. It's better than C in which case senior architects are just taking more or just having people rotate. If people are rotating, you're

still not opening up the environment so everybody gets a say in it. They can be the best answer. All right. Next principle here, guys. Protect your team's focus by avoiding

task overload. This is one of those principles where you don't want to overload the team. You don't want to have the team work overtime. You don't want to push the team to do something that's going to make them work overtime. Overtime is unsustainable. Task overload is unsustainable and will

lead to poor quality performance. Never select an option like that. Let's see the questions on this. Your web development project is progressing well when the marketing director approaches you with an urgent request for your lead developer to quickly create a promotional landing

page for an upcoming trade show. Okay. The lead developer is already working at full capacity on critical project features, but you're the only team member, but they're the only team member with specific skill set needed for this. So, you got a team member already doing

work. Okay, what do we do? What should you do? Ask the lead developer to take on promotional landing page since it's only a few hours and could benefit the company significantly. You're making the mark over time here. I wouldn't do this. Negotiate with market to delay the

promotion land until after the current sprint is complete. Okay. Have the lead developer train another member to handle promotional work. If you do this, you're taking away work from them. You're giving them additional work. Discuss a request with lead to understand the

capacity and decline if it would compromise their focus on the primary project responsibilities. So in this particular one here, what you want to do is you want to work with them. So let's combine all the principles. Let's work with them. Um, you don't want to just delay it

until after the current sprint. This is something that you want to just bring it to their attention and say, "Hey, can you do it? If you can't, that's okay. If not, let's move out." Then decline if it would compromise. So, this one here, we're working with a team. We're giving

the team what they want instead of being a dictator and just decide, hey, no, we're not going to just do that off the bat. This is the best answer here because we're not selecting for them. We're letting them choose and we're not task overloading them.

Principle 26, use prior programming for skill development. Now, this is going to be a tricky one in this principle because you you don't have the expertise to train people. You're going to have the team to help train each other. In

the world of extreme uh programming, generally there's this thing called peer programming where one person writes the code while one person checks the code. For that to happen, they must be experts at it. So, we're not talking about peer programming here. I wanted to put wanted

to point that out. We're talking about like a senior training a junior. Uh we're talking about a guy a senior guy that knows one thing training another senior guy that doesn't know that thing. Things of that nature. Let's see the practice question on this. A project

manager is leading a data analytics platform implementation when the team realizes they lack sufficient expertise in the new analytics tools. Three team members have basic knowledge. Two have intermediate skills and one has advanced

expertise. The team needs to develop these skills quickly to maintain project momentum. What should the PM do? Enroll the entire team in formal training course to ensure consistent uh skill levels. Well, do you need to do the whole team? All right.

The team realized that they lack expertise that some have basic, some have intermediate, some has expert skills. All right. Uh since not everybody here, some people so I don't know if I want to put all of them in in the course. Organized peer learning

sessions team members learn teach and learn from each other. Okay. Hire additional members with the required expertise. I don't think I would do this yet because we have people with expertise already. Outsource the analytics components to an external vendor. No, we have some people that are experts at this. I think the

best answer here is going to be be let them work and learn from each other. It's okay to have team members learn from each other and work with each other. Sometimes that's your best principle. Now, I got this pretty cool principle here. And this one is going to eliminate

so many choices for you. So, so many choices for you. I call this the be nice principle on a project. This is eliminating. This is not to select the right answer. These things here, these things here are

all we're going to be using to eliminate choices. For example, don't fire anyone. If one of the choices like remove this guy to this task, hire somebody else, not not an answer, don't make anyone over time. Just said that. Don't put anyone down in front of

others. We just said that. If you have a problem with someone, work with that particular person. If one person is causing issue, don't do anything until you speak with that person. All right? If one person is interrupting a meeting, one person is being mean to another person. All right?

uh don't do anything. Meet with that person. See what the issue is. There's a common question where people this guy's always coming late to the meeting. Always late. What are you doing? When somebody's always late to a meeting, you don't know why. Maybe they were meeting with the CEO. Every day you have

this meeting. Maybe this person has a health problem. Meet with them and understand what that problem is first before taking some kind of action. All right, let's do a practice question on this. Be nice principle. Remember this principle is really to eliminate

options. Question. A project manager notices that one team member consistently arrives late to meetings. Interrupts others during discussion and submits deliverables past agreed deadlines. This behavior is affecting

team morale and project progress. Other members have started making comments about the individual's performance during the meetings and some have approached the project manager requesting action. What should you do first? Address the performance issues with the individual in a private one-on-one conversation. I like this.

All right, let's meet with them. Let's find out what's going on. Discuss the team members during the next team meetings. Now, this is going to be in front of everyone. Document the performance issues and escalate to human resources for disciplinary. Don't give it away. Let's meet with them first.

Reassign the problematic. Don't fire the guy. So, you notice this here is like this principle really eliminates like don't fire people. Don't give away your work. not in front of everybody else. Just work with that person. Make it a the best answer. So remember, I think

that principle is really going to really, really eliminate. It doesn't allow you to select the right option right away, but it eliminates some of those bad choices. Next thing here, guys, we're looking at is going to be

agile specific principles. We got a few of these here to go over. By the way, if you're enjoying this video and you appreciate that my legs are hurting right now to get you to pass your exam, you're going to click on that like button, subscribe to the channel would be absolutely amazing.

Let's get this principle 28. The product owner documents and prioritize features. Only the product owner prioritizes the product backlog. Train them if needed, but don't do it yourself. This is

important. At no point on an agile project. By the way, let me stop right here. How do you know when it's an agile project versus a traditional project? Look for the keywords. If you're working on a project

and you see the keyword like backlog, product owner, sprint, iteration, scrum, scrum master, you know you're working on an agile project. The real issue sometimes is it's when it

says hybrid. Hybrid is a tricky thing because a hybrid project has a project management plan and it has a product backlog. So those you're going to want to read very carefully. Let's go back to this principle. So I want to point out something. At no point should you the project manager add

to the product backlog, remove things from a product backlog or prioritize things in a product backlog. Only the product owner does that. All right, remember that. Only a product owner does that. Now there are going to be times when the product owner does not want to add sometimes the product owner be like

oh you know all of them are uh highly valuable and they don't want to prioritize it or they don't want to this feature I don't know if I should add it or not they have to determine they have to determine if they want to add it or they don't want to add it we got to get a decision it's not something

we or the team should be doing the product the product owner basically owns the product backlog question. Your agile development team is starting the next sprint planning session, but the product owner has been traveling, hasn't had time to properly

document the user stories for the upcoming features. The development team is eager to start working and has already identified several features from the previous discussions that they believe are high priority. What should you do? Allow the development team to start

working on the features that they identify as high priority while the product owner completes the documentation in parallel. Okay. All right. Notice you're letting them work on the features that they identify. So that the team here is doing basically the product owner work. All right.

Probably not the best answer here. Okay. Have the development team create the initial user story documentation based on their understanding. No good. The user stories are called user stories because there should be made by the users not the team. Postpone sprint plan

to the product can probably document or prioritize even if it creates a delay. Okay. All right. Not the best answer. Um not the best answer, but it's okay. Work with a product owner to quickly prioritize the most critical features

and have them document just those stories needed to start the sprint. Okay, we got two decent answer here. Which one sounds best? Well, I would say let's not postpone anything. Can we get the product owner to quickly prioritize?

Can we get some of those things in there to get the sprint going? D and C and D are decent answers, but D is just a better answer. starts the work without delaying the project and it priorit it prioritizes it and it

documents what the team needs to start doing the sprint plan making D the best answer. Don't forget that the product owner owns the product backlog. All right, let's go with a one principle that I just put a whole lot of things into. Is this the way agile team likes to

work? First of all, collocations. What's a collocation? Agile teams love collocation. Collocation is when you bring everybody together in one central place to work. It's different than virtual teams in which case they just work in silos. Agile prefers teams to be

together and work together in person working. There are virtual collocations. The way you would do that is by basically having everybody use things like Zoom, but everybody keeps the cameras and mics on all day long. kind of like each everybody's sitting around

a desk on your exam. Face-to-face communication is the most effective way to communicate anything. Would you guys think this video would be highly effective if you never saw me and all you see was me

talking behind a slider? Do you think it's effective? Because you can see me. I can't see you, but you can at least see my face. You can see my emotions. You can see all my talking with hands stuff. keeping you all engaged. Face-to-f face communication keeps people more engaged. Humans, believe it

or not, like seeing humans, not every human, but most humans. In the course, we did do a chart on this. There are psychologists that said face to face with a whiteboard is the most effective way. Agile teams like wallspace. Remember the term I used in the course?

High-tech, low touch. Let's use sticky notes. Let's use magic markers. Let's use whiteboards for your team. Information radiators. So when you walk into an agile space, you should see automatically what they're working on.

This are going to be things like a burn up and a burndown chart, generally on a big screen or on a big chart somewhere. Uh tell us what's what's left, what they're working on. A good example of this would be like a canband board. I use cananband board. I use scrum band

personally when I do agile projects. and a cambban board if I could just look at a canband board and see hey they finished that still working on that and they have those things to do so it is a great amazing way to track what's the work in

progress what has been done what needs to get done so can board is a good information radiator remember something agile will emphasize visual workflows agile wants consistent uh stakeholder inputs, customer inputs

and the sprint review meetings and they break works up into iterations. So quite a lot of things here with agile. Let's take a look at a question. Your New York's your agile development project has team members distributed

across three different locations in New York City. The team has been working remotely using video calls and collaboration tools. But you've noticed communication delays and coordination challenges affecting sprint velocity. Sprint velocity is how much work they're doing, how fast they're doing work. What should you do to

enhance? Invest in better video conferencing technology and collaboration tool to improve the remote working. Okay. Arrange for team members from different location to travel and work together in the same location for the most critical aspect. I like that. Okay. Okay, you're bringing people using

a collocation. It's going to be face to face. All right. Establish more frequent check-in meetings and structured communication to improve more check-ins, more communication. I think this is going to lead to more problems. Reorganize the work to minimize dependencies between different location. Allow each

site to work in. No, they should work together. You're not bringing them together. You're you're splitting them apart. So, what do we do? Do we invest? Do we go keep going the path of technology or do we go low tech highouch? Let's bring that collocation. Now if you're thinking

isn't this a problem? Well, the question has something very particular in it in that it is in one city. So now if this question was written where it was like they were all over the world, then I I don't think B would be a good answer.

Maybe A would have been a better answer, but because they're in the same city, B is probably a better answer than A. All right, next principle. And principle number 30. Let's take a look at guys. Principle 30.

Uh, did you guys click on that like button yet? Did you guys subscribe to the channel? That would be amazing. Come on, guys. My legs are still hurting. I'm still standing up all morning. If you guys can help me out because of my leg hurting would be absolutely amazing. Principle 30, roll out methodology

changes gradually using pilot or phase implementation. So one of the things you're going to get on your exam that's pretty common is companies that are changing. They're going from like traditional to agile or vice versa or

agile to hybrid or something like that. And do you just do this big bang approach in which case you just push it all on them and let them start working in right away or do we slowly roll it out? Well, in this mindset we're saying don't push it all out. Sometime it

creates a lot of chaos. Let's see what this is about. All right. Question 30. The organization has decided to transition from traditional waterfall project management to agile

methodologies across all development teams. The CTO wants to implement agile practices organizationwide immediately to get benefits as quickly as possible and has scheduled agile training for all teams next month. What should you

recommend for implementing this methodology change? support the CTO plans to implement agile across all teams simultaneously. After the training to ensure consistent adaptation, quick benefits realization. This is going to create chaos. They

haven't really done this. Right after the training, you push the whole thing out. I'm not like I don't like that. Select one to two teams to the initial agile pro gather um lesson learn. Refine the approach then roll out. Okay, I like this. Not bad. All right, that's following principle. Implement agile

only for new projects allowing current projects to finish using traditional then transition all teams once current work is complete maybe see I don't see C has a problem right because you're waiting them and then uh

transition them once the current work is done are you are you gathering lessons are you looking to improve here I'm not sure divide the team into groups and implement agile phases first group starts immediately after training. Second group starts 3 months later. I

think the best thing here is to do the gradual roll out. I think it's best to refine the approach, gather lesson learn versus just pushing it out now and then three months later or just pushing them in the moment their work is done. Let's see and let's refine the process. You

know, I want to point out something to you guys is agile is different in every organization. Even though on our PMP exam uh agile is you know this one is scrum or or it's

extreme programming or it's scandan or something in organizations they they mix it up and a lot of organizations has their own little ways of doing things and so in that sense B would probably be the better answer the next principle agile requires ongoing customer feedback continuous

validation the whole point of using agile is to welcome changes is agile means to be able to change, be able to move quick and fast. We welcome changes on a consistent basis and because of that we welcome customer feedback. At least once

a month customer should be given feedback on what was being made or is made. Don't forget you have the sprint review meeting where the customer gives you feedback on what was done. So on a consistent basis we're getting that and

you should always get this. Agile promotes things like minimum viable products for example. Let's go do a question on this. Your agile team has been developing a mobile app for the past three sprints. The customer was very engaged during the

initial requirements gathering but has been increasingly difficult to reach for feedback sessions. Missed to the last two sprint reviews and saying they're too busy to attend regular meetings. Oh no. What should you do? Insist on insist on regular customer feedback sessions

and adjust the sprint schedule if necessary to accommodate the customer availability even if it slows down development. All right. Continue development based on the original requirements and the customers expressed their trust in the team

and schedule a comprehensive review. Probably not the best answer here. You're just pushing them. You're not getting their feedback. Have the product owner make the customer validation decisions based on their business knowledge to maintain development momentum. Not the best answer. The best people to tell you

whether something is going right or wrong is the people that's going to use it. And that's the point of sprint review meeting. Pause until the customer becomes available for regular feedback since agile cannot function effectively without ongoing customer inputs. Interesting answer. Interested.

uh you know one is pausing the development, one is insisting on regular feedback. You got two good answers here. What are you going to go with? Well, let's not pause development. You don't want to stop a project just like that. Let's see if we can get the feedback.

Even if we need to adjust some of those schedule, it's better than pausing the entire thing. So in this one, you're adjusting the sprint schedule. In this one, you're pausing development completely. Which one is better? Let's adjust the schedule or let's pause the thing. And I think a is going to be the best answer on this one. So we always

want to make sure that we gather those customer feedback. All right guys, let's take a look here at the next set of principles. What do we got here? We got quality and delivery coming up right now. We got uh quality is a is a major major player of customer

satisfaction. Poor quality leads to poor customer satisfaction. Good quality, higher customer satisfaction. So let's see if you could do this right. Principle 32. Define quality requirements early and

check them often. This is on a traditional project. All right? And on an agile project. Agile also uses this concept of uh the definition of done. So quality requirements, I want to define

quality requirements versus scope requirements. Quality requirements is paint this wall white. Scope requirements is going to be I said that wrong. Scope requirements paint the wall white. Quality requirements are things that's going to make the customer

not present, is going to be unhappy. For example, you know, one of the the quality requirements would be even painted walls. You don't want to come to one side as darker than the other side. You don't want to paint over the guy's light switch. Those would be like

quality requirements, right? You want to make sure that you have nice even painted walls if you're building this phone. So, I just got a brand new phone. I'm filming this video. I got this phone a couple days ago. Here is the uh the Samsung uh I want to show you guys what's on my

screen here, but this is a here's the Samsung Fold 7. Now, this phone has a it's a brand new style of phone. There's flip phones and you can actually see that we have a notch here, right, for when the phone flips. Quality requirements for a

device like this versus scope requirements. Scope requirements would be of course that the screen functions, it checks emails, it does everything a smartphone supposed to do. But what would make me upset? Quality requirements would be like this crease is too big and you can really feel it. You really can't, by the way. You really can't see it when looking at it. Quality

requirements should be how fast it functions, right? So if I try to put my thumb print and it takes too long to log me in, the I would say this is a bad phone. So one of the quality requirements would be to make sure that it has good performance. So remember something quality requirements really

leads to customer dissatisfaction. Score requirements is really what they want. So we need to document this and in the traditional projects those 49 processes we have something called collect requirements. In that process is where you document your quality

requirements and you store them in the requirements documentation and then you document how you will reach them in the process of plan quality management. It's in the quality management plan that you will document how you how you plan to meet the quality requirements on traditional projects on an agile

projects. We will meet with the customers and we're going to document the quality requirements and how it should function how it should look how it should act when it's done by the definition of done. For example, when the product is finished making by the

agile team they're going to say how do we know it's finished? Right? How do we know we've actually met and produced a high quality product? Well, that's what the definition of done. All right, lots of lots of things I said there. Let's see the practice question on this.

Your team is starting development on a new e-commerce platform. During the initial planning meeting, stakeholders have focused heavily on functional requirements, but have provided minimal guidance on quality standards. respond respondent that we'll figure

that out as we go and just make it work well. Uh that's probably not good. Uh remember you notice the questionnaire they're focused on functional requirements minimum guidance on quality standards. That's not good. What should you do before development begins?

Proceed with the proceed with development using industry standard quality practices since the team has experience and stakeholders trust their judgment. Okay. Begin development of core features while scheduling quality requirements discussions for later sprints when

stakeholders can see work and software and provide more feedback. Research similar e-commerce platforms to identify typical quality standards used for those default requirements until the stakeholders provide guidance. I don't love this one. I'm eliminating

this one. I like the others. Not I don't really like them very well, but they're better than C. Facilitate discussions, facilitate sessions with stakeholders to define quality requirements, performance, stability, usability, reli. Yes, this is best. You know why? Because I want to

point out something to you that I didn't mention is that quality is user specific. Quality is is very subjective. What I find that's quality, you don't find quality. So, we want to work with them. And you really shouldn't start it until you really know the quality here. So

definitely D is better than A and B. In other words, A and B are waiting until the work starts to start doing this. So that would be the best answer. Don't forget guys, quality is important. If you do it wrong, you're going to have bad customers and have to rework the

entire project. Next principle. In traditional projects, customers should validate deliverables for scope and quality. Yes. You see in the 49 processes we learned that there's a process called control quality. In that process the customers and you or at

least you go through the deliverable to see if the deliverable has met the quality requirements. That's how you get the verified deliverable. In the process of validate scope you would go through the deliverables with the sponsor or the customer to get a verified a validated

deliver or I'm sorry accepted deliverable. The accepted deliverable means it has met the scope requirement. Now agile customer checks the quality and scope during the sprint review meetings. This is why you have them at

the end of every sprint. Show them what what you built. Have them touch it, feel it, use it, manipulate it. That's a sprint review meeting. And hopefully I mentioned earlier agile likes these MVPs, these minimum viable products.

Agile says those are the greatest thing in the world to have. When you have an MVP, the customer can use it. They can gain value from it. They can make money from it. It's actually something that's going to be installed on their computer, for example, and they're going to tell you what they like and what they don't

like. So, MVPs are great things to use. Let's take a look the practice question on this. Your team has completed the first major deliverable for your web application project. a fully functional user authentication

system. The system meets all technical specifications and passes all automated tests. But the customers been traveling wouldn't be able to validate for validation until the next phase until the end of the next phase. What should you do? Delay the authentication system to production. Deploy the authentication

to production since it meets all technical requirements and has passed internal quality checks. Then get customer afterwards. Okay. All right. I don't know about that one. and you disregard the customer. Continue with the development phase while waiting for

a customer's validation since the technical team is confident the deliverable meets requirements. All right. All right. Wait for the customer to return and validate before proceeding with the deployment or the next phase. Okay. Okay. I kind of like that. All right. I don't know about this

one here. I don't want to just push it out here like that. Present the authentication system to a customer representative or proxy who can uh preliminary validate until the customer is ready. Okay. All right. So, we got a couple of decent answer here. Which one did you go with? All right. Do you want

to continue the next phase while waiting? All right. Uh should we do that? Nah. I think we're going to come down to either C or D here. And the problem is notice wouldn't until the next phase. So this is going

to cause a massive delay. The best thing we need to do we need to gain some kind of validation not just from our internal system but from at least from a customer or a proxy. So proxy people who can choose on behalf of. So this is a better answer than just waiting uh and delaying

it until the next phase. The point is to make sure you get validation before moving forward. All right. You know, we want to I want to mention this in uh agile projects. When you are looking at quality on agile

projects when you're working with teams, I did mention this earlier. You want to use inclusive tools like whiteboards rather than complex software. Always go low tech, hight touch. It's interesting how they built the Empire State Building in the 1930s in

under two years and and we can't even build a user interface on a piece of software to all our high-tech machinery in two years. Interesting, right? Maybe we need to go back to this more low tech and high touch. And I know I know there's a bunch of AI stuff out there. Maybe we can go back to low tech,

high touch and get work done be faster and better. Let's never on your exam choose options that breaks the team apart. There is this thing called silo work which case people work by themsel. You don't want that.

You want people to work together not separate from each other. All right, let's take a look at a question on this. Your cross functional team needs to brainstorm solutions for a complex

integration challenge that affects multiple system components. The team includes developers, business analysts, subject matter experts, and stakeholders with varying technical backgrounds who all need to contribute ideas and understand the proposed solutions.

What should you do to facilitate effective collaboration? All right. So, you notice we got developers, we got analysts, we got subject matter experts, we got a lot of people working here. You want good collaboration. What are we going to do? Schedule a series of detailed technical

meetings where experts could present comprehensive solutions using advanced modeling software. Yeah, this this you have a lot of people here, man. You have BAS, you have subject matter experts, you have developers, you even have stakeholders. They all have different backgrounds. I don't think people with

different technical backgrounds is going to understand advanced modeling. So digital collaboration where team members can contribute ideas asynchronously through structured templates and voting mechanisms. It's not bad but it's still very technical right because it's a digital

platform on it. Create a shared online workspace. Real time editing capabilities. All stakeholders can contribute. Okay, it's not a bad answer. It's shared online workspace. Not too bad. Let's see what the other one is. Organize a workshop where everyone can sketch ideas, sketch

ideas on a whiteboard. Yeah, definitely the best answer if you're following this principle because all of these are tech tech. This is low tech making high touch. Making that the best answer. Humans like, believe it or not, I know you guys have a hard time believing this, but humans like being with other

humans. I know you don't. Or sometimes I don't like being with certain humans, but I like being with certain humans. Like I like being with my children. They're humans. Actually, now I like being my dog. The Anyhow, that's another story. All right, let's take a look at the next principle.

35 traditional. This principle says use bottomup estim estimating for more accurate results. When you are coming up with an estimate of time and their cost, there are variety of traditional estimates. You

got top down or analogous estimation which is quick but not very accurate. You have parametric. You have expert judgment. The best estimate you can use is bottomup estimation. Bottomup estimation is when you break down work into it details and then aggregate it

up. For example, this room is 200 square foot. If I say, "How long will it take to paint the wall?" You're going to say, "Well, 200 square foot times 10 minutes is 2,000 2,000 minutes." But is it really really?

Well, this wall has a whole bunch of foam on it. This particular wall in front of me because that's where all the sound protection is in. This wall also has a bunch of foam protection on it. And this one has a door on it. So, these two walls you don't need to paint. This one has a door. So, realistically, that

wall zero time. this wall uh let's say 25 minutes, this wall 25 minutes and this wall 50 minutes. This is bottom up. So now you add up 50 50 you add it and you start to add up the

walls individually. So you break down the work to the small then aggregate it up. Now you have a perfect estimate. Bottomup estimation does require you to know the work in detail and it does require a lot of work. So it's takes long to do but it's

very accurate. When it comes to agile estimation, they use relative estimation techniques like story points and planning poker. In the agile course, I don't want to get too much in depth because it's a big discussion. But in the agile course, I

reviewed with you guys the Fibonacci sequence, in which case they use the Fibonacci numbers. Uh I can't remember it right now. 1 3 I forgot. plus one now one two then it's three then it's five

then it's eight something like this right I can't remember it all right now but you guys check out the Fibonacci sequence I do cover that in the course that's what they use they assign these things every user story is given a certain number then those numbers are added up to form the entire points of

the product backlog the product backlog let's say I got 10 stories each is worth 50 points it be 500 500 points to complete this entire project. If you're doing uh 50 points an iteration, then it' be 10 iteration, be 10 months to do it.

That's how they do this. How do they determine how much work they can do? By doing the team velocity. Hopefully, everything I said there made sense. If not, you need to review the course again because this you will be tested on during the class, during the exam.

And of course, here in this video, question 35. Your team needs to provide time estimates for developing a new customer portal with several integrated modules. The project sponsor is asking for accurate estimates to support budget

planning and resource allocations decisions. What estimation approach should you use? Use your experience from a similar portal project and applying scaling factors since historical data provides reliable baseline estimates and

is much faster than detailed breakdown. I don't think you should be doing this because this is considered more of a top down where you're just pulling from historical data. Have technical leads provide highle estimates for each module based on your expertise since they understand the technical complexity. Okay, not too bad. You are bringing in

other people but it's high level. Get detailed task level estimates from developers who will perform the work. Then aggregate those to create the overall project timeline. This is better because in this one you're breaking out the work. Combine approaches by using historical data for the initial

estimates than having tech than having technical leads validated. So this one here you're pulling it from historical data. The best answer here is going to be to have those estimates uh come from the team members themselves. C best answer. So

remember guys, the best form of estimations are always top down. The next part of this here guys is we're going to be doing is going to be the risks and procurement section of this. We do have a few principles I want to mention that comes to risk. Let's take a

look at it here. And this is going to be principle 36. Now, oops, push yourself a little bit. All right, here we go. When it comes to risk, let's just say everything in life has risks. Pembach

defines risk. An uncertain event. Number one, risk is uncertain. An uncertain event that affects one or more project objectives. Risk affects your project. How does it affect your project? Well, there's what's called positive risk

called opportunities. These are risks that can reduce the schedule, reduce your budget, increase functionality. Negative risks are risks that can push up the schedule, go over your budget, reduce

functionality, like a bad snow, like getting a bad snowstorm or a permit coming really late, delaying your project. Positive risk is where team members are extremely come to find out extremely knowledgeable in this can finish the work quicker.

Positive risk can be the permit coming six weeks earlier. So we want to make sure we understand that. Now we want to document risk early and thoroughly. We want to do this throughout the project. Risk is not something that's done just once. You want to do it early because

you never want risk to derail you. A good project manager is able to predict the risk and respond to these risks. Question. You started a new cloud migration project for your organization's legacy system. The sponsor is eager to begin

the migration work immediately and has expressed concerns that spending too much time on planning activities might delay the benefits realization. What should you do first now?

Conduct a comprehensive risk identification session. Before beginning any migration work, document the potential technical issues and organizational risk. Okay. All right. Begin the migration with less critical first to gain experience and identify risk. Well, I don't want to

start the work right away. That's probably not the best answer. Start the technical migration. Again, you're starting it without knowing your risk. You shouldn't do the work if you don't know the risk. Focus on technical risk only. that uh since those are the

impact the cloud no I think here you want to do your risk assessment they want to do it but you you can't start the work until you actually know the risk because if you don't know the risk that's going to affect your project you might end up in a situation where something happens and you don't know how

to respond and the whole thing gets completely delayed and thrown off. If you identify risk that you can put in safeguards to even stop those risks from happen them before they start. Remember something everything in life has risks. Now next principle

is document responses for both threats and opportunities. I mentioned earlier opportunities are the positive risks. Threats are the negative risks. The risk registers stores both negative and positive risk. So I'm telling you guys here the risk register is where you

store the risk the listing of the risk and the responses. The risk management plan doesn't have risks. So if they give you a question and they say there's an uncertain risk and one of the choices to

update the risk management plan risk. Wrong. You don't do that because the risk management plan doesn't have risk. The risk management plan tells you how to manage risk, but it doesn't actually have risk in it. So, you don't you want to make sure that you understand that concept.

Let's do a question on this. Your software development project is progressing well when you receive unexpected news. A major competitor has just announced they're discontinuing their similar product, creating a

significant market opportunity. So this is a positive risk. Additionally, a key technology event has offered you early access to the new API that can enhance your product capabilities beyond the original scope. Oh, good. What should you do first? Quickly modify the scope

to incorporate the enhanced API and accelerate the market positioning. I don't think you should take an action right away without really assessing it. See what's going on here. Schedule emergency meeting to discuss how to pivot the market project strategy to capture the maximum benefits. Okay.

Okay. Not too bad. Document these efforts in your risk register and develop uh specific responses. Okay. I like this. Begin. No, you shouldn't implement right away. Don't take an action right away. Now, it comes down to two things. Should we document it in a

risk register? It is an opportunity. Or should we go talk with the stakeholders? Well, here's what I'm going to do. I'm going to do C first and then I'm going to do B. But it's asking what do you do first? I can see the best answer here. So remember something about risk.

Uh risk is something that is you know I want to go back to a principle here. I want to go back to this uh principle when you're doing risk identifying documents early and thoroughly. I should I want to add in here. Let's add in another point.

And you want to do this all throughout the project. All right, you identify risk. Let's add this in right on the fly on the video. Risk is identified continuously. This is why I see I don't write man.

Best handwriting the world here guys. Remember something about risk. I want to mention that risk is consistently evolving. Risk is consistently getting better, getting worse. Remember risk at a certain level today will change tomorrow. Getting the flu in the

winter time is higher than getting the flu in the summertime. So risk evolves continuously. So you're always continuously identifying and assessing risk throughout the life cycle of your project. At any moment new risk can arise and old risk can go away. So your risk register is a living document that

keeps on moving. All right. Uh question and principle 38 question principle 38 let's go on to vendor management use mutually beneficial contracts and procurement.

Now this is important in the course we covered different types of contracts time material cost reimburseable and fixedric contracts. The key though your exam is not really going to say hey you know what's the definition of that contract. It's a scenario based exam.

What you want to do is you want to identify when to use one over the other. And you have to remember something. Time material, use it when you don't know your scope and the scope is very high level. Cost reimburseable, use it when you want to balance the risk between you

and a vendor. Fixed price contracts when you know your scope really well and you don't want to manage risk. But I want to bring up this point here that when when you're negotiating a contract, you want a contract that satisfies you and your vendor. Don't do

lopsided contracts, in which case it's all for you and forget the vendor. So this is more of an ethical thing, in which case we're going to be trying to be fair on every side. 38.

You're negotiating a contract with a software development vendor for a critical project component. Your procurement team has drafted a contract that includes steep penalties for any delays. Requires the vendors to accept unlimited

liabilities for any issue. That provides limited payment milestones. What should you recommend? Oh boy. I would not like to work with this company. It's what I would say if I was a vendor. Proceed with the contract as drafted since it maximizes protection for your

organization and the vendors already agreed to the terms and if I just want to keep doing that. Modify the contract creat more balanced risk sharing reasonable terms and incentives that benefits both parties. I like it.

Add additional penalty clause to ensure vendors performance while maintaining the current favorable terms for your organization. I like that. It's not bad. All right. You want to I like that because if you hate your vendor, you would like that even more. So, let's go.

All right. So, if I'm working with a vendor I really hate, I'm probably going to add more things on there. But obviously, that's against the mindset, guys. It's not go see. Accept the terms, but add bonus. This is just adding a little icing on top of your terrible contract. The best thing here to do is to be is to work with everyone.

All right? You have to be fair in what you're doing. All right, I got two more principle here guys. Um on uh two principles that deals with life cycle and closures. Let's get into it. 39. Update the lesson learn register throughout the project. Yes,

the lesson learn register. The four of the 49 processes you have something called manage project knowledge. Lesson learn register is also in your agile project. In agile they have the retrospectives where they do this. But remember something, you don't

update lesson learn once at the end of this the phase or the project. You do lesson learn. You update your lesson learn throughout the entire project. You learn something now, put lesson on register. You learn something tomorrow, put in the lesson learn register.

Now, oops, I missed something there. Here we go. Uh, lesson learning lesson on register. We just said that created in the project in the process manage project knowledge. All right, we did actually say that. All right. Question 39. Your agile development

project is halfway through when your team discovers that the initial API integration approach isn't working requiring a complete technical pivot that cost two weeks but ultimately led to a much better solution. It's lesson learned right there guys. Additionally

learned that conducting user train at every three sprints instead of every sprint actually provides better feedback quality. More lesson learned. What should you do to recording these discoveries? Wait until the project retrospective at the end to document all the lessons learned comprehensively and

ensuring you capture the complete picture of what worked and didn't. Document these lessons learn immediately. Sline register so they can benefit the current and future projects even if it takes time from the current sprint work. Share these insights uh informally

with other project teams through casual conversation and team meetings. No, got to put in lesson on register. Focus on completing the current deliver first then schedule dedicated time after the release. Not after the release. This can take a long time. So we're going to do this retrospective. Let's do it immediately.

I do want to point out that the agile projects also have lesson learn and it shouldn't take that much time away but it's where learning things put it in the put it in the lesson learn register and then you can refer back to them in the retrospective making that best answer.

Now I want to talk about when it comes to closing your project in number 40. Did you guys uh click on that like button? You know my legs are really hurting now. Now my hips hurt. Can you guys relieve some of that pain by clicking on the like button, subscribe

to the channel? If you already clicked, don't click it again though. Principle 40. All projects should be formally closed, whether completed successfully, terminator or terminated early, ensuring all bills are paid, and resources released. Now, I want to talk about closing this project here.

On this exam, you're probably going to get a question. I'm pretty sure you're going to get a question where a project is unexpectedly terminated. What do I mean by that? You're working on a project, you're halfway done, the CEO in the middle of

the night decides, "We don't want to do that anymore. Kill that project." Calls you up the next morning, kill the project. We don't want to do that. What do you do? And then he's like, "Go work on this project." And then you're like, you just leave this project and just go work on the next one. No. Every project

needs to be formally shut down. This includes when the CEO calls and says, "Okay, we got to terminate that project." Be like, "Okay, I need to do this, this, and this. I need to make sure I need to release the team members. I need to pay all the bills. A project cannot close. If there are bills that

needs to be paid, maybe you got contracts and vendors that need to be paid. You need to formally release team members and tell them where to go. Did it go back to operations? Did it go work on a new project? Um and you need to document what was done, what wasn't done in the project

report. Remember this a document output of closed project or phase. So you have to formally close down all projects. Now I do anticipate you guys getting a question like this on your test.

Question 40. Your mobile app development project has been cancelled due to strategic changes in the organization. The executive team wants to immediately reassign all project resources to a new

priority in incentive that starts next week, instructing you to wrap things up quickly since there are no deliverable to complete. H notice they won't immediately reassign all the resources. Uh, what should you do?

Immediately transition the team to the new as requested. Handling the administrator cleanup yourself over the next few weeks. I don't know. Request additional time to properly close out contracts, equipments, organize and conduct the final uh final final financial

reconciliation. Okay. Assign one member to handle the closure while moving the rest of the team. One person. I'm not sure. document the project status and outstanding items and then hand over closure to the operation. So notice you're handing over the work. You're handing over the work. You're just

terminating it. The best answer here is going to be to formally close out that project. Making that the best answer. You must formally close out your projects at all time, guys. You never want to you never want to just go on and do the project just like that. Formally close

it out. All right, let's take a look here, guys. And the next section we got is continuous improvement. Now continuous improvement is something that we should be doing on a consistent basis with our projects. Something that we're going to work on quite a lot.

Uh if you don't continuously improve, you will become obsolete. You guys are continuously improving, right? You're taking your PMP. Let's take a look at this principle. Repeat and reinforce the vision to the team. Important.

As you're working on a project and you're a team member, your head is stuck in the screen, right? The screen. So, I have a screen right here. Screen of coding. All you're watching is code. You tend to forget the long-term aspects of where this project is going. You're

forgetting that this project supposed to do this or supposed to accomplish this and so on. That's the problem here. What we want to do is we want to always as a good project manager, we want to consistently work with the team to let them know what this vision is. Let them

know what this project is about. Let them know what the what they're trying to work on. Sometimes when you're digging up the road and you're you're just a worker digging up the road, fixing a hole, you kind of forget that the whole idea is to make sure it's nice smooth paves with pipes fixed at the bottom. So it's a good project manager.

We are going to work with them for the to reinforce that project vision. Let's take a look at a question here. Your e-commerce platform project is three months into development when you notice the team has become highly

focused on technical implementation detail and sprint deliverables. And this is common. This is what I was mentioning earlier. They become so ingrained in the work they kind of forget the whole picture. team member seems to have lost sight of the bigger picture. Creating a seamless customer experience that will

revolutionize how users interact with the company's products. What should you do? Continue letting the team focus on technical excellence since they're making good progress on deliverables and the vision will become clear once they see the fi finished

product. [Music] You're not doing anything here. Don't do nothing. It's part of if one of the choices like just keep doing what you're doing is probably not the answer. Bring in the product owner to realign the team with business requirements and ensure

techn is something that you need to do. Don't bring in other people to help you sponsor a product owner. Create a detailed user story to explicitly connect each technical task to specific customer. You shouldn't be writing user stories. Schedule a regular session. Discuss and reinforce how the technical

work connects to the overall vision. Yes, let's work with the team. Let's bring let's always show them that vision. Let's continuously uh keep preaching the vision so they know where they are. I know I know this

sounds a little crazy, but it is very easy to forget the long-term effort of what you're doing when you're ingrained in the work. When you're working on a project, it is important to clarify what success and failure look like. It is critical that

you know that success looks like this, failure looks like this. In agile, we do this thing called remember the future. In which case, you work with the customer to say remember the future. Now, this sounds crazy. What is remember

the future? Well, it's an exercise you do when you ask your um customer what would a successful deployment of this software look like? what a successful user interface of this and they tell you well it functions like this it had this

feature it did this it produced this number it had this report now you're they're telling you what success looks like so we want to consistently do this we want to clarify the team should really understand and we're going to do this with things like user stories uh remember the future like I told you

about but then you also got to ask what would cause this thing to completely fail they might tell you well it failed a function like this it uh it was too slow. It produced these errors. Now you

know what to look for. So on a project we want to consistently do that. All right, let's take a look at a practice question here. Your team is working on a customer service automation project with the goal of improving customer satisfaction.

However, during a recent discussion, you realize that different stakeholders have different interpretations. The VP of customer service expects a 20% reduction in support tickets. The IT director assumes success means deploying the system on time within budget. What

should you do to address this? Work with all stakeholders to define specific measurable criteria for project success and failures. Ensuring everyone has the same understanding what constitute the goals. Yes, I like this. You're working with everybody. You're getting what success and what failure looks like. I

like that. Continue high level goals since stakeholder agreement on broad term is more important. Don't do this one here. You're not doing anything. Focus on delivering the technical solutions as specified. Since stakeholders satisfaction with the deliverable will

naturally indicate whether the project succeeds. All right. All right. Uh and this one here you're focusing on one thing. All right. I don't like that. I think A is better. document the different stakeholders expectation and plan to address them through multiple success criteria to satisfy. So we got

two good we got A and D. We're just going to document them and plan to address them through multiple or let's all bring them together and let's come up with what success and failure looks like they can aid the best answer. This is something that's important to consistently do. It's really important

to understand what success looks like and what failure looks like. Quick one principle in agile the retrospectives are used to review

and improve future sprints or iterations. Same thing sprint iteration. The retrospectives are done at the end of the agile projects to understand what we did right during the sprint, what we did wrong during the sprint, what should

we do more of in the next sprint and what should we do less of. It's where we look back on where we spent too long on meetings. Maybe we spent too long collaborating here. Maybe we were using the wrong techniques here. Agile teams are always

looking to do continuous improvement. And one of the best ways to do that is in a retrospective. So remember, it's done at the end of every sprint. We're going to document what we should do more of, what we should do less of, what we should improve upon, what doesn't need to be improved upon, and so on. So

remember, retrospective, you cover this in depth. Make sure you understand. Question. Your agile development team has just completed their third sprint and delivered all committed features successfully. Team velocity is

consistent, stakeholders are happy with deliverables, and there are no major blockers or conflict. Some team members suggest skipping the retrospective this time since everything went well since they prefer to use the time of a plan in the next sprint. Now, this is

something you don't do. So, skip the retrospective since the sprint was successful. Use the time for more detail. Something you should be doing, not something you should be skipping. Conduct a brief 15-minute retrospective just to check if there are any issues.

Then move on to sprint planning. Okay. Hold the full as planned. Focus on what was successful in the sprint. Identify opportunities for even better performance. I like that more. Replace with a celebration of successful. No, no, don't replace it. Let's do the full

thing. Stick to the retrospective. The retrospective is where we're going to use to improve upon. Even if the team feels there's nothing to improve, that is incorrect. We can always get better at what we're doing, no matter how great we're doing it. Let the team know that and proceed with the full retrospective

principle. Next principle, implement feedback loop. Apply lessons from one task to the next. So feedback loop is when you're doing something and a customer or team member tells you, hey, that's great. um then take whatever

you did great and then apply it to the next thing. Do it like that again or make it better. Or the customer says, "Hey, that isn't good." Then don't do that again, right? Or fix it because it's not good. Use feedback loops. So feedback loops when I tell you something, you apply that and I tell you something again, you apply that again.

So it's a loop keeps on going and going. This is expected throughout your entire project. So it's something you always want to implement. All right, let's take a look here. Question 44. Your team has just completed the first

module of a multi-module software system. During development, they discovered that the initial technical approach caused integration challenges. The testing strategy missed some edge cases and stakeholder reviews would have been more effective earlier

in the process. What should you do before starting the second module? Analyze the lessons from the first module and adjust the technical approach, test and strategy and review process for the second module before

development begins. Okay, I like that. Begin mod development of the second module as planned while document lessons from the first to future reference. I don't like this for future should be using it right now. Continue with the current approach since the team gained valuable from the first. No, implement

what you learned. Schedule a detailed postmodern review of the first to be conducted after the second. You should implement that right away. The moment you see something is wrong. You and you get feedback. Don't wait till the next phase. Don't wait till the next

uh deliverable. Don't wait till the next sprint. If you get if you find a way to fix something right now, fix it right now. Just don't push it off. Right? That's something you want to do. Okay. Principles 45 and 46. We're looking at

cost and schedule management. Two quick principles. Principle 45. Avoid cost and time overruns if if you must choose to fix budget issues before scheduling. This is a

wider principle. Obviously, you don't want time and cost overruns, but if you got to choose one, if you must choose, fix the budget first. People are more worried about money than time. It should be the

opposite. But go with me on this. If you get a question, and I want to show you a question like this. If you get a question like this, stick with the time. All right? And this is on a traditional project. By the way, I'm sorry, stick with fixing the budget first. This is on a traditional project. on an agile project.

Agile projects has what's called time box. Each sprint has a fixed duration of about two to six weeks uh and is determined by the team capacity. So the team determines how much work they're going to do in each sprint. All right? And they adjust the scope within each iteration. What does

that mean? Well, remember the scope on an agile project is consistently changing. So that's something you want to keep in mind. So how do we work with um time and cost overrun on an agile project? Well, first

of all, agile has a fixed budget and a fixed schedule. So they will generally adjust the scope within each iteration. Sometimes they adjust the scope on the project to keep the budget and time the same because they have fixed duration.

If you remember the beginning of when I taught agile, I said about flipping a triangle. In traditional projects, you're trying to keep the scope the same while adjusting cost and time. Ideally, you're adjusting more time than cost. In agile, you're adjusting the scope to

keep the actual budget and schedule the same. Let's do a question on this. Your project is facing both budget pressure and time constraints. Due to unexpected technical complexity, you're projecting a 15% budget overrun on a

three-week schedule delay. What approach should you prioritize? Focus on reducing scope and features to meet the original project to meet the original timeline accepting the budget overruns as necessary. Cost of

maintaining the schedule commitment. All right. Notice focus on reducing scope and features. All right. uh negotiate additional funding to cover the budget overrun while accepting the 3-week schedule as a trade-off. Implement cost reduction measures to fit

first to address the budget overrun. Then work on schedule compression. All right. Seek a balance approach that partially addresses both issues. Accept them smaller overruns in budget and schedule rather than fully res fully resolving either. So this is a tricky

question. You notice it's asking what you going to prioritize. You got to choose one. Should have reduced the scope. One of the things especially this is not an agile project. Doesn't state it. It seems like it's a traditional. So what are we going to do? Negotiate for extra money. Are we going to cost do

cost reduction measures? Going to seek a balance here. The best answer here like I point out is to put in that cost reduction measure in there. Let's reduce uh the cost and then try to fix the schedule around it.

When it comes to traditional projects, you want to understand when managing the schedule, we have something called a critical path. I don't want to get into critical path on this because this it's a very long topic. Understand for your exam that a critical path is the longest

dur is the longest path through your schedule or through your network diagram. It determines the length of your project. It carries the highest risk activities. Any manipulation of activities on the critical path will result in the project extending or

decreasing. So if you want to compress your schedule, compress the critical path activities that will shrink the schedule. If you're if activities on a critical path are it has no slack, right? Has no float. If activities on a critical path are extended, the whole

project gets pushed out. Remember these concepts for your exam. Agile manages schedule two sprint commitments and velocity. So once again, let's go through this. On an agile project, how do you determine the schedule? Well, if the product backlog

is 600 points and the team does 100 points per iteration, the velocity is how much points they do per per iteration. Then you know you have six iterations in this. If each iteration is four weeks, it's a four uh it's a

six-mon project. So that's how you would do this. All right. Now, don't forget they also work on the highest priority. So the way their work is scheduled is based on the highest priority work to the lowest priority work. Very different than traditional project where you're just doing all the work in one big shot and

you're not breaking it up. Let's do a question on this. Your project has encountered several issues simultaneously. The UI design is running two weeks behind schedule. Database optimization delayed by one week. Security review has slipped by

three and integration testing four days behind. What should you focus on first when assessing the schedule impact? Identify which of these delay activities are on a critical path and will actually implement the project end date. Then

prioritize those. Okay, I like that. Address the UI design since it affects user experience and stakeholder satisfaction. Okay, I like this all because you're trying to fix the schedule here. Focus on security review since has the longest

delay and security issues could prevent project deployment. Work on all delays simultaneously. This require too much resource since they all behind schedule. I think the best answer here if you want to fix your schedule is you want to focus on a critical path.

You focus on a critical path. If you fix the critical path or you reduce the critical path, the whole schedule compresses. So remember that concept for your exam. Coming down to the last of it, I just got a few more principles I just want to quickly go over with you. There's going

to be some quick principles. I probably mentioned a few of these, but I wanted to just to put them in here so you can see them again. Uh, by the way, have you enjoyed this video so far? We're coming down to the end. Look, look how long it is. See, I don't really know how long it is because I'm just recording it up, but

uh it's it's pretty long, right? So, if you guys enjoy the work I'm doing, give the video a like. Share this video with others. Would be amazing. All right, let's go over this. I want to point out a couple exam strategies when you're doing your exam.

This principle here is not going to apply in every single scenario or every single question, but most 90% of the questions. A couple things I want you guys to know. When you see answers that are absolute, like always or all, they're not probably

correct. Like always implement this, always work with this, always fire this guy. Those are probably not going to be the answer. Project management is never absolute. The answer, you know, what's best is dependent on the scenario. And

you're not going to do this thing all the time. So keep that in mind. All right. It's not something that's always okay and stop. Answer this question without

looking at the answers. I'm sorry, without reading the question. Answer this one. So look, I'm not going to read it. This one says always all never. I'm going with C. It might or might not be the answer. I don't know. But I'm going to go with C. Let's see if this works.

Your project team is debating the best approach for stakeholder communication during a system implementation. Different team members have varying opinions about communications, frequency, methods, and content based on their experience with different types of stakeholders. What statement presents

the best approach for stakeholder communication. Always communicate status regularly to all stakeholders uh to maintain transparency and keep everyone engaged. Not every stakeholders needs to be communicated regularly. CEO

probably not. Probably just wants to know you start and when you're done. All project decisions should be made collaboratively. Not not necessarily not all the time with stakeholders input to ensure you're never going to get every stakeholder to agree on your project. So no tailor communication frequency based

on stakeholder specific needs. Yeah, we did talk about this. The communication should be tailored to the stakeholder. Never make significant changes without first conducting thorough you should you should not make any changes without assessing those changes making see the

right answer. Now once again that principle is to eliminate choices. The moment you see something says all never uh something that is always the right answer. Now, speaking about never, let

me put never in another term. Never do nothing. It's easy as that. What do I mean by that? Well, never on your exam, choose a choice that doesn't change something, that doesn't take some

kind of action. If you're going to choose, if there is a choice that says continue doing what you're doing, in other words, you're doing nothing, don't select that. So, never do nothing. All right? If a if you read the choice and you're like,

"Well, they ain't doing anything. They just continue doing what they're doing right now." That is not the answer. Let's see what I mean in the question. Don't read, don't read the question. Let's see if you can just go through the answers. Continue with the current development.

Focus on completing all the features. Wait to address the API. Contact the vendor to understand the issue. Which one did you go? Choose one answer. All right. And let's read the question. See if you got it right. Choose one answer. So continue with the current.

Focus on completing all their things. Wait to address it or contact the vendor to understand the issue. H. Which one did you go with? I know what I went with. Let's see if you got it right because I know what I went with. All right. Obviously, I can see the answers right here. off. Uh your development

team has reported that a third-party API the integrated with has been experiencing immediate slowdowns over the past week. The API vendor hasn't acknowledged any issues and the slowdown haven't caused hasn't caused complete

failure yet. Just long uh just longer response times that my user might notice. What should you do? Okay, so we had a problem with a with a vendor here. They haven't they haven't acknowledged any issues and the slowdown haven't you know caused complete fail. What should

you do? Continue with the current development. Well, no, because you know it might cause an issue coming up later. Focus on clean all the features and revisit if it becomes an issue you should fix. Be proactive. Don't be just reactive. Wait to address it until the

sprint planet. If you're waiting, it might collapse. So, I know I got D. Did you get D when you read it? So I would say contact the vendor. Let's fix this. Let's be proactive on it. There was something here. A, B, and C never really did anything with it, but they just let

it kept progressing. They let kept pushing it off, which is not the best answer. So always you want to be proactive, right? You don't want to uh you know, you always you you want to be proactive. You don't want to just

leave things. All right. Here's the one that I like. I've told my students this a hundred times. If you watch the video, the 200 ultra hard questions, I don't know how many times. I got to tell you guys one thing. The perfect answer isn't always listed. You must choose from the choices available.

Sometimes you get a question and all the choices kind of suck. Uh by the way, 49 and 50 are very similar. They kind of suck. Your your objective is just to go with the closest to right, not the right one. You're not looking for the absolute right. Go the

closest. Cuz if I say, "What's the color of this wall? Is it cream? Is it blue? Is it green or black?" Well, you know, you got to choose one. It's a white wall. Yeah, I know. But you don't got that option. Cream is the closest I got. So,

hopefully that made sense. Let's see a question on this. Your project team discovers a significant security vulnerability in the application two days before the schedule production deployment. The vulnerability affects user data encryption and could potentially expose

sensitive data. What should you do? Deploy the application as schedule and plan to fix in the next release cycle. Deploy the deployment. Delay the deployment by one week to implement a security fix that eliminate vulnerability. Okay. Launch the v launch the vulnerability but implement

additional measures to detect any potential breaches quickly. Deploy to a limited user groups to first test the security risk and controlled before full release. All these answers kind of like suck. One is delay it. The

other one is just push it out and deal with it. I think the best answer here though, even though it's not a good answer, they all these answers kind of suck. You should never push out anything with a security vulnerability as pushing something out with a security vulnerability can cause massive data

breaches uh and can bankrupt an entire business. So the best thing here is to don't push it out. Even though delay in the project is not what you want, it's probably one of the uh better answer. Okay,

I want to something very similar. All right, and I just wanted to do it again. Technically 49 and 50 is the same thing, but I want to emphasize this. All right. These mindset principles are not meant

to be done in stone. I said something earlier. Don't fire your team members. I said that, right? But you might have to follow that principle

when it's the only good option. You see, sometimes there is no correct answer. And sometimes going again the mindset all the things I taught you might just be the right answer because everything else really sucks man choose the best of the four it's not

about selecting it's about selecting the best of the four I can't emphasize this enough I want to give you more one more example listen what are the mindset principle is to never defy the team member but what if the team member is breaking the law and is doing something against the law like stealing company data you might have to

terminate him okay because That's an ethics thing. Now you're saying, "Well, that one is easy because that was ethics." Let me give you an example. What if you're managing a project and you found a team member is having arguments with other team member

and causing trouble. Now, this is an extreme example. I'm just trying to prove a point. What should you do? Number one, fire the guy. Number two, beat the hell out of him. Physically beat him up. Number three,

have your sponsor beat this person up. Number four, blow up the world. What do you do? Well, everything here is really bad and everything really goes against the mindset. Well, the other the last three are

unethical, obviously, beating people up and the first one is fire the guy. Go with the least sucky one. The objective on your exam guys is not to get all the right select the right choices. Select the best of the four. I

go over a lot with this with students when they do my coaching program or they we're doing questions together on Tuesday nights. And I and I'm like they're like Andrew B isn't correct. And I'm like well is A C and D correct? No.

But so B is just tiny bit better than A C and D. B is the right answer. The objective is to pass the test. All right, that's your main. You go into that exam room, pass the test, guys. Best of the four. Let's do a practice question on this and then we finish this up. Your team is debating where

implement the new feature requested by a stakeholder. The feature would enhance user experience but require additional development time. The sponsor supports it, but the timeline is already tight. Development team is split on its value. What should you do? Implement the feature since it enhances user experience and have sponsor support

accepting the timeline impact as necessary. Decline the feature to protect the timeline original scope uh explaining the trade-off to stakeholders. Negotiate a compromise by implemented a simplified version feature that requires less development on add

the feature to the backlog to the next project's phase acknowledging its value while maintaining the current scope and timeline commitments. And this question is where I leave off because the answer, okay,

is probably not the one you were going to go with. All right, the best thing here you can do is to try to come up with something that you feel is best. And this is a question that I know a lot of you guys are going to put in the comments. Hey, Andrew, I went with A and I think you're wrong. Or I went with B

and I think you're wrong. I went with D and I think you're wrong. I went with C and you're right. I know. I know you you guys going to you did in my 200 question video. Probably going to do it here, too. Here's what I'm trying to tell you guys. I'm not going to justify this answer. Not everything has the right solution.

And I'm not going to go into justifying this answer because I've gone through all the the mindsets with you. Choose the best answer. Now, I'm going to go and just tell you that the best thing I can come up with here is negotiate. Now, I did write this question in a way that is convoluted and

difficult, and I want people to get this one wrong. It's very difficult when we I was looking at this question and I was like okay let's make it even harder implement the feature. I don't think you should just implement features like that. It has a sponsor support. I think we want to again notice they support it

but the timeline is tight. We're going to have to push something off. I don't think we just push it off decline it. I don't think you should ever decline things. I think we should work with them to get it out. So I think DB was definitely wrong. Add it into the next phase. Although I like this thing. If it brings value, maybe we could push it out now and just adding it in. That's the

best thing I can come up with. This is the 50 principles that you guys have. If you want access to the PDF with all of these questions, and by the way, if you're watching this in my course, if you have access to my Udemi course, if you have access uh to

the course on the TI exams, this 35 hour course, you already have access. I'm going to give you this PDF if you want it. you already have it in there here on YouTube. You know, you could make your uh it's hard to put documents here. All right. So, if you want this PDF with all these principles, check your course. You already have it in your course. I know

most of you guys are my students already. So, check the course uh in there. Check the um it's going to be attached to this video on it. All right. Hopefully you guys enjoyed this. This was a video a lot of people has been asking me to make. I finally make

it. So, now you guys have it. Please subscribe to the channel. implement these things on your mindset. Let me know in the description if this mindset was helpful. Let me know if you pass your exam with it. And guys, once again, did you subscribe? Did you click on that like button? Don't click it again if you

did. Guys, I wish you guys the absolute best in passing your exam. And I'll see you in the next video.