ZeePedia

Risk & Change Management Concepts

<< Risk and Change Management: Risk Management Concepts
Risk Management Process >>
img
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
img
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
img
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
img
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.
i.
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
img
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
img
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
Risk
Risk
Identification
Analysis
Mitigation
Risk Probability
Risk Avoidance
Risk Impact
Risk Monitoring
Contingency
Risk Factor
Planning
337
Table of Contents:
  1. Introduction & Fundamentals
  2. Goals of Project management
  3. Project Dimensions, Software Development Lifecycle
  4. Cost Management, Project vs. Program Management, Project Success
  5. Project Management’s nine Knowledge Areas
  6. Team leader, Project Organization, Organizational structure
  7. Project Execution Fundamentals Tracking
  8. Organizational Issues and Project Management
  9. Managing Processes: Project Plan, Managing Quality, Project Execution, Project Initiation
  10. Project Execution: Product Implementation, Project Closedown
  11. Problems in Software Projects, Process- related Problems
  12. Product-related Problems, Technology-related problems
  13. Requirements Management, Requirements analysis
  14. Requirements Elicitation for Software
  15. The Software Requirements Specification
  16. Attributes of Software Design, Key Features of Design
  17. Software Configuration Management Vs Software Maintenance
  18. Quality Assurance Management, Quality Factors
  19. Software Quality Assurance Activities
  20. Software Process, PM Process Groups, Links, PM Phase interactions
  21. Initiating Process: Inputs, Outputs, Tools and Techniques
  22. Planning Process Tasks, Executing Process Tasks, Controlling Process Tasks
  23. Project Planning Objectives, Primary Planning Steps
  24. Tools and Techniques for SDP, Outputs from SDP, SDP Execution
  25. PLANNING: Elements of SDP
  26. Life cycle Models: Spiral Model, Statement of Requirement, Data Item Descriptions
  27. Organizational Systems
  28. ORGANIZATIONAL PLANNING, Organizational Management Tools
  29. Estimation - Concepts
  30. Decomposition Techniques, Estimation – Tools
  31. Estimation – Tools
  32. Work Breakdown Structure
  33. WBS- A Mandatory Management Tool
  34. Characteristics of a High-Quality WBS
  35. Work Breakdown Structure (WBS)
  36. WBS- Major Steps, WBS Implementation, high level WBS tasks
  37. Schedule: Scheduling Fundamentals
  38. Scheduling Tools: GANTT CHARTS, PERT, CPM
  39. Risk and Change Management: Risk Management Concepts
  40. Risk & Change Management Concepts
  41. Risk Management Process
  42. Quality Concept, Producing quality software, Quality Control
  43. Managing Tasks in Microsoft Project 2000
  44. Commissioning & Migration