Hello, everyone so now let's discuss the last process of scope management knowledge area,
which is controlled scope.
So just, like any other knowledge area, just like time management, just like schedule management,
cost management, quality management, resource management, whatever you talked about, we
will always have a control process.
So when we were in the similar to plan like we'll have planned scope management, plan
schedule management, plan cost management.
Similarly we also have a control process like control cost, control schedule, control scope.
So this is I call it as a common process because what you do is basically you are trying to
manage the changes to the scope and if there is a change, then you are making sure that
you are following the proper change control procedures.
So let's see what does this involve.
The process that ensures proper handling of scope related change requests, so since I
am doing control scope, I am referring more towards the scope related changes and what
impact does this scope related change has on the other two legs of the triple constraint
triangle, which is time and the cost, so it is a monitoring control process which prevents
scope change requests from overwhelming the project and it prevents the unnecessary change
request.
So customer might sometimes come up with some unnecessary change request which are no longer
required or which are not that important or pertinent.
It is your job as a project manager to make sure that they stick to the scope and if they
are asking for more features then you have to follow the change control process.
It is like you have to do it, simply.
So let's see change control, All change request would be processed through the perform integrated
change control process, So again this is a common statement which I would probably use
in all the control, like when I do the control cost, I would say the same thing.
All change requests must be processed through the perform integrated change control process,
this is like must.
Importance, It is important to understand the underlining cause of the change request.
Yes, what was the reason of that change request?
Was it something the team missed or was it something that customer was not able to identify
or was it like the stakeholder was even missed, and because of which the requirement did not
got captured, and now you have to do that requirement.
So that's also a part of scope as well.
Then we have the variance, control scope should be invoked whenever there is a difference
between the work results and the documented scope.
So basically what you do is you do a comparison of planned versus actual.
So what was really planned and what you actually did that's control scope for you.
Let us see some of the ITTO’s of this process, so on the first we have the inputs, then we
have the tools and finally we have the outputs.
On the input side, we have the project management plan, and after that we have the project documents,
then we have work performance data and OPA tools we have the data analysis and outputs
we'll have the plan updates and the document updates.
Since work performance data was the input, so you will definitely have the performance
information of course change requests, you try to prevent them but it is not necessary
that you would be successful in preventing them.
So you get a lot of change requests as well as an output.
Okay, so now let us discuss these inputs tools techniques and output in much more detail.
Again, I repeat ask these questions to yourself; why you need these inputs, why you need these
tools, why I need this outputs or why this output was generated.
When you start asking these questions to yourself, I'm pretty sure you would be confident to
do the right thing and your concepts would be improved and that's where I come in, because
I'm trying to build your concepts.
So let's see, first we have the project management plan, since we are controlling the scope,
we definitely need the scope management plan and the requirement management plan and if
there is a change request, how to work towards it, you need the change and the configuration
management plan as well.
Of course, it's all about scope, so you need the scope baseline and the performance measurement
baseline.
We will be discussing the performance measurement baseline sometime later but again you need
all of those things to make sure that you are properly able to manage the changes to
the scope.
On the project document side we have the lessons learned register, so whatever mistakes which
have been done by your previous projects or whatever good things you have gained from
this project or bad things you have done in this project, you want to have a track of
all those things, you want to make sure that they are helping you in tracking the scope,
helping you to control the scope.
So you need that lessons learned register as an input and of course you need the requirements
documentation and the traceability matrix because scope is all about the requirements,
Right?
That if you have to control it, you have to control the requirements.
Then you have the work performance data, the raw observation.
Okay guys, keep one thing in mind that work performance data will always be an input to
these control processes.
What do I mean by that, if you're talking about control cost, control schedule, control
quality, control risk, control procurements, all of those would always have work performance
data as an input which is your raw observation and if work performance data is an input,
your output will always be information.
Because data is converted into information and if information is an input to any of the
process, some like any of them out of the 49 processes that will get converted into
work performance reports.
So another thing for all these control processes, you will always have change requests as an
output.
You are trying to prevent change requests from happening if they are unnecessary but
you end up getting the legitimate change request and sometimes the not so legitimate change
request, but you have to do it.
Let's see, some of the tools and techniques.
So first we have the data analysis, which is the variance analysis and the trend analysis.
So if you remember variance analysis; this was something which we discussed in the integration
management knowledge area.
If it was all about the planned versus actual; what you planned and what you actually did.
If you remember the example which I gave you, that you were planning to watch all the integration
videos but you were only able to watch the top three, the first three, so that was a
variance.
Right?
So that's your variance analysis.
Then if you remember, the trend analysis, the example I gave you was about the stock
market example, the e-commerce companies where the stock actually rose at them and at the
holiday season, at around the Thanksgiving, Christmas.
You will see the people are heavily spending and their stocks would rise.
Then on the output side, we have the plan updates and the document updates, the important
ones since data was the input, you will get information as an output and of course as
I told you will have change requests as an output.
Let's see what are the things which are part of project management plan.
Anything related to scope, scope baseline, scheduled baseline, scope management plan,
performance measurement baseline.
So all of the you know the important ones are actually an input here, most importantly
all the baselines are getting updated here because we're trying to control, there might
be a change request, you might have to go back and update these baseline.
Then since data was the input you got information as an output then on the document side you
will get the lessons learned register.
Sometimes in order to control the scope you might get to know that, oh this was a good
thing, which suited, so you have to go and update the lessons learned register.
Similarly, when sometimes we are trying to control the scope, you might end up with new
requirements being added to your project and since new requirements are being added, you
have to go back and update the requirements documentation and your traceability matrix.
Finally, let us do a quick revision of this process of whatever things we did.
Focus on the tool variance analysis and trend analysis, remember variance analysis was planned
versus actual and trend analysis was the stock market example, which I gave.
Know that control scope is linked to the overall perform Integrates change process, so all
of these control processes are actually linked to these perform integrated change control
processes.
So if there is an issue it has to follow a proper change control process, know that this
process is important to prevent unnecessary change requests, so you don't like change
requests.
Remember you do not like unnecessary change requests and if you try to control the processes
control the scope in a good way as per which is defined in your scope management that you
would be successful in doing that.
Know that both products as well as the project scope are being monitored, so it is not just
specific to your product scope, the features, it is also about the project scope, which
is being monitored here.
So this marks the completion of scope management knowledge area, we discussed lot of good concepts
in this knowledge area, a lot of good questions specifically around the collect requirements,
WBS, validate scope, you will get a lot of good questions from them, but this video is
of no use until and unless you practice some questions, practice some real scenario based
questions.
Just go ahead and go to our website www.eduhubspot.com, if you are on the move you can download our
app and start doing the questions.
Of course reach out to us share your questions, share your results.
If you have any questions send us an email and I will try my best to make sure that I
replied to you within 24 hours thank you and all the best talk to you in the next knowledge
area which is our time management.
Thank you.