Risk & Change Management Concepts

<< Risk and Change Management: Risk Management Concepts

Risk Management Process >>

Software Project Management (CS615)

LECTURE # 40

9. Risk and Change Management

9.1

Fundamentals

What is it?

Change Management is the process by which changes to the Project's scope,

deliverables, timescales or resources are formally defined, evaluated and

approved prior to implementation.

A core aspect of the Project Manager's role is to manage change within the

project successfully. This is achieved by understanding the business and system

drivers requiring the change, documenting the benefits and costs of adopting the

change and formulating a structured plan for implementing the change.

To formally request a change, it is often necessary to complete a Change Form.

The change request details may then be recorded within a Change Register.

Risk Management is the process by which risks to the project (e.g. to the scope,

deliverables, timescales or resources) are formally identified, quantified and

managed during the project.

A project risk may be identified at any stage of the project by completing a Risk

Form and recording the relevant risk details within the Risk Register.

First, risk concerns future happenings. Today and yesterday are beyond active

concern, as we are already reaping what was previously sowed by our past

actions. The question is; can we, therefore, by changing our actions today, create

an opportunity for a different and hopefully better situation for ourselves

tomorrow.

This means, second, that risk involves change, such as in changes of mind,

opinion, actions, or places...

[Third] risk involves choice, and the uncertainty that choice itself entails. Thus

paradoxically, risk, like death and taxes, is one of the few certainties of life.

Who does it?

Everyone involved in the software process managers, software engineers and

customers - participate in risk analysis and management

Why is it important?

332

Software Project Management (CS615)

Think about the Boy Scout motto: "Be prepared" Software is a difficult

undertaking. Lots of things can go wrong, and frankly, many often do. It's for this

reason that being prepared, understanding the risks and taking preventive

measures to avoid or manage them is a key element of good software project

management.

What are the steps?

Recognizing what can go wrong is the first step, called - risk identification. Next,

each risk is analyzed to determine the likelihood that it will occur and the damage

that it will do if it does occur. Once this information is established, risks are

ranked by probability and impact. Finally, a plan is developed to manage those

risks with high probability and high impact.

What is the work product?

A risk mitigation monitoring and management (RMMM) plan or a set of risk

information sheets is produced.

How do I ensure that I've done it right?

The risks that are analyzed and managed should be derived from thorough study

of the people, the product, the process and the project. The RMMM should be

revisited as the project proceeds to ensure that risks are kept up to date.

Contingency plans for risk management should be realistic.

9.2

Risk & Change Management Concepts

Foresight is an excellent management quality that can often be cultivated with

experience. Indeed, in many cases, problems can be anticipated.

In such cases, the manager can plan for the possibility that a problem will occur

by estimating its probability, evaluating its impact, and preparing solutions in

advance. This is referred to as an effective means of combating potential

development problems.

Performing risk analysis means being prepared. It is a form of insurance, the basic

idea being that if a problem occurs, a solution is readily available. Like all

insurance, risk analysis usually comes with a price.

The cost of preparing for the occurrence of a problem is primarily the cost of

having the alternative solution at hand while the problem may or may not occur.

In some cases, the cost may be minimal, the time needed to analyze and document

the solution, and the time to track the problem.

In other cases the cost may be substantial, for example, the price of an alternative

piece of development equipment.

333

Software Project Management (CS615)

In any case, a problem that has been analyzed and resolved ahead of time is far

simpler to resolve than a problem that occurs unexpectedly.

When risk is considered in the context of software engineering, three conceptual

underpinnings are always in evidence:

The future is our concern what risks might cause the software project to go

awry?

Change is our concern -how will changes in customer requirements,

development technologies, target computers, and all other entities connected

to the project affect timeliness and overall success?

Last, we must grapple with choices - what methods and tools should we use,

how many people should be involved, how much emphasis on quality is

"enough"?

Risk analysis and management are a series of steps that help a software team to

understand and manage uncertainty. Many problems can plague a software project

A risk is a potential problem - it might happen, it might not But regardless of the

outcome, it's a really good idea to identify it, assess its probability of occurrence,

estimate its impact, and establish a contingency plan should the problem actually

occur.

Any project can encounter uncertainties in the form of increased costs, schedule

delays, and diminished qualities. Unless tackled, these uncertainties can lead to

major project disasters.

