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
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 project's
Now, if you look at the project scope management process it consists of different sub-processes.
Let us look at the slide now.
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 project's 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 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 want to have a decision support system for supporting the organization's
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 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 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 organization's 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 project's 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.
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 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 are considered only four dimensions: risk, profitability, commercial success and
time to market and we have drawn different particular project's 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 project's 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 manager's 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.
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
Similarly, we need to question each and every aspect. Do not take 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
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
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 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
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.
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 hospital's 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 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 hospital's 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
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.
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.
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 team's 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 project's requirement, to get a commitment from the team, to demonstrate
the management's 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 project's 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.
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 concept's 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 project's 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 project's sponsor to the scope as is defined.
Please remember this; the quality control is an internal requirement whereas bringing
the acceptance is the 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 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 project's
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 customer's 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
product's 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
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
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.
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.