Follow US:

Practice English Speaking&Listening with: Lecture - 30 Project Scope Management

Normal
(0)
Difficulty: 0

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 project's

scope.

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

doing this.

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

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.

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

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.

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

aspects.

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

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.

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.

The Description of Lecture - 30 Project Scope Management