The uncertainties encountered during project execution are the potential project

risks. Every software project has to grapple with the new risks threatening

information security along with the conventional risks, such as hardware failure,

time and cost escalation, defects, or resource crunch.

Risk can be defined as the possibility of loss. Risk arises due to the inability to

achieve objectives within defined cost, schedule, and technical constraints.

Risk has two components:

The possibility of not achieving a particular outcome is one, and

The result of failing to achieve the outcome is the other

The former is the probability of loss, and the latter is the loss. Software project

management deals with managing both these components of risk.

Risk management focuses the project manager's attention on those portions of the

project most likely to cause trouble and compromise participants' win conditions.

334

Software Project Management (CS615)

In other words, risk management is a set of actions that helps the project manager

plan to deal with uncertain occurrences. It is through risk management that project

managers assess risks and manage to reduce risks to an acceptable level.

9.3

Types of Risks

To be able to manage project risks, you must first understand what constitutes, a

risk. All uncertain occurrences are not risks.

Only those occurrences that have an adverse impact on the progress of a project

are risks to the project.

Risk is not a bad thing. Risk is bad only when it results in loss for an organization.

Unless there is a potential for loss, there is no risk.

Moreover, loss can be interpreted as either a bad outcome or a lost opportunity.

The tendency of most project managers is to jump at the statement this is a risk.

However, the desired reaction is to pre-empt all possible outcome and plan for

them. Project risks can be broadly categorized into development process risks and

product risks.

Development Process Risks

The risks encountered during product development are categorized as

development process risks.

These comprise developer errors, natural disasters, disgruntled employees,

and poor management objectives.

Developer errors could be attributed to poor training due to budgetary

constraints and inadequate skills and software tools.

Ergonomic problems, environment problems, and interruptions or distractions

at office also account for developer risks.

Other risks in this category include problems in personnel acquisition and

retention.

Similarly, natural disasters such as flood, cyclone, fire, storm, and snowfall

are also risks to a project.

Disgruntled employees can also become a risk to an organization. For

example, a sacked employee can use password snuffers to gain unauthorized

access. A dismissed person can flood the system with senseless messages. A

335

Software Project Management (CS615)

disgruntled employee can also try to sabotage the project work by destroying

files and programs.

A poorly defined management objective is another development process risk.

If the language in the management objective is ambiguous and not stated

clearly, the risk management program will not function properly.

Narrowly focused and changing objectives that are not updated can also be

counted as risks.

Lack of contingency plans, incomplete cost estimates, and unrealistic

schedules are also potential risks in a project.

Similarly, unrealistic performance standards are also potential risks to the

development process.

Other possible risks include contractual risks, technological risks, and

inadequate documentation of other concurrent projects.

ii.

Product Risks

Product risks crop up in the form of changing requirements during product

development.

Incomplete and unclear requirements are a risk to the product during

development.

Similarly, problems in meeting design specifications can also be categorized

as risk to product development.

Risks could arise if the project deliverables or objectives are not clearly

defined or if technical data is missing.

The possibility of several alternatives at any given time during the project is

also a cause of concern. If errors are not recognized during the design phase,

they could turn into risks for the project.

Similarly, risks could arise due to the size and complexity of the product or

while achieving client acceptance of the product.

Note:

The key idea in risk management is not to wait for a risk to materialize and

become a problem. The objective of risk management is to ensure that for

each perceived risk; you know well in advance how to tackle it.

336

Software Project Management (CS615)

9.4

Risk Management Process

The process of risk management begins during the analysis phase of software

development life cycle. However, the actual process of managing risks continues

throughout the product development phase.

Risk management is a dynamic process because it deals with the activities that are

yet to happen.

Risk management has a two-fold agenda. First, deciding actions for preventing

risks from happening, and second, deciding actions for tackling risks that

materialize.

Therefore, risk management is all about pre-empting a risk, coming up with a plan

for resolving the risk, and finally executing the plan.

Figure 1 displays the steps of the risk management process. Formally, articulated,

risk management process consists of three steps:

4. Risk identification

5. Risk analysis

6. Risk mitigation

Figure 1: Risk Management Process

Risk Management

Risk

Identification

Analysis

Mitigation

Risk Probability

Risk Avoidance

Risk Impact

Risk Monitoring

Contingency

Risk Factor

Planning

337

Table of Contents: