110 PMP Drag & Drop Questions and Answers

hi everyone welcome to this set of 110 drag and drop questions and answers for your PMP exam this set of questions is taken from the pumbo guide seventh edition the process groups practice guide and the agile practice guide to get a really wide range of project scenarios and problem solving that we can go through and match up the order and processes of things in our project management process and project management definitions you'll probably see between two and 10 Dragon drop questions on the actual exam but the power of this session is to just really get

up to speed and review of all these definitions before taking the real thing and I'll make this download available in my course on udemy which is currently the highest rated PMP udemy course it's just wonderful and it would be great to have you there if that's the sort of thing that you're into let's get into the first question and the first one we're looking at is estimating if the team uses something similar to estim like data from a similar project uh it's similar and it's an analogy so we're using analogous estimating with our team if

a builder uses measurement to uses a measurement to estimate like $55 a meter or $100 an hour they are using a parameter so it's parametric estimating and that can be extremely useful if we've got some data around that like $55 a meter for example the team adds together the smallest pieces in the work breakdown structure so they've got all of their work packages and they add all of those together to get the overall estimate that is our bottom up estimating and if a team takes the average of the optimistic most likely and pessimistic estimates that

is an average of three points so it's our threo estimating now let's quickly check those and see how we went and there we go in the pbook guide seventh edition from 2021 page 178 under estimating if you want to check that out for yourself how did you guys go with that very first one let's get into the next one project tools okay the team need to see their project activities visually on a calendar that is our Gant chart that's where we're seeing our project activities on a nice bar chart uh the business analyst needs to

show how customer requirements meet their completed deliverables that's our requirements traceability Matrix we're tracing the requirements through to their completed deliverables on a matrix an agile Team all right agile is a good keyword there wants to show the planned trend of work versus the actual trend of work that's going to be our burndown chart and you've seen this before I hope you've got the planned trend of work and the and what actually happens and that's our burnd down chart it's burning down all the way there and the last one a project manager wants to see

the number of items completed every day that's going to be the throughput of our items so our throughput chart let's quickly check there we go fantastic how did you guys go with that one PBX 7th edition uh under visual data and information on page 188 to 190 fantastic stuff all right let's see what we've got next okay a few calculations wow this is going to be fun oh and here's a few tricks that I can tell you we've got the uh the schedule performance index and the cost performance index so if you've got an index

we use divide and if if we've got the variance we use minus so this is actually very easy and here's another trick if it's the cost uh index or the cost variance we always use the actual cost in our calculation so this should be quite easy earned value divided by actual cost divided by it's an index and actual cost it's the cost performance index earned value divided by planned value divided by it's a plan it's a an index and planned value it's the schedule so that's perfect now actual cost cost variance here we go and

if we minus the planned value it's going to be our schedule variance that's a wonderful way to know those uh that variance analysis and those calculations there we are that went well and that's in a process groups practice guide under page 311 earned value calculations summary table if you want to check that out for yourself pretty cool all right earned value management oh more earned value management but this looks like some scenarios so the project sponsor approves the total planned budget total planned budget is our BAC or budget at completion the project manager needs to

see how much work should have been completed how much we had planned to have been completed at this point in time the team shows how much has actually been completed how much we have earned what we have earned through our hard work being project managers and with our project team and that leaves our last one the project sponsor needs to know what we have actually spent that's a wonderful tip there that is our actual cost let's have a quick check and see if we got those right we did how did you go pretty straightforward but

again these are the things that we really need to know and these definitions are going to be very handy for our exam from the process groups practice guide earned value analysis wonderful stuff all right let's go to the next one and a typical Sprint in agile wow this is good okay what's the order of a typical Sprint this is very handy to know and the first thing we start is we plan our Sprint and once we've planned our Sprint and we kick off our Sprint I think it looks like daily standups are going to be

next we have our daily standup move blockers report on what we've completed and what we're going to complete uh the next day or during the day uh and then during the Sprint we also do backlog refinement so we prepare more user stories for our upcoming Sprint so that we don't have no work to do coming up now these two we always end the Sprint with a retrospective guys so very important to know and that leaves the Sprint review second to last where we showcase the work to our project customer and they say hey that is

exactly what I was looking for or no it's not what I was uh thinking because now they can actually see it and here we go that works perfectly you did an amazing job agile practice guide under common agile practices perfect stuff all right halfway through this little session here and the next one is agile ceremonies oh so what do we actually do and we've already had some Clues so a team update user stories with acceptance criteria that sounds like our uh backlog refinement where we're updating those user stories we're refining the backlog making sure user

stories are ready uh the team reflect on their process and their Lessons Learned that's our retrospective so we're improving our process for the next iteration or the next Sprint always trying to get better the team agree on user stories to complete in the Sprint that's our Sprint planning and I hope you are beating me to these as we're going along I think you can do it the last two oh the team demonstrate that usable increment that's nice and easy that's our Sprint review that means the team updating on what they worked yesterday what they will

do today and raising any blockers that's going to be our daily standup let's have a quick check of that and it's come from the agile practice guide common agile practices on page 50 if you want to check that out wonderful stuff that's our typical Sprint really getting through these ones so doing a great job okay position descriptions who does what in a project team and we've got a few different ones here Emily prioritizes the product backlog who does that can you tell me that is the product owner absolutely they uh look at customer value and

they prioritize all of those items so we're delivering the highest value first ideally Liam approves the Project funding and resources based on the project Charter that's going to be our project sponsor so they uh they usually hold the resour resources and funding and once we get that approved we have access to that resources and funding as the project manager let's do that project manager next is it the servant leader or is it who's in charge of project planning and monitoring I think it is that one scrum Master is our servant leader who removes blockers for

the project team let's have a quick check of this and that has come through excellent work process groups a practice guide under definitions and we've got some sponsor scrum master project manager definitions in there which is really really great all right let's check out the next one process group uh inputs tools and techniques and outputs or EOS as they call them determining the budget okay oh and these look like all cost management things okay oh this is actually quite tricky estimate costs well we know that we're going to need the basis of our estimates in

estimating costs and planning cost management that's where we create our cost management plan our process for how we're going to work with cost now determining the budget when we have our budget we have our cost Baseline exactly it that leaves controlling our cost we're going to need some cost forecasts to control our cost let's have a quick check and there it is under the process groups Plan cost Management on page page 99 there so nice and easy last two in this little section and we've got program and portfolios if James is hired for a temporary

Endeavor to deliver a change or business value what does that describe that is our project delivering business value and it's only temporary remember it's not ongoing it's not operations that's the difference and Alex has a range of related projects managed as a group together that one is our program program of related projects and so if Rachel owns a collection of project groups and operational work as well to achieve an overall strategic objective that's going to be our portfolio it covers everything projects programs plus a little bit of operational work all together to help achieve that

strategic objective let's quickly check and there it is process groups of practice guide page nine the relationship among portfolio programs and projects very handy to know and also very handy to know the last one in this little section ni and easy the types of project management officers or pmos this pmo provides a consultative role to projects and supplies templates and best practices that one is the weakest pmo it's a supportive pmo the pmo requires compliance through adoption of methods or Frameworks okay now these two are quite tricky because I remember that the top one is

directing it's a directive uh pmo so they're the ones who assign project managers directly and that comes from the pmo and it reports to the pmo that's directive and controlling they control through methods or Frameworks so that's how we're going to put that one let's do a brief check of that and it's come through I hope that has been fantastic for you as well page 48 on the process groups practice guide types of pmos and this is just the first 10 I hope you've had a wonderful time I truly believe that by by practicing this

every day you can pass your PMP exam and these are the definitions and information and scenarios that you truly need to know in your project management career as well as to help you pass the exam and gain your PMP I know you can do it I definitely believe in you let's get into the next set of questions our business organizational Matrix do you remember this from the PM guide or looking at that so let's start from the top resource availability is high so we have a high access resources the project manager project budget is managed

by the project manager so our next one is moderate too high for resource availability the total one is pmo so pmo is all always at the top that's the most uh that's the strongest Matrix so the next one is going to be just a normal strong Matrix organizational Matrix that's where we still have quite a lot of control but uh it resource availability is only moderate to high now we get into the weak matric which is basically when things are managed by the function or the the receiving manager or you might be doing a process

Improvement within your team for example resource availability is low budget is managed by the functional manager now I think the lowest one that we have here is organic so remember this in between we've got all the different matrices uh Matrix strong Matrix weak that's managed by the functional manager and then right at the bottom we've got the budget being managed by the owner owner or the operator instead of the pmo let's quickly check this and see how we go wonderful stuff that's come through process groups of practice guide on page 46 if you want to

check that out for yourself a bit of a tricky one to start off with but let's see what else we have leadership styles excellent okay and we're definitely going to see some stuff around leadership and conflict on the exam the project manager takes a hands-off approach and allows the team to make their own decisions that's as a fair leadership if they focus on others growth learning development autonomy and well-being do you know this one that's our servant leader we're helping the team grow we're leading by serving the team inspirational motivation now these can be tricky

uh but inspirational is transformational leadership and the reason why I select that is because at the very end here charismatic that matches up with high energy self-confident and they hold strong convictions that is the definition of charismatic leader let's quickly check and thank goodness we got those correct practice guide the process groups practice guide page 61 under leadership styles if you want to check that out oh okay precedence diagramming method ah this is good all right so start to start finish to start do you remember all these ones but do we remember what they mean

and here's a trick for figuring these out actually the the second one cannot start before the first one has started and here the second one cannot finish before the first one has finished so it's in it's in order the second one can't finish before the first one can't finished or has finished so knowing that let's do this should be pretty easy let's have a look the next activity cannot start so we got two starts here until the previous activity has finished so finish to start the next activity cannot start until the previous activity has started

that's our start to start the next activity cannot finish until the previous activity has finished that's finish to finish and the next activity cannot finish until the previous activity has started now isn't that easy Once you know that little trick I think that's fantastic let's double check and thank goodness we got that correct the process groups practice guide 2023 page 284 under precedence diagramming method very very handy to know all right team motivation oh oh I love this stuff now this is this is my favorite stuff actually let's see what we've got the project work

is expanding to fit the time allotted to it that one is our Parkinson's law where work expands to fit the time a lotted to it the team Waits until the last minute does that sound familiar maybe when we were at school and we were finishing a project and we didn't do it until the night before that's our student syndrome uh the functional manager they motivate people with things like money bonuses and power these things are external to us so it's extrinsic motivation your team finds motivation in the work itself through a strong sense of purpose

it's internal so it's intrinsic motivation and lastly there is not a smooth transition between tasks or team members they're transitioning but they are dropping the Baton just like in a baton race like you see at the Olympics let's double check and make sure we are correct and things are going very very well check page 96 in the process groups practice guide under motivation of Staff if you want to look at that wonderful wonderful stuff okay oh hey and this one's also a really good one so Myers Briggs you'll probably see a Myers Briggs question on

the exam uh but it's more around team personality assessments so we just want to sometimes adjust our approach to match the personality of the people that we're dealing with and that's that shows that we have emotional intelligence so it's part of emotional intelligence now this is uh not too hard once you know this it's not too hard so if we're drawing energy from solitary activities we are introverted we're doing them ourselves but if we draw energy from social interaction and external activities we're extroverted so we're outgoing but if we prefer focusing on cont concrete facts

