Software Engineering

Prof. Shashi Kelkar

Department of Computer Science & Engineering
Indian Institute of Technology, Bombay
Lecture - 30
Project Scope Management
In our session by understanding 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 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 projects 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 at this particular stage that all stakeholders must agree with the
projects scope.
Now, if you look at the project scope management process it consists of different subprocesses. Let us look at the slide now.
(Refer Slide Time 02:44 min)

The first process that 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 if followed by the scope definition process where the projects 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 yesterdays analogy of falling from
the first flow or versus rolling down the stair case 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 IS projects based on several considerations. For instance,
there may be explicit business objectives that need to be achieved. Similarly, there may
be some implicit business objectives to be achieved so this may include that we would
like to provide a kind of a service level to the customers and we say if the service level is
to be provided then the corresponding documentation must also be equally good.
Another particular reason for justification is response to competitive system. If your
organization is challenged by some competitors and you may be required to come out
with variety of other systems that will cope with it; Dot com companies and e-business as
given a good series of responses in this particular direction.
There are other reasons for justifying the projects like management decision making.
Sometimes you may (w.6:08) want to have a decision support system for supporting
the organizations top bras. Many many other things are there; legal and government
requirements, technical requirements for the systems, good internal rate of.. these are
all commercial kind of. internal rate of (re..6:28) net present values, reasonable
payback for the investment that is made and there may be other considerations like a
higher probability of achieving the benefits in (res..6:42 time).
Now what happens is an organization cannot take all projects at the same time. So, like
you say it will take some good and some bad, 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 takes those projects which have to be done and it may also take some
also ran kind of projects so there are variety of reasons why organizations will undertake
projects. So the set of projects which is selected for being performed or particularly
undertaken is what is called a project portfolio.
So, basic premise band, project portfolio management approaches to collectively evaluate
all the applications in the portfolio you study their impact on the organization. So the
balancing is done on a variety of considerations like project size, experience with the

technology, support to strategic role, centralizes end user computing, risk versus payouts
and user proficiency in tackling the situation. So, an organization chooses a variety of
projects to balance its overall requirement, balance its overall requirement.
Now, how does the organization select these 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. So the feasibility analysis starts with generating alternative solutions; the
solutions ranging from complete automation to complete manual activity. Similarly,
creativity and imagination will be the corner stones for coming out with these particular
solutions.
Once we have identified some alternative solutions the project manager is required to
make reasonable estimates about various resources required for doing this particular
project. Also he needs to provide confidence that the system will work if the resources
were provided and he needs to given indication as to how the system will fit in the
organizations overall plan. 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 than this particular space. Once we have prepared these particular alternatives
the next thing that we 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 these particular projects. And again one might to 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 work methods;
how much are you going to spend every year. You might take the approach of present
work or you might take the approach of future work also. In a present work approach
what you will find out is if you are going to spend so much money every year for the next
so many years what is the present value of that particular money and then do the
compiler.
Another particular approach is to find out how much is going to be the return on
investment; how much you are investing, how much you are getting it back and how
much you will really make. And many organizations typically that you will not undertake
a project unless you have so much return on investment at minimum.
Other particular approaches are discounted cash close, then payback periods. One can
also do a sensitivity analysis. for instance, suppose we make a particular assumption and
this particular assumption deviates a little bit; total sales for instance, instead of being a
10000 units turns out to be 9500 or 9000 or 11000 or 6000 or 15000 kind of a situation.
What will be the impact on our decision?

Other techniques like break even analysis, treatment of risk, 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 by decisions like you know whether it makes sense to
make it rather than buy what is available.
And another useful approach is the charge out approach. So what you do; depending on
who is the user who is using this particular project he pays for the use of the project
product. So you say what is the value of this service that this projects product will
produce and provide to the user to the user. So, this criterion can be used to find out how
we can do the other things.
(Refer Slide Time 12:22 min)

Now look at the slide for instance. Suppose in an organization we just consider several
projects so you have the billing ordering consolidation project and a product line
reporting project and sales forecasting project and sales customer analysis project and job
production scheduling, financial modeling, factory, computer aided manufacturing
application and the truck loading application and so on.
Again look at the slide; you might want to compare these projects based on
considerations like return on investment, risk, impact on the business, demand from the
customers and take some kind of a weighted number to come out with the overall
favorable or unfavorable situations from the project then we could do some detailed
analysis and look at these particular results. So in this analysis it looks like the billing and
ordering consolidation project has a rating of 43.
Obviously these particular projects have been rank-ordered already for decision making
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 should be
included
in
your
project
portfolio.

