MBA management


The word risk originates from the Italian term risicare. Risicare means to dare. It is a science based on theory of probability. The risk is understood as the possibility of loss. Risk is identified, its possibility of occurrence is expressed in probability, and consequence of the risk is measured in loss.

Peter Drucker says, “while it is futile to try to eliminate risk, it is essential that the risks taken are the right risks.”

The monetary impact of the loss is a quantitative measure of risk impact. The risk is perceived as high or low in terms of its exposure, defined as the product of the probability of its occurrence multiplied by the potential loss.

Risk is handled by different people in different ways based on their preferences and attitude towards risk. People differ in their tolerance to risk. The difference occurs due to the different utility functions on which exposure is measured.

A person’s utility function reveals whether he or she is risk adverse, risk seeking, or risk neutral. Risk is managed through strategies. The strategies are of two types, one ‘reactive’ and the other ‘proactive’. Reactive strategies are the ones that are applied when risk occurs, whereas proactive strategies are the ones that are applied in anticipation of risk. Like any other business function risk also needs to be managed properly through a process called risk management.

Risk Management(CRM)

RM is a process made up of the following steps: risk identification, risk analysis, risk assessment, risk planning, risk monitoring and risk mitigation. RM resolves the risk scenario through these steps.

Risk Identification   Identifies and enumerates the risks
Risk Analysis   Enables an understanding of the occurrence, its impact and the timing of occurrence.
Risk Assessment   Quantified in terms of the probability of occurrence, loss on occurrence, and the risk exposure.
Risk Planning for resolution   Provides approach in terms or effective steps in dealing with risk in terms of strategies and execution.
Risk Monitoring   Helps to identify and measure the occurrence, impact and implications of risk till it is resolved satisfactorily.
Risk Mitigation   Helps to meet the challenges of risk occurrence in effective implementation of specific plan of RM.

RM converts a threating risk scenario into an acceptable risk scenario, controlling risk through the stages of its likely occurrence to its satisfactory resolution. Risk scenario is perceived with reference to goals and objectives to be achieved. Hence, a clear definition of the goal is essential in RM. The risk is seen in the process of goal achievement when it is riddled with uncertainty, lack of knowledge about the future, and loss that might occur if risk is not resolved properly.

RM is a scientific process based on the application of game theory, decision theory, probability theory and utility theory. Risk scenarios may emerge out of management challenges and technical challenges in achieving specific goals and objectives.

RM must be performed regularly throughout the achievement life cycle. Risks are dynamic, as they change over time. RM should not be regarded as an activity integral to the main process of achieving specific goals and objectives. Risk and its management should not be treated as an activity outside the main process of achievement. Risk is managed best when RM is implemented as a mainstream function in the software development and goal achievement process.

Introduction to Software Risk(SR)

Software risk is a measure of the probability of its occurrence and the loss due to its exposure. The SR affects the process of development, project development, and software product itself. The SR is possible in software process, project and product management.

Software risk arises due to uncertainties in management and the ineffectiveness of technical procedures.

Types of Risks

Software process Risks include managerial and technical procedures required to be undertaken for software development. Managerial processes include activities like planning, staffing, monitoring, quality assurance and control. In technical procedures, software engineering activities such as requirement analysis, design, code and test are included. Process risk occurs due to uncertainties involved in assessing, estimating various inputs to the software process. There are uncertainties in resource availability, confirmed quality specifications from the customer and so on. In technical procedures, uncertainty may be on account of the customer not being able to confirm in precise terms the software requirement specifications, or uncertainty about platform, its capability and configuration and so on. Such uncertainties affect quality, efforts, cost and schedule enhancing the business risk.

Software Project Risk arises on account of operational, organizational and contractual software development factors. This risk occurs due to conditions and constraints about resources, relationship with vendors and contractors unreliable vendors and lack of organizational support. Funding is the significant project risk the management has to face. It occurs due to initial budgeting constraints and unreliable customer payments.

Software Project Risk mainly concerns the quality characteristics of the software product. This originates from the conditions such as unstable requirement specifications, not being able to meet the design specifications affecting software performance and uncertain test specifications. In view of the software product risk, there is a risk of losing the business and facing strained customer relations.

Though these risks are identified and put into three classes, they have a close relationship with each other. For example, if there is an uncertainty in requirement specification, it gives rise to software product risk of not meeting the customer acceptance standards. Further, it affects the resource estimation, as requirements are not known completely in clear terms giving rise to project management risk. Once there is uncertainty about requirement, there is also uncertainty about the process of development affecting the schedule. The risk of not able to deliver the product on time sets in.

The nature of risk and its class are, however, fixed, and they are stated below:

• Technology Risks (Unpredictable)   These risks fall in the domain of hardware, software and network communication technology, which are subject to continuous improvement and may lead to obsolescence.
• People Risks (Known)   These risks are associated with persons in the teams and risk concerns availability, capability, skills, maturity and so on.
• Organizational Risks (Predictable)   These are in the area of development organization and customer organization. The environment in both the organizations is a matter of concern.
• Requirement Risks (Known)   This is about clarity, completeness and confirmation of the requirement by the end users and customer. It is about the volatility of the requirement.
• Estimation Risks (Known)   Not being able to judge in precise terms the component of the software, reusability and system characteristics affecting the size, effort and schedule.

Predictable risks are the ones that can be identified based on past experience in development. The examples are people, organizational and technology risks.

The unpredictable risks are the ones that appear suddenly and out of the blue. They are technology, obsolescence, business and management change.

The objective of viewing the risk by nature, type or category is to identify all of them and deal with them effectively. Experience reveals that risk incidence is spread over the entire life cycle of software development. Due to the complex nature of software risks operating throughout the life cycle of development, Software Risk Management (SRM) becomes an essential and integral component of the software development.

Software Risk Management(SRM)

SRM is a process built in five steps. The steps are:

Identify Risks -> Analyze -> Plan Risk Resolution Strategy -> Track Monitor Risks -> Mitigate Risks

Identify Risks

Risk identification is a process to handle certain inputs that produce a set of outputs, namely, a list of risks, their types and its importance in the context of the software proposed to be developed.

The inputs are the degree of uncertainty on a number of features such as requirements, technology, people allocation, insufficient domain and application knowledge, concerns about lack of skills and know-how, and issues regarding the technical and commercial aspects of the software development .These inputs help to identify the risks and their nature. In order to ensure that risk identification is complete, organizations develop checklists that are used to identify the risks. Mature organizations also maintain a risk database if they handle a number of small and large software development projects. The checklists, risk database, and risk assessment forms are the facilitation in the identification process. The inputs mentioned so far are external, arising out of software development proposal. The other set of inputs that help to identify and to some extent assess the risk are proposed resource allocations based on the software requirement specifications.

The risk identification process begins with an assessment using the checklists. The assessment is best done when it is conducted as a participatory activity. The risk analyst conducts interviews with experienced personnel who have worked earlier in similar software projects. Periodic meetings are conducted with persons to identify the risk. It should be noted that risk identification is not a onetime task undertaken at the beginning of the life cycle; it is an exercise that continues till the software is delivered satisfactorily. Some risks, which were not perceived in first review, may emerge later in the life cycle.

Once the risk is identified, its attributes, that is, the probability of occurrence and the loss arising out of risk are determined. Both these attributes are based on the subjective judgment of the concerned people. This judgment may be supported by risk database and the experience of people in the field. The loss may not be monetary, but could emerge in the form of adverse effects on software quality, which includes features like flexibility, maintainability, portability, reusability and so on.

The risk identification process not only identifies the risk but also determines attributes and communicates further to people in the team. The key to successful identification process is the use of checklists. One can us safely the SEI Software Risk Taxonomy as shown in the following paragraph. The taxonomy is divided into three parts, namely, product engineering, development environment and program constraints. Further, each part is subdivided into components. Each of these components is discussed for identification of an attribute determination. This exercise gives rise to a list of risk statements with contextual information and details of identification. For example, the risk analyst will discuss stability of requirements, suitability of development process and personnel in terms of availability, capability and maturity.

Product Engineering

1. Requirements a. Stability
b. completeness
c. Clarity
d. Validity
e. Feasibility
F Precedent
G Scale

2. Design

a. Functionality
b. Difficulty
c. Performance
e. Testability
f. Hardware constraints
g. Non developmental software

3. Code and Unit Test

a. Feasibility
b. Unit test
c. Coding/Implementation

4. Integration and Test

a. Environment
b. Product
c. System

5. Engineering Specialties

a. Maintainability
b. Reliability
c. Safety
d. Security
e. Human factors
f. Specifications

Development Environment

1. Development Process
a. Formality
b. Suitability
c. Process control
d. Familiarity
e. Product control

2. Development System
a. Capacity
b. Suitability
c. Usability
d Familiarity
e. Reliability
f. System support
g. Deliverability

3. Management Process
a. Planning
b Project organization
c. Management experience
d. Project Interfaces