details and present realities we are using our senses because we're sensing those current facts and realities but if we have patterns possibilities and all sorts of ideas we are using our in inition out there now if we make logical analysis and lots of thinking we're doing lots of analysis that is our thinking or t if James makes decisions based on personal values they're feeling those values emotions and everything else uh that's what they're feeling and lastly if you prefer flexible adaptable or a spontaneous approach you can perceive lots of different approaches lots of different things

and lastly if you've got an organized or planned or structured approach to life you are judging uh your way forward so using you're like a judge very straightforward and planned and organized and all of that to say let's hope we got that correct and there we are and you can find that at Myers Briggs on Wikipedia you can see that there very very easy nice way to see all of those different Myers Briggs personality profiles okay all right and more organizational management wow this is good okay so lots of leadership this is going to be

fun the team's needs are met from the bottom to the top from safety to belonging to self-actualization if you know that one that is our Herz oh no that is maso's hierarchy of needs there it is couldn't quite find it the team takes pride in their work and sees setbacks as a positive challenge this is where we've got McGregor's Theory X and Y now H now which one was which gosh this might actually trip me up I think the Y is when we see it as a positive Challenge and the x is when we when

the team is lazy and avoids work and we have to take a more Hands-On authoritarian management style so we start off not as good and we get to better so XY Z it goes in order we're getting better over time I'm going to go with that anyway hsb's theory of motivation that's when we have hygiene factors such as job security and fairness of salary and then we have motivational factors such as uh being belonging and work that really means something to us so fingers crossed let's make sure and have a look and yes thank goodness

we got that one correct so remember that McGregor's Theory X and Y that's under motivational models on page 158 in the pumbo guide 7th edition and we're getting through this bunch of questions nearly there oh I love this one tuckman's ladder one of my favorites now can you remember remember the order of this one it's when we come together as a team and the order is it's a beautiful rhyme forming actually let's just do this as we go forming storming because we're coming together and we're having a little bit of conflict as we uh as

we figure everything out then we become norming we get to a normal way of work and once we work through all of our conflicts we start to get through performing where we work together really well as a team and at the end of our project we adjourn so we finish and leave and we are adjourning in the project and that's the one there page 166 tuckman's lad in the pbot guide 7th edition wonderful wonderful stuff all right who does what on a project if Michael elicits requirements with the customer and monitors business value he is

a business analyst but if Penny oversees and coordinates m multiple projects do you remember this one this is our program manager incidentally program managers get a 30% pay rise according to PMI and their salary report so uh check out that video if you haven't already very very interesting stuff and PMP holders also have a 30% higher increase in Pay than non- PMP holders which is pretty cool now if you're a manager responsible for a particular area of the organization you're responsible for that function functional manager and if you're responsible for the day-to-day workings of the

company those are the operations of the company so you're an operational manager and we got those right fantastic stuff page 324 and Page 338 under definitions in the process groups practice guide let's get right into the next one second last one in this little section and these look absolutely fantastic some scope issues here oh I love these okay the approved version of a scope statement the work breakdown structure and its Associated WBS dictionary that is our scope Baseline and we might even have some work packages listed in there as well going above and beyond in

the scope when it's not required that is gold plating where adding gold to the just to the plate it's not really actually made of gold we're just gold plating it it's uh we didn't have to do it uncontrolled increase in scope let's say our stakeholders are requesting extra features now the scope is creeping out of control a description of the project and the project scope and major deliverables that's going to be our scope statement that's usually just a it can be just a a sentence really describing what the project is going to do sometimes a

high level features list as well and lastly the launch date is pushed out because our stakeholder kept adding features that's going to be done drift and let's check this out let's hope we are correct looking absolutely fantastic PB guide 7eventh edition if you want to check this out for yourself page 83 under managing requirements you'll probably find a lot of this uh under scope in the process groups practice guide as well last one in this little section you guys have done an amazing job agile Frameworks oh now you're definitely going to get something around agile

Frameworks and we get some funny ones out here they're not all just under the banner of agile some of these Frameworks are very different uh but they all do very much the same thing so that's a clue for us now the organization applies scrum ways of working to programs and portfolios so scrum that is a tip for us large scale scrum they do it only when necessary in fact they recommend that you don't use scaling method uh because it's sort of anti- agile actually for small teams we want for agile the company focuses on organizing

project teams around value streams now if you remember or if you've had some good instruction value streams come from the Toyota production system or lean and safe or the scaled agile framework uh has actually taken that idea of value streams and so we organize our projects around value streams it's how the how an item is delivered from customer order to customer delivery and then all of the work that happens in between a small team uses a framework that emphasizes iterative development real customer involvement and shared code that's our extreme programming we always share the code

in extreme programming anyone can touch any part of the code at any time uh so that everyone learns and that's a nice way to do it that leaves us with dsdm or dynamic systems delivery method now the thing with this one is it always has that constraint driven approach if you remember our constraint triangle with our scope our cost and actually let's make this one the schedule because these two items down here are fixed that's constraint driven delivery let's just double check and see if we've got this correct and we have and that's agile practice

guide page 111 under scaling Frameworks and you've done another little section of 20 Dragon drop questions on your way to passing the PMP exam wonderful practice you're doing an amazing job it takes dedication and hard work to pass the PMP but I know you can do it and you're definitely doing the right thing keep going I believe in you let's get into the next set of questions and this first one looks like Change Control process all right how do we do change control on a project what's the first thing we do the stakeholder now remember

any stakeholder can raise a change so they're going to raise a change request EST and then we need to analyze the impact of the change is it is the change going to impact anything else like our scope our schedule our cost or the go live date any of these things uh then we need to submit the change for approval and that uh those approvers are in our change management plan most likely it's going to be our CCB or our change control board so that's also outlined in our change management plan so we can come up

with that at the beginning when we're planning our project then we're going to communicate the outcome to the stakeholders so was it approved was it denied or was it deferred and then at the end record the outcome and close that item and in the change log so it's all closed off let's quickly check there we go under PMI we can go to change management process for a project directly from PMI so that's a wonderful way and a bit of a tricky one to kick off that's our Change Control process all right oh now another process

risk management process great now what's the first thing we do here we're going to need to identify the risks that's our first thing then we're going to do things like add the data to the risks first it's qualitative data do you remember what that is that is the impact of the risk and the likelihood of the risk and we put those two things together and that gives us how um how bad the risk is or how urgent the risk is then we can add extra data like quantitative data that's Financial or Big simulations Lots of

quantitative data now lastly we want to implement the risk responses of course and then before that we're going to note the risk owners and the responses to our risk so do we mitigate the risk are we transferring the risk let's check these out seems like we got it correct and that's wonderful stuff page 113 under plan risk management in the process groups practice guide really really great to check out all right what have we got next oh wow I feel like we've got some hard ones in this session actually schedule and resources the project manager

adjusts activities within their free and total float when resources are unavailable so we're smoothing them out or there's a few different ones that's resource smoothing and resource leveling but if it's within their free and total float then it's a smooth ride so it's going to be resource smoothing because we have float available or wiggle room available in our schedule wow tricky some activities on the critical path they're currently in sequence but they can be done in parallel that's fast tracking so we're bringing them back in line uh basically instead of in sequence now we're going

to be doing a few at the same time nice and easy and schedule crashing let's see what we've got here the project sponsor approves extra funding when we're throwing money and resources to uh expedite the delivery of our activities and then like we said before leveling out uh is when resources have been overallocated to the to the same time frame we need to level them out or level out the activities so let's make sure and check that we've got these all correct okay thank goodness those were pretty tricky under resource optimization page 291 under process

groups a practice guide how did you go with that one pretty essential to know those things agile roles now this should be a little bit easier the scrum Master is who have we got a servant leader that facilitates ceremonies and removes blockers for the team the project team are the people who do the work ah yes they perform the work and they create value and or also known as developers in a scrum team but basically the team uh because it doesn't have to be development work it could be knowledge work or research work or analysis

representing the customer oh who is that they prioritize features in the product backlog that's our product owner and lastly a stakeholder is anyone affected or perceived to be affected by the project let's quickly check and that's come through excellent work agile practice guide under page 40 agile roles if you want to check that out for yourself all right what do we got next next okay oh goodness there's a lot here the triple constraint do you remember the triple constraint now in adaptive projects it's one way and in uh in predictive projects it's another way so

if we remember this we variable in an agile project is always scope and on a on a predictive project scope is fixed so we want that to be fixed and then everything else becomes variable so cost becomes variable on a predictive project time becomes variable uh our schedule and quality could be fixed or variable so we can actually choose there how much uh we want to fix the quality and whether we can let that slip or not to to fix some of the other items or to help along our scope cost or time so for

agile let's have a look cost is fixed because we've got a fixed team and it's a fixed team for a fixed amount of time and here we are our fixed amount of time and we just deliver our scope until the time and the money run out and quality can also be fixed or variable but ideally in an agile team quality is everyone's responsibility from requirements to design to development to ultimately to release so let's quickly check here it is absolutely fantastic that was quite an involved one the triple constraint wonderful stuff and oh it's tuckman's

ladder my absolute favorite forming remember forming storming norming performing and adjourning so what's our first one the team know each other's rols and find a regular rhythm that's just a normal way of work the project finishes and the team moves on to other things they're adjourning team members come together but they're still independent and individual they are for forming a new team the team comes to rely on each other and they have high trust and when you have high trust you can get things done faster and uh better basically they are performing that's the best

Stage to be in and lastly uh but not lastly in this in the actual process of things but just as a description storming is when conflicts arise in the team and different personalities are trying to figure their way and where they fit and what their roles are and so we're storming through through those items let's quickly check and there it is tuckman's Ladder page 166 uh pbot guide 7th edition wonderful stuff guys absolutely excellent process groups and edos remember our inputs tools and techniques and outputs from the process guide process groups practice guide let's see

what we've got and hang on a minute we've got four answers here in five answers and four options so okay a little bit tricky and you will see these that's the way it is on the real exam also team charter is for our resources so when we're planning resources probably under planning Resource Management there's two resource ones here actually let's have a look we we'll put that aside just for now we can change it if we need to let's try an easier one planning Communications management we're going to use our communication Styles assessment just figuring

out how our stakeholders want to be communicated to and what information they need very very important uh planning quality management we're going to do quality assurance test and inspection planning to make sure that it meets the customer requirements and then check all of those off and now we've got two left SWAT analysis that's more for risk and uh and uh figuring out what risks we might have our strengths and weaknesses and our threats so I think we'll put that one aside for now but the resource breakdown structure let's have a look does that belong in

planning Resource Management it could uh or estimate activity resources oh a bit tricky if we're estimating the activity resources we do want to figure out where everyone fits so where do they fit in our project team we're breaking down our project team and we'll do our team charter so our ways of working as we're planning Resource Management I think that's probably going to be right let's have a quick look okay thank goodness that was a little bit tricky and we've got that in the process groups practice guide under all of the inputs tools and techniques

and outputs under the process groups there uh from 2023 page 109 is the activity resources or estimating activity resources ones but you can easily search for the others as well all right very very handy to know project phases now oh this is a bit of a pallet cleanser this is a little bit easier thank goodness what do we do first feasibility because it's our business case and our project Charter kicks off our project then we we don't build it we have to design it first that's our gathering requirements and doing prototypes then we can build

the item then we want to test it and do quality assurance make sure it meets the customer need and finally we can deploy that item and incidentally if we're doing an agile way of work we're going to do all of these for one increment and release multiple increments but if we're in a predictive way of work we're going to do all of these just once uh and finish it at the end of the project so then we deliver in one big go at the end so that's the difference there just wonderful wonderful stuff let's quickly

check and there it is excellent work two to go in this little section so let's have a look we've got the agile oh agile Manifesto one of my favorite things now can you remember the agile Manifesto and it's handy to know because it gives us tips on how to act on an agile project we want to do do uh individuals and interactions over processes and tools oh and you know what it's uh it's done the other way but uh I think hopefully we get what we mean so the customer collaboration over contract negotiation uh comprehensive

documentation so res working software instead of comprehensive documentation and following a plan no responding to change instead of following a plan it's a bit confusing cuz they're upside down but let's check them out and that is correct the agile Manifesto and mindset page eight always remember that as our way to act individuals and interactions working together instead of or in as opposed to we prefer it over processes and tools last one here we go quality tools what do we do when we ask why something happens until we get to the root cause that's our root

cause analysis five y's to show a series of steps that lead to a defect we're going to use flow charts and we can do that to uh figure out how a process or a system works as well when we first join a project team very very handy the problem is at the head and the root cause ideas are in the Fishbones a fishbone diagram is also an Ishikawa diagram after the man who created it wonderful wonderful diagram and Par analysis is a count of the data that focuses on the few causes uh so we've got

a few here and then the rest maybe not so much but overall this accounts for the majority of our causes it's the 8020 principle uh the few causes with the biggest impact let's quickly check that we got it correct and there it is root cause analysis on page 249 on the pumb GU 7th edition and what else is quality is the quality of work that you're putting in to all of these questions doing this every day improving yourself just a little bit getting a little bit more knowledge and enough for you to pass your PMP

exam I truly believe that doing this work will help you not just in your project management career but also to pass your exam and I truly believe that you can do it let's get into the next set of questions okay project process groups all right looks like oh our classic initiating planning executing monitoring and controlling and closing and what have we got the project sponsor approves the project Charter project Charter and the uh project manager identifies the project stakeholders that happens in initiating the project manager develops the project management plan we are planning and the

team collect requirements and Define the scope and basically everything to do with our plans risk plan quality plan schedule and cost our budget really really cool the team manages project knowledge acquire resources where doing things we are executing things and uh we implement the risk responses we're doing the risk responses as well executing and the project customer validates the project scope based on the quality test outcomes that happens just before closing so usually our project sponsor or the high level project customer might approve of those things that we've delivered and usually they use the um

the test results to do that just so that it's nice and easy the last one is closing of course and where we create the final report let's have a look and there we go process groups of practice guide page one introduction or basically this will come from all of our um all of the process groups very very handy to know all right let's see what we've got next project artifacts a project manager needs a feasibility study to confirm if a project will offer value that is our business case a project sponsor needs to formally authorize

a project we do that with our project Charter exactly right a project manager needs a plan for managing the project including the scope schedule cost and quality and we just spoke about that that's our project management plan and all of the bits and pieces that go into that all the subsidiary plans risk plan Communications plan now if a scrum Master needs a collaborative ative document that out outlines how the team will work effectively throughout the project this is our way of working our team charter let's quickly check and there we go pinok guide seventh edition

commonly used artifacts that we've got here team charter is a wonderful agile one that you'll see come up in resources in the process groups practice guide as well all right next one doing great process groups uh in uh inputs tools and techniques and outputs a project manager is working to acquire resources okay and I like this cuz we've got uh it basically tells us what we're working on here acquiring those resources let's have a look uh project team assignments because who is assigned within the team that one makes sense a project manager sees gaps in

the team's work and needs to develop the team this is very handy it's uh out laid out very nicely for us actually what are we going to do here team performance assessments we're going to assess the team performance a business analyst is facilitating a session to identify stakeholders we're going to do that with our stakeholder register and the project management team directs and manages the project work we're going to use our project management information system or put all of our project data and information into that information system so that we can usually get a report

by analyzing all of that data let's have a look in see how we went excellent work process groups of practice guide all the EOS or the inputs tools and techniques and outputs for that fantastic stuff all right directions of influence do you remember this one this is fairly straight forward if it's Senior Management a sponsor or a steering committee they are above uh where we are currently the project team or Specialists providing knowledge or skills to the project ooh that's a tricky one uh I wonder if that's sideways that might be downwards actually people within

the project so that we are managing so we're slightly above uh in the directions of influence anyway peers of the project manager are the middle managers and people in charge of resources in a functional area for example they're going to be sideways to us and that means suppliers or government departments or even users of the system or the thing that we're delivering are outside the team they are outward for our dire directions of influence and there we go absolutely fantastic how did you guys go with that one directions of influence in the process groups practice

guide page 302 excellent stuff all right halfway through this little section Paul sends information to uh people by email who need to receive it that is pushing information we pushing it out to other people the project stakeholders can access access information on a web portal at their own discretion that is pull communication they are pulling it towards themselves whenever they're ready to access it an talks in a straightforward linear process a sender transmits a message to a receiver that's basic communication so nothing fancy there we're not actually getting confirmation that the message was correct and

we do that in interactive communication stakeholders have a two-way Exchange emphasizing ongoing dialogue and mutual understanding between parties the best example of this I have heard is in playing to win the book by alen Lafley I think and they talk about the assertive inquiry where this is this is what I think do you have anything else that you need to add or do you agree and that's just checking your understanding it's a two-way exchange and there we are all confirmed page 252 in the process groups practice guide under communication methods fantastic stuff all right let's

get into the next one responsibility assignment or so responsibility assignment Matrix is our ra that you'll see but aayy is our who is responsible who's accountable who's consulted and who's informed so Olivia provides expert judgment on part of a system for a project that means we are going to consult them on that information they're providing their expertise Ben provides or Ben creates this is a key word here the system flowchart to show people how it works he responsible for creating that item Sarah signs off on the project deliverable approving it for release she is the

approver she signs off on it she is accountable for that item and Frontline workers need to be told about changes to the system they need to be informed so that is our racy let's have a quick check and see how we went all locked in absolutely fantastic process groups of practice guide page 293 under responsibility assignment Matrix if you want to check that out for yourself all right couple to go in this little section what have we got here Ben stops talking to Anna and Retreats from the conflict situation resolving conflict this is withdrawing and

avoiding the situation and we'll look at this in a second but that is I I think that's either a lose lose situation or a lose win situation but let's see Amy con concedes her position to the needs of others to maintain Harmony and relationships she is accommodating her position uh so accommodating other people sorry CLA wants everyone to get along and asking that each party gives something up to resolve the conflict uh CLA is compromising here and Michael pushes his viewpoint on the issue at the expense of others he is forcing the issue on other

people now let's just double check this and make sure we got it correct okay that is correct and so what we're looking at here is smooth and accommodate compromising and re reconciling is a lose lose um forcing or directing is a win lose because you're winning and someone else is losing and smoothing and accommodating I think is a lose win and maybe withdrawing is actually also a lose lose I think the only one that's win-win is problem solving and collaborating with your team but check that out on page 258 under Conflict Management okay let's see

what we've got next interpersonal skills James gets stakeholders together in a workshop to quickly reconcile differences and reveal issues earlier James is facilitating and problem solving here Isabelle thinks before she acts and is empathetic to others in a high stress situation that is emotional intelligence where're looking at our effect and other people's effect emotionally Benjamin acknowledges and clarifies and confirms to ensure understanding he is using active listening and Maria clearly articulates points and positions gathering information to reach agreements Maria is influencing here let's check it out excellent that's all good process groups of practice guide

page 331 interpersonal and team skills wonderful stuff all right let's check out the next one and we've got some of the best stuff out there it is risk our favorite thing Leah identifies a risk but doesn't have the authority to perform the response Leah needs to escalate this CU it's outside of her control Riley asks the project team to remove some of their planned scope to eliminate the threat they are avoiding the threat because they're not doing that part of the project that would lead to the threat Owen H hires a contracting company to deal

with a dangerous part of their Pro project he is transferring the threat to a third party JN takes specific action to reduce the probability or the impact of the threat he is mitigating the threat through his actions and Luke acknowledges that there is a risk in his functional area but decides to take no action he is accepting the threat now let's have a quick check looks like we got those correct page 303 strategies for overall project risk wonderful stuff and also wonderful stuff is the last one here for opportunities as well very very important Jade

discovers an opportunity to improve the system but it's outside the scope of the project that sounds familiar it's like our other one it is escalating uh because it's outside of the scope of our project Liam wants to make sure that an opportunity for a joint venture actually happens now that's either enhance or exploit I think if we're definitely doing it we're exploiting it uh let's have a look at the other ones just in case Sam finds an opportunity in the system but his project doesn't need it so he offers it to someone else he is

sharing the opportunity and it takes steps to increase the probability of the opportunity occurring she is enhancing that probability of the uh opportunity happening which is great and Sarah acknowledges that the opportunity is there but decides not to take any action Sarah is accepting that opportunity without any action let's double check oh fantastic that has come through page 303 strategies for overall project risk and a strategy for overall passing your PMP is exactly what you're doing right now you're doing an amazing job keep going keep learning this is the kind of information that will help

you in your career and will help you to pass your PMP exam I absolutely know that you can do it and I truly believe in you let's get into the next set of questions develop approaches activities are performed once for the project with a single delivery at the end uh that sounds like a predictive or a waterfall method or a traditional method they might call it as well activities are repeated until correct based on feedback so repeat it until correct with a single delivery at the end that sounds to me like where iterating towards success

there until the end activities are performed once for a given increment so just for a particular increment for each increment uh we must be using an incremental approach let's have a look and in activities are repeated until correct so we've got a little bit of this and then uh with frequent small deliveries those two things are a com combination to form agile so agile is actually iterative and incremental at the same time and lastly combines any elements of predictive and adaptive development approaches to get the job done that's our hybrid approach and that could be

using a waterfall method with Canan boards and information radiators or it could be doing an agile method with proper sponsor approval and change control uh depending on how you want to swing it there's many many different ways to look at it let's have a look at how we did and that all came through Page 15 in the process groups practice guide project and development life cycles fantastic how did you go with that one all right agile colle collaboration approaches and we've got mobbing pairing and swarming Emily asks the team to work in pairs to complete

work check and learn together they are pair programming or it could be side by side programming or pair programming or just pairing if it's uh knowledge work or something else other than programming an issue is raised during standup and multiple team members meet afterwards to solve it quickly they are swarming around the issue so that's what we want to do try and solve those issues quickly Oliver is a portfolio owner impacted by a recent change and asks multiple teams to come together for an outcome they are mobbing they're creating a mob and that's all coming

together uh many many different teams let's have a look at how we did and that is wonderful stuff agile practice guide page 152 under definitions if you want to check that out for yourself all right agile tools Henry asks the team to display project information in the team location such as backlogs and risks or backlog I should say he is looking at the information radiator with all of our team project information where anyone can see it at any time Haley gathers around gathers the team around a visual tool used to track and manage workflow during

a standar a visual tool track and manage workflow sounds like a kban board to me and if you remember our kban board it's a going to have a few different columns here and we're going to move our user stories from in progress all the way to done right at the end there so we're tracking that workflow Lucas needs to see the planned trend of the work versus the actual trend of the work and you remember this one this is our planned Trend and then the actual trend of the work that is our burndown chart exactly

right that just leaves us with one Alice needs to know how many story points the team could complete in the next Sprint during uh Sprint planning and that's going to be our velocity chart now if you haven't seen that before we've got the story points that we planned the story points we completed planned completed planned completed planned completed and that gives us an average of the Velocity or the story points that we can complete and we use that for our Sprint planning to keep a sustain pace so we're not uh doing hurry up and wait

hurry up and wait and all of that to say we got those correct and I hope you did to page 150 under definitions in the agile practice guide a wonderful way to get up to speed all right uh number 44 some more agile artifacts some of my favorite artifacts actually the user Stories the team decides that they can complete in a Sprint that's going to be our Sprint backlog the prioritized list of features that's our product backlog and who owns the product backlog can you tell me it is the product owner exactly right and adjusting

the backlog to balance the highest cost risks with the highest value features risks versus features we have a risk adjusted backlog so we're delivering some solutions to risks but also delivering some value where're uh adjusting it for risk part of the feature that is small enough to complete in a Sprint that's going to be our user story and let's check those out that has come through Page 152 definitions in the agile practice guide wonderful stuff okay agile decomposition oh this is good okr user stories and epics and what have we got a larger feature or

deliverable or a collection of stories around a central theme that's going to be our epic so epics basically are like are deliverable and then we Brak those down into user stories so where's that one a description of an end user's need that can be completed within an iteration similar to a work package in a traditional project so call them user stories or call them work packages we're assigning them to a person so that they can complete them but what's an okr that is an objective and a key result an enterprise-led strategic Direction that's our objective

shown as a business goal uh with a way to measure it that is our key result okay RS let's have a look and there we are fantastic stuff agile project practice guide page 150 under definitions and we're also just over halfway through this little section well done keep going guys you're doing great request for quote all right or what have we got Emma isn't sure on what solution a particular vendor can provide she needs more information request for information the project team have a complex problem that can be uh to be solved by a vendor

they're going to need a proposal from that vendor on what they can do about the problem the pmo have a clear set of criteria that can be found in the market from multiple vendors all they need is a price they just need a request for quote or RFQ let's have a look and that is good looking good page 75 the bid process under the pbot guide 7th edition uh from 2021 fantastic all right what have we got procurement contracts when scope is straightforward and requirements are well defined we can use a fixed price contract because

we're not we don't need anything fancy here it's just fixed price everything is straightforward but when you want to incentivize the seller or if works are expected to change incentive incentivizing them we're going to use cost reimbursable contract so that's when there's a set cost and if they come in under that cost then they get a bonus basically or they get the difference between the cost and what we were going to pay them anyway so cost reimbursable useful when a precise statement of work is not available we can just use time and materials how much

does your time cost how much do the materials cost and keep working until the job is done and there it is that's come through at page 15 191 agreements and contracts fantastic and only a few to go in this little section and what we're looking at now is cost management oh I love this stuff cost management is great so what do we do with contingency reserves management reserves if it's set aside to deal with planned risks that is a contingency it's our contingency reserves if it's set aside for unexpected activities related to in scope work

that is our management reserves and you don't often find these in the real world sometimes budgets just don't have this but it is a nice thing to have as a just in case or as a final Hail Mary if you need more money to come through all of the work package costs plus the contingency reserve is our cost Baseline and then all of the cost Baseline plus the management reserves become our project budget overall and so that is exactly what we looking for pimot guide 7th edition page 62 under budget how did you guys go

with that one it's such a great way to brush up on all of this information before taking the exam last two for this section agile Concepts leading by serving the team that sounds familiar to me removing blockers and facilitating growth we are doing servant leadership maintaining a manageable workload that allows the team to effectively work over over the long term we are keeping a sustainable pace and that's why we use our velocity chart to make sure that we're matching our work to the previous velocity when a developer tester or a business representative meet to or

and a business representative meet to elicit user stories those are our Three Amigos or the Triad of those the developer tester and customer we might call them too stable long-term consistent teams that perform better over time are stable teams and those are the teams we want so they can grow that uh intellectual property and information about the system and then we get into that performing stage uh for tuckman's ladder which is also really really good and that is correct wonderful stuff how did you guys go with that one page 34 in the agile practice guide

if you want to check that out servant leadership empowers the team and we're up to the last one for this section which is absolutely fantastic more agile Concepts and lots of Concepts Fragile on the exam that you'll see so this is perfect quality is integrated and maintained throughout every phase of development from requirements to development we are building in quality at every step the project team plans near-term work in detail and further away items at a high level they are rolling wave planning so that's what we describ that and you'll see that concept come up

pretty much everywhere there's always rolling wave planning going on the team removes silos by including everyone they need to deliver the project or the product they are using the whole team approach getting everyone involved the team information is clearly available to everyone so they can self-manage their work they're using visual management and all of these or most of these come from the Toyota production system originally which is a great way to see where agile came from and that's come through as correct page 150 under definitions and what else is correct is the way that you

are going through and learning every day to improve yourself so that you can pass the PMP exam I know you can do it and I believe with the work that you're putting in you will pass the PMP exam keep going keep improving I believe in you let's get into the next set of questions okay agile Concepts getting opinions on the product and process speeds and increasing learning for future releases goodness gracious uh opinions on the product and the process oh and it that speeds increasing learning for future releases that sounds like we're doing a retrospective

we're putting information back into our process to improve okay the team come together and reflect on their process and the Lessons Learned oh hang on a minute that sounds more like a retrospective so what's this one opinions on the product that's going to be oh okay maybe early and frequent feedback we'll see if any other ones fit the build just in case the team finish a Sprint that sounds like a Sprint review they demonstrate the usable increment to the customer that's going to be our Sprint review the team have a visual display of project information

for anyone to see that's our information radiator and when the team are meeting to update what they worked on yesterday what they're going to do today and raise any blockers that's our daily standup for agile ceremonies let's have a quick look here okay we did get those correct page 150 under definitions in the agile practice guide how did you guys go with that one more agile Concepts oh and some of my favorite here definition of ready and definition of done so a prioritized list of features to be delivered that's our product backlog and we break

that down into user stories and we put that into a Sprint so the user Stories the team decides that they can complete in a Sprint that's our Sprint backlog now the team the criteria that the team agree for when an item is ready to be worked on that's the definition of ready or do the definition of done is the criteria that we agree on for when an item is complete so this might be the item has been coded it's been tested it's been checked off with the product owner then we can class that item as

complete it's our definition of done let's have a Quick Check and that's come through in the agile practice guide again check that out for yourself many many definitions for us to look through how did you guys go with that one okay agile oh lots of agile here the project designs by feature builds by feature tests and releases by feature and has dedicated feature teams that sounds like featur driven development one of my favorite ways to uh to do Agile and one of the one of the Frameworks that fed in to the agile Manifesto back in

01 so really really cool developers write the test first then they write the code that will allow the test to pass we're doing test first or test driven development business analysts write the tests in user Centric language what customers want and what customers do that is our given when then or behavior-driven development or bdd work is frequently incorporated into the main build and then it's tested as whole we're continuously integrating it continuous integration or CI time booxed research or learning often for Technical Solutions or acceptance criteria to figure out acceptance criteria with a team that

is a spike time boxed learning let's quickly check these make sure that we got them correct and that is looking really good agile practice guide again look through that under our definitions for any of those um to find those items agile measurements the time to complete a task or a smaller piece of work for example a user story that is our cycle time just for a single task or a single small piece but the time from customer order to customer delivery is the whole time the for a feature for example that a customer is going

to get their hands on that is our lead time now how much was committed versus how much was completed uh that's how predictable our process is and we can do that with a velocity chart if you remember from the previous questions where we show the velocity or the amount of user story points that we completed in previous iterations and then we can use that uh to be more predictable going forward and to put that amount of user story points in the next Sprint or the upcoming Sprints the amount of work waiting to be completed is

our Q size and the measures of the ratio of value added or VA work to uh non-value added or NVA to the total work time shows how efficient our process is it's process efficiency let's check that out just in case and it looks like we got it right so that's fantastic work page 66 agile practice guide agile teams measure results that one was really really good oh the theory of constraints oh I love this one personally very agile Centric this one and the Order of the theory of constraints I think Eli Gold rat was the

one who did this first we need to identify it so we're going to grab that and now what do we need to do then we're going to improve the process or streamline the process for that constraint we're just going to do everything we can to improve it without spending money on it once we've improved it we're going to keep that process just at capacity so just below the top capacity that we can handle for that process so doing the most we possibly can without overloading it and then once we've done all of that then we

can spend money on it or add resources to it or uh or add system power to it we can Elevate the constraint but we don't want to do that before we've improved it as much as we can I hope that makes sense and that's just a great way to operate in a team uh and that's why the theory of constraints is so great and once we've done all of that a new bottle neck will pop up once we've solved one we'll get a bottleneck somewhere else so we're going to repeat that on other processes and

looks like we did get that correct so that's good check out the goal by Dr Eli Gold rat if you want to learn more about the theory of constraints but that's basically it it's a really really good way to operate okay agile Frameworks oh my favorite kban which one is kban it is a workflow management method that optimizes work by limit limiting the work in progress and when we limit work in progress we're not task switching or multitasking so we're just focusing on the work at hand and amazingly we get work done faster as a

result if we facilitate iterative progress through timeboxed Sprints when do we use Sprints we use Sprints in scrum with a focus on continuous Improvement focus on frequent releases continuous feedback and higher customer involvement oh oh that could be either one probably extreme programming because scrumban is a combination of can kban and scrum so here we go here scrum with the flexibility of kban we put those two things together and that's how most agile teams work these days is a combination of those two things so let's have a look and see how we went and that

has come through excellent work guys page 99 to 111 that's all of the agile and lean Frameworks in the agile practice guide if you want to check that out for yourself okay let's have a look at what we've got next more agile Frameworks well that's good and you're definitely going to get some stuff on agile Frameworks in your exam so very very handy to know the project designs by feature builds by feature tests and releases by feature and has dedicated feature teams we did this one before this is our agile featur driven development the team

focus on constraint driven delivery with formalized prioritization of scope for example Moscow do you know what Moscow is must have should have could have will not have that's how we prioritize our scope and our constraints remember scope schedule and cost and in agile scope is variable and the other two are fixed and the method that brought that into into the workplace is dsdm so that was back in the '90s wonderful way to work and that fed into the agile practice guide in 2001 one uh a family of methodologies that emphasizes tailoring practices to the specific

needs of the project and the team that is Crystal because remember with Crystal they have a range of methods depending on how big the project is so crystal clear crystal uh Sapphire and all of these ones were different stones and colors to determine how big the project was and how much governance you needed around it and that just leaves uh an iterative Cycles across seven key disciplines such as modeling implementation and test that's going to be our agile unified process or AUP let's have a quick check and there we are excellent work page 99 to

111 again in the agile practice guide for all of those agile and lean Frameworks to check out how did you guys go with those ones okay scaling Frameworks also very handy to know if we apply scrum ways of working to programs and portfol folios only when necessary that is going to be our large scale scrum because uh less or large scale scrum actually recommends that we don't use a scaling method only if we absolutely have to now if we focus on organizing project teams around value streams that's going to be our scaling agile framework or

safe they use the value streams method which again came from the Toyota production system or lean a scaled approach where multiple scrum teams collaborate through cross team meetings I'm not sure about that we've got a few others aims to extend the scrum practices to the organizational level okay between these two I think scrum of scrums is just uh having scrum like a program at a portfolio level so at a team program and portfolio level basically more scrums across more teams uh with a with a a person representing for the project team at a program level

