Hello everyone, so now let's discuss the first process of monitoring and controlling process
group and I would say the fifth process of scope management, which is validate school;
an important process.
We have discussed lot of good processes in this knowledge area.
We started with the plan scope management, then we discussed the collect requirements,
then we went towards the defining of scope, then we created the WBS in the last process
and now we are in the validation of scope process.
So for the validation of scope, what does this mean?
Validate scope.
What are you really doing in validating the scope?
Okay, so first, you as a team member or you as a project manager are not validating the
scope; it’s not your job.
You are not doing the validation in this particular process.
If you have, if your quality team has to do the validation that is something which you
would be doing as a part of control quality process, which is your internal testing and
all those things.
But once your control quality, your testing team has actually told you that this is something
that you have validated.
We are good with the product and we think that the customer’s requirement is done.
Then from there, the output actually flows into this process, which is validate scope.
Where the customer will do the testing.
So now, think of the same example, which we have discussed till now, which was the buying
of car.
This is where the dealer has called me and asked me to come and see whether the requirements
whatever I have mentioned has been met or not.
So what I will do, I will have the requirements document with me, I will go to the dealer,
I will see my customized car, I will go through each and every requirement, whatever I have
drafted , see whether the dealer did it or not.
If there are any questions or any changes that need to be done then of course I will
say that to the dealer and dealer might follow the change control process.
To see or if there are any defects or issues which means that what requirement I asked
and the dealer did not do with them, they would have to go back and do that as well.
So let's see, it’s a process where customer is particularly interested in it.
So of course, I would be interested in seeing my customized new car, Right?
That's what I'm here for, that's why I did this project.
The process group would be the planning monitoring and control monitoring and controlling process
that verifies that the project deliverables; which is the product, service or result, match
the documented scope.
So what I am doing, I’m doing a comparison with the requirements document with the actual
deliverable which the dealer gave it to me.
So it is all about right versus wrong, completeness versus correctness so completeness versa correctness.
It checks for completeness.
So this process will actually check for the completeness.
So once I am reviewing my deliverable, I am fine with it.
I am happy about it.
Then what I will probably do is I will give a sign off on that, right?
So sign off is a significant milestone on your project.
You can say that okay now I'm satisfied and this project is complete.
Of course, you have not transition, you have not given the car to me yet, but still have
given the sign-off that you know I like it, whatever I asked for you have done.
It is not control quality, so control quality was about correctness, when I say correctness;
I am referring to the internal testing, which the team did.
So prior to the dealer showing the car to me, they might have done all of their testing,
they might have done the same thing what I am doing right now.
They would have taken my requirements document and they would have taken the car and probably
like in a checklist kind of manner, they would have done.
Okay Requirement number one-done.
Requirement number two- done.
Requirement number three-done.
So this is what they might have done.
Stakeholders it’s performed by PM sponsor, customer and other key stakeholders.
So it's like a combination, it's like an effort of everyone.
But of course basically the customer is somebody who was majorly doing this process, because
the final sign-off would actually come from him.
It’s important because acceptance represent a significant milestone.
Of course, today is the day, for example for you, for the PMP application, the day your
PMP application gets approved like once you finish this course, once you do the questions,
practice questions, you can actually download the 35 hour PDU certificate.
You will use that 35-hour PDU certificate to your application, your PMP application,
and once you do that, then your application is approved by the PMI.
That is a significant milestone, Right?
So this is this is an important one, it's like another important milestone that today
is the day, my car, my requirements, the dealer actually manufactured created the deliverable
with the requirements I asked for.
Let's review the ITTO’S, the input tools and techniques and the outputs of this process.
So the inputs we have, the project management plan and the project documents.
Of course we will have the verified deliverables, so this is the verified deliverables I was
referring to, which was coming from a control quality process.
Something from when your internal testing team has actually verified each and every
requirement and they have told you that ok this product is ready and this product is
now verified.
You will have work performance data as an input as well.
Tools will have inspection and decision-making, and outputs will have the accepted deliverables,
work performance information because if you see work performance data was an input, so
this data actually got converted into work performance information.
Then you have change request, then you have the document updates.
So let's discuss these inputs in much more detail and see why they are really the inputs.
Ok again remember guys, you need to ask these questions that why this is an end, why this
is a tool, why this is an output, remember the concepts are much more important than
the memorizing of these ITTO’s.
So first, we have the project management plan, so if you need to validate the scope, you
definitely need the scope management plan.
You definitely need the requirement like how you will validate the scope that is actually
part of your scope management plan.
Then you need to require the requirement management plan and the scope baseline.
You need to know what are the requirements, how you were managing those requirements,
how you were working towards, how you were managing the changes about those requirements.
All of those were an important inputs for you.
As far as the documents is concerned, we have the Lessons Learned Register, whatever things
you get from your past projects, whatever lessons you have learned in this present project,
whatever good things happen, whatever bad things happen.
All of those things will actually become part of your lessons learned.
So you want to take that information also as an input.
Then you will have the requirement documentation, because what I am doing, I’m comparing the
requirements documentation with my car, so I am doing the comparison of the requirements
with the car itself.
So I need the documentation.
What was the origin of those requirements that information is actually coming from your
traceability matrix.
So you need to know that as well, requirement traceability matrix.
And then you will have the quality reports , this is something which we would be discussing
in the quality management knowledge area, because I told you that quality it's all about
requirements, meeting your requirements.
So this is a good quality product, only if the car dealer makes sure that all of my requirements
were fulfilled by them.
Then we will have the verified deliverables, this is something which will be an output
of the quality control quality process.
Something which our internal team did, the testing, did the comparison, what me as a
customer is doing this right now.
They would have already done that in the past and then only they would have gone to this
process.
Then we have the work performance data, the raw observations.
The first time I saw my car, either I would say wow this is a beautiful car or oh my god
what did you make.
So, these are some of the raw observations which I did and what performance data is all
about, raw observations.
But remember, if work performance data is the input, your input will always be the work
performance information.
If any time in future work performance information is your input, then work performance reports
will be your output.
Let us discuss the tools and techniques.
So we have only two tools over here, first- we have the inspection and the other we have
the decision-making.
Inspection is something, which we will be discussing in quality management knowledge
area in much more detail, sometimes this is referred to as the reviews and the product
reviews and the walk-throughs.
Inspection, you all know what inspection is right , you are actually going and inspecting
your deliverable, making sure that it is meeting your requirements, making sure that whatever
requirements you mentioned in the requirements documentation, this is meeting that.
Decision-making, sometimes let us say, I went with my entire family to do this Validate
Scope Process.
To go to the dealer and see whether the dealer did a good job or not, at that time let's
say, I said I need a white color car and the dealer came up with off-white or bright white,
but my father probably likes more brighter white.
So again at that point of time, this is more of an issue, Right?
So we will probably do the voting and if you remember, this is something, which we did
in collect requirements process we did the unanimity, majority polarity and the autocratic
rule.
If you remember, all those were part of the voting section.
Then of course, if you remember in decision-making there was also the multi criteria.
So voting would be done to make sure that whether it was white or whether it was off-white.
We need to take a decision, Right.
So let's see the output, so of course after the end of this process, we will get the accepted
deliverables.
Of course, I can reject the deliverables if it's not meeting my requirements, but majorly
it would be accepted deliverables, where me as a customer or as a sponsor you give the
sign of on the deliverables and this is something which I asked for and this is what the dealer
provided me, that's accepted deliverables.
Then if you remember, work performance data was the input so definitely you will have
the work performance information.
Initially I had the raw observation, but now I have something more substantial.
When I sat in the car, when I touched the leather seats that was the time that gave
me more information.
Whether it is really actual good quality leather or it's not a good quality leather, Right?
But prior to that, I was just seeing it like as an okay leather or a good leather or a
bad leather.
Then for the document updates, we will definitely come up with Lessons Learned Register, I might
come up with some lessons learned saying that oh you could have done this in a better way
or you could have done this or this was done pretty nicely.
So that the dealer can make sure that for next customer, he or she does not repeat the
same mistakes or does it even better.
Then of course, your requirement documentation and traceability matrix might get updated,
because I was referring to white but my father was referring to off-white.
So we might have to change the requirement, but he would have to go back to the perform
integrated change control process and see what will be the impact of changing the car
color from white to off-white.
That is a change request.
Okay so let's do a quick revision of whatever things we discussed, so know that the accepted
deliverable is the primary output of validate scope process.
So again accepted deliverables of course, it could be rejected also but accepted deliverables,
the sign-off would come from this process.
Know that the validate scope cannot be performed under some component of the project deliverable
is available for inspection.
So it's a step-by-step process, right?
So if you remember in direct and manage project work, which we did in the execution section
that gave me the deliverables.
Those deliverables actually went to the control quality process, which we will be discussing
in quality management but that actually went to the control quality process, where my internal
team did the testing.
An output of that was verified deliverables like they verified that whatever requirements
I asked for they did that.
From verified deliverables that actually came to this validate scope process, where the
customer did the testing and when customer likes it, customer will give the sign off,
and the output will be accepted deliverable.
Okay then know that the control quality can be performed before, during or after the validate
scope, so again control quality it happens in parallel.
It can be done before and after, I'll tell you why, like for example, let's say you completed
deliverable one, so again deliverable one got completed, it went to the control quality,
it got approved, it went to validate scope.
So now what the customer is doing?
Customer is validating the control, the deliverable one, but at the same time for deliverable
two, your testing team has already started working on it.
So it's most of the things are done in parallel.
Know that, this process brings objectivity to the acceptance process.
Yes it will bring objectivity because this is where you will get the final sign-off from
the customer, that this is what I asked for and this is what you did and I'm happy with
the response from the team.
So this marks the completion of your validate scope process.
Next process is the control scope and we will discuss about how we are managing the changes
to that scope in that.
Thank you.