4. Management Methods

a. Monitoring
b. Personnel management
c. Quality assurance
d. Configuration management

5. Work Environment

a. Quality attitude
b. Co-operation
c. Communication
d. Morale

Program Constraints

1. Resources
a. Schedule
b. Staff
c. Budget
d. Facilities

2. Contract
a. Type of contract
b. Restrictions
c. Dependencies

3. Project Interfaces
a. Customer
b. Associate contractors
c. Subcontractor
e. Corporate Management
f. Vendors
g. Statutory Bodies

Analyze and Assess Risk

Risk Analysis b (RA) is a process that defines activities and methods to estimate and evaluate risk. In estimation, the probability of occurrence is estimated and its consequence. In evaluation, the risk options against certain criteria are discussed.

The risk analysis process begin with list of risks obtained from the earlier process of risk identification. Each risk from this list is taken for estimation and evaluation. To act on this step, the organization needs an evaluation criteria and the risk database. First, the probability and consequence is estimated and then the risk Exposure (RE) determined.

The risk analysis process begins with list of risks obtained from the earlier process of risk identification. Each risk from this list is taken for estimation and evaluation. To act on this step, the organization needs an evaluation criteria and the risk database. First, the probability and consequence is estimated and then the Risk Exposure (RE) determined.

Risk Exposure = Probability X Loss

For example, the customer environment suggests that the stability of requirement specification is very low.

This is also the experience of the project team with this particular customer. Hence, identified risk, a critical requirement may be missing or may change radically .Based on the risk database and customer experience, probability is 0.50. The loss due to this risk occurrence is a waste of three man-month effort, amounting to a loss of Rs. 1.5 lakhs. Hence, risk exposure is

RE = 0.50 X 1.5 = 0.75 lakhs

Based on this criterion of risk exposure, it is determined whether it is low, Moderate or high and considered against the time frame as short, medium and long term. Both these attributes are evaluated on common criteria known as risk severity. The following table shows the index of risk severity.

Timeframe       Risk exposure    
    Low   Moderate   High
Short   5   2   [1]
Medium   [7]   4   3
Long   9   8   6

Based on the risk severity criteria, the risks are prioritized for action Index “1” for a short term time frame and high risk exposure is considered the highest risk severity. Index ‘9’ is termed as the lowest because of the low exposure and long term time frame. When you evaluate all risks by these criteria, they come under a common platform, irrespective of whether the risk is of project, product or process.

At the end of risk analysis, you get a prioritized risk list with probability, risk exposure, and risk severity. This forms the basis for constructing a risk action plan for resolution.

Plan Risk Resolution Strategy

The risk plan proposes various actions to deal with the risks identified and analyzed in the earlier processes. The output of the process is the Risk Action Plan (RAP).

RAP takes as input the Prioritized Risk List based on risk severity, and determines resolution strategies for each one on the list. The risk resolution strategies suggested by Ellan H. Hall a researcher and author of the book on Risk management are:

• Risk Acceptance
• Risk Protection
• Risk Reduction
• Risk Transfer
• Risk Reserves
• Risk Avoidance
• Risk Research

Risk Acceptance: this strategy is chosen when you have no choice but to live with risk and face the consequences.

Risk Protection: This strategy is chosen when there is a possibility to reduce the probability of occurrence and the consequential loss. For example, you may hire a temporary consultant to provide domain knowledge support or the skills required to reduce process delay and product risk.

Risk Reduction: This strategy is chosen over and above risk protection. Based on a cost benefit analysis, the organization may take such actions that risk incidence is reduced, giving rise to major reduction in the consequential loss.

Risk Transfer: This strategy is chosen when it is possible to transfer the risk to somebody else. You may choose outstanding, subcontracting, buying a resource or tool, taking insurance as a risk transfer strategy.

Risk Avoidance: This strategy is chosen to eliminate risk altogether or by pass it altogether. This strategy is chosen when you are in lose lose situation. You will deal with the sources of risk to avoid or eliminate them by management actions.

Risk Research: This strategy is chosen to reduce the risk by seeking more information about it for better evaluation, and also to deal with it effectively. The firm may, for example, conduct a proof of concept exercise or experiment to reduce the volatility of the requirement specifications. Another example is that the organization may seek more information from genuine resources on new products or the introduction of new technology. Based on this information, the index of severity will be reduced, and the action plan changed accordingly.

The process has an input on risk status from the project team and from various MIS reports on software development addressing the issues of schedule, cost, delivery and quality. Thee output of the tracking process is evaluation of exposure, severity and triggers to act where necessary.

