CS615 - Software Project Management - Lecture Handout 40

User Rating:  / 0
PoorBest 

Related Content: CS615 - VU Lectures, Handouts, PPT Slides, Assignments, Quizzes, Papers & Books of Software Project Management

Risk and Change Management

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?
    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.

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.

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.

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.

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 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.

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.

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:

  1. Risk identification
  2. Risk analysis
  3. Risk mitigation

Figure 1: Risk Management Process

Risk Management Process