for example but Enterprise scrum that's when we're extending scrum practices to the organization across the organization and lastly a framework that uses agile and lean methodologies that's going to be our disciplined agile and that has come to be owned by the project management Institute so now they've got uh they're integrating all of those into that one approach called disciplined agile and there we go that one is correct page 111 under scaling Frameworks excellent work work very very handy to know and only two more to go in this little section so you're doing an amazing job

what have we got oh and also I love this stuff the uh the cost of quality uh internal failure external failure William wants to improve the process and provide training for the whole project team William is preventing a quality issue from happening Sophia is a software tester and creates a plan to find defects or errors in the product she is appraising that product she's uh checking it out quality assurance that's the cost of of assurance the product fails during quality assurance testing and review with the senior user that is internal failure it hasn't reached the

customer yet but it has failed we've found a defect and lastly the project team have released the product but the customer reviews show that there is a major issue it has reached the customer it is external to the project team so it is external failure and that's our cost of quality let's double check excellent we got that one right uh page 88 in the pach guide 7th edition cost of quality if you want to check that out for yourself last one in this little section agile scenarios oh wow okay if we want to involve actual

users of the system early and showcase to the customers in the Sprint review um that sounds like that's we want to do that if we have a poor user experience now uh if we're ensuring The Three Amigos collaborate regularly to create the user stories we're going to do that if we have probably unclear requirements so to get clear on requirements we can get our Three Amigos together to collaborate regularly now if we have an unclear purpose for the team let's have a look Workshop the team charter to align the mission and the high level features

that will give us a purpose with our team charter that does sound correct so let's do that first and if it's uh we can always change it if this one ends up being more correct so Workshop the team charter definition of ready and definition of done that's going to help us get clear on working agreements because definition of ready in definition of done are more of our ways of working I think that's what we're going to do let's double check all right excellent work that's come through as perfect and Page 58 in the agile practice

guide if you want to check that out under agile pain points and troubleshooting but you know what's not a paino is all of the wonderful work that you're doing preparing for the PMP exam and getting up to speed on all of these scenarios all of these definitions and a few drag and drop questions so that we're prepared for that when we get that during our exam I know that you can do it and I know that you can pass your exam because you're doing an amazing job studying and practicing iing every single day I know

you can do it I believe in you let's get into the next set of questions okay measurements proactive metrics that are used to predict future performance and identify potential issues that sounds like leading where leading indicators and this could be things like do we have a uh process for what we're doing or are our stakeholders engaged those things are leading indicators uh if stakeholders are not engaged then things might be going south in the future now metrics that reflect past performance and outcomes providing insights into what's already occurred so things like customer sales or uh

or things that have already happened those are lagging indicators measurable objectives or measurable values used to assess the success of project activities and overall performance uh it could be either of these I think that's going to be our kpis just just general measures or key performance indicators for our project how are we measuring the things on our project and a high level written goal with the measures to get there that's our objective High ritten goal and key results those are the measures or okrs that we might see in agile let's quickly check that out and

it looks like those are correct from the pinbot guide 7th edition if you want to check that out key performance indicators on page 94 how did you guys go with that one first one off the ranks in this little section so really really good measurement pitfalls okay where what we measure influences the behavior of the people that we're measuring that is the Hawthorne effect and so be careful if you measure uh if you measure how fast things go then people will do everything in their power to go really really quickly but that might cost us

uh quality so we the quality might go down so we have to be careful what we measure it's a or just be aware of it measuring things that are not actionable ah that might be vanity metrics because we're just measuring them but we can't actually take any action on them what's the point it's just for our own vanity or as an executive this does happen quite a bit you've probably noticed um if what we measure is not achievable then we get demoralized so we're demoralized because we're measuring something and we just cannot ever see ourselves

achieving it and using metrics to validate our own opinions we are confirming our own opinions that is confirmation bias have you ever done that you've gone out and found a whole bunch of data just to confirm your own opinion and then you say we'll see look the data confirms what I said but there's a whole bunch of other data that we didn't actually look at anyway I could talk about this stuff for hours and there it is that's comes through measurement pitfalls in the pbot guide 7th edition uh page 111 to 112 how did you

guys go with that one all right more measurement pitfalls oh well seems like there are a lot of pitfalls when we're measuring things measuring things that aren't action actionable if you remember that was our vanity metrics looks like there's just two extra ones here so using metrics as a beating stick instead of helping remove blockers that is misusing the metrics have you ever had someone uh use these metrics and just say well you just need to go faster but really uh if we're leading properly or especially in agile servant leadership we should be using the

metrics and saying how can I how can we remove those blockers for you to get what you need how can we get you what you need to do the job that you need to do uh using metrics to align with our own opinions that is confirmation bias again and the last one this is one of my favorites if two things happen at the same time uh it doesn't always mean that one caused the other for example that happens there and it happens there they're very very similar but that doesn't actually mean that those two things

are caused by each other and a classic example of this is uh is drownings versus Ice Cream sales drownings go up at the same time as ice cream sailes so people thought that ice cream uh caused drownings but really it was the hot weather because more people go swimming in the hot weather and more people eat ice cream in the hot weather maybe a little bit more that one but it's a good example and let's just quickly check there we are pbook guide 7th edition page 111 and 112 measurement pitfalls all of these things really

really good to be aware of as we go through our own projects not just for the exam so that's pretty cool all right the benchmarking process oh now how good is this and also when do we use benchmarking well what do we do first we want to find the process that we want to improve uh select the process here we go so that one's good and why do we do benchmarking we want we use this to find Opportunities to improve we Benchmark our process against another team or organization's process to find ways that we might

improve so we want to figure out the current situation our process and then the organizations that we want to compare it to so ours and theirs and then we want to document our current process so that we've really got all of our current situation laid out and then once we've done that we need to collect all of the data from other organizations so we can compare it and that's what we do next uh or collect and compare to the other organizations and we find those uh improvements that we can make and we plan and in

Implement those changes then we review those results and we repeat and you'll find that Consultants so the big consultancy firm firms let's quickly check though okay that's right great but the big consultancy firms like KPMG or PWC or McKenzie they actually use benchmarking a lot because they have a lot of data from all of the other organizations that they've already worked with and so that's where the power of working with those consultancies comes in page 249 under benchmarking and how did you guys go with that one it's a great way to get ideas for your

projects or improvements types of analysis uh analysis on whether work should be completed internally or purchased for from an external supplier we're figuring out whether we need to make it ourselves or buy it make or buy analysis prioritizing our stakeholders by their influence and impact is stakeholder analysis and you remember what this looks like don't you it's like a matrix and we've got four quadrants basically of 1 to 10 and 1 to 10 and one is our infl uence and one is the impact that they could have that our project will have on them and

really we want to focus on the people with the highest impact uh to them and the highest influence that they have on us so all of that is very very you it's just a great way to to work and a very good thing to be aware of analyzing how much contingency and management reserves are remaining that is our reserves analysis and that looks like a little burndown chart actually we've got our reserves and how much do we have remaining just pretty simple doesn't have to be too complicated uh evaluating how changes in key variables impact

project outcomes okay last one is our sensitivity analysis and what else can we call sensitivity analysis it is a tornado chart because we've got zero here and is it a little bit to the left is it negative or is it positive negative positive and it ends up looking like like a tornado let's quickly check and that is good page 174 to 176 data Gathering and Analysis in the pumbo guide 7th edition wonderful stuff all right more types of analysis let's see what we've got analyzing a risk probability and impact that is our risk qualitative analysis

uh and so that's a good way to do it five wise Ishikawa diagram or Paro diagrams help us find the root cause of the problem root cause analysis using statistics to find trending data Trends are regression it's a regression to the mean so it finds the trend over time and analyzing strengths weaknesses opportunities and threats that's an acronym for SWAT our SWAT analysis let's have a little check and and that one is correct wonderful page 174 to 176 data Gathering and Analysis in the pumb guide 7th edition how did you guys go with that one

that one is not too bad pretty straightforward and really good to be up to speed with all of these terms that we're going to see in the real world and on the exam a list of categories broken down from high level to low level or risk categories that is our risk breakdown structure and we might put these into categories like commercial risk management risk uh or system risk and then we can break them down further so what are all the system risks that we typically see and it's a great way for us to brainstorm risks

and then to use them in the future within our same company so pretty handy adjusting the backlog to balance the highest cost risks with the highest value features that is our risk adjusted backlog and uh we've seen that before definitely using that in agile evaluating risks based on their potential impact using subjective judgment and expert opinions uh subjective judgment is qualitative it's our qualitative risk but analyzing the risks based on statistical and mathematical methods is quantitative it's our quantitative data we're quantifying it with numbers and let's check that out there it is Page 231 under

risk management plan in the process groups practice guide from two uh 2023 wonderful stuff all right only three to go in this little section you're doing really really well let's see what we've got clear real world measures of the risk impacts and likelihoods those are our risk definitions and risk definitions are really handy because then if we've got a likelihood of 1 to 5 we're saying what does that actually mean in the real world is a likelihood uh 20% chance of it happening or it's only going to happen once a month or once a year

or once a day what does that look like in our organization and each organization will be different so we have to Define it pretty cool I really like that stuff uh the person accountable for the risk and its outcome is the risk owner maybe that makes me a little bit weird with uh you know I like Risk so much but hey you know it's everywhere so we want to manage it properly the controls iations and other responses are our risk responses wonderful and a list of risks including the title impact status owners and responses we

put all of our risks into that risk register let's check that out and see what we've got and there we are pinbot guides 7th edition 2021 page 189 under logs and registers excellent how did you guys go with that one two to go in this little section so so let's keep going assessing the stakeholders by their power urgency and legitimacy that is our salience chart similar to a stakeholder uh uh stakeholder Matrix but we have three things and they call it a maybe it's a 3D uh or a cube uh version of the analysis as

well uh because there are three parts not just two so prioritizing the stakeholders according to their impact and their influence that is our normal stakeholder Matrix now what's a document that lists all of our project stakeholders detailing their interests influence and the impact on the project that's going to be our normal stakeholder register and classifying stakeholders by their current and desired level of support is our stakeholder engagement Matrix now do you remember with the stakeholder engagement Matrix how we rank them it's uh are they unaware are they resistant are they neutral are they supportive or

are they leading and we want to put a c for their current state and a d for their desired state so if they're unaware currently we want in the future we want we desire them to be supportive and so that's our stakeholder engagement Matrix uh just a little bit of extra stuff there and that is correct so we've got that and that's wonderful page 250 stakeholders in the glossery nice and easy to find last one you have done an amazing job this is the last one for this particular section Michael asks stakeholders to cast votes

or to rank or to rank or narrow down a list of features wonderful way to do it if we're voting multiv voting is going to be the one now multiv voting we might have five dots this is can also be voting with dots we might have five dots to put towards different features and so everyone uses up all of their dots and you could use five dots on one feature if you wanted to um or you could spread them across different features and that way it ends up just uh people really end up getting what

they want so it's a really good way to do voting um Leia prioritizes items with the highest value and the lowest effort that is our prioritization Matrix and that just looks the same as our other matrices that is just like this with the 1 to 10 of highest value and lowest effort if it's low effort we can put it as a 10 and we want to be doing the ones with the with the highest value and the lowest effort pretty simple and a good way to prioritize Oliver is using safe or the scaled agile framework

