Risk Management

Loading...

来自 Indian School of Business 的课程

IT Project Management

140 个评分

Indian School of Business

IT Project Management

140 个评分

课程 4（共 6 门，Specialization Business Technology Management）

The concepts and use of project management tools, techniques and methodologies are becoming all pervasive. This course addresses project management in the context of IT projects, including software projects. Using the framework of project life cycle, the course covers various aspects pertaining to (i) project initiation, (ii) project planning and scheduling, (iii) project monitoring and control, and (iv) project termination. For planning and scheduling of projects, the use of project network and estimation of time and cost are covered in detail. Scheduling of projects with resource limitations is covered next. Risk assessment methods including simulation and risk reduction approaches are also be covered. The students will be required to use the software @risk to simulate project completion times. The use of Earned Value Analysis for Project Monitoring and Control is emphasized. For Software Project Management, the Waterfall Model and Agile Project Management are covered in detail.

从本节课中

Resource Scheduling and Risk Management

Activities in a project typically require the use of resources such as people, material, equipment and working capital. The schedule for the activities that we had calculated in the previous module assumes that adequate resources are available as and when required. However, in practice often adequate resources may not be available as required and the schedule may have to be modified. There are two types of problems when resource requirements are considered. One is the Resource Smoothing Problem and the other is the Resource Limitation problem. In the first one, i.e. the Resource Smoothing Problem, although the resources are available as and when required, we would want to find a schedule that “smoothes” the use of resources without delaying the project completion time. Critical Chain Project Management (CCPM) is the next topic dealt with in this module. CCPM has not gained universal acceptance although it is being used by some organizations with positive results. CCPM places a lot of emphasis on aggressive estimation of activity durations and provides for buffers to take care of some delays. With Risk Management, we first define what risk is and then discuss the risk management process including risk identification, risk assessment and various ways of reducing exposure to risk. Risk monitoring and control including change control process are also covered. Finally, the Program Evaluation and Review Technique (PERT) including a simulation approach to finding the distribution of the project completion time is covered as the last topic in this module. As in the previous modules, towards the end of this module, we present some practical aspects pertaining to the concepts covered. This again is done through a Q & A format with Mr. Prashun Dutta, Advisor - Gaiga Smart Cities

Resource Scheduling11:09

Critical Chain Project Management5:19

Risk Management15:30

Programme Evalution and Review Technique (PERT) and Simulation9:12

(Optional Learning) Interview with Prashun Dutta, Gaiga Smart Cities7:30

与讲师见面

M Rammohan Rao
Professor Emeritus
Operations Management

[MUSIC]

In this session, we will look at the qualitative aspects of risk management.

And in the next module, we'll get into what is called PERT Simulation,

which is an extension of the critical part matter.

First, some definitions and then we will look at some of the benefits of being

prior to in terms of risk management processes.

What is risk?

Risk is an uncertain event that if it occurs it can be beneficial or

it can be adverse.

We always think of risk in terms of adverse effect.

But if it is beneficial to us we would not mind the risky event happening.

Essentially, you can not avoid all this and you may not even be able to

predict all the risky events that make up and when they make up.

The risk management process starts with identifying the type of risky events

that are likely to occur.

And assisting them in terms of the impact that they may have

on the project in case the risky event occurs.

You need to plan ahead your response in case the risky event occurs.

You have to constantly monitor the environment to find out if the risky event

is likely to occur.

You must have a change management process,

which is essentially in order to understand how the risk can be handled.

The main idea behind the risk management process is that if we are able to

proactively think through before the risky event occurs,

you'll be able to manage them better.

And the risky event occurs, you're likely to be under pressure and

trying to decide what should be done, will be difficult.

Unless you have earlier considered all possible responses and

arrived at the best possible course of action.

You have to consider the likely impact of the risky event and

how it may be reduced by your response.

You should also look at possible actions before the risky event occurs so

that it can be made less likely to happen.

You must, however,

be aware that some risk will happen in spite of all the precautions you take.

The first step in the risk management process is risk identification.

You have to do an analysis of the project to understand the different

sources of risk.

Then, you have to assess the severity of impact of the risk event in terms of cost,

completion date of the project, and the quality of the output.

You then have to arrive at the desirable response in case the risky event occurs.

You also have to arrive at an implementable strategy

to adjust the plans.

As the project progresses, new risks may crop up, and

you have to decide upon the course of action before the risky event happens.

