Hi everyone. So many people have commented how my videos help them get into the mindset for the PMP or the ACP exams and some people have asked specifically if I can create a video on the mindset that you need to have going into the PMP exam. So that's exactly what we're going to do today, a really quick overview on the mindset.
Now this idea was originally pioneered by Andrew Ramdale and it's basically the high-level overview of how do you need to think as you're going into the PMP exam in order to answer the questions correctly most of the time. So basically it's just good practice in project management in general and it's also going through the project management process in the right steps. Pretty much that's what it comes down to.
So we're going to go through the general exam mindset, predictive exam mindset and agile exam mindset. Let's get straight into it. The general exam mindset. First one, when answering exam questions always assume that all the information you need to answer the question is included in the question.
There will often be two or more possible answers and you've heard me say this over and over again. Sometimes three out of the four answers will seem to be correct. Prioritize the answers from best to worst and then choose the absolute best one based on all of the information that is provided in the question.
Avoid extreme answers though, such as closing a project if you can help it or escalating to someone else. We're the project manager. We want to ideally solve this using our project management skills ourselves. Try to avoid extreme actions such as we must do this. or there's only this particular way.
Aim for answers that have inclusiveness and collaboration. We want to collaborate with people as the project manager, and always be direct and collaborative in your approach. Don't skirt around the issue, go straight to the source, find the root cause of the problem.
If there's conflict between people, be direct and be collaborative in your answers. As project managers, we don't have to have all the answers, but we have to be able to get the answers. Consult the project team members on solutions, on estimating the work, and when something should be done. They're the ones doing the work, so we need to get that expertise, that expert judgment from our team. Always consult.
The project customer, however, is the best person to judge the outcome, the overall deliverable that we're delivering to them, because they're the ones receiving it. So whoever's receiving the value, make sure they're checking those deliverables at the end. Now if there's any conflict in the project and there will be lots and lots of questions with conflict, always make sure that the outcome benefits the project, not just the individuals. So don't favor the individuals, make sure the outcome that we go for favors the project value that we're delivering. Always use inclusive tools, collaborative tools, and try and keep it simple if you can.
Remember estimating techniques, there's the two main sorts. Bottom up, where we're adding everything together. and then getting an overall budget or an overall schedule duration.
That's going to take more time but it's going to be more accurate. Top down is where we just give an idea for the big chunks, the big features or deliverables. That's going to be less accurate but it's also going to be less time consuming so it's going to be faster.
Most of the time we're probably going to go with bottom up estimating to get the most accurate view. And lastly for general exam tips, we are going to need to figure out what framework we're in. Are we in a waterfall framework or an agile framework or hybrid somewhere in between?
The majority of these days will probably be somewhere in between with some parts of waterfall and some parts of agile. But what we're looking for here are the key words in the question if we can. Agile are going to have iterations or sprints, a product owner, a scrum master, retrospectives and sprint planning. and user stories. Whereas a predictive or a waterfall approach is going to have change requests, project plans that we need to stick to, issue logs and risk registers and those sorts of things that we need to abide by during our project.
All right, those are the general exam mindset ideas. Next one we've got is the predictive exam mindset. And the first one is always create a plan. We're creating a plan and we're sticking to the plan if we can.
Now, if we can't stick to the plan, we need to make a change request. Know your change process. So we outline the change process in the change management plan. We can decide this, but generally here are the steps. Any stakeholder can raise a change, note it in the change log, assess the impact of the change to our schedule or our cost, then take all of that information to the approvers, which is usually the change control board.
But again, that's outlined. We can outline this in the change management plan. So often we can decide or collaborate with people to decide on this. Take it to the change control board. They give us the outcome.
Do they approve it or reject it or defer it? And then we advise our stakeholders of the outcome and note that outcome in the change log again. So it comes full circle.
Just remember that change process for your predictive projects. Remember that a risk is in the future and an issue has all... already happened.
Use your risk register for risks and an issue log for your issues. Risks can be positive, so opportunities, or negative, which are threats. Identify as much risk as you can as early as you can because the cost of risk increases as we get closer to our customer, just like bad quality increases as we get closer to our customer.
Always consult your team on solutions. There's that expert judgment again. Make sure we're going to them. for those ideas and information.
And know the closing process. Remember you can close a project early but you still need to go through the project closing steps. Generally it is going through these things.
Confirming the formal acceptance of the product with our project sponsor or the project customer. Finalizing any open claims with procurement. Ensuring the transition of that product to operations and then measuring those product benefits.
Finalize the lessons learned with our team. Then as our project winds up we can formally release resources and remember we want to do that in writing and make sure that they're formally released. Finalize and close any accounts so that people can't use the accounting for our project as it's closed. The final report is the main output of closing our project and that just provides a summary of the project performance whether we met the objectives that we intended to meet and then we can archive all that project information for future use and that goes into our organizational process assets within the organization. Lessons learned.
We can update those any time throughout the project, and we should. Also, make sure you know your stakeholders'communication preferences. We have to ask what they need, what communication they need, how much, how often, when they need it, in what form. Don't assume. Make sure we always ask.
And we can do a communication styles assessment, usually. Engage our stakeholders all the time, early, often. Review and update our stakeholders throughout that project.
Alright, wow, that was quick. Exam mindset predictive. Exam mindset agile is our last one.
Very, very common. Lots of agile on the exam these days. So let's see what we've got. And the main thing is also one of my favorite things.
Be a servant leader. And what's a servant leader? We remove blockers for the team so there's nothing stopping them from doing the work.
They can get right into that zone. We shield them from politics and diversions outside of the team. and we help them grow in agile and in their chosen field. We are leading through service to the team.
We find out what motivates the team, help them improve and grow. Everyone might be different. Some people might like rewards or other people might like a day off here or there. You just don't know. Let's ask again.
Coach the product owner only if they need it, but they need to prioritize the product backlog, not the scrum master usually or not the project manager. So ideally. product owner, they're the business owner, they represent the customer, they do need to prioritize the features. And if they don't know how to do that, then we can help them grow. We can coach them as that project coach role.
Communicate that vision often to the team. And how do we do that? In a project charter.
Let's outline that project charter with the team. What's our vision? What's our way of work? What are our communication preferences? Who are our stakeholders?
Basically, what is our way of working with the team? Always co-locate. the team if you can. Why do we do that? So that we can talk to someone, so we can pick up information by osmosis.
It's just seeping into our brain because people are having conversations all around us much faster than working remotely because we're getting that extra information. Always face-to-face communication if you can because the effectiveness is high with face-to-face communication. We can pick up all those extra signals like uh body language and tonality that you cannot get just in an email. Very important.
That's why they recommend it. And always allow a lot of wall space for our information radiator. That's visual management. We're managing the team by having visual management on the walls. How is it tracking?
What's in our current sprint? What's our burndown chart look like? And so we get to see that.
What are the current products or features that we're working on in the product backlog? All of that can be on the wall so anyone can see it. It's visual management.
Ensure a safe space for disagreements. Can we disagree and still be friends? And the answer is yes, we need to do that.
It's psychological safety. Ensure that everyone in the team has a voice. And our last couple here, use that Kanban board, that beautiful Kanban board, to show the work, see constraints, and limit the work in progress. What that means is if we've got analysis, development, test, sign off and whatever else release and you can change these in the real world to suit your particular project but let's say we've got a whole bunch piling up in tests of user stories we can say hey what's the constraint there let's problem-solve this with the team maybe there's something blocking us there's an environment a test environment that's not ready and so we need to fix that all of a sudden they can that constraint is removed and then we can start the test again secretly another constraint will pop up somewhere else but that's just the way that kanban and the theory of constraints works it's really cool very cool stuff review the way of working and any issues in a retrospective that's right we say what's working what's not working if something is troubling the team we can hold a retrospective usually at the end of a sprint we'll hold a retrospective always improving always improving last one review any product items completed in the sprint review or a demonstration. We're demonstrating the actual item.
We're not just doing a showcase or a report. So we're physically seeing what's actually being created, the real things, which is why Agile is so, so wonderful. And I hope this has been wonderful for you because I've personally had an absolutely fantastic time.
And I also truly believe that you can pass the PMP exam if this is what you're going through and learning every single day. It does take effort and it does take a little self-belief, but I also believe that you can do it and I think you're doing the right thing. Keep going and I'll see you in the next video. Bye for now.