Transcript for:
PMP Exam Preparation and Strategies

[Music] hi everyone welcome to this set of 150 PMP questions and answers the questions and answers have come directly from the pmbok guide 7th edition making this a great way to prepare for your exam or just a great way to brush up on your project knowledge or your project management information and especially because these questions are scenario based you'll find that they they appear as real life scenarios so it's a great way to just check and see what else is happening out there in the real world and how it matches up to that latest pmbok guide this is an absolutely fantastic way to prepare for your exam and I cannot wait to share this time with you by spending this time preparing I truly believe that you can pass the PMP let's get into the questions you have been assigned to a new project where the workers behind schedule and the team are not working together well the team is relatively new and conflicts are arising team members are blaming each other for the work not done and some people are not showing up to work on the project at all okay well gosh what will you do next so it's hard to have a project if we haven't got people coming to work with us and sometimes this is hard because we've got you know we may not own these resources we may be borrowing them from certain you know functional areas in the business or an organization so what are we going to do here okay meet with the functional manager of that area to agree on team members time requirements um you know that could work but also conflicts are arising and the team is also relatively new so you know how are we going to manage that I think there's probably better answers there meet with your team to set a charter team charter and Define roles and responsibilities that one sounds actually quite good because then we're getting into what they're responsible for what their role actually is sometimes that's unclear and also a team charter how is the team going to work together we're starting to move into an agile you know agile terminology here so the vision you know the escalation points uh team roles team responsibilities I actually think that's a pretty good one let's see what else we've got meet with the project sponsor to gain additional funding for resources who can work together you know what even if we change the resources it's not a hundred percent guaranteed that they're still going to work without conflict projects are difficult situations and so you know conflict is going to arise it's up to us to manage it as project managers it's part of the wonderful job that we have at last escalate the issue to the steering committee wow escalating it even further as soon as possible as a project risk okay well it's already happening so it's more of an issue I think you know probably it could be it could be a risk you know for future scope or schedule issues maybe but I don't think we really want to escalate this to the steering committee without managing it first and we manage it by answer B I think let's go with that there it is the standard for project management asks that we create a collaborative team environment including team agreements definitions of roles and responsibilities formal committees tasked with specific objectives so really specific things they need to do standing meetings that regularly review a given topic so all of those things create a collaborative team environment page 28 and 29 in the book guide 7th edition under creating a collaborative team environment how did you guys go with that one first one there's many many more it's going to be fun and also I think that wasn't too bad so I think that was pretty good start let's see what we've got next you have recently completed a project for a new product and have been asked to manage it after its release to keep it relevant in today's Marketplace sounds like a product owner role or a product manager but perhaps half of your existing team are rolling off to other projects okay so we're on a project now but we need to keep the product relevant so we need to keep releasing features potentially to make sure that it's up to date what are we going to do next the project budget is nearly depleted I don't think we'll manage this as a project this is probably something that we go into more of a stable team or you know business as usual and then release continuous features I think maybe again moving into an agile sort of way of work here let's see what options we have create a business case and a project Charter for your project sponsor to approve that would be if we had a specific project in mind but I really think this is more about product management here retain as many of your current project staff to continue work on the product that could work but how are we going to do that we're going to need money here you know these things just don't magically appear people also may be rolling off the project as as they say and there's no more money to pay them so unless we can pay them with love I don't think that one's going to work raise a change request for your current project and add scope and continue making changes to add scope and continue making changes change request again um probably not the best and I see I probably answered D I think is probably where we're heading though secure funding for a stable team that's what we were saying then use current research research to form a suite of projects to improve the product so this is where we're continuously releasing features to improve it over time and we have a stable team so they become really really good at that particular product I think we're going to go with answer d all right there it is this question is referring to product management hey that's good we got that file product management involves the integration of people data processes and Business Systems to develop or maintain a product or service throughout its life cycle and of course you know over time it may eventually you know finish the product may be retired and and then you know then we can roll off and move on because we're not needed anymore under page 17 to 19 under product management considerations in the promo guide seventh edition if you want to check that out for yourself how did you guys go with that one I thought that was really really good let's see what we've got next you're delivering a critical change and several key stakeholders in your organization have added seemingly unnecessary steps for you to take with extra approvals reports and meetings they're also restricting the people you need from working on your project in a larger capacity so again this is because if we don't own those people necessarily uh and they're coming from other functional areas in the business sometimes we don't have 100 control over those people and they may not end up working for us full time what will you do next so we have to manage that we have to manage these things and this is great for the real world as well go directly to the people you need to avoid extra back and forth with the stakeholders so if we go directly to the people that we need they may agree to come and work for us you know we could probably convince them but then what happens when their boss finds out and their boss you know that's probably going to be a more difficult situation to manage because now we've gone behind their back so you know I think you know that's probably the easiest way but it just won't work in the long run because of that reason raise a risk in the risk register on the lack of access to sufficient resources sure maybe yeah we could raise a risk I mean that's a low maybe though if we're just raising a risk how are we going to manage that risk so you know maybe there's a better way here communicate more often with the stakeholders and gain a deeper awareness of their ideas and situation okay communicating always good it's a large part of project management is this going to solve what we're after here so you know they're restricting people you know what communicating what does communicating do it helps with people's engagement this could be an issue with our stakeholder engagement actually and so if we're communicating more finding what uh what their ideas are and their situation is maybe there's good reasons for them restricting the people or slowing down the project or maybe they just don't feel engaged or involved enough so communicating always helps there that's a high maybe for that one let's see if there's a better one just in case show your stakeholders the resource assignment Matrix and project roles and responsibilities I think that also could be good so then we're just sort of saying look here it is you know this is what you agreed to but the thing is they may agree to it but they still may not do it because they're not engaged so I think if we're gonna we could win their minds by this for example we can force them to do it but if uh what's that saying are those convinced against their will are of the same opinion still so I think if we haven't won their hearts you know from that perspective we need to communicate more often let's go with that one I think answer C okay this question refers to the principle of effectively engaging with stakeholders stakeholders may add steps or requirements or restrict team members if they're not engaged appropriately communication and awareness of their ideas through knowledge sharing and regular meetings ideally face to face may help and this is directly from the pilmont guides 7th edition as well you've got page 32 and 33 under effectively engaging with stakeholders all right well so that was a little bit trickier and a bit of the soft skills there that we need on our projects let's see what we've got next you're managing a project team made up mostly of men recently Jane was hired for her High expertise High expertise in the brands that make up your industry Okay so we've got mostly men and now we've got Jane okay well I mean what's going to happen here hopefully nothing crazy but you notice she has been left out of some key meetings and others are overlooking her opinions you also notice she is paid significantly less than her male colleagues what will you do next wow okay tricky situation this one and I think for us as a project managers you know how do we manage this as managers and leaders you know we want to go for for fairness I'm pretty sure so that things don't you know come back and bite us down the road and that people stay engaged and they see that you know we're acting fairly as well I wonder if there's an option here so make steps to update her pay to the same range as the others on your project and ask her opinion and advice specifically during each meeting along with others in your team well that covers pretty much everything doesn't it so I don't know that one's pretty obvious I think if we can act in a you know that's quite a fair manner I really like that one let's see what else we've got just in case take the lower pay as a win for your project as it will help keep costs low and her colleagues don't need to know wow okay you know what and you know what this will happen in the real world as well but what happens when people find out engagement goes through the floor and and then people leave and they take all that all that product knowledge with them at the same time and then you have to hire someone you trust me it just you know it's not the best scenario definitely a no for that one for those reasons you have to look at the bigger picture here ask Jane to write down her knowledge of the industry just in case she leaves um you know I mean yes we would do that anyway I think I think it's good to capture some of that information but are we still acting fairly I would prefer I would prefer to still act fairly here so no need to rock the boat this is just how people work in this industry again you know some people will just carry on with the status quo in the real world that will definitely happen but for us if we're going to be true leaders true managers let's go for the equality here I think let's go with answer a okay this question is on integrity and stewardship this is good we should have respectful engagement of project team members including the compensation access to opportunity and fair treatment and by the way this can happen the opposite way as well you know um you know it doesn't have to be a man a man woman thing this can be just someone who's not assertive enough to ask for a higher pay you will see this happen all the time so just something to be aware of and when people find out that it's not equal you know then that engagement really does plummet and that's what we don't want we want things to to stay high engaged with our team members so that's really good page 25 be a diligent respectful and caring Steward that's a really nice principle okay let's get into the next one during one of your work group meetings working group meetings a stakeholder raises the concern that the product you're working on will be discontinued in the next five months you are not aware of this and your project budget has already been approved until all the scheduled delivery which is in five months also okay hang on discontinued in the next five months and we're delivering a project at that five months Mark as well that's probably not a good thing uh what are we going to do next of course another tricky situation for us to manage using our project management skills let's see what we've got keep the project going as it is the discontinued product isn't your responsibility and you know what maybe it's not maybe you know maybe it's someone else's responsibility but also that stewardship thing again you know can we do the right thing here so let's put a a very low maybe maybe a quite a no for this one set a meeting with your project sponsor to share the information probably good and a recommendation to terminate the project wow that's quite full-on um I mean I guess that makes sense because it's just why are we even delivering this it actually I think that actually does make sense let's put a high maybe for that one for now and see what else we have just in case change the scope of the project to meet a different product hang on so your project can remain relevant you know what projects are usually about you know one one set thing um they're you you kick off a project for a particular reason for a particular Improvement or a particular change and for us to just completely change that halfway through using the same money I don't think that's really going to work we probably have to kick off a new project ask for additional funding to see if you can improve the product instead of discontinuing it and again look I mean improving it I think an additional funding there's a whole lot of rabbit holes that we'll have to go through for that and also it may not work because it actually is just being discontinued we would probably terminate the project and start a new one based on a different set of rules and maybe a different product or maybe you know a different scope that we're looking at here I think under this set of circumstances let's go with answer B okay and these are a little bit tricky actually so this question is about delivering value the primary motivator for a project exactly if the project is no longer aligned with the business need or it seems unlikely to provide value the organization may choose to terminate the effort okay so that's good good news and remember that's directly from the PM box 7th edition page 35 focus on value so that's a very good thing to know and understand definitely makes sense when I see it like that so how did you go with that one I think a little bit trickier there but still pretty good and we're halfway through this section so this is really really good let's see what else we've got you've collected the requirements for your project and you're creating a scope statement and the work breakdown structure scope statement is your acceptance criteria and a just a statement about the scope and the work breakdown structure is breaking down high level features into smaller pieces and then ultimately to work packages that people can work on during this process you notice some functionality in your database system that will help a different project that you're aware of in your project management office Okay so we've got our project another project and some of our scope over here actually could help this one over here so what will we do next wow okay wow this is really good place the feature in the other projects backlog and ask them to prioritize it as soon as possible so we've done this research on the on the feature we just hand it over to them and then they prioritize it I mean that's maybe maybe we could do that I wonder if we can just hand it over like that do they even want to do it is it even on their scope do they have the budget for this sort of thing so maybe there's more to this tale raise the functionality in your risk register as a threat with the response to mitigate I don't think this is a threat this is more of an opportunity probably I wonder if we've got something in here so definitely a no for that one add the scope to your project and complete it as soon as possible do we just do it well if we do it you know it's not uh within our product or what we're working on so our team is not going to be the experts on this it's probably better if you know if the team who are the experts in that product actually completed because they'll have the resources specific to that product so I think that's a no for that one as well for that reason raise the functionality in your risk register as an opportunity okay there we go with the response to exploit so we're exploiting the opportunity probably a good thing and meet with the other projects team and sponsor to discuss I think that actually could be good so I think if it's between that one and just throwing it into their backlog I don't think we have the power to put it into another person's backlog the steps that we would go through first are to talk with them so we'd say hey guys this is an opportunity we can exploit this uh you know and you know is this something that you're able to work on I don't think we're just going to throw it over the fence we need to talk about it first and I think for that reason let's go with answer d excellent systems thinking wow okay I didn't know we were going there involves taking a holistic view of how project Parts interact with each other and external systems projects operate within programs so you've got programs you've got projects underneath that and you know then you've got BAU layer under that so operations and all of that sort of thing and so small systems affect all of the larger ones finding a previously unknown opportunity the next best step is to make it known and to exploit that opportunity there we are in the Pumba guide page 39 responds to system interactions systems thinking page 129 and opportunities there in the Puma guide seventh edition all right that's quite good to know let's see what we've got next you're working on a higher profile project several high-ranking senior Executives want to take the credit for this initiative while limiting the impact to their own resources this has led to several conflicts and a scope statement that is unclear leading to a risk of project failure what will you do next okay it seems pretty straightforward another difficult situation obviously maybe something around engagement let's see what we've got create a scope statement yourself to avoid further conflict okay I mean we can definitely do this but then what if no one agrees to it and the customers that we're delivering to if they don't accept those deliverables then we're in trouble so probably a no for now on that one facilitate a discussion with the executives as a neutral third party I like that and again this is more of that you know facilitator role that agile terminology that we will see in the PM box 7th edition focusing on agreed project goals that's definitely a high maybe for that one I think that's pretty good we'll see what else we've got just in case limit your project resources to the executives until they can agree on a Way Forward I mean maybe but also if we've got our project resources that maybe they're sort of still costing money and still costing project funds so if we're not using any of those resources then we're also wasting the project funds so potentially not a good thing I think probably a no for that one escalate the issue to the project steering committee and ask them to resolve the problem again for this as project managers we should be managing this as best we can until we've exhausted every single option and then if we need to escalate it then we can so we'll put a no for that one for now I think out of all of these the best one becomes option b let's see what we've gone on fantastic leadership is not the same as Authority when senior managers suffer conflict over priorities neutral facilitation helps more than detailed recommendations so we could again we could come up with recommendations for these guys and say okay here's what we're going to do but then again they haven't agreed with to it it hasn't come from them so they're not really engaged with those ideas if we're facilitating and extracting those ideas from them then potentially we have a better outcome leadership Acumen involves focusing a team around agreed goals generating consensus on the way forward so getting their inputs negotiating and resolving conflict and more all very tricky things to do all these soft skills that you will need as a project manager and Page 42 under demonstrate leadership behaviors a wonderful wonderful thing in the promo guide 7th edition fantastic how did you guys go with that one I think these are really really good let's see what we've got next there's only three to go in this little section you're managing a project where the majority of the product has been planned up front but an external system is needed from a vendor in partial pieces where the requirements are unclear half okay so that sounds like agile that one doesn't it so we've got agile but we also have upfront planning so we've got our predictive or our waterfall so we've got a few different methodologies here which one will we choose or can we do a hybrid approach uh half of your stakeholders want to use a waterfall approach and the other half are advocating for an agile approach what will you do next let's see what we've got I think if we've got both of those I think we could probably merge those two and create a hybrid approach and that's quite a common thing to do so let's see what we've got use an agile methodology the fixed scope is low risk and you can capture the changes using agile I think it's probably a better option use a waterfall methodology okay so it's either one way or the other and ask the team to plan the uncertain scope better uh again I mean maybe a medium for that one but not great there's probably a better option here proceed with a hybrid method to start and with pre-planned scope but agile ceremonies that promote feedback I think that's probably one of the better ones again it's that hybrid approach we can combine them here because we've got two differing situations that need differing ways of management use a combination of waterfall and agile to capture all the requirements and keep stakeholders happy I think this is really similar to 2C except C uses the specific terminology of a hybrid method and hybrid is where we are combining waterfall and agile but using it only where it's applicable so I think for all of those purposes let's go with answer C all right excellent this each project is unique and success is based on adapting to the unique context of the project to determine the most appropriate methods the tailoring approach is iterative in nature okay wow so we might actually change our tailoring approach over time you know what we include or what we don't include is it more waterfall is it less waterfall for example and this project requires a hybrid of waterfall and agile with the option to improve it over time I think that's actually quite good so page 44 to 46 under tailoring in the pmbot guide 7th edition how did you guys go with that one so that's a really good one to be aware of project life cycles when to choose them lots of hybrid stuff in the PMP exam as well excellent work all right only two to go you're doing great you're working on a project where senior users have been testing the product as parts are released they have found some missing requirements and defects okay good their manager is worried that the project won't deliver a product that is fit for purpose without defects and within the time frame needed what will you do next Okay so we've got some defects we've been testing it uh now the manager is worried about those defects I think how do we manage this form some of the testing yourself to ensure a quality product we may be tempted to do this but I think the value in a project manager is where the conductor of the orchestra so you need a conductor to keep everybody on track and to keep that rhythm going basically so everyone has their little sections trumpets saxophones xylophones percussion you know woodwind all of the rest of it and they are experts in their area I don't think we need to do the testing I guess that's the point there help every team member focus on quality from correct acceptance criteria to a developed and tested product that's a very broad answer maybe I mean it definitely makes sense yes focusing on Quality quality is everyone's responsibility in an agile team you will hear that said a lot so let's put that as a high maybe for now limit testing until the very end of the project so you can do it all in one go when the product is completely ready I think for this one you know this may not work because again in an agile project we want to test at all levels unit testing on our story cards system testing has a for the system as a whole user acceptance testing with the user's eyes on it and then even regression testing where we're testing to see if anything else is broken when we've released a certain part so I don't think we necessarily just want to limit it to the end here increase the testing on your project and add more testing resources so no defect goes unnoticed potentially but again may not be the best answer I think actually looking at that I would choose B over D because now the whole team is focusing on Quality quality is everyone's responsibility we're not just throwing resources at it we're actually managing it like we should I think let's go with answer B excellent work all right quality focuses on meeting acceptance criteria for deliverables and satisfying stakeholders expectations on product requirements quality is everyone's responsibility in an Adaptive or agile project and there you are you will hear that a lot so if there it is again page 47 to 49 in the pimport guide seventh edition build quality into processes and deliverables that section there and you know what else is really really good quality is the last question that you've got in this section and the way that you've gone through this amazing work you're doing a great thing for your PMP exam preparation let's see what we've gone you are working through the risk assessment with your team who are having trouble coming up with ideas for risks you decide to give them some guidance on types of complexity that might affect your new product what will you do next okay risk and complexity uh two wonderful things that you will see or not see you know that will definitely be there regardless of whether we can see it or not in your project ask them to brainstorm qualitative and quantitative risks yes that could probably work from a risk perspective but what about the complexity behind that so what else have we got ask them to perform the five wires and Ishikawa analysis that is root cause analysis to find the root cause of a problem probably not necessarily related to what we're doing here ask them to brainstorm around possible unwanted human behavior system Behavior ambiguity and Technical Innovation impacts so that way we're Gathering risks but we're Gathering risks based on all of these things which are types of complexity and volatility so you'll see vuca volatility um I don't know what that one is uh gosh now I've forgotten it uh complexity ambiguity that one will come to me in time I can't remember now if someone remembers put it in the comments save me please and last one ask them to perform a retrospective uncertainty there it is to discover what isn't working well and what still puzzles us if you beat me to that in the comments please give yourself a thumbs up at the end of your comment well done and I don't think we're going to go with answer B either I think D I think C is definitely the best one there from that vuca perspective I absolutely love it let's choose that one and there it is complexity is often the result of human behavior system interactions technical Innovation uncertainty and ambiguity complexity can be introduced by advance or conditions that affect our value our scope stakeholders risk and more which is why working on projects there is never a dull moment we always have to deal with these wonderful things and having a toolkit to do that really really helps that's where the PMP is just the best thing to do for your career page 50 51 navigate complexity and you made it to the LA to the last bit of this little section well done I absolutely congratulate you for doing that and also I truly truly believe that you can pass the PMP with this preparation and with all the work that you're putting in keep working at it every day it's definitely a worthwhile activity and it's definitely a worthwhile thing when you do get your PMP I truly believe that you can do it you're working on a project where you discover a certain negative risk with a potential impact of two million dollars Okay negative risk impact that's good to know you meet with your project stakeholders who determine that this is within their risk appetite provided that you meet a risk threshold of 10 hmm interesting what will you do next okay risk threshold I'm pretty sure this is the threshold around the impact so if we've got two million dollars so we've got 2 million and we want a risk threshold of 10 so they're happy with it they're fine with that but it still has to meet within two within 10 which is an extra 200 000 here or a minus 2000 which would be 18 1.8 million I think so plus or minus 200 000 which is 10 of 2 million I think that's what we're going to go with here I you know let's see what what options we have note the acceptable risk level as a threat of two hundred thousand dollars which is ten percent uh tricky but I don't think that's us for now note the acceptable risk level as a threat of 18 1.8 million to 2.2 million which is a 10 variance I think that definitely matches up here and we can potentially go with that note the impact as outside the acceptable risk level of two million dollars I don't think I mean they're happy to accept it so I think we're okay there note the impact as an opportunity of two hundred thousand dollars as well which is ten percent again so no I think those ones we can discount and get rid of I think we're going to go with answer B here all right good work risk appetite describes the level of uncertainty or risk your stakeholders are willing to accept so they're willing to accept this and the risk threshold is the measure of acceptable variation around an objective that reflects the risk appetite in this scenario a 10 variation around 2 million is 1.8 to 2.2 million and we've got page 54 in the pimlicine seventh edition under risk directly if you want to check that out for yourself all right wow good one to start with risk you know it's always going to happen on your project so that's always good to know let's see what we've got next a risk has been rare more risk that's just what we needed a risk has been raised in your project around insufficient building materials one risk response assigned to the functional manager suggests to use a brand new material which has not been fully tested before in a building project so that actually could be even more risky maybe so we've got a risk around insufficient building materials but now we're suggesting a brand new material that hasn't really been tested yet half of your stakeholder group are happy with this risk response but the other half are not and refuse to sign off on it what will you do next okay uh if our if the stakeholders that need to sign off if we've still got 50 not signing off on it then we probably can't proceed so what other options do we have here suggest a quantitative risk approach to give a more accurate Financial impact as you will know from our other videos qualitative risk is our impact and the likelihood of happening and then we usually multiply those together to get a risk rating but it's a subjective rating usually quantitative is more your in-depth analysis scenarios and Monte Carlo Monte Carlo analysis that sort of thing big simulations and you know big Financial simulations usually as well anyway all of that does say I don't think we need to do that just yet suggest they proceed with the proposed risk response and ensure it is followed through well we can't force it on them because 50 are disagreeing as well so maybe a no for now let's see what else we have just in case suggest a different risk owner as an executive may have more power to respond to the risk I mean again someone could force this through but if 50 of our stakeholders are disagreeing uh there may be a reason for that and if it's a brand new building material things could go wrong here so let's put a no on that one for now as well suggest a different risk response as they should be timely cost of oh this sounds promising timely cost effective realistic and agreed to by relevant stakeholders and all those things are for a reason cost effective and realistic I think in this case um yeah it you know and people are disagreeing for that reason I think let's go with answer D I really like that one okay excellent this question refers to risk responses risk responses should be appropriate And Timely uh to the significance of the risk cost-effective realistic within the project context agreed to by relevant stakeholders and owned by a responsible person here's the best answer and we've got page 54 in the promot guide 7th edition under risk again if you want to check that out for yourself all right excellent work more risk I wonder how much risk we're going to have here but that was actually very good to know and a good way of managing risk in our project what have we got next your project is starting to go off track due to a large amount of uncertainty in the requirements and resources and you know what this will happen all the time in the real world sometimes we need to come in here and help manage it that's why they need us to help get clarity on that scope and the requirements and you know we need to gather that from our stakeholders at a significant cost you manage to rein in these issues okay however your project management office would like you to brainstorm ways to improve with your team so that it does not happen again that makes sense what will you do next so we're brainstorming with our team okay what are we going to do here ask your team to increase the project contingency reserve to allow for these impacts um I think there's probably a better is there something around problem solving I think is probably what they're asking us let's see what else we've got uh let's put it low maybe for now ask your team to change the project methodology from waterfall to Agile and you know what this will happen in the real world as well people will say okay we just need to change the methodology and everything will be solved unfortunately life still happens and whether you're using waterfall or agile or either one you know we're still going to be faced with a lot of this complexity and uncertainty that we have to manage as project managers with our project management toolkit from the Puma guide wonderful wonderful thing so I don't think I don't think that's our one yet ask your team to use short feedback loops okay continuous Improvement and transparent planning oh so all of those are agile tools as well uh short feedback loops to get feedback and improve continuous Improvement transparent planning so that you know people it's all visible what we're doing so that everyone can see at any moment whether we're on track or off track and what we're delivering I think that's actually quite a good one unless there's a better one that might be our one ask your team to check their work twice before sending it to the next part of the process I think you know that could be one option but C is definitely a far better option with you know better things in there as well and more and better things so all round I like that one better let's go with answer C excellent work all right a project team needs to embrace adaptability and resiliency with methods such as using short feedback loops continuous learning and Improvement regular inspection which is sort of like this and adapt adaptation of project work diverse project teams transparent planning using prototypes and more all of those are great tools by the way so really really good to use in your own project management career page 56 under Embrace adaptability and resiliency so really really great stuff all right how did you go for that one I think that was quite good definitely leaning a bit more agile here as well which is very nice let's see what we've got next as your project progresses many of the business stakeholders are starting to voice their concerns to question some of the changes and even miss key meetings while trying to sabotage your efforts what will you do next I think we've had similar ones before and this is around that engage engagement communication engagement I think let's see what we've got uh oh and I can already see communicate here which is this could be you know the one that we're looking for already communicate the vision and benefits for the change clearly along with the impact to their work so communicating more communication will definitely help and also listening very clearly to what they need so communication goes both ways so that's a definitely a higher maybe for now let's see what else we have create an impact over influence chart to determine who should be engaged appropriately uh I mean that's definitely also a good thing but then it's not going to help with the missing key meetings or you know people questioning the changes I think we need to communicate those things first so still a for me escalate the matter to your project sponsor and arrange for different stakeholders again you know sometimes sometimes we can but often we can't just replace our stakeholders they're already embedded in an organization we have to work with them and do the best we possibly can so that's a no for now map the current state and the proposed future state of the change for the stakeholders so that's sort of working with them and problem solving with them but what about all of the other things so you know I think again oh that actually actually quite a good one but I still think for engagement communication is more of the key let's try and say it's between answer A and D let's try a okay good yeah very tricky could have been either of those they're pretty good this question is on change management which is a structured approach to transitioning groups to a future state too much change or a lack of understanding can lead to resistance and change fatigue methods include communicating the vision goals and benefits of the change early along with the impact to work processes so we've got page 59 in the pinball guide 7th edition enable change to achieve the envisioned future State fantastic stuff and change management has a bit of a bigger place in the Pumba guide seventh edition so it's becoming more prominent in today's projects which is good all right let's see what we've got next nearly halfway through you are analyzing your stakeholders through an impact over influence chart and have found more than 100 different groups of people and over 3 000 impacted stakeholders other parts of your project are starting to fall behind as you try to keep up with a large amount of people what will you do next okay so lots and lots of stakeholders lots of groups of people some people are falling behind because we're trying to keep up with everyone can we prioritize these so this might be the best way to move forward here I think let's see what options we have ask your project team to engage different groups of stakeholders so everyone is covered yeah wow that could potentially work it's not a specific thing that you'll find you know just sort of splitting up the work but it definitely makes sense let's see what else we have just in case clearly prioritize the stakeholders okay well so there's our prioritization that could be our one then engage and communicate with the highly impacted and influential groups early and often and there's that communication again as well so you know that's probably one of those keys keys to change management like we were seeing before that's definitely a good looking answer that one we'll see what else we've got just in case monitor the stakeholders for signs of stress and respond to the group's most stressed about the project wow that's also quite good that might fall into like a prioritization method as well so potentially prioritizing is still our best overall answer with that keyword in there so let's see what else we've got just in case create a SharePoint page for the changes that any stakeholder can gather information from any time so they can pull information um you know whenever they need it again that's another really good approach that one so we've got lots of good options here but I think the key word we're looking for is to prioritize these things so based on that let's go with answer B excellent all right this question is about engaging stakeholders the process includes identify understand and analyze prioritize engage and monitor your stakeholders where you have too many to engage effectively prioritization is the key impact and influence are two ways as well as power beliefs expectations and proximity to the project power interest and more so again you could make up ways or things that fit your circumstances to prioritize so but all of that to say yeah that still becomes that's that keyword that we're looking for and we've got page 11 and 12 under stakeholder engagement and prioritize and engage in the promot guide 7th edition wonderful work and that means we're halfway through this little section as well which is even better you're doing great keep going guys five to go if you want to keep continuing with this and these are just starting to get good so it's good preparation for your PMP exam you're managing a project which communicates to the customer using mostly pull communication so far just like we were talking about before so that's very timely when monitoring the engagement of your stakeholders you notice a trend that they are not clear on the impacts or benefits of the project okay so again we're seeing lots of communication here which is really really good you decided to add push communication to your communication plan what will you do next oh well this seems fairly straightforward it's basically about what is push communication so we know what pool communication is we've got a site where people can get information from any time they want to they can pull that information what is push communication we're pushing information to them with an email or a meeting or a telephone call or you know however we're doing that we're pushing it out to them they don't have a choice whether they get that information or not let's see what we've got create a web page you using SharePoint with all the project information that your stakeholders can see that's pull information push more funding for your project on your project and communicate this to the project sponsor while the keywords are right you know the sentence doesn't really make sense so you don't really need more funding for this and we don't need to communicate it to our project sponsor either so let's put a note for that one for now push your stakeholders to engage in more two-way communication again we've got the keywords here push your stakeholders but it's not quite right is it two-way communication again sounds good but doesn't really fit I hope D works for us because we're running out of options here um send okay send a weekly email to stakeholders with a project update including the impacts and benefits well that sounds really really good and also it's the sending that we're we're doing we're pushing that email out into the world that's definitely the one let's go with answer d excellent work all right push communication is sent to stakeholders using memos emails status reports voicemail and more poor communication is something a customer can pull at any time from a bulletin a web page a whiteboard anything visual as well so that's that visual management that you'll see in agile page 13 in the pinbook guide 7th edition types of communication excellent all right we are really getting through these you're doing a great job and such a wide range of topics as well really really relevant for your project career this is good stuff okay what have we got next you have taken over on a project with a vendor where scope and requirements have been missed okay you notice that miscommunication and mixed messages are common you set a meeting with your team and the vendors team the meeting is extremely important to get right what will you do next okay so this is more about communication again very good stuff so speak slowly and clearly with the vendors team at a louder volume if necessary okay and I mean we've all we've all been there we've all seen that happen uh surely you know we haven't done it ourselves of course but if someone doesn't understand us when we're speaking at a louder volume to as if that's going to help them understand the words themselves so you know maybe a little bit of fun probably a no for now unless it's the only option left of course confirm they hear your message oh this is good confirm they hear your message determine if they agree so we get that feedback loop are they are they hearing a message are they agreeing and identifying nuanced or unintended messages that they may have received oh I love that and that's a very like that's very big on a communication style and communication process so we're getting feedback we're saying hey this is the way I see it do you see it the same way or you know do you agree with this is there anything that I'm missing here and through doing that we flesh out all of those unintended messages and we determine if they truly do agree or not I think this is a wonderful answer let's see what else we've got just in case only communicate with the vendor in writing so you have a trail of proof if anything goes wrong in the future potentially however here's where this won't work because you've probably heard that most of communication is visible I guess so it's like a you know 90 of communication is when you're speaking and you can see the people and you can uh and you can hear the voice as well so if we're taking out all of those things and just giving them the words in writing there's actually more you know that it can actually be misinterpreted a lot more easily and you've probably had that happen to yourself where you've sent an email and you thought it was fine and someone has received that email and read it and they've read in some sort of you know some innuendo or some sort of you know maybe they think that you're being snarky when you're not actually because that's the way that they've read it so anyway all of that to say I think writing sounds good but you're taking away all of that extra or extra stuff that you need to communicate with like seeing people the you know the body language you know the tonality all of those things are very important so that's a no for now prepare a claim for the mishandled scope of your project through the procurement team I think if we can uh work on the communication first with our meeting I think that's probably our best case let's go with answer B excellent work all right this question is asking about communication with all forms of communication quick feedback loops provide the information you need by confirming they heard the message determining if they agree and identifying any nuances or additions to the message that they have may have added or heard themselves page 13 stakeholder engagement engage in the permit guides 7th edition so that's really really good how did you guys go for that one some really good tips in there as well so really really good for your own PMP exam and also we're down to the last three questions in this section you're doing really really great keep going guys your stakeholders seem to be engaged however there are frequent changes to scope and requirements causing delays issues are often raised and result in multiple rounds of feedback you're not sure who or what could be the cause what will you do next Okay so we've got a lot of issues but we don't know who or what is the cause of these issues I think let's see what options we have perform root cause analysis with your project team on the problem to brainstorm ideas sure that's pretty good we'll put that as a maybe for now raise a risk in the risk register for the project delay and review responses with your team I don't think that's related to what we're after at all so let's put that as a no it's not a risk we're looking at issues and we need to know who or what is the cause so we've got root cause analysis that certainly fits uh what else have we got though review the issue log the risk register and the change log for the most frequent requesters then update your stakeholder engagement approach for those people wow whoa okay that's deep uh okay and again it comes down to communication uh funny that you know so we're obviously needing to communicate a lot on our projects that's a good tip for us this really does make sense we're sort of delving straight into this this takes a to a new level we're looking at the issue log risk register changelog for the people who are requesting it so The Who and then we're updating the engagement approach so can we engage with those people more get that two-way feedback uh you know get information from them give information about the project to them so that they're more on board with the project maybe we are genuinely missing something and they really need to be in our stakeholder engagement approach engaging more often I think this is actually a pretty good one let's see the last one just in case ensure your project budget has enough contingency reserves to meet the multiple reviews and delays uh you know that's a good practice but again how can we manage that without just throwing money at it can we actually rein it in without spending money on it first let's go with answer C based on all of that information okay excellent a significant number of changes or modifications to the project requirements or scope May indicate stakeholders are not engaged or aligned with the project objectives again it comes down to that engagement a review of the project issue register or risk register can identify challenges associated with individual stakeholders so is it all coming from Billy over here there is is he the one who's just being loud and wanting changes and trying to slow things down or is he genuinely concerned and we've genuinely missed information from him do we even need to engage Billy you know can we work with that or yeah and if we do we need to do it more often because it's all coming from this area so good information to be aware of here really really good stuff page 15 under checking out comes stakeholder performance in the promote guide 7th edition wonderful stuff all right we're down to the last two questions you're doing great let's get into this you've been working on a project where the manager leads in a dictatorship style over time the team have stopped making suggestions sick days and mental health days have become more frequent and the pace of work has slowed which typically does happen in a dictatorship style it can work for a little while but then over time the team becomes disengaged the manager comes to you for help you suggest a servant leadership style instead what will they do next okay this seems pretty straightforward because we're probably just talking about a servant leadership style what does that involve and I think I've got some ideas here you probably do as well you might beat me into this one so serve the team as much as they can ensuring their every need is matter and that sounds good but that's not the case because we're serving them by helping them grow and removing the blockers to their work so we don't need to make sure that every need is met they need to take responsibility for their lives as well so while that sounds good it's not actually our one focus on obstacle removal encouragement and development opportunities that's removing blockers and growing our team probably that's a really good one ensure the team is serving other team members and helping each other succeed that's also a good practice but not typically servant leadership specifically this is more removing blockers growing that sort of thing serve the team new ways to do the work and engage them through additional variety again we've got the right keywords in there but it doesn't quite make sense with what we're after so I think all in all let's go with answer B excellent work all right servant leaders allow project teams to self-organize when possible and increase levels of autonomy so they have power over how they do the work by passing appropriate decision-making opportunities to project team members servant leadership behaviors also include obstacle removal being a diversion Shield so shielding them from other requests outside of the team and development opportunities helping them grow and make progress in their careers and there it is page 18 distributed management and leadership in the public guide 7 Edition wonderful stuff and also for up to the last question you've done really really well guys this is it so you can take a break after this but you've done just such a wonderful job let's see what this one is you have been allocated to a new project team with members from different parts of the functional business area it soon becomes clear that very few of them have worked on a project before there is a lot of miscommunication and rework as occurring amongst the team which is starting to cause delays what will you do next okay and again this is one of those things that we'll see all the time in your own project career set a daily stand-up with your team to ensure they update what they completed I mean that probably could help review the resource assignment Matrix with your team to ensure they are doing their job I mean that also could help I think I have a feeling there's a better option here maybe around Clarity uh you know of the role or something similar set help the team set their vision and objectives roles and responsibilities here we are and team operations usually done through a team charter as we have seen so that is something really really good to do uh whether at any stage in your project as well so it's really really good to go through those things send your team members on training in their roles to increase their capability so again these three are all really really good options but the best option again from an agile perspective or even from a leadership perspective Vision setting the roles and responsibilities getting Clarity for your team helping the team operations and how we operate and escalate things let's go with NC for all of that and there it is when project team teams form across different organizations more work may be required up front to establish a one-team mindset ensuring everyone understands how they contribute team development such as establishing a vision clear roles and responsibilities and a way of working are key page 18 under common aspects of Team development and you made it that's the last of this 10 question set and of course there are many many more to come if you want to continue and I truly believe that you can pass the PMP exam with all the wonderful preparation that you're doing keep going I really do believe in you I know it can seem challenging and difficult at times but if you keep going and keep learning every single day I truly believe that you can do it you have collected the requirements for your project matched them to project scope and broken them down into smaller parts and the activities required in doing this you notice that the manager of the marketing department has added extra scope that is unrelated to your current project okay what will you do next okay so we have scope in our project we've got someone over here has added something that they really want and they've just thrown it over into our projects to see if we can do it so what do we do in these situations let's have a look start an open dialogue with the functional manager that sounds pretty promising actually I'm starting to see a trend as well in these questions in that there are a lot more about communication and collaboration and working together they're more about working with people as opposed to you know the processes that you'll find in the pumbock sixth edition which is really process based this one is more people based probably with that agile you know way of working that you'll see it's much more common it's much more about people so this seems to be on track here raise the incorrect scope items and their impacts and start an open dialogue I think that's actually pretty good we'll see what else we have just in case override the marketing manager's decision on scope as you're the senior project manager okay uh you know what uh this is going to be tricky especially because the functional manager is our customer so ultimately they'll be signing off on the scope oh no the marketing manager isn't our customer we could override it but I think talking with them is probably a better option that we'll see so let's put a low maybe for now on that one raise a change request for the additional scope and let the Change Control Board aside decide or the CCB and this is in our Change Control process but again we need to figure out really if we need to make a change first I think talking it through is probably best we don't know if we're actually you know if it actually fits in our project and if we don't think it does then maybe we need to talk it through first last one place the additional scope into the product backlog for the product owner to prioritize it uh that's also a really good one especially from an agile perspective because we might just have an ordered list and maybe that item just stays at the bottom of the list and it never gets prioritized you know to be worked on next and that's fine as well um but you know that's one way to do it I think still we want to talk it through because maybe it was a mistake maybe they can actually do it uh you know maybe it needs to be part of some other project we just don't know until we talk it through I think for that purpose let's go with answer a okay without an open dialogue you may not know if the scope was a mistake there we go previously approved that's right could have been previously approved as well or any other reason for it being there positive discourse and courage are key aspects of a winning project team culture so you know that's a really good thing to note others include support respect celebrating success and transparency as well so I think we're going to see these themes come up a lot as we go through these questions from the pumox 7th edition and this is in on page 21 project team culture if you want to check that out from the book directly yourself that's where it came from Fantastic all right that was a good one to start let's see what we've got next your Project's team are protected by a union agreement you notice that they don't know how to use the product you're improving they're slow to respond and regularly complain about the work okay okay difficult situation here your project sponsor has had enough or okay difficult situation getting worse and threatens to shut down the project if improvements can't be made what will you do next all right another tricky situation where we have to use our project management skills to try and you know win the day let's see what we can do here and again maybe we use a similar idea where we're trying to collaborate with people I think that's probably where we're going here let's see set up a new project with different team members and transfer the work the project work to that team uh you know that is a nice idea but I don't think it's very feasible so that's just something there's going to take a lot of work to do that we may even need you know oh gosh I just can't even imagine all the stuff involved to to do that usually that won't be very straightforward plus you're not guaranteed to get better results with different people immediately you'll still have to go through the forming stages you know forming storming norming performing you'll still have to go through the stages of a team development as well so anyway let's put that as a a low maybe or a no for now so set a clear project purpose and a vision and pair your team with a customer okay I like this one and again it has that agile bent to it where working directly with the customer and we're also collaborating we're setting a vision maybe through a team charter to show them how they are making a positive difference I think that works with our engagement what we're trying to engage these guys especially if they're complaining not not showing up slow to respond the engagement here is very low obviously so I think this is actually quite a good one let's see what else we have just in case tell your project team that they will lose their jobs okay nothing like a threat to uh you know and you know what that might work for a little while but eventually you know either those people will leave if they get fed up the engagement still won't increase based on a threat as well if they don't increase the speed of their work so let's put a no for that one for now again you know sometimes that can work in some situations but long term it's better to work with people create a project again chart schedule and burn down chart so the work is transparent to all transparency is also a good thing will that help us in this situation maybe not directly I don't think so I think a working Vision working with a customer pairing with a customer uh you know and working with the product helping them learn the product I think but for that reason let's go with answer B all right excellent this question calls for leadership skills oh that's really good we're setting a vision and a purpose and showing your team how they're making a difference can increase their intrinsic motivation which is our internal motivation so you know when it's not money or bonuses or you know or fame we're actually internally motivated we feel pride in what we're doing we're happy with the work transferring to another team in the same company May risk the same result and threatening your team may embed their behavior further oh that's right because when you disagree with someone directly it's like have you ever found or do they change their mind immediately no they dig their heels in they go well no I'm even more right so and then it just becomes a battle like that and this is where we're going we're going with these ways around little psychological tricks uh you know instead of making people embed that behavior further we're actually helping them come out of that behavior through these things pairing with a customer showing them how they're making a positive this is actually pretty good page 24 25 leadership skills establishing a vision and motivation in the promo guide 7th edition there we go all right let's get into the next one because these are actually pretty cool I'm liking these so far during a key scope meeting an argument arises well who would have thought the business manager accuses the technology manager of not delivering to their needs on past projects and the technology manager accuses the business manager of changing requirements that impact the delivery schedule and of course you know when when our teams are separate it's easy to point the finger at the other team isn't it the meeting is at risk with the stakeholders being closed off to any further discussion so what are we going to do what will we do next all right let's see what options we have take the side of the technology manager as the scope that impacts delivery should be controlled I don't think we really want to take sides here so let's see if we have any anything else take the side of the business manager as we should always deliver to the customer specification the thing is both of these things are true so I think we have to work together again you know it's that collaboration because in this case there's a little bit of correctness in each view so that's pretty important facilitate that's a good word to keep the communication respectful focus on the issue in the present that's not good and search for Alternatives together I think that's a really good answer again we're sort of looking at that facilitation again more of an agile way of working here facilitating instead of you know directing that's really good ensure they both agree to the Change Control process to avoid disagreements in the future that's also a really good answer uh you know so so why not well if we're agreeing to scope plus the Change Control process for how to make changes that's actually pretty good but to get there I think we need to problem solve first first and look at the issue in the present not the past I think that's probably where we're going to go and again seeing that same theme with all of these questions so far let's go with answer C okay fantastic not all conflict is negative how conflict is handled can either lead to more conflict or better decision making and stronger Solutions the permalt guide notes open and respectful communication focusing on the issue not the person and the present not the past and searching for Alternatives together and that's under page 29 under Conflict Management in the pmbok guide 7th edition that was really good all right how did you guys go with that one a few correct answers potentially there as well so that's what you'll find on the PMP exam sometimes you'll see more than one answer that could be correct and you have to choose the best one so for this purpose I think this is actually pretty good let's see what we've got next you're working on a project where the Project's team is completely distributed around the country in multiple sites including working from home some of the project team members have not been able to contribute to the project and there are concerns that from the program that the project will fall behind what will you do next okay so I've got people everywhere and some team members actually haven't been able to contribute at all so you know that's a problem especially if we've got resources or we're paying for resources so now we're falling behind not good what are we going to do about this one okay raise a request to the program to co-locate all your project team members as soon as possible uh another good idea but how feasible is that really uh are we really going to uproot everyone from their respective cities and you know put them in one city in the one place uh that could be very difficult to do so let's put a low maybe for now proceed with daily stand-ups and working group meetings with any team members in your area okay what about the team members in the other areas probably not good for that one set team leaders for each area around the country to report back to you as the centralized project leader well this is we're still working in different silos isn't it so that's probably still not good is there a way that we can get more transparency here and more interaction I think if there is let's go with that use technology to maintain ongoing contact with audio and video for meetings A Team website to keep all project information available so that's our transparency I think that's probably our one and again it's more about collaboration with everyone not just to select few people we want to talk with our team get them all involved and make sure they have all the information that they need as well let's go with answer d fantastic this question is on distributed project teams really good especially in this day and age see it more and more and more to improve you can use audio and video capabilities for meetings use technology including messaging for ongoing contact built in time to get to know remote team members and have an open project site for open information and transparency page 30 under distributed project teams in the pmbok guide 7th edition fantastic if you want to check that out for yourself I do recommend it it's not a bad read it's actually pretty good not as big as the sixth edition which is nice so it's a little bit lighter all right how did you guys go for that one I think we're getting through these you're doing really really well let's keep going you are initiating a project to to a sales team where the process will change significantly even though the outcome of a completed sale will remain the same okay that's fair enough so we've got a process uh but the process is changing even though the sale is the same so you know that's fair enough we still want the same outcome the process is different okay the functional manager is concerned about the change and any disruption that it might bring what will you do next okay so is this about change management perhaps let's have a look kick off the project with multiple deliveries to deliver small parts and reduce the change impact yeah I mean that sounds nice smaller deliveries will it actually reduce the change impact we're changing a whole process here kick off the project with a single delivery okay at the end of the project when the process change is complete let's see what else we've got kick off the project with continuous delivery in mind I think that's a red herring to ensure fast delivery to the business kick off the project using periodic deliveries as delivering delivering value as it's ready but again it's one process change so probably a no for that one it's between these first two and they're both good but I do seem to remember with process changes we want to do that in one go just because it's we're changing that one process all in one go uh it's a tricky one but I think we're going to go with answer B and let's see okay all right it could have gone either way actually let's see if we get any tips from the answer this question covers delivery Cadence and their various benefits a process re-engineering project may not have any deliveries until near the end of the project when the new process is rolled out and ready okay all right so that's what we're talking about there directly from the Vermont guide page 34 under delivery Cadence uh quite tricky could have gone both ways but that is something good to know and be aware of when you're doing the exam under those scenarios under a process scenario re-engineering process all right let's keep going we're halfway through this little section hopefully they're not as tricky as that one but we'll soon find out you're working on a project where the requirements are clear but the solution ideas are uncertain the product owner and the technical experts can't be sure which ideas will work in practice and which ones won't the organization can't afford to get this project wrong now that's a big clue as they have previously made mistakes and customers are starting to leave so what will you do next so we've got uncertain solution ideas so we might need to change or you know improve but we can't afford to get the project wrong so we can't really just be releasing bits to get feedback directly from our customers we actually need to release in one big in one go so improvements along the way but one big release is an iterative approach so we're iterating towards success so I think that's probably going to be our one here incremental is delivering increments of value so we do we don't want to do that just yet because we don't want to scare away our customers use a predictive development approach that will just plan everything up front and then deliver in one go without all of that feedback in between and a hybrid is you know part agile and part waterfall so not specifically for our scenario here let's go with answer B okay all right for development approaches an iterative approach is used when you need to capture ideas that might change while still delivering in One release okay that's good to know incremental progressively delivers features or increments predictive plans everything up front and a hybrid is a combination of predictive and adaptive so this is page 37 under development approaches and page 18 as well uh in the in the agile practice guide so that's pretty cool so this is the pmbok guide as well as the agile practice guide under characteristics of project life cycles very very handy to know and good information to have all right how did you go with that one so that's good to know I think there's going to be quite a few of those on the exam around you know which life cycle do we choose or which development approach do we choose all right next question you're working on a new product for your organization where the requirements are complex and are likely to change a few times as the project progresses all right that's another good clue so requirements are going to change the organization also needs usable parts of the products to be released that's another good clue those are our increments as fast as possible to capture some of the market that they're aiming for away from their competitors what will you do next sounds like an incremental approach here we're delivering an increment an increment an increment and getting that feedback as we're going along so iterative that's one big bang but feedback predictive is planned up front adaptive that could fit here that's our agile approach basically so a combination of feedback plus releases combination of iterative and incremental that is adaptive or an agile approach and hybrid is a combination of agile and waterfall so those two in those two situations or scenarios So based on that we don't have an incremental option here so increments but we do have an Adaptive or agile approach which is increments plus feedback or increments plus iterations I think we're going to go with answer C based on that great doing very well adaptive approaches are useful when requirements are subject to uncertainty and change and a Clear Vision is established at the start of the project and initial loan requirements are refined or replaced in accordance with user feedback as we're going along or unexpected events under page 35 adaptive approach in the permit guide 7th edition wonderful how did you go with that one I think we've got we've had a few on the same idea here now about development approach it's pretty good to get into so especially the different scenarios that we will see let's get into the next question we've only got three to go for this little section a new project has been kicked off in your organization due to a recent government inquiry into your industry okay government could be a clue here so lots of Regulation which found multiple processes with significant regulatory oversight that need to change okay usually when government or regulation is involved we if this is about processes again or development approaches okay which it seems to be it's usually going to be a predictive or a waterfall approach where we're planning everything up front getting all of the quality checks and things signed off properly and then releasing so that there's no mistakes and that's where we've got a lot of Regulation and a lot of government oversight so could be that one let's quickly finish this and see if there's any other Clues just in case the inquiry ordering these changes has given you a due date of 10 months time before you start incurring penalties what will you do next proceed with an Agile development approach to deliver change as quickly as possible you know again it sounds good and that does have potential but with that government oversight and Regulatory environments probably best to go with predictive at least from the pimple guides perspective proceed with a hybrid development approach to respond to changes while planning up front again actually I think any of these could fit but again you know as sort of mentioned directly in the pmbok I do remember that that regulatory oversight proceed with an iterative methodology to improve using feedback again so all of these are actually quite good but the best one for us let's go with answer C okay all right we're doing well in considerations for selecting a development approach environments that have significant regulatory oversight may need to use a predictive approach due to the required process documentation and demonstration needs so again here just uh trying to to satisfy all those government regulations can be a bit more tricky can need a bit more oversight and a bit more planning page 40 under considerations for selecting a development approach in the permit guide seventh edition fantastic work all right and last two questions you're doing amazing work these have certainly been a little bit different so you know much less process based isn't it than the pimp guide sixth edition all right last two let's go your organization is moving to an agile way of work your project team are strongly opposed to using agile as they've been burned using iterations when Executives used the team velocity to try and force the team to work faster instead of keeping a sustainable Pace wow towel that's a there's a lot of information there sustainable pace is what we want in agile so we don't want to have Peaks and troughs it's not hurry up and then wait hurry up and then wait we want sustainable pace of work so people don't burn out and you know and don't have to work overtime to catch up uh and all of that to say velocity as well is the amount of work that we're getting through in an iteration so the average amount of work usually in story points so maybe it's 50 story points uh on average every uh every iteration but that's an internal team measure we only want to measure that within the team because every team is going to be different and every team is going to have a different product different complexity different people so that velocity you know once Executives get their hands on that and try and use it as a beating stick instead of you know just as a way for the team to understand how much work they can take on to keep their sustainable Pace then you know things get a little bit more ugly you know so that's something to be very aware of it's actually pretty good good scenario here what are we going to do here okay so we're moving to an agile way of work so it seems like we have to do that anyway how can we get around this add extra resources to your team to deliver faster and avoid Executives getting involved I don't think those two are related Executives will probably still be involved potentially adding extra resources might complicate things as well so something you know that may not help proceed with a predictive development approach and deal with the consequences later we may not have that option because you know it's coming from the organization it's moving to an agile way of work we may have to to do this eventually and so why not look at see if we can figure it out now rather than later so let's put a no for that one for now ask your team to work with agile velocity and iterations despite their hesitations this might work but again it's the you know we can force them to do it but because we're forcing them you know they they are sort of convinced against their will and they it just may not work they may not have their hearts in it so their engagement will be low again we're seeing a lot of Engagement and sort of that leadership come into these questions I'm going to put a no for that one and hope the last one is okay maybe we just select the last one based on elimination unless they're all wrong let's see what we've got suggest the team uses flow based scheduling okay well this actually sounds promising flow-based scheduling with a kanman board for visual work so those are agile principles that we can use so we've got visual management kanban board moving our work across the board and flow-based scheduling we we don't we've got a work in progress limit so we can only we only want sort of three cards for this person at one time or one card or two cards or five cards user stories pieces of work work packages whatever you want to call them that someone is working on that's how we're limiting work in progress to keep people focused on the one or two things at once so we're not multitasking and context switching gosh a lot of words in here a lot of agile based work that you will see and find but all of that I think let's go with answer d and there it is kanban is one of the largest parts of agile approaches aside from the other parts other major parts such as lean extreme programming and scrum a flow-based scheduling approach does not use Sprints velocity or life cycles but optimizes deliveries based on resource capacity and minimizes waste such as context switching and handoffs between different people so again we sort of described how that happens with kanban there which is pretty cool and you know you can use that in the real world very very handy stuff and there we are answer D and that's the description page 45 under flow-based scheduling in the pmbot guides 7th edition this is really good stuff and you can see much more agile stuff coming into these questions it's pretty cool and what else is pretty cool we're up to the last question you've done really really well let's do this you've done an amazing job your team have not worked on projects before and don't know about waterfall agile or any of the different models your your project may also have requirements that are certain or uncertain with varying levels of risk so you're not sure which approach to use as you begin this new project what will you do next okay so we're not sure about our you know which which way we're going to go waterfall or agile and also we've got requirements that could be certain or could be uncertain no one really seems to know so what approach can we use in this scenario you know can we use any Approach at all let's see what we've got use waterfall and plan everything up front so the team have more stability sure I mean that could definitely work that's a maybe use General phase definitions such as feasibility design build test deploy and close that is actually very interesting okay there's something about this because what you'll see in the permit guide and even just when you work around any project these are actually the the broad you know sort of phases that you'll go through on any project or in any life cycle well if we're using agile then you know feasibility design build tests deploying closed these are sort of done for each project increment and then we you know we get the feedback and then we do it again for the next increment if we're doing it for waterfall this is the sequential you know start to finish planning steps and then release steps from the very beginning of the project to the very end of the project where we release all in one go so these are actually the same uh you know in any development life cycle they're just at different stages or used a little bit differently but we still have to go through them that's actually pretty good so let's see what else we have just in case use agile to ensure you can respond to change while your team's capability increases again that's a fine answer it's actually quite good but we're not sure on anything else we can use something that fits everything quite broadly don't use any project approach it doesn't matter as long as the work is getting done I mean maybe as well there's probably better answers there you could probably do that in the real world and just see if you could go for it but it's way better if you've got a process that actually works in my you know experience so I think for us let's go with answer B all right excellent work all projects will go through the general phases of feasibility design build test deploy and close waterfall projects will do these in sequence once while agile projects will do it multiple times for each feature or increment the underlying principle Remains the Same so this is a good place to start page 42 life cycle and phase definitions in the promote God 7th edition that was a really really good one and wow so much information here so much great stuff for your own PMP exam but now you know we've learned this we've done it in an exam environment already this is something that's truly truly going to help you pass the exam and I really do believe that you can do it especially with all this work that you are putting in I truly believe in you you're a project manager in an organization with a directive project management office and are currently in between projects the pmo asks you to prepare for an upcoming project in the accounting area by meeting with the functional manager there you have no team no scope and no requirements and no timeline as yet what will you do next okay wow let's see what we've got ask the functional manager for their wish list of improvements so you can take these to your pmo okay I mean maybe then we could maybe prioritize those I wonder if there's anything any other better options here though create a project management plan so the project scope budget and schedule are more clear I think we'll do that once we have kicked off the project and we can plan the project usually before that stage you know there's no project in existence so why do a plan necessarily create a small backlog of work and start your first Sprint then progressively update the backlog as the project progresses that's like an agile or an iterative approach but you know we still may need to do the planning and why are we doing this project in the first place uh even though we've got a small backlog of work I think you know maybe we need something bigger than this a vision or Direction it's put a low maybe on this one for now progressively elaborate the vision okay there's our vision that's that could be good vision statement and project Charter to kick off our project also good to define a coordinated approach okay remember we're in the very early days here you know the project hasn't even been kicked off to kick off a project we do need a project Charter or in an agile environment a vision statement at the very least to find out where we are going then we can do all of these other things project plan small backlog of work and even you know prioritizing a wish list of improvements as well but for our purposes I think let's go with answer d excellent work all right before initiating a project of any sort we start with a vision statement project Charter or business case in order to identify a coordinated path to achieve the desired outcomes page 52 under planning overview in the Puma guide 7th edition all right nice one to start with a little bit of leadership a little bit of vision that's pretty good let's see what we have next you're working on a project where part of the project delivers a high value high risk component another part of the project delivers a routine change to the system okay tricky your project sponsor wants to gain the business quickly the business value quickly but your project team want to start with the work that they're familiar with first what will you do next gosh Okay so we've got high value high risk components and we've also got BAU work as well so what do we do here and people want to start with different things okay prioritize the higher risk items at the end of the project um okay let's see what else we have prioritize the high risk items at the start of the project okay oh you know what that actually sounds pretty good because that's that's sort of a principle that we do try and remove all of the high risk items first because the risk actually gets higher toward towards the end of the project so if we haven't delivered it haven't delivered it then it's actually the risk becomes higher and higher and higher because maybe we won't deliver it at all or maybe it will impact something else right at the end of our project which is a terrible scenario so actually that one could work let's see what else we have just in case use an incremental approach and deliver part of the routine and higher risk work in each Sprint our incremental I don't know I think because then we're doing increments and we're delivering one bit of this one bit of that uh you know what if anything I would look at more of a hybrid approach where some of this is agile and some of this is waterfall so some of this is planned up front and some of this is uh you know is uh is released in increments or you know at least iterated on so that we can get the feedback on it um so I think no on that one for now plan out the work in detail and secure a scope Baseline with formal change controls to reduce the uncertainty I think that's probably going to make the situation a little bit worse so for US based on that let's get rid of those high risk items first then work on our BAU stuff let's go with answer B excellent work this question refers to the concept of last responsible moment well that's something good to know work that is novel or risky can be prioritized at the start of the project to reduce uncertainty with the project scope before a large investment has been made routine work can be delayed until the cost of further delay would exceed the benefit in other words can we delay it as much as possible until it's just going to become too costly to delay that any further and that's when we need to do it so that actually is pretty good page 54 in the pmbok guide under delivery page paragraph three Puma God's 7th edition fantastic way to get us started on this that was actually pretty good all right how did you guys go with that one I think we're getting through this pretty well let's see what we have next you are working on an agile project where the functional manager you're delivering to only has a high level idea of the system requirements they'll need the functional manager suggests a work breakdown structure however your team feel that that is more for a predictive or waterfall delivery approach oh okay what will you do next so it says we're working on an agile sort of project but does that mean that we can't use a work breakdown structure not necessarily but you know is there another way to put this or do this in an agile project so decomposition is the is the idea here and it still applies whether we're working in this way or that way so let's see what we've got create use and create a work breakdown structure anyway as it's just a tool I mean maybe maybe we do do that I wonder if there's anything more agile Centric though use rolling wave planning that sounds promising and keep the work at a high level until you're ready to work on it and then you can plan in detail that actually sounds pretty good I mean I put that as a as a high maybe for that one as well that one's a high maybe are these all going to be good answers I'm not sure note the high level themes or epics okay there's that decomposition that theme the principle of decomposition where decomposing things into smaller and smaller pieces decompose them into features and again into user stories all right that's a really good answer as well especially because that's basically a work breakdown structure we've got our high level themes decompose them into features and then again into multiple user stories for people to actually work on that could be our one especially because it's more agile Centric there last one use the functional ask the functional area for more detailed requirements before the project begins I think we want to collaborate with the functional area we can't just ask them for it you know we really have to work with people to you know elaborate and extract these these requirements so all of these are pretty good but the best one I think for us is answer C all right great work this question refers to decomposition or breaking down the work we could use a work breakdown structure or rolling wave planning but for an incremental approach breaking down the work from epics into features to user stories is a form of decomposition that fits the delivery approach that we're using page 54 under delivery paragraph three again in the promote guides 7th edition wonderful to know you can check that out for yourself how did you go with that one a few good answers there that was actually pretty good all right let's see what we have next you're you're at the beginning of a planning a new project and have researched and gathered the requirements from the area broken them down into deliverables and activities which you believe could take 26 weeks to deliver okay well we've done a lot of work here this is good the project sponsor is asking you for an estimate on how long the project will take what will you do next all right tell the project sponsor 26 weeks is it that easy uh hmm that seems pretty straightforward we think 26 weeks oh hang on a minute though you're at the beginning of planning a new project so we're right at the beginning here we're not sort of even in the project at all so potentially here then we're then we're you know doing the planning and then we're doing the delivering and then you know ultimately the product is delivered so we're like all the way back here at the very very beginning this is tricky because when we're estimating on things our estimates are really bad at the beginning and they get more honed they get better and better and better as we get more knowledge and information as the project goes along um so that's something that we really need to be aware of and not to mention there's actually ranges so now that I think about this more there's ranges you know when it's really far away it's like uh minus 50 plus 75 or something similar is they call it a rough order of magnitude uh that that's you know that's a rough guide at the beginning and it gets narrower and narrower so then I think the budget estimate is -10 to plus 25 or something similar um or you know and then maybe minus five to plus 10 something like that until ultimately it's delivered and the estimates are just zero because that's what it actually is so all of that to say tell the project sponsor that you'll use an iterative approach where value is delivered until the project stops uh we still need to estimate it I think so we still need a rough guideline here to you know so that we know what we're dealing with so let's put a no for now let's put a no on that one for now as well tell the project sponsor approximately 24 to 28 weeks okay so we're right at the beginning uh 26 what's 50 off that would be down to 13 wouldn't it so is that enough not really that's not quite enough and plus 75 percent not quite enough either uh but the other one is tell the project sponsor approximately 20 to 45 weeks so that is that's minus something like what is that 25 minus minus 25 hmm okay this is tricky none of these match up with what we've done here I you know this is I don't really remember them all exactly but I think the biggest one I think is this last one so this is the biggest range let's go with that and see how we go okay answer D this question is related to estimation and range estimates should have a broad range at the start of the project just like we said starting at okay -25 to plus 75 oh I was close it was uh 25 instead of 50 there so that's good to know when there is not much information once the project team has a smooth delivery Cadence and experience in the product a smaller range such as minus five to plus 10 can be used a zero percent range is when everything is known when the product has been delivered so we were pretty close ah nearly um but you know right on the right track and still managed to eliminate all the other ones based on that so that's good uh page 55 under estimating and range in the pmbot guide 7th edition all right a little bit trickier that one how did you guys go did you beat me to it possibly I was flounder a little bit there so but we still got there in the end that was good all right we're nearly halfway through after Gathering your project requirements project scope and breaking it down into activities you need to estimate the project schedule within your team with your team okay more estimation maybe after some analysis and discussion your team come up with a range of 53 to 75 days assigned across all tasks what will you do next okay and look at our answers here it's we've got accuracy and precision this is a question on accuracy and precision and I think we've done this before in the sixth edition pmbok guide sixth edition questions so accuracy and precision accuracy is the range so if it's a small range then it's high accuracy if it's a wide range so this is actually a pretty wide range it's like nearly 20 days more than 20 days here and quite a big percentage of what we're looking at so I think for us the accuracy is actually quite low it's a quite wide range here okay and the Precision is more about you know is it sometime next week or is it uh specific this day like Wednesday or you know in days or hours or minutes um the Precision is pretty good so we're saying you know it's these this amount of days it's not saying you know sometime between now and November or whenever uh okay so low accuracy that's this one uh confidence and precision that's not a real thing so oh that's a little bit of a red herring we can get rid of those but low accuracy and higher Precision ensure the estimates become more accurate as the project unfolds and that's what we found as we get better at the project the estimates become more accurate like we were looking at before I think based on that we can go with answer B all right excellent this question is on estimates and their accuracy the lower the accuracy the larger the potential range in values so big range and that's what we're seeing Precision is different from accuracy as it refers to the exactness of the estimate how exact is it for example two days is more precise than sometime this week and that is good to know Pumba guides 7th edition page 54 again under estimating accuracy precision and confidence how did you guys go with that one that was actually pretty good getting a little bit trickier but we're getting through them you're doing a great job let's see what we've got next you are working on a business case where you know that the industry is undergoing a significant change at the moment and there could be many different impacts to your project benefits before it's delivered completely okay your project sponsor asks you to for the best estimate of benefits that you can give under the circumstances what will you do next okay wow tricky uh so there's going to be lots of changes to our project and potentially to the benefits but we have to estimate what the benefits are again do we do that range do we do a range here let's have a look at the options we have ask your team for a probabilistic estimate so that is a range and it's a range with estimates with probabilities attached to it so maybe there's a you know 50 percent chance of here maybe there's a maybe a 30 chance of this one maybe there's a 90 chance of this one so that's actually pretty good and pretty handy that could be what we're after let's see what else we have just in case ask your team for a deterministic estimate I think that's a specific number so it's we're determined about it I think a specific number let's see I would say a no for that one for now ask your team for an absolute estimate maybe those two are similar I'm not sure but both of those sound very absolute and and we're sort of changing our environments changing so it's not going to be the best ask your team for a relative estimate that's more agile related where we're look looking at the smallest piece and then estimating everything else as it relates to that first piece for example there's two bits in there four bits in here for example you know that sort of thing and there's various ways to do that obviously with Fibonacci numbers and that sort of thing that you will see in the real world that's your relative estimating not particularly what we're after here I think we're going to go with answer a all right great work guys probabilistic estimates include a range of estimates along with the associated probabilities within the range such as a confidence level or a probability distribution like your so your cumulative distribution here where you know ultimately we get to a hundred percent or this is zero percent here and at this stage we're going to have the highest probability for example so you know this is just a one example cumulative distribution where we're accumulating over time a deterministic or if the number is uncertain that that's the best approach deterministic is a number absolute is specific okay so we're close that's just a number that's specific and actual numbers and relative estimates are shown in comparison to other estimates page 57 under presenting estimates in the promo guide seventh edition wow all right getting a little bit trickier but still I think we got there in the end that was actually pretty good I'm learning quite a little bit here as well how did you guys go with that one think we're doing this we're doing really well let's see what we have next you have noted nine epics for delivery as part of your most recent project your team have broken down these epics into user stories and would like to see the effort involved for these deliverables okay we're looking at effort again potentially you ask your team to find the smallest user story size it with a one and then determine the size of the other cards based on how they compare to the original card ah oh this is okay a few things here what approach are you taking so this is the type of estimating and we had a bit of a clue from the last one it's not deterministic it's like so it is a number that is fine but we're comparing its relative to the original card it's that so we've got one is a one then this one is going to be you know two for example next one is going to be a three based on how big it is in relation to that first one so what approach are we taking here oh and there it is relative estimating with your team I think that's probably going to be our one let's see what else we've got just in case deterministic estimating to determine the effort uh again it's a that's a specific number I think wasn't it absolute estimate mating was was just something absolute a specific number again that was a number and that was a specific one though I get those mixed up probabilistic estimating is that probability that we used before but it's not relative here for us it is relative estimating let's go with answer a all right excellent work this question is about estimating and making an estimate in comparison to other estimates that is relative estimating page 57 under relative estimating in the pinball guide 7th edition wonderful work guys we're really getting through this really really doing it learning a little bit that we can use in future questions as well all right let's keep going you're working on a project where a competitor is also working on a similar feature and being first to the market will have a significant impact on this year's profit your product owner would like to measure how quickly story cards are being completed once they start being developed okay what will you do next do we have anything on velocity here although that's velocity is for all of the story cards in a Sprint for example um but this is so just how quickly story cards are being completed in general once they start being developed okay and I see we've got lead time cycle time uh check the Gantt chart I don't I think that's going to throw us off that's not it check the schedule Network and precedence diagram that's going to throw us off as well so we've got either the lead time or the cycle time the lead time is from the time the customer makes the order so for our purposes it might be from when the feature makes its way into our backlog and then to the time it is delivered to the customer or released so into production for example so that's the lead time that's the full time but in between we might have different story cards being completed and that is our cycle time the cycle time is when a developer starts picking it up and then completes their work that's the cycle time for their work so all of that to say I think our answer here is going to be answer C excellent work all right cycle time is the total elapsed time it takes one unit to get through a process or just their process lead time is the time from when the customer makes the order or the requirement is noted to the time that the item is delivered or released well that's pretty much exactly what we were saying so that's really really good news schedule Network diagram is useful for finding the critical path and precedence diagramming is used to find what deliverable or activity relies on other activities page 58 under flow-based estimating in the pmbok guide 7th edition that was pretty good all right you know what else is pretty good we are down to the last two questions you've done an amazing job let's keep going we're nearly nearly there you're working on a project that has recently moved to a more agile way of work the team have not completely taken on the scrum approach however and are comfortable working with a more flow-based approach you are moving user stories across a kanman board so flow based is that kanban approach that we saw before you're wanting to get an estimate on how much work can be completed in the next three months based on the team's existing process what progress what will you do next wow okay so we're just using flow-based scheduling it's a pull approach where someone pulls the work usually onto the kanban board once they're ready there's usually a work in progress limit so we can only have one or two in progress at one time per person so they're not having to switch between tasks all the time so that reduces that you know cognitive load that context switching so that you know people can really really focus but because we're doing that okay multiply the velocity by the number of remaining user stories that's more of a scrum way of work oh here we go multiply the cycle time by the throughput cycle time is that time for each user story to be complete so maybe it takes three days for example on average and multiply that by the the throughput so how many of these are we getting completed you know every every week or so or you know every every month for example um and so then that gives us a really good idea on how much progress we're making and how much work can be completed in the next three months based on that and that's for your can men approach really similar to the scrum approach but just a little bit different there multiply the lead time by the scheduled performance index that's a red herring trying to throw us off multiply the planned value by the actual value that's our earned value management that we'll see and relevant for other scenarios but not this one in particular for our purposes let's go with answer B there it is Scrum uses velocity kanban or flowbo based estimates are developed by determining the cycle time and throughput cycle time is the total elapsed time it takes one unit to get through a process throughput is the number of items that can complete a process in a given amount of time okay goodness all right so to complete that feature for example all right that's pretty good to know page 58 under flow based estimating if you want to check that out in more detail for yourself which I do recommend that's pretty good and you can go directly there to the promote guide fantastic how did you guys go with that one you're up to the last question you're doing an amazing job let's do this your product owner wants to bring the next feature forward so that it is done in parallel to the current feature okay fast tracking perhaps so we're doing things in sequence and now we want to do them at the same time to make things go a little bit faster but it's still released in the existing feature order oh okay so it's limp this one's still coming first this one is released a little bit afterwards perhaps you make the necessary adjustments to the product backlog and decide to adjust the product roadmap which you have visualized as a Gantt chart so product backlog is our list of features so which features are prioritized first for example so we can re-prioritize those accordingly and then we can put them on our Gantt chart which is you know it looks like this just bars on a chart as they're you know going on a schedule so what are we going to do next how are we going to make this happen and I see we've got leads and lags here okay this is good leads and lags so lagging is when it's moving backwards it's lagging behind leading is when we're leading it forward so we're leading the item back you know forward to us where that's where using the lead that we have available and so he wants to bring it forward so we're leading It Forward remember so let's have a look use a schedule lead so we've got either a or C here because we're using a schedule lead and oh okay change the feature to finish to start so this is precedence diagramming so the Precedence diagramming method where we've got finish to start start to start start to finish and uh there's another one there I think there's only four so yeah uh so the way we do this this is a little trick as well is uh the second item can't start before the first item has finished and so on so the second item can't start before the first item has started the second item can't finish before the first item has finished so that's your little trick to use when you see precedence diagramming method so our second item for us still has to be in the same order so it can't finish before the first item has finished like we were saying here there's still that still the same order isn't it but it can start before the first one has finished we actually want it to start so that it's ready to go based on all of that information so I think this is going to be our one answer C we can finish uh the second one can't finish before the first one finishes but we can bring it forward and start it so that it is ready to go all right I hope we got this right let's see and to see okay good work guys excellent schedule lag is moving an item back schedule lead is bringing an item forward precedence diagramming method States for finish to finish items the next item cannot finish until the previous item has finished this allows the items to be worked on in parallel while still keeping the same delivery order wow that was actually pretty tricky and we've got page 59 schedules lead in lag in the seventh edition and we've got page 180 precedence diagramming method in the sixth edition of the pmbok iron so both of those really good books definitely do recommend you go through them they're fantastic tomes of information and what else is fantastic is that you and I have gotten through this little section of PMP questions specifically on the pinbook guide 7th edition so the that latest information you're doing a wonderful job I truly believe that you can pass the PMP exam keep practicing keep learning a little bit every single day and I know you can do it you're working on a project where you have been completing the deliverables in sequence and the project work is starting to fall behind the project sponsor asks you to speed up the work and reduce the time for the project to be delivered but also makes it very clear that there is no more money to use when speeding up the work what will you do next Okay so we've got sequence here oh and it looks like we've got a few different options around uh schedule around improving the schedule so bringing our schedule back on track we've got leads and lags um okay but what are we trying to do here we're doing things in sequence we have no more money unfortunately and so we can't use schedule crashing so schedule crashing is where we're throwing money and resources at the at the schedule to bring it back on track so we can put that out of out of our minds because we don't have any extra money here uh leads and lags we could use that but I think we need more information around that it needs to be more specific so let's say no to that one for now resource leveling is when we're taking items that are being done at the same time and instead doing them in sequence for example if they're both assigned to the same person like these two tasks they can't be done by the same person at the same time so they need to be leveled out so that's actually the opposite of what we're wanting but schedule fast tracking is when we're bringing in items and doing them in parallel to each other so that uh now hopefully we're bringing the schedule back on track because we're doing them sooner instead of one after the other that's fast tracking and I think that's the one that we're going to go for answer B fantastic project fast tracking is a scheduled compression method so we're compressing our schedule in which activities or tasks that are normally done in sequence are performed in parallel at the same time schedule crashing includes adding people to activities working overtime or paying to expedite deliveries and we've got page 59 under schedules fast tracking and crashing in the promot guide 7th edition great way to start us off that is really good and a whole bunch of information just in that first question let's see what we've got next after reviewing your project schedule you notice you are behind by three weeks and the schedule needs to be compressed excellent because we've just learned all about that so your project does not have enough budget to crash the schedule that sounds familiar you check with the lead for each area and review the schedule as to whether they can Fast Track their deliverables what will you do next and we know about that so that's doing that doing them in parallel instead of in sequence bringing it back in line but we're fast tracking all these items but it looks like we're doing okay which one are we going to do with which with what sort of dependency are we going to do the fast tracking on so which items can we easily move on our schedule can we move the industry regulated ones probably not usually because they're you know there's a lot of lot more checks and balances a lot more regulation a lot more oversight on that one let's put a low Maybe on that one for now external dependencies also very difficult to move because we don't own those dependencies usually they're external to our team harder to move let's put a low maybe for that one mandatory dependencies they are set in stone you know they have to be done in a certain order or they have to rely on this one or that one so again hard for that one to move discretionary though is just at someone's discretion so you know is it if they may want it or they may not want it but it's not it's not a hard dependency it's not set in stone that one is much easier to move so I think for our purposes let's go with answer hey all right doing well when compressing the schedule some activities cannot be fast tracked because of the nature of the work while others can a discretionary dependency is based on Project preferences so and it might be modifiable external and mandatory dependencies usually cannot be modified internal dependencies might be modifiable except when based on specific regulatory needs so regulatory needs not good for us but internal dependencies we might be able to do but we didn't have that really specifically mentioned here either so all right that was really good well we're really getting through these you're doing a great job how did you go with that one I think that was another good addition to our schedule compression compression techniques hard to say but uh easy to get it right for us let's see what we've got next okay your team are new to Agile oh we've got agile and have previously been working with waterfall okay maybe moving from waterfall to Agile your key customer asks you for a project schedule the project team believes using a project schedule is from the old waterfall way of working and they shouldn't have to create one what will you do next oh now that's not necessarily true but maybe there's an maybe there's an agile Centric way of describing a project schedule for example a product roadmap would usually do the trick let's see what we have create a project Gantt chart to visualize the activities within the project that's a yes a product roadmap can be a Gantt chart as well so let's put them maybe for that one for now determine the Project's planned versus actual value instead of working with a schedule directly um this one is more about the variance of the schedule so what have we planned versus how is it actually going it's not really an agile Centric even though it's a good practice to do so we could put a maybe a low maybe for that one for now advise the customer that we don't need to plan ahead in an Adaptive way of work not necessarily true we that's the whole point of a product roadmap so we can see the features that are coming up and make sure that they're adding value in the eyes of our customer so I think what we've got here D is looking a bit more promising ask your team to develop a high level release plan like a product roadmap showing the features to be included in each release as we're coming up and it's the coming up in the future the time frame doesn't have to be exact but this is what's coming up in the future and we can usually tell when it's coming up based on how quickly we're completing our work our velocity so I think for our purposes let's go with answer d all right good stuff adaptive scheduling planning adaptive schedule planning uses incremental planning a high level release plan is developed that indicates basic features and functionality to be included in each release and then if we're uh so those are the increments that we're delivering in other words that incremental planning so that's really good to know page 61 under adaptive schedule planning in the pmbok guide 7th edition wonderful stuff and I'm already learning more about the Boombox 7th edition without having to actually read it myself and that's even better even though it's not too bad it's not as big as the sixth edition which was a huge huge book we're really getting through these you're doing great you're working in a project team that has recently moved to an agile way of work your business analysts want to gather the requirements Solutions match them to the scope and do a work breakdown structure for the whole deliverable your product owner says this will take too long and is not agile enough for their needs okay what will you do next okay is there another way to break it down perhaps instead of doing it all in one go ask your team to review the scope management plan for the proper process I think maybe there's a better answer than that one let's put a low maybe for now break the deliverable down into smaller pieces so you can deliver those faster yeah that's definitely possible and then they could you know analyze those smaller pieces as well potentially that could work ask your team to time box work on the highest priority items in the backlog update the estimates and then re-prioritize them as necessary that's probably that sounds really quite good uh obviously we're prioritizing the highest items update the estimates for those highest priority items and then re-prioritize them as necessary we're time boxing the work very agile Centric you know lots of agile words there you know in that agile way of working time boxing prioritizing uh I mean that's a that's a pretty good one review the project Charter for the high level scope and then use this to begin delivery quickly I think there's definitely a better answer than that we still need to plan properly whether we're working in an agile way or a waterfall way we still need to do the proper um you know detail on the requirements and the scope and the solutions and that sort of thing so between B and C do we just break it down into smaller pieces that might not actually fit you know what we're doing so sometimes if we're just breaking it down into pieces they still have to be usable pieces really but this one working on the highest priority items and then getting them to analyze those highest priority items and reprioritizing as necessary that one definitely sounds a lot better between those two let's go with answer C and hope for the best okay all right that was actually a little bit tricky both of those were pretty good let's see if we get any tips here adaptive approaches often use time boxes so that's good the work is based on a prioritized backlog that's what we're talking about the project team determines the amount of work they can do in each time box estimates the work and self-managers to accomplish that work at this point the backlog may be re-prioritized for the next time box so it basically is just describing an agile way of work and then prioritizing those those items to work on so I guess that satisfies all of these things moving to an agile way of work and you know ensuring that things that they can start to work more quickly rather than doing all of the analysis for everything before they begin and here we've got page 62 under time boxes in the Pinback guide if you want to check out that one for yourself which I really do recommend alright how did you guys go with that one that was a little bit trickier let's see what we have next when reviewing the current progress of your with your project sponsor they notice that the system solution is missing a critical piece that will impact the benefit of the project okay the project sponsor approves the scope okay that's good to know your project has a planned value of 520 000 and an actual cost of 535 000. so we'd planned to be at 520 and but where actual cost so we've spent more than what we had planned to at this point so 535 so we're behind our budget so we're over our budget sorry let's see what options we have I'm not sure what we're trying to do here just to add this critical piece of scope I suppose work with the pmo to unlock the project management reserves for the extra work okay management reserves as we've been through a few times we've got our project budget then we've got our contingency reserves for any risks that pop up that becomes our I think I can't remember the name of it but over the overall project budget to which we and we add the management reserves on top of that for any scope that we didn't see but that is is actually part of the project is approved so that actually does fit that fits for what we're after here I wonder if there's any other answers that fit as well let's have a quick look but that one's looking pretty good ask the priority ask a product owner to reprioritize the backlog and see if the new work will fit I think if we do that something else will have to be bumped out usually and it doesn't say we're specifically working on an agile project either so this could be any type or any style let's put it maybe for now perform the work within your normal budget as your project is on track um I think we can't do that because we're actually over budget so that's a definite no and that's very handy to know so that's good raise a change request for the changes and gain approval for from the Change Control Board I think that one is also good but it looks as though the project sponsor has already approved that scope so project sponsor would usually be a part of the Change Control Board but it depends on the project depends on what you've outlined in your change management plan so the process for change management either way all of that to say it's already been approved I think we can say no there that gives us I think answer a is going to be our best one here there it is management reserves are set aside for unexpected activities related to in-scope work depending on the organization's policies management reserves may be managed by the pmo at the program or the portfolio level page 62 under budget in the Pumba guide 7th edition really good to read up on and you can go straight there you don't have to search for that and that's really really good to know all right how did you guys go with that one uh I think these are we're getting through them really well so this is quite good and we're halfway through this little section you're doing a great job let's keep going you're in the planning stages of an agile project where the functional manager and Senior users have provided the high level requirements and scope you have been asked to put together a project team that will be able to deliver quickly what will you do next okay so everything is ready to go we need a team and to pull those guys together it's a team that will be able to deliver quickly so what other features of a high performing team let's have a look select project team members from each City to ensure diversity of knowledge within the team knowledge might be one thing let's put a low maybe for now because I think an agile project specifically we're looking for things like transparency in our work environment but also co-location is always a big one where people can learn by osmosis by overhearing conversations and working together closely so put together a resource management plan outlining the resources required uh I think not just yet do we have a strategy behind this we're not sure yet let's put them maybe for now ask your pmo for current available resources and assign them to the work I mean yes we'll probably do that as well unless there's a better answer those are those are okay select a small team okay that sounds good that can work in the same area so they can solve problems as they arise all right that actually sounds very good and that's part of that co-location idea as well plus a small team keeps the communication channels small as well now I can never remember the formula but basically the more people you have it actually increases the communication channels so between this guy this guy this guy and this person and then this person this person and then everyone interacting and the ways that they can interact it increases exponentially the more people you have so that's why we ideally want to work in smaller teams it actually keeps things a lot more simple but for us I think we're going to go with answer d excellent work when planning for the team the project sponsor considers the ability and necessity for them to work in the same location small project teams that can work in the same room are able to take advantage of osmotic communication that's overhearing that information conversations and solving problems together quickly and they can solve problems as they arise so Pages 64 project team composition and structure in the pmbok guide 7th edition all right that's really good agile teams very good information to have very handy to know how did you guys go with that one all right let's get into the next one you're putting together a project team to deliver an accounting system to offices around the country the accounting system you're moving to has not been used by anyone in your organization before the project is quite high risk and the delivery needs to be right the first time what will you do next okay so if it's quite high risk and it needs to be right first time we might use a predictive or a waterfall way of work or an iterative way of work where we're iterating and then still releasing in one big bang so what are we going to do and oh look at that or select a small team that can work in the same area so they can solve problems as they arise maybe that's the right answer again who knows um I mean it certainly could work but I think we're looking for more other things other things like uh you know it hasn't been used by anyone in our organization before so that actually might not work for us we might need some information from outside our organization let's think about that use a predictive project approach okay that's what we're talking about here and Source part of your team externally all right if they have the skill sets in that new system oh that's what we were just talking about very good so that actually could be our one it could be pretty good train existing internal staff in the new system and then have them work on the project also could be very good you know obviously that's that that's definitely a way of working it might come with other problems because they may not know you know ways of working in projects or not have worked on projects before so you'll definitely be going through that forming storming norming stages of a team so that could be a little bit painful as well let's put a maybe on that it's pretty good but I still like this one the best perform a make or buy analysis on the different software options I think we're a little bit past that one at the moment uh yep I think we're past that we've already decided on that one I think for our purposes the best answer here let's go with answer B okay excellent the benefit that outside skills bring to the project are weighed against the costs that will be incurred with higher risk and a single delivery a waterfall or predictive project delivery approach is best so it covers a few different angles there and both of them are good page 63 project team composition and structure in the Pokemon guide 7th edition and that's really good to know and that's good team structure very handy still usable in the real world as well all right we've only got three questions to go in this little section you are doing great you're putting together a project plan for a change that affects nearly 10 000 stakeholders in your organization you have identified the affected stakeholders analyzed and prioritized them okay stakeholder analysis very good um high impact High influence usually and are putting together a communication plan to ensure that the right engagement is made what will you not include in your plan oh that makes it simple communication plan what do we not include in that okay and what have we got here we've got why what how and when I they all sound pretty good let's get a bit more information why should information be shared with stakeholders that's the why behind it the vision the reason for everything that's pretty good what is the best way to provide them the information definitely that one we want to work with them and give them what they need how can they make changes to the communication plan I don't think they're necessarily making changes to the communication plan it's more what we're here for and we will we need to take into consideration their feedback so so we're sort of doing that anyway I think that's a low maybe for now let's see what the last one is when and how often is information needed well definitely that one so we want to be communicating in the way that they need and how often they need as well so I think what we're not going to include let's put answer C for now excellent work planning communication for the project entails considering the following who needs the information who has the information that they need why should information be shared with stakeholders when and how often is the information needed what is the best way to provide the information what information does each stakeholder need that's actually really really good and that's in your communication plan page 64 in the promote guide 7th edition great stuff I think I'm actually going to use that in the real world because communication is so important on a project so important and when you stop communicating then you start hearing about it from your stakeholders as well so that's always you know they'll definitely let you know but I will also let you know we're down to last two questions in this section let's get to this you put together a resource plan for a large amount of physical inventory to be purchased from overseas you ordered the inventory during project execution however Global Supply chains were impacted and the shipment was delayed by three months significantly impacting your project what should you have done differently oh goodness okay how can we work with this um so we we did it during project execution is there a better way so sounds like we needed to do it earlier obviously but you know how do we get it go about that should we have hired a resource manager to take care of the resource tasks on your project maybe let's put it that as a maybe for now planned strategically about the timing definitely from order to delivery to usage definitely managing resource risks and their responses and I guess these uh this impact is a was a risk that turned into an issue wasn't it so were we even aware that this was potentially going to happen in the future and it was a risk on our project we needed to manage that risk this is actually a really good one this is a great answer let's see what else we have but that's probably our one and she what it means to track the inventory from arrival on site to the delivery of an integrated product even though we're tracking it that doesn't manage all those risks either does it so let's put a no for now sourced the inventory locally to reduce the impact of local Supply chains that's a definite possibility but for our purposes um uh you know it it seems like in the question it has to be purchased overseas so even though that's a good option if we have that option available we're not sure I think and plus would be if we were managing it correctly then that would be a part of managing it correctly as well so I still think let's go with answer B excellent work all right project teams whose projects require significant physical materials think and plan strategically about the timing from order to delivery to usage this can include evaluation of bulk ordering versus the cost of storage Global Logistics and more page 65 physical resources in the Puma guide 7th edition and that's yeah that's really really good information to have as well so wonderful things that we've learned in this set of questions and we're down to our very last one in this section well done guys let's get this done you are halfway through your agile project when there is a significant change to the Project's scope after it was found that the project would not be able to deliver the benefits that it had promised you check your project budget and there are contingency and management reserves available what will you do next okay good good information and we've been through those contingency management management reserves that information before already so take the project scope change to the Change Control Board for approval I mean maybe let's see what else we have use the available contingency reserves to make the appropriate change to the Project's scope and remember contingency reserves are for project risks and management reserves are for unforeseen scope usually that's still approved within the project so contingency for those that doesn't fit let's put a no for now review the change management plan for the Change Control process um I think we need to do something else first let's see what else we have re-prioritize the backlog and I see we're on an agile project so that does fit including the new scope and begin work on the highest priority item straight away I I think you know what actually that that actually fits so if we've got a new scope item or a new feature we just re-prioritize that and you know maybe this one drops off at the end instead so either way we're still working always working but we're working on the highest priority items and that's the way that agile and the prioritized backlog works so we don't need to worry about scope you know about reserves or anything extra extra cost we're just re-prioritizing and if something low value doesn't get done then that's what happens so for that reason I think we're going to go with answer d excellent okay changes may occur as a result of a risk event environment change a deeper understanding of requirements customer requests and more project teams should prepare a process for adapting plans throughout the project in an agile team this may take the form of re-prioritizing the backlog instead of a formal Change Control process with project baselines page 66 under changes in the Puma guides 7th edition and here we are we did 10 questions just like that that felt quite easy are we getting better at this maybe I know I'm certainly learning a little bit but more importantly I truly truly believe that you can pass the PMP exam but not only that it's one of the most important things you can do for your career projects are everywhere and they are not going away there's just more and more change happening every single day your skills are so important and we need them so much around the world you can do this keep going you have recently taken over on a project that is behind schedule and slightly over budget you raise an issue at the steering committee meeting where they advise that there is no additional funding available for the project and it the project must finish on time you believe that you can optimize the project process to bring it back on track okay that's good what will you do next how do we optimize a project process let's have a look use additional people and resources to the project or add them to to speed it up uh well that's it's not really optimizing the project process which just throwing resources at it so let's put a no for now utilize the Project's contingency reserve to Source the resources you need that's more about risk as we've seen in other questions contingency reserve goes on top of our project the cost there and that's for project risks and on top of that goes the management reserve for unforeseen scope that's still needing to be delivered for the project but that's not for us I don't think perform project activities in parallel completing multiple items at once instead of one at a time that's schedule fast tracking so instead of doing them in sequence we're trying to do them at the same time to speed it up that's sort of optimizing the project but not really the project processes oh ah here we go of course you use lean production methods which is actually specifically around process Improvement to reduce non-value ad activities anything that doesn't add value to getting that product to our customer and retrospectives for the team to suggest improvements that's process Improvement a hundred percent let's go with answer d excellent work all right ways of optimizing the process project processes for the environment include lean production methods retrospectives or Lessons Learned and finding where the next best funding is spent adding people and resources may not always improve things it can also increase the complexity and the communication channels on your project making it more difficult more ways to people for people to communicate and get messages wrong as well so for for mixed messages to happen page 71 under project processes in the pinball guide 7th edition and that was a great first question for us in this little section really really wonderful way to kick us off all right let's see what we've got next your project management office is optimizing all the projects within their portfolio they ask for your advice in tracking the type of work each team member is doing and how long it takes suggesting that they categorize and record their work in addition to the work itself oh a bit painful what will you do next so they're doing their work but now they also have to spend extra time just categorizing what work they're actually doing so that is actually non-value ad exactly like we were talking before with the lean production process Improvement methods oh and I see we have some of that in our answers here we go okay ask your team to record and categorize their work as it's important I think there's a better answer so maybe we do it but maybe there's a better answer here recommend an automated reporting tool where possible as categorizing that work is non-value ADD I think that's a probable yes for that one let's see if we can automate it or take it out of their hands because we want them to be doing the actual work instead recommend an automated reporting tool because they're because recording their work is value-add it's not value-added it doesn't add value to the End customer it's just a an Administration you know task for us to do ask your team to ignore the request and focus on delivering customer value only and you know sometimes we may want to do that but also this is coming from our project management office I think we want to keep them on side if we want to stay in a job potentially I think that's probably a good way to do it for our purposes let's go with answer B excellent work the time taken to track or record time can be viewed viewed as non-value added work that does not directly benefit the output or of the receiving customer or the receiving customer whichever you where you want to see that we should respect the pmo request but in addition to being efficient processes should also be effective page 72 project processes in the promote guide 7th edition wonderful stuff we're getting a really good range here improving ourselves working with teams working with risk okay I think let's see what we've got next but this is going really really well how did you guys go for that one I hope that was pretty good non-value-added activities you're working on an agile project as a scrum Master where the functional manager has worked with some people in your development team before functional manager being from the business so usually from a functional area they're the manager in that particular area she approaches them directly to see if they can add a feature to the product in their current Sprint what will you do next Okay so we've got our team this doesn't sound like she's the product owner even though she's from the functional area but she's approaching your team directly and trying to get them to do work so there's a better way to do this it needs to be prioritized first especially in an agile team let's see what we've got here adjust the Sprint backlog to allow for the additional feature maybe but then we'd have to prioritize it and maybe it's not up to us either I think the product owner needs to do this adjust the product backlog to add the customer requirement Sprint backlog product backlog right so an extra feature would probably go in the product backlog the Sprint backlog is just for the upcoming Sprints so how much work you know what are the user stories we can put in those Sprints that's the backlog of work the Sprint backlog so I don't think either of those for now ask the manager to speak with the product owner for the product priorities then protect the team from direct requests in the future this is really good because ideally in an agile team any new requests people have to convince the product owner that it's actually a good idea so instead of everyone just throwing ideas out there and saying mine is the most important now they actually have to come up with the goods and say here you know product owner I have this great idea should we can we prioritize this and here's why and if the product owner is not convinced they're not going to do it it's they're the single point of decision for the team for prioritizing work the highest value work for the team I really like this one let's see the last one just in case ask the manager to create a change request so it can go through the proper process potentially except we're in an agile team so I think the prioritization method is probably the best so let's go with answer C fantastic work project managers have a responsibility for assessing and balancing project team focus and attention this may involve protecting the team's production capability so their team health and their satisfaction protecting them from all these outside influences and the politics and all of the stuff that goes on that isn't valuable to their work in agile this also means being a diversion Shield really really good so we've got our team Happy People everyone's coming at us with requests but they can't get to us because you know our product owner and our scrum Master are shielding the team from those requests wonderful stuff and that gets in the way of them making progress of their work so we don't want any of that under page 73 maintaining project team focus in the pinball guide 7th edition a really really good way and as you can see a little bit of agile sprinkled in here a little bit of waterfall questions we've got all sorts so many different types of ways to manage a project all right how did you guys go with that one let's get into the next question you're doing great part of the project management plan is a detailed Communications plan which has the stakeholders on the project their communication needs and how information will be communicated while this is being signed off by the project sponsor you receive many ad hoc requests for information from new stakeholders what will you do next so our communication plan we need to update this and make sure we've got all the right stakeholders and also what their communication needs are I think because then obviously not getting what they need so let's see what we've got review the communications management plan to include the stakeholder as well okay very good did I read ahead yes perhaps that was spot on I hope they're all like this one with the information that they need exactly as we said and their communication Pro preferences wonderful wonderful stuff good answer that one let's see what else we've got just in case but I think that's probably going to be our one create an information radiator and ask the stakeholders to pull the information they need that actually is pretty good it's pretty good but we're talking about the communications management plan so I mean that's actually a pretty good answer but I think this is still a better answer ignore the new requests as you've captured all the stakeholders you need to in your plan obviously not because we've got ad hoc requests ask the new stakeholders to review your Communications management plan to see how you're Distributing information it's up to us to get the feedback and put it into the communications management plan ourselves let's go with the answer I excellent once collected information is distributed as indicated in the project management Communications plan and abundance of ad hoc communication requests May indicate that the communications planning was not sufficient to meet stakeholder needs it's a good idea to review it page 72 project Communications and engagement a really good way to get into that Communications always be communicating in the ways that our stakeholders need excellent stuff we're nearly halfway through you're doing great guys let's keep going you're working on a high value construction project to include smart home components within multi-million dollar buildings after completing a make or buy analysis you find that it will cost seven hundred thousand dollars to make a new system or five hundred thousand dollars to buy it from a vendor you prepare a procurement management plan to purchase it so we're going to purchase this thing from a vendor what will you do before conducting a procurement or tricky okay we plan communication we plan procurement we've got our procurement management plan what do we do before actually conducting that procurement uh let's have a look work with your project team to complete as much as we can in-house as possible that's not what we're doing so we can definitely Mark that one off work with Contracting Professionals in our organization yes so there's usually people who understand the legalities of these contracts to develop an RFP sow request full proposal and statement of work so the work that needs to be done and the terms and conditions that actually sounds quite promising so let's see what else we have but that's probably looking pretty good adjust your stakeholder register to include the new vendor and add the scope to yours to your work breakdown structure dictionary not the right order we should have that scope already that's how we create our statement of work comes from the scope that we actually need delivered isn't it it's just someone else is going to be delivering it this time so let's put a no for now work with your project team to develop an rmp SMP and list of resources ah I don't know what these are uh are they rmp is this a made-up term I'm not sure SMP I cannot think of what that is uh uh four so it's either I really like answer B this one I'm not sure of uh if it's answer D instead then look we'll have to take one for the team but I think it is it's going to be answer B let's have a look okay good we got it right but let's see if we get any tips here Pro prior to conducting a procurement the project manager and technically qualified project team members work with Contracting professionals to develop the request for proposal statement of work terms and conditions and other necessary documents to go out to beard page 74 working with procurements it didn't give us any tips on this so I'm not sure about that I'm not sure if that's a real thing if it is uh leave a comment and see if you can find out I'm not sure I don't think it is it's probably a red herring actually so be ready for stuff like that just in case and also we're now over halfway through great stuff guys how did you guys go with that question was a little bit trickier I think they're all going to be a little bit tricky on the real exam we have to be ready for it you can do it a missing item has been uncovered in the project scope that your project team cannot deliver okay so a missing item in the scope is this our management reserves again let's have a look the item is not complex and seems to be fairly readily available from various sources oh maybe it's a procurement item again you are ready to move to Source selection and choose a vendor that will meet their needs what will you do before sending out those bid documents to vendors oh did we get any tips from the last question what will we do before sending out bid documents I think we would already passed that stage maybe in the last question let's have a look at what we've got prepare a request for a proposal for vendors to provide a solution to your needs that is the bid document I think wasn't it so that was part of the bid documents that we send so let's put a no for that one a request for quote to determine the best price from the vendors what would we do before sending out so both of these are Bid documents um I think so I'm going to put a no for that one because we're doing before that so prepare a request for information to gather more information and viable sources from the market that would happen before these these items I think so that's a probable one that's pretty good let's put a maybe for that one review the procurement management plan for your Project's procurement process do you are ready to move to sort that's actually pretty good as well but also would we be creating the project the procurement management plan and some of this information would go into that procurement management plan oh so between both of those if we were creating it maybe and putting some things into the procurement management plan I would put that as a yes but I think before all of these bid documents we need the information we need that information and that will go into the into this plan as well so I think for our purposes let's go with answer C okay good stuff the request for information is used to gather more information from the market prior to sending out bid documents to a set of selected vendors a request for proposal is used where scope is complex or the buyer is looking for the vendor to provide a solution request for quote is when price is the deciding factor it's just a quote and this is direct from the pmbok guide seventh edition as well page 75 the bid process very very handy information to have how did you guys go with that one there are a few tricky questions in there sometimes there are a few answers that will seem correct and we have to choose the most correct one it can be very difficult but I know you can do it what have we got next you're working on a project where part of the work is planned carefully up front and another part is subject to change you negotiate terms and conditions including cost delivery and payment dates the vendor is concerned about confusion that might occur between pre-planned and changeable work what will you do next okay so sounds like we're working with a vendor we've got some pre-planned work some changeable work and you know is there confusion about this how do we manage this with a vendor okay or this could be tricky and it looks like we've got contracts uh okay maybe it's the different types of contracts to manage this this could be good use a firm fixed price contract to ensure the cost is fixed but the scope can remain flexible incorrect uh firm fixed price is just here's the scope and here's the price and that's it so let's say no for that one use a time and materials contract to ensure only the time and the materials used are paid for that could be pretty good so but again we've got these two different sorts uh still could get confusing exactly like they're saying so how do we avoid that confusion adjust your project plan to suit either a predictive or adaptive approach to reduce the confusion so do we choose either one and just lock it in either one agile either or waterfall I think we need to go with both I prefer like a hybrid method here so we'll say no for that one for now use a Master agreement for the overall contract with an Adaptive with adaptive work placed in an appendix okay that actually could work especially because we're talking about contracts we have a master agreement on what we need and then for the Adaptive work that's placed in the appendix so that we're aware that there is a is some changeable work happening as well it's still part of the contract so it still works for us it gets rid of any confusion because it's all written in the contract I think that's actually pretty good let's go with answer d okay great for projects that use an Adaptive approach for some deliverables and a predictive approach for others a master agreement is used and the Adaptive work may be placed in an appendix or a supplement this allows the changes to occur on the Adaptive scope without impacting the overall contract and remember again this is direct from the pmbok guide 7th edition page 76 the bid process Contracting for that particular section if you want to check that out for yourself and I really recommend you do you know this is really good you can go straight there and check that out and you know what else we can check out is the last three questions in this particular section wow we're really getting through this you're doing an amazing job not far to go let's keep going you're working in an agile project where there are vastly differing levels of product knowledge within your team the scrum Master suggests that you try to gain knowledge by osmosis because the project information may be lost when only communicating by email what will you do next so how do we do things by osmosis we've spoken about this before it's when we're all co-located in the same space so that we can overhear conversations and you know we're actually information is just seeping into our brain because we're overhearing it naturally and we're close to the action we're close to the things that are happening this is such a powerful method and it really really does work and I can see co-locate the team to capture the benefit of each person's tacit knowledge that's knowledge that they can't readily explain so it just happens in those conversations I think that's actually really good refer to the organizational process assets to capture the team's explicit knowledge it explicit knowledge is things that can be explained so like a like a processes that we can put in place for example but that's a no for now osmosis is that co-location refer to the project Knowledge Management System and capture the Project's explicit knowledge very similar again good practice but not for us create a process to capture the team's tacit knowledge that's uh we're creating a process to do that but the process actually is co-location usually we're all together we're overhearing things I think for our purposes let's go with answer a excellent work all right learning by osmosis is capturing information from immediate surroundings such as co-locating the team tacit knowledge is information that is not straightforward such as experience insights and practical knowledge or skill explicit knowledge can be readily codified using words a process or pictures and that's page 77 under explicit and tacit knowledge in the promot guide 7th edition how did you guys go with that one I think that's pretty good and we're learning more about creating our own teams as well really powerful stuff last two questions let's keep going you're doing great you're working as a product owner this time and have placed high level information about the product in the product backlog that's good the highest priority feature is at the top that's also good senior users in forming the project are unable to clearly articulate their requirements okay that's a clue and they're concerned that the product will not truly meet their needs what will you do next so how do we articulate requirements better let's see prior proceed with the highest priority item during the first Sprint I think this is more about articulating requirements so potentially no work with the customer to create mock-ups and prototypes to discover what works for them I think that is probably a yes because that's helping them get information on those requirements as well so that's actually pretty good ask your stakeholders to submit a change request and update the project scope accordingly again we need to articulate requirements so let's say no for now begin breaking down the work into user stories to place into the spring that could work but only if we're clear on what we're delivering which is what requirements are and to get that we need a mock-up or a prototype or a wireframe or a storyboard so that we can get an idea of what it's going to look like and adjust that before we begin I think for our purposes let's go with answer B excellent work on projects that do not have clearly defined requirements prototypes demonstrations storyboards and mock-ups can be used to evolve those requirements in these situations stakeholders are more likely to take in I'll know it when I see it approach now they can see it and they can say oh that's actually not what I thought it was going to be let's adjust it page 83 under revolving and discovering requirements in the pmbok guide 7th edition wonderful stuff guys you have made it to the last question in this particular section amazing work and I know I have learned a whole bunch actually so I hope you have too and I hope you've had some good fun this has been really good a great way to learn let's do this last question then we can have a break a nice relax well deserved relax you are gathering requirements for a new feature in a customer management system the product owner has given a user interface feature as the next highest priority and you are co-located with the team receiving the benefits everything sounds great so far what will you do next show the customer team how the new user interface will look as they will be using it so we've got our item we're co-located with the team I think we need to break this down so we've got our product item need to break it down and put it into the Sprint backlog so we've got our product backlog uh we work with the team make sure everything is is good get the user stories and put them into the into the Sprint backlog I think uh communicate the requirements to developers with a coherent logical flow of ideas oh that is actually that's also quite good we need those requirements maybe we need to mock-up again so let's put a maybe for that one elicit requirements into user stories oh so that's taking it to a new level I think so now we're getting those requirements we're putting them into user stories using acceptance criteria oh that's much better that is clear verifiable and traceable even better again so good way to put your acceptance criteria make sure it's clear verifiable and traceable back to the requirement that that we wanted in the first place I think that's actually a really good one show the mock-up or prototype to the developers and ask them to develop based on that again could be good or there are quite a few good options here but I think the best one with acceptance criteria and eliciting those requirements is answer C let's have a look there it is elicitation means to draw out well-documented requirements are clear concise verifiable consistent complete and traceable those are all really really good things that's in good information to have a prototype is useful but may need more information for developers to turn into a product clear purpose coherent ideas controlling flow concise expression and con correct grammar are part of the five C's of communication so separate still good but not for us at this stage page 83 under requirements elicitation and you know what else is a really wonderful thing is the fact that we have made it to the end of this particular section of questions it's a lot of work and I really respect the work that you guys are putting in to learn this information to improve your project management skills but more importantly to prove those skills through a wonderful thing like the PMP exam you are doing an amazing thing something that will truly help and improve and change your life and I really really believe that you can do this with the work that you're doing and the improvements that you're making every single day keep going I truly believe in you you're working in an agile team who are trying to break down the project requirements and the scope they have created a scope statement and a work breakdown structure excellent but are not sure how it will work when that now that they're using Sprints and user stories okay so is this about how to use a work breakdown structure sort of a tool or you know that way of working in an agile way of working as well because it definitely can fit we might just call it something different for example so what will we do next okay assign activities to each of the scope items in the work breakdown structure and place them on a Gantt chart that's what we do in a traditional project and it certainly can work in an agile project as well it might be our product roadmap but we just put it in the view of a Gantt chart in a in a project schedule so there's our items over time I mean so maybe let's see what else we have just in case create a product roadmap with the team using the lowest most detailed part of the work breakdown structure usually a product roadmap would be the the feature level so like a high level not the most detailed level most detailed level is the user's stories usually so I think maybe a maybe for that one or a low maybe maybe a no group the work by large themes of customer value such as shown as epics that sounds promising and then break them down into smaller user stories to complete in each Sprint and that's exactly it so we've got our features and we break those down into user stories and then we place those in the Sprints and that's the agile way of working and that's you know that's the way we we do similar work breakdown structure or a decomposition of our work I think that's actually really good let's see what else we have ask the team to trace the requirements properly using a requirements traceability Matrix also good practice but probably not what we're after here I think the best answer for us is answer C excellent work all right one way to identify scope is identifying the themes of customer value Associated by a common factor such as functionality so we're sort of releasing a usable feature ideally of customer value could be data source or it could be security level you know how are we grouping this thing together these are shown as epics which are too big to complete in one Sprint and we have smaller user stories which we can complete in one Sprint within those page 84 under scope decomposition wonderful and that's again direct from the PM book guide seventh edition direct learning too easy wonderful way to do it how did you guys go with that one I think that was actually pretty good let's go let's see what we've got next your project team are trialing an agile way of work the product owner has a Clear Vision for the product there is confusion in the team as to how much work should be done on a user story before it's taken to the Sprint review and how they will know that a story is complete what will you do next okay traveling and agile way of work not sure how we know when it is done this sounds to me like the definition of done and there's definition of ready and there's definition of done definition of ready is how we know that work can begin on an item and that might be at different stages as well so how is it ready for our you know analysts or to get the requirements how is it ready to be developed how is it ready to be tested there's different levels you know and it doesn't have to be complex you know we can make it very very simple but each section usually has a definition of ready and each section has a definition of done how do we know when it's a when it's complete so is there something like that here there is looks good refer to the user's story acceptance criteria that's wonderful and your team's definition of done I love that one let's see what else we have just in case review the user story with multiple users to ensure it's correct yeah I mean that's probably a good practice might be part of our definition of done actually so you know so maybe ask the product owner to sign off on the completed user story that's also good practice because the customer is then accepting that item but again that's going to be part of our definition of done ensure quality testing on the user story is completed and passed also good practice these are all great answers but the best answer for our purpose is let's go with answer a all right wonderful different ways to describe component completion include acceptance or completion of criteria technical performance measures and the definition of done quality testing will be done to the acceptance criteria as will the product owner sign off so it all feeds into that acceptance criteria into that definition of done page 85 completion of deliverables in the pmbok guide 7th edition wonderful work how did you guys go did you beat me to that one that was you know pretty straightforward I really like that a little bit of agile Centric wording there as well which we're going to see more and more of all right let's get into the next question you've been working closely with the quality manager of your project planning the budget for the project phase that's due to begin in the next two months sounds like a waterfall project they mention the need to to budget for appraisal costs to avoid quality issues in the future what will you do next okay called the cost of appraisal there's different types of costs costs of prevent prevention for Quality so the cost of quality prevention costs appraisal costs if there's failure costs if we catch a defect and there's internal and external failure so if we catch a defect before it reaches the customer it's internal if it reaches the customer and it's a failure uh you know in the quality then that's external failure costs the worst kind and the most costly as well so appraisal costs where appraising we're reviewing we're checking this is our testing testing phase so let's see what we've got here ensure there's enough for training well that's I think we've had that in a previous question that's probably preventative so we're we're preventing quality issues by training people for the future so it's a good practice but not for us ensure there's enough for a quality tester to verify the deliverables against the agreed specifications that sounds pretty good from our testing point of view ensure there's enough to create a quality assurance plan I mean maybe as well well but probably not as direct as this one so I still like be better I think ensure there's enough to allow for rework or rectification when defects are found and so that's our that's our failure costs there so we'll put a no for that one for now and I think even though these two are both good let's go the best one answer B let's go with that one wonderful work all right this question is on the cost of quality prevention costs are training or quality planning appraisal costs oh so there we go that's maybe uh prevention instead so that's good to know appraisal costs are verification or audits internal failure is waste defects and rework external failure is customer complaints repairs and servicing and warranty claims again direct from the pmbok guide that answer page 89 cost of quality a really great way to learn and a great way to do it how did you guys go with that one I thought that was pretty good we're really getting through these you're doing a great job let's see what we've got next your agile project has recently had multiple quality issues project features have been prioritized by the product owner and broken down into user stories what will you do to help reduce the cost of quality issues the most okay so it seems like everything is going you know quite well from an agile way of working perspective what will you do to reduce the cost of quality issues the most okay quality test each user story according to its acceptance criteria before release I think that's pretty good yeah I mean that's that's what we were looking at before that's that quality testing that appraisal costs but I wonder if there's something better or earlier that we can do here let's have a think advise the team that any quality defects will come out of their bonus and that's a pretty harsh way to do it and you know maybe that will work for a little while but also it's pretty harsh uh you might sort of lower the engagement of the team I mean it could work but I don't love that answer there's probably a better answer in there somewhere perform testing all in one go at the end to reduce the cost of testing resources for an agile team or for any team this is a particularly agile project but we test at all levels so at the unit unit test System test user acceptance test and regression testing so we you know equality is everyone's responsibility in an agile team from the very beginning to the very end so that's a no so far this is the best one and sure a Triad of developer oh this sounds promising tester and customer is involved during the requirements and design so reducing quality issues um I mean testing definitely is good but here quality issues we're sort of catching it before it becomes an issue so we're getting the testers involved we're getting the customer involved we're getting the developer involved and we're making sure that things are correct from the very beginning this actually could be the answer answer D because what you know it's there's different stages from the very beginning our you know requirements and acceptance criterias uh then you know goes into the development then it goes into testing but if we're catching all of those defects during testing they have to go back to here and it's it's more costly than doing it at the big at the beginning so when we're doing it and getting it all right from the very beginning so this is pretty tricky it could be either one a or D but if we're going to reduce the cost of quality the most let's go with answer d okay cool that could have gone either way so that's a little bit tricky um this question is about the cost of change let's see if we get some tips here the cost is least during the requirements and design okay and is 20 times during the build uh 50 times during test and 150 times if a defect has to be rectified in production so this is a good good point if we catch it early on it actually is quite easy to fix so we can say oh that's a little bit wrong it might just be a wording change in the acceptance criteria but by the time we've developed it now we have to change that acceptance criteria and redevelop it and then by the time we get to testing we have to do all of those things and retest it and if it gets to the customer it's even worse again so that's why the cost increases over time as these things you know as we go through the process of our project which is very handy to know so that's actually really good if if the requirements design and acceptance criteria is incorrect extra quality testing won't help now that's a good point as well page 90 under the cost of change that was pretty good I actually learned quite a bit with that one how did you guys go with that one that was uh yeah that was pretty good I'm definitely learning a fair bit here and again direct from the purple guide so handy to know all right next question you're working in an agile team where Executives in the team you're delivering to are asking for a large display of reports to be created every two weeks showing how the project is tracking and updating them on the costs and benefits what will you do next okay large display of reports is there another way to do this we're in an agile team can we have an information radiator so you know a large visual display our kanban boards burn down charts our risks all in the one place so people can pull that information and see it at any time let's see what we've got collect the planned value versus earned value to show the executives any variance in the plan I think there might be a better answer than that one co-locate the team with the executives so they can answer any questions as they arise ah you know that actually could be a good idea anytime we're co-located we just pick up information so you know they would be learning by osmosis which we're hearing a lot you know you're picking up conversations you know things are going on they can hear it directly that's a pretty good answer but maybe not the best one suggest a demonstration of the feature developed during each Sprint instead and a burned down chart of future product releases right okay so we're not going with a big visual you know area we're going with a direct demonstration so a Sprint review for example what did we complete what did we create what value are we creating and here it is we're going to demonstrate it and show it to you you know right here and now plus the burn down chart of future product features so we've got product features coming up and we're completing them over time that's actually pretty good so it's a high level burn down chart all right yeah that's actually pretty good and it's definitely agile Centric that one create the desired reports for the executives to keep them happy I think out of all of these let's go with answer C wonderful work all right the value of measurements is not in the collection and dissemination of the data but it's how to use that data to take action to take appropriate action so that's really handy to note sometimes you'll be working in companies and they just create reports for the sake of creating reports has that ever happened to you maybe not you directly but someone you know perhaps agile projects demonstrate value and features delivered so we're demonstrating the actual item itself the real customer value and we use live information radiators instead of large reports to stakeholders page 94 under measurement performance domain and that's again pinbook guide 7th edition it's right there very agile Centric so now as you can see we're starting to get a lot more agile questions there how did you guys go with that one all right I think that was pretty good let's go to the next question multiple features have been released but they are not having the effect that the product owner believes they should your team are using some key performance indicators kpis to track performance and you agree to move to more leading indicators okay what could you use as examples of leading indicators on your project so we've got leading indicators and lagging indicators lagging indicators are things that have happened so information that's already happened work that's already happened leading indicators are is you know how do we figure out what's going to happen in the future and that can actually be very tricky so let's see what we've got here it's usually around you know do we have the right processes in place or do we have you know the right requirements for example um so yeah it's a little bit more fuzzy but let's see an increase in customer usage once the feature is released that's lagging such as sales and repeat purchasing we'll put a no for now stakeholders who are not engaged and a lack of a risk management process so definitely disengaged stakeholders will lead to poor performance in the future that is a leading indicator and again it's a bit fuzzy but it's still leading so that's actually pretty good velocity of the work completed in each Sprint and cycle time of the user stories now that is work completed again so it's already happened it's lagging um you know if we can use it to forecast but it's still a lagging indicator because you know it will change as things uh as we're completing those things and updating the the user stories in the cycle time variance in the schedule between planned and actual time taken again a lagging indicator I think for all our purposes let's go with answer B here all right great work there are two types of kpis leading and lagging leading predicts changes or Trends in the project and include a lack of a risk management process stakeholders who are not engaged poorly defined project success criteria oh that's a good one how many times have you been working on a project and we actually don't know what success looks like so everyone has a different version of it and now you know that also leads to disengagement you know lots of leading indicators there lagging indicators include work completed or schedule variants page 96 leading indicators in the book guide seventh edition all right I think that was another good one now we're getting into metrics and measures there's a whole section on metrics and measures in the promote guide as well so that's really good to know and we're more than halfway through this section so you're doing a wonderful job we've only got a couple to go let's see what we've got next you're working in an agile project team that has increased in size and complexity since the project began it re in reviewing the throughput of work with your team you notice fewer and fewer user Stories being completed so we've got increase in size and complexity and now the work is starting to go down and the roadmap of features scheduled to go live is being pushed out so our schedule is being pushed out so what are we going to do next so can we reduce the complexity here somehow place a limit on the work in progress and work with the team to reduce the cycle time okay I mean agile team that's certainly an agile you know agile Centric wording there so the work in progress that could work from a context switching perspective so if we've got too many things that we're working on and we're switching between these you know every day then we actually it takes time to get back up to speed on each different feature so it's actually pretty difficult you know we waste it takes more time there and increases the complexity you know just in in that context switching but if we've only got one thing that we're working on or two things that we're working on here um you know then that's a lot easier for us to just focus and push through and get it done that could be the one but let's see what else we have increase meetings with the team okay definitely not I don't know if you've seen you know recently Elon Musk in Twitter sending that email out sending that you know notice out to all of his staff he's basically reduce meetings get rid of meetings you know only meet if you absolutely have to and that is also you know good practice so we're we're certainly probably let's not do that one for now according to Elon Musk ask the team to work overtime until the number of features reduces uh you know and actually this is anti-agile because we we don't really want Peaks and troughs we want a sustainable pace so we have six six days here and over you know burn out here that is a terrible way to run a project um you know for various reasons but if we've got a sustainable Pace then everyone's there often all the time just completing work and you know engaged in the project that's the way we want to work I think so that's a no for now put a pool system in place where the team can pull work only when they are ready oh you know and that's actually pretty good except here's what will happen they will have you know they'll get blocked on a piece of work and instead of just focusing 100 on it and unblocking it they will pull a new piece of work and then all of a sudden we've got too much work in progress so that is a lot of your agile stuff going on here which is quite wonderful and the reasons why we do it so I think for our purposes though out of all of those options let's go with answer a okay great work with more work different tasks and increased complexity the team are likely context switching between too many different things kanban aims to limit the work in progress to avoid that context switching and multitasking other things we can use are reducing cue size and batch sizes and reviewing process efficiency all right so also those are other things and that's actually pretty good to know as well page 99 what to measure under delivery in the promote guide 7th edition wonderful work all right how did you guys go with that one you were doing great only three to go in this little section you're working on an agile project where the project customer wants a reliable way to measure the project performance and you know you first need a baseline oh this is good what measures will you show to your customer as part of your agile project okay so this is good what do we measure in an agile project should be pretty straightforward and this is what we show to our customer oh this is tricky because team velocity I see is an agile you know thing that we do for measuring but we try and keep that within the team not we don't really show that to our Customer because it's an internal team measure start and finish dates you know maybe but probably better to our customer the rate of features completed so here's our feature here's our next feature and here's what we're delivering here's the value that we're delivering to you as the customer I think agile wise we're going to go with answer C schedule and cost variance you know more of an old waterfall way of working and again an internal team measure let's go with NCC wonderful work an agile project tracks and demonstrates the actual features delivered with a stable team cost is most often fixed oh so that's good to know not really cost variance because cost is fixed our team is stable we just deliver features until we run out of money the schedule is also fixed and the scope is variable depending on what the customer wants to prioritize in the given time so the scope is the thing that changes page 100 under Baseline performance in the pinball guide wonderful work guys how did you guys go with that one did you beat me to that one as well possibly I think we're getting pretty good at these all right last two the product owner has worked with a team of senior users to gather feature ideas they now have a list of more than 50 ideas for your team to develop which has far too many to complete in the time frame that you have what will you do next and what do we do if we've got too much work and not enough time we prioritize the things so the most highest value and potentially you know the the least effort or the easiest things to do so what are those things let's do them first and over time we'll be delivering you know the lower value items as well if we get there but first the highest value items so let's see if we've got that here and I can see it already so ask the new product owner to prioritize the features using cost to benefit that's one way to do it so pretty good and then deliver in their priority order until the time all the money runs out that's definitely the way that we're going to go what else do we have just in case start work on the smallest features first again we want highest value so that's enough so ask the product owner to return and ask for a shortened list you know we can have a long list but we just prioritize it with the highest value Workshop the features with a wider audience that could get messy and get a completely diverse view on their priority we actually want the product owner to own this and be the the one person who decides so people have to convince the product owner not the other way around and so because of that you know because they have the deciding factor we can move much faster we don't have to get a cast of thousands so again that is a no let's go with answer d wonderful work product owners prioritize features based on business value metrics that measure business value include cost to benefit ratio planned to actual benefits delivery return on investment and Net Present Value so all of those things good metrics to know page 102 under business value in the pmbot guide wonderful work we made it to the last question we're nearly there what you're doing great you know and these have been this has been some good learning for me I know that let's do this last one we're nearly there your agile project team has only recently formed the product is still unclear and there have been disagreements in minor conflicts over the past two weeks as the team find their Rhythm what would you would like things to improve but you can't quite pinpoint or address the problem what will you do next um so so do we need to problem solve with our team oh probably again agile wise what do we do retrospectives so if we're stuck we hold a retrospective we find out what is challenging us you know what's not working well we get that feedback take actions and we problem solve and move forward from there so let's see what we've got I see there's a retrospective here have the team complete a net promoter score that's interesting with comments so that's just you know one to ten how am I enjoying my time in the team for example um usually it's would we would we recommend it to a friend um but you know it can be adjusted for any situation it's like a customer satisfaction measure and ask for improvement ideas at the next retrospective net promoter score is an interesting choice here uh but look I think we could roll with that especially with the comments and then the retrospective is the real key where you know inviting that feedback improving our process I don't see it anywhere else so hold a workshop with your team and ask them why they're unhappy maybe but that could just turn into you know a a miserable session you know where people are just complaining we're not actually improving so pretty important there raise the issue with their line managers and ensure that everyone is working on the issue we actually have to work on the issue ourselves and work with the team have the team pair up together so they can learn from each other that's a great practice but it's probably uh you know there might be other things that we need as well that might actually come out of our retrospective as an action so let's go with answer B all right great stuff measuring stakeholders can be done with a net promoter score or a satisfaction score especially with a comment or a mood chart so that's pretty good to know Improvement ideas are captured during retrospectives for most agile teams pairing is another agile practice but it's not as relevant here at least initially and again we might get to that stage after some improvement information or decisions page 103 measuring stakeholders and you know what else we're going to get to is the very end of this little section of questions you've done an amazing job but more importantly I really truly believe that you're doing the right thing and that you can pass your PMP exam what you're doing is so important because projects are everywhere and this preparation will set you up for the rest of your life you're doing a wonderful job keep going the project has faced serious impacts in getting materials with Supply chains being disrupted and a global pandemic sounds familiar and is currently three weeks behind schedule okay you take this information to the next project steering committee meeting where they advise they need more information on how much the project project will end up costing okay what will you do next so we're behind schedule how much are we go how much is our budget going to be budget completion or something similar let's see what we've got here use the current budget with no deviations until it runs out we won't help us with what they need to know so let's see if there's a better option use the project burn down chart to see the burn rate of accounting funds that's more about the features or the user stories that are being completed so we thought that it was going to go this fast and it's going this fast you know we could use that for a bit of variance analysis but I don't know if that's the best answer here use regression analysis which is um so we see how it's tracking and we forecast that out into the future so that's regression analysis and it will end up around here to see the current rate of spending and see where the final cost will end up I don't know if that's the best answer hopefully there's another one here I'm running out of options use the Project's estimate at completion so EAC there we go so you've got your budget at completion which is what we think what we thought initially the budget would cost and the estimated completion is once we've been going you know is there a variance are we lower or higher than we thought we were going to be that ends up as our estimate at completion to show the steering committee the most likely final cost I think that's probably going to be our one even just by a process of elimination actually so let's go with answer d all right wonderful this question is talking about budget forecasts regression analysis may work but the best answer is estimate completion which is the budgeted completion divided by CPI the cost performance index which is earned value so how much have we actually completed divided by the actual cost how much have we actually spent so yeah there you go that's the formula for that you may not get the direct formula but you'll get a similar question you know around these formulas like you will on the PMP exam pretty good page 104 under forecasts directly from the promote guide wonderful stuff how did you guys go with that one all right let's see what we've got next you're working on an agile project where the project sponsor and executive managers require lengthy reports about how the project work is going each week about the project work each week this takes you and the project team a considerable amount of time to do and reduces time spent on creating the actual product this is non-value AD work from the lean you know lean thinking and lean production method what will you do next okay let's see if we can reduce this somehow and it's an agile project so what do we do instead we demonstrate to the customer we have visible charts and visible areas and information radiator that people can pull information from okay reuse most of the information each week so your time spent on them is reduced oh that's well I like that it's cheating a little bit actually but I think there's probably a better answer there um suggest the leaders come to the Sprint review that could be good and gather any information that they need from the information radiator there we go that's our big you know it's an open visual transparent area it's got all of the items the features that have been delivered uh you know perhaps things like the team velocity current team risks maybe burn down chart how everything is going they should be able to see everything there and the Sprint review is demonstrating the actual product that we've created in the last Sprint so whatever usable piece of value I think that's probably going to be our one ask your project sponsor to wait until a steering committee meeting for the information it's better if they can get it any time and you know get it live as well which is what that information radiator is share your working project schedule and budget with the executives instead of creating the reports and that that could work and it's sort of similar to the information radiator but that one's better because they can just go there anytime this one we have to actually physically share it so this one is more live I think let's go with answer B excellent work all right agile teams showcase actual work completed at the Sprint review information radiators also known as Big visible chance are visible displays that allow anyone to pull that information from they can get at any time they're often low Tech and high touch so it doesn't have to be you know a technological thing could be a whiteboard for example but it's high touch because we're looking at it you know changing it updating it every day and they contain information on work completed or remaining tasks risks things like the kanman board burn down chart like we said page 108 under information radiators in the punbot guide 7th edition wonderful stuff how did you guys go I think we're really getting into a lot of agile questions here so this is quite a good way that it's going I think it's really good let's see what we've got next you're working on a project that has planned as much as they can up front you would like them to move to a more agile way of work currently the work is hidden the team catches up only once a week in a working group and it's hard to see what each person is working on and to keep track of it what will you do next okay I mean this is where a lot of agile tools and ways of working really help it makes it visible and transparent and we catch up more often as well so let's see what we've got ask your team to report on their work in a written status update each day so you can keep track I think no that's that non-valuated work that we're talking about before have more working group meetings so you're always up to date on what the team is working on I think there's probably a better answer than that we might have a stand-up meeting but it's very short 15 minutes each day usually just so that we can remove blockers make sure that everyone has what they need to get the work done for that day ask the team to work to move their work to a central visible task board like a kanban board and then have a short meeting each day to discuss progress on their cards like a stand-up meeting I think that is probably where we're going remove the team meetings altogether and trust your team to get the work done you know I'm definitely having trust in your team is a good thing but also talking with your team is also a good thing so I think this one for our purposes let's go with answer C excellent work all right this question is talking about stand-ups and a kanban board task boards are part of the visual controls used we're an increment of work moves from to do to in progress to done you know maybe testing sign off development any phases that you need in your project the team meets for 15 minutes each day to discuss progress and raise any impediments which are blockers to their work page 109 visual controls task boards in the permit guide if you want to go and check that out directly wonderful stuff really getting through these questions so let's keep going you're working on a hybrid project where the majority of the work has been planned up front the team manages their work via a kanban board and report on progress and blockers each day as the project evolves stakeholders have added more and more scope to the product with one executive raising an urgent feature that needs to be added what will you do next okay so it's hybrid work we've got a kanban board and we do the stand-ups with reporting and progress and blockers but now we've got all of this scope coming in so too much scope what do we do then we try to prioritize it let's see what we've got limit the number of cards in ready or to do and ask the product owner to work with stakeholder requests noting the need to swap the new item for an existing item that is prioritization so they might want to add something but it's going to cost them because we're going to have to bump something out we can only work on so much so we want to be working on the highest priority items at all time the highest value items that's actually pretty good let's see what else we have just in case match the number of user stories to the team's velocity to ensure a sustainable Pace uh yeah probably not for now work with the stakeholder to raise a change request and note the outcome in a change log that could work as well but more obviously if we're if we keep adding scope it's not really a change it's more of an addition so for this one where we've got a bit of an agile way of working I think prioritization is still the best way review the impact of the scope change with the stakeholder using the work breakdown structure dictionary I think we may not use that to review the impact we might use a variance analysis you know is it going to impact our schedule or our cost I think that's probably a bit of a red herring answer that one so let's go with answer a excellent work all right as a hybrid project using kanban and some agile ceremonies the most appropriate way to manage the work and scope is by using a work in progress limit on the board the product owner has the final say on prioritizing features in scope so they work with the stakeholders to ensure they understand that something might be deprioritized by adding a new feature and sometimes that's hard for executives to handle but you know we have to be firm and strong and with a strong product owner in place who can make them you know can help them understand that you know then obviously again if as long as we're delivering the highest value stuff it shouldn't be a problem page 110 under kanban board independent guide 7th edition all right really really doing well and we're nearly halfway through this section so you're doing a great job let's keep going you're working as a product owner in an agile team where the main measure of project success is the number of features delivered into production okay that's good to know over the past six months the team have delivered the highest number of features your organization has ever seen interesting however customers are starting to complain about issues and bugs in the product what will you do next this is super interesting actually so our measure of success is the number of features and so what does the team do they deliver as many features as they possibly can but at the cost of everything else by the sounds of it because now we've got bugs and we've got issues and all of these things so it's actually not the best quality product however we are meeting our success measures we're moving quickly so how do we fix this or how do we help this what will we do next ask the team to work harder okay oh gosh uh you know what there's definitely better answers than this especially when we're talking about sustainable Pace in an agile team very important to deliver more features and fix the product product issues possibly a better answer there adjust this product metrics to include customer satisfaction and quality measures oh this actually could work because we're adjusting the way we're measuring the team so now we're also focusing on customer happiness or customer satisfaction so we can deliver quickly but we also have to meet customer satisfaction measures and so you'll see the behavior change as we change what we measure in a project team I can't remember what it's called it's like Hawthorne's uh hawthornes something it's like a fallacy like a bias that we have I can't remember exactly the name of it but maybe we'll get a tip in the answer add a slack card of Five Points in the Sprint backlog to deal with the technical debt it may not just be technical debt although yes I mean that's actually pretty good that's a pretty good answer actually so yes we definitely want to be doing that reducing the technical debt reducing the defects and issues definitely um but yeah but how do we actually deal with the root cause of the issue so these are both good but I think we'll still go with answer B remove customer comments and feedback completely until you've finished delivering all the features uh so I guess we can't they can't get mad of it at us if we're not measuring it at all but then we stick our head in the sand and all of a sudden it just gets worse so for our purposes we've got two good answers there they're both good let's go to the root cause of the issue let's fix the measures and see if that helps initially and to be okay great oh yeah there it is the Hawthorne effect there you go so I can't remember it's by someone called Hawthorne I think obviously um and so what we measure influences the behavior of our team in this case we measure the number of features only and the team deliver those features but at the cost of quality and customer satisfaction by adding measures for those two things that will balance out the team's Behavior wonderful good you know wonderful thing to know really really important stuff and good for the real world as well in your own project in your own team when you're leading and managing for yourself page 112 measurement pitfalls the Hawthorne effect that is really cool a really good one to know you know what else is really cool is we are halfway through this little section so you are doing an amazing job you know this is tricky stuff but we're really getting through this together you've been working on a project for the past eight months your project team have been approached by multiple stakeholders for reporting on various performance measures about the project and the product area no now a large amount of their time is spent on creating these reports for others and they have escalated this issue to you what we do next okay and this will happen in your real project working life as well you'll get people approaching your team asking them to do things all of a sudden their time is spent on other things that they need to be you know instead of the real valuable work delivering the product for your project so how do we get around this ask the project stakeholders to stop interacting with your team I mean that's a maybe but also maybe we need them to interact for other things so we can't just cut them off all together let's put a maybe for that one for now spend a portion of your project budget to automate the reports for your stakeholders that could be pretty good um yeah another decent idea work with the team including the stakeholders to only measure things that will facilitate as a decision help avoid an issue or increase project performance wow okay that's that's very deep that answer and I really like that again we're going way back to the root cause uh you know and and the root thing that will solve this so we're measuring things that will so we're still engaging with our stakeholders as well so that makes this one not the best because we actually want to engage with them get those answers and we want to facilitate decisions avoid issues and increase our project performance so we still want to talk with people and get those answers and that will actually help I think that's actually pretty good we could automate these reports as well but we also want to talk and communicate and collaborate so let's see what the last one is just in case invite your stakeholders to your Sprint reviews so they can see a working feature in practice pretty good again good practice to do definitely like it like this one as well but the collaboration aspect and getting back to the root cause of it let's go with answer C there it is the intended measuring and displaying data is to learn and improve to optimize project performance and efficiency only measure and Report information that will allow the project team to learn facilitators the decision improve some aspect of performance help avoid an issue or help prevent performance deterioration in the future so we've got page 114 under growing and improving in the promote guide and that's really good to know another very handy tip for the real world and for the exam how did you guys go with that one all right only a few to go let's get into it you're working on a project where there is a significant amount of uncertainty about the requirements there is also a legislative change coming and no one knows what it will mean for your industry as a project manager how do you deal with this uncertainty or this is good and we've looked at this before where we've got volatility uncertainty complexity and ambiguity and there's different ways of dealing with this the pinball guide actually goes into this in a fair amount of detail probably because projects have a lot of all of these things and that's what makes them so difficult to deal with and why we need this toolkit to deal with them so it's actually pretty cool let's see if we've got any good options here so uncertainty perform additional planning for your project to improve your view on open management I mean maybe we can make it less certain with more planning that's a low maybe though I think there's better options there hold additional retrospectives to capture challenges and improvements from your team again that doesn't help us with the uncertainty because we're still having to work through you know how do we figure out and make things more certain create a risk assessment of all possible project risks maybe with their risk ratings and owners um I mean potentially uh is there a better option there that's a that's a maybe-ish all of the risks now we're making you know now we've got ways of dealing with future risks and making things less uncertain for that way that's pretty good gather information and prepare for multiple outcomes and build team resilience through processes and training um definitely the the multiple outcomes I think if things are uncertain we can prepare for this one that one and that one and that one and that's sort of what the risk question is doing but this one adds building team resilience so when we're working with uncertainty some people just you know are not good at working with that so how do we build team resistance through resilience through processes and training so we help them become more resilient to uncertainty in the future I think that's actually pretty good tackles it from a few different angles let's go with answer d excellent this question is about General uncertainty and risk uncertainty cannot be predicted precisely and methods for responding to uncertainty include gathering information preparing multiple outcomes preparing four multiple outcomes using set-based design so maybe we're figuring out prototypes and that sort of thing to work our way through it and building in resilience for our team page 118 under General uncertainty and that's a really good one to check out in the pmbot guide 7th edition how did you guys go with that one all right only a few to go let's get into it you're working on a project with a vendor where there is a significant where there is significant ambiguity involved okay again uh v u c a ambiguity and multiple options that the team could go with many outcomes are possible that have varying degrees of impact to improve the situation so what are we going to do next so we've got many outcomes it's ambiguous which way do we choose use experiments and prototypes and Progressive elaboration to work your way through it ah that actually sounds awesome so that sounds perfect and Progressive elaboration is that agile way of working we're delivering something maybe it is just a prototype getting the feedback on it yes is it good is it working and then you know adjusting and moving forward and going again getting that feedback we're progressively elaborating and we don't have to do that with a full thing we can just use a prototype to do that so that's actually pretty good let's see what else we have ask your team for additional reporting around different options so you can make an informed decision probably not the best one for ambiguity add all the different options into your project scope so all your bases are covered what are we going to do then you know how do we work through the ambiguity it's still going to be ambiguous isn't it even we've got still got all of those options to choose from work more closely with your senior users so they can inform you of the product requirements I think that's good practice in general but won't help us directly with the ambiguity this one is definitely the best option let's go with answer a excellent work this question is on ambiguity now that I've said that so much there are two different types of ambiguity conceptual where something is hard to understand that's pretty good and situational where there are multiple options and multiple outcomes and the reason this vuca was it actually came from the military so it was and for various reasons because in a military environment you're going into you know an environment that is or could be volatile it could be ambiguous you know we're not sure there's lots of different options it could be complex you know there's there's lots of things interacting with each other and changing the outcome so this is you know even though it came from the military all many many years ago it actually works perfectly in a project environment because all those things are present for us all of this complexity uncertainty it happens in a day-to-day and we have to work through it as project managers so use Progressive elaboration just like we said experiments and prototypes to work through this ambiguity and we can do that in any project environment physical you know software related uh any any of those things page 120 under ambiguity in the promotion wonderful work guys last two questions you're doing great you're working on a project to improve some software that has been in production for over 17 years and it's been modified extensively over that time it also integrates with many other systems within your organization gosh this sounds like complexity doesn't it so we've got an old system it interacts with many other systems so it makes things quite complex you cannot decide which features to deliver first how will you deal with the complexity oh that's good okay we're definitely on the right track here list out the possible features you can deliver and prioritize them by cost over benefit that's pretty good that's definitely good practice let's see what else we have just in case simulate decoupling connecting parts to simplify the number of variables okay and we're simplifying and so we're decoupling this and decoupling this now all of a sudden it's not interacting with five things or you know or the other way around and it's a little bit simpler to deal with so now I think that reduces some of that complexity so we just do that in a simulation we don't have to actually physically do that but we can check that out and see what would happen then reframe your view by brainstorming with a diverse set of stakeholders we need lots of different viewpoints hopefully to get the information we need to reduce that complexity I think that's actually pretty good uh what else have we got just in case provide an incentive for your project team for whoever can solve this complex problem um I think we have to work together on this and use the actual tools and methods for reducing complexity form a business case for a third party system to replace the existing complex system to transfer the risk of delivery that uh you know that may not reduce the complexity so we still have to go through this process of critical thinking and reducing the complexity just Outsourcing it may actually increase the complexity we don't know so I think that's a no for now let's go with Hansa B excellent all right this question is on complexity and methods for dealing with complexity include systems based decoupling and simulation reframing by getting diversity and balanced views uh process based so iterating forward engaging stakeholders and using uh error proofing or a Fail-Safe so how can we make it impossible to make a mistake or you know something stops if it has an error so we've got page 121 under complexity in the promotion wonderful stuff and what else is wonderful is that we've made it to the last question in this little section and I've learned a whole bunch about the pmbok guide 7th edition and I hope you have too especially I love that volatility and vuca stuff because you see it every day and it's good to have tools to deal with that let's do this you're working on a project that requires a very particular programming skill set like Liam Neeson he has a he or she has a very particular set of skills programming skills that are not very common excellent It's also the hottest job market the industry has seen in two decades gosh of course people are hard to come by and they leave often the programming language is also evolving at a quick Pace what will you do next okay so we need this programming skill people are hard to find how do we work with this so is this another one of our vuca things is it volatility it sounds like it could be a volatile environment and I think we've done all the others so that might be a clue for us um all right how do we deal with volatility a developing the product from scratch in a more common programming language maybe maybe there's better answers ask your whole team to learn the programming skill set to cover the risk I mean maybe may not be very feasible for us to do that we might still need to keep delivering we don't have the time for it but it's okay you know in an unlimited world that would work use Alternatives analysis that sounds promising to gather different options and ensure a sufficient cost Reserve to help complete your project okay that sounds like a very pragmatic or mature approach so we've got different options just in case and we can brainstorm those and also also just in case we've got a cost Reserve if something does go wrong or if we need to tap into that as people come and go that actually that's pretty good I think that makes sense raise a risk to your project completion with the threat of project team member skill sets yes that's also good practice these are all finances but I think the best answer for us is that answer C for Co for volatility I think it is let's see and it is we got it very good the question is referring to volatility which is an environment that is subject to Rapid and unpredictable change including ongoing fluctuations in available skill sets or materials alternative analysis and cost reserves are ways to deal with volatility page 122 under volatility in the Puma guide seventh edition and we made it you made it amazing stuff I had a whole bunch of fun with these this set of questions I thought this was really really good loved all of that volatility stuff good stuff to find out about but more importantly what you're doing is something amazing for your life and for your career as you can see this these skills are so valuable in real world environments not just in an exam it's so powerful you're doing the right thing I truly believe that you can pass the PMP as well you're doing an amazing job keep going your project team have found a significant data vulnerability in one of the features planned in your product backlog where customer data is exposed without password access okay wow that's uh that's pretty bad okay this feature is partially made by a third-party vendor okay so we don't even control this necessarily third-party vendor and the relationship is owned by a functional manager in your organization what will you do next okay and it looks like here we've got answers relating to risk so what are we doing with this particular threat or this particular risk let's have a look do we avoid the risk and wait for the third party vendor to fix the vulnerability I think in this case this is pretty serious so I think we need to get take action or get some sort of traction on this quickly or straight away if possible so I think that's a no for now transfer the risk by asking a different vendor to create a feature with no vulnerability in their design I mean that that's sort of taking action but in the meantime what are we going to do that could actually take time to do ah I mean it's a maybe maybe a low maybe for that one escalate the risk to the manager with the appropriate authority to act on the response so it looks like we're talking about the different types of you know the way that we can respond to risks do we avoid it or transfer it do we escalate it I think in this case because it's quite a severe risk we can escalate it plus we don't have any Authority you know it's owned by someone else it's a separate vendor so we actually need to go to the people who have that Authority and have that information who can actually do something about it I think that's probably a good one accept the risk and move on to other features so the work continues to get done I don't think if it's that severe of a risk I think we shouldn't just accept it I think we should still raise it and try and do something about it so let's go with answer C there it is with project risks and responses to threats there are five main types avoiding escalating transferring mitigating and accepting them escalation is appropriate when the project team agrees that the threat is is outside the scope of the project or exceeds the project manager's Authority so that's a very good one to know obviously we could try and manage it first but in this case it's well outside of our realm I think it's appropriate to escalate it and that's page 123 in the PM book guide seventh edition under overall project risks and threats which is really good to know so you can go directly there if you want to very very handy how did you guys go with that one all right let's see what we have next you brainstorm risk responses with your project team and project sponsor and decide you cannot transfer a certain high impact risk okay so we can't transfer it and it is high impact you also can't avoid the risk and there is no one in the organization to escalate it to okay that doesn't leave us with many options your project sponsor agrees that you should actively accept so actively accept the risk and I think there's a difference here between actively and passively accepting the risk I just can't remember what it is what will you do next okay develop a contingency plan that would be triggered if the event occurred actually sounds pretty good because it it will still happen but we'll be ready we'll be actively accepting it but uh but we've got something ready if it does actually happen that actually could be good so we've got a contingency plan ready and yes it might happen but we're ready if it does let's see what else we have just in case shift the ownership to a third party to manage the risk and bear the impact if it does occur I think it said we couldn't transfer it actually but that is transferring the risk so it's not actively accepting it act to eliminate the thread or protect the project from its impact only is that mitigating I think or mitigating the threat let's see what the last one is just in case take action to reduce the probability of its occurrence and the impact of the threat so I think that's very similar but either way both of these I don't think that's actively accepting that's probably more putting in putting in mitigations for the risk or that sort of thing for our purposes let's go with answer a there it is all right this question is describing the various risks how the risk responses to threats actively accepting a risk can include developing a contingency plan which is exactly what we're doing that would be triggered in the if the event occurred passive acceptance means just accepting it and doing nothing okay so that's the difference up there acting to eliminate the threat is avoiding it okay so that's avoiding and the other one must be mitigating I think so mitigating the risk is taking action to reduce the probability of occurrence or the impact so that's all the various ways that we can respond to those risks which is very very handy to know page 123 under risk threats in the permit guide 7th edition really good information to have all right how did you guys go let's see what we've got next you're working on a project to build a new customer database system for an engineering team in working with the requirements you realize that this system can also work with other teams in your organization and the effort to add those teams is actually quite small what will you do next okay wonderful that sounds good and oh it looks like this is really similar we're looking at opportunities now because it's a positive risk and so what are the different options that we have we can work with the other teams and their managers to escalate it exploit it enhance it or accept the opportunity okay so what are we going to do here I think escalating it is when we don't have the authority so maybe but I think there's possibly a better one accepting it is just if we again could be passive or active acceptance when we're just accepting that it's there enhancing it is when it's already happening perhaps and and now we're sort of making more of it that could fit but I think probably the best one for us is to exploit the opportunity to actively make sure that it happens so it's like mitigating a risk we're actually taking action we're saying okay let's do it and let's let's make this opportunity happen I think for our purposes let's go with answer I mean there's a lot of good ones here maybe we'll get some tips in the answer I'm pretty sure we really want to exploit this low let's try answer B okay that was good I mean could have gone a few different ways but let's see what our tips are here when dealing with opportunities in your project there are five main responses exploit is acting to ensure an opportunity occurs okay so that's good we're definitely doing that escalating is when it's outside the authority of the project manager just like we said sharing allocates ownership to a third party who is best able to capture its benefit so if there was someone else it is another team but I think we're still adding that information so even sharing may not have fit the best for us because we still need to actually exploit it and and do the work enhancing is increasing the probability of its occurrence okay so that's actually very good information to have do we enhance it well no we still need to exploit the opportunity and make sure that it happens not just increase it the probability of it happening and then actively accepting me or accepting merely acknowledges that it is existing without doing anything extra so I think we want to take a bit more action than that and there it is Page 125 under risks and opportunities in the pmbok guide so that's actually pretty good we're getting a really good view of risks positive and negative risks uncertainties it's actually pretty good how did you guys go with that one let's see what we've got next I think these are getting pretty good A little bit difficult too you're working as a product owner in an agile team and during a recent risk review the team have uncovered various risks more risks excellent that's always fun that will impact your project you brainstorm risk responses with your team the project customer would like them to be mitigated as soon as possible what will you do next okay so and again we're a product owner in an agile team so how do we deal with risk in an agile team probably very similarly to the way we deal with everything else we prioritize it and we prioritize the the highest risks first I think let's see if we have anything that aligns with that ask your team to work on the risk responses and get them done as soon as possible so we've got what risk responses are we just asking them to just go ahead and do it okay but what about all the other work within the team as well I think you know we still need to make sure that we're working on the right things so that's a maybe but you know maybe we've got something better ignore the risks initially some might dissipate over time and only the important ones will be left uh you know in fact it might go the opposite way as well so then maybe those risks will get worse and blow out of proportion so I think we really want to tackle risk and be actively managing it assign the risk responses to all stakeholders around your project team to share the load I mean you could do this but only if it's appropriate some people might end up with risks that they know nothing about and then it's just going to take them forever to do as well so let's put a no for that one for now Pro here we go prioritize that beautiful word in agile prioritize the risks by comparing the expected monetary value of the risk to the anticipated return on investment so it's similar to cost benefit I guess so the the value of the risk you know the Impact versus how much we need to invest how much return on investment also we're comparing it against the return on investment of our other deliverables oh so we're prioritizing all of that and maybe a risk will fit in here because it has a high monetary value and then something else has a lower value a feature so that gets bumped down that's how we prioritize that that's actually pretty good information I really love that one let's get with answer d and there we are prioritizing risk responses in a risk adjusted backlog is just as important as prioritizing features to avoid negative risk impacts and Technical debt comparing the expected monetary value of a risk to the ex to the anticipated return on investment of a deliverable allows product owners to incorporate risk responses into the planned work in a normal way so that's actually very handy I'm probably going to use that in the real world as well you know so this is not just for our exam this is actually good stuff to know very good information to have all right how did you guys go with that one I think we're nearly halfway through so you're doing great you're planning a project where Supply chains have been impacted and the requirements are complex and intertwined with other areas of the business your project sponsor asks you to manage these risks before the project moves to execution what will you do next okay so we have to manage the risks what do we want to do here move to project execution so you can work through risks as they happen I think there's probably something better it's complex maybe that's a clue move to an agile way of work so you can deliver faster and also deal with the complexity I think there's probably a better way here again just changing our way of work often doesn't help we you know because we still have all these things in life that impact our project we still have to manage those things whether we're working agile or waterfall or anything in between note the risks with appropriate controls and Adam can tell this sounds good at a contingency reserve in the project budget as we've been over a few times you've got your project cost you add a contingency reserve for risks which becomes your project budget and then you add the management reserve for any unforeseen scope on top of that that's still within the scope of the project and so that's our way of you know managing these risks before it gets to execution that's actually pretty good assign a management Reserve oh and that's a nice one sort of throwing us off there but as we saw management Reserve more for scope so to deal with the risks before moving to project execution not that one for us let's go with answer C excellent work reserves are an amount of time or budget set aside to account for handling risks contingency reserve is for identified risks should they occur management Reserve is for unknown events such as unplanned in-scope work and that's page 127 management and contingency reserve in the pimbot guide 7th edition wonderful stuff and I know we've been through that a few times but you know it's a good information to have still and also useful for your own projects when you're going to need maybe to tap into some contingency reserve for those risks all right what have we got next you're working on an agile project and delivering a usable feature every few weeks the project sponsor is from a waterfall background and is concerned that there is not enough focus on risk of course I think there's certainly enough focus on risk in this set of questions though sorry you know at least we've got that covered they would like to hold a regular risk review with a wide group of stakeholders what will you suggest instead okay so agile project we don't want big meetings because that can end up being a waste of time we want small focused meetings or like stand-ups and demonstrating the actual work so how do we manage risk on a agile project there is no need for a separate meeting as risk as everyone's responsibility in an agile team sort of but maybe we could do something a bit more here so a low maybe for that one use daily stand-ups to report blockers early sounding good and fortnightly demonstrations that's our Sprint review of the product to catch any stakeholder dissatisfaction I think that actually sounds very very good so you know that's capturing types of risk but in a physical like in an actual way using the actual product and you know talking close in person place and time that's pretty good so use the kanban board to see the work and how it flows I mean that's also a good option we're sort of uncovering things doing that but I think this is still the best hold the risk meeting but only with the immediate project team to avoid unnecessary participants we might actually need some of those external stakeholders so you know that's something to consider so for our purposes I think we're going to go with answer B in agile teams the risk review can take the form of the daily stand-up reporting blockers that could come that could become threats if they continue to delay progress frequent demonstrations of the product can also surface threats and opportunities as can retrospectives while quality is everyone's responsibility and the kanban board does visualize the work B is the best answer page 127 under risk review in the pinball guide 7th edition all right that was pretty good lots of risk stuff agile waterfall lots of different ways to handle it and it's actually really great how did you guys go with that one let's see what we've got next your project management office has no prescribed way of work so they're working with a vendor who supplies an extreme programming framework at a significant cost okay um well that's an interesting scenario maybe not for the real world or maybe your organization is using it but projects are still running behind schedule over budget and with low customer satisfaction and by the way this could be for any framework you know I mean I see this happen all the time replace this name with some other name you you name it it's happened um what are we going to do next okay tricky situation as always let's see what we've got tailor the approach to suit the organization operating operating environment and project needs okay that actually sounds pretty good and that's a big theme in the Puma guide as well is tailoring to suit your project environment or to to suit the environment that you're in so we can take any again this could be anything could be waterfall could be it could be scrum it could be you know I mean you've got other agile Frameworks hundreds of agile Frameworks almost but all of those do need to be tailored to suit the organization that's actually pretty good let's see what else we have just in case use a waterfall approach instead to ensure the proper planning again same thing switch to scrum instead and see this is the thing we could literally switch to anything but we'd still need to tailor it as it's a more popular framework of course you'll see that happen all the time I've got to do the most popular one there must be a reason for it or you know people get tricked by that but it's not always the best tighten the controls around the project environment with a more directive pmo approach I think for our purposes we really want to tailor it let's go with answer a projects operate in a in complex environments that need to balance competing demands tailoring is performed to better suit the organization operating environment and project needs page 132 under tailoring overview in the Vermont guide 7th edition wonderful stuff all right only three to go you're doing great let's keep going your project management office is in the middle of a company-wide ways of working transformation okay similar situation here they have taken a popular project framework and are tailoring it to the organization with branded templates and processes that meet their existing governance requirements so controlling pmo for how you have been asked to help finalize the process what will you do next okay Do We Gather feedback from the functional business areas to ensure the process meets their needs about a project management office so potentially no for that one roll out the new way of working to the pmo as a pilot then to the rest of the organization um maybe I wonder if there's a better one here enable a process for tailoring again I think this might be our key word here based on size and complexity that's really good and Implement ongoing Improvement so again we won't get it right the first time we're going to need to adapt it and improve it over time I think that's also a bit of the agile sort of creeping in there that continuous Improvement happening former working group comprised of Executives and project professionals also I think there's more to it than that so for our purposes I really love the process let's go with answer C excellent work this question is referring to the tailoring process which is select the initial development approach tailor for the organization tailor for the project and Implement ongoing Improvement so that's a good process to be aware of page 137 the tailoring process in the pinball guide 7th edition and again this stuff is direct from the pmbok guide 7th edition it's a good way to learn it nice and easy scenario based but also you know quite similar to what we'll see on the exam which is also good and we've only got two to go that's also good I think we're doing great let's do this you're a manager of a pmo in a large organization which has recently undertaken a company-wide way of working transformation you need to select an initial development approach for your project which you will then tailor to suit further to suit them further what will you do next okay an initial development approach and then we're going to entail that so we've learned all our lessons from the past questions that we just had and now it's time to select an initial approach before we tailor it how do we do that okay use a framework that best engages your executive team through easy to use graphics and presentations oh boy isn't that a can of worms okay let's not get started on that it's tempting to be you know Bamboozled by beautiful graphics and presentations but let's put our critical thinking hats on and use the one that actually gets the work done oh okay let's put a no for that one for now and I don't want to go any more about that we could talk for hours select the most popular current framework to keep up with what other organizations are doing wow okay I feel this question now that is pulling our leg for all of these uh okay we don't have to keep up with the Joneses we have to do what's right for our organization what fits our project environment let's put a no for that one select multiple development approaches as a baseline for your organization look that's probably going to go wrong because now we've got to keep up with multiple development approaches so you know there may not be a one-size-fits all and that's fine but also if you've learned anything from these questions and the pub guide we generally have the same steps whether it's waterfall whether it's agile you know you've got and I can't remember them all but you know it's design you know build test and release you know that sort of idea and all those steps are present no matter what idea that you're using what framework you're using so let's put a no on that one for now and I hope the last one is correct because we're out of ideas now use a suitability filter okay that actually sounds quite promising to assess the most appropriate development approach makes complete sense suitability filters you know that's it gets sort of advanced you know once we get through all of our basic agile you know how to's then we start looking into coaching and and evolving organizations and when we do that using a suitability filter is a great way to start so answer D is fantastic let's do that one and there it is a suitability filter helps project teams consider whether a project has characteristics that lend themselves towards a predictive hybrid or adaptive approach select one of them as a base then enable the ability to tailor to your project or organization's circumstances really good answer page 138 select initial development approach in the pimbot guide 7th edition let's see what we've got next your organization is starting to move to an agile way of work and they're setting up a value delivery office or vdo to complement the existing pmo project management office the executives in the area have begun working through what the function looks like and the roles and responsibilities that might exist they approach you for help what will you tell them okay let's see what is a video basically what do they do a video is responsible for the value delivered and owns the programs within the organization I think that might be more the pmo I'm not sure I wonder if there's a better option here the video focuses on coaching that sounds promising coaching project teams because uh you know in in agile or value delivery where more coaches we're more about facilitation rather than directing that sort of thing building adaptive skills growing our teams capabilities and mentoring sponsors and product owners to be more effective I think that's actually a really good answer so we'll see what else we have the video is responsible for agile resources such as scrum Masters and product owners to be allocated effectively to project teams that might be your directive pmo again sort of more of a pmo function the video creates the organizational framework to be used on each project throughout the company again probably more of that directing pmo function I think for our purposes value delivery let's go with coaching building growing and mentoring answer B excellent work all right our video serves an enabling role rather than a management or oversight function it focuses on coaching project teams building adaptive skills and capabilities throughout the organization and mentoring sponsors and product owners page 141 tailor for the organization the value delivery office but you know what else has brought value is you and I going through these questions having a little bit of fun hopefully a lot of fun who knows but also learning a whole bunch while we're at it I've had an absolute blast and I hope you've enjoyed yourself as well but more importantly I truly believe that you can pass your PMP exam and I know what you're doing is going to help your career so much you are doing the right thing keep going I know you can do it and I truly truly believe in you you've been planning a project for the last two months Gathering requirements and scope and assigning tasks to a schedule as you get closer to the execution phase of your project you decide what delivery you need to decide what delivery approach you will use the requirements are likely to change okay require a medium amount of compliance that's good to know but can be released in one go what will you do next so we we're sort of needing to change and update things but we've got release in one go that sounds like an uh an iterative approach where we're iterating towards success and then releasing in one go it's not incremental where we're releasing increments at a time and it's not waterfall where we're just planning all the way up front and then releasing in one go so that's where it is in the middle there and I see it's not predictive incremental is probably our one it's not really agile or adaptive and it's not oh it iterative iterative is the one sorry because we're iterating towards success I always get them confused as well a little bit tricky but it's not delivering increments so let's go with answer d fantastic Gathering feedback and improving over time while delivering in One release is an iterative delivery approach incremental releases increments of value like features predictive plans predictive plans everything up front once and then delivers in one go and agile gathers feedback and releases incrementally we've got page 141 under Taylor for your project product and deliverable in the pinball guide 7th edition wonderful way to start how did you guys go with that one I thought that was pretty good so now we're starting to get into the delivery approaches very important stuff what have we got next you've been asked to make a process Improvement in the accounting area for your organization you have been assigned a small team of nine people sounds promising each with all the skills you need to complete the project this sounds like a very agile way of work so far the team is co-located even better and have unlimited access to the project customer okay wow this is just you know the perfect agile scenario I think how will you tailor your delivery approach wow okay or how will how what sort of delivery approach are we going to use okay by the sounds of it so use predictive probably not agile adaptive sounds perfect incremental I mean yep we could deliver increments but this one's going to be better because it has everything it's iterative and incremental is an agile way of work so we're using both we're getting feedback and delivering features use a hybrid delivery approach that's waterfall plus agile so that's not not for now so I think for our purposes let's go with answer B excellent work all right an agile or adaptive delivery approach works best when the team is small fewer than 9 to 10 12 people has close access to the customer is cross-functional so everyone has the skills required and you know some extra skills you know so that they can do other jobs as well if needed and is co-located in the same space so that we can learn by osmosis you will have heard that a few times in this series predictive is best when lots of planning is needed hybrid is best when there are two different approaches needed and incremental delivers features over time page 141 under Taylor for the project project team in the pimbot guide 7th edition wonderful wonderful stuff and we're certainly getting through them let's see what we've got next you have been working as a project manager in an organization for some time where an agile Centric delivery approach and way of work has been selected and tailored for the organization good stuff over the past few months you notice several things are not working and could be improved as you begin new projects what will you do next okay so what do we do when things are not working in an agile team uh usually we if we don't problem solve we hold a retrospective or something similar so I wonder if there's something here like that review the product backlog to see the flow of features going through the teams not really necessary for what we're wanting to do here look into issues threats and quality assurance statistics so defects and things like that I don't think that's really going to help I mean that might be part of the problem-solving approach but we need to to get you know more broad range of ideas and solutions and feedback on our way of working so suggested retrospective I think that's probably going to be our one with our pmo leaders to determine ongoing Improvement opportunities so what worked well what didn't work well can we take actions on the thing that things that didn't go well and we can improve them them over time review a control chart and value stream map to see non-evaluated activities and remove waste in the process that's also a really really good answer that's probably for our problem solving and it's going to be a process Improvement approach so you know that is actually quite good agile Centric though you know that just might be one part of the problem solving that we do as part of a retrospective where we're going directly to the source and asking for feedback and improving as a team let's go with answer C it could be either one but let's try and to see okay pretty good lucky um in an agile environment holding a retrospective to gather what is working well and what is challenging us or could be improved is the best way to find ongoing improvements so this can definitely work um you know it's still a good way to do it but the best way is you know close in person place and time with our retrospective under page 151 tailoring diagnostics for agile teams pretty good all right how did you guys go with that one let's see what we have next you have been working on a project to deliver a new customer data system and have noticed that the work is starting to slow down fewer user stories are appearing in your Sprint backlog as they are not ready okay and you hold you hold a retrospective with your team good thing maybe we we read we'd have previously read the last question and we've got a few tips Maybe and we discover that there are long delays waiting for requirements and acceptance criteria approvals okay what will you do next all right so how are we going to speed things up long delays waiting for those requirements and waiting for those approvals so you know that's definitely not a good thing we can problem solve this and improve it so what do we do do we streamline approval decisions through fewer people such as a product owner authorized to make decisions up to certain value thresholds well that actually sounds very good I really like that one actually it makes sense too let's see what else we have just in case ask your team to place the user stories in the splint Sprint backlog reducing the need for customer approval uh that's probably going to end in tiers I'd probably prefer to you know work with the customer directly and closely I think that's the whole point of agile as well so we can always be getting that feedback make sure the requirements are right make sure that you know the development acceptance criteria is right and then the developed item is right and then the test criteria is correct and then the ultimate product is correct as well so Happy Days customers always involved and happy note the long delays as risk as a risk to your project with a high likelihood as it's already happening probably more of an issue if it's already happening as we would know so maybe a no for that one escalate the issue to the functional manager to ensure approvals are happening quickly I think we could escalate it but is that still going to solve the problem you know so we still need to problem solve this and manage it ourselves as project managers I think not the best answer that one let's go with that one answer a I think is our one excellent work all right where there are long delays or waiting for approvals the tailoring suggestion is to streamline decisions through fewer people authorized to make decisions up to certain thresholds at certain value thresholds and don't forget that is directly from the PM box 7th edition so you know any questions you can go directly there it's page 151 common situations and tailoring suggestions go and have a nice read you know some good bedtime reading there for sure and uh but this way you know we're sort of getting the information directly which is also nice how did you guys go with that one all right we're nearly halfway through let's keep going you have been assigned to take over an existing project as the previous project manager leaves for another opportunity in working with your team you notice that there's a large amount of work currently in progress all at once or I think we've we've tackled this before with team members working on multiple items at a time and constantly context switching between tasks and we've spoken about that you know then it takes time to get back up to speed on the next task doesn't it and then they leave that one and then they go to the next task and then they have to get back up to speed on that one as well and all of that getting back up to speed is time lost and it also takes people out of the Flow State you know if you if you're into deep work so you know all of these things you know many many different things I could talk about this for days if not weeks but we can't we haven't got time for that right now what are we going to do next add more people to the project okay if we add more people then that actually might complicate things you know we prefer small teams for a reason because there's fewer communication channels and there's fewer ways that we can get mixed messages so it's much easier to manage in a small team so let's put a no for now use value stream mapping and kanban Boards I like that one to visualize the work and brainstorm Solutions with your team that definitely could be it but a kanban board will help us visualize that work in progress so then we can limit the work in progress typically that's something that comes from kanban because we can see it and we can easily you know only have one or two cards per person in progress for example so they're not having to context switch ask your team to work overtime or to cover the extra work and bring it all back in line obviously and again we've spoken about that working overtime is the opposite of a sustainable pace so we want a sustainable pace so people don't have to work overtime and then take sick days and get disengaged and then come back and work overtime and you know it's that hurry up and stop hurry up stop all of that you know that just ruins the flow of work again we want a nice flow of work so that's a no for that one review the scope of the project and reduce items with low customer impact with low impact to customer satisfaction I mean yes that's a good practice so that's actually a decent answer as well but I think the best answer for our purpose is getting rid of that context switching keeping a low work in progress let's go with answer B okay good and again a few different answers that could be correct there you will see that on the exam it can be a little bit tricky but we want to choose the best answer for us where there is too much work in progress or high rates of scrap it's recommended to use techniques like value stream mapping and kanban boards to visualize the work identify the issues and propose Solutions adding more people can also complicate communication and processes and you'll probably see that happen in your real life and career many many times page 151 in the pinbook guide 7th edition under common situations and tailoring suggestions really really good stuff all right we are more than half all we're halfway through now you're doing great guys keep going the product owner has prioritized the product backlogger features and the team creates user stories with estimates and places and places enough of them to fill a two-week Sprint very nice you notice that the piece is being completed are being rejected by the customer okay that's not so nice for defects and missed requirements what will you do next okay this is great we've got so many really good scenarios here and stuff that you're going to find in your day-to-day job even better really great fun okay what do we do about this create the project scope from scratch and the project team with the project team and customers so it's correct okay so we're suggesting we work together but we burn it all down and and you know start from the ground up I think there's probably a better way to do it than that so let's put a low maybe for that one for now have an iteration zero planning Sprint with your project team to set it up for Success oh okay yeah look you will hear that term a lot iteration zero I think there's way better ways to do it so look what people say suggest is you have this empty iteration that is just for planning but really we want to just be working and getting in that flow State and getting work flowing through the team straight away and so there's way more to this that we could again talk about one because requirements take a long time usually or a longer time to figure out and get solutions for and then it's broken into pieces and those pieces take a couple of days to complete each so the work is done at different rates it's not really done in iteration zero something to consider you will definitely see this in the real world when you're working in your career in corporate worlds and let's put a big fat no for that one for now add more feedback loops okay that sounds all right such as shoulder checks peer review that sounds good unit testing and system testing okay obviously all of these sound good and this is testing and quality at all levels so we want the requirements to be correct we want you know them to be peer-reviewed to make sure the customer is okay with those shoulder checking of the um you know of the development of the code units unit testing of the single items system testing of the system as a whole if we're doing all of those things you know now we're catching a lot of those issues before they become issues and it's it's less costly for us to catch them earlier at the requirement stage and then the longer it goes on the more costly it becomes to catch and fix those defects something else to consider so that's a pretty good answer I think we'll put that as a high maybe have less frequent customer demonstrations so they only see the product when it's correct for our purposes we want to be working with our customer all the time The Good the Bad and the Ugly we need them to see what's being delivered so they can give their feedback on it so we want that feedback that feedback loop let's go with answers C very nice when a product is facing poor quality deliverables the tailoring suggestion is to add more feedback loops or feedback verification loops and quality assurance steps including things such as demonstrations and reviews peer review of the you know of the items shoulder checks pair programming working together with someone else close a quality audits or testing unit testing system testing user acceptance testing regression testing and automated testing as well definitely a big thing in agile so all of those things what a great combination page 151 under common situations and tailoring suggestions directly from again the pinbook guide 7th edition wonderful stuff all right how did you guys go with that one I think a little bit more complicated but still pretty nice and really good learning as well I'm having a bit of fun I hope you guys are too all right let's see what we got next your project team has started to find their Rhythm excellent you yet you notice that they seem disengaged okay there's always a catch isn't there I always think oh this is going well oh no something happens in their work and they're dragging their feet on normal tasks okay this will happen you check your project budget and note that the team are all paid fairly for the market and within the same range for the role okay that's a good thing to check and as you will see it's not always and even really about the pay so as long as the pay is roughly fair then engagement for your team actually comes from many other different factors not just the money yeah once the money is taken care of it's everything else and there's a lot so let's get some tips from this particular question this should give us some ideas look for ways to reward the team members with bonuses above their normal pay rate so this is just throwing more money at it and again it just it it works for a little while but then it wears off very quickly I've seen it time and time again let's put a no for that one for now you know it's nice but again not the best answer move team members around to different roles frequently so they experience job variety so Variety in general is pretty good except if we're moving around into different roles we're losing that expertise and we're losing that progress and we're losing that flow state in the job and in the work as well so when you get really good at something you easily get into the Flow State you can do it you know with your eyes closed much easier as long as it's not too not boring then that flow state is a very good state to be in so yeah look we're getting pretty deep into this stuff actually gosh I wasn't prepared for this okay I should probably stop waffling on give the team a pay today off okay more pay you know and again you'll see this happen all the time Executives will just throw money at things because they don't have any other tools they actually don't know what else to do so let's give them all let's give everyone a Payday off again everyone love who loves a Payday off who's going to say no to that but it wears off so quickly you know you come back to work and the work is still not good uh so you know it's it's probably even worse now you feel even worse about coming back to work okay uh all right I hope the last one is good here establish ways for the team to grow in advance okay that's progress progress there's been studies on this uh so people who who are having a sense of progress you know whether it's real or imagined that's why you see levels so people getting different levels you know from beginner to medium to Advanced this is why computer games you know are so it can become addictive because you're always making that progress it adjusts for your skill level and again like I said I could talk about this for hours career paths learning Pathways but all of that to say that's one aspect of it there's probably 20 more but I think let's go with answer D for now okay all right and here's the study actually this is good so Frederick Herzberg conducted a study of motivational factors in working life and found there are hygiene factors so company policies make sure they're Fair salary make sure it's fair a physical environment make sure you know it's we're not you know in danger and it's not a dark dungeon you know there's light and water and you know enough that it's nice and then there are motivational factors so once the hygiene factors are taken care of uh then people want to you know then the way to motivate people is through these extra factors motivational factors which are achievement growth and advancement if the hygiene factors are insufficient they cause dissatisfaction but if they are sufficient then use motivational factors to provide satisfaction paying bonuses or a Payday off might seem like a good idea but will fade and not address the root cause of the engagement page 158 and again this is direct from the pimmock guide you know it's a it's a smaller guide than the PM box sixth edition but they really go into a lot of this you know leadership psychology you know pretty good stuff hygiene and motivational factors and uh wow wow I had a lot of fun on that one maybe too much fun I think we know we've got three to go let's get into this we've uh we're starting to run out of time now okay you're working as a project manager on a regulatory change for your organization you notice that the team are not communicating as well as they could be and you put together a plan to improve team communication by increasing its Effectiveness and richness what will you do all right good question include methods that will oh so I love this actually I know what this is too I've seen this team communication Effectiveness and richness ah I think this is directly from agile from Crystal and I'm doing something on this you're going to love it Crystal Alastair Coburn I think his name is one of the original guys you know from one of the original methods that fed into agile and he had different things that fed into Effectiveness and richness of communication so it's like natural language and stuff like that uh oh and the first one is straight away include methods that will handle multiple information cues so body language voice words all of those things combine to give you the message if you're just sending an email you lose 90 percent of that as well you've heard that before facilitate rapid feedback very important you know are they on the same page as us utilize natural language so you know none of this jargon or you know or a fancy other language I think that's a really good one include methods to escalate issues quickly with Executives being open for anything the team needs you know that's actually pretty good too it's nice but I think directly it's this one include ways to get sign off in writing so it can be recorded and reviewed later when needed sounds nice you know decent idea nothing wrong with it necessarily include communication that ensures everyone gets a voice and input into decisions these are all nice answers very very nice but I think directly what we're looking for with that Effectiveness and richness let's go with answer a excellent work all right Alistair Coburn there he is really really good stuff to read actually on crystal uh developed a model that describes communication channels along the axes of Effectiveness and richness media richness includes the ability to handle multiple information cues rapid feedback establish a personal focus and utilize natural language for example face-to-face communication co-located teams as we'll see many many times page 157 under effectiveness of communication channels wonderful stuff really really good two to go you're doing great as well let's keep going your deliverables have been signed off by the product owner and they're ready to be released to the customer which is in the which is the finite Financial analytics team of your organization the new system will be quite a change from their normal day-to-day work the team already have the desire to use the new system so what will you do next okay it's going to be quite a change we're releasing something to this to this organization the team already want to use use it so they already have the desire this sounds like it's a change management framework to me so do they need a vision and the why they already they're already on board so they already agree with it that's a good thing to do but not for us use training and education to show them the new processes and systems they have a desire to use it we need to show them how to use it I think that's actually pretty good give them unlimited Hands-On practice so they can get used to the new system I think we need to train them first so let's try that include rewards recognition feedback and measurement once we've released it to them um you know let's let's do that so let's do do that after that but this one first I think answer B I think that's going to be our one excellent work all right the ad car model for change management and you'll see there's quite a bit in change management awareness desire knowledge ability and reinforcement once people have the desire for change the next step uh which the next step is knowledge which includes training and education for the new processes and systems page 161 under ad car model and a lot more change things you know a lot more change management coming into project management these days you'll see a lot of it going around but what else what else will we see going around is the last question from 1 to 100 and there are some more coming after this by the way but 100 you've made it to 100 that's a pretty impressive feat really congratulations let's do this last one out of 100 amazing work you are leading a large organizational change that affects more than a thousand people across multiple teams you've engaged with the senior members senior managers of that area created a brief vision statement that someone Rises the change and created a strategy to realize the vision you communicate the vision throughout the change process what will you do next okay release multiple usable features so to the affected teams so they can get used to it gradually uh I think there's got to be a better answer than that one anchor the changes so this might be where are we up to in another change process I think it is so we're ready we're communicating the vision we're creating a strategy to realize that Vision but we haven't necessarily performed that yet I think so anchor the changes into corporate culture so we haven't done it yet so we can't really anchor it into the culture yet we can't tell success stories and we can't recognize people just yet so let's put a no we could release multiple usable features uh but I wonder if there's anything else address any obstacles to the change I think that could be good including outdated processes and people resistance so we've got a vision we've created a strategy now let's figure out what the obstacles are towards that change address them and then release I think that's actually pretty good we don't want to release before we address the obstacles right otherwise we could end up you know it just could be a bad situation set goals for continued Improvement on the change throughout the organization I think that happens later again I think our best one is probably going to be addressing those obstacles first then releasing it let's go with NCC excellent all right John Carter's eight-step process for leading change you'll see that a lot as well is a top-down approach create the urgency form a powerful Coalition create a vision for the change communicate the vision remove obstacles create short-term wins build on the change and anchor the changes in corporate culture so that's the the way that they go that's the step by step what we can do for that change after communicating the vision comes removing obstacles page 162 under the eight step process for leading change you have done an amazing job getting this far and also doing all of this together working on these PMP questions I truly believe with this practice and with this work that you're putting in you can pass the PMP exam I genuinely believe in you and I believe in what you're doing you're doing the right thing not only that I truly know that you can do it we're doing it together your project manager assessing the risk of future releases with your team you have a clear set of requirements from your customer however there are a range of possible correct Solutions okay so one input lots of different potential outputs that may or may not get the outcome that the customer needs there are a range of known unknowns I feel like that's a clue but I'm not sure how known unknowns are like risks so we know that they're there but the sort of the impact of them is unknown so how are we going to approach this situation I have a feeling this is about one of the models in the guide as well as like complexity models there's a lot on complexity and ambiguity and stuff so let's see what we've got use current best practices to make decisions that sounds all right sure I couldn't really go wrong there could we uh let's put them maybe for now use emergent practices that will allow you to Pro probe the environment sense the situation and respond with action probe the environment I mean oh I think that's for like a quite a complex situation maybe this one is like medium complexity because we know that there's stuff out there we know what it is we just don't know what's going to happen what the responses or what the solutions need to be so we need to what do we do here assess the facts analyze the situation and apply known good practices I think if we were to look at this from that risk perspective that's probably what we would do I feel like I'm going to get tripped up here though sense where there is some stability and take steps to try and stabilize the situation okay that's like a you know an out of control situation I think so we need to stabilize it and then we can go and apply some of these other practices so let's put a no in that one for now it's not out of control I think between these two let's treat it as we would as if we were managing risk um and so we don't need just the just the normal best practices we need to analyze do a bit of analysis as well so let's try let's try with NCC okay wow that was a little bit lucky I think oh and here's the framework so that's good uh oh and this one so it's spelled that way but I think it's pronounced coonavin the coonavin framework uh complicated relationships exist when there is a set of known unknowns or a range of correct answers so complicated relationships in these situations it's best to assess the facts analyze the situation and apply good practices okay so we got there answer B is for complex unknown unknowns so that's unknown unknowns D is for chaotic no clear cause or effect so we need to bring it back in control and a is where there is an obvious cause or effect okay wow that's a lot of information on the first question gosh I feel like I've got my money's worth already how good is that all right I hope they're not all like this but uh let's see what we've got next you've been asked to initiate a project to deliver a new system the requirements and not clear here we go again okay and it will take some time to uncover them the system has been used by some team members but not all and it has a medium level of uncertainty around it okay how are we going to approach this project is this the same kind of model again I'm not sure uh release small usable features so the requirements are not clear we need to make them become clear and there's medium level of uncertainty release small usable features and improve your approach based on feedback I mean I think that sounds quite good actually that's your typical agile approach isn't it so that's why we use agile is to work through that uncertainty and uh for things to become clearer so that's pretty good let's see what else we have just in case do additional planning up front to ensure every component is thought of I think no because we're still going to have to work through that uncertainty so split the team into two and work on different parts of the system to simplify it I think it's better if we have just small teams and work on it together and work closely together so that's that's a no form a business case for starting from scratch with new easier to use technology uh you know maybe but that's going to be a long road to recovery for that one so I think to get started straight away we can actually we can actually get started straight away using small features and working through it so let's go with answer hey great stuff oh and there is a model around this too so it's not just sort of the the agile way of working the Stacy Matrix looks at two Dimensions to determine complexity uncertainty in the requirements and uncertainty in the technology so that's good to know the labels this label is a project simple complicated complex or chaotic and agile methodologies work best in complicated and complex environments if it's chaotic same as the other model we need to stabilize it and bring it back into that middle realm so then we can use those agile methods page 165 under Stacy Matrix in the pinball guide 7th edition wonderful stuff we're getting pretty deep here so this is pretty good all right what do we have next your project team come came together from different parts of the organization and were introduced formally to each other so we've all met that's good now you notice that there's some conflict in the team okay good you know we're going through that for warming storming norming performing you know those phases of a team some people don't respect others decisions and are not working together well and there are some personality clashes within the team what are we going to do next next okay uh let's see what we've got here help team members get to know each other their names I feel like they were introduced so we sort of we know each other I think we're past that help the team understand their roles and responsibilities and form a regular rhythm of meetings collaboration and work maybe I think that's decent perhaps help the team shock you for position within the team and Foster healthy conflict I think that's that actually sounds unhealthy so I think that's contradictory conflict can definitely be healthy but only if we're working towards an outcome or a solution together not competing against each other so last one help the team complete Project work and disperse onto other things I think that's adjourning perhaps I hope I'm on the right track here but that's when we've finished and then we can we can leave the project but if we've already done this one we don't want that one that one's at the end then that really just leaves answer B so let's try that one okay pretty good we got there by the by elimination which is nice all right this scenario describes the five stages of team development it was the tuckman ladder oh I didn't quite match it up but it wasn't too bad when there is conflict and difficulty working together the team is in the storming stage we should help them understand their roles responsibilities and find a regular rhythm so they can move to the norming stage that does make sense page 166 under tuckman ladder in the public guide 7th edition excellent excellent work all right and we're really getting through these questions you are doing a great job let's keep going you have formed a new project team and have worked with worked through the purpose and mission of the project with them good you expanded on who is on the project team and the skills and abilities each person brings great you would like to foster a high performing culture and ensure the team is able to deliver as soon as possible what are you going to do next Okay so we've done the vision we've done the we've done the who so now do we do the what so what do we do like as a project maybe High performing culture I wonder if that's any clues as well work through changes on the project team and the projects such as deliverables and stakeholders I think uh probably not for a high performing culture and maybe we're not there yet I think if we've got the why The Who and we need to do the what I think um decompose the high level plan into greater detail including a detailed schedule of backlog yeah maybe maybe maybe that's the what I wonder if there's anything else that gives us a clue though Define a plan to achieve the project goals maybe including Milestone schedules release plans and high level budgets sure plan to achieve the goals and the last one clarify the goals of the team and what you are here to deliver okay the what so what is it we're here to deliver once we've done that then we do the plan and then with that plan then we decompose that into a backlog and then we work through the changes oh how about that I think we got there in the end I think the next step for us is answer D I hope okay these are these are a little bit tricky for me I don't know how you guys are going but we did get there in the end so that's good this question refers to the Drexler Civic team performance model wow we've got models everywhere at the moment this is great project management models have that the steps include orientation trust building goal clarification commitment implementation high performance and renewal and after trust building comes goal clarification so that's good and we've got page 167 Drexler Civic team performance model in the Puma guide seventh edition wonderful stuff how did you guys go for that one all right we are really getting through these so let's keep going your team members have raised an issue as they believe the current project scope will not reach the intended project goal of increasing customer retention okay so our project we don't think it's going to reach the goal so that's good you take their concerns to the project sponsor who controls the funding and resources the project the sponsor dismisses them and directs you to proceed with the scope currently set what will you do next tricky situation and is this uh so they've dismissed what they don't they say just go ahead and do it anyway and they are the sponsors so they're in charge I mean really is there anything else we need to do I'm not sure problem solve with the sponsor and final resolution yeah problem solving is always one of the better answers for sure let's put a maybe for that one hi Maybe come from oh okay well this is the different types of conflict I think um so we're pro where it's uh so this is win-win I think something like that anyway uh compromise with the sponsor so each party gets a little bit of what they want that's actually a lose-lose again I hope I'm on the right track here accommodate the sponsor to mean maintain Harmony and Good Will so we lose a little bit and they win and you know what that's appropriate I guess because they are the project sponsor we're delivering it to the customer it is actually up to them so you know that's actually not a bad thing this might fit in our scenario here but again you always do want to go for that win-win scenario I guess uh force the issue that would be so the sponsor accepts the change so that would be us winning and them losing that's a win-lose scenario so out of all of these we don't want lose lose so we can get rid of B we don't want you know win lose we don't really want to make our sponsor lose you know while we win that's probably going to be bad for our careers then so let's put a no for that one between win-win and lose win both of those are good but if it's if it is our literally the customer who we're delivering to I think probably accommodating them in this case is going to work for us so both of these are good this is actually another tricky one I hope I'm not wrong here but let's go with answer C okay all right I'm a bit relieved but also that honestly could have gone either way I think um let's see what tips they give us in the answer here so looks like another model which is which is always good we must be up to the model part of the pmbug guide so Ken Thomas and Ralph kilman describe six ways to address conflict depending on the relative power between the individuals now that makes sense so now all of a sudden the sponsor they have a lot of power they have a power over our career they have and they're the customer so we want them to be happy obviously they have all of the Power really so there is confronting and problem solving collaborating compromising accommodating forcing and withdrawing since there is a desire to maintain a good relationship with a sponsor adopting and accommodating posture might be appropriate that actually does make sense so page 168 and 169 under the conflict model in the pmbok guide okay well I think you know I got lucky there but how did you guys go and I certainly learned something at the end of that as well which is definitely the main thing that's really really good all right we're more than we're halfway through now so you're doing great the functional manager raises a concern that they have not been engaged correctly and the program is missing some key requirements as a result you believe you've captured all the items required your program manager asks you to handle the situation and approach it from look at that a win-win perspective what will you do next well okay I mean is it going to be another tricky one I'm worried about this now escalate the decision to the steering committee to ensure your point of view is heard uh probably not a win-win I think we want that problem solving don't we so demonstrate integrity that's always good find Mutual trust also good and look for the situation look at the situation from their point of view all of those are good things but is that a win-win I'm not sure I mean sort of let's put a maybe for now choose to give some leeway in your approach so the functional manager can add their requirements so we want win-win again is that a lose win is that more of a lose win scenario I'm not sure let's put a low maybe on that get your requirements baselined first and then compete with the manager to ensure a win oh and let's win at all costs except of course there are going to be costs down the road when that manager doesn't you know collaborate with us in the future so not the best scenario let's put a no for now if we're win-win do we have to have integrity absolutely do we have to find Mutual trust do we have to look at it from their point of view all of those things very appropriate I think uh I you know I'm not confident of all of these or any of these but the best one I think the high medium let's go with answer B okay all right ah and it's Stephen Covey from uh the Mad what is it the seven highly of uh the highly effective habits of people something I can't remember what is the book Someone helped me out in the comments please uh but you know it's a wonderful book Stephen Covey really good stuff um and he says think win-win so it shows different possible outcomes but we've got all of those a win-win approach is found when there is mature character trust and the ability to approach it from the other's point of view so there it is directly from the permit guide seventh edition page 169 under negotiation and also nice that they threw in the The Seven Habits of Highly Effective People so there I finally remembered it excellent and we're nearly done we're only got four to go in this little section you're doing an amazing job guys keep going you have been planning a project to deliver a process change for the past four weeks the requirements and scope have been signed off by the business owner and the team are moving into delivery and execution the work begins in line with the project plan and scope what will you do next you know what this sounds suspiciously like the pmbok sixth edition actually though those steps the project steps so we've planned we've initiated it um you know it's the requirements have been signed off by the business owner we're ready to move into execution and delivery so what do we do next we Monitor and control and then we close the project so that's uh that's all of those steps that you've become very familiar with from the PM box sixth edition and now they've taken a bit of a back seat in the Boombox seventh edition um so I see we've got that answer here what and there we are these are all those steps execute the project work well we're currently doing that plan the work we've already done that formally sign off the project we can't do that until it's finished so I think for our purposes let's monitor and control that work make sure that it stays on track make sure it meets its goals let's go with answer a okay very nice and we've been through that so much if you've been through the waterfall questions you will know that back to front sorry the project management process groups are initiating planning executing monitoring and controlling and closing there may be they may be performed in sequence or they might be iterated on um you know or they might be done or all at once for one increment if you're working in agile they're applicable in every scenario as Project work is executed it's then it then needs to be monitored and controlled page 170 under process groups in the permit guide seventh edition wonderful stuff how did you guys go for that one all right we've only got three to go you're doing great you're working as a product owner while your sales and revenue have been increasing over the past eight months the overall profit has decreased by 17 wow this is great uh and you know this is something this is a good lesson for us all because revenue and sales is not the same as profit so the money that we get to take is the profit and so in between that is all of our costs so all of our operating costs people costs system costs and that takes away from uh from the revenue and turns it into what we've got left which is our profit so you'll hear a lot of people saying oh I made a million dollars in sales okay well how much of that did you get to keep you know sorry basic business good to know your executive manager asks you to address the situation what are we going to do next so stop the current work and set a planning session with your team to address the situation anytime we can not stop the work you know that's what we want to do we want to keep going and I think that's part of why agile works is because we're we're working just in smaller pieces and smaller teams and we can keep going even when things get difficult or complex so let's put a no for that one for now ask your team to work overtime on the current features in your backlog to get the work done and we've been through this again and again and again you'll see it come up again and again and again in your life sustainable Pace we want to keep that sustainable Pace we don't want Peaks and troughs we don't want to hurry up and wait hurry up and wait so let's put a no for that one perform benchmarking with a similar yet non-competitive company and and add any process improvements to your product backlog so what are we trying to do here we're trying to reduce that cost so we have more profit left over at the end of the day how do we do that process improvements maybe we get some ideas from another company to see how they're going uh that's actually pretty good so pretty good look for opportunities to partner with other projects products in your organization and increase your sales further good example here if we're increasing ourselves further but we haven't taken care of that cost issue what's going to happen we might increase a little bit but yeah we haven't addressed the root cause so you know that profit is still not going to be as high as it could be this is a great question uh wow this is a lot of fun this one and I think if you guys are on the same page as I am I think we're going to go with it that ends to see okay very nice as a product owner your responsibility is to increase users sales revenue and profit for your product if profit is decreasing while sales revenue is increasing the product is costing more to produce or sell performing benchmarking to find gaps in your process then executing them with your team will help pumbot guide 7th edition page 175 data Gathering and Analysis benchmarking again this is information direct from the pmbok guide 7th edition so we're learning while we're answering these questions uh you know you don't need to read the book you still can I would recommend it but you know we're actually going through it piece by piece so this is pretty good how did you guys go with that one all right two to go let's do this you have been given authority to manage the upcoming features your team will release you do not have a high enough level of expertise in the product so you gather senior users from the product area to create a features list makes sense each stakeholder wants their feature to be delivered first okay of course they do you will see this happen in the real world all the time how will you prioritize them and move forward okay this is just on prioritization so this we can do this one and I see Moscow here that's really good so I wonder what else we have go with the features wanted by the top level Executives first to avoid issues later on we could do this uh in fact there's a name for it the highest paid person um person's opinion the hippo you will see that a little bit uh but you know you might you might appease the high level Executives but they may not be close enough to the work to understand what's really really needed so that can be a dangerous thing let's put a no for now for Moscow analysis with the stakeholders that's certainly a way to prioritize you have must have should have could have and won't have something similar or will not have for now or something as they want but the thing is with this with this uh and you know you'll see this all the time as well is everyone just votes for their item to be must have so you know yeah yeah it sort of works but not really so Moscow everyone just says well mine is a must-have okay we need to delve a little deeper here and get a bit more information if there's nothing else we'll go with this but let's see what else we have perform a root cause analysis and go with the features that address the root cause well what are we doing here what are we addressing the root cause of so I'm not sure about this I mean maybe between these two I'm not sure I'd probably go with Moscow over that one actually let's see what the last one is just in case use a cost benefit analysis and compare the time needed to recover the project cost okay oh gosh there's a lot of information there cost to benefit that's a really good way to do it so what is the benefit we're getting from each of these features wow you know shouldn't we look at that so high benefit yes but also low cost what's the lowest cost highest benefit one that we can deliver first that makes sense and compare the time needed to recover the project cost okay that one's got me a bit I'm not sure on that but obviously if we're trying to recover the cost from the benefit that we're getting so that sort of makes sense I think if we're looking at that probably better than Moscow even though Moscow is a is a direct prioritization framework cost benefit analysis also is so this is tricky but I really like this one better for those reasons that we spoke about let's go with answer D okay cost to benefit and the payback period time to recover an investment that's what they were talking about other best accepted ways to prioritize business value well there you go something for the real world something we can take away and use root cause analysis is better for specific problems which we didn't know what they were performing Moscow with the stakeholders may result in each of them wanting their feature to be must have yes indeed page 175 business justification analysis methods direct from the promo guide again and here we are last question in this little section you've done an amazing job let's do this you are creating a business case and a project Charter with a small initial project team you have a high level feature decomposed into smaller release milestones and you'd like to note a high level schedule using wide band Delphi or a high-level version of planning poker okay what are we going to do next wideband Delphi is when we do an estimation and it's your high level and in the next pass we actually get a bit more refined so we're and then in the next pass we get a bit more refined again and in the next pass and so actually this is based on everyone's information so everyone has different estimates and then the estimates get closer together now that we know what everyone else is saying and they've given their reasons until finally we've got our final amount after all these different passes and estimating so it gets more honed every time so planning poker hold a round of cards with points on them where each team member places their cards in the center for the total estimate uh that sounds correct but it's not um because it's it's still this planning poker is basically still this but just with you know with cards so with playing cards or with numbers so um people change the numbers with each round uh let's put an O for now ask subject matter experts to complete multiple rounds of estimates sounds good individually compare and explain the highest and lowest estimates for each round that's exactly it show the wide band high level range from the lowest to highest for each feature they use the right word but that's not the right process so let's put a no for now find the business functionality for each feature and estimate the effort based on that I think that's a different type of estimation not wide band so that's a no let's go with answer B and there it is the wideband Delphi technique asks subject matter experts to complete multiple rounds of estimates individually compare and explain the highest and lowest estimates for each round planning poker is a variation of wideband Delphi page 178 estimating why band Delphi in the PM book guide 7th edition and you guys have made it through this little section you've done an amazing job I have to congratulate you on just the work that you're putting in by putting in this work you're truly proving that you can pass the PMP you're putting it a little bit every single day learning a little bit more getting a little bit better and if you keep doing that nothing can stop you I truly believe that you can pass the exam and I know you can get what you need out of your career once you do that you have been asked to help facilitate a senior planning meeting in your organization a highlight high-level Executives have made a presentation on the strengths and opportunities of the organization so strengths oh this sounds like SWOT strengths opportunities weaknesses and threats painting a Rosy picture Revenue has fallen recently and the chief executive asks you to level out their analysis with a more complete view what will you do next Okay so we've got the strengths and opportunities how do we level that out we need the weaknesses and the threats as well we need that whole picture I think unless I'm off track there but let's see if there's something like that in the answers add your organization's competitors and compare their products competitors could be something around there with our threats or our you know maybe let's put a low maybe for now showcase the pipeline of upcoming work to be delivered in the next quarter I'm not sure if that's relevant here especially for what we're after let's put a sort of a no for that one for now we can come back to that add in the background and abilities of the executive team that will allow the organization to deliver uh I think we need a more rounded picture than that you know we don't just need the good we need the bad and we don't just need you know their background either so I think that's probably a bit less relevant here brainstorm and capture the weaknesses here we go of the organization and threats to the organization I think that's exactly where we're heading here let's go with answer d all right fantastic this question is referring to SWOT analysis strengths weaknesses opportunities and threats once strengths and opportunities have been captured a complete picture also involves the weaknesses and threats page 175 under SWOT analysis in the pinbook guide 7th edition wonderful stuff how did you guys go with that one all right let's see what we have next you are adding an essential feature to your product roadmap okay very agile Centric your team believe they can complete the feature in six weeks however the feature is quite large and a bit more complicated than normal one of your lead developers says they worked on a similar feature in another company and it took around four months to complete okay that's a good clue what will you do next so the team believe they can do it in six weeks but someone else has worked on something similar on the on in the past and what is something similar similar is uh like an analogy so that is analogous estimating where we're looking at something similar and using that as a guide so maybe it's going to be that let's have a look use relative estimating so relative estimating is when we have the smallest piece of of work that we could do and that we assign that as you know usually in story points as a one and then everything else is relative to that so if it's twice as big as a two three times as big as a three five times as big it's a five it's all relative to that first smallest piece but I don't think that's relevant here use analogous estimating okay so that's sort of what we were talking about I think that could work and place the feature with around four months to complete that way we're a little bit safer maybe I wonder if there's a better one but that's pretty good use parametric estimating and it looks like it's all just the different types of estimating here so parametric is when there's a parameter so a dollar per meter uh you know or your hour dollar per hour something like that but I don't think we have any parameters to go off here so let's put a no for now use function Point estimating to show the amount of business functionality in the feature and again I don't think we have that information so that's not really relative here out of all of these options even though it's not you know it's not really amazing but it's probably the best option here analogous estimating because of that scenario they've worked on it in the past let's go with answer B okay that was definitely it when the effort on a feature or deliverable needs to be estimated and there are people who have experience delivering a similar item you can use analogous estimating like I said it's an it's an analogy it's similar to something else so we can estimate the effort quickly and with a medium level of accuracy because they've already done it in the past page 178 estimating analogous estimating in the pmbok guide 7th edition wow all right getting a little bit trickier how did you guys go with that one I think that was still pretty good good information to have as well you have a prioritized backlog of features okay very agile again so lots of agile questions here you have decomposed the next feature to be delivered into user stories okay backlogger features decompose them into user stories and that can go into a Sprint or multiple Sprints to complete a Sprint of two weeks so that's good the team would like to estimate the effort involved on those user stories but are unsure on how to proceed what will you do next so again this is on estimating and remember in the last question we were talking about you know mostly on user stories that's that relative estimating usually with the Fibonacci method as well although you know it can be various different ways it's not mentioned specifically in the combo guide I don't think but Fibonacci is one two three five eight thirteen twenty one so it takes the previous two adds them together and that's how you get the next number the previous two adds it together that becomes that one so that's how Fibonacci works and that's just the way to show the increasing complexity as things get bigger but uh what are we going to do here for user stories ask each team member to add their own estimates as they complete the acceptance criteria potentially I mean that could work that's a decent way to do it estimate the effort for the overall feature and reduce the need for individual story estimates I think we still need the story estimates to put into the Sprints so we can get our velocity so how much we're completing on average within one Sprint velocity is good so that's a no on that one for now help the team perform relative estimating okay this is what we're talking about where the stories are sized in points relative to the smallest piece that's probably the most common method for user stories and they can do that oh but you know what if we're doing it on our own then we don't have the benefit of doing relative estimating together where now we're getting input from the Tester the developer and you know everyone involved in doing the work so that is actually that's a key piece there I think that's pretty good base the estimates on cost per hour that's our parametric estimating that we saw before and add them after the work is done to ensure it's correct okay well then it's not really estimating is it it's uh we just know because that's what it actually what actually happened so it doesn't really do us that much good I think that's a no let's go with answer C all right wonderful stuff relative estimating is the most common method for user stories where they are sized in comparison to the smallest piece often in story points and often in a on a Fibonacci scale like we said before page 178 under relative estimating in the guide so that's actually pretty good information to know all right we are getting through these questions and you are doing a great job how did you go with that one I think that was pretty good let's see what we have next you are halfway through your current Sprint of two weeks the work is progressing well however you notice that there's not enough work ready and elaborated for when the next Sprint begins what will you do next this is great very agile Centric as well what do we do when we have our Sprint it's happening we've got an upcoming Sprint but we only have that much work we don't have enough work so what do we need to do here hold a backlog refinement meeting and work with the team to identify the work that could be accomplished I think that's pretty good it's either that or a Sprint planning meeting except Sprint planning happens just before the next Sprint we're halfway through this Sprint we've still got a little bit of time to go so backlog refinement could actually be our one raise the issue as a Blocker in the daily stand-up and ask your team to swarm around the problem I mean that's that's not bad except swarming around the problem then it's potentially taking people off the work if we problem solved this with the team maybe but that is what a backlog refinement meeting is for or a catch up so tricky tricky situation uh raise the issue in the next retrospective and take an action for the team Ah that's decent but it's going to be too late by that time because retrospective happens at the end of a Sprint so you know I think let's put a no for that one decent idea though place the cards on the kanban board so the team can see the work and get started I think we need to get the work ready has to be ready according to our definition of ready dor as well you'll see so all of that I think all of that all of this is done in a backlog refinement so I think we really need to go there let's go with answer a okay good stuff at a backlog refinement meeting the backlog is progressively elaborated and reprioritized or prioritized to identify the work that can be accomplished in an upcoming iteration very nice page 179 meetings and events backlog refinement good information to have not just for the PMP exam as well for the real world I think that's pretty good okay we're up to a question that's halfway through you're doing great let's do this you have completed a make or buy analysis in your project and found that part of your deliverable is best created by an external vendor sounds like a procurement happening so this is good these can be a little bit complex as well so we'll see how we go you work with your project team to create the procurement strategy Source selection criteria and statement of work so this selection criteria is we know the reasons why we're going to select someone so this is this is good and what are we going to do next so we've got our strategy as well which is good um so gather the seller proposals including technical details and price seller proposals I think we need sellers first actually so we've got our source selection criteria we need to find out who our sellers might be or could be meet with prospective sellers could be good to ensure all vendors have a common understanding of the procurement that could be good let's put that as a maybe for now perform Source selection on analysis on what you want from prospective vendors I think we've done that already gosh I hope I'm on the right track here so let's put a no for that one for now create the procurement agreement for the third party vendor to provide their specified Services I think the agreement is like a contract so we're not at that stage yet I think we need to meet with those Sellers and make sure that we get the right Sellers and that they all have the same understanding of the procurement so they can then provide you know requests for quote or proposal I think that's probably where we're going I think it's going to be answer B but let's see okay all right a bit lucky there these are always tricky these procurement ones these are the outputs of plan procurement management a business a better conference so better conferences that's what it is is meeting with prospective sellers prior to the preparation of a bid or proposal to ensure that all prospective bidders have a clear and common understanding of the procurement so that's good this meeting may also be known as contractor conferences vendor conferences or pre-bid conferences that's pretty good information to have too page 179 under better conference in the pmbok guide 7th edition wonderful stuff well done guys how did you guys go with that did you get to the same places I did we just sort of eliminated the other ones so it wasn't too bad all right next question one of the stakeholders in your project has raised a change request after some of the deliverables contained defects and a missed requirement okay your project has a formal Change Control process that's good as opposed to a more agile prioritized product backlog all that's good information to have what will you do next so formal Change Control how do we work with that gather feedback from other stakeholders to see if they also need the change I think it's pretty clear that we're going through with it it's we've already raised the change request let's leave that off for now note the change in the change log yep then place the requested item in the next Sprint we need to go through the Change Control process so again it said a more formal Change Control process we're not just putting it into the Sprint it has to go through that process take it to the Change Control Board okay that sounds good then communicate the decision to approve or reject the change definitely yes that's definitely your formal process I think that's pretty good raise the request as an issue that will affect your project schedule and budget I think that's not really what we're after here so I think for our purposes formal Change Control process Change Control Board let's go with answer C excellent stuff all right we're a formal change control processes in place a change controlled board includes the people who are accountable for reviewing approving or rejecting changes to the project the decisions made at this meeting are recorded and communicated to the appropriate stakeholders so good good information to have good to know page 179 under Change Control Board in the pilmont guide as well really great so you can go directly there and check that out for yourself if you really really want to that's good all right and we're more than halfway through now guys you're doing great in this little section 10 questions nice and neat little bundle we're doing fantastic your agile project has recently gained some new stakeholders after a department restructure okay new people this is great what do we do they complain to you that they're not seeing enough traction of work delivered through the project and they're worried that it will not meet their requirements okay tricky situation new people all of a sudden you know to other requirements different as well what do we do next invite them to the Daily stand-up so they can see the work that happens on a daily basis I mean the daily stand-up depending on the methodology that you follow some people say it should be open to any stakeholder other people say it should just be the development team so that's from your scrum so look there's a few different ways to do this uh I don't know because of that I'm not sure I'd put that as a maybe um if there's a better answer we'll go with a better answer I think invite them to iteration planning so they can choose what the team works on uh no it depends on our situation do we have a product owner because the product owner needs to put that you know choose what to work on the highest value item or you know what needs to be delivered next um so if we're just inviting all of these stakeholders it's going to end up in a bit of a messy situation potentially let's put a no for that one for now invite them to the retrospective so they can raise their issue there and come up with a solution they're not really part of the core team and really it's just to improve the core team's process so that's probably not the best one uh okay last one actually looks pretty good invite them to the iteration review so the Sprint review so they can see the usable increment that the team delivers this is when we demonstrate what we delivered in that Sprint and we demonstrate it to our customers to our stakeholders to anyone outside the team who wants to see a usable feature that we have delivered and created during the Sprint so now they can see what's been delivered and then they can comment on that and give their feedback and that's that feedback process I think answer D is probably going to be our one let's go with that all right wonderful stuff the iteration and or Sprint review is held at the end of an iteration usually of two weeks to demonstrate the work that was accomplished during the iteration to the project customers and stakeholders exactly like we said that's very handy page 179 iteration review wonderful good work guys how did you guys go with that one I think we got there eventually it's a few few good answers there too it was pretty tricky all right only three questions to go I think you're doing great let's keep going you have recently taken over a project your project team approached you to say that there is a regulatory approval that has not been granted yet and it might block development of your project in the next five months okay wow you check your Project's documentation but cannot see any mention of this what will you do next okay very very tricky so something coming up in the future as well possibly a risk if it's happened it's an issue before it's happened it's a risk and we can manage that and put controls around it and that sort of thing try and stop it from happening or mitigate that risk anyway okay let's see hold a risk review meeting capture it as a risk and ensure an adequate risk response well that sounds pretty good so put that as a higher maybe for now let's see it all what else we have just in case holder retrospective with your team to capture what challenges the team are facing I think there's probably a better answer there retrospective is for improving the team's process maybe not all of these things issues or risks so adjust your product roadmap to reflect the changes to the time frame of that deliverable we may not know yet because regulatory approval has not been granted yet and it might block it but we're not sure and it's coming up in the next five months so we're not sure on that either so not sure if we can do that or if that's the best answer at least escalate the regulatory approval to the project steering committee okay well I'm not sure what they're going to be able to do about it because it's a regulatory approval it's outside of their Authority as well plus where the project manager we really need to manage this as best we can instead of escalating it to someone else all of this to say I think let's go with answer a is the best option here all right great stuff the risk review is a meeting to analyze the status of existing risks and to identify new risks this includes changes to probability impact or urgency and determining if responses are adequate so that's good to know page 180 under risk review in the pmbok guide 7th edition and we're down to the last two questions in this section you've done an amazing job how did you go with that a little bit of risk always good you'll see it everywhere on your projects so good to handle it now okay you're an agile project manager and holding daily stand-ups with your team you notice people accusing other team members of not doing their job and there are some tasks that are not mentioned anywhere and no one is responsible for okay goodness the team velocity has slowed in the last three sprints what will you do next okay uh and the team are are having issues and troubles in our team process so what do we do we usually hold a retrospective so I think if there's anything like that we'll probably go with that um what's the first one though refer to the team charter that actually could be good and the team roles also good and agreed ways of managing conflict wow that's actually really good so that's a great answer um let's see what I mean definitely we'll see what else we've got just in case raise it as an issue in the next retrospective okay so there's that retrospective and come to a solution with the team that's also a good answer so all of these are good sign team roles to those you think are best suited I mean that's decent as well if we're a manager on this project probably a better answer than that one though let's put a low maybe on that one work with your team to size user stories correctly so velocity improves um so that's taking a different approach but I think we're looking at roles here roles and responsibilities so let's put a no on that one for now between these two these are both good so you know there's some tasks are not mentioned anywhere and no one is responsible for so even if we go to the team charter it maybe it's not there I think you know we're saying that it's actually not listed anywhere so in that case we need to problem solve and probably update the team charter so that's maybe a little bit of a trick again I think we're coming back to that problem solving retrospective with our agile team let's go with answer B okay all right two very good answers there but I think you know if it's if the information isn't there we can't refer to it so you know that's always that the agile approach is to problem solve with your team a retrospective is a regularly occurring Workshop similar to Lessons Learned similar to a Lessons Learned meeting where the team explore their work in order to improve their process and the product page 180 under retrospective in the bookmark guide excellent and what else is excellent you made it to the last question in this particular question set amazing work let's see what this one is I think this has been a great practice so far you're managing a large construction project due to some delays the project schedule has been pushed back by one week as a result one of the project risks has increased slightly but is still within the acceptable limits what will you do next okay hold a risk review and update the risk response and owners hmm maybe raise a change request for the change to the project schedule it's still with an acceptable limits so let's put a no for now capture the change in your project reporting and take it to the next status meeting I think that's pretty good we obviously want to keep our stakeholders informed so uh hmm I don't know none of these are really speaking to me yet update the Sprint backlog to reflect the delayed work oh that's probably a no especially on a large construction project so I think you know maybe on a software project maybe but still not the best so between these two so one of the project risks has increased slightly hold a risk review to update the risk response and owners do we need to update the risk response it's still within acceptable limit so it says do we update the owners no not really okay so purely by the process of elimination I mean this answer is okay communicating is always good um taking it to the next status meeting making sure people understand and know what's happening definitely a good thing so I think let's go with NCC okay all right that was pretty lucky Maybe how did you guys go with that one maybe uh maybe you got straight there I'm not sure but yeah it definitely by process of elimination does make sense a status meeting is a regularly scheduled event to exchange and analyze information about the current progress and the project and its performance page 180 under status meeting in the promotion seventh edition and so that's that yeah and you know what else is a good way to communicate is to communicate that we have made it to the end of this little section of pumbock and project management questions and PMP questions you have done an amazing job I also want to say that I truly believe that you can pass the PMP exam and when you do it will really positively impact your life I know it has helped me personally and especially in my career it's given me just such a great framework for working with projects and getting better outcomes that I could not get before I truly believe that you can also do it and we're working together we're doing it every day and learning and improving this is fantastic you are an agile project manager and your team have delivered three features to improve a customer app over the last three months your product owner needs to know if the features are having the desired effect it's a large organization and there are multiple measures available okay what will you do next so is this what are we going to measure this or how are we going to measure that the features are having the desired effect as a product owner this could be a little bit tricky what effect exactly are we wanting here let's have a look at the the options that we have ask them to gather the team velocity and throughput over the past three months okay that's more of a team measure so are we you know how fast are we delivering but again that's more of an internal team measure usually throughput is more how many features are we delivering so just purely how many features not are they having the desired effect so let's put a no for now ask them to gather the cost benefit ratio over the past six months the cost benefit ratio is more so how much did things cost versus what's the benefit that they got it's actually or the benefit that we're expecting usually so it's actually more of a measure we use to prioritize our items so what has the lowest cost but The Highest Potential benefit then we'd really want to do that one next you know that's not bad but I wonder if there's something better here ask them to gather The NPS over the last over the past six months net promoter score so net promoter score is a customer measure and the product owner represents the customer if they're not the customer themselves as well so net promoter score scores from one to ten How likely would you be to recommend this to a friend or something similar that's that sort of question it's a great customer measure and then you take then they do something Fancy with that measurement as well to find the detractors and the promoters something like that but uh but you know that simple measure one to ten is a good start and I think that's also a good measure actually so I think that's pretty good ask them to gather the average app availability and uptime so that's more around the sort of the operations of the app unless we were delivering features to specifically improve those operations I still think the customer measure is definitely the best from a product owner point of view let's go with answer C excellent work all right a product owner prioritizes features to improve usability and profitability of a product the net promoter score measures the willingness of the customers to recommend a product or service to others and is used to gauge overall customer satisfaction and loyalty to the brand or product under page 181 net promoter score in the promote guide 7th edition and that was a wonderful way to start us off all right let's see what we've got next you are a project manager in an agile team developing new features for an app an executive stakeholder with a high influence in the organization approaches you and asks you to add a feature that they like oh and of course this will happen all the time they call it the the highest paid person in the room the hippo and you know and they have a lot of influence and sometimes they get their ways simply because of the role or the title that they have very difficult situations they ask their friends and their friends think it's a good idea as well well of course they did you know that's confirmation bias that we'll see and you'll see that happen in the real world as well uh you know we we gather all of those opinions that that conform with our own and then we say well look everyone else agrees you know it must be a good idea how do we get some critical thinking around this so what do we do next okay this is a pretty good scenario actually place the feature in the product backlog and prioritize it using cost versus benefit all right that's pretty good that's what we were talking about before where we want the lowest cost but the highest benefit so now you know instead of just asking people whether they think it's a good idea we're getting some hard data on this that actually could be a really good one let's see what else we have just in case raise a change request to add the new feature into the scope Baseline I think we really want to analyze it first so let's say no for now gather the requirements for the new feature and ask your team to elaborate it on it well we need to figure out if we're doing it first so let's put a no for now as well analyze the impact to your Project's schedule and cost and add the feature to your project scope I think I would probably analyze the impact then then would raise a change request and then we'd gather the requirements but before all of that we need to figure out if we're actually doing it let's go with answer a excellent work all right in agile we have a product backlog that we prioritize prioritization schema are methods used to prioritize portfolio program or project components such as features requirements or even risks examples include multi-criteria decision matrices so we've got our criteria down the side and our criteria up the top and you know does it score high on this one and high on this one well that's a five maybe low on this one and low on this one that's a one for example so that's a good way to prioritize Moscow which is must have should have could have or won't have cost to benefit and more there's many different ways to do it some work better than others and you'll find your way in the real world but we've got page 181 under prioritization schema in the Pumba guide seventh edition wonderful work all right how did you guys go with that one let's get into the next question your project team are gathering solution ideas for a particular customer requirement which is prioritized to be worked on next the item is complicated and they've been trying to find a way forward for the past three weeks there is not enough work for the upcoming Sprint oh okay so we've got our upcoming Sprint not enough work to complete in that Sprint currently so that's not good and our requirements we you know they're fuzzy we can't really it's comp too complicated for them to figure out we need to get those requirements done so that we can get that work into the Sprint and keep the work going and flowing so how do we do this this is good all right start work on the item in the next Sprint anyway and elaborate as the Sprint begins um I think it's going to be pretty tricky then we're not actually delivering at this you know instead we're actually working on the requirements so a four agile I'd prefer to be doing both at the same time people who need to be working on the requirements doing that and then people who need to be developing doing the development work so you know making sure that that work you know doesn't stop uh that's probably the best scenario so let's put a no on that one for now arrange the right people to elaborate the issue with a spike okay Spike sounds promising that's a time-boxed research you know to try and figure it out getting the right people as well you know in the room making sure that they have the information the people uh to solve that problem close in person place and time and time box it to two days yep so let's do everything that we can in the next two days to try and figure it out that usually puts uh you know a deadline on it so that gets rid of this of student syndrome where we might just carry this on as long as we can until the very very last minute just like working on a project when we were back at school hopefully not the PMP exam study though of course right anyway last one adjust the project schedule to reflect the extra time taken on elaboration uh let's put a no for that one we'd prefer to solve it if we can and I missed answer C de-prioritize the item until the team can figure out the issue that could work you know if we could re-prioritize it and work on something else but it is kind currently work prioritize to be worked on next there's probably a reason for that let's try and work through it and get that time-boxed Spike done and get that stuff into the Sprint let's go with answer B okay excellent the spike is a short dedicated user story to research or analyze something a time box is a short fixed period of time in which work is to be completed often a few days to a few weeks and we've got page 181 under time box in the pinball guide 7th edition excellent work now we've got a few different agile terms coming through there which is a lot of fun so that's really good how did you guys go with that one a few possible answers there that could work as well in the real world and that you will have to work through in the real world too pretty good stuff all right your project team have planned the requirements scope schedule and cost for constructing a new building in your organization probably not an agile project this one man isn't it probably more of that sequential waterfall so this is going to be good an executive from another area approaches you as your project is funded and about to begin execution and asks if you can help them deliver a website as part of your work what will you do next okay this is a really pretty tricky because if we're working on a construction project you know there's not a high chance that we have website developers on our project it's probably more of a construction yeah we might have Architects Builders you know and all the rest of it um so what are we going to do here raise the request as an issue in your Project's issue log well I mean maybe there's a way we can work through it first add the website to your project scope and adjust your project scope schedule and cost I don't think it's really suitable for our project so let's see if there's a better option raise a change request for the added scope and review the impact to your project scheduling cost do we even have the people to work on this we're not sure so I hope there's an answer D is a good answer because we're running out of options here offered to help them create a business case for the new idea and get funding for a new project okay that sounds pretty good it really is potentially a completely different project it needs its own business case its own project Charter and it will probably need its own funding as well so unfortunately in this case they can't just you know jump on the back of our of our project it is a different scenario potentially with a different outcome so let's go with answer d all right great work the scope and and team required to build a website is very different from a physical building a new project with its own funding is the best option a business case is a value proposition for a proposed project that might include financial and non-financial benefits it typically precedes a project Charter and a formal project approval and kickoff so that's a use your project Charter to kick off or initiate a project using all of those things project or the the business case the benefits so we can show how much it will cost roughly and how what the benefits we'll get out of it will be at a high level page 184 earned a business case in the Pumba guide 7th edition wonderful work how did you guys go with that one I think we're really getting through these questions so you're doing a great job you're working on an agile project and you're planning your product backlog for the next three to six months you have some high level features of feature ideas from various parts of your organization from Frontline staff to Executives to customer re to Direct Customer research as well what will you do next Okay so we've got feature ideas that's exactly what we want we're working on an agile project planning the product backlog I think we've got those feature ideas and we've got a lot of ideas we really just need to prioritize them probably let's see if that's an option so well goodness I'm not sure if it is we'll see break down each feature into epics yeah we could do that and use the stories and then size the work with your team that actually could be a good option because then we're figuring out the effort so you know is it having a high effort or a low effort that could work let's put it maybe for now add all of the items into your product backlog and work on the ones from the managers first tempting to do we want to keep those managers happy but again we want to prioritize based on the best benefit and the lowest cost ideally or the lowest effort so let's put a no for now work with the requesters and your technical experts okay that sounds promising so we're getting everyone together to create a business model canvas for each feature okay business model canvas I think that is going to give us all of the information on one page about the the benefits about the cost about you know where how we think this feature is going to serve the company and how we think it's going to win and help our strategy and stuff like that so that actually could be pretty good as well and then we can use that information to prioritize and then once we've prioritized because that's going to give us a bit of the size information as well pretty tricky A and C are both pretty good perform precedence diagramming on each feature to determine their dependencies uh I think Paul we can't really do that until we get more information about how it works the solution potentially and then even break it down so noting that let's get that information first so we can prioritize it and then we can break them down into epics and user stories once we know which one we want to work on first that's rolling wave planning high level in the future detailed level up close so I think for our purposes let's go with answer C all right great stuff the business model canvas is a one-page visual summary that describes the value proposition the infrastructure customers and finances they're often used in Lean Startup situations but yeah we can use that to feed into everything else page 184 under business model canvas and the Puma guide 7th edition wonderful stuff guys and we are halfway through this little section you're doing a great job how did you go with that one a few potential answers there as well just like you'll find on the real exam a little bit tricky but good to work that through all right let's see what we've got next you're working in a new agile team where the work has started to slow and there is uncertainty and low team engagement you set time to create a team charter with your team hey that's great we must have learned from all the other questions that we've been through previously we've done that a few times now agree on roles and responsibilities and the team Cadence that's good stuff we're going to try and get that Clarity in the team improve the engagement of the team what will we do next okay set a team goal for them to be more engaged in the work over the next three months potentially yeah I mean goals the the what are we doing that's pretty good create a product vision statement showing the value you're bringing and the why behind the work now that's really good so that's part of us creating the team charter so roles and responsibilities plus that that product vision statement so that actually could be very good ask the team to contribute more to all pieces of work during each team meeting I don't think that's really what we're talking about here you know so maybe that's something for a different time but not as part of us creating a team charter raise it as a people issue for your project and manage it with the project steering committee so you know I think we are managing it ourselves and I don't think we need to escalate this just yet we want to manage it first and do the best that we can as project managers so let's put a no for that one for now I think for our team charter let's do that product vision statement the why behind the work the value that we're bringing I think that's going to be really good let's try answer B okay all right that was really good the project vision statement is a concise high-level description of the project that states the purpose and inspires the team to contribute to the project page 184 under project vision statement in the Pokemon guide 7th edition and that's really really good stuff so I think you know we're getting with through those engagement questions and I think we're getting pretty good at those by now actually so how did you go with that one I thought that was pretty good what have we got next you're integrating a third-party system as part of your project the developers in your project team have not worked on this system before but they believe the language and layout is the same and they should be able to implement it adding a bit of time for the uncertainty they give a high level estimate of five weeks what will you do next okay that's actually pretty good so estimation so this is good do we need to give ourselves a bit of leeway you know if we've got five weeks do we want to add a little bit on the end there um we've got some assumptions there so how do we manage those let's see what answers we have note the estimate of five weeks and update the Assumption long okay well that's good with the technical assumption that the languages and layout is the same so that actually could be pretty good I wonder if we add a little bit of time in there but let's put them maybe for that one for now don't add the estimate break down the integration into user stories and use a bottom-up approach I mean that also could work so you know but if we're just trying to get a high level idea I mean that's definitely a good answer I wonder let's work through these and see what else we've got check the estimate using parametric estimating to increase its accuracy also a good idea potentially not the best idea for us so let's put a low maybe for now I think we need to just get that estimate done bottom up estimating with user stories is typically agile doing noting the estimate and the assumption is also really good practice so yeah we can put that one as a lower one for now gather your whole team and customers together and estimate using wideband Delphi or planning poker where we have one round of of estimation another round and it gets closer another round and it gets closer and each person explains their highest and lowest uh you know estimates and then we re-estimate and it usually gets closer and closer and closer until after a couple of rounds it's probably the most accurate that we'll get it that's also good practice to do so all of these are really good but here's the information we have you know they know a little bit about the system we've made an assumption we've got an estimate of five weeks already so I think let's put that estimate in and with the Assumption and let's go with answer a okay all right an assumption is a factor that is considered considered to be true real or certain without proof or demonstration a constraint is a factor that limits the options for managing a project program portfolio process an assumption log records all assumptions and constraints throughout the project okay so that's pretty good good to know and I think that's obviously where we were going with that question so that's pretty good page 185 under assumption log in the purple guide seventh edition and of course that can apply to many other questions that you might see so it's good information to have now let's see what we've got next your agile project has delivered three features so far and is halfway through delivering the latest Improvement you're during a brainstorming session one of your customers comes up with a new feature idea you check the benefit and the benefit is high the complexity is also low so this is exactly what we're After High benefit low cost or complexity so this is this is good what are we going to do next all right well I mean it seems like we'd probably want to work on this so let's see and it's come directly from the customer as well so that's wonderful all right add money to your budget to accommodate the additional feature as soon as possible maybe but on an agile project we usually have a fixed budget and fixed time and then we have a variable scope so the scope can change which is what we're doing here we're changing and re-prioritizing that scope so hmm I wonder if there's a better answer here elaborate on the feature break it down into user stories and estimate them again I think we need to prioritize it first so you know do we even want to work on this we're not sure we don't want to break it down and spend all that work on it if we're not sure so let's put a no for now place the item in the backlog and re-prioritize it to be next yeah okay well there's that there's that magic word prioritization reprioritizing as we said High benefit low cost is a good thing that does sound like what we would do I think would put a high maybe on that one for now create a business case for the new feature outlining the benefit and costs involved well I think we already have the benefiting costs involved and a business case we would do it on a waterfall project but for an agile project we place it in the backlog and prioritize it based on you know the prioritization schema depending on what that is this one seems to be pretty solid I think let's go with answer C excellent work guys a backlog is an ordered list of work to be done projects may have a product backlog a requirements backlog an impediments backlog and many other things items in a backlog are prioritized and prioritized work is a scheduled for upcoming iterations or Sprints so we'll place it in there so that we can get it done in each usually in each two-week Sprint as we've got there page 185 under logs and registrars the backlog in the pinball guide 7th edition excellent work all right how did you guys go with that one we've only got two questions to go in this little section you are doing amazing work okay one of the senior users testing your product has found that it was missing a key requirement that he had assumed would be there it was not noted in the project scope which has been baselined already you check the impact to cost and schedule raise a change request on his behalf so this is great good good process here and you take it to the Change Control Board where it is approved hey this is do we need to do anything else I'm not sure so that sounds pretty good do we just work on it now what will you do next okay ask your team to elaborate and turn the requirement into user stories yeah I mean maybe we do maybe we just go ahead with it is there something we need to do first though let's have a look place the new requirement into the Sprint backlog for the next Sprint um I think we need to turn it into acceptance criteria and actual user stories first so we can't just place the requirement in there we have to elaborate on it and figure out what the actual work is first do we add the missed requirement to the issue log and solve and problem solve with your team to ensure it does not happen again in the future I mean yeah maybe we do do that but but potentially after all of this I think we need to figure out what to do with it first so we can problem solve that's also a good option gosh there are a few good options here again so let's see what the last one is note the outcome in the change log and communicate it to your stakeholders okay this one I really love because this is actually the Change Control process so once we've had it approved by the Change Control Board we need to note that back in the change log and then we need to communicate the outcome to the affected stakeholders so we do that first then we elaborate on it then we place it in the Sprint and then we take it to the next retrospective and we problem solve and figure out how to avoid that happening in the future so the first Best Next Step let's go with answer d excellent all right a change log is a comprehensive list of changes submitted during the project and their current status a change can be a modification to any formally controlled deliverable so any Baseline document a project management plan or project document and we've got page 185 logs and registrars change login and promote guide 7th edition great stuff guys and you know what else is great you have made it to the last question in this little question said 10 questions you've done an amazing job really great preparation for your exam let's see what that last one is you have you're working on a hybrid project to replace an aging customer system that has just had a feature upgrade release the senior developer raises a concern during the daily stand-up that the system doesn't seem to be able to connect to some parts of the organization after the upgrade Okay so we've had an upgrade and then now it's it's broken something by the looks of it okay what are we going to do next re-plan the project to ensure the correct scope is worked on that will connect to the organization we may need to do that yeah potentially um so but what are we going to do immediately you know we've currently got an issue I think it's actually happened it's impacting our project here we go raise it in the issue log could work for us assign it to a responsible party absolutely and work with them to find a resolution I think that's pretty good so and you know we don't have to know all the details of this but we have to know the process so that we can go through this find the right person to work on it and help them come to that resolution make sure we're not we're removing any blockers making sure they've got free work they've got all the connections that they need and the people that they need to get that answer and that outcome I think that's pretty good that one so let's see the other two just in case raise the concern as a risk and brainstorm risk responses it's already happened so it's more of an issue escalate the issue to the technical manager so they can resolve it I think if we're going to do that we prefer to do it to any responsible party it may not be the technical manager and uh you know and we need to raise it in the issue log as well so that's still the best answer let's go with answer B antastic and issue log is a current condition or situation that may have an impact on the project objectives and issue log is used to record and monitor information on active issues issues are assigned to a responsible party for follow-up and resolution and we've got page 185 under logs and registrars the issue log in the pinbook guide 7th edition and you guys have made it you've made it through this 10 question set scenario based questions really great preparation how did you go I hope they were really enjoyable and also I hope you learned something because I know I did but more importantly with this preparation I truly believe that you can pass the PMP exam and with the dedication that you're showing every single day to learn something new and to improve your skills I know that nothing is too great you'll be able to achieve anything with that mindset in the future as well I know you can do it you're working on an agile project where your project team have raised multiple risks to project delivery some of these risks may impact your cost and schedule significantly your program manager asks you to manage them using a risk adjusted backlog what will you do next okay looks like this is just a question about a risk adjusted backlog so what is that it's where we take our risks and we place them into our backlog of work and we prioritize them against all of the other items as well so make sure that we end up doing them in uh you know in in the Sprints as we're going along on our work so it's not just normal work now we include risks as well it's risk adjusted we're including risk in our backlog let's see what we've got here adjust your risk register to include the work not completed if the risks are triggered I think no backlog in there so we'll say no adjust your backlog velocity OH Close we've got that nice word but velocity doesn't really match so that your end date is not impacted by the raised risks so we're not really looking at the velocity here so that how much work we can complete lead it's more you know can we place this risk and get that done as well as other items in as part of our work gather risk mitigation responses from your retrospectives and assign them to an owner I think that's close but I see probably the best one here place at least one risk response so that's those risk responses it's good to have but we want to work on them as well we place them in each Sprint in an agile project to manage and close so now they're in our backlog they're going into being worked on and that becomes our risk adjusted backlog I think I think probably out of all of these you know that's probably the best one definitely agile Centric so let's go with entity okay a risk adjusted backlog is a backlog that includes work and actions to address threats and opportunities so even though we're sort of putting those into each Sprint sort of has to be in the backlog first so I think that's still appropriate we've got page 185 risk adjusted backlog in the pumbot guide seventh edition a great way to start us off right how did you guys go with that one let's see what we've got next you are delivering a project to a functional area in your organization the project is highly complex and there are many risks to project delivery the functional manager would like to see the biggest risks that are assigned to her what will you do next okay so risks who are they assigned to what do we do how do we figure that out is it the risk adjusted backlog I mean maybe if they're you know the the risk user user stories or cards maybe they're assigned to someone in their place in in the Sprint potentially but what about all the other ones well in the backlog as well that could work let's put a maybe for that one for now show the risk register um I think that's probably the one it doesn't say we're on an agile project specifically as well so risk register will have the risks their responses um and you know the stakeholders the people who it's assigned to so all of the information basically it's it's the whole register of all the risks and that information that probably going to be our one I think it has all the information we need show the risk management plan that's the risk process so how are we Gathering and managing risks show how the qualitative risk assessment that is our impact and likelihood and we put the impact and the likelihood together and we get ourself a qualitative risk assessment I think that's not going to give the information that we need but the best one between these two they're both good not specifically an agile project best case scenario risk register I think and to be fantastic a risk register is a repository which outputs in which outputs of risk management processes are recorded So information can include the person responsible for managing the risk the probability and impact so we've got this in there as well which is good planned risk responses and more so all of the information that we do need page 185 under risk register in the public guides 7th edition looks like we're working through artifacts so there is a section in the permok guide seventh edition that has just the artifacts that you'll use on a project as well so I think we might be working through some of these by the looks of it and that was pretty good there we go risk register now we know all right how did you guys go let's get into the next question your project has been in progress for the past six months someone you have not met before approaches you and says they've not been engaged sufficiently even though he believes his team is highly impacted by the change Okay so we've got high impact so impact and potentially I'm not sure about the influence but we'll soon find out either way if it's a high impact we definitely want to help and manage those people closely and work with them closely he advises he may block the project as a result okay and that can happen and that's not good what are we going to do next about this it's stakeholder engagement is so important for that reason because things can go wrong when we're not engaging properly perform stakeholder engagement assessment with your with your stakeholder okay well that's pretty good that's what we do here so yes I think that's a pretty good answer let's see what else we have just in case add him to the stakeholder register including his salary and interest information I don't know about salary I don't know about interests either I think that's a little bit of a funny answer that one stakeholder register I like so let's put a no I see there's another stakeholder register add him to the stakeholder register including his impact and influence information which is this again so we're taking this and adding to it now we're putting him in the stakeholder register as well which is very appropriate otherwise he's not there he's not listed and you know if someone else takes over the project they won't have met him before either and he won't be listed anywhere so that's actually better that's a better answer raise a risk to the project delivery due to the nature of his actions I think there's better answers here we need to manage this first and you know I don't maybe it's a risk but probably there's better answers and I think the best one is answer C okay excellent work a stakeholder register records information about project stakeholders which includes an assessment and classification of the of the stakeholders we need to know our stakeholder ensure their details are recorded and where they fit before we take further action that's very good all right so page 185 under stakeholder register in the promote guide 7th edition how did you guys go with that one a few good answers there again so that was good to work through I think we're getting through this pretty well all right let's keep going you are a product owner on an agile project and you've created a product backlog of features in a prioritized order for delivery okay that sounds pretty good that's what we're supposed to do so that's great you ask for team to break down the first feature into user stories and estimate their effort what will you do next this is great so we've got our product backlog high level features now we're breaking those down into user stories and now we have you know efforts for each of those stories which is really really good story points for example maybe fives threes twos maybe there's an eight in there somewhere we're ready to go so we're potentially ready to work on these so do we create an iteration plan with your team and the iteration is a Sprint so same terminology similar terminology so Sprint plan with your team we take all that information we place as as much as we can in the Sprint to match our velocity or how much we think we can do I think that's actually really good that's a great answer that one so let's see what else we have create the product roadmap with your team that's part of the product backlog but just put on a road map when do we think it's coming out similar to a Gantt chart sometimes or a schedule but we've already passed that so we're now breaking it down into user stories I think we're past that stage perform a Sprint review that's where we demonstrate the items so we're not there yet begin daily stand-ups with your team and I think we can't do that until we plan the Sprint so let's go with answer a excellent work all right an iteration plan is a detailed plan for the current iteration it usually matches the estimated work for the Sprint to the average Sprint velocity so if we think we can get 40 points done or that's the average over the past five Sprints then we put 40 points worth of Cards into the upcoming Sprint and we try and get that done you know in the upcoming spring so items from the product backlog are broken down into user stories and placed into upcoming Sprints page 186 plans iteration plan in the promo guide 7th edition wonderful stuff all right and we're nearly halfway through guys you're doing an amazing job how did you go without one lots of agile terminology there lots of agile ways of working pretty good stuff we're getting pretty good at it I think all right what have we got next you have worked with your project customer to create a list of features that will bring the most value to them excellent these guys are just doing so great you know high value that's what we want that's exactly what we want so good times they would like to see when some of this value will be delivered and the expected outcomes of each what will we do next okay great how do we do this so we're doing on the right track that's at least show the features at the next Sprint review so the customer can see what they look like I think we're probably more after a schedule or a product back our product roadmap here I think we can demonstrate it but we need a future view as well so let's put a no for now place the features on a release plan and show this to the customer that could work yep release plan I think that's appropriate that's basically or similar to what a product roadmap is anyway it's going to come around here release Here release here I think that's pretty good check the features against the velocity chart to see when they might be delivered oh I don't think that's necessarily potentially but that can change I think in agile we have a high level view with the product a roadmap more so that release plan I think is more appropriate maybe we'll this will be an input into that release plan potentially so it's pretty good but not the best answer place the features into the next Sprint plan and show this to your customer okay but what about all the future stuff as well so you know again not too bad but not the best answer I think let's go with the release plan so we can get that forward view let's go with answer B okay excellent work this release plan sets expectations for the dates features and outcomes expected to be delivered over the course of multiple iterations page 186 under plan's release plan in the permit guide 7th edition all right that was really good we're really getting through those plans and artifacts as well so we're certainly going to learn a lot about those and also you're halfway through this little section so we've done amazing good job guys let's keep going you're in the planning stages of your project where you need to find out exactly what the project customer needs so you can find a solution and make it happen your business analysts are new to their roles and they're not sure what their process will be what will you do next so we need to find out exactly what the customer needs their requirements and our business analysts who would usually help you know extract those requirements gather those requirements from the customer or work with them to figure them out uh you know what's the process for them to do that so how do they actually do that we need a plan so we need a requirements management plan I think so ask the business analysts to begin writing user stories so not just yet we need that process first create the project management plan to outline how the project will be delivered I think we need to get more specific than that it'll be it'll actually go into the project management plan so I think that's what we're after work with the business analysts to create a requirements management plan and that also could be sometimes this is called the business analysis plan as well so how are we managing requirements how are we going through our process uh as part of matching requirements to scope all of those things um I think that's probably a pretty good answer that one create a work breakdown structure on the project scope so now we're breaking it down yes that's a good Pro process but that just might be one process out of many different things that we have to go through for our requirements so I think for our purposes let's go with answer C all right great work the requirements management plan is a component of the project management plan that describes how requirements will be analyzed documented and managed page 186 requirements management plan in the permokai wonderful stuff all right so we're really getting through those figuring out what to use and when this is pretty good and of course direct from the permit guides so really good way to study all right how did you guys go I think that was pretty good and now we're down to the last four for this section so let's keep going you're doing great you're working on a new software application with a lot of complex interdependencies the senior user providing and testing most of the requirements is concerned that some of those dependencies will cause errors upon release if they're not checked thoroughly what will you do next okay senior user is doing a lot of the testing hmm interesting and so we've got requirements and interdependencies and that they're going to cause errors when the product is released okay wow there's a lot of information here so potentially a lot of things we could do ask the senior user for a written list of all his requirements then check if they're included in the project scope is that going to figure out the dependencies or you know help manage the testing I'm not sure probably not let's put an O for now raise a risk on the software complexity with a project team maybe and then we can manage that let's put it maybe for now create an affinity diagram with the senior user where we were grouping things together as per their Affinity to each other so you know I don't think that's really appropriate here we've got complex risks and interdependencies this could show some things that are you know have an affinity to each other so that I mean yeah that's a that's another maybe as well review the test plan with the senior user okay uh but you know what like everything all of this goes into the test plan so you know the requirements to the test cases and the acceptance criteria so that shows us what we're testing when we're testing how we're testing all of that and all of that complexity and the interdependencies would be covered as part of our test plan so that's where we need to catch it before it's released none of these really jump out at me you know risk is okay Affinity is fine but test plan is probably the best I think for us let's go with NCD okay excellent work a test plan is a document that describes the deliverables that will be tested tests that will be conducted and the processes that will be used in testing it forms the basis for formally testing the components and deliverables page 186 under plans test plan in the promote guide 7th edition another plan for us to check out but pretty good actually good information to have as well we're definitely going to be able to use that in the future how did you guys go with that one all right I think that was great we've only got three to go so you're doing well you're planning your project and have captured the requirements from the project customer you ask your team to plan the project scope but they need to see exactly what needs to be delivered and how each part relates to each other what will you do next so what we're delivering is the product so and how does it relate to all of the other parts we've got this part I think it's probably a breakdown so a breakdown structure potentially so create a product breakdown structure with your team that could definitely work now this piece is related to this piece over here Etc so it could be good create the requirements traceability Matrix with your project team that's the requirements to the scope into testing criteria and you know into deliverables as well so so that's not too bad but how does it relate to each other part we're not sure so probably not the best one create the risk breakdown structure with your project team similar but not as good create the scope manage management plan with your project team that's that's the process of how we're going to manage the scope not necessarily how it relates to each other so I think for our purposes the best one is the product breakdown structure and that will show the the sort of dependencies and how everything interrelates let's go with answer a okay excellent work a product breakdown structure is a hierarchical structure reflecting on a product's components and deliverables it provides an exhaustive hierarchical tree and I hope I've said that correctly structure of deliverables that make up the project arranged in whole part relationship so whole to a parts or to the parts and we've got page 187 product breakdown structure in the pilmore guide seventh edition that was pretty good all right how did you guys go with that one I think we're definitely getting there I think getting through these a little bit faster I think I mean we're getting better at this so this is pretty good and we've only got two to go so you're doing great you've just finished breaking down the scope with your project team that will meet your customers requirements your program manager wishes to control the scope the project scope control the project scope so any changes go through the proper process what will you do next sounds like we're baselining the project scope here I think and I see that here that could be our one let's see what we have just in case create the change management plan to see how changes will be managed well we need to Baseline our items first I think so that they're controlled and also baselining the project scope and noting it in the configuration management plan so that it's a baselined item I think that's actually really really good so yeah let's see what else we have create the scope management plan with a rule minimizing changes that's the process of scope management but we need to know how what is the Baseline what does it look like I think that goes into the configuration management plan create a resource assignment Matrix limiting roles and that could be also be a responsibility assignment Matrix limiting the roles who can approve project changes project scope changes I mean that could also work but I think we still need to know what is the Baseline what does it look like and you know what is the item what are the items that are baselined in the configuration management plan I think for our purposes let's go with answer B okay wonderful work a baseline is the approved version of a work product or plan where actual performance is compared to the Baseline to identify variances baselined items are noted in the configuration management plan all right we got it you did it well done great work page 188 under bass lines in the Pokemon guide so many artifacts we're definitely going through those artifacts now so I think we're not going to have too much trouble there on the PMP exam so that's pretty good how did you guys go with that one but more importantly we got it we're done we've done nearly done the 10 questions we're up to the last one so you've done a great job and it doesn't look too tricky either so amazing work you have planned and begun the current Sprint where the project team have committed to delivering and releasing a particular feature you need to see how the team are tracking towards their Sprint goal what will you do next how are we tracking towards our Sprint goal I think I know where we're heading here the kanban board we could do that so kanman board you know uh cards that's actually not bad you can see it uh is there a better answer though team velocity chart velocity chart shows usually previous Sprints and what we said we could do versus what we did then the next Sprint what we said we could do versus what we did what we said we could do versus what we did so that's our velocity so and maybe it's 50 points maybe it's 45 here for example so measured in velocity usually but for that purposes how we're tracking towards the goal you know not really it's used to measure other things you review the Sprint burn down chart I think that could be could be quite good so we've got all of the items in our goal up here from here to the end of the Sprint is a straight line and then this is how we actually complete uh the items uh and maybe we've got a bit of a break and then we finally get there at the end so the Sprint burn down chart is a burn down of all of the items as we complete them I think that's probably going to be the one perform a Sprint review with the team so Sprint review shows what we have completed in a Sprint and we demonstrate to the customer but for our purposes I think the best answer let's go with answer C okay wonderful work a burn down chart is a graphical representation of the work remaining in a time box for example an iteration or a Sprint of two weeks it compares the ideal Trend with the items actually completed like we said a Sprint review demonstrates what was created during the Sprint once that Sprint is complete and we've got page 188 under burn down chart in the pinball guide 7th edition and you made it you made it to these 10 questions wonderful work I hope you enjoyed them but more importantly the work that you're doing is really really going to help you pass your PMP by showing what are the correct answers what are not the correct answers and figuring it all out together and also putting that back directly from the promot guide this is a great way to learn I truly believe that you can pass your PMP I know you can do it with all of the work you're putting in a little bit of dedication every day can work wonders and I know you can do it your agile project has recently been merged into a larger program and the program manager is reviewing how the project is tracking she asks you how much has been completed in design but also how much has been completed in development testing and sign off what will you do next okay I think this is uh in agile there's a few different ways we can do this so show her the Sprint kanban board that could work obviously we've got the different phases so we've got the backlog then we've got you know whatever phases you want to put on your kanban board so you've got potentially requirements maybe design maybe sign off or testing you know something similar anyway whatever it is you choose so you could see all of the cards but that would usually just be for one Sprint so depending on how we're managing the project let's see if let's see what else we've got just in case take us through the team product backlog so that would be the backlog of work but it won't show at which which phase everything is in necessarily so let's put a no for now show her the team cumulative flow diagram okay so cumulative flow diagram is like a line graph but it shows uh each phase so maybe we've got all of these ones down the bottom here and that's uh in design and that's been completed and then we've got in uh in development and then in test and then in sign off and so overall that's all of the stuff but here are the little different sections and where they've been completed and how much has been completed so that is actually pretty good that's not just for a Sprint that's over the whole pro project as well so or for the for the whole product so I think that's pretty good that one let's see what else just in case show her the team velocity chart well that'll just be the velocity chart so how much velocity 50 points for example in us on average in a Sprint that's not for each little section so I think for our purposes let's go with answer C all right wonderful a cumulative flow diagram indicates features completed over time separated at each stage such as features in the backlog then design development testing and more pmbok 7th edition page 188 and the cumulative flow diagram really getting into these diagrams and artifacts in the Pokemon guide as well so this is great obviously we're getting through it getting near the end of the book so that's really good news how did you guys go with that one let's see what we've got next features developed by your agile team have added some complexity to your website delivered quickly with no time to refactor the code so it's a bit messy code perhaps so it hasn't been refactored hasn't been cleaned up and made nice you believe the user stories are moving slower now as a result but you can't be sure what will you do next okay how do we know if and when user stories are moving slower as a result do we check the velocity is sort of for the whole team check the cycle time of the chart of the team that actually sounds pretty good cycle time is time to complete one item so just from when we start developing to finish developing or cycle time for testing start testing and finish testing that's the cycle time of testing that card so that is actually pretty good that's your user story cycle time lead time is from the time the customer makes the order or the item goes into the backlog at the very very beginning to all the way through to the time that it is delivered to the customer so that's you know the full range and you've got multiple different cycle times in between that so that's there so what else have we got I mean that's pretty good I think that could be the one Shadow the developers to over view the work that they're doing um you know I don't think that's going to give us the answers we need view the product roadmap for posed release dates I don't think that's going to give us this user story you know how much how long they're taking review the points in the Sprint backlog versus the last three Sprints velocity that could give us a bit of an idea of how the team is tracking as a whole but not just for the individual story cards so for our purposes I think let's go with answer a all right excellent work a cycle time chart shows the average cycle time of the work items completed over time it can be a scatter diagram or a bar chart actually and usually it has um so you know if you've got days so 10 days for example zero days here and an items completed here here it's sort of a scatter chart and then it will usually give you a bit of an average over time so that's your cycle time of all of those user stories and again many programs will have that information that you can extract a chart from pretty pretty well all right that's pretty good we must be getting into the charts and an artifacts section of the pmbok guide now I think so you know this is good to be going through you're working on an agile project with a full product roadmap for the next six months your project team are not sure what the next feature does or how they should turn it into user stories what will you do next Okay so we've got product roadmap of features how do we turn that into user stories and we're not sure what the feature does as well so that is a clue I think for us so review the scope Baseline the scope Baseline would just sort maybe not on agile project either so I think it's not a great answer story mapping with your team is where we take the features we break them down into usable parts and then into you know into parts that we can actually deliver again into user stories so story mapping breaking it down it's like a work breakdown structure in a way but based on the usability of a product so that shows us what the feature does and also how to turn it into user stories so that's actually pretty good Sprint planning with your team we need those user stories to go into the Sprint plan so we can't do that yet perform a retrospective with your team at the end of the retrospective then we check in and we ask what went well what didn't go well what still puzzling me what have I learned and we take any actions to you know for anything that's not going well and we try and solve them and problem solve them with the team but that's not what we want here I think let's go with answer B all right wonderful work our story map is a visual model of all of the features and functionality desired for a given product give are created to give the project team a holistic view of what they're building and why it can also break the feature down into user stories based on functionality page 190 under story map in the Puma guide 7th edition excellent work guys how did you go with that one that was pretty good we're really getting into those artifacts so that's really good stuff and we're getting through these questions really really well you're a program manager on a large-scale agile program where each project team has its own scrum Master you need to know the rate at which work is flowing through each team so you can see if there are any blockers or issues and whether they will remain on track what will you do next okay so the rate of work for each team so that could be good raise your query at scrum or scrums so each team knows what they need to do if there's a better answer there do we know what we need to do I think you know maybe we can come with some information there let's put a low maybe on that one attend the Sprint review of each team at the end of each Sprint that could work yep I mean that's that will show what was completed I suppose but will it give us the rate of work maybe not it's just a demonstration review the schedule management plan for managing the schedule so that's the process of what we're going to do to manage the schedule I don't think that's appropriate to show us the rate of work so I hope answer D is a better one because none of these are any really good at the moment review the team velocity charts that could work and what was committed versus what was completed we said we'd do 50 points and we got 47 you know pretty good and now our average our average is you know 45 so we commit to 45 we managed to do 47 again you know so that sort of thing that's your velocity chart goes over time and each Sprint has what was committed versus what was completed I think that's probably going to be our best answer to show the rate of work let's go with answer d alright excellent work the velocity chart tracks the rate at which deliverables are produced validated and accepted within a predefined interval like a Sprint for example page 190 under velocity chart in the pmbok guide and we've nearly made it to the halfway point so you've done an amazing job and then after that only five to go let's keep going we're getting through this really really well your project has been executing for the past five months and due to an organizational change a new project sponsor has come on board okay what's going to happen here he asks where the project is up to and whether it's on track you tell him but he wants more information what will you do next okay uh what can we do here show him the signed project Charter okay well that's sort of taking it back to the beginning of the project isn't it where we kick off the project to ensure that he honors the original agreement I think we need it like a status we need to know where the Project's up to actually so let's put a no for now show him the project management plan including the schedule management plan now again with this while it will have some information in it it's more about the process so that's the process of how we're going to manage these things the schedule and how we're going to manage the project and all of those things that go into the project so there will be some information in that it's probably going to be a lot maybe too much plus it's more about the process of managing on how we're going to do it so that's a that's okay but let's see if there's something better review the status report okay that's promising and re and previous status report with the sponsor Okay so we've got the previous one and then we've got this one as well so we can see how it's actually going you know is it the same is it still on track did it go way off track is it getting better um you know that actually is good for whether the project is on track or not usually you'll have uh red Amber and green they call it rag status um you know how is the project tracking or maybe you'll have some variance information in there maybe where you know a hundred thousand uh you know below budget or something similar so I think that actually could be our one invite him to the next Sprint review so he can see the progress made we don't see an agile project here specifically so um you know that's not bad but I think whether it's on track or not that will show us a piece of progress but not all the progress so let's go with answer C excellent work the status report provides a report on the current status of the project it may include information on progress since the last report and forecasts for cost and schedule performance in the future as well page 190 reports status report in the promote guide 7th edition great work guys how did you guys go with that that was pretty good I think you know we were able to eliminate some of those answers there that don't really fit so we're doing a good job and we're also more than halfway through now so let's keep going your agile project needs a third-party vendor to help complete the work the project of the product owner has multiple features on their roadmap excellent work which may change over time excellent they might be re-prioritized for example making the scope of your project uncertain okay so we're dealing well so we've got a vendor and we've got uncertain scope and an agile project so how do we manage that in an agile project what do we do next okay ask your product owner to fix the features and scope so the project is more certain well that wouldn't really fit an agile project then I think maybe there's a better answer here create a Cost Plus incentive fee contract with your procurement team goodness these are actually quite tricky that's not bad incentive fee with your procurement team that definitely could work they're charging us what it will cost no matter what the cost is and then there's an incentive fee usually based on a few factors like do they get it delivered quickly or that sort of thing so we can put those into the contract oh so I mean that's not bad then if the cost goes up or down depending on the new features could work let's put a maybe for now create a firm fixed price contract with your procurement team I think that will be very difficult because you know everything is changing over time so it's probably not fair to us or to the vendor to have a firm fixed price for a firm scope and a firm price let's put a no for now use the external vendor funding to create a project team in-house and complete the project wow okay you know definitely so agile part of agile is the whole team approach where we're trying to bring everyone into the project team so do we go with the whole team approach try and bring the vendor in-house or do we work with an agile Centric procurement contract which will work from based on the cost and an incentive fee to keep them happy I think probably the easiest way at the moment would be to do the the contract we don't know if we can actually bring an external vendor in-house so you know there's all sorts of complexities around that it could get very messy I think the simplest easiest way still agile Centric let's go with answer B okay all right that was pretty lucky they were both good those answers let's see if it gives us any tips here cost reimbursable contracts involve payments to the seller for actual costs incurred for completing the work plus a fee representing the seller profit they're used when the scope is not well defined or subject to frequent change well there's our clue it includes Cost Plus Award fee fixed fee or incentive fee page 191 under cost reimbursable contracts in the promotion okay that was pretty good so really good to work through definitely after that contract information so that was good to know as well how did you guys go with that one it was pretty tricky and we've only got four to go so you're doing great let's keep going your project is releasing a number of upgrades to a commercial building over the next 12 months material costs have changed a lot recently okay you need to budget for the materials required however the volume of materials may change significantly as the project evolves what will you do next all right so and again I think we're starting to get into that procurement stage so contracts and vendors and that sort of thing so how do we deal with contracts and vendors from a pumbuk guide perspective so I mean there are a few contracts here create a firm fixed price contract for the materials you know but that indicates that we would know exactly how much we need so we need this much and we're going to pay this much and it's firm and it's fixed but it's going to change for us so we can't put that one for now ensure a sole supplier for your materials or ensure multiple suppliers for your materials so between those two while this one could work it's not going to solve the problem of having you know that we might need more and and then the change the price might change as well so that's going to get us but I think this one here so idiq and this is a type of contract indefinite delivery indefinite quantity so we can have an indefinite delivery time frame that we choose and put into the contract and an indefinite quantity so the quantity can go up and up and up and up and up it can change it doesn't matter but we put that at that certain price over the next 12 months for us for example I think that's probably the contract that we would want to go with under this circumstance let's try answer a okay excellent indefinite delivery indefinite quantity provides for an indefinite quantity of goods or services with a stated lower and upper limit which is good and within a fixed time period so that's also good fixed price will work better if the quantities are known so that's that's really good to know as well page 191 under agreements and contracts in the pinball guide 7th edition how did you guys go with that one that could be a new contract for some of us but all of these things will be good to know they might pop up in the exam different types and just when are we going to use them what circumstances all right let's see what we've got next you've completed a make or buy analysis and you agreed to hire a third party vendor looks like we're really doing vendors here to complete part of your product you create the statement of work and have a list of acceptable sellers that will meet the source selection criteria okay so statement of work we know what we need to deliver we have the sellers that we need that can deliver for us so that's good the work is not complex that's even better and they understand the scope so everyone understands that it's pretty straightforward it's business as usual potentially what do we do next send a request for proposal or that they may not need to do a proposal because it's not too complex it's pretty straightforward request for information for the from the sellers uh we like if we already have their information we already have a list of acceptable sellers so that's actually pretty good we're fine with both of those request for quotation if it's pretty straightforward maybe we just need a price so that could be quite good hold a bidders conflict conference to ensure all sellers are on the same page again I think we have that list of acceptable sellers so we're pretty good there for our purposes I think it's straightforward enough that we can just get a quote for a price let's go with answer C okay excellent work the bid documents are used to request proposals from prospective sellers the best answer here is request for quote as we have the requirements ready request for proposal is used when the item is complex request for information is when more information is needed better conference is used to ensure all sellers have enough information page 192 bid documents in the per month guide okay we're really getting through this and we've only got two questions to go how did you go with that one we're certainly into this procurement and vendors part of the pmbok guide that's for sure so lots of really good information we're getting here okay last two let's do this your project is new and the team have just come on board there have been multiple disagreements and the work is slow as they try to understand where they fit in the project and the team what will you do next okay and this is one of those you know team engagement things you know I think we've been through this a few times um so where they fit with the project and the team project Charter kicks off the project definition of ready shows what an item needs to have on it before it can be worked on by the next person or start start of work it's when it's ready project management plan is our whole project management plan for all of our schedule scope cost but it doesn't show people where they fit into the project the team charter shows us our team Vision our mission our roles and responsibilities and you know ways to manage conflict and any other ways of working for our team I think that's going to be our best answer let's go with answer d excellent work the project team charter records the team values agreements and operating guidelines it establishes clear expectations regarding acceptable behavior by the project team members page 192 project team charter and you did it you've made it to the last question let's do this hopefully it's not too hard because you deserve a nice easy one after all of this work let's see what we have you've created a high level view of the features your project will deliver and prioritize them prioritized product backlog as we know the development team is ready to start work but they don't know where to start as the information is too high level these features are two high level we need to break them down what we do next okay ask the team to begin with the highest priority item first well we need to get more information maybe decompose them break them down a little bit help the team break the features down that sounds promising into user stories to place in a Sprint so this one now we've broken it down into uh you know similar to work packages items that a person can work on and we take this much and that goes into the next Sprint because that's how much we can deliver I think that's probably pretty good hold a retrospective with the team to understand What's blocking them that will happen after the Sprint after we've started re-prioritize the features into an order that makes sense for the developers it's too high level so that's not going to solve our problem we definitely need to break it down let's go with answer B okay wonderful a user story is a brief description of an outcome for a specific user it has enough information at a level which team members can work on that item page 192 other artifacts use a story and 192 must be close to the end of the pinball guide because we have reached the end of this little question set and unless I add any more you've done an amazing job 150 questions is a huge achievement not only that but I truly believe with this effort and dedication that you definitely can pass the PMP exam I truly do believe in you and I know that when you do it it will help your career and your life so much it's a truly wonderful thing to have and I know you can do it I hope to see you in the next couple of videos and bye for now foreign [Music]