Next, we will look at the process of risk identification.

You first generate a list of possible risks by brainstorming

with those involved in the project, and individuals who are knowledgeable.

During the process of brainstorming, you should not criticize any of the solutions.

Even though the risky event identified is highly unlikely to occur.

Risk identification is best done through what is called risk breakdown structure.

You need to look at the profile of the project.

Not only in terms of technical and external factors but

also in terms of organization and project management factors.

For instance, on the technical factors,

you need to know whether the requirements have been well specified or

not, and whether the requirements are likely to be stable or not.

Under external factors, for instance,

you should assess that a liability of the suppliers and subcontractors.

And the organizational factors, for instance, you should

look into whether resources including finance are readily available or not.

In a risk breakdown structure, under each of the factors,

you ask questions that address the various areas of uncertainty.

These questions may be developed from past experience and

should be tailored to the particular project.

The answers to these questions identify the risk involved.

I recall one instance where one of the students are graduating,

joined a software company.

And his first task was to identify the source of risk in an ongoing software

project management.

Believe it or not, he came up with 160 possible sources of risk, of course,

not all of them will have substantial impact and

some of them may have substantial impact, but low probability of occurrence.

But one has to still go through the list and see what action you would want to

take, depending upon the cost benefit analysis that you do.

Next, you look at the impact level.

This may be high but the chances or the risky event happening maybe so

low that you may choose to ignore it.

Furthermore, the cost for taking precautions may be so

high that you may decide not to do anything about it.

For risk assessment, you have to do scenario analysis.

And in this scenario, you look at which risky events are likely to happen.

And the likely impacts separately on the 3 parameters namely,

cost, time and performance.

You have tested the likelihood of your risky event happening.

For assessing the impact separately on cost, time and

performance, you may use a five point scale.

Such as very low impact, low impact, moderate impact, high, and

very high impact.

The likelihood of a risky event is low and the impact of the 3 parameters also low.

You would not worry about that particular risky event.

The likelihood of the risky event happening is high and the impact on one or

more of the parameters is also high.

You have to take appropriate action to reduce the likelihood of this risky event

happening and or reduce impact on the 3 parameters of interest.

In other situations, you have to plan ahead the course of action to be taken if

the risky event does occur.

Probability analysis also may be done if the necessary information is available.

A decision tree approach is possible if the required probabilities can be

estimated.

Assimilation of the project may be done to study the impact of the risky event if and

when a possible course of action is undertaken.

Essentially, for risk management there are three aspects to consider.

First, of course, is identifying the risky event and

the likelihood the risky of it happening.

Then, you have to assess the impact the risky event would have on the budget,

schedule and scope.

You also have to look at the cost of taking remedial action now or,

if possible, the cost of trying to prevent the risk event happening.

Finally, based on this analysis, you have to take some appropriate action.

In many instances, as the project processes, you may have more information,

as to the likelihood of the risky event happening.

A importance is how much in advance you can predict the risky event is most likely

to occur.

If you have adequate to respond to the risky event,

you may then postpone any action until you have more information.

Let us next look at mitigating risk.

You may not be able to emulate the risk completely but

you maybe able to reduce the likelihood of that doers assuming.

Prototyping and testing will reduce the likelihood of something going wrong.

Some lenders may be good at supplying on time while some others may not

be supplying on time.

In that case, you can have a vendor development process.

You constantly interact with vendors and

ensure that the supplies come on time and have good quality.

Essentially, you reduce the risk of the vendors delaying supply and

are the supply of poor quality.

Similarly safety training may be given to mitigate the risk of accidents.

You can also reduce the risk by having two separate teams working on the same

project and see which team comes up with the good product first.

This is, in essence, parallel processing of the same project, or

the sub project, and may be a costly option.

But it may be very important that you turn up a good product in quick time.

Apparently, Microsoft uses this approach for

some modules in the development of the system software.

In R and D projects you may have some projects

that may be undertaken by two teams in parallel.

Apparently this approach is sometimes used in the aircraft industry.

You can transfer to this by having fixed price contracts.

Another possibility is the use of options for transferring risk.

You have to pay a premium to purchase the option.

For instance, supposing a project, you need to purchase some raw material in

future from abroad, and you may be concerned that the rupee may

depreciate a lot by the time you require the raw material.

Here, you can is the rupee, depreciating too much, by purchasing the call option,

to buy the required currency at a predetermined rate,