There are also other ways of looking at this particular thing. You may or may not be
interested in looking at only the quantitative aspects of the projects feasibility or
desirability in which case again you can take another approach. For instance, look at this
polar chart look at this polar chart.
(Refer Slide Time 15:06 min)

Now here we are considered only four dimensions: risk, profitability, commercial success
and time to market and we have drawn different particular projects profile with different
lines 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 in all the four directions
covering the reach in all the four directions. Of course 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 some points for selecting this.
So, once we have done this particular kind of an activity that the project portfolio has
been selected then we come down to one specific project that is where really our subject
starts. We say that we need to now initiate this particular project we need to initiate this
particular project. So what is really the purpose of this particular project initiation? To
begin with it is to confirm that the assigned project is achievable within the specified
framework. You say, yes it can be done; then formally authorize the new project. So we
say this particular project has. the company has decided to take this particular project
for development in the next.. whatever the 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 little later but at this
particular stage you will need to specify the requirements in adequate details so that the
project planning activity can begin. Also, the broad idea is required about the quantum
and the kind or resources that you require for undertaking this particular project. You also

have to establish a basis for your.. how this particular projects success will be judged
because you do not want to find out at the end of the project it will be successful or not;
you 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 a very important particular thing.
And as we have already seen an organization does not run in vacuum it runs as a part of
performing organization. So obviously from that particular point of view, so linking of
the current project to the ongoing activities of the performing organization is very
essential. Last but not the least when we announce the project we would like to bring
together the team members with the view to make sure that we get their commitment for
doing the project.
Remember, neither the project manager nor individual team members have been selected
only for their preference; it is the organizational preference in allocating these particular
people to this particular project. It is very necessary that these people whatever their
initial reservations that maybe to doing and working on this particular project they need
to be overcome and you need to give them a team sprit whereby they say, yes, we would
like to do this particular project. So all this particular things need to be achieved with the
project managers particular project initiation process project initiation process.
How do we go about doing this? So the first thing during project initiation that the project
manager need to do is to question everything literally; what we mean is question
everything. Now look at the slide.
(Refer Slide Time 19:17 min)

An IT project manager, for instance, needs to check that the management has given him a
particular project is it valid, all the resources adequate, is the time specification correctly
done, who are the vendors going to be supplying to this, who are the other managers and

the team members are going to be working on it, what kind of support is required for this
particular project, what talents or the skills will be required for doing this.
Similarly, we need to question each and every aspect. Do not take (en..19:56) program
as a project manager when you are beginning you are taking over a project you are taking
over a project. Remember, what we are doing is you are taking over a project and when
you take over a project you need to 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. So you have questioned everything
that you can and you have found that 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; psychologically you are willing to stick your neck out and say yes
I will get this particular project done. So what is the next thing that you do.
Now, the next thing that you must do is to identify all the project stakeholders. Who are
the stakeholders? Stakeholders are all those people who are affected because of the
project. Stakeholders are all those people who are affected by the project. They may be
affected either directly or indirectly. One of the fears that is always stalked all the IT
projects is little result in eliminating manpower which of course many studies have
shown is not true.
Similarly, the stakeholders may be affected 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 stakeholders. This is especially true because interest of
different stakeholders are often conflicting just like you know. suppose you try to
introduce an Octroi management system at the Octroi Naka then lots of people are going
to be affected because of this particular decision. It is no different from trying to
introduce small system in say Chitale Bandhu Mithaiwale shop in Pune; the customers as
well as all the workers and the managers and the top management all are going to be the
stakeholders in such a project.
Now the stakeholders can also be classified as internal and external. So the internal
stakeholders are typically the sponsors, the project staffs, the support staff, the top
management and all the other people working within the organization and typical external
stakeholders are the customers are external sponsors of the project, the suppliers, the
regulatory agency, the competitors and of course the society at large the society at large.

(Refer Slide Time 23:54 min)