For example, risk of delay in delivery is a high severity risk. Assume that over 100 activities are involved which affects the delivery. So threshold for these activities is a delay of 15% in completion. If delay exceeds 15% it should be reported through MIS for action.

It is important to note that risk occurrence is a possibility at any time. The original estimates and forecasts on occurrence, exposure, timing may change during the life cycle, and tracking risk becomes an essential activity in risk management system, and has to be made integrated activity in software development plan.

Resolve Risk

Risk resolution process is defined where risk action plan forms the basis for resolving the risk using resolution tools and techniques and risk action plan forms the basis for resolving the risk using resolution tools and techniques and risk database. The objective of the process is to reduce the risk to level of acceptable risk. The output of the risk resolution process is list of acceptable Risk, Reduced rework and corrective actions.

Risk resolution activities are:

• Act on the trigger.
• Execute the risk action plan.
• Monitor the action plan and assess the new risk scenario.
• Control the risk exposure through action, and/or action on deviation.

The skills required to resolve risk are creatively and collaboration. Effective implementation of risk action plan calls for generation of new and innovative ideas. This calls for creativity in the project tam. Further, the risk action plan implementation is not straight linear action process by an individual. It is a collaborative process, and not a process implementation in isolation. The fundamental risk resolution strategy is to reduce uncertainty, gain additional knowledge and draw upon the experience of others from internal and external sources.

Resolution of risk is not a structured method but a process where creatively and collaboration of team members are key success factors.

Risk Mitigation through RMMM plan

SRM handles each risk based on its severity and suggests resolution strategy. Organization needs a SRM plan for all identified to track, measure, monitor and trigger action to contain the risk impact. This is known as Risk Mitigation, Monitoring and Management (RMMM) plan.

Risk Mitigation Planning

Risk mitigation or reducing the impact of risk is done through an RMMM plan. An RMMM plan deals with mitigation, monitoring and management of risks in a systematic manner. The steps in an RMMM plan are as under.

• Prepare a prioritized risk list based on risk exposure and its severity index
• Determine risk resolution strategy for each risk
• Design an action plan based on resolution strategy to deal with risk
• Institute a monitoring plan through systematic review , and MIS reports on risks integrated into software development MIS reports
• Take corrective measures to control the impact

Preparing for RMMM plan

Software projects are risky for various reasons. The objective of the analysis is to identify the risks and assess them to evolve risk management strategies. The business proposal should consider calculated risks. Calculated risk is the one that can be guarded, monitored and controlled. If there are risks to be managed that are critical to the business, one may think of educating the customer and then proceeding. Alternatively, don’t bid for the project.

• Software risks have two characteristics.

• Uncertainty: The event does not happen as expected or planned, affecting performance parameters of the project.

• Loss: If the risk becomes a reality, it would result in a financial loss to the company or to the customer.

(a) Risk Item Checklist having uncertainty and loss as characteristics:

• Project Size
If the size of the project as estimated through FPA is large both in content and duration, chances of deviating from the plan are high.

• Project Complexity
Complexity is a relative factor. A project may be a complex one depending on the environment and the organization’s experience ill handling such projects.

• Technology Risk

• New and whether proven

• Organizational experience in handling such technology

• Availability and the extent of support from technology vendors

• Upward technology support

• Customer environment risk

• Technology exposure, handling

• People characteristics affecting RDD

• Fitting of the solution in the current environment

• Level of understanding of the solution and ability to handle the change in solution

• Availability of key personnel and other resources as constraints

• Professional management of business operations

• Business impact risks

The business gains proposed in the project would depend on other factors outside the project scope.

• Precision and level of implementation of the solution

• Falling in line of other systems considered a prerequisite to the successful implementation of the project

• Level of end users’ understanding of the system and solution

• Management participation

(b) Risk estimation

Risk is estimation on two accounts: one, on the probability of occurrence and second, the consequences of the risk, should it occur.

Risk estimation considers the following:

• Scale on which risk could be perceived
• Consequences of the risk
• Importance of the risk
• Degree of accuracy

A risk estimation table is constructed taking two pivotal points

1. Consequences of erroneous system (CES)

2. Consequences of desired results not achieved (CDR)

CES will affect the performance of the systems, but CDR will affect the cost and delivery schedule. The impact of consequences could be described in terms of financial loss.

• Loss
• No Loss No Profit
• Marginal Loss of Profit
• Negligible Loss in Profit

Process of risk estimation