referred to as the strike rate.

At the time when the payment is due,

if the exchange rate is unfavorable compared to the strike rate,

you would exercise the call option and get the foreign exchange at the strike rate.

If, on the other hand, the exchange rate is favorable compared to the strike rate,

you will simply throw away the option that purchased for a premium.

The use of the call option is like purchasing insurance

against the exchange rate depreciating too much.

You can also share your risk by partnering with other organizations,

this way you will share the risks in terms of the cost but you may have to give up

some profits that may be derived from the output of the project.

For instance, Airbus 8340 was designed and commissioned by a consortium of companies.

You have sharing of risks and build, own, operate, and transfer type of contracts.

These contracts are a way of sharing risk between the government and

the private organizations.

You may also try to avoid risk by using proven technology, although it may be more

expensive then some new technology that has been developed recently.

But you're not sure how reliable it is.

Similarly in my true suppliers from stable regions,

that there are no political upheavals because you're not sure whether you will

in deed get the supply from regions where there is lot of instability.

There may be technical risks also.

These are resources related with scope,

are performance of the product which is an outcome of the project.

This would, of course, depend upon the particular project.

Schedule risk is the risk associated with the schedule.

For instance, if you delay the completion of some activities,

especially the critical activities.

The project may get delayed.

For non-critical activities you have some slack.

During the early part of the project for non-critical activities,

if you start using the slack you may have too many critical activities to manage and

run into difficulty during the latter part of the project

when some of the activities may take more time than the estimated time.

Provides some rough bulletin terms of time and cost to avoid the consequences of

the project getting delayed by the consequences of project over run.

One problem of the is that the people may behave as though the extra time and

the budget are available to them In the normal course of executing the project.

It should be made clear that the extra time and

budget are to be used sparingly, and only when there is no other choice.

One problem that in some other projects in India,

is that the contractor works on a shoestring budget, in the sense that he or

she does some work, and expects to be paid immediately so that the funds can be

used for the next phase of the project that is the next set of activities.

But in many organizations that sponsor the project,

payments to the contract can be made only after some measurements are completed

to ensure that the work done is as specifications.

In this process, if there's a delay in payment to the contractor,

further work on the project gets delayed.

Finally, is you understand that they will always have some risk in the project.

And you have to retain that risk.

So your contingency plan is important as mentioned earlier.

In order to monitor and control the risk,

you need to establish and change management system.

Before a risky event occurs, you have to assign the responsibility to one or

more persons to take the necessary actions when the risky event actually happens.

You need to document this and those involved in the project should be aware

of their as well as others responsibilities.

Risk monitoring and control starts with the risk response matrix.

In the first column of this matrix, you have all the risky events identified.

In the second column, you identify the possible immediate response.

The contingency plan is recorded in the third column.

The fourth column identifies the trigger that would escalate the problem to

a higher authority.

The last column gives the name of the person responsible to

handle the risky event when it happens.

A change control process is essential to control and communicate the changes.

The sources of changes, including the project scope changes,

improvement changes, etc., should be identified and recorded.

A scope change may be difficult to accept and manage.

This is often referred to as scope creep.

The customer may want some changes in scope.

Before accepting a scope change,

a thorough analysis of the implications of accepting the change should be done.

Important implications,

especially with regard to the time of completion of the project.

And the cause should be communicated to the client.

Sometimes some negotiations maybe required before the scope changes accepted.

An individual wanting some change should submit a request

which is to be reviewed by an authorized person perhaps the project manager.

If the request is not accepted, the person who will requested the change would be

informed of the reasons for not accepting the change.

If the request is accepted, appropriate action needs to be initiated.

The project plan should be updated and communicated to all for information and

necessary action if any, while it is desirable to keep the changes to

a minimum, sometimes it may be desirable or even essential to make the changes.

In this module, we have looked at various aspects of risk management.

Sometimes it may be desirable not to give only one possible project completion time,

but instead arrive at various possible project completion times and

their associated probabilities.

In the next module, we'll see how simulation with program

evaluation review technique, also called PERT,

may be used to identify the distribution of project completion time.

[MUSIC]

探索我们的目录

免费加入并获得个性化推荐、更新和优惠。

Coursera 致力于普及全世界最好的教育，它与全球一流大学和机构合作提供在线课程。

© 2018 Coursera Inc. 保留所有权利。

通过 App Store 下载

通过 Google Play 获取