Now look at the slide. Now the slide shows you typical stakeholder analysis in a
simplistic manner. Here we have Mr. Rajendran, so, that Rajendran is basically a member
of the management, he is the internal sponsor, he is a company director, unique facts
about him are like he is very demanding like details, he is a business (.23:47) and he
has done his Masters degree from IAM, his level of interest in the project is very high and
his influences are very high and suggestions for keeping, mentoring him are that he likes
to be. keep him informed, let him lead the discussions and quickly do what he says.
So you look at Nyan, another girl working on our particular project; is a team member, is
a lead programmer; obviously is the best programmer we have got, is very easy to get
along, has a very good sense of humor and her 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 it is very hard to be replaced so we would like to make sure that we
keep per as long as we can; so keep her happy so that she stays and of course on a lighter
side we also prescribed that needs some Mexican foods like Mexican food or something
like that.
We have another detail about somebody like Jagdish who is the hardware vendor who is
going to do supplies for our particular project. he is somebody who has been in his line
for a long time, nice, elderly gentleman, settled; to him your project is one of the projects
that he is supplying so his interest is reasonable like he is not really running after your
particular project; his nature requires that you give him adequate lead time to deliver and
though he takes a back seat but there is a lot of things that you can learn from him, you
have his large experience; you have his large experience. So now we do a stakeholder
analysis.
Now it is 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 and put in the notice board. But

as a project manager it is very essential for you to get a good thinking done in this
particular area; good thinking done into who are the stakeholders and how you would like
to tackle it. Once we got 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.
So you say a project without clear goals cannot succeed; why?
For a simple reason; it will not achieve the goals that are required because we do not
know it we cannot achieve it. It may achieve some goals which really are not required;
again does not really count towards the success or achieve the goals which are already
been achieved. So we are duplicating the effort; somebody has already done it
somewhere and you are doing it all over again. They say the projects need a very clear
goal so the project objectives may be classified as a hierarchy also. So the top level
hierarchy will be broad details and then you will have to go on specifying these
objectives to a level where they are ultimately measurable; the level they are very
measureable.
Thus, you have system level objectives, you have functional objectives and you have at
the last quality objective to be achieved by the project. Similarly, critical project
attributes for a particular project can also be specified. So we will say what are the
critical attributes. You say critical attributes are those attributes which if not achieved 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.
Now 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; here having a problem on
hand. But we know from our experience that lots of projects get delayed well beyond two
weeks and fine nothing seems to happen; a payroll project for instance gets delayed by
two weeks, nobody is going to really bring the heaven and earth together. So you say
critical attributes are those which the project must achieve and the other attributes
different degree of levels need to be achieved.
Usually there are product attributes which are critical and there are project attributes
which are critical. Now, reliability and speed may be like the product attributes whereas
the quality, cost and schedule maybe grouped as the project attributes which are
important. Now let us take an illustration.

(Refer Slide Time 29:20)

Look at the slide. One of the hospitals wanted to develop a hospital information system.
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 patient, 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 note. 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 aut.30:11) to relive
the hospital staff from repetitive and clerical work. Have you not heard of social work
agencies where they train social workers, spend two third of their time in pen pushing
rather than going and doing social work in the field, meeting the children or aged people
whatever they are do because the system makes a lot of demands on this particular kind
of activity. So, to relive the hospital staff from repetitive and clerical works is a very
major objective from this hospitals point of view.
Another particular objective is to assist in education of hospital staff on an ongoing basis
by providing an overall view of the hospitals healthcare system and its organization. It is
very important that we train people as close to reality as possible without really having to
actually work in the field without experience and then learn by making mistakes. So,
training of people is a very important issue 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 period of time.
Last but not the least is to provide the hospital management with a tool for measuring the
costs and performance of its activities. Now remember, in the past there has been a
misconception that the charity hospitals; hospitals usually were optional; so started by
charitable institutes that costs and performance are not there judging factor that is very