The process is simple and needs to be executed collectively using experienced resources within the organization. The steps are as follows:

(1) Identify the risks associated with each item on check list, namely,
• Project size
• Project complexity
• Technology risk
• Business impact risk

(2) Estimate the probability of its occurrence in percentage. The approach for estimation would be to determine the most likely probability.

(3) Give the impact value on the following basis.

Loss: 5 (non achievement of business gains)

No loss no profit: 4 (partial achievement of business gains) Substantial loss of profit; 3 (some achievement of business gains)

Marginal loss of profit: 2 (budget overrun through resource management)

Negligible loss of profit: 1 (can be sustained through resource management)

(4) Sort the risk in order of highest probability of occurrence and high impact. The management then has to decide on what is the cutoff probability, above which risk is labeled high, and blow which it will be termed low. The cutoff essentially depends on the risk bearing capacity of the management.

(5) Prepare a Risk Mitigation, Monitoring and Management plan (RMMM) for all risks above cutoff line.

(6) Risk Mitigation, Monitoring and Management Plan (RMMM).

• Risk mitigation strategies
• Risk elimination
• Look for a way to work around the problem
• Look for other options
• Work on resource and customer for improvement
• Revisit certain issues and sort out
• Hire external resources
• Work at customer end to eliminate risk factors
• Reconsider the utility of deliverables
• Risk Reduction
• Training
• Purchase of tools, middle ware
• Educating the customer
• Rescheduling the skill set
• Revisiting architecture to reduce size; complexity, impact, etc.
• Phasing out project development and implementation plan
• Solicit vendor involvement
• Visit similar project site for experience learning
• Friendly consultations
• Risk monitoring
• Introduce a checklist for progressive assessment of risk
• Ensure from time to time that the risk perceived is at the same level as before
• Check whether the impact on deliverables and performance is above the acceptable level
• Risk handling and management
• Institute within the project MIS, a system to report risk
• Keep a contingency plan ready. Homework on all aspects should have been done
• Schedule meetings with the top management of the customer to handle situations when necessary
• Quick and satisfactory problem/ conflict resolution
• Resource availability
• Skills availability
• Personal problems
• Absentees
• Turnover of personnel
• Rescheduling, Preplanning and obtaining customer acceptance

Case Study

A large construction house engaged in real estate construction business decided to develop Enterprise software (ERP) through its subsidiary Constro Softeck. During the kickoff meeting between the company senior managers and Constro’s project team, the following observations were made.

The correct estimation of construction cost is a key result area as it affects contract pricing and profitability of the business. Cost estimation is required in two parts, material and labor, split by building, floor, and also by class of material such as cement, steel, titles, sanitary ware, electrical, doors and windows, etc. The precision in engineering measurement is most important. These measurements are the basis of material and labor estimation, and its cost. Software module of estimation in ERP should extract engineering measurements from civil engineering drawings and use the company’s standards of material and labor estimation, and its cost. Software module of estimation in ERP should extract engineering measurements from civil engineering drawings and use the company’s standards of material and labor consumption for quantity and cost estimation. The output of such a module will be cost sheets detailing the relevant information for contracting, budgeting, progress monitoring and bill payment. Constro Softeck team has no domain knowledge and is inexperienced in engineering estimation. So far as development technology and methodology is concerned, the team is competent.

Project managers and construction engineers have given the requirements for system development but are not sure about its completeness and correctness. They would like to revisit the requirement specifications when the first cost sheets are received. They have given the present cost sheets developed by them on desktops for the Softeck team to study.

(a) Identify the risk in cost estimation module in terms of product, process, and project.

(b) Analyze and measure the risk in terms of risk exposure.

Choose your best guess probability of risk occurrence and loss thereof. Suggest risk management strategy for each risk.
Copyright © 2015         Home | Contact | Projects | Jobs

Review Questions
  • 1. What do you mean by risk? How do you manage risk?
  • 2. What is software risk? What are its types?
  • 3. Explain the software risk management processes.
  • 4. How will you analyze and assess the risk?
  • 5. What are risk resolution strategies? Explain.
  • 6. What is risk mitigation/ what are the ways in which risk can be minimized?
Copyright © 2015         Home | Contact | Projects | Jobs

Related Topics
Risk Management Keywords
  • Risk Management Notes

  • Risk Management Programs

  • Risk Management Syllabus

  • Risk Management Sample Questions

  • Risk Management Subjects

  • EMBA Risk Management Subjects

  • Risk Management Study Material

  • BBA Risk Management Study Material