5.5 Validate Scope | PMBOK Video Course

[Music] hi everyone welcome back to these processes in the project management body of knowledge this one in particular is validating the scope and where does

validating the scope fit in the overall process group and knowledge area mapping well we've initiated our project we've planned our project and we've gone through all those planning activities

and put them into the project management plan we've executed on those project on the project and the deliverables and we've created some of those deliverables and now it's time to validate that they

are fit for purpose and they're exactly what the customer wanted in the first place so validating the scope is the process of formalizing the acceptance of

those completed deliverables and we do it because it brings objective objectivity to the acceptance process so it increases the probability of the final product service or result being

accepted by validating each of those deliverables as we complete them and you might see claims so be a part of the project management body of knowledge and

that study that you're doing for the PMP exam and claims are come about when there is a disagreement and so they can't just who parties cannot agree so let's say for example the we've

delivered something to our customer and the project management team says well this is what we've delivered and the customer says well no hang on that's not actually what we wanted so you know let's say in this case they can't agree

and so a claim is made against your project and it has to go through the claims management process and if it can't agree there then a third party gets involved and so ultimately this is definitely not a stage that you want to

be in or something that you want as part of your project you want to avoid this where possible and to to avoid it validating each deliverable as it comes through is a great way to just check and

make sure that everything is on track and the way that the customer wanted it in the first place so an overview of validating our scope is the verified deliverables obtained from controlling

the quality so when we've when we've tested all of these things that we've created and now there are they're verified in that way so you know they're fit for purpose now we can take them

back to our project sponsor or our stakeholders and say here it meets the criteria do you accept the requirements documentation and the scope

baseline are the basis for performing that validation so we check that it meets those that initial scope baseline especially and that's what's used for the final acceptance there so there's a

key difference here that you'll see validating scope which we're looking at is that primarily concerned with acceptance of the deliverables which we're seeing and controlling the quality

is more of testing those deliverables in the first place and that happens before we validate them so we're testing were primarily primarily concerned with the correctness of those deliverables so

meeting the quality requirements and quality is a key part of your project management plan and it is a plan all to itself in many cases as well inputs tools and techniques and outputs

you'll see the project management plan is a big input as always we need to know what we we've decided to deliver and what we have delivered over time the project meant of project documents

verified deliverables that we have done through our control quality so that we've tested and any work performance data for our project that we do need as

an input tools and techniques our inspection so they our deliverables may need to be inspected and decision making so maybe we need to vote on whether it's

acceptable or not outputs you'll see are the accepted deliverables themselves work performance information change requests if we need to make a change to

our scope or any other items in our project and project document updates as well and of course validating the scope has an input into many other and many

other processes so monitoring and controlling project work performing integrated change control if we're making change requests and of course closing the project or phase because we

need accepted deliverables before we can actually close off our project all the phase that we're working in let's look at the inputs in more detail we've got the project management plan so we're

going to need the scope management plan the requirements management plan and the scope baseline or these will first will describe how we had gathered the all the the

requirements and the scope and then the requirements management how also known as the business analysis plan which we saw earlier with the rise of the

business and analyst role so this is how we are how we gathered the requirements as well and then the scope baseline includes the the scope statement the

work breakdown structure and the work breakdown structure dictionary which we which we saw which is more detail for each of the activities or each of the

smaller work packages that were assigning to our teams to deliver project documents that we might have an input as other quality reports so when

we've done the testing you know if we've got those tests results let's include those and show those to the people who are signing off on these deliverables lessons learned requirements

documentation what we wanted to to have in the first place and the requirements traceability matrix in other words these are our requirements that we matched to the project scope that we have turned

into our work breakdown structure deliverables and each of these deliverables is now being its verified and so that's you know it's a great tool that we can use is the requirements

traceability matrix to show that journey and show how everything matches up to what we want to be delivering for our customer verified deliverables themselves as an input there are the

project deliverables that are completed and checked for correctness so this is our quality process also we might call it testing for our project or for the

deliverables and we do that through the control quality process where we're testing those deliverables work performance data can include the degree of compliance with requirements the

number of defects that we might have the severity of defects that we might have and the number of validation cycles performed in a period of time so how many times have we tested do we test it

every time one or in one big bang at the end and again that might come down to whether we're using a waterfall or an agile approach which is our project lifecycle as you can see all of these things come

together and we're using all of them in some form or another tools and techniques we might use inspection on the deliverables so this includes activities such as measuring examining

and validating to determine whether the work and deliverables meet those requirements and the product acceptance criteria so that acceptance criteria is

often in our work breakdown structure dictionary with the more information and you doesn't meet the definition of done for that particular item inspections can

be called reviews product reviews or walkthroughs and again more seen in an agile sense you might have you might have walkthroughs or reviews or demonstrations at the end of an

iteration when you are delivering a feature for example in some application areas these different terms have specific or unique meanings so it's important to know the enterprise

environmental factors for the organization that you're working in how you know maybe they say something but it means something else so they might call

you call something a walk through but it's actually you know it's not really a sign-off it's just your pitch just a showcase or something similar what are the ef-s in the organization that you're

working for decision-making you'll need and that includes voting autocratic decision making and multi-criteria decision analysis which we've seen a lot

of but voting you'll remember you've got the majority you've got the unit unanimity and you've got the plurality which is a hundred percent more than 50

percent or just the largest block when we're voting and you will see that on the PMP exam autocratic decision making where just one person is making all of the decisions and multi-criteria

decision analysis where we've got our matrix of the different criteria and the different options and which ones meet those different options that's how we

make our decision they're the accepted deliverables themselves are an output for our validate scope process so now that we've gone through this whole process someone has said yes they are fit for purpose

and they are our accepted deliverables deliverables that meet the acceptance criteria our formally signed off and approved by the customer all the sponsor

the the people that we're delivering the project to in the first place and the sponsor is usually had is providing the resources and often the money to perform

this project formal documentation received from the customer or sponsor acknowledging formal stakeholder acceptance of the project's deliverables is forwarded to the close project or

phase process in other words we need these accepted deliverables to be verified so that we can close off our project or this particular phase now of

course we might see work performance information as an output where we have information about the project progress such as which deliverables have been accepted and which have not been accepted and the reasons why this

information is documented and communicated to all of the stakeholders that need to know so that they can see you know how we're tracking with our deliverables what has been accepted what

hasn't you know so that they understand that progress within the project as well as a result of all this we might have change requests if deliverable has not

been accepted for example then maybe we need to make a change but if it's a baselined item or a baseline item of scope that has been locked in at a

certain period of time in order to change it we need a change request so completed deliverables that have been not formally accepted are documented along with the reasons for non

acceptance of those deliverables those to the rules might require a change request for defect repair in other words if it's a defect then yes we might need a change the change requests are

processed for review and disposition through the perform integrated change control process which is 4.6 in our project management body of knowledge

usually it'll be a change request raised and goes through either the customer or the project sponsor or the change Control Board if your project has a

change Control Board either way it will usually need to be what are approved by the Kabaddi project sponsor and we might see project document updates where we're updating the requirements documentation if needed

requirements traceability matrix if needed for example any scope changes or scope acceptance or you know deliverables acceptance can we sign off some of those and any lessons that we

have learned along the way and that is all the detail for validating the scope within your project

[Music]