wrong. See, cost is the other side of resource consumption. there is a resource
consumption and cost are two sides of the same coin and a hospital maybe a charitable
organization and it may not be wanting to cost and price its services but it is very
essential for it to realize how much resource is being deployed in the end product that it
has produced. So these particular objectives as they are specified by the University
Hospital of Geneva in Switzerland 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 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 rendering. What
it means is that the top management is endorsing the decision of the proposing
management to undertake this particular project. so measuring the usefulness of the
product to the project owner, choosing between alternative solutions and optimizing
under the given circumstances etc all these things have been done and now this needs to
be endorsed by the top management. So, after senior management decides to undertake
this particular project 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 could
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; 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
project charter plays a very important role.
Let us now look at some of these particular aspects. So let us look at some of these
particular aspects.

(Refer Slide Time 35:18 min)

This is the illustration of a project charter. This is the illustration of a project charter.
now what do you see here; you start with by putting a name; so you say our particular
project is termed OS upgrade XP and 2000 servers, sponsor is Arun Raje is the chief
executive officer, the team members are Chandru who is the network administrator, then
his team consists of Shashi, Jagdish, Pankaj and Jolene; 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
by that same date.
Now let us proceed further; what does it say.

(Refer Slide Time 36:22 min)

You need to make a business case for this particular project. You 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; it 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 technologies which can run only on Windows XP; it will
also be in keeping with our orientation of keeping the web presence on the www world
wide web and also serve all the servers will have to be upgraded to this particular
this thing. Then it is very important for us to specify what are the time deadlines, how the
progress will be managed, what will be done in September, what will be done in October,
what will be done in November, what will be done in December, what budget is required,
what test facilities are required, what educational. for instance our educational
consultant is a company called Software Mart India limited Software Mart India limited
so this kind of a detail will have to be specified in the project charter.

(Refer Slide Time 37:35 min)

So, project initiation process basically comes out with outputs like first the project
charter. Second, it also might bring out a list of constraints these are the factors which
limit the projects teams options, it will also list all the assumptions that have been made
on the basis on which the project is going to be implemented and identification of a
project manager. Please remember, the earlier you assign a project manager to this
particular job project the better is the chance of survival of this particular project;
somebody to take ownership of this particular project at the earliest. 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 tomtom about it, it is called project kick off. So,
if you have a formal project kick off it will get so much better response from the
organization.
What are the purposes that it will 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 sprit up front, it also help formulate give an open
environment an opportunity for pair change of technical issues in the organization about
this particular project, to achieve common understanding about the projects requirement,
to get a commitment from the team, to demonstrate the managements backing to the
project; for instance, who attends your project kick off will really go down in the
grapevine of the organization to say how important this project is to the organization.
So the project kick off needs to be well organized; 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 is it you are all ready to begin your project you are all
ready to begin your project.

Let us now go to the second subprocess in scope management that is the scope planning
and definition process. Scope planning and definition process is aimed at note that
progressively elaborating not one time progressively elaborating and of course
documenting the work that needs to be done to produce the product. So it develops
documents which will form the basis for all the subsequent project decisions all the
subsequent project decisions. So criteria for completion of a project or the 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, how they are to be done, what information needs to be communicated up and
down the organization and clarity in assigning roles and responsibilities to different
people who are associated with the project and last but not the least evolve a common
understanding for the projects 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 of a lot of breakdown structures. The work
breakdown structure will tell you what different activities need to be performed to
complete the project. Similarly later on we will talk of deliverable breakdown structure; it
will say what things will be physically delivered to either the internal or external clients
of the project.
So first let us look at the typical work breakdown structure. So, look at this particular
slide.
(Refer Slide Time 42:43 min)

We have 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 role out and provide an 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. So look at the concepts part of it. So first we will 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
activity, the role out and the support activity. 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 so we say how we define the requirements;
we say define the user requirements, define the content requirement, define the system
requirements, define the server requirements.
Please remember, defining requirements is the most difficult task in any project; defining
the requirement is always the most difficult task in any project and from that point of
view we need to have all the stated requirements, all the implied requirements, all the
legal requirements, all the exotic requirements that you may have and these particular
requirements do not all come from the same source so we need to go to different people
to get their requirement and then reconcile the conflicts that may arise in this particular
requirement and specify the requirement. So, in this particular way we have defined how
this particular job will be done at the third level.
And as I have already mentioned earlier each of the other particular tasks at second level
need to be further defined the third level and subsequently to a lower level if required. So
when we have done our scope planning and definition process activity what output do we
get. The first output we get is a document called the scope statement; from then 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, its justifications and its deliverables. It is
also possible to have multiple scope statements 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 do not consider this
as the final but all the same at this point of time you need to put down in writing
whatever the project is supposed to be doing in a document called the scope state.
Now, since this particular scope is going to be tracked throughout the life particular of the
project this scope management plan will have to be prepared. Scope management plan
will describe how the projects 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 these scope changes will be identified; classified and incorporated please
understand this. The changes will keep coming without any predefined kind of a
distribution; it just comes whenever somebody changes the requirements or some errors
are discovered, conflicts are discovered the change will come. therefore changes come as
and when they are sort of deemed necessary; incorporating those changes within the

