Project Scope Management - SE Video Lecture - Computer Science Engineering (CSE)

in our session by the stranding project
scope management in our earlier session
we saw that the project management
consists of nine knowledge areas namely
the scope schedule cost quality and you
know HR procurement
risk and communications management the
last area of course being the
integration management the project scope
management pertains to defining what the
project will produce a project generally
results in producing a single product
consisting of many components for
instance if you take a telephone system
it will have hardware software training
implementation and many other small
things so project scope management
involves defining and of course
subsequently controlling what is and
what is not included in the project that
is what products will the project
produce and how those products will be
produced it is obvious in this
particular stage that all stakeholders
must agree with the project's scope now
if we look at the project scope
management process it consists of
different sub processes let's look at
the slide now the first process
we are talking about sub-process that we
are talking about is called project
initiation process but there is a
prelude to this since an organization
never does a project in isolation the
organization has to manage a portfolio
of projects the organization has to
manage a portfolio of projects and there
are several projects that the
organization is performing at the same
time so as a prelude to studying the
project initiation process we need to
study how does the organization really
select its project portfolio once we
have done that the next particular
process is the scope planning process
scope planning process is where the
details of the product to be produced
are understood this is followed by the
scope definition process where the
project scope is put down in writing in
a pre-specified format any job is really
not done until you have undertaken the
verification for the work done if you
remember yesterday's analogy of falling
from the first floor versus rolling down
the staircase we must do some work so
always understand define and verify so
the fourth particular scope involves
scope verification last but not the
least is the scope that we have defined
is never going to remain constant the
scope that we have defined is never
going to remain constant and as such we
will have to control the changes to the
scope now we will look at all these five
sub processes in more detail for
instance
typically an organization justifies IT
and ice projects based on several
considerations for instance there may be
explicit business objectives which need
to be achieved okay similarly there may
be some implicit business objectives to
be achieved you know so this may include
that we would like to provide a kind of
a service level to the customers okay
and we say if the service level is to be
provided you know then the corresponding
documentation must also be equally good
another particular reason for
justification is response to competitive
systems you know if your organization is
challenged by some competitor then you
may be required to come out with variety
of other systems you know that will cope
with it you know dot-com companies and
ebusiness has given a good series of
responses in this particular direction
there are other reasons for justifying
the project's like management
decision-making sometimes you may might
want to have a decision support system
for supporting the organization's top
brass many many other things that are
legal and government requirements
technical requirements for the systems
you know good internal rate of these are
all commercial kind of an internal rate
of return
you know net present values reasonable
payback you know for the investment that
is made okay and there may be other
considerations like a high probability
of achieving the benefits in the
specified time now what happens is an
organization cannot take all projects at
the same time so you know like you say
it will take some good and some bad you
know like it may take some small
projects and it may take some large
projects it may take some risky projects
and it may take some safe projects and
it may take those projects which have to
be done and it may also take some
also-ran kind of projects okay so that
variety of reasons
you know why organization undertakes
project so the set of projects which is
selected for being performed or
particularly undertaken is what is
called a project portfolio okay so basic
premise behind project portfolio
management approaches to collectively
evaluate all the applications in the
portfolio to study their impact on the
organization okay so the balancing is
done on a variety of considerations like
project size experience with the
technology support to strategic role
okay
centralized versus end-user computing
risk versus payoffs and use a
proficiency in you know tackling the
situation okay so an organization
chooses a variety of projects to balance
its overall
requirement balances overall
requirements okay now how does the
organization select this particular
projects in the portfolio that is based
on generating a wide variety of
alternative solutions to each of these
particular projects and then comparing
which particular solution is best in the
interest of the organization okay so the
feasibility analysis starts with
generating alternative solutions okay
the solutions ranging from complete
automation to complete manual activity
similarly creativity and imagination you
know will be the cornerstones for coming
out with these particular solutions once
we have identified some alternative
solutions you know the project manager
is required to make reasonable estimates
about various resources required for
doing this particular project also needs
to provide confidence that the system
will work if the resources were provided
and it needs to give an indication as to
how the system will fit in the
organizational overall plans
so for instance what technology will be
needed what will be the social
implications of introducing this
particular system now what we need to
remember is the operational details of
each project are not very important at
this particular stage once you have
prepared this particular alternatives
the next thing that you are going to do
is to compare them now obviously you can
use only one yardstick for comparison
and you will have to consider several
alternative ways of comparing this
particular project and again one might
want to take a weighted average of these
particular alternative ways of
evaluation to come out with the final
decision about what should and should
not be included in the project portfolio
typical basis for comparing the
alternatives are for instance equivalent
worth methods you know how much money
are you going to spend every year you
might take the approach of present worth
or you might take the approach of future
worth also in a present worth approach
what you will find out is if you're
going to spend so much money every year
for the next so many years what is the
present value of that particular money
you know and then do the comparison
another particular approach is to find
out how much is going to be the return
on investment you know how much we're
investing how much are you getting it
back and how much you will really make
and many organizations stipulate that
you will not undertake a project unless
you have so much return on investment at
minimum other particular approaches are
discounted cash flows you know then
payback periods one can also do a
sensitivity analysis further so suppose
we make a particular assumption and this
particular assumption deviates a little
bit total sales for instance is so being
say 10,000 units you know turns out to
be nine thousand five hundred or nine
thousand or eleven thousand or six
thousand or fifteen thousand kind of a
situation what will be the impact on our
decision okay other techniques like
break-even analysis
treatment of risk you know like some
organizations are more risk prone others
are not so you might look at the utility
functions as well you may also consider
things like make or buy decisions you
know whether it makes sense to make it
rather than by what is available and
another useful approach is the charge
out approach so do depending on who is
the user who is using this particular
project you know he pays for the use of
the project product okay
so you say what is the value of the
service that this projects product will
produce and provide to the user you know
to the user so these criterias can be
used to find out how we can do the
allocation now look at the slide for
instance suppose an organization wishes
to consider you know several projects
okay so you have the billing or during
consolidation project and a product line
reporting project and sales forecasting
project and sales customer analysis
project and you know job production
scheduling financial modeling you know
factory computer-aided manufacturing
application and the truck loading
application again look at the slide you
know you might want to compare these
projects based on considerations like
return on investment risk impact on the
business
you know demand from the customers okay
and some kind of a weighted number to
come out with the overall favorable or
unfavorable situations for the project
then we could do some detailed analysis
and look at this particular results so
in this analysis it looks like you know
that the billing and ordering
consolidation you know project has a
rating of 43 you know obviously this
particular projects have
rank order already for decision-making
you know and it is clear from this that
you will have to select some projects
from the top of this particular list for
implementation and to be included in
your project portfolio to be included in
your project portfolio there are also
other ways of looking at this particular
thing you may may not be interested in
looking at only the quantitative aspects
of the project's feasibility or
desirability in which case again you can
take another approach for instance look
at this polar chart look at this polar
chart now here we have considered only
four dimensions risk profitability
commercial success and time to market
you know and we have drawn you know
different particular projects profile
with different lines you know and it
shows you that the particular project
with this particular project for
instance seems to be having the maximum
area and covering the reach you know in
all the four directions covering the
region all the four direction because
this may not be very good for doing the
selection but it gives you at a glance
perfect idea about which particular
projects are candidates and what are
their dominant sort of strong points you
know for selecting them okay so once we
have done this particular kind of
activity you know that the project
portfolio has been selected then we come
down to one specific project that is
where really our subject starts okay and
we say that we need to initiate this
particular project we need to initiate
this particular project okay so what is
really the purpose of this particular
project initiation to
again with it is to confirm that the
assigned project okay is achievable
within the specified framework so you
say yes it can be done okay
then formally authorize the new project
okay so we say this particular project
has company and decided to take this
particular project up for development
you know in the next whatever that
specified period it also is aimed at
specifying exactly what the project will
produce or achieve it needs to
adequately specify the requirements for
undertaking the project planning
activity mind you the details of the
requirement will have to be finalized
later but at this particular stage
you'll need to specify the requirements
in adequate detail so that the project
planning activity can begin also the you
know broad idea is required about the
quantum and the kind of resources that
you are required for undertaking this
particular project also to establish a
basis for how this particular project
success will be judged you know because
we don't want to find out at the end of
the project will they feel successful or
not we would like to check throughout
the life of this particular project and
to find out whether the project is
running on the right course so control
mechanisms will have to be also
specified then we have very important
particular thing and as we have already
seen an organization it does not you
know run in vacuum it runs as a part of
a performing organization so obviously
from that particular point of view okay
so linking of the current project to the
ongoing activities of the performing
organization is very essential okay last
but not the least when we announced the
project we would like to bring together
the team members okay with a view to
make sure that we get their commitment
for doing the project remember neither
of
project manager nor individual team
members okay have been selected only for
the preference it is the organizational
preference in allocating these
particular people to this particular
project it's very necessary that these
people you know whatever their initial
reservations that may be doing and
working on this particular project they
need to be overcome and you need to give
them a team spirit whereby they will say
yes we would like to do this particular
project so all these particular things
need to be achieved with the project
managers particular any project
initiation process project initiation
process how do we go about doing this so
the first thing during project
initiation that the project managers
need to do is to question everything
literally what we mean is question
everything now look at the slide an IT
project manager for instance needs to
check that the management has given him
a particular project is it valid now all
the resources adequate if the time
specification you know correctly done
okay who are the vendors going to be
supplying to this who are the other
managers and the team members who are
going to be working on it okay what kind
of support is required for this
particular project
you know what talents or the skills will
be required for doing this okay
similarly we need to question each and
every aspect don't take anything for
granted as a project manager when you're
beginning to break apart you're taking
over a project remember what we are
doing is you're taking or a project and
when you take over a project you know
you need to take make sure that before
you take this particular project up
there are no doubts in your own mind
about the possible success of this
particular project possible success of
this particular project okay
so you questioned everything that you
can and you found that okay for you know
you get a reasonable answers to all
these particular questions then you
start looking at the project itself so
now you have taken charge of the project
in a true sense you know psychologically
you're willing to stick your neck out
and say yes I will get this particular
project done so that what do you what is
the next thing that you do now the next
thing that you must do is to identify
all the projects stakeholders who are
the stakeholders stakeholders are all
those people who are affected because of
the project stakeholders or all those
people who are affected to the flooding
they may have affected either directly
or indirectly you know one of the fears
that has always talked all the IT
projects is it will result in
eliminating manpower which of course
many studies have shown is not true okay
similarly the stakeholders may be
affected you know you know in terms of
various positive or negative manner and
this you need to keep in mind so any
project really needs to balance between
the expectations of the stakeholder this
is specially true because interests of
different stakeholders are often
conflicting you know it's like you know
suppose you try to introduce an octree
management system at doctoral innaka
then lots of people are going to be
affected because of this particular
decision it is no different from trying
to introduce you know a small system in
say Cheeta a bandeau meet annually shop
in pune
okay the customers as well as all the
workers and the managers and the top
menu all are going to be the
stakeholders in such a project
okay now the stakeholders can also be
classified
internal and external you know so the
internal stakeholders have typically the
sponsors the project staff the support
staff the top management you know and
all the other people working within the
organization and typical external
stakeholders are the customers or
external sponsors of the project the
suppliers the regulatory agencies the
competitors you know and of course the
society at large the society at large
okay now look at the slide now the slide
shows you typical stakeholder analysis
in a simplistic manner here we have mr
rajendran okay so the rajendran is
basically a member of the management is
the internal sponsor is a company
director is you know unique facts about
him are like he is very demanding
you know like details as a business
focus and he has done you know a
master's degree from I am okay his level
of interest in the project is very high
and his influences were very high and
you know suggestions for keeping
mentoring him are that he likes to be
you know keep him informed you know let
him lead the discussions and quickly do
what he says okay so you look at nan
he's another girl working on our
particular project you know she's a team
member she's the lead programmer
obviously he's the best programmer that
we got you know he's very easy to get
along and she's a very good sense of
humor
and have interest also in the project is
very high having been with us for a long
time she has a good influence in the
organization and this is very important
very hard to replace so we'd like to
make sure that we
keep her as long as we can right so keep
her happy so yet she stays okay
and of course on a lighter side we also
specified that she needs some Mexican
food likes Mexican food or something
right we have another details about
somebody like jiggly who is the hardware
wonder who is going to do supplies for
our particular project okay
he's a you know somebody who has been in
his line for a long time
nice a little gentleman settled okay to
him your project is one of the projects
that he is supplying to so his interest
is reasonable you know you know like
he's not really you know running after
your particular project
his nature requires that you give him
adequate lead time to deliver you know
and though he takes a backseat but
there's a lot of things that you can
learn from him in view of his large
experience in me of his large experience
okay so now we do a stakeholder LLC now
it's a very tricky situation in many
cases you may not be in a position to
put the stakeholder analysis on a piece
of paper and circulate it then put it in
the notice board but as a project
manager is very essential for you to get
a good thinking done in this particular
area
good thinking down into who are the
stakeholders and how you would like to
tackle them once we get the stakeholder
idea now we need to make sure the first
thing that you would like to do is to be
very clear about what are the objectives
that the project is supposed to achieve
most importantly okay so say a project
without clear goals cannot succeed why
for a simple reason
no it will not achieve the goals that
are required because we don't know it
you know you cannot achieve it it may
achieve some goals which really are not
required you know again doesn't really
count towards the success you know
achieve the goals which have already
been achieved so we are duplicating the
effort somebody is already done is
somewhere and you're doing it all over
again they say you know the projects
need a very clear goal okay
so the project objectives may be
classified as a hierarchy also you know
so the top level hierarchy you know will
be broad details you know and then
you'll have to go on specifying these
objectives to a level where they are
ultimately measurable they well they're
very major okay so you have system level
objectives you have functional
objectives and you're at the last
quality objectives to be achieved by the
project similarly critical project
attributes for a particular project can
also be specified we will say what are
the critical attributes is a critical
attributes are those attributes which if
not achieved you know the product will
be deemed to be a failure the product
will be deemed to be a failure the
project will be of no use I'll take a
simple example suppose you are having a
CSI convention in Bombay and you are
required to develop a CSI conference
registration system and your system is
going to be ready two weeks after the
CSI convention is over you're having a
problem on hand but we know from our
experience that lots of project get
delayed well beyond two weeks you know
and find nothing seems sharp and a
payroll project for instance gets me
little bit two weeks you know nobody is
going to really you know bring the
heaven enough together so I say critical
attributes are those which the project
must achieve you know and the other
attributes different degree of levels
need to be achieved
you know usually there are product
attributes which are critical and the
project attributes which are critical
reliability and speed may be like the
product attributes whether the quality
cost and schedule may be grouped as the
project attributes which are important
now let's say
illustration look at the slide one of
the hospitals wanted to develop a
hospital information systems so what
objectives did they have in mind so the
first and foremost the objective was to
make available wherever required
integrated real-time information about
the patients of course to all concerned
the second particular objective was to
help in optimizing the sharing of
hospitals resources across various
departments this particular aspect is
very important please not many times the
information is generated and kept in one
department and it is not very easily
available to other departments look at
the third particular objective of this
particular hospital in automating to
relieve the hospital
staff from the repetitive and clerical
work have you not heard of social work
agencies where social trained social
workers spent 2/3 of their time in
pen-pushing
rather than going and doing social work
in the field you know meeting the
children or aged people or whatever they
do you know because the system makes a
lot of demands on this particular kind
of activity so to relieve the hospital
staff from repetitive and clerical work
is very major objective from this
hospitals point of view another
particular objective to assist in
education of hospital staff on an
ongoing basis by providing an overall
view of the hospital's health care
system and it's organization you know it
is very important that we train people
as close to reality as possible without
really having to you know actually work
in the field without experience and then
learn by making mistakes ok so training
of people is a very important
shoe with all the organizations and this
particular training can be done to a
large extent also by sharing information
that is available that is accumulated by
the organization or periods of time last
but not the least to provide the
hospital management with a tool for
measuring the costs and performance of
its activities not remember in the past
there has been a misconception that the
charity hospitals hospital II you know
we're often so started by charitable
Institute's that costs and performance
are not their key judging factors that's
very wrong see cost is the other side of
resource consumption there is a resource
consumption and costs are two sides of
the same coin and a hospital may be a
charitable organization and it may not
be wanting to cost and price you know
its services but it is very essential
for it to realize how much resource is
being deployed in the end product that
it is producing okay so these particular
objectives you know as they are
specified you know by the University
Hospital of Geneva is visible you know I
am sure many organizations produce this
particular type of documents so once we
got the objectives in mind now what we
need to do is to make a big bang
announcement okay that this particular
project is going to start so the project
initiation process the next thing it
does is to authorize the new project
that we are undertaking what it means is
the top management is endorsing the
decision of the proposing management to
undertake this particular project okay
so
measuring the usefulness of the product
to the project's owner choosing between
alternative solutions and optimizing
under the given circumstances all this
has been done and now this needs to be
endorsed by the top management so after
senior management decides to undertake
this particular project okay it is
essential that the rest of the
organization knows about this particular
decision there are many different ways
in which this decision is communicated
down the line to everybody in the
organization one particular approach is
to produce a document called project
charter of course please remember a
project charter by any other name you
know would still mean the same
particular thing basically announcing
the arrival of a project so project
charter is the most frequently used
document that authorizes the
commencement of the selected project in
the organization what does this do once
you have selected this particular
project this project needs to be linked
to the other aspects in the performing
organization you know it needs to
integrate with the external aspects the
internal integration within the
particular it must integrate with the
planning framework of the organization
and the control framework of the
organization so the projector plays a
very important role let's now look at
some of this particular aspect okay so
let's look at some of this particular
aspects this is an illustration of a
project charter this is the illustration
of a project charter okay now what do
you see here you start with you know by
putting a name you say our particular
project is term OS upgrade XP and 2000
service sponsor is Arun Raja is the
chief executive officer
you know the team members are Chandru
who is a network administrator and his
team consists of Shashi Jagdish
Pankaj and Julie
in the project goals are that all the
desktops in the organization will be
upgraded to Windows XP by 3rd December
Windows 2000 will be put on six new
servers that we are planning to buy by
20th of December and all existing
servers in the organization will be
upgraded to Windows 2000 ok by that same
date now let's proceed further what does
it say you need to make a business case
for this particular project they say
business Windows 95 has served the
company for the last five years it has
been decided now to shift to new
technology from Microsoft which is
similar but far superior to Windows 95
Windows XP will make us more productive
more mobile and more secure this will
also enable us to introduce in future
excellent techni technologies which can
run only on Windows XP it will also be
in keeping with our orientation of
keeping the web presence ok on the www
World Wide Web and also so you know all
the servers will have to be upgraded to
this particular the same then it is very
important for us to specify what are the
time deadlines how the progress will be
managed you know what will be done in
September what will be run in October
what will be done in November what will
be run in December what budget is
required
you know what test facilities are
required what educational conferences
our educational consultant is a company
called software mark India Limited
software mark India Limited ok so this
kind of details will have to be
specified in the project charter
so project initiation process basically
comes out with outputs like first the
project charter ok
it also might bring out a list of
constraints these are the factors which
limit the project teams options it will
also list all the assumptions that have
been made and the basis on which you
know the project is going to be
implemented and identification of a
project manager please remember earlier
you assign a project manager to this
particular job the project you know the
better is the chance of survival of this
particular for example if you take
ownership of this particular project at
the earliest okay so this will bring us
to the end of project initiation but
project initiation really never gets
completed in a true sense unless we do a
little bit of a formal term term about
it you know what is called a project
kickoff okay so if you have a formal
project kickoff okay it will get you
know so much better response from the
organization what are the purpose is it
we serve first of all it will introduce
the project manager and the team members
to each other it will also help in
creating a team spirit up front he'll
also help formulator Oh forgive open
environment you know an opportunity for
fair exchange of technical issues in the
organizer about this particular project
to achieve common understanding about
the projects requirement to get a
commitment from the team to demonstrate
the management's backing to the project
for instance who attends your project
kickoff will you know really go down in
the grapevine of the organization to say
how important this project is to the
organization okay so the project akov
needs to be well organized you know you
need to invite the management and other
stakeholders you need to set a stage you
need to specify the purpose get all the
involved people together and highlight
the financial budgetary commitments that
the organization is making and that
you're all ready to begin your project
you are all ready to begin your project
let us now go to the second sub process
in scope management that is the scope
planning and definition process scope
planning and definition process is aimed
at note that progressively elaborately
not one day progressively eliminating
and of course documenting the work that
needs to be done to produce the product
wait so it develops documents which will
form the basis for all the subsequent
project decisions all the subsequent
project decisions yeah so criteria for
completion of a project or a phase of a
project what are the estimated costs
what are the schedules what are the
resources what is the baseline for
monitoring and controlling the projects
what measurements are required you know
how they are to be done what information
needs to be communicated up and down the
organization okay and clarity in
assigning roles and responsibilities to
different people who are associated with
the project okay and last but not the
least you know evolve a common
understanding for the project scope
amongst all the stakeholders so the
scope planning and definition process
really is at the heart of the project
scope management activity it will result
in some kind of a work breakdown
structure being produced understand we
will talk now a lot of breakdown
structures the work breakdown structure
will tell you what different activities
need to be performed you know to
complete the project
similarly later on we'll talk of
derivative
variable breakdown structures we will
say what things will be physically
delivered to the either the internal or
the external clients of the project okay
so first let us look at a typical work
breakdown structure okay so look at this
particular slide we have you know an
Internet project and at level one we
need to do say five activities
conceptualize the project do a website
design then develop the website
according to the design then do a
rollout and provide ongoing support for
our site now each of these particular
tasks each of these tasks at the first
level can be further defined at the
second level okay so look at the concept
part of it so first we do is evaluate
the current system then define the
requirements for our particular project
then define the risk management approach
for our project then we develop a
project plan for performing the project
and we do a briefing for the development
team we will need to do a similar
decomposition for website design website
development activities the rollout and
the support activities now you can
extend this particular idea to one level
further or as many levels further as
required in this particular case we have
drawn up a third level breakdown
structure you know so we say how do we
define the requirement so is it define
the user requirements define the content
requirements define the system
requirements define the server
requirements please remember defining
requirements is the
most difficult task in any project
defining requirement is always the most
difficult task in any project and from
that point of view you know we need to
have all the stated requirements all the
implied requirements all the legal
requirements all the exotic requirements
that you may have you know and these
particular requirements do not all come
from the same so so we need to go to
different people to get their
requirements and then Z cancel the
conflicts that may arise in these
particular requirements and specify the
requirements so in this particular way
we have defined how this particular job
will be done at the third level and as I
already mentioned earlier each of the
other particular tasks at second level
need to be further defined to a third
level and subsequently to a lower level
if required so when we have done our
scope planning and definition process
activity
what outputs do we get so the first
output we get is the document called the
scope statement sometimes it is also
known as statement of work especially if
you are subcontracting a particular
project then the statement of work is a
very important document statement of
work is a very important document it
directly or indirectly refers to the
product its objectives it justifications
and its deliverables okay it is also
possible to have multiple scope
statements okay to match different
levels of the work breakdown structure
so you may define the scope statement in
detail in keeping with the levels in the
work breakdown structure in this
particular statement please remember
though we make it now
is going to be revised on an ongoing
basis so don't consider this as the
final but all the same at this point of
time you need to put down and write
whatever the project is supposed to be
doing in a document called the scope
statement now since this particular
scope is going to be you know tracked
throughout the life particular of the
project you know this scope management
plan will have to be a scope management
plan will describe how the project scope
will be managed this includes how to
bring about the possible changes that
might in course of time come for this
particular project it also describes how
the scope changes will be identified
classified and incorporated please
understand this the changes will keep
coming you know without any predefined
kind of a distribution it just comes
whenever some you know somebody changes
the requirements or some errors are
discovered conflicts are discovered you
know the change will come so the changes
come as and when they sort of are deemed
necessary incorporating those changes
within the scope statement you know has
to be done in a planned manner that's
why the scope management plan tells you
how to bring about these changes you
know in the project scope last but not
least know several supporting details
like assumptions and constraints will
also be there you know every time you
are doing any particular job the job is
always going to be done based on certain
constraints and certain assumptions you
know and it is very necessary for you to
prepare an appendix all the time you
know to say what are the assumptions and
what are the constraints under which the
current decisions have been taken
current decisions have been taken okay
so we initiate the
project then we defined the project now
what we need to do is to verify that
this particular definition is correct
now please realize this we are not
looking at the scope verification
process as a quality control activity
quality control activity you know may
also have an objective to verify the
scope that is defined but in our case
the objective of the scope verification
process is to bring an acceptance bring
an acceptance of the project sponsor to
the scope as is defined please remember
this the quality control is an internal
requirement where is that bringing the
acceptance is a project's requirement of
a different type so scope verification
that we are talking about is very
different from quality control activity
which might involve for instance review
of the scope definition so this
processes of scope verification and
quality control reviews may often be
performed together okay
to ensure because both are achieving
different particularly achieve different
objectives but the activity that is
involved may be similar so scope for
evasion process is aimed at obtaining a
formal acceptance of the project scope
by the stakeholders a vague or a broad
scope you know might result in for
instance scope creep but it is a creep
that is a gradual increase in the
coverage of the project you know because
some ends were left loose okay so it
case you have such open end opens of
lose ends and the scope is not defined
and then subsequently verified you may
have very frequent changes
to the scope so our objective is to make
the scope statement as good and as
acceptable as possible and make sure
that subsequently the number of changes
are kept to a minimum and whenever they
occur they are brought about into the
scope statement in a controlled kind of
a manner so the scope variation process
has a formal output and that is the
acceptance of the scope definition by
this equal dose by the stakeholders okay
now once we have got this verification
we must make sure that requirements
management is a very important activity
that we'll have to perform throughout
the life of the project the requirements
are specified in the scope you know will
not be the same ones that are met at the
end of the project and the requirements
will keep on changing from that point of
view over the life of the project so say
what is really the purpose of
requirements management in this context
so you say we say if we have a proper
requirements management then it will
ensure that the requirements are defined
properly that is even the simplest of
the needs are documented then those
requirements are understood uniformly by
all concerns that means the customer the
developer the testers the third parties
must understand the same thing from what
is documented these requirements need to
be agreed validated and accepted by all
the stakeholders so obviously the
conflicts that may exist in these
particular requirements will have to be
eliminated before that and last but not
the least the requirements will have to
be maintained and controlled okay so
once we have done this particular kind
of a job you know it will help us a lot
in subsequent implementation of the
project so we
periodically be able to confirm that the
changes that we have you know have been
agreed upon you know any negotiations
that might be required have been done
and any changes to the baseline also
been performed so all these particular
activities will have to be done so we
come to the next sub process and that is
the scope change control process scope
change control process says that the
changes to the requirement are
inevitable those changes may be because
of the customers initiation Dickinson's
that if the state government was to
change the tax laws you know then the
corresponding changes will have to be
made to the payroll system you know it's
a customer initiated change you can't
really do away with similarly the
developers may initiate changes usually
the developer initiated changes are as a
consequence of the errors detected
you know whenever an error is directed
some kind of a corrective action which
should be taken so the developer
particular thing and of course there
could be changes which might be because
of the you know project products
environment that you are producing you
know like in the middle of your
development effort if the new version of
you know OS or a DBMS or some compiler
or some tools was to be introduced and
you may like now to change the scope of
your project to incorporate this new
technology okay so the variety of
reasons why these particular changes
will really the change control process
you know is directed at controlling the
changes many projects fail because the
changes to the scope are in an
uncontrolled fashion changes to the
scope are uncontrolled so we say in
brief the scope change control process
is concerned with influencing the
factors that cause the scope changes
obviously we would like to keep the
number of changes to the scope to a
minimum
next whenever these changes are proposed
agreeing upon the scope changes as to
what will and will not be changed
pretty much every suggested change need
not necessarily be implemented let's
take an example suppose we have a ABC
categorization of changes you have a car
when the car doesn't work you know the a
can take every problem needs to be
solved immediately suppose the horn or
the headlights are not working you have
a system that is working but in a
curtail fashion and it's not fully fit
maybe a car without headlights cannot be
driven at night or a car without harm
cannot be taken to bullish her area you
know where the pedestrians in plenty on
plentiful on the roads okay but all the
same the car works and they take the C
category changes like a scratch on the
paint and you'll say yeah you know we're
not going to go through the mechanic you
note for getting this particular car
done up or the repair garage to get the
car done up immediately whenever the car
goes for repair next time you know we'll
also get these small things done the
same analogy can be done with a software
project okay so you have a situation
where a product you know have crashes
you know it's a category problem if you
find that you know there's a performance
issue involved and you know the number
of users at any one point of time logged
you know in some manner will go beyond a
certain level you have a problem no it's
a me category problem or you may know
that a particular function is not
working very well so you say please
don't use that function the rest of the
system is equally usable let me get a
get a problem you have a C category
problem where there may be a spelling
mistake in the screen and obviously this
mistake you know need not really
initiated you know bringing about a new
version of the whole product this can be
taken care off whenever you're you know
making other
changes to this are similar kind of
programs
okay so agreeing upon the scope changes
and managing the actual changes when
they occur you know managing is very
important you already had this problem
that the change was incorporated but
somebody who wrote that particular
change in you know the old version of
the file was again retrieved recovered
or incorporated in the build sequence of
a product you know and the change which
you apparently made does not reflect in
the final product okay now remember this
the scope change control that we are
talking about also needs to be
integrated with the other change control
processes in the integrated integration
knowledge area that glass we have we
have a process called overall change
control so the overall change control
integrates between changes favoring
first take a simple example suppose I
was to change the scope of my project it
may affect that changes to quality it
may affect changes to cost it may affect
changes to shading and so on and so
forth so you can make a change to the
scope without making corresponding
changes also to other knowledge area
okay so scope change control process X
by itself and it also integrates with
the other change control processes in
the organization other change control
processes in the organization now before
this being a very important point before
we go further let me highlight you know
some suggestions which are made by
experts to minimize the changes to a
project scope please remember though the
changes are not avoidable you know they
can definitely be minimized okay so what
are the season first develop a good
project selection process deliver good
project selection process include the
users you know in almost all decision
makings you know
Kolak eight the users with the
developers you know so the familiarity
between the two will avoid
misunderstandings you know use
techniques like prototyping joint
application development or know if
you're a rational ros user you know use
cases kind of approaches to clearly
understand the requirements ok the more
you invest in understanding the
requirements there are less chances of
there being changes to the scope later
on ok
so this stakeholders and various
stakeholders and the developers if they
have brought close too close to each
other you know then the chances of any
changes due to misunderstanding are
likely to be less next important thing
is to put all requirements in writing
keep those things current and have them
readily accessible
don't put the requirement document under
a safe key so that nobody can look at it
and say it's a very important document
signed by the client and from that point
of view cannot be touched by you know
the ordinary and the mundane people
working on the project now ok
extensively use case tools you know for
getting the requirements and
subsequently you know generating the
depth vertical implementing the project
based on this particular requirements
not a very successful approach but one
approach also is to make the user sign
off you know things whenever the
documents are produced
please remember this particular session
has only a limited application because
you know if you the user is totally
unaware of your way of writing
describing and specifying he may just
either not sign or sign the document
without really understanding it ok also
you make sure that
deliverables to the project are
delivered on a regular basis then you
have periodic meetings with the users
you know then do the testing throughout
the lifecycle make the project
information available to all concerned
develop and follow a requirements
management process evaluate the change
request you know I have some kind of a
change Control Board you know which will
look at impact analysis of each
particular change before it is made okay
so these suggestions will help you in
minimizing the changes and obviously if
the changes are minimized then the scope
change control process will work very
well what are the typical outputs from a
scope change control process okay first
is scope changes these are the agreed
please underline the word agreed
documentation vertical agreed
modifications you know to the scope
which are documented and which are fed
back into the planning process and they
have implemented to all the stakeholders
ok so whenever you make a change make
sure that it is documented it is
approved authorized then you make
changes to the plan and intimate all
concerned that the changes been made so
the results you know will be very
obvious on that the second is the
corrective action sometimes the changes
are due to an error and once you detect
these particular errors you might want
to correct the output that has been
generated but also correct the process
you know that generated the wrong output
in the first place basic simple example
so they have a process which is aimed at
doing a third normal form analysis and
your first normal form says that in case
you have a repeating group okay separate
the repeating group with a new key which
consists of a compound key of the parent
groups key plus the key of the separated
group fine works fine now if you while
doing the
particularly of your encounter situation
where we have nested repeating groups
now you know the process is silent about
it so what you do you'll say okay how do
I solve nesting situations in other
times you know like if statements or new
statement and I always tackle the
innermost you know loop first and then
the outermost one and using the same
particular approach you were to take the
repeating group and take the innermost
repeating group and separate it out as a
relation and then separate out the outer
repeating relation repeating group as a
relation you will find that you made a
mistake you know and the correct way of
doing it is in case you have nested
repeating group then remove the
outermost repeating group first as a
separate relation and then from this new
relation remove the repeating
second-level repeating group as another
relation so fine you first time you do
the project you do this mistake and then
during the review or somewhere down the
line somebody pointed out the mistake
and you went and made correction to the
normalization that you did to the
product but now you also need to go and
make a normalization process
modification you need to take a
corrective action okay so that the
process is also modified and any
subsequently if any one is encountered
encounters this kind of situation that
person will not repeat the same mistake
again so you have a scope changes the
near corrective actions you may also
adjust the baselines we will see
subsequently during the configuration
management what is the baseline it is a
collective you know group of version
control items together known as a
baseline okay so you have a baseline
document okay and all these particular
baselines will need to undergo changes
whenever you made a change last but not
the least you know the lessons learned
from any of the
exercises that you have done must also
be fed back into the organizational
system okay so these are the various
output from the scope change control
process let us now summarize what we
have talked so far good look at the
slide now the scope management sub
processes are first the project
initiation process which is preceded by
project portfolio selection then you
need to do the planning and the
definition of the product that you are
producing once you have done the
planning and the product definition then
you need to verify the defined scope of
the project and here we may not do the
quality control activity that can also
be done but mainly get approval of the
sponsor with the scope as you have
defined in the document is consistent
with what they had in mind and last but
not the least I have a scope change
control process in place which in turn
integrates with the overall change
control process of the project
integration knowledge area thank you