Hey guys, welcome to EduHubSpot PMP Mindset video series. In this particular video, I am going to
talk about change request, how change request is managed on predictive projects and how change
request is managed in agile projects. Before I go into detail, the first thing you really need to
know is how to download or how to get this mindset tool, which I'm going to show it to you right now,
but I will be explaining that tool, how to get that for free of cost at the later part
of the video. But let's first talk about the concept first, which is much more important.
So once you have this tool, make sure you enable the macros,
how to enable the macros. You can go from how to section, there is a video on the how to section,
how to enable the macros. You can look at from here, but you know what, let us go on the concept.
So first is change request. Let us click on change request. So on a traditional project,
a plan should always be followed and no changes should be made without an approved change
request. Changes in scope should be assessed in terms of how they will affect all other parts
of the project, which includes the schedule, cost, quality, resources, communication, risk,
procurement, and stakeholder engagement. So basically on the traditional projects,
you need to follow a proper change control process. If a change is requested,
the first step you will probably do is you will go to the CCB Change Control Board. You will do
the impact analysis of that particular change as respect to the triple constraint triangle,
which is scope, cost, and schedule. And you would also take into consideration other factors like
what is the impact of this change on quality, on communication. Once everything is done,
either you approve it or you reject the change and communicate the stakeholders accordingly.
You update the change log. So it's a long and a tedious process in predictive
side on how a change request is managed. On the agile side, it is totally different. Agile
embraces change. So let us read it. Agile methods aim to adapt to change and deliver the desired
outcomes as quickly as possible. Change management is often appreciated due to the iterative nature
of agile. Exactly! So in agile changes are very common and in fact, this entire methodology was
developed to make sure that the team can work on changes as frequently as possible.
In traditional, the change was very expensive and in agile,
it's not that expensive. So if there is a change in agile project, you will discuss
this with the product owner, and the product owner will reprioritize the user stories.
And once the product owner reprioritize the user stories, they will determine whether this new
change request should be implemented in the next sprint or it could be done in the later sprints
also. So the product owner takes that decision. So see how a change request is handled in Agile,
which is much more simpler as compared to traditional projects where changes are
not that appreciated if you ask me. Let us do a quick question on that.
Nick is a project manager who is working on an integration project. The customer is confused
about one of the project requirements and they have submitted a change request. What does this
mean for Nick? Now, clearly, if you read the question, I could feel that this question is
on the predictive side because there is no agile keywords are used like product backlog or user
stories or scrum master or sprint review, things like that. They are talking about requirements.
In agile side, it's not really requirements, it's more user stories, which is at a much
more detailed level if you ask me. And they have submitted a change request in this case,
it looks like it's a predictive project. So let us see A: The project charter is finished,
but the work cannot be started because Nick needs to update the scope baseline. The scope baseline
would only be updated once the change is approved, but the question states that they have submitted
a change request. So it does not look like that change has been approved yet. So you don't really
need to update the scope baseline until the change is approved. So option A does not look correct,
double click on this and it will show you that it is a wrong answer.
Let us go on option B; Nick cannot implement the change until he is approved.
Exactly, that is what I was actually talking about. So B looks like the correct answer,
but before I double click on this, let me read option C and D. Nick can implement the change
after implementation. Nick has to make sure that he is showing a demo to the customer. That
is also incorrect. It says Nick can implement the change. How can Nick implement the change
until and unless the change is approved. Question doesn't state that the change is approved. So C is
also out. You can see that. Double click on that and you will see it is a wrong answer.
Let's see. Option D. This shows there is a defect in
the deliverable that must be repaired immediately.
So, how a defect is created. A defect is created when the product has been launched to the market.
I don't think we can see, we can figure it out that the product is already launched. So there is
no definition of defect or there is no statements which are depicting that there is a defect. So
D also looks like an incorrect choice. So the correct choice is option B, which is the correct
answer. In order to see the correct answer, you can click here to see the answer explanation. You
can see the answer, the textual description. If you want to watch the video where I'm explaining
why this option is better, I just did it in this video also, but you have a video explanation,
you can click on that and it'll take you to a video where you can watch this video again.
Then I have another question, which is question number two. I am not going to do this question
for you. I want you guys to practice it and how you can practice this is by downloading this tool,
from the EduHubSpot website. You can get it free of cost. So first step is go back to the homepage.
How to get this tool for free of cost. Just go on my website, www.eduhubspot.com. When you
go on my website, you will see two options over there, either bottom right hand side,
you will see an option of chat, like click on that chat option, talk to one of my team member,
or you request a demo, book a demo and you will directly, based on the timeline,
you can connect directly with one of my team member and they're going to set up a 30-minute
zoom call with you. Now, what is the purpose of this zoom call? They are going to explain you how
to use this tool. They are going to understand your background, what you are doing, how you are
doing in your studies, and they will give you some pointers. After the end of that zoom call,
they are going to email this mindset tool for you free of cost. If you are my student or if
you are not my student, you will irrespective of that, you will get this tool free of cost.
Only thing I ask from you is go on my website and talk to them. Give us those 30 minutes,
because ultimately I want to make sure that I am impacting your life, not just by
helping you pass the PMP exam, but you know touching your hearts. That is my end goal.
And please don't forget to like and subscribe to my YouTube channel because I am going to explain
this entire 15 concepts, everything. Like before the real PMP, you have to watch these 15 sections,
wear your PMI hat in order to pass this exam successfully and don't forget to send
me an email when you pass this exam because these emails helped me a lot. It motivates
me a lot to make something as beautiful, like something like PMI mindset tool, which I did.
Hey guys, I hope you liked my video on the change request, basically where I was talking about the
predictive side and the agile projects. But my next video would be about scope in the mindset
series. So click on that video to watch that on one side. On the other side, watch
my favorite video. Once again, go to my website, Edhubspot.com to download the mindset tool. Now.