scope statement has to be done in a planned manner that is why the scope management
plan tells you how to bring about these changes in the project scope.
Last but not the least several supporting details like assumptions and constraints will also
be there. every time you are doing any particular job the job is always going to be done
based on certain constraints and certain assumptions and it is very necessary for you to
prepare an appendix all the time to say what are the assumptions and what are the
constraints under which the current decisions have been taken current decisions have
been taken. So we initiated 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 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 projects sponsor to the scope as is defined.
Please remember this; the quality control is an internal requirement whereas bringing the
acceptance is the projects 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 these processes of scope verification and
quality control reviews may often be performed together to ensure because both are
achieving different particular achieving different objectives but the activity that is
involved maybe similar. So, scope verification process is aimed that obtaining a formal
acceptance of the projects scope by the stakeholders. A vague or a broad scope might
result in for instance a scope creep; what is the creep? That is a gradual increase in the
coverage of the project because some ends were left loose. So, in case you have such
open end opens of loose end 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 control kind of
a manner. So, the scope verification process as a formal output and that is the acceptance
of the scope definition by the stakeholders by the stakeholders.
Now, once we have got this verification we must make sure that requirements
management is a very important activity that we will have to perform throughout the life
of the project. The requirements as specified in the scope will not be the same ones that
are met at the end of the project and the requirements will keep on changing in that point
of view over the life of the project.
What is really the purpose of requirements management in this context?
So we say, if you 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 concerned that means the
customers, the developers, the testers, the third parties must understand the same thing

from what is documented; these requirements needs to be agreed, validated and accepted
by
all
the
stakeholders
so obviously the conflicts that may exist in this particular requirements will have to be
eliminated before that and last but not the least the requirements will have to be
maintained and controlled. So, once we have done this particular kind of a job it will help
us a lot in subsequent implementation of the project. So we will be periodically able to
conform that the changes that we have have been agreed upon, negotiations that might be
required have been done and any changes to the baseline has also been performed so all
these particular activities will have to be done. So we come to the next subprocess and
that is the scope change control process.
Scope change control process says that the changes to the requirement are inevitable
those changes maybe because of the customers initiation. take for instance that if the
state government was to change the tax laws then the corresponding changes will have to
be made to the payroll system; that customer initiated change which you cannot really do
away with. Similarly the developers may initiate changes.
Usually the developer initiated changes are at the consequence of the errors detected.
Whenever an error is detected some kind of a corrective action needs to be taken for the
developer and of course there could be changes which might be because of the project
products environment that you are producing; in the middle of your development effort
if the new version of OS or RDBMS or some compiler or some tool was to be introduced
and you may like now to change the scope of your project to incorporate this new
technology and so on so there are variety of reasons why these particular changes are
made in.
The change control process is directly controlling the changes. Many projects fail
because the changes to the scope are in an uncontrolled fashion; changes to the scope are
in an uncontrolled fashion. We say in belief 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; please remember, every suggested change need not necessarily be implemented.
Let us take an example. Suppose we have A B C categorization of changes, you have a
car in the car does not work so A category 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 it is not fully fit maybe your car without headlights cannot be driven
at night or car without form cannot be taken to Bhuleshwar area where the pedestrians are
in plenty plentiful on the roads but all the same the car works and then take the C
category changes like a scratch on the paint and you say yeah you are not going to go
the mechanic 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 will also get these
small things done.

