Hey guys, so now let's discuss the third process of scope management knowledge area which is
define scope.
So, first we started with the planning of scope management where we were discussing
about how we will define the scope, then we moved into the collect requirements phase
where we work with the stakeholders to gather the requirements from the stakeholders and
now this is the third piece, which is our defining of scope.
So, whatever requirements we defined in the scope management in the collect requirements
process, now it is the time to give a detailed description of that.
Your output would be the project scope statement, which will contain that detailed information.
So let us see, it is a planning process to create a detailed understanding of the project
scope; the process group, which we are doing.
This is part of the planning process group so while collect requirements has already
been performed, this process refines the team understanding of the project work.
So, your team might have some confusion about those requirements and they want to review
and they want to see some more details about it, this is the document project scope statement
which will help them in this particular scenario.
This understanding is documented in the project scope statement, which is the one of the outputs
of this process.
Let's see the top three points.
The consumption: it's about improving your understanding of project scope and documenting
that understanding.
So, first as a team member you want to implement a particular requirement and you want to know
what all things are part of it.
This is where you would go back, see that document: the scope statement and talk more
about it and understand more about it.
Importance: the project scope statement contains the detailed description of scope, very important!
Like, you know this document would be used by lot of other processes, because they want
to really know what all things this document entails and what all things this document
will help them to take an informed decision.
Management: This may be the visited often throughout the project, so again as more and
more requirements would be identified you need to update this document.
Why?, because you would have to explain those requirements in much more detail.
You don't explain those requirements in details in the requirements document but you do that
in this scope statement which is an output of this process.
Okay, so now let's see the ITTO(Input Tools & Techniques Outputs) of this, so on the input
side we have the project charter, then we have the project management plan.
We have some of the project documents and then we have the EEF (Enterprise Environmental
Factors) and OPA (Organizational Process Assets).
On the tools, we have expert’s judgment, decision-making, inter-personal and team skills,
product analysis and the data analysis.
Output, we will have two main ones, which is the project scope statement and the document
updates.
So, now let's review each of these inputs, tools and techniques and of course the outputs
in much more detail.
So, first of all, always whenever I am explaining you these ITTO’s, you need to remember one
thing ; you need to ask these questions to yourself, that why this document or why this
particular plan is an input to this process, why it is, or why it is the tool , why it
is the output.
You have to ask those questions to yourself.
So, first we have the project management plan, so project management plan and specifically
the scope management plan, which we will talk about that how you will define the scope.
So, you cannot just go ahead and define the scope until and unless you know that, how
you will do that, and scope management plan would help you to understand that.
Then project charter would also be an another input, an important input, because if you
remember, project charter has the high level scope defined in the project charter, and
this is where you would explain that high level scope defined in the project charter
in much more detail.
If you do not have your ITTO sheet, I would really appreciate, stop this video right now,
go to the web site www.eduhubspot.com and download the free ITTO sheet.
When you download it, go to the third tab, the differentiation tab to see the difference
between the project charter and the scope statement.
What all different things are part of both of these documents, very important.
And if you already have that then see the difference between those two documents, then
for the project documents we have the assumption log, requirements documentation and the risk
register.
So assumption log: the things which we assumed to be true, like the same example of my friend
who is helping me to buy this car.
I'm assuming that he will be there to explain me what all different features he was talking
about, he would have to describe that in more detail.
I just had the high level feature that I need a car which is safe and secure, that's it.
But he would be the one who would tell me the difference between what all different
safety measures are and he might even actually rank them so that's an assumption log.
Now you know, that because I'm assuming that he would be the one who would be helping,
he would be the one who would be giving his expert judgement to it.
Then requirements documentation: what are you describing what are you describing in
detail, you are actually describing the requirements defined in the requirement documentation in
much more detail.
So of course we need the requirement documentation and risk register: what if the car I am planning
to buy, planning to customize, is not worth it, right?
It's too expensive and it's not what I was really looking for, that's a risk register.
Then we have the common inputs the EEF and OPA, remember the EEF the enterprise environmental
factors, something which is not in control with the project team, like your organization
culture that's a biggest example.
OPA same thing, your processes your procedures your policies your lessons learned all those
are actually part of your OPA.
So these are the common ones you can think you can keep.
Next we have the tools and techniques.
So in tools and techniques of course, we have my friend who is helping me to buy that car,
that's expert judgment.
As far as decision-making is concerned, I have multi-criteria decision analysis, something
which I would say the criteria I have defined to buy that car.
For me luxury was important, for my family probably safety was, security was more important
than for others like, for my family speed is more important, right?
So again, these were the different multiple criterias I used in order to buy the car.
Okay then interpersonal and team skills, facilitation: one of the tools which we already discussed
in the previous process collect requirements process, we also briefly discussed this in
the integration management knowledge area.
If you remember facilitation technique more like a facilitated workshop where we have
a facilitator, trying to work with these stakeholders to define the scope in more detail.
The three examples for the JAD session; joint application development.
Then we have the QFD; quality function deployment and then the voice of customer, if you remember
that example.
And then the third was the user stories, so user stories so all those were part of the
facilitation workshop where multiple stakeholders come under the one roof and try to describe
the scope.
Then we have the product analysis, in this technique the team asked questions about the
products and services.
It helps to define the deliverable scope in much more detail, example includes the product
breakdown, requirement analysis, system analysis, value analysis and the system / value engineering.
So again product analysis is important, I do that all the time for my simulator.
I talk to the students and I ask them that what are the things which are good for the
services, which are good, which you don't find it, what are the things which can help
you to study more or study better.
All those things are discussed with the students on our social networking groups; the Facebook
and LinkedIn.
So I heavily do that, I analyze the product and this helps me to define the scope of my
product then on the data analysis side, we have the alternative analysis.
Anything we do, we have alternative options, like if you remember the example I gave you
from that Varun needs to travel from Washington DC to New York.
So what are the different alternatives to do that, right?
I can take a car, I can take a bus, I can drive myself I can fly I fly.
I can walk.
All these alternatives have some pros and cons, like flying would be the most expensive
one but it's the fastest option for me, if I want to do that I'd probably do that.
I want to have comfort, a pit stop anywhere I want, I would probably take my own car but
if my goal is to take the cheapest option I would probably take the bus and if let's
say I'm looking for more, I'm preparing for a marathon or I'm preparing for something
crazy I will probably walk as well.
No, I'm not saying I will do that but I'm just giving you a different alternative options
for that.
So, everything has their own pros and cons and you would probably select that based upon
your own choice.
Okay now let's quickly talk about the outputs, so we have two outputs over here, first we
have the project scope statement and something which will describe in much more details in
the requirements, then as far as the document updates is concerned assumption log, which
was there in the input as well.
Requirements documentation, the traceability matrix, the stakeholder register.
So like for example when you're describing a particular requirement think from this perspective,
that you came to know that you might need a stakeholder A from Team B which you have
never involved that stakeholder in your project.
So what will you do, you reach out to that person and now that person will also become
a stakeholder on your project and if that person becomes a stakeholder on your project,
you probably would have to go and update your stakeholder Register also.
So, that's why you see stakeholder register as an output to this process.
Okay since the beginning we have been talking about one word, I would say the most important
word was the Project Scope Statement but what is this scope statement?
-It's the documented project requirement that sets focus, the expectations of the project
stakeholders but in much more detail, so the key word is the detailed description of the
project's scope of the requirements as well.
So first of all, it’s progressively elaborated.
If you remember, the progressive elaboration concept we did in the introduction section,
where not all the requirements are known upfront but you constantly update them as you know
more and more information about them.
It will include both, the project as well as product scope.
Remember, the diagram of product and project scope where the product scope was in the middle
the features of that product and project scope was the outermost umbrella.
Like how much time you will take to implement this feature, how much cost it will take to
implement those.
So all those things were the project's scope.
But when you are dealing with the specifications of that product, that's product scope.
It will also include the assumptions and constraints, so assumptions and constraint, this is an
important topic, right.
You will have assumptions and constraints as well, it will also tell about the in-scope
and as well as the out of scope item.
So what are the project exclusions?
You will talk about the acceptance criteria, how you will accept that, how the customer
will accept that scope, so acceptance criteria would also be laid out in this.
Then project deliverables: the deliverables are mentioned over here and of course you
know the detailed description of the project.
All of these are actually the content of the project scope statement, so one of the questions
which you may encounter in the real exam could be that, which of the following is part of
project scope statement or which of the following is not a part of project scope statement?
-So you need to memorize when you when you will go and read the PMBOK, make sure that
these fours are definitely in, and sometimes it might have some more information as well.
Okay let's do a quick revision and then we will go over the next process in the next
video.
So on the focus side we will focus our efforts on understanding the primary output which
is the scope statement.
So scope statement will be your primary output, an important one, which will have a detailed
description of the scope.
Remember detailed description.
I am putting a lot of stress on the detailed description because that's one of the most
important keyword for this process.
I know that the project scope statement is a narrative and detailed description of the
requirements needed to successfully complete the project, so your team might come to you
and ask you about what does this requirement mean?
-You probably can tell them to refer to the scope statement, because scope statement is
the one which will have the detailed description of that requirement what the team member is
asking.
Be aware that this process shares a common thread of analyzing the scope in more detail,
yes you analyze the scope in more detail then only you can have a detailed description of
that scope.
The key benefit of this process is that it describes the product service or result boundaries
and the acceptance criteria.
The exclusions, the deliverables, the description, the boundaries are referring to your exclusion
criteria.
So this marks the completion of the scope statement the define scope next video will
be talking about the create WBS process thank you!