uh prioritizing features using a method similar to the cost of delay that is the weighted shortest job first or wisf now it is very similar to the cost of delay so just keep that in in mind um and you shouldn't have a calculation on that but it's good to know and with our cost of delay we want to choose the highest value that that it comes out of that calculation Ruby prioritizes features by must have satisfiers and delighters that is our Kano analysis and remember delighters in today's terms become satisfiers in tomorrow's term so over

time people become used to it and they start expecting those things so Delight become satisfiers and then over time become must-have quality for example electric windows in the ' 80s in 1980s everyone it was a delighter it was an amazing thing or maybe in the '90s uh and now today it's just a standard musthave part of quality let's quickly check how we went and it looks like we've got a winner but also a winner is the way that you are going through these questions and improving yourself and improving your knowledge every single day I think

this is absolutely fantastic and it's a wonderful way to prepare for your exam and also truly the best thing to improve your general project knowledge projects are so important and by getting this skill you are doing something important too and I'll see you in the next set of questions prioritizing using a dollar benefit and versus the time it will take to deliver that sounds like a prioritization matrix but we might have to come back to that I'm not sure so that could be a few things maybe the cost of delay let's check oh it could

actually be the cost of delay uh let's go with that one I think that's more likely the dollar benefit we use and then we we check that against how long it's going to take so how long that benefit is going to be delayed perfect okay thank goodness prioritizing by must have should have could have and will not have that's our Moscow way of prioritizing and evaluating and ranking options based on different criteria that we choose that's our multicriteria decision analysis and multicriteria this is such a great way if you've got a really complex um project

or lots of complex criteria this is a fantastic way to prioritize find yourself a good template for that one I have some templates for this as well but uh those are that's a really good way to do it and prioritizing by effort and value that's going to be our prioritization Matrix okay let's quickly check that seems to be correct how did you guys go with that one a good way to start us off estimating methods great so we're prioritizing we're estimating all very important things to do the team estimate on the effort high and low

estimates discuss and then reestimate until a consensus is reached that is our wideband dely estimating now just as an aside that's also planning poker in agile and planning poker was based on wide band dely estimating basically so we discuss the the high and low uh discuss their reasons and then we try and form a consensus based on that now does it have to be perfect no but you'll find that's a really good way to get a pretty accurate estimates involving estimates the size or effort of tasks by comparing them to the smallest one it's comparing

them their relative and we also do this in agile where we have a small user story and we give that one story point and then every other story after that is uh relative is sized relative so and it usually goes in the Fibonacci number sequence so 1 2 3 5 8 and then 13 and you and so on and so on we uh I won't go into that in full detail uh but that's just a brief overview of relative estimating a weighted of three weighted average of three estimates that's going to be oh now when

it's a weighted average we have the optimistic four times the most likely so it's weighted towards the most likely and then the pessimistic we add those all together and then divide it by six that's our per or beta estimating similar to our three-point estimating that we've seen before using something similar to estimate we're using an analogy it's analogous estimating and that's from page 178 in the pbot guide 7th edition underestimating how did you guys go with that one all right wonderful way to kick this one off really really good job James needs to see project

activities visually as bars on a calendar he is looking at a Gant chart Dylan has brainstormed dozens of ideas and needs to group them into similar categories he needs to find their Affinity to each other Hannah needs a count of defects on a bar chart so she can find the most occurring ones that is our histogram basically similar to a bar chart Matthew has a complex defect and needs to find the root cause he's going to use a cause and effect diagram and what else do we call a cause and effect diagram it could be

a fishbone diagram or an Ishikawa diagram under the per under the name of the person who created it and mirr is sequencing project activities and finding their dependencies we can do that with a schedule Network work diagram and all of those have come through correct how did you guys go with that one pbot guide 7th edition page 188 visual data and information now keep going if you're not getting these correct you can always review them it's always here you can always come back to it let's see what we've got next a description of the project

and the product scope and major deliverables okay this is all of our wonderful scope items that's going to be our scope statement it's just a can be a sentence and then a list of features just the major deliverables using a visual example of the work decomposition into work packages we're taking those high level deliverables and we're turning them into uh smaller and smaller pieces where decomposing them that's going to be our work breakdown structure a matrix containing any additional attributes for each of those work packages that's going to be our work breakdown structure dictionary we

had resources cost duration or time estimates quality details who signed off on it all of that extra information a piece of work or functionality small enough to be assigned to a person or team is going to be our work package and that's what we're breaking things down to that smallest level a work package but in agile if we're breaking down features now notice it's the same concept it's a feature and we're breaking it down into user stories uh we're calling it a different thing but the concept is exactly the same user story mapping in fact

user story mapping we're doing it on the customer Journey as well so maybe we've got a customer step by-step little flowchart they take this step next step and then we break this feature down into those user stories as they go along the customer Journey that's customer story mapping let's quickly check okay that is correct page 236 scope Baseline for all of those scope items halfway through now an agile predictive or hybrid project processes ceremonies and tools oh oh this is great this is the project manager Talent triangle and you'll see this in the uh in

the process groups practice guide you need ways of working uh now what if we have collab ative leadership conflict management team building and effective communication those are our power skills and we need all of these three things to be a good project manager by the way understanding value priorities making good business decisions good commercial decisions making sure we're delivering that business value and continuous Improvement that's our business Acumen or business knowledge let's quickly check and that is great project manager competencies under page 58 in the process groups practice guide now if we have a sequence

of activities which make up the shortest possible duration uh for the project completion what is that that is our critical path uh it's critical because we can't move anything because it's the shortest duration we can possibly figure out to finish the project in the amount of time an activity can be delayed without affecting its success activity that is the free float of that activity how far can we float it if we need to now the amount of time an activity can be delayed and still keep the whole project on schedule that is our total float

so free float and total float and the date when major items will occur are Milestones uh or thing when things are going to be delivered and the project days that are available fored activities so do we have any days off or holidays uh do we not work weekends or do we only work two days a week uh what are those things let's put those on our project calendar and that's from a process groups practice guide page 262 under the critical path method which is really really handy to know now how do we plan scope let's

have a look here first thing we always do in any situation is create our plan for how we're going to manage it so we create our scope management plan now the next thing we need to do is collect the requirements or uh elicit or gather the requirements from our stakeholders or customers so that we know what they want and what we need to deliver then we need to what do we need to do next create the scope statement that's that high level uh with the high level statement with a list of high level features then

we can break that down with our work breakdown structure so we're going to break that down into smaller and smaller pieces that a person can work in work on and what's that called that's called a work package so we but we do that last because before that we need our work breakdown structure dictionary and that has all of the extra attributes remember like resources needed the time estimates or the cost estimates for those work packages and then at the end we have that final list of work packages and there it is excellent process groups and

management phases under page 22 to look at that process very very handy to have and of course once we've planned and gathered and collected our scope then we can look at planning and planning our schedule and figuring out how we're going to do that and remember the first thing we do is planning out how we're going to manage our schedule who does what what are the steps that we're going to take what's our schedule management plan now what do we need to do next probably create the list of activities based on the scope and the

Milestones then we want to create uh sequence those activities so do they have any dependencies now once we know that we can estimate the activity durations and we've already looked at a few uh estimating methods which is really really great and right at the end we have our approved schedule which becomes our Baseline schedule so then it needs to go through a change request in order to change it if we're in a predictive way of work just a few little extra bits of information oh that's always a good bit of fun page 58 under schedules

and the last two in this little section you're doing an amazing job first 2 third fourth and fifth under project integration the first thing we do is our project oh no hang on I nearly got caught there business case so we need a feasibility study is the project going to deliver value is it worth doing in the first place that's our business case then we initiate our project with a project Charter the project sponsor signs off on it and gives us access to funding and resources then we create our project management plan and we plan

out all of those things like we just saw previously and a few extra things procurement risk Communications resources and as we go through the project we need to access and and use our project management information system and that could be anything that could be a system like jira or Microsoft project uh or monday.com or any of those things and lastly we're going to close off the phase or the project with our final report so that everyone is on the same page and there we are page 288 uh or 211 under final report and project management

information system in the process groups practice guide wonderful stuff and well done last one here uh oh and why did they have to give us calculations for the last one oh that's a bit harsh okay but here is actually you know what it's actually pretty good because I can tell you a little trick here and the trick is with uh with all of these things if we've got uh the cost performance index or the schedule performance index those two things one is how much we should have delivered at this exact point in time if it's

greater than one we have delivered more and that's for both of these if it's less than one we have delivered less so let's have a look cost performance index is 1.2 so we've delivered more than what we should have at this point in time so we are under our budget because we've delivered more so project is under budget there we go nice and easy but the schedule performance index is 0.8 so we've delivered less than what we should have at this point in time the project is behind its schedule now it's the same for the

cost variance and schedule variance uh except the the number is zero so if it's less than 50 for cost variance we're going to be over our budget because we've delivered less so that's very handy to know and schedule variance is over zero so we've delivered more which means our project is ahead of schedule and so we'll just get rid of that and double check this make sure that that is correct and that has come through which is really really good that was actually good to know so I'm glad we did finish with that one and

I'm also glad that you're here practicing and improving your knowledge every single day to pass your PMP exam and get better at project management project management delivering value and really making change and doing great things in the world it's such an important skill and you're learning it and growing and improving and getting even better skills that will help you deliver that value I cannot think of a better way to spend my time maybe I need to get out more but I think you're doing a fantastic job and I'll see you in the next set of

questions dealing with complexity an iterative process of adding greater levels of detail as they become available okay that to me sounds like Progressive elaboration and a lot of these techniques for dealing with complexity are actually match up with the agile way of work so agile was sort of created to deal with a lot of this complexity and uncertainty and even volatility that classic vuka that you hear about uh and so what's the next one a small lost low cost version of the real thing that sounds like a prototype so we want a small lowcost version

of the real thing to see if the real thing might actually work that could be a model or it could be a storyboard or even a process map just to see if it's going to work tests of similar items uh to the real thing in a controlled environment to identify cause and effect um experiments and simulation very similar these things but if it's a test we're going to go with an experiment and if it's a scenario similar scenarios or data used to find insights I think we're going to do a simulation there and Monte Carlo

simulation is something you'll find in quantitative data especially for our risk where we do a thousand different runs or tens of thousands of different runs of the same scenario but with different variables for each of the inputs anyway data is one of my favorite things if you can't tell but also one of my favorite things is we got that correct how did you go with that one dealing with complexity on page 120 in the pbot guide 7eventh Edition what a wonderful start to this little section okay tailoring scenarios uh use value stream mapping oh so

we've got the approach and the situation here so if stakeholders are not engaged let's have a look um well which way do we do this go from let's start on the right hand side when do we use value stream mapping and carban boards to visualize the work and track issues maybe if uh if there are issues we and there are high rates of scrap we're going to use K uh visual value stream mapping to map out the process and to find nonv value added items and to find rework and cues and all those sorts of

things that's what value stream mapping is for to find issues uh and waste in the process okay so we got that one this one's pretty tricky streamline approval decisions through fewer people up to certain value thresholds we're going to do that if there are long delays for approvals so if we have long delays for approvals we can um have fewer people approving them and so it's not going through too many people and we can have different value thresholds so we don't have to have people approve millions of dollars we can have smaller amounts and different

thresholds there that's actually a really good problem solving one uh use feedback loops to check whether sufficient information is being shared un people unsure of how to do the work or stakeholders not engaged well the last one is adding more guidance and training and verification that's definitely for if we're not sure of how to do the work and that means feedback loops and checking on information that we're sharing will help with stakeholder engagement that was actually pretty tricky let's check okay we did get it correct so that's good how did you guys go with that