So, same analogy can be done with a software project. You have a situation where a
product crashes; A category problem; if you find that there is a performance issue
involved and if the number of users at any one point of time logged in some manner it
will go beyond a circled level you have a problem it is a B category problem or you may
know that a particular function is not working very well so you say please do not use that
function the rest of the system is equally usable, B category problem; you have a C
category problem where there maybe a spelling mistake in the screen and obviously this
mistake need not really initiated bring about a new origin of the whole product; this can
be taken care of whenever you are making other changes to this or similar kind of
program.
So, agreeing upon the scope changes and managing the actual changes when they occur;
managing is very important. We have always had this problem that a change was
incorporated but somebody overrode that particular change and an old version of the file
was again retrieved, recovered or incorporated in the build sequence of a product and the
change which you apparently made does not reflect in the final product.
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 is last we have we have a process called overall change control. The
overall change control integrates between changes for it. Take a simple example; suppose
I was to change the scope of my project it may affect the changes to quality, it may affect
changes to cost, it may affect changes to schedule and so on and so forth so you cannot
make a change to the scope without making corresponding changes also to other
knowledge areas. So, scope change control process acts 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
some suggestions which are made by experts to minimize the changes to the project
scope. Please remember, though the changes are not avoidable they can definitely be
minimized.
So, what are the stages?
First, develop a good project selection process develop a good project selection process.
Include the users in almost all decision making. Co-locate the users with the developers
so that the familiarity between the two will avoid misunderstanding, use techniques like
prototyping, joint application development or if you are a rational rows user use cases,
kind of approaches to clearly understand the requirements. The more you invest in
understanding the requirements there are less chances of there being changes to the scope
later on. So these stakeholders and various stakeholders and the developers if they are
brought close to each other then the chances of any changes due to misunderstanding are
likely to be.
Next important thing is put all requirements in writing; keep those things current and
have them readily accessible, do not put the requirements documents under safety so that

nobody can look at it and say it is a very important document signed by the client and
from that point of view it cannot be touched by the ordinary and the mundane people
working on the project.
Extensively use case tools for getting the requirements and subsequently generating the
depth what you call implementing the project based on this particular requirement. Not a
very successful approach but one approach also is to make the users sign off things
whenever the documents are produced. Please remember, this particular suggestion has
only a limited application because if the user is totally unaware of your way of writing,
describing and specifying things he may just either not sign or sign the document without
really understanding.
Also, you make sure that the deliverables to the project are delivered on a regular basis;
that you have periodic meeting with the users, then do the testing throughout the life
cycle, make the project information available to all concerns, develop and follow a
requirement management process, evaluate the change request, have some kind of a
change control board which will look at impact analysis of each particular change before
it is made. 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?
First is, scope changes. These are the agreed please underline the word agreed
documentation it is called agreed modifications to the scope which are documented and
which are feedback into the planning process and they are intimated to all the
stakeholders. 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 change has been made. So the results will be very obvious in that.
The second is the collective 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 that generated the wrong output in the first place.
Just take a simple example; suppose you 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 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 this particular job you have encountered a situation where you
have nested repeating groups; now the process is silent about it so what you do is you say
okay how do I solve nesting situations in other time like the if statement or do statement
and I have always tackled the inner most loop first and then the outer most one; I am
using the same particular approach; you were to take the repeating group and take the
inner most 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 have made a
mistake and the correct way of doing it is in case you have nested repeating group then

remove the outer most 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, first time you do this project you do this mistake and then during the review or
somewhere down the line somebody pointed out the mistake and then you went and made
corrections 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 so
that the process is also modified and subsequently if anyone encounters this kind of a
situation that person will not repeat the same mistake again. So you have scope changes
then you have corrective actions, you may also have to adjust the baseline. We will see
subsequently during the configuration management what is the baseline. It is a collective
group of version control item list together known as a baseline. So, you have a baseline
documents and all these particular baselines will need to undergo changes whenever you
have made a change.
Last but not the least the lessons learn from any of the exercises that you are done must
also be fed back into the organizational system. So these are the various outputs from the
scope change control process. Let us now summarize what we have talked so far.
(Refer Slide Time 01:07:00 min)

scope Look at the slide now. The scope management subprocesses 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 we have done the
planning and the definition then we need to verified the defined scope of the project and
here we mean not do the quality control activity that can also be done but mainly get
approval of the sponsor that the scope as we 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.