one page 151 under tailoring suggestions in the pbot guide 7eventh Edition so that's come that's a pretty good one all right tuckman's ladder one of our favorites we love good old tuckman's ladder team members are getting acquainted establishing ground rules and forming initial Impressions that could be forming uh unless we've got another one but we'll start there team members are building relationships resolving conflicts and working together as a team they are storming team members are disag oh no team members are disagreeing over roles and responsibilities creating collaboration challenges that's more like storming uh maybe if

they're building relationships they are starting to come into norming and the team complete their tasks reflect on their achievements and transition out of their roles they are adjourning they're finishing up the team is operating efficiently leveraging strong collaboration to achieve high levels of productivity they are performing that's when we build that high level of trust and now we are performing really really well as a team and that one came through wonderful stuff page 166 pbot guid 7th edition tuckman ladder excellent how did you guys go with that one all right artifact scenarios Ken would like

to transition the company to a new customer relationship management system and needs to evaluate the benefit costs risks to secure approval he does that with a business case of course before a project Charter so Mary has received approval to develop new software and needs to outline the project scope stakeholders and roles to formally authorize the project oh I was going to go with project management plan but if it's to formally authorize the project I think it's going to be project Charter well let's see Tim Needs to develop a document defining how his project will be

executed monitored and controlled and closed that's our project management plan Rob is developing strategies for engaging people managing expectations and ensuring effective communication throughout the project that's going to be our stakeholder management plan how we're managing the stakeholders and that is perfect wonderful stuff page 184 strategy artifacts in the pach guide 7eventh Edition predictive and adaptive scenarios okay predictive has fixed scope and requirements at the beginning usually and then we need a change request if we make changes to those as the project goes along agile has adaptive planning uh agile also has incremental delivery and

oh no predictive has sequential step-by-step phases predictive also has detailed planning whereas agile has our cross functional teams and do you remember our cross functional teams the t-shaped team member so a broad range of different skills but one deep specialty so that's our t-shaped generalizing specialist very very important to have in the team if you can let's quickly check that one and there it is excellent so those are your predictive and agile ways of working all right let's see what we've got next more predictive and agile and adaptive excellent I like these ones cuz they're

some of my favorites the product backlog of course is one of our agile ways of working the Sprint backlog is also one of our agile ways of working where we put enough user stories for the next 2 week Sprint the work breakdown structure we'll usually use in predictive and what's something similar in agile it could be user story mapping or it could be breaking down epics into user stories change management plan that's going to be in predictive and risk management plan that's going to be in predictive burndown chart is what we're going to use in

in agile so let's quickly check those ones wonderful stuff all right that has come through how did you guys go with that one I like those ones they're not too difficult all right predictive and adaptive this is good I love this great sequence of uh of questions this one agile has user stories uh work breakdown structure that's going to be predictive project Charter every project has a project Charter so we can kick off a project whether it's agile or waterfall or predictive uh it still needs that project Charter to get access to the resources so

that means rolling wave planning we're going to use in either uh agile or predictive or when we combine them together it's a it's a hybrid approach let's just double check and there we go excellent work all right now hopefully that's the last there we go so no more adaptive and predictive ones but three in a row that's pretty good now we've got some more tricky ones I think the project team has been experiencing communication delays and misunderstandings if they're doing that they need an information radiator to get more communication to communicate all of the project

information in the team area I think that's good the team development team is facing issues with frequent rework and miss aligned expectations oh hang on a minute collocated teams could have also worked here so oh let's let's have a look for this one I think continuous feedback loops will help us with frequent rework and misaligned expectations so we're getting more feedback and closer feedback the project team is struggling with visibility into the project status now that is our information radiator leading to confusion and delays in addressing issues that means communication delays we want to collocate

our team so that we get that close communication we don't have to wait 3 days for someone to respond to an email we can just look over our shoulder and and chat to the person who's sitting right there that means schedule crashing the project is falling behind schedule due to unforeseen delays and the team needs to find ways to accelerate the completion of critical tasks they can do that with schedule crashing which is throwing resources and money at the project to expedite certain tasks on the critical path okay and that one has come through project

situations very very cool all right more project situations these are pretty good actually so the team is planning a new project and they need to assess what they are good and bad at to make informed decisions is that a retrospective or is that going to be good and bad so strengths weaknesses opportunities and threats that's going to be our uh SWAT analysis the team is struggling with aligning their development efforts and ensuring that they deliver features in a strategic order that's our product road map when we uh and a product road map doesn't have to

be anything fancy it can just be the sequence of features that we're delivering or we can put it on a a Gant chart or a calendar or we can put it on a schedule Network diagram any of those things will do it's just a way of visualizing how we're going to deliver the work after completing several Sprints the team is experiencing recurring issues and inefficiencies that are affecting their performance let's use a retrospective to check in on the work and improve our process if we can the project manager needs to quickly estimate the duration and

cost of a new project but lacks detailed information we can use an analogy a similar item or a similar project to at quickly and there we go those answers are correct wonderful stuff now you're up to the last one for this particular section you're doing a fantastic job and surprise surprise it's more agile versus predictive well I love these ones so I don't mind I hope you like them as well but we can do these pretty quickly scope is fixed on a predictive uh project scope is variable because we just reprioritize the scope in the

product backlog exactly scope management plan we plan all of our scope up front but we have a product backlog in agile epics and user stories we have in agile and deliverables and work packages and you see how these things are very much the same uh but just with different names and slightly different ways of working um but again in agile we just want to keep the effort to to manage all this stuff light so we're we're spending more time doing the work and less time CL on all of the documentation let's quickly check and there

we go wonderful stuff and also wonderful stuff is that this is the last question in this particular section so you've done an absolutely fantastic job well done in getting through this and well done in improving yourself and doing the work and learning and getting better and doing everything that you need to do to pass the PMP exam and also to improve your general project management skills which will take you so many places because you're delivering bring value for organizations it's such a valuable skill and you're doing the right thing and I'll see you in the

next set of questions okay one of my favorites agile versus predictive now what have we got here agile is pretty simple I love this stuff product and Sprint reviews definitely we're having a Sprint review at the end to see if our increment matches the what the customer wanted uh close customer contact we're always going to have so we prefer talking face to face to get all of those extra visual cues and tonality cues that you don't pick up on when you're sending an email uh we're going to have a complete requirements document in predictive and

we're probably going to have system documentation instead of reviewing the actual product and in predictive we might have a schedule Network diagram to show the order of our things like a on a Gant chart but in agile it's a similar idea but we're going to have a product road map instead so really just called a different thing you could use uh a Gant chart for your product road map and that's what I personally do in the real world all right that was a pretty good one to kick off with I like that one so how

did you guys go let's go into the next one planning schedule management oh these are process groups inputs tools and techniques and outputs oh these are tricky okay planning will H the first one's not too bad because what's the first one that we always do we're planning schedule management and we're cre creating our schedule management plan so how we're going to manage our schedule if we're sequencing our activities o precedence diagramming method we might need to know uh the Precedence diagramming method for what comes first and what comes next we're sequencing it okay let's try

that developing the schedule is going to oh goodness that's probably going to be the critical path method and we can move that if we need to defining the activities gosh this is actually pretty hard um defining the activities we're going to decom uh use decomposition because we're taking our scope and decomposing it into the activities and oh I I thought that was strange we've got two sequence activities so leads and lags can be used here at the same time as our precedence diagramming method in sequence activities that's why I thought it was strange let's double

check and make sure that we got that correct well the other way around but both of them were for sequence activities so thank goodness that was pretty good page 89 under plan schedule management very handy information to have okay that was a bit trickier how did you guys go with that one procurement now A Benchmark for our quote prepared by an outside professional estimator and we could have uh commercial databases of information or we could go to um to consultancy firms like KPMG or McKenzie who have that information on uh other people in the industry

all of these we look at as our independent cost estimates defining the scope to be included in the contract and the terms of reference that's going to be our statement of work what the vendor needs to bid on and used to ensure that the prospective vendors all have a common understanding we're going to hold bitter conference so everyone is on the same page and no one gets preferential treatment that could come back to B us later that's that's great we did it great excellent page 74 fantastic and another one I think these are getting trickier

uh now so uh I hope hopefully it's not always getting trickier up to 110 but if you want to check that out pbot guide 7th edition working with procurements all right procurements again oh goodness um used to explain the difference uh the list of potential sellers uh or expand the list of potential sellers how do we do that we advertise so if you've got a government contract particularly you might need to advertise uh that opportunity so all of the vendors have an opportunity to bid and again then they can't come back later and say well

we never heard about this and it's unfair so it just keeps us safe uh contested items in a project where the buyer and seller can't agree on any changes that's a claim and claims Administration and last one details on how we choose our vendor including capability that's how we select them our source selection criteria let's double check that's come through wonderful wonderful stuff hopefully that's the last one on procurement Goodness Me Okay more EOS goodness this is a really tricky one okay subdividing project deliverables into smaller more manageable components is creating the work breakdown structure

finding the work number of work periods needed to complete individual activities is estimating the activity durations and all of this is going to be in our process groups practice guide so we can check this out developing approaches to involve stakeholder uh project stakeholders based on their needs that's planning stakeholder engagement and lastly developing the document that formally authorizes our project that's our project Charter let's double check and that is wonderful stuff process groups practice guide if you want to check that out for yourself under all of those inputs tools Tech tools and techniques and outputs

risk parameters they are throwing all of the fun stuff at us today okay the period of time we need to respond to the risk in for it to be effective Ive that is the urgency I would say and we can always Shuffle these around if we need to the ease with which the results of the risk can be recognized that's how easily we can detect the risk the period of time between the risk occurring and when we might Discover it that's how long it's lying dormant so how uh what's the dorcy of the risk and

how related the risk is to other project risks how connected is that risk to other project risks let's double check wonderful stuff well done all right little bit tricky for those risk ones but page 247 assessment of other risk factors and only four to go in this little section so you're doing an amazing job consider pair work oh agile scenarios okay oh goodness me consider pair workk shoulder checks or code inspections test driven development and workshop the definition of done when are we going to do that I think we're going to do that when we

have too many defects so we can Workshop the definition of done use test driven development for quality and shoulder check and and pair programming to make sure that uh we're finding those defects I think that would work reduce the story size the user story size and estimate with the people doing the work we're going to use those things if we have inaccurate estimation in our team these are tricky building a slack card to refactor code and ensure developers are part of user story creation that's when we have technical debt so we can build in a

slack card which is just a card maybe it has five points uh and that card goes into the Sprint backlog and it takes up so that we're not using that velocity on other work and then we can use that time to um to refactor the code and to improve the code to make it better for the future last one is going to be unclear team progress and we do that when we uh if we can use a kban board and use daily standups to report blockers and to micro commit to what we're going to do

in the next section and if you want to see that that's page 58 agile pain points and troubleshooting and that's come through wonderful wonderful stuff all right how did you guys go with that one last three so project process groups initiating the team is successfully defining project goals securing stakeholder Buy in and what's the keyword there creating that project Charter they're initiating a project the team is working diligently to develop a detailed schedule allocate resources and Define the project scope I think uh well I don't like the allocate resources but defining the project scope is

planning now if the team is working actively to complete those deliverables they are executing coordinating team activities yes and managing resource objectives yep that sounds good the manager is tracking progress they're monitoring and controlling in the process groups measuring performance and making adjustments and if the team has completed all the deliverables and reviewed those outcomes and finalizing the documentation maybe creating a final report there that is closing the project and that is good that's come through so page 171 under process groups in the Pro in the pbot guide seventh edition wonderful stuff okay more agile

scenarios oh well we got through the other ones pretty well so let's see how we go reducing the story size and defining the definition of done maybe if uh oh if work is not completed within Sprints we can reduce the story ex size and make sure we've got the definition of done really really crisp ensure the servant leader or scrum Master escalates problem solves or clears obstacles if the team is struggling with obstacles hold retrospectives regularly with no more than three action items for next time uh if there's no improvement in the team process very

handy to do and work with managers of external resources to dedicate them into our team so that uh we can use the whole team approach that's if we have siloed teams or people who aren't involved directly close with our project page 59 agile pain points and troubleshooting in the agile practice guide and that is very good really good one to go through that one now risks issues and change if Billy wants to add a feature to project delivery and the scope is already baselined he's going to need a change log exactly right I I assume

that's right we can always move it but that seems like the most correct one um let's see what what else we've got just in case one of the resources has been delayed which is now impacting the project schedule it's happening now it is a project issue exactly right the receiving organization tells you of a regulatory change impacting scope that could happen in the future we're going to put that in our risk Reg register because it is a risk it's potentially it could happen in the future the team have estimated the activity durations but noted they

are only accurate with their current expertise they are using assumptions so making sure that we note those assumptions in the Assumption log and let's check those answers they have come through as correct wonderful stuff page 185 under logs and registar uh yeah I think that's correct pinbot guide 7th edition 2021 if you want to check that out for yourself and that was actually the last one in this session so wonderful stuff you've done an amazing job we got this through that it the time just flew and you know what they say about that is time

flies when you're having fun I know I was having fun and I hope you were too but at the very least I know that you are doing the right thing to prepare for your PMP exam and also to improve your life because project management is such an important skill especially when you're delivering change or managing teams it is something that's truly going to take your career to the next level and really really improve your life I know you can do it I truly believe that you can pass the PMP exam and I'll see you in

the next set of questions all right checking outcomes a significant number of changes uh happening to the project requirements and scope okay so what's the scenario that's leading to these issues if we've got a lot of changes to the requirements and scope stakeholders disagree with the project objectives uh let's put that in there for now and we can always change it review the issue register for individual stakeholder challenges and use surveys and interviews that's going to be disatisfied stakeholders and we want to look at the issue register because who's raising the most issues and who's

raising the most risks to our project or to the project they're possibly the most dissatisfying stakeholders so we can start there it's such a a good way to do it project team applies critical thinking and interpersonal skills they are a high performing team the project team adapts to changing situations and is resilient in the face of challenges oh gosh that actually could be oh both of those are are the same they're very very similar project team apply critical thinking and interpersonal skills maybe that's leadership and the other one is high performing I think those two

are so similar I'm just going to have to take a gamble there and see how we go okay that's correct so pbot guide 7th edition page 15 under checking results stakeholder and checking results team so those are really great things to to check just for project scenarios how did you guys go with that one pretty good pretty good way for us to start off all right agile and predictive change methodologies if a project uh if a product owner reprioritizes the product backlog and adjusts the product road map that is change in an Adaptive way of

work or an agile way of work if a change request is logged as per the process in the change management plan that's change in a predictive way of work project scope changes updated in an Adaptive project um not sure it's seems like this is the only one left we would update it on an information radiator yep that seems fair enough and changes communicated to the correct stakeholders in the ways that they prefer we will check our Communications management plan let's double check these results and wonderful stuff all right these are pretty good sort of scenario

based ones so quite good to go through and another one so let's see how we go is the project supported by the organization and allowed the resources to proceed we're going to need the project Charter to initiate our project is the project on track to realize the intended outcomes in the time frame that we planned them we're going to need our business case and the benefits management plan that shows us who tracks the benefits how we track them what what time frame do we want to realize the project benefits in so that's pretty good does

the Adaptive project team understand the product requirements uh uh I'm probably going to go with produ with stake uh with backlog and user stories so with the backlog and the user stories that's where we see the product requirements and Sprint reviews is when the stakeholders accept and are satisfied with uh the project deliverables so there we go let's quickly check and that has come through as correct really well done let's see what we've got next measuring stakeholders asking project team members to rate their agreement with statements such as I feel my work contributes to the

overall outcomes we're sort of measuring their engagement uh or uh how they're feeling about the project if it's just a question we might be doing that with a survey uh if we we can always change that if we need to high rates of unplanned team turnover if we have lots of absenteeism or lots of turnover in the team we have low team morale they're not engaged and that can really affect the speed of our project measuring the degree to which a stakeholder or customer is willing to recommend a project or a product to others that's

our net promoter score we ask How likely would you be to recommend this to a friend on a scale of 1 to 10 and I think 7 to 10 or or 8 to 10 are classified as promoters of the item and 6 to Z is a detractor I think so you can definitely check me on that one but but uh but the idea is that we want more promoters than we have detractors for our product to track how stakeholders are feeling using colors numbers or emojis we can use a mood chart and let's check there

we go pinbot guide seventh edition under page 103 measures stakeholders so that's a really really good thing good thing to check in with our project team uncertainty many interconnected influencers that behave in diverse ways reframe or disconnect parts of the system okay I do love vuka or volatility uncertainty complexity but what is this one many influences this one I think is complexity because it makes things complex and we decouple it to make it more simple exactly so an event that if it occurs has a positive or negative effect on one of the project objectives that

is risk because we can have uh threats or opport unities in Risk the probability or the possibility for rapid and unpredictable change use Alternatives and have Reserves at the ready that's volatility and it's giving us good ways to handle this by the way reframe or disconnect parts of the system use Alternatives uh and reserves now the last one a state of being unclear or having difficulty identifying the underlying cause of events use prototypes and experiments to get rid of ambiguity exactly right there we go that I feel like that was just a short master class

in dealing with vuka uh which is really cool so page 119 to 122 uncertainty in the pbot GU 7th edition if you want to check that out for yourself I thought that was quite good all right estimate ranges and this is so important when we're first doing an estimate uh especially for a customer or for our stakeholders we want to start uh by giving a range of minus 10 no hang on what's the biggest one -25 to + 75 and that's our rough order of magnitude now what have we got next the preliminary estimate minus

15% to plus 50% as we're getting closer and things are becoming more defined we can uh bring in our estimates the budget estimate typically what we would uh put into a budget we're going to say it's -1 to + 25% and we can often uh begin our project at that point now the definitive estimate if we're getting really really close and we've got more information - 5% to + 10% and the final estimate when things are actually done and paid for we have no more wiggle room at all it is now 0% it is the

final amount let's check it out and there it is excellent that was quite good I do enjoy that those estimates so that's really good to go through all right nearly through this section adaptive versus predictive predictive what do we have we have a it's not fixed cost it's variable cost because in agile it's agile where we have fixed cost we have a fixed team for a fixed amount of time and they just keep uh releasing features until the money and the time Runs Out in agile we're going to have servant leadership and in predictive we're

going to have directing leadership a little bit more of a command and control uh in predictive we're going to prefer written communication so system documents and requirements documents but in agile we prefer face Toof face communication now in predictive we're going to define the requirements at the beginning and in agile we can progressively elaborate those requirements let's double check and see how we went excellent work that has come through how did you guys go with that one I do like the agile and predictive questions and I also like Risk so you know that's great you've

got to whether you like it or not we always have to deal with risk on our project so let's get into this one Ben is numerically analyzing the effect of uncertainty on the project objectives he is using quantitative analysis he's quantifying the risk Michael is defining the degree the type and the visibility of risk management activities for the project uh Michael is planning risk management with our risk management plan how are we going to manage risk Sarah is finding and categorizing individual project risk risks as well as sources of overall project risk Sarah is identifying

risk and Isabelle is developing options to address project risk exposure Isabel is planning risk responses let's double check and see how we went and that is correct excellent page 113 in the process groups practice guide if you want to check that out for yourself plan risk management very very good to go through now the last two the critical path everyone loves the critical path and what is the critical path it's the shortest time we can complete our project in based on the sequence of tasks that we have to do so if task B is on

the critical path and is delayed by 3 days okay so it's on the critical path we don't want to delay it but it's delayed by 3 days what are we going to do oh goodness me these are okay I might need to read a few of these but we could use lead time we could lead it forward so we could say that um we could use schedule crashing or fast tracking as well we're not going to use lag time because it's lagging behind we want to bring It Forward we want to lead it forward so

task D is on the critical path and has 2 days of available float so it has some wiggle room and we could actually uh we could actually bring that back we could lag it behind because it has 2 days of available float so we can use our lag time there task A and B are performed in sequence but can be done in parallel you know what this one is instead of sequence now we're doing them at the same time we are schedule fast tracking there we go now let's see what we've got for these two

the team bring task C forward to start it while task D is still being worked on that is our lead time so they're they're using lead time uh or they have lead time available so they can lead it forward and that means we're going to use schedule crashing to uh make sure that that task is not affected on the critical path and let's have a quick check and there we go page 262 the critical path method in the process groups practice guide amazing job guys and nearly there we're up to the last one scope and

quality if we ensure that the project outputs are complete correct and meet customer expectations I see what's going on here because these are always uh these are often confused so validate scope versus control scope versus control quality these are often confused in a project so when we're when we're validating the deliverables that is validating our scope the customer or the project sponsor will say yes this is what I wanted and I agree that these are ready to release oh no hang on the formal acceptance of project deliverables that's validate scope now if we're ensuring that

the project outputs are complete and correct that is controlling quality there you go see it tricked even me and that's what happens it's uh these things are often confused so we're controlling quality because quality is the uh amount that it meets customer expectations so uh that is the key word there the process of reviewing and approving changes to the scope is controlling scope and monitoring the status of project scope and changes to the scope Baseline oh goodness me changes to deliverables and project documents oh these are all quite tricky maybe that one is just perform

integrated change control and if we're monitoring the status of project scope and changes to the scope Baseline that's going to be control scope let's have a look I think we've got this and we have thank goodness that's wonderful to hear page 165 perform integrated Change Control in the process groups practice guide now really quickly there is a bonus question if you made it this far you can leave a comment and say that you made it to the bonus question 11 a magical number that will give you good luck for your exam and it's around the

my Bri it's just another Myers Briggs one just in case you get this on the exam and it'll give us some nice tips because uh enjoying social interaction that that's our extrovert if we're solitary that's our introvert if we're using senses to determine reality and the reality of the situation that's sensing if we're using our intuition to find patterns that's Intuition or n if we're logical and impersonal that's probably think feeling if we're using our feelings and emotions that's f for feeling judging with firm fast decisions is J and perceiving with flexibility and and seeing

all of the different options and being adaptable and uh and flexible that is p so just a really quick recap bonus question right at the end and I have to commend you on such an amazing job getting through all of these Dragon drop questions you've done a truly incredible job and with this practice and with this study and with improving yourself every day I truly believe that you can pass the PMP exam it's definitely something worth doing as projects are delivering value for organizations every single day we're making change and doing great things it's really

really worthwhile and it's worthwhile having a way to understand how to manage those projects it's so so important you're doing the right thing I can't wait to hear of your success when you do pass the exam and you do get that pay rise with your PMP but until then I'll see you in the next video and bye for now [Music]