An Analysis of the PROJECT RISK MANAGEMENT at

Systems Domain Bangalore.

Submitted BY

MUDASIR SHAFI
ROLL NO: - 511027525
Under the guidance of

In partial fulfillment of the requirement For the award of the degree Of MBA IN

Project Risk Management

SMU Sikkim Manipal University 12th June 2012

MUDASIR

Table of Contents

Introduction5 The Principles of Risk Management: ....................................................................................... 16

Organizational Context ............................................................................ 16 Stakeholder Involvement .......................................................................... 16 Organizational Objectives ........................................................................ 17 M_o_R Approach .................................................................................... 177 Reporting ................................................................................................. 188 Roles and Responsibilities ........................................................................ 18 Support Structure.................................................................................... 188 Early Warning Indicators ...................................................................... 188 Review Cycle ............................................................................................. 19 Overcoming Barriers to M_o_R ............................................................... 19 Supportive Culture .................................................................................... 19 Continual Improvement ........................................................................... 20
Method: .......................................................................................................................... 200 Establishing the context ................................................................................................... 22 Identification .................................................................................................................... 22 Assessment:...................................................................................................................... 25

Composite Risk Index:.............................................................................. 25 Risk Options: ............................................................................................. 27

Create a risk management plan: ..................................................................................... 411 Implementation: ............................................................................................................. 422 Review and evaluation of the plan: ................................................................................ 422

Limitations: ............................................................................................... 43
Enterprise Risk Management: ........................................................................................ 444 1

MUDASIR

Risk management activities as applied to project management: ..................................... 45

Risk management and business continuity: ............................................ 53

Bow tie diagrams: .......................................................................................................... 544 Seven cardinal rules for the practice of risk communication ......................................... 544

Project Risk Management: Perform Qualitative Risk Analysis ............. 56 Project Risk Management: Perform Quantitative Risk Analysis ........... 57
Reducing Risk and Increasing the Probability of Project Success .......................................... 59 Risk management: IT Software Development Just Isn't Working! ................................. 59

Change Is Inevitable ................................................................................. 60 Picking The Right Process ....................................................................... 61 A Lower Risk Approach - Iterative Development.................................... 64 Key Principles ........................................................................................... 65 Iterative Risk Driven Approach ............................................................... 65 Senior Management Commitment ........................................................... 67 High Level of Communication - Keep Talking!...................................... 67 Highly Skilled Development Team .......................................................... 68 Use Case Driven Approach ...................................................................... 68 Change Control......................................................................................... 69 Visual Modeling - 'A picture is worth a thousand words' ...................... 69 Are You Really Risk Focused?................................................................. 69 Longer Term Business Continuity ........................................................... 71
The Top Five Software Project Risks ...................................................................................... 81

Risk 1: Inherent schedule flaws ............................................................... 81 Risk 2: Requirements Inflation ................................................................ 81 Risk 3: Employee Turnover...................................................................... 82 Risk 4: Specification Breakdown ............................................................. 83 Risk 5: Poor Productivity ......................................................................... 83
2

MUDASIR

On Agile Solutions .................................................................................... 84

Risk Management Process: A Practical and Effective Approach .............................................. 85

Defining "Risk" ........................................................................................ 85 The Risk Management Process ................................................................ 86 Creating a Risk Register or Risk Matrix ................................................. 88 Important Things to Remember ............................................................... 88
Project Risk Management: It's Either Contingency Planning Now or Emergency Relief Later .................................................................................................................................................. 89

The Common Constraints ........................................................................ 90

1. Risk management is applied inconsistently ................................................................. 90 2. Risk management is not prioritized ............................................................................. 90 3. Risk management earns limited buy-in and support .................................................... 91 Project Risk Management Tenet #1: Assess Early and Often ......................................... 91 Project Risk Management Tenet #2: Build It into the Schedule ...................................... 91 Project Risk Management Tenet #3: Communicate and Illustrate Ownership ................ 92 Risk Management Options:...................................................................................................... 92

Common Types of RMIS ........................................................................ 122 Key Vendor Attributes and Differences ................................................. 124 Average RMIS Costs and RMIS Market Drivers: ................................. 126

References................................................................................................ 132

MUDASIR

List of tables 1 2 3 4 5 6 Risk Identification Methods RBS Probability Distribution RBS Levels Check sheet Complaint data

List of Figures: Figure 1 Figure 2 Figure 3 Figure 4 Figure 5 Figure 6 Figure 7 Figure 8 Figure 9 Figure 10 Figure 11 Figure 12 Figure 13 Figure 14 Figure 15 Risk Management Process Impact analysis Risk Check list Risk Analysis High-level process flow Software Projects Waterfall Development Lifecycle Coping with Change Waterfall Risk Profile Risk Profile Comparison Between Iterative and Waterfall Processes Histogram Scatter Diagram Control Charts Trigger for Change Integrated Risk and Opportunity Management

MUDASIR

Introduction:

Risk is defined as a positive or negative effect of uncertainty on objectives. The identification, assessment, and prioritization of risk are therefore considered as risk management. Risk management is adopted widely to maximize the realization of opportunities or to prevent the effect of unfortunate events. Thus risk can be defined as: The effect of uncertainty on objectives (whether positive or negative). Or The chance of something happening that impacts project objectives. A project manager must anticipate and handle risk efficiently by: Identifying potential risks. Initiating proactive measures to avoid risks. Managing consequences effectively, if risks do occur. For this purpose, project managers must follow a methodology or a process for managing risks. You will get more insight into this subject in the subsequent sections.

MUDASIR

The Risk Management Process Projects face many risks. Managing these risks is therefore an integral part of any project management. Risk management helps you to identify and address the risks facing your business and in doing so you achieve your businesses objectives. There is a wide convergence and international consensus on the various elements for risk management process. The risk management process is: Supported by growing range of capable tools and techniques An accepted process worldwide A research base for academics Implemented across many organizations A Risk Management Process describes the steps you need to take to identify, monitor, and control risk. Risk management process helps you: Identify critical and non-critical risks Quantify the impact of the risk Document each risk in depth by completing Risk Forms Log all risks and notify management of their severity Take action to reduce the likelihood of risks occurring Reduce the impact on your business, should risk eventuate Risk management becomes even more significant if your project aims to enter into new business areas such as launching a new service or targeting a new market. In such scenarios, your standard risks are: Emergence of new technologies that make your product redundant. Competition following your suit. As a project manager, you must envisage such risk occurrences and put in place effective measure to thwart them. The best way to manage risks is by using a
6

MUDASIR

Risk Management Process. Most teams are subject to constant risk of meeting their objectives. The key to success lies in how you manage risks, by putting in place a clear Risk Management Process. The risk management method in the context depends on methods, definitions, and goals that vary widely according to various business segments: Project management Security Engineering Industrial processes Financial portfolios Actuarial assessments Public health and safety Generally, a risk management process involves following five phases that are depicted in Figure 1. This Risk management process shows you all the steps you need to take to implement Risk Management in your organization. Using this risk management process to monitor and control risk, you can ensure you meet your team objectives.

MUDASIR

Figure 1: Risk Management Process

1. Risk Identification: Risk Identification is a process of identifying the risks associated with your business activities in a methodical manner. Risk identification starts with the problem source or with the problem itself. So after establishing the context the next step is to identify the potential risks. Analysis of Source: The target of risk management is the internal or external risk sources in the system. The stakeholders in a project, the employees in a company or the weather in the airport may be the best examples for risk sources. Analysis of Problem: Risks are deviation from assumption, it is essential to identify risks related to threats. The best examples are the accident and casualty threat, private information abuse, or money losing threat. The government legislative bodies, shareholders, and customers are few threats with various entities. Culture, industry practice, and compliance depend on the chosen method for identification of risks. There are number of ways by which you can go about identifying risks:
8

MUDASIR

1. Risk identification by Objective-based: The event which prevents you from achieving an objective completely or partially is identified as risk and every project and organizations have these objectives. 2. Risk identification by Scenario-based: The scenarios are usually the ways to achieve an objective or to analyze the interaction of forces. Any scenario that triggers an undesired event is identified as risk. 3. Risk identification by Taxonomy-based: This risk identification is a breakdown of possible risk sources. 4. Risk identification by Common-risk checking: Many industries list out their known risks and share them. Each risk in the list can be checked for application to a particular situation. 5. Risk identification by Risk charting: This risk identification is done by listing Resources at risks and combining the above approaches. In this method of identification you can start with threat and identify the resource that will be affected or you can examine the consequences and then determine the combination of threat and resource. After the risk identification, it becomes essential to assess the risks so that the right actions can be planned for the same. In the case of value of building loss or in the case of probability of an unlikely event occurring, it is easier to arrive at these quantities. But statistical information is not accessible in all kinds of risks that might have occurred in the past, thus project managers are faced with this difficulty in assessing risks. To evaluate the rigorousness of the impact of risk is often difficult for immaterial assets. However, assessment of risk must produce information such that the information can be used by the management in an organization to identify risks and prioritize risk management decisions. There are several theories for quantifying risk attempts. Out of the many different risk formulas that exist, the most accepted formula for quantification of risk is:

Risk = Rate of Occurrence x Impact of the event

MUDASIR

The financial benefits of risk management are independent of the formula used, although they are more dependent on frequency and how the risk assessment is executed. 2. Risk Probability: Assessing the probability of the occurrence of the risk is known as Risk Probability. The first problem in assessing the probability of project risks is the term itself. Probability has an accurate numerical meaning. The best method for assigning probability is measuring the relative frequency or likelihood of occurrence of an event, where the values lie between impossibility (zero) and certainty (one). The uncertainty dimension such as frequency, likelihood or chance is the major component of risk probability. 3. Risk Response: Being prepared on how to respond to the occurrences of risk is called as Risk Response. There are a few things you can do about a response to any risk, and the strategies are: Avoidance of Risk: The risk has to be avoided, do something to remove the risk. For example use another supplier. Avoiding risks also means loss in the potential gain for the organizations that retain or accept the risks which have been allowed. Possibility of earning profits is also avoided by not entering a business that may avoid the risk loss. Transfer of Risk: Risk has to be transferred, someone will be responsible. Possibly a vendor will be made responsible for a particularly risky part of project, a third party by outsourcing or an insurance company. The original risks are likely to still revert to the first party if the insurance company or contractor goes bankrupt or end-up in court. So practitioners and scholars alike, the insurance contract purchased is often called as a risk transfer Mitigation of Risk: The risk has to be mitigated. You need to take measures to reduce the impact or chance for the risk to occur. If the risks are related to availability of resources, make an agreement and sign-off for the available resource. Prevention of Hazard: Prevention of risks in an emergency refers to the hazard prevention. Elimination of hazards is the most effective stage of hazard prevention. If this is too long, too costly, or impractical then the second stage is mitigation of hazards which prevents hazards from occurring.

10

MUDASIR

Reduction of Risk: This method involves the reduction of likelihood of the loss of occurrence, or the severity of the loss. For example, sprinklers are designed to put out a fire to reduce the risk of loss by fire. This is not suitable because of the greater loss by water damage. By developing and delivering software incrementally, the modern software development methods reduce the risk. Retention of Risk: Involved the acceptance of loss. True self insurance falls in this category. Strategy for small risk is viable in risk retention, in which the cost of against risk insuring is greater over time than the sustained total loss. By default, all risks are not transferred or avoided. This includes risks which are very large can either be feasible or insured. A response in risk planning includes the approach and the strategy addressed by items. The actions include when it should be finished, who is going to do it, and what needs to be done. 1. Risk Measures: This is a process by which an organization initiates measures to effectively deal with the consequences when the risk actually occurs. To understand this in a better way, you can use the two dimensional table given on page 8 wherein the risk is quantified. The impact and the probability of the risk must be evaluated in a simple scale of 1 to 4. The greater the number, the higher is the intensity and impact. Figure # 2 : Impact analysis

11

MUDASIR

If the probability is more, and the impact is less, it is a medium risk. So, if impact is more, and probability is less, it is a high priority risk. Using this method, risk can be quantified to a certain extent. 5. Risk Tracking: Tracking and monitoring the effectiveness of your risk management approach is a very important process. To track risks, project managers should hold regular risk reviews to identify actions which are outstanding, probability of risks, and the impact of risk. This process helps in removing the risks that are no more valid and the new risks can be identified and added. This continuous monitoring of risks to determine any changes in its status, or if they turn into any issues is an essential part of risk management process. Any risk management process also requires running risk reviews regularly to identify and quantify risks. This enables you to track risks that have occurred and build mitigation plans thereby curbing their recurrence to the bare minimum. As a result the process of risk management will be useful in: Improving the decision-making, prioritization, and planning. Helps you in allocating the capital and resources effectively. Anticipating what might have gone wrong and minimizing the amount of firefighting that you may want to do. Preventing disaster and even serious financial loss in a difficult case scenario. Delivering your business plan on time and to budget it significantly improves the probability. Figure#3: Risk Check list

12

MUDASIR

Creating a Risk Management Plan: For applicable and effective controls for managing the risks a risk management plan should be created. Actual loss results, experience, practice will require changes in the plans. You must provide all information that can help in developing different possible decisions to handle the risk. Also, you have to update the risk analysis results and management plans periodically. The two primary reasons for this are: To assess whether the prior selected security controls are still appropriate and efficient. To assess the feasible risk level changes in the business environment in an organization. There are seven steps in the risk management process planning that are explained below: Involve: The risk management planning must involve each individually in the team and request them to contribute at least ten potential risk items. Consequently, the person in the team will assume that the definite project risks are known already, and so it is not needed to be listed. Collate: Collecting the lists of project risks and compiling them into a single list with the duplicates removed is the second step in risk management. This will give you a complete list of possible risks. Asses: Assessing the probability or likelihood, impact or outcome, and detecting each item on the master list is the third step in risk management. By assigning each item on a numerical rating from 1 to 4 or subjective term like low, medium, high this assessment can be done. Group: Breaking up the planning team into different sub-groups and by giving a portion of master list to different sub-group is the fourth step in risk management. The caution signs can be identified by each sub-group for the assigned lists of projects. Thus every caution must be noted down even if it is minor one.

13

MUDASIR

Identify Actions: In this step, sub-groups have to identify feasible preventive actions for the intimidation (or threats) and try to enhance the action points for the opportunities. Create Contingency Plan: The sixth step in risk management is that the subgroups have to create a contingency plan for most of the project risks in such a way that the plan should include the actions where the risk may occur or trigger. The process in the risk management will not be so effective if the contingency plan is time consuming to address the risk. Assign: This is the final pace in planning the risk management process. This talks more about the determination of the owner of each risk in the list. The responsible person for watching out for triggers is the owner. The owner responds suitably if the triggers occur. Then the contingency plan is to be used by respective owners. Mostly, the project managers will be the owners of the risk. Evaluation of Plan and Reviewing Like any other plans, risk management plans need to be evaluated and reviewed on a regular basis. Actual loss results, experience and practice will require changes in the risk management plans. Thus you have to update periodically the risk analysis results and management plans. The two primary reasons for this are: To assess whether the prior selected security controls are still appropriate and efficient. To assess the feasible risk level changes in the business environment in an organization. In ideal risk management, a prioritization process is followed whereby the risks with the greatest loss and the greatest probability of occurring are handled first, and risks with lower probability of occurrence and lower loss are handled in descending order. In practice the process can be very difficult, and balancing between risks with a high probability of occurrence but lower loss versus a risk with high loss but lower probability of occurrence can often be mishandled.
14

MUDASIR

Intangible risk management identifies a new type of a risk that has a 100% probability of occurring but is ignored by the organization due to a lack of identification ability. For example, when deficient knowledge is applied to a situation, a knowledge risk materializes. Relationship risk appears when ineffective collaboration occurs. Process-engagement risk may be an issue when ineffective operational procedures are applied. These risks directly reduce the productivity of knowledge workers, decrease cost effectiveness, profitability, service, quality, reputation, brand value, and earnings quality. Intangible risk management allows risk management to create immediate value from the identification and reduction of risks that reduce productivity. Risk management also faces difficulties allocating resources. This is the idea of opportunity cost. Resources spent on risk management could have been spent on more profitable activities. Again, ideal risk management minimizes spending and minimizes the negative effects of risks.

Objectives of Risk Management: To identify and prioritize potential risk events Help develop risk management strategies and risk management plans Use established risk management methods, tools and techniques to assist in the analysis and reporting of identified risk events Find ways to identify and evaluate risks Develop strategies and plans for lasting risk management.

15

MUDASIR

The Principles of Risk Management: Every project manager and business leader needs to be aware of the practices and principles of effective risk management. Understanding how to identify and treat risks to an organization, a programme or a project can save unnecessary difficulties later on, and will prepare managers and team members for any unavoidable incidences or issues. The OGC M_o_R (Management of Risk) framework identifies twelve principles, which are intended "not ... to be prescriptive but [to] provide supportive guidance to enable organizations to develop their own policies, processes, strategies and plan." Organizational Context A fundamental principle of all generic management methods, including PRINCE2 and MSP as well as M_o_R, is that all organizations are different. Project managers, programme managers and risk managers need to consider the specific context of the organization in order to ensure thorough identification of risks and appropriate risk treatment procedures. The term 'organizational context' encompasses the political, economic, social, technological, legal and environmental backdrop of an organization. Stakeholder Involvement It is easy for a management team to become internalized and forget that stakeholders are also key participants in everyday business procedures, shortterm projects and business-wide change programmes.
16

MUDASIR

Understanding the roles of individual stakeholders and managing stakeholder involvement is crucial to successful. Stakeholders should, as far as is appropriate, be made aware of risks to a project or programme. Within the context and stakeholder involvement, "appropriate" concerns: the identity and role of the stakeholder, the level of influence that the stakeholder has over and outside of the organization, the level of investment that the stakeholder has in the organization, and the type, probability and potential impact of the risk. Organizational Objectives Risks exist only in relation to the activities and objectives of an organization. Rain is a negative risk for a picnic, a positive risk for drought-ridden farmland and a non-risk for the occupants of a submarine. It is imperative that the individual responsible for risk management (whether that is the business leader, the project/programme manager or a specialist risk manager) understands the objectives of the organization, in order to ensure a tailored approach. M_o_R Approach The processes, policies, strategies and plans within the M_o_R framework provide generic guidelines and templates within a particular organization. These guidelines are based on the experience and research of professional risk managers from a wide range of organizations and management backgrounds. Following best practices ensures that individuals involved in managing the risks associated with an organizations activity are able to learn from the mistakes, experiments and lessons of others.
17

MUDASIR

Reporting Accurately and clearly representing data, and the transmission of this data to the appropriate staff members, managers and stakeholders, is crucial to successful risk management. The M_o_R methodology provides standard templates and tested structures for managing the frequency, content and participants of risk communication. Roles and Responsibilities Fundamental to risk management best practice is the clear definition of risk management roles and responsibilities. Individual functions and accountability must be transparent, both within and outside an organization. This is important both in terms of organizational governance, and to ensure that all the necessary responsibilities are covered by appropriate individuals. Support Structure A support structure is the provision within an organization of standardized guidelines, information, training and funding for individuals managing risks that may arise in any specific area or project. This can include a centralized risk management team, a standard risk management approach and best-practice guidelines for reporting and reviewing organizational risks. Early Warning Indicators Risk identification is an essential first step for removing or alleviating risks. In some cases, however, it is not possible to remove risks in advance. Early
18

MUDASIR

warning indicators are pre-defined and quantified triggers that alert individuals responsible for risk management that an identified risk is imminent. This enables the most thorough and prepared approach to handling the situation. Review Cycle Related to the need for early warning indicators is the review cycle. This establishes the regular review of identified risks and ensures that risk managers remain sensitive to new risks, and to the effectiveness of current policies. Overcoming Barriers to M_o_R Any successful strategy requires thoughtful consideration of possible barriers to implementation. Common issues include:

Established roles, responsibilities, accountabilities and ownership. An appropriate budget for embedding approach and carrying out activities. Adequate and accessible training, tools and techniques. Risk management orientation, induction and training processes. Regular assessment of M_o_R approach (including all of the above issues.

Supportive Culture Risk management underpins many different areas and aspects of an organizations activity. A supportive culture is essential for ensuring that everybody with risk management responsibilities feels confident raising, discussing and managing risks.
19

MUDASIR

A supportive risk management culture will also include evaluation and reward of risk management competencies for the appropriate individuals. Continual Improvement In an evolving organization, nothing stands still. An effective risk management policy includes the capacity for re-evaluation and improvement. At a practical level, this will require the nomination of an individual or a group of individuals to the responsibility of ensuring that risk management policies and procedures are up-to-date, as well as the establishment of regular review cycles of the organizations risk management approach. Method: For the most part, these methods consist of the following elements, performed, more or less, in the following order. 1. identify, characterize, and assess threats 2. assess the vulnerability of critical assets to specific threats 3. determine the risk (i.e. the expected consequences of specific types of attacks on specific assets) 4. identify ways to reduce those risks 5. prioritize risk reduction measures based on a strategy The International Organization for Standardization identifies the following principles of risk management: Risk management should:

create value.
20

MUDASIR

be an integral part of organizational processes. be part of decision making. explicitly address uncertainty. be systematic and structured. be based on the best available information. be tailored. take into account human factors. be transparent and inclusive. be dynamic, iterative and responsive to change. be capable of continual improvement and enhancement.

Risk Management Process:

21

MUDASIR

According to the standard ISO 31000 "Risk management -- Principles and guidelines on implementation," the process of risk management consists of several steps as follows: Establishing the context Establishing the context involves: 1. Identification of risk in a selected domain of interest 2. Planning the remainder of the process. 3. Mapping out the following:
o o o

the social scope of risk management the identity and objectives of stakeholders the basis upon which risks will be evaluated, constraints.

4. Defining a framework for the activity and an agenda for identification. 5. Developing an analysis of risks involved in the process. 6. Mitigation of risks using available technological, human and organizational resources.

Identification After establishing the context, the next step in the process of managing risk is to identify potential risks. Risks are about events that, when triggered, cause
22

MUDASIR

problems. Hence, risk identification can start with the source of problems, or with the problem itself.

Source analysis : Risk sources may be internal or external to the system that is the target of risk management.

Examples of risk sources are: stakeholders of a project, employees of a company or the weather over an airport.

Problem analysis : Risks are related to identified threats. For example: the threat of losing money, the threat of abuse of privacy information or the threat of accidents and casualties. The threats may exist with various entities, most important with shareholders, customers and legislative bodies such as the government.

When either source or problem is known, the events that a source may trigger or the events that can lead to a problem can be investigated. For example: stakeholders withdrawing during a project may endanger funding of the project; privacy information may be stolen by employees even within a closed network; lightning striking a Boeing 747 during takeoff may make all people onboard immediate casualties. The chosen method of identifying risks may depend on culture, industry practice and compliance. The identification methods are formed by templates or the development of templates for identifying source, problem or event. Common risk identification methods are:

23

MUDASIR

Objectives-based risk identification : Organizations and project teams have objectives. Any event that may endanger achieving an objective partly or completely is identified as risk. Scenario-based risk identification: In scenario analysis different scenarios are created. The scenarios may be the alternative ways to achieve an objective, or an analysis of the interaction of forces in, for example, a market or battle. Any event that triggers an undesired scenario alternative is identified as risk - see Futures Studies for methodology used by Futurists. Taxonomy-based risk identification: The taxonomy in taxonomy-based risk identification is a breakdown of possible risk sources. Based on the taxonomy and knowledge of best practices, a questionnaire is compiled. The answers to the questions reveal risks. Common-risk checking In several industries lists with known risks are available. Each risk in the list can be checked for application to a particular situation. Risk charting : This method combines the above approaches by listing resources at risk, Threats to those resources Modifying Factors which may increase or decrease the risk and Consequences it is wished to avoid. Creating a matrix under these headings enables a variety of approaches. One can begin with resources and consider the threats they are exposed to and the consequences of each. Alternatively one can start with the threats and examine which resources they would affect, or one can begin with the consequences and determine which combination of threats and resources would be involved to bring them about.

24

MUDASIR

Assessment: Once risks have been identified, they must then be assessed as to their potential severity of loss and to the probability of occurrence. These quantities can be either simple to measure, in the case of the value of a lost building, or impossible to know for sure in the case of the probability of an unlikely event occurring. Therefore, in the assessment process it is critical to make the best educated guesses possible in order to properly prioritize the implementation of the risk management plan. The fundamental difficulty in risk assessment is determining the rate of occurrence since statistical information is not available on all kinds of past incidents. Furthermore, evaluating the severity of the consequences (impact) is often quite difficult for immaterial assets. Asset valuation is another question that needs to be addressed. Thus, best educated opinions and available statistics are the primary sources of information. Nevertheless, risk assessment should produce such information for the management of the organization that the primary risks are easy to understand and that the risk management decisions may be prioritized. Thus, there have been several theories and attempts to quantify risks. Numerous different risk formulae exist, but perhaps the most widely accepted formula for risk quantification is: Rate of occurrence multiplied by the impact of the event equals risk Composite Risk Index: The above formula can also be re-written in terms of a Composite Risk Index, as follows:
25

MUDASIR

Composite Risk Index = Impact of Risk event x Probability of Occurrence The impact of the risk event is assessed on a scale of 0 to 5, where 0 and 5 represent the minimum and maximum possible impact of an occurrence of a risk (usually in terms of financial losses). The probability of occurrence is likewise assessed on a scale from 0 to 5, where 0 represents a zero probability of the risk event actually occurring while 5 represents a 100% probability of occurrence. The Composite Index thus can take values ranging from 0 through 25, and this range is usually arbitrarily divided into three sub-ranges. The overall risk assessment is then Low, Medium or High, depending on the sub-range containing the calculated value of the Composite Index. For instance, the three sub-ranges could be defined as 0 to 8, 9 to 16 and 17 to 25. Note that the probability of risk occurrence is difficult to estimate since the past data on frequencies are not readily available, as mentioned above. Likewise, the impact of the risk is not easy to estimate since it is often difficult to estimate the potential financial loss in the event of risk occurrence. Further, both the above factors can change in magnitude depending on the adequacy of risk avoidance and prevention measures taken and due to changes in the external business environment. Hence it is absolutely necessary to periodically re-assess risks and intensify/relax mitigation measures as necessary.

26

MUDASIR

Risk Options: Risk mitigation measures are usually formulated according to one or more of the following major risk options, which are: 1. Design a new business process with adequate built-in risk control and containment measures from the start. 2. Periodically re-assess risks that are accepted in ongoing processes as a normal feature of business operations and modify mitigation measures. 3. Transfer risks to an external agency (e.g. an insurance company) 4. Avoid risks altogether (e.g. by closing down a particular high-risk business area) Later research has shown that the financial benefits of risk management are less dependent on the formula used but are more dependent on the frequency and how risk assessment is performed. In business it is imperative to be able to present the findings of risk assessments in financial terms. Robert Courtney Jr. (IBM, 1970) proposed a formula for presenting risks in financial terms. The Courtney formula was accepted as the official risk analysis method for the US governmental agencies. The formula proposes calculation of ALE (annualized loss expectancy) and compares the expected loss value to the security control implementation costs (cost-benefit analysis).

27

MUDASIR

Methods for Risk Identification: The first step in determining which risks may affect the project is Risk Identification. Identifying risks present in a project is an art in itself. The chosen method of identifying risks may depend on culture, industry practice, and compliance. For example, brainstorming is a technique that is best accomplished when the approach is open or unstructured. Group members verbally identify risks which provide the opportunity to build on each others ideas. To achieve the desired outcome, it is essential to select participants who are familiar with the topics discussed, provide relevant documentation and a facilitator who knows the risk process to lead the group. A note-taker should be appointed to capture the ideas that are being discussed. A number of Risk Identification methods are given below along with their advantages and disadvantages. As a project manager, you could use any or more of the methods given according to their fitment in the organization. Table # 1: Risk Identification Methods: Detection Method Interviews Advantages Disadvantages

In a face to face meeting Requires lot of time sensitive matters are revealed quicker

Helps to involve people in risk management Brainstorming A lot of results in a short Everyone does not period speak up freely in a group Risks are shared with others constantly It is difficult to plan and get everyone together Costs Consulting Independent view on matters Experts Sensitive information May have expertise not may be disclosed
28

MUDASIR

A hierarchical ly organized depiction Requires lot of time Acquisition cost of the identified project risks arranged by category is called Risk Breakdown Structure. This arrangement of risk items into labeled rows and columns within a table is called Matrix. Risk Matrix is a tool used in the Risk Assessment Process; it helps in determining the severity of the risk of an event. Risk Breakdown Structure is based on the concept of the Work Breakdown Structure. It provides a means for the project manager and risk manager to structure the risks being addressed and/or tracked. The RBS is basically a hierarchically organized depiction of the identified project risks arranged by risk category. Although, many project managers and risk managers might have used some other methods for listing, identifying, assessing, and tracking risks in their projects e.g. spread-sheets, listing, time and again Risk Breakdown Structure has proven to be most useful. It helps you understand the risks completely and therefore enables you to better identify and assess the risks, and get into the depth of each risk, taking it to as many levels of identification as might be required. An example of how Risks are broken down into a matrix structure is given in the table below: Table # 2: RBS Certain Likely Negligible Marginal Critical Catastrophic High High Extreme Extreme Moderate High High Extreme
29

available in the company Study Project Old forgotten risks are Risks that have Documentation often documented already been solved may resurface Insight in the working procedures of a project team Study Shows the state of art Specialist Literature Specialist knowledge and available may be written for solutions academic audience Literature

Risk Breakdown Structure (RBS):

MUDASIR

Possible Unlikely Rare

Low Low Low

Extreme Moderate High Low Moderate Extreme Low Moderate High

The company or organization then calculates up to what levels of Risk they can take with different events. This is done by weighing probability of the occurring against the cost to implement safety and the benefit that can be gained from it. For Example, The risk of being physically hurt may be made up of the hazard of being hit by a car, the risk of having a crane dropped on you and the risk of being caught in a stampede. As you know, each risk has probability and a consequence. Here, the probability of being hit by a car is much more than that of being crushed by a crane or a stampede. However the consequence of being struck by a car is less than that of finding yourself under a crane. The same is depicted in the table below with a few other options as well: Table # 3: Probability Distribution Negligible Marginal Critical Certain Busy market Likely Car Possible Crane Unlikely Stampede Rare Wind storm Risk Breakdown Structure for a Project: The Risk Breakdown Structure for a generic Project is given in Table which explains each and every level of Risk Breakdown Structure with examples. Catastrophic

Volcano

30

MUDASIR

Table # 4: RBS Levels

Risk Analysis: Risk Analysis is a procedure to identify threats and vulnerabilities, analyze them to determine the exposures, and highlight how the impact can be eliminated or reduced. It is based on an ordered approach to thinking through threats, followed by an evaluation of the probability and cost of risks in the event of occurrence. It is usually conducted at the beginning of a project to compare two are more alternative scenarios, action plans, or policies. It usually results in a
31

MUDASIR

plan of action to avoid the risks or minimize their consequences in the event of occurrence. There are two types of Risk Analysis Quantitative and Qualitative Risk Analysis. i) Quantitative Risk Analysis: Quantitative Risk Analysis provides mathematical estimates to allow organizations to understand risk exposure to people, business, the environment, markets or other areas of interest. The main characteristics of this type of analysis are: Mainly two elements are used in this approach: Probability and Likely Loss Result of Probability x Likely Loss is produced It has several drawbacks: - No accurate probability record probability is usually unique to case - Expected loss is hard to establish - Fairly limited use ii) Qualitative Risk Analysis: Qualitative Risk Analysis is an analysis that analyses an organizations risks to threats, which is based on judgment, intuition, and the experience versus assigning real numbers to these possible risks and their potential loss margins. The main features of this methodology are: It is widely used It provides approximate potential loss/impact used No probability record is required Risk level is often an outcome of this analysis. The following diagram illustrates the process for Risk analysis:
32

MUDASIR

Figure 4: Risk Analysis

33

MUDASIR

Risk Assessment: Risk Assessment is a step in project risk management process. Risk assessment is the determination of quantitative or qualitative value of risk related to a concrete circumstance and a recognized threat (also called hazard). Explanation: Risk assessment consists of an intended evaluation of risk in which assumptions and uncertainties are clearly considered and presented. Part of the difficulty of risk management is that measurement of both the quantities in which risk can be assessed potential loss and probability of occurrence can be very difficult to measure. The chance of error in the measurement of these two concepts is large. A risk with a large potential loss and a low probability of occurring is often treated differently from one with a low potential loss and a high possibility of occurring. Mathematically, both are of nearly equal priority in dealing with first, but in practice it can be very difficult to manage when faced with the scarcity of resources, mainly time, in which to conduct the risk management process.

34

MUDASIR

Risk Assessment Cycle: The Risk Assessment Cycle is pictorially represented in the following diagram. Figure 5: Risk Assessment Cycle

35

MUDASIR

The Risk Assessment Cycle has the following seven stages: 1. Set the Limits / Scope of the Analysis While doing Risk Assessment, the Limits/Scope of the Analysis should be set to provide the project manager very clear direction on what should be done. There are many instances where clear direction is lacking or the steps are unnecessarily confusing or ambiguous. 2. Identify Tasks and Hazards Identifying Hazards is critical because if hazards are omitted the associated risks will remain unknown. A task-based approach to identifying hazards has been shown to be very effective and is recommended where applicable. After the hazards are identified you need to determine two things: Is the associated risk minor? If yes, fix it straight away and move on. Is there a Regulation, Advisory Standard, Industry Code of Practice or guidance material associated with this hazard? If yes, the Regulation must be followed. 3. Asses Risk (Initial) Initial Risk Assessment is very important step to find out the initial risks which consume more time. 4. Reduce Risk There is no point in assessing the risks of a project unless one plans to perform risk reduction. The risk reduction effort is always completed even though not every residual risk requires further risk reduction since the risk may already be acceptable. This implies that risk reduction is a necessary part of, and should be included in the overall risk assessment process. 5. Assess Risk (Residual) Assessment of Residual Risks is very important to make the risk assessment process complete. In a way it helps in reducing the risks. 6. Subjective Judgments need to be Accepted
36

MUDASIR

Subjectivity is a necessary part of risk assessment. Even in quantitative risk assessments subjective judgment occurs. However, the subjectivity does not diminish the value or credibility of the risk assessment process and subjective risk assessments do offer value. 7. Document the Results Documenting the Results obtained is very important for the future reference and use. This can be of help in upcoming projects. Potential risk treatments: Once risks have been identified and assessed, all techniques to manage the risk fall into one or more of these four major categories:

Avoidance (eliminate, withdraw from or not become involved) Reduction (optimize - mitigate) Sharing (transfer - outsource or insure) Retention (accept and budget)

Ideal use of these strategies may not be possible. Some of them may involve trade-offs that are not acceptable to the organization or person making the risk management decisions. Another source, from the US Department of Defense, Defense Acquisition University, calls these categories ACAT, for Avoid, Control, Accept, or Transfer. This use of the ACAT acronym is reminiscent of another ACAT (for Acquisition Category) used in US Defense industry procurements, in which Risk Management figures prominently in decision making and planning.

37

MUDASIR

Risk avoidance: Includes not performing an activity that could carry risk. An example would be not buying a property or business in order to not take on the liability that comes with it. Another would be not flying in order to not take the risk that the airplane were to be hijacked. Avoidance may seem the answer to all risks, but avoiding risks also means losing out on the potential gain that accepting (retaining) the risk may have allowed. Not entering a business to avoid the risk of loss also avoids the possibility of earning profits. Hazard Prevention: Hazard prevention refers to the prevention of risks in an emergency. The first and most effective stage of hazard prevention is the elimination of hazards. If this takes too long, is too costly, or is otherwise impractical, the second stage is mitigation. Risk reduction: Risk reduction or "optimization" involves reducing the severity of the loss or the likelihood of the loss from occurring. For example, sprinklers are designed to put out a fire to reduce the risk of loss by fire. This method may cause a greater loss by water damage and therefore may not be suitable. Halon fire suppression systems may mitigate that risk, but the cost may be prohibitive as a strategy. Acknowledging that risks can be positive or negative, optimizing risks means finding a balance between negative risk and the benefit of the operation or activity; and between risk reduction and effort applied. By an offshore drilling
38

MUDASIR

contractor effectively applying HSE Management in its organization, it can optimize risk to achieve levels of residual risk that are tolerable. Modern software development methodologies reduce risk by developing and delivering software incrementally. Early methodologies suffered from the fact that they only delivered software in the final phase of development; any problems encountered in earlier phases meant costly rework and often jeopardized the whole project. By developing in iterations, software projects can limit effort wasted to a single iteration. Outsourcing could be an example of risk reduction if the outsourcer can demonstrate higher capability at managing or reducing risks. For example, a company may outsource only its software development, the manufacturing of hard goods, or customer support needs to another company, while handling the business management itself. This way, the company can concentrate more on business development without having to worry as much about the manufacturing process, managing the development team, or finding a physical location for a call center. Risk sharing: Briefly defined as "sharing with another party the burden of loss or the benefit of gain, from a risk, and the measures to reduce a risk." The term of 'risk transfer' is often used in place of risk sharing in the mistaken belief that you can transfer a risk to a third party through insurance or outsourcing. In practice if the insurance company or contractor go bankrupt or end up in court, the original risk is likely to still revert to the first party. As such
39

MUDASIR

in the terminology of practitioners and scholars alike, the purchase of an insurance contract is often described as a "transfer of risk." However, technically speaking, the buyer of the contract generally retains legal responsibility for the losses "transferred", meaning that insurance may be described more accurately as a post-event compensatory mechanism. For example, a personal injuries insurance policy does not transfer the risk of a car accident to the insurance company. The risk still lies with the policy holder namely the person who has been in the accident. The insurance policy simply provides that if an accident (the event) occurs involving the policy holder then some compensation may be payable to the policy holder that is commensurate to the suffering/damage. Some ways of managing risk fall into multiple categories. Risk retention pools are technically retaining the risk for the group, but spreading it over the whole group involves transfer among individual members of the group. This is different from traditional insurance, in that no premium is exchanged between members of the group up front, but instead losses are assessed to all members of the group. Risk retention: Involves accepting the loss, or benefit of gain, from a risk when it occurs. True self insurance falls in this category. Risk retention is a viable strategy for small risks where the cost of insuring against the risk would be greater over time than the total losses sustained. All risks that are not avoided or transferred are retained by default. This includes risks that are so large or catastrophic that they either cannot be insured against or the premiums would be infeasible. War is an
40

MUDASIR

example since most property and risks are not insured against war, so the loss attributed by war is retained by the insured. Also any amounts of potential loss (risk) over the amount insured is retained risk. This may also be acceptable if the chance of a very large loss is small or if the cost to insure for greater coverage amounts is so great it would hinder the goals of the organization too much. Create a risk management plan: Select appropriate controls or countermeasures to measure each risk. Risk mitigation needs to be approved by the appropriate level of management. For instance, a risk concerning the image of the organization should have top management decision behind it whereas IT management would have the authority to decide on computer virus risks. The risk management plan should propose applicable and effective security controls for managing the risks. For example, an observed high risk of computer viruses could be mitigated by acquiring and implementing antivirus software. A good risk management plan should contain a schedule for control implementation and responsible persons for those actions. According to ISO/IEC 27001, the stage immediately after completion of the risk assessment phase consists of preparing a Risk Treatment Plan, which should document the decisions about how each of the identified risks should be handled. Mitigation of risks often means selection of security controls, which should be documented in a Statement of Applicability, which identifies which particular control objectives and controls from the standard have been selected, and why.
41

MUDASIR

Implementation: Implementation follows all of the planned methods for mitigating the effect of the risks. Purchase insurance policies for the risks that have been decided to be transferred to an insurer, avoid all risks that can be avoided without sacrificing the entity's goals, reduce others, and retain the rest. Review and evaluation of the plan: Initial risk management plans will never be perfect. Practice, experience, and actual loss results will necessitate changes in the plan and contribute information to allow possible different decisions to be made in dealing with the risks being faced. Risk analysis results and management plans should be updated periodically. There are two primary reasons for this: 1. to evaluate whether the previously selected security controls are still applicable and effective, and 2. to evaluate the possible risk level changes in the business environment. For example, information risks are a good example of rapidly changing business environment.

42

MUDASIR

Limitations: If risks are improperly assessed and prioritized, time can be wasted in dealing with risk of losses that are not likely to occur. Spending too much time assessing and managing unlikely risks can divert resources that could be used more profitably. Unlikely events do occur but if the risk is unlikely enough to occur it may be better to simply retain the risk and deal with the result if the loss does in fact occur. Qualitative risk assessment is subjective and lacks consistency. The primary justification for a formal risk assessment process is legal and bureaucratic. Prioritizing the risk management processes too highly could keep an organization from ever completing a project or even getting started. This is especially true if other work is suspended until the risk management process is considered complete. It is also important to keep in mind the distinction between risk and uncertainty. Risk can be measured by impacts x probability. Areas of risk management: As applied to corporate finance, risk management is the technique for measuring, monitoring and controlling the financial or operational risk on a firm's balance sheet. See value at risk. The Basel II framework breaks risks into market risk (price risk), credit risk and operational risk and also specifies methods for calculating capital requirements for each of these components.
43

MUDASIR

Enterprise Enterprise Risk Management:

In enterprise risk management, a risk is defined as a possible event or circumstance that can have negative influences on the enterprise in question. Its impact can be on the very existence, the resources (human and capital), the products and services, or the customers of the enterprise, as well as external impacts on society, markets, or the environment. In a financial institution, enterprise risk management is normally thought of as the combination of credit risk, interest rate risk or asset liability management, market risk, and operational risk. In the more general case, every probable risk can have a pre-formulated plan to deal with its possible consequences (to ensure contingency if the risk becomes a liability). From the information above and the average cost per employee over time, or cost accrual ratio, a project manager can estimate:

the cost associated with the risk if it arises, estimated by multiplying employee costs per unit time by the estimated time lost (cost impact, C where C = cost accrual ratio * S). the probable increase in time associated with a risk (schedule variance due to risk, Rs where Rs = P * S):

44

MUDASIR

Sorting on this value puts the highest risks to the schedule first. This is intended to cause the greatest risks to the project to be attempted first so that risk is minimized as quickly as possible. This is slightly misleading as schedule variances with a large P and small S and vice versa are not equivalent. (The risk of the RMS Titanic sinking vs. the passengers' meals being served at slightly the wrong time).

the probable increase in cost associated with a risk (cost variance due to risk, Rc where Rc = P*C = P*CAR*S = P*S*CAR)
o o

sorting on this value puts the highest risks to the budget first. see concerns about schedule variance as this is a function of it, as illustrated in the equation above.

Risk in a project or process can be due either to Special Cause Variation or Common Cause Variation and requires appropriate treatment. That is to reiterate the concern about extremely cases not being equivalent in the list immediately above. Risk management activities as applied to project management: In project management, risk management includes the following activities:

Planning how risk will be managed in the particular project. Plan should include risk management tasks, responsibilities, activities and budget. Assigning a risk officer - a team member other than a project manager who is responsible for foreseeing potential project problems. Typical characteristic of risk officer is a healthy skepticism.
45

MUDASIR

Maintaining live project risk database. Each risk should have the following attributes: opening date, title, short description, probability and importance. Optionally a risk may have an assigned person responsible for its resolution and a date by which the risk must be resolved. Creating anonymous risk reporting channel. Each team member should have possibility to report risk that he/she foresees in the project. Preparing mitigation plans for risks that are chosen to be mitigated. The purpose of the mitigation plan is to describe how this particular risk will be handled what, when, by who and how will it be done to avoid it or minimize consequences if it becomes a liability. Summarizing planned and faced risks, effectiveness of mitigation activities, and effort spent for the risk management.

Approach Our overall approach for managing risk throughout the project involves the following steps: Identify, Assess, Analyze, Monitor, Mitigate. 1. Identify Risks Throughout the project we will consider risks to the successful completion of the project. We will document those risks in the Risk Management Plan. We will continually consider the project in light of risk and any new risks that come up will be added to the RMP. 2. Assess Risks Each risk will be openly discussed and analyzed. We will assess and document the probability of the risk occurring and the severity of the effect on the project if the risk did occur. We will use the following ratings for this assessment:
46

MUDASIR

Probability: High The risk is more likely to occur. 50% Medium The risk is about as likely to occur as not to occur. 50% Low The risk is more likely not to occur. 50% Severity: High This risk, unmitigated, would result in a complete failure for the project. Medium This risk would have a major impact on the projects schedule, cost, or performance. Low This risk would have a minor impact on the project. 3. Analyze Risks Based on the ratings given to each risk, they will be analyzed to determine what action the project will take. That action could include immediate programmatic changes to ensure that the risk does not occur, development of mitigation plans that could be implemented in the event of the occurrence of the risk, or some other action as appropriate.

4. Monitor Risks Every effort will be made to ensure that the risks do not occur, and if they do occur, that we notice the occurrence of the risk as soon as possible. Early notice can help us limit any possible negative effects of the risk on the project. If progression of the project changes the assessment of the probability or severity of a risk, the risk will be analyzed and the RMP will be updated.
47

MUDASIR

5. Mitigate Risk In the event that a risk does occur, the issue will be analyzed in light of the mitigation plans and action will be taken as appropriate.

48

MUDASIR

Risks categorization:

Programmatic Risks Personnel Availability DESCRIPTION: We have a number of individuals already identified to participate in this project. We are also planning on hiring some additional help. The individuals working on the project could become unavailable at some point in the future. We could also have difficulty finding the specific skills we need within our budget. ANALYSIS: We have a range of expertise available across multiple people. Much of the staff of the project are GSFC civil servants that yields some stability as well. PLAN: We have potential backup individuals that will work together to share knowledge so that no one person is critical to the success of the project. We also intend to thoroughly document work as it proceeds, minimizing the time to bring a new person up to speed if that does become necessary.

49

MUDASIR

Computer Security DESCRIPTION: An unauthorized individual could break into our development machines. ANALYSIS: They could destroy programs or data in a noticeable way, or worse, maliciously alter data such that we produce the wrong answers. PLAN: We will contract with the LTPCF to administer the primary development machine. All security measures recommended by the LTP Security plan will be put in place. The SAs will monitor security recommendations and patch any software as security patches become available. Additionally, logins to the host will be restricted to SSH. Non-GSFC developers will make deliveries of code and data through a one-way anonymous ftp drop box.

Schedule Concerns DESCRIPTION: The schedule and milestones are codified into the contract and are not flexible. ANALYSIS: Because the funding for this project is dependent on producing specific products and meeting specific performance goals, the schedule is critical. Careful thought and negotiation before project initiation resulted in challenging but achievable goals.
50

MUDASIR

PLAN: The PM will manage the project with the schedule and focus management actions toward meeting the scheduled milestones. Regular meetings of key project personnel, at least biweekly, and milestone charts ANALYSIS: Scientific communities are often slow to adopt new research methodologies. Using our software may involve an unpalatable paradigm shift in their research methodologies. We have, however, experience with many agencies and scientists open to new ways to solve problems and new ways of automating manual tasks. PLAN: We will work closely with the customer scientific community throughout the project, making them part of the requirements definition and staying responsive to their needs as we develop the software. We will have annual workshops to work directly with potential customers and ensure that the software is acceptable and useful for the community.

Technical Risks Software Performance DESCRIPTION: The software must meet specific performance goals for certain milestones.
51

MUDASIR

ANALYSIS: We have analyzed the underlying algorithms and believe performance improvement is possible. As we baseline the code, we will be working with the CT project to define specific performance goals. PLAN: We will work with the CT project to define performance goals that are realistic and achievable.

Application Security DESCRIPTION: The software product will include a WWW accessible front-end. This has the potential for network security issues. ANALYSIS: We intend to produce a software application that will be delivered to customers outside of this project and outside of NASA. The reputation of NASA, this project, and the individuals involved depends on producing a secure product. PLAN: We will make security a requirement for the system. We will analyze aspects of the software for security throughout the development life-cycle. We will use security expertise of our staff to the fullest.

52

MUDASIR

Risk management and business continuity: Risk management is simply a practice of systematically selecting cost effective approaches for minimizing the effect of threat realization to the organization. All risks can never be fully avoided or mitigated simply because of financial and practical limitations. Therefore all organizations have to accept some level of residual risks. Whereas risk management tends to be preemptive, business continuity planning (BCP) was invented to deal with the consequences of realized residual risks. The necessity to have BCP in place arises because even very unlikely events will occur if given enough time. Risk management and BCP are often mistakenly seen as rivals or overlapping practices. In fact these processes are so tightly tied together that such separation seems artificial. For example, the risk management process creates important inputs for the BCP (assets, impact assessments, cost estimates etc.). Risk management also proposes applicable controls for the observed risks. Therefore, risk management covers several areas that are vital for the BCP process. However, the BCP process goes beyond risk management's preemptive approach and assumes that the disaster will happen at some point. Risk communication: Risk communication is a complex cross-disciplinary academic field. Problems for risk communicators involve how to reach the intended audience, to make the risk comprehensible and relatable to other risks, how to pay appropriate respect to the audience's values related to the risk, how to predict the audience's response to the communication, etc. A main goal of risk communication is to
53

MUDASIR

improve collective and individual decision making. Risk communication is somewhat related to crisis communication. Bow tie diagrams: A popular solution to the quest to communicate risks and their treatments effectively is to use bow tie diagrams. These have been effective, for example, in a public forum to model perceived risks and communicate precautions, during the planning stage of offshore oil and gas facilities in Scotland. Equally, the technique is used for HAZID (Hazard Identification) workshops of all types, and results in a high level of engagement. For this reason (amongst others) an increasing number of government regulators for major hazard facilities (MHFs), offshore oil & gas, aviation, etc. welcome safety case submissions which use diagrammatic representation of risks at their core. Communication advantages of bow tie diagrams:

Visual illustration of the hazard, its causes, consequences, controls, and how controls fail. The bow tie diagram can be readily understood at all personnel levels. A picture paints a thousand words.

Seven cardinal rules for the practice of risk communication

Accept and involve the public as a legitimate partner. Plan carefully and evaluate your efforts. Listen to the public's specific concerns. Be honest, frank, and open. Coordinate and collaborate with other credible sources.
54

MUDASIR

Meet the needs of the media. Speak clearly and with compassion.

1 Plan Risk Management 2 Identify Risks 3 Perform Qualitative Risk Analysis 4 Perform Quantitative Risk Analysis 5 Plan Risk Responses 6 Monitor and Control Risks Risk refers to future conditions or circumstances that exist outside of the control of the project team that will have an adverse impact on the project if they occur. Whereas an issue is a current problem that must be dealt with, a risk is a potential future problem that has not yet occurred. A reactive project manager tries to resolve issues when they occur. A proactive project manager tries to resolve potential problems before they occur. This is the art of risk management. Not all issues can be seen ahead of time and some potential problem that seems unlikely to occur, may in fact occur. However, many problems can be seen ahead of time and they should be managed through a proactive risk management process. Figure # 5: High-level process flow

55

MUDASIR

Everything in life has some degree of risk. Walking across the street can be risky. Your projects have risks as well. The project manager should perform a risk assessment with the project team and the client to identify high, medium and low level risks. If you are lucky, you may find that you only have low risks. However, this assessment will alert the client and the project team to any medium and high-level risks that may cause future problems. Identifying risks on your project is not necessarily bad, since risks are common to all projects. All projects have some degree of risk. Projects with a higher level of risk require more rigorous risk management and more management focus. Although not all risks can be eliminated entirely, most can be anticipated and managed ahead of time. The purpose of risk management is to identify the risk events for a project and then establish a Risk Management Plan to manage the risk event and minimize harm to the project. In the Ten Step process, the first time you perform a risk evaluation is in the 1.0 Define the Work step. Additional risk identification should occur throughout the project on a scheduled basis (monthly or quarterly) or at the completion of a major milestone. Project Risk Management: Perform Qualitative Risk Analysis This process entails assessing the impact and likelihood of identified risks. The purpose (output) of this process is to prioritize risks and update the Risk Register, which was created in the Identify Risk process. Therefore, the Risk Register is a key input to this process. Other inputs are the Risk Management Plan and the Scope Statement. Some Tools and Techniques used in this process are: Risk Categorization, Probability/Impact Rating Matrix, and Expert Judgment. The output of this process is an updated Risk Register, which will contain relative ranking of risks and watch-lists of low priority risks. In PMBOK Project Risk Management quantifying risks is the next step.

56

MUDASIR

Project Risk Management: Perform Quantitative Risk Analysis This process involves the quantification of each risk with numerical values. Key inputs include: Risk Register, Risk Management Plan, Cost Management Plan, and Schedule Management Plan. Some Tools and Techniques used in this process are: Expected Monetary Value Analysis Using Decision Trees and Expert Judgment. The output of this process is an updated Risk Register, which will contain a prioritized list of quantified risks and probabilistic analysis of the project.

57

MUDASIR

Risk Management Tools:

Operational risk management - the continual cyclic process which includes risk assessment, risk decision making, and implementation of risk controls, which results in acceptance, mitigation, or avoidance of risk.

Probabilistic risk assessment, Probability Consequence (P/C) or Probability Impact Model - Simple model where estimates of probability of occurrence are multiplied by the consequence (cost, schedule delay, etc.). RiskAoA A predictive tool proprietary to the US government, used to express risk as a single number, like cost or schedule, comparing total risk between programs, proposals or other alternatives. Risk register - a project planning and organizational risk assessment tool. It is often referred to as a Risk Log. Safety case - an assessment of the potential risks in a project and of the measures to be taken to minimize them. SAPHIRE - a probabilistic risk and reliability assessment software tool. SAPHIRE stands for Systems Analysis Programs for Hands-on Integrated Reliability Evaluations.

58

MUDASIR

Reducing Risk and Increasing the Probability of Project Success Risk management: IT Software Development Just Isn't Working! IT systems are at the heart of modern business and the development of new software applications and maintenance of existing systems are critical to productivity and profitability. Advances in software technology over the last 20 years have allowed progressively more complex business solutions to be created enabling companies to offer their customers exciting new services and products. And yet, software development projects still suffer from similar problems and characteristics, regardless of the technologies being used, that they suffered from more than ten years ago. A report from the Standish Group clearly shows that the reliability of delivery of IT software applications has not improved over the years. Figure 1 is for 2001 and this looks remarkably similar to a diagram from the same source in the early 1990's.

59

MUDASIR

Figure # 6: Software Projects

The important question that needs to be addressed is why is software development so risky? Change Is Inevitable All software projects implicitly have associated risks. One of the major sources of risk results from changes that occur during the project's lifecycle. In its most common form, this is seen as changing user requirements. It is, however, not just confined to this area. For example the following changes all present real risk to projects: 1. Changes to the makeup of the project team or in stakeholders 2. Changes in the technology being used 3. Changes to any external systems with which the new software must work

60

MUDASIR

How you deal with changes to the project is the key to reducing your development risks, and to increasing the overall chances of success of your project. But what is the best way to do this? The major influence lies in the development process you choose and not the technologies being used. Picking The Right Process As a project manager you may be tempted to try and eliminate change in your project through a rigid policy of no change. This is the case for waterfall processes where the major assumption is that development can proceed in an orderly, linear and predictable fashion. Waterfall processes have a clearly defined sequence of stages, each of which must be completed and signed off before progressing to the next stage. For example Requirements (capturing) is completed before Analysis is started. Design cannot then be started until Analysis is complete and signed off...and so on. Figure #7 shows the typical lifecycle of a waterfall development process.

61

MUDASIR

Figure # 7: Waterfall Development Lifecycle

Waterfall processes may appear at first glance to be a reasonable and common sense approach. The problem is that developing software is inherently unpredictable and this type of process does not cope effectively with change. The result is that this approach to developing software almost always fails to mitigate risk. Worse still, with this type of process, you may all too often be lulled into to a false sense of security as the project progresses. By adopting a rigid sign off strategy for each activity in the project, it is all too easy to believe that the project is getting easier and risk is reducing as you get nearer to the go live date. Change will inevitably occur during the project lifecycle, and this is usually the result of feedback. As we see in figure 3, waterfall processes have a late

62

MUDASIR

feedback cycle for the part that really counts, the actual software code, and not the signed off paperwork. Figure # 8: Coping with Change

The result is that changes often need to be made to the system during the later project stages such as integration (when the different modules of software code are assembled into one application system) and the testing of the system proper. Imagine having to write off a 100 man-year project, after having already spent 95 man-years of the budget, because of a fundamental misunderstanding in the user's requirements! The risk profile for waterfall processes, as shown in figure # 9, is inappropriate for software development.

63

MUDASIR

Figure # 9: Waterfall Risk Profile

The fundamental problem with waterfall processes is that they rely on the assumption that the progress of a software project can be predicted with reasonable accuracy from the outset, and that a reliable completion date can be derived from this. By assuming that the development lifecycle will be predictable, you are admitting that a high degree of risk cannot exist within a project. This is a fools paradise! The Waterfall process is the wrong approach for software development. A Lower Risk Approach - Iterative Development Project risks are associated with the unknown. These can be technical, organizational or business oriented in nature, such as: 1. How will my system communicate with system A? 2. How do I manage my offshore development group?
64

MUDASIR

3. Do the system requirements actually reflect the true needs of the users? Adaptive software development processes realize that producing software is a risky business and highly unpredictable in nature. They also recognize that the best mechanism for achieving successful delivery is to contain and mitigate risk by means of the regular and controlled delivery of testable software code to provide a reality check on progress and to give feedback to the users throughout the entire lifecycle of the project. Key Principles There is no single overriding rule that guarantees project success but the following key principles will greatly increase your chances: 1. The adoption of an Iterative Risk Driven Approach 2. The commitment and involvement of senior management 3. A high level of communication between all project team members 4. A highly skilled development team 5. The adoption of a Use Case driven approach 6. The adoption of a comprehensive and rigorous system of change control 7. The use of Visual modeling Iterative Risk Driven Approach This will reduce risks by developing small pieces of the system over a short timeframe (a maximum of four weeks for large projects). At the end of each development cycle, the software should be demonstrated to the users to obtain feedback on its functionality and suitability.
65

MUDASIR

An iterative approach will continuously reduce project risk from the outset. The reason why, is that it forces the team to address the most important aspects of functionality and to resolve high risk issues at an early stage. A real example of how an iterative approach reduces risk occurred in 2001 when I was working on developing an application to monitor financial transactions. One of the users' requirements meant that the system had to process one million financial trades within an eight hour window. The client was adamant that this was a key requirement and that the application must be capable of running on low cost hardware. We recognized that there was a major risk that we might not be able to meet these performance objectives, so we built a basic working system within three weeks and provided critical feedback to the users that we could only achieve 10% of the performance required. Result - the users reassessed their objectives and realized that a lower processing target was indeed adequate. This major risk was thus mitigated within the first three weeks of the project. Figure 5 provides a comparison of typical risk profiles between iterative and waterfall development lifecycles. The iterative cycle continuously mitigates risk from the early project stages as a result of regular feedback from users.

66

MUDASIR

Figure # 10: Risk Profile Comparison Between Iterative and Waterfall Processes

Senior Management Commitment Changing the way people work is probably the hardest thing to do in any business and when it involves technologists it can be an even harder challenge. It is important to ensure you have full executive support for any type of process change. You will need backup to drive through changes in the early stages - but once the process starts working, people will naturally want to be associated with it. High Level of Communication - Keep Talking! First and foremost projects are about people. Without everybody working together you haven't got a team and the project will fail. Communication is paramount within the team and more importantly with your users and sponsors. This has to be on a regular basis, daily with the team, and at
67

MUDASIR

least weekly with the users and sponsors. Your end goal should be to make all these groups part of the project team. Iterative development will greatly increase communication with the users. Communication comes in many forms - not just verbal, and includes producing good documentation. Aim to keep documentation lightweight by adopting a 'just enough' policy. Use visual modeling (key principle) whenever possible to raise the level of communication. Highly Skilled Development Team A highly skilled group of individuals that understands how to work together should form the nucleus of your team. They will be very efficient and productive. If you haven't already got the right mix of skills (technical and process), then invest in training focused on meeting your project's needs. Do not, however, waste time and money with off-the-shelf 'one size fits all' training courses. Consider supporting your project team with expert mentors to assist and accelerate process adoption. Use Case Driven Approach Use Cases are highly effective because they provide a contextual representation of the system requirements. One of the main reasons why they should be used is that they are non-technical in nature and provide a written step by step description of how the actors (system users - human or otherwise) shall interact with the system. Simplicity is the key strength of use cases. So many times I have seen documents that purport to contain the complete system requirements, when in fact they are just a set of business rules and a list
68

MUDASIR

of user needs. To drive a project forward, you need objectives and goals to aim for, and Use Cases are the best way do this. They bind together the whole development process from the capturing of user requirements through to the testing of the application software. Change Control This is very different from stopping change from occurring to your project. Instead the emphasis is on the careful consideration of new requests and deciding (with the users) how these should be accommodated. For example, if the delivery date is fixed, does a new request mean that an existing requirement has to be removed from the live release, or that a further system release should be considered? Visual Modeling - 'A picture is worth a thousand words' Visual modeling is the modern equivalent of the "flowcharts" used in the early days of software production. The value of visual aids remains valid and diagrams should be used throughout the project. Demand that all roles use the same modeling notation, from business analysts to designer and coders through to testers. The UML (Unified Modeling Language) is the de facto standard for the visual modeling of systems and should be used to communicate consistently and concisely across the project. There is no excuse for not using it. Are You Really Risk Focused? I have worked with many clients and spoken to senior managers and technical specialists who swear that they are risk focused and follow an iterative
69

MUDASIR

approach. You will come across the same situations, so how do you know if your IT group is really doing risk based iterative development? Ask a few telling questions: How long is an iteration? The answer should be anywhere from a few days to a maximum of about four weeks. Answers of three months or more should indicate the process is still waterfall with long feedback cycles with the associated high risk of getting it badly wrong before being able to rectify the situation. What is delivered at the end of each iteration? The answer should be a demonstration of some actual working software to the users, during which they will have the opportunity to provide feedback. If the answer is documents for sign-off, then they are missing the point. When do you the users see what they are going to get? The answer should be at the end of every (short) iteration. An answer of "only during acceptance testing prior to delivery" is just not acceptable. When do you intend to start integration testing? The answer should be that integration testing is a continuous activity that occurs during each iteration.

70

MUDASIR

How do you manage risk? The answer should be that there is a regular assessment of risk, quantified in terms of probability and impact to the development schedule along with proposed mitigation strategies. The project manager should maintain a running risk list, available for inspection by all people associated with the project. Longer Term Business Continuity So if I adopt all these good practices what does this really mean to my business? We know that software development is a highly risky business that costs a lot of time, effort and money. But the greatest costs occur long after the initial development is over, as shown in diagram 6, when the system enters the support and maintenance phase of it lifecycle. Software Cost Breakdown Adopting these good practices, with the focus on developing systems that deliver what the users actually want, will usually produce systems that are of a higher build quality and are 'fit for purpose'. This typically results in systems that are easier to maintain and revise and thereby reduce the long term operational costs and associated risks. Risk Identification The risks that could occur, and indeed did have been split into a number of sections that are detailed below:
71

MUDASIR

(a) Pre-programmed components At the beginning of the project, it was not planned for us to use any preprogrammed components so at the time we would not have said there was any risk involved with these. We have so far not used any pre-programmed components and so have encountered no problems with them. We do not plan to use any pre-programmed components in the remaining part of the project. (b) Personnel illness/unavailability Before the project began it was not really anticipated that there would be any problems with group members being ill or leaving the university. The risk of this happening would probably have been said to have been low. So far, there have been minor problems due to illness during this project, but nothing that had any effect for more than a couple of days. One major problem that did occur during the project was that one member of the group left the university. There is of course the possibility of further personnel illness in the remainder of the project, but this is only thought to be of low risk, although you never can be sure. We feel there is a moderate risk of group members not doing the work they have been asked to do, especially over Easter. (c) Organization risks Due to the nature of the project, organizational risks were minimal, although we knew from an early stage to look out for things such as requirements creep due to the experience of a group member who was retaking the year and had done the Software Hut project previously.
72

MUDASIR

In actual fact, there has been very little change in the clients requirements, and it was a condition of this project that the requirements be frozen after five weeks. However, until the Week 5 cut-off point, changing requirements was certainly a possibility. When, after Easter, our system is shown to the client, we think there is a moderate chance of them wanting us to alter the system to fit in some new requirements. However, we think this presents only low risk because Professor Mike Holcombe has instructed us not to alter our system for any late requirement changes due to the lack of time. (d) Tool risks The only tool risks in the project were associated with the Symantec Caf tool used to generate code, particularly the graphical user interfaces. Having used this product in the past and found no reliability problems, we would have thought at the beginning of the project that there was only a low risk of the project being affected by Symantec Caf not functioning properly. So far, Symantec Caf has worked very well, although there have been some problems with it only working on certain computers in the Lewin Lab. However, these problems have not led to any difficulties. Having finished creating the program, we have no more need for any tools and so the estimated risk due to tools for the remainder of the project is none.

73

MUDASIR

(e) Technology risks At the start of the project, technology risks were considered to be the biggest risk to our system not being a success. The risk basically was that either the system would be too difficult to produce given the networking requirements, or it would be produced, but just not work on the clients computer systems. The members of the group have little experience in networked technologies so initially we wondered if the system could be created. The main risk was not finding somewhere for the server to be located. We have managed to implement the system and get it to work properly within the Department of Computer Science, but it is still unknown whether it will work on the clients machines. Due to the client not cooperating, it is even unknown what exactly the facilities are that the client can provide. Attempts at getting CICS or DCS to host the system have proved unsuccessful. As things stand at present, we feel there is a moderate to high risk concerning whether the system will work on the clients computers or not. There have also been technology problems concerning the CICS and DCS computers. At the beginning, we did not anticipate problems with the machines but there have been some times when group members have been unable to log-on. The effects of this were not serious, although we did lose a few hours. We think the computers may not be working at a few points after Easter, but as we have nearly finished the project, there should be little risk involved with this. To summarize, the main risks at the beginning of the project would probably have been identified as follows:

74

MUDASIR

 Our group not being able to create the system. The system not working on the clients machines. Changing requirements. The main risks from this point onwards are: The system not working on the clients machines. Personnel illness/unavailability. The client wanting to make changes to the system.

75

MUDASIR

Risk Planning:

In this project, we did not have a Risk Management strategy, and therefore no formal risk avoidance or reduction plans. The only problems that we had only resulted in a small amount of lost time, which was easily made up. The departure of one group member did not affect our plan, as at the time we had no formal plan. Personnel illness/unavailability was compensated for by simply making up the work later. Changing requirements was an inherent part of the project, but the effects were not serious and did not need to be compensated for. If Symantec Caf was unusable, we would simply have had to program the frames manually. Of the problems listed, none could be avoided; they could only be compensated for. In terms of planning to avoid the risks that might occur in the remainder of the project, we have down the following things: (a) The system not working on the clients machines This could well lead to the program not working at all, which could in turn lead to us getting a very low mark. The risk to the project due to this was considered so high that it was decided to build a standalone version of the system. This version should have no problems working on the clients machines because all the problems and uncertainties so far have been to do with finding somewhere for the server of the system to go. It will not have any of the monitoring facilities of the networked version, but these were only desirable requirements anyway, and not mandatory. The task of producing the standalone system has been assigned to Andrew Cubbon, who will produce it over Easter. It is anticipated it should not be too difficult to produce, due to it mainly involving just deleting parts of the present system.
76

MUDASIR

(b) Personnel illness/unavailability In case of group members being ill, their work will just have to be redistributed among the remaining members. To try to make sure group members do the tasks assigned to them, it has been stated precisely what each group member has to do over Easter and strict deadlines for work submission have been set. Group members know that the marks for the project may not be distributed evenly in the case of group members not doing their fair share. For further details of this, please see the Time Plan document for the Easter vacation. (c) The client wanting to make changes to the system The plan in case this occurs, is to say to the client that we have been instructed by Professor Mike Holcombe not to make any significant changes to the system at this late stage. If, however, the changes were minor, then we would try to make the alterations the client required. Project Risk Management In many projects, risks are identified and analyzed in a random, brainstorming, fashion. This is often fatal to the success of the project, as unexpected risks arise, which have not been assessed or planned for and have to be dealt with on an emergency basis, rather than be prepared for and defended against in a planned, measured, manner. Very early in the preparation and planning stage, it is essential that potential risks are identified, categorized and evaluated. Rather than look at each risk independently and randomly, it is much more effective to identify risks and then group them into categories, or, to draw up a list of categories and then to identify potential risks within each category. This way,
77

MUDASIR

common influences, factors, causes, potential impacts and potential preventative and or corrective actions, can be discussed and agreed on. Categorizing risks is a way to systematically identify the risks and provide a foundation for awareness, understanding and action. Each project will have its own structure and differences, but here are some categories that are common to most projects (to which you can add your own local, sector, or project specific, categories). I have not given deep detail here, but your project team and sponsors should be able to relate to these categories and use them in the risk assessment process. For example, with "operational resources" your team can discuss issues such as, availability, delivery timing, cost, capability, necessary conditions for operation (e.g. ground, weather, light); with "stakeholder resources" your team can identify all stakeholders and list potential risks that these stakeholders may generate, such as bad publicity from the media, delays caused by community or environmental groups, delays caused by utility companies, problems with trade unions. Related risks and potential actions, must then be documented in the risk management plan and discussed at all the key stages as the project progresses. All the details and the actual action taken and the outcomes, must then be recorded and reviewed during the closure and review stage, for lessons to be learned and applied to future projects. Here the question that most project managers ask: "how do we know if we can manage the risk, if it arises?" Often, sadly, no evaluation is carried out to determine the expertise, experience, capabilities of the team, individuals, organizations that would be required to deal with, manage that risk, if it occurred. As a result, if it did, the team may not be able to deal with it effectively, even though the initial forecast was that the risk could be managed.
78

MUDASIR

This happens frequently when the planning team is not the project team that manages the project and/or when key individuals in the original project team leave the team during the project and are replaced by individuals with different skills, experience and capabilities. The clear message here is that setting a risk tolerance level is a dangerous business. Each potential risk needs to be carefully, rigorously, analyzed and the project team, the supporting teams and individuals, the organization(s) involved in managing the project, all need to be evaluated to determine whether there is the capability to manage that risk successfully, should it arise. Where gaps in capability are identified, then appropriate corrective action must be taken. During the project itself, this capability must be constantly monitored and, where necessary, action taken to return the level of capability to the required level. Conflict over resources often arise during the middle to later stages of a project, because, often unexpected other, newer demands arise which are seen as being of higher priority. This can lead to resources that were originally allocated to the project being taken away, or reduced in quantity or quality, almost certainly to the detriment of the project. The answer to this dilemma is not easy, but in essence, the project management team must include "conflict over resources during the life of the project" as a major potential risk and plan for it accordingly by securing agreements and then monitoring the situation continuously. If a dispute does arise, there is a role here for the project champion and or the client to ensure that the allocated resources are not taken away. Fundamental to many of the issues that we discuss here is the question of who should be responsible for risk assessment and management. Too often the
79

MUDASIR

responsibility for risk identification, assessment and management, are left to the project team, especially once the project has started. But there are other individuals and groups, including some external stakeholders, who should be continuously monitoring particular activity and feeding back regularly to the project team leader. Some are easy to identify. They include of course, the client, the sponsor, key specialists in the project team's organization, or organizations, the major external participants, such as emergency services, local authorities and contractors. The easy way to identify other individuals and groups is to look at your list of stakeholders. Each one has a responsibility, to a greater or lesser degree, to help identify potential risk and give information on this to the project team. Again, the answer to managing the question of risk responsibility is to build discussion, planning and action, on this into the project planning and operational activity.

80

MUDASIR

The Top Five Software Project Risks Risk 1: Inherent schedule flaws Explanation: Software development, given the intangible nature and uniqueness of software, is inherently difficult to estimate and schedule. Waltzing...Solution: Get the team more involved in planning and estimating. Get early feedback and address slips directly with stakeholders. Agile Practice: On agile projects the team is heavily involved in planning and estimating through activities such as XP's planning game and Wideband Delphi workshops. By working in short increments the true velocity of the team quickly emerges and is visible to all stakeholders who are now more closely involved in the project. In short, the true progress is hard to hide and quickly revealed, giving feedback to the stakeholders. Risk 2: Requirements Inflation Explanation: As the project progresses more and more features that were not identified at the beginning of the project emerge that threaten estimates and timelines.
81

MUDASIR

Waltzing...Solution: Constant involvement of customers and developers. Agile Practice: Agile projects plan in the regular trade-off discussions about features and estimates at every iteration boundary. Changes and requirements inflation are accepted as a fact of software projects. Rather than utilizing change-suppression mechanisms, prioritization sessions are scheduled that allow worthwhile changes to proceed and initially envisioned features to be superseded if the business gives their authorization. It has never been possible to squeeze a pint into a quart cup, but now at least we anticipate the likely issue and have mechanisms in place to address the matter as part of the project from its early stages. Risk 3: Employee Turnover Explanation: Key personnel leave the project taking critical information with them that significantly delays or derails the project. Waltzing...Solution: Increased collaboration and information sharing on the team. Agile Practice: Agile projects practice information sharing techniques such as pair programming, common code ownership, and frequent reporting at daily stand-ups specifically to reduce the "bus-factor". When this "bus factor" (the impact to the project of a key member being hit by a bus) is reduced multiple team members share key information and the risk due to employee turnover is small. Also, often overlooked, is the fact that when working in an engaging, rewarding, empowered, collaborative environment such as agile projects, people

82

MUDASIR

are far less likely to want to move elsewhere so the risk is often avoided as well as reduced. Risk 4: Specification Breakdown Explanation: When coding and integration begin it becomes apparent that the specification is incomplete or contains conflicting requirements. Waltzing...Solution: Use a dedicated Product Manager to make critical trade off decisions. Agile Practice: Agile projects utilize the concept of an ambassador user, subject matter expert, or customer proxy to play the product manager role. The idea is that someone (or some group) need to be readily available to answer questions and make decisions on the project. Traditional projects suffer specification breakdown when no one will own the role and conflicting assumptions or decisions are made. Agile projects have some form of product owner role central to their core team composition to ensure decisions are made in a timely fashion. Risk 5: Poor Productivity Explanation: Given long project timelines, the sense of urgency to work in earnest is often absent resulting to time lost in early project stages that can never be regained. Waltzing...Solution: Short iterations, right people on team, coaching and team development.

83

MUDASIR

Agile Practice: Agile methods recognize Parkinson's Law and the Student Syndrome apply to software projects. Parkinson's Law says that: "Work expands to fill the time available" and Student Syndrome: "Given a deadline, people tend to wait until the deadline is nearly here before starting work." By having short iterations, work is time boxed into a manageable iteration (typically 1-4 weeks) and there is always a sense of urgency. Agile methods do not specifically address getting the right people on team, coaching and team development, but these are core leadership roles applicable to both agile and traditional projects. On Agile Solutions It should really be no surprise that agile methods have techniques built right into them to address each of the top software project risks. They were created out of the experience of what worked well for practical software development. Given that these problems occur time and time again on software projects it is natural that their solutions should become baked into the DNA of agile methods. So, while risk management is a dry and dull subject to many, Waltzing with Bears brings the subject to life with valuable pointers for software project managers and is a recommended read.

84

MUDASIR

Risk Management Process: A Practical and Effective Approach

Some experts have said that a strong risk management process can decrease problems on a project by as much as 80 or 90 percent. In combination with solid project management practices, having a well-defined scope, incorporating input from the appropriate stakeholders, following a good change management process, and keeping open the lines of communication, a good risk management process is critical in cutting down on surprises, or unexpected project risks. Such a process can also help with problem resolution when changes occur, because now those changes are anticipated and actions have already been reviewed and approved, avoiding knee jerk reactions. Defining "Risk" Before one can embark on a risk management process, one must have a solid understanding of some key definitions. Project risks as defined from a PMI perspective are, at their core, unknown events. These events can be positive or negative, so that the word "risk" is inherently neutral. That said, most of the time and focus is spent handling negative project risks, or "threats," rather than positive project risks, or "opportunities." Often, companies that do perform a risk management process on a fairly typical multi-month project (no longer than 12 months) will identify and manage possibly five to ten easily recognized project risks. However, that number should in fact be much higher. With a high number of project risks identified

85

MUDASIR

early on, a team's awareness of what to look for is increased, so that potential problems are recognized earlier and opportunities are seen more readily. It may seem that project risks cannot be managed without taking away from the actual work of the project. However, this can effectively be accomplished with a seven-step risk management process that can be utilized and modified with each project. The Risk Management Process Step one of the risk management process is to have each person involved in the planning process individually list at least ten potential risk items. Often with this step, team members will assume that certain project risks are already known, and therefore do not need to be listed. For example, scope creep is a typical problem on most projects. Yet it still must be listed because even with the best practice management processes in place, it could still occur and cause problems on a project over time. Therefore it should be addressed rather than ignored. Step two of the risk management process is to collect the lists of project risks and compile them into a single list with the duplicates removed. Step three of the risk management process is to assess the probability (or likelihood), the impact (or consequence) and the detect ability of each item on the master list. This can be done by assigning each item on the list a numerical rating such as on a scale from 1 to 4 or a subjective term such as high, medium, or low. Detect ability is optional, but it can be simple to assess - if a risk is harder to see, such as with scope creep, then it's a riskier item. If it's easier to
86

MUDASIR

catch early, such as loss of management support or loss of a key resource, then it's lower risk. Step four of the risk management process is to break the planning team into sub-groups and to give a portion of the master list to each sub-group. Each subgroup can then identify the triggers (warning signs) for its assigned list of project risks. All triggers should be noted, even minor ones. Normally there will be at least three triggers for each risk. Step five of the risk management process is for those same sub-groups to identify possible preventive actions for the threats and enhancement actions for the opportunities. Step six of the risk management process is for the sub-groups to then create a contingency plan for most but not all project risks - a plan that includes the actions one would take if a trigger or a risk were to occur. This plan will be created for those risks scoring above a certain cut-off point, which is determined after looking at the total scores for all risks. This keeps the risk management process manageable. The risk management process is not effective if it is so time-consuming that it is never done. Step seven, the final step in planning the risk management process, is to determine the owner of each risk on the list. The owner is the person who is responsible for watching out for triggers and then for responding appropriately if the triggers do in fact occur by implementing the pre-approved and now established contingency plan. Often, the owner of the risk is the project manager, but it is always in the best interest of the project for all team members to watch for triggers while working on the project.
87

MUDASIR

Rather than start this risk management process from scratch for every new project, it can be followed once to establish a list of generic project risks and triggers, skipping step three. Then, a team simply has to add project-specific project risks and triggers and assess the probability, impact, and detect ability for each risk, saving a great amount of time and helping to ingrain a risk mentality into your project culture. Creating a Risk Register or Risk Matrix Upon completion of the risk management process, a master document, known as a risk register or risk matrix, is created. The most effective format for this document is a table, because it will allow a great deal of information to be conveyed in a few pages. If the information is instead presented in paragraph form, it may not be read by people and will be rendered ineffective. The columns in the table can include risk description, probability, impact, detect ability, triggers, preventive actions, and contingency plan. Other columns, such as quantitative value, can also be added as appropriate. Important Things to Remember Often, the steps in which triggers and preventive actions are identified are overlooked. However, these are vital to the entire risk management process. After a team has completed this exercise once, the members will be better conditioned on what to pay attention to while managing the project so they are more proactive in catching changes or issues early. If these steps in the risk management process are skipped, the team can find themselves in constant reaction mode, simply implementing a contingency plan for each risk after that risk catches them by surprise. They could also ignore a seemingly
88

MUDASIR

overwhelming list of project risks, which is why narrowing the list down to the most important risks is critical for making sure the list is used. Once the risk register is complete, it is easy to maintain. It can be reviewed during regular status meetings, with as little as 15 minutes spent making sure the list is still current. Determine if any project risks can be closed (but not removed completely), if any risks have increased or decreased in value, and if there are any new project risks to add. This will ensure that the list is continually seen as relevant and useful throughout the life of the project. Project Risk Management: It's Either Contingency Planning Now or Emergency Relief Later Several years ago, I was concluding a project risk review meeting, and I received a text page from my project's executive sponsor ("Jim") summoning me to his office. As soon as the meeting concluded, I went to Jim's office where he launched into a lecture about the need to cultivate a "positive environment" for the project team. After a few minutes of his diatribe, I explained to Jim that I did not know what triggered this discussion. Jim then explained the regular risk review sessions I was facilitating had created a "negative vibe" throughout the project team, since we were focusing on reasons that the project could not be done. He went on to request that we limit our discussions on project risks and focus on the things we can control instead of those things we cannot. As a seasoned project management professional, I was admittedly stunned that our project sponsor advised his project manager to virtually eliminate our risk management efforts from the project!

89

MUDASIR

I have learned in the years since that this scenario is not that uncommon in the project management environment. The competitive market and stakeholder risk tolerance levels exacerbate the myth that risk management initiatives are a waste of project resource time; that time should be focused on the actual work of the project, not events that may or may not occur. The fact is, however, that it is either contingency planning now or emergency relief later for our projects. The Common Constraints In most cases, risk management initiatives either do not occur at all or are done as a mere checklist formality early in the project. The three most common constraints with project risk management are: 1. Risk management is applied inconsistently Even when potential risk events are identified for a project, this process typically occurs early in the project and is never revisited. As a result, the project team may not be prepared to respond to new uncertainties and issues that have not been identified. 2. Risk management is not prioritized The risk planning, analysis, and response planning efforts are rarely integrated into the overall project plan. As a result, risk management is not a priority for the project team, and adequate resources (budget and people) are not allocated to address issues caused by risk events. This "we will deal with those events if and when they occur" mentality leaves little or no room for error on the project.

90

MUDASIR

3. Risk management earns limited buy-in and support In many cases, project sponsors and senior management discount risk management efforts for their projects because the benefits are unclear. Additionally, senior management, hearing the phrase risk management, might say, "We have a group that handles our risk management, so why do we need to have a separate effort on the project. Plus, we are not reducing project costs or delivery time so why should we invest in risk management?" As you have likely discovered, the challenges present in project risk management are just another element to worry about as a project leader. There are three basic tenets you can incorporate that can turn your risk management efforts into a consistent and proactive process. They include: Project Risk Management Tenet #1: Assess Early and Often Project risk management must occur throughout the life cycle of the project. Uncertainties can be discovered at any time, while the relative probability and consequence of identified risks can change over time. For instance, the farther along a project goes into the schedule, the more likely you will lose team members to other efforts. In addition, the impact of poorly defined requirements will typically have a greater impact on project success in the latter stages of the project. It is imperative that the project team address uncertainty early and often, throughout the entire term of the project. Project Risk Management Tenet #2: Build It into the Schedule In order to adequately deal with uncertain events, the project schedule must include risk management activities. The project manager must ensure that risk
91

MUDASIR

assessment (identification and analysis) and response planning initiatives are a regular occurrence. Depending on the size, scope, and complexity of the project, risk reviews can either be an agenda item on the weekly review meeting or a biweekly review by itself. Either way, the project manager must incorporate consistent risk management mechanisms into the project schedule. Project Risk Management Tenet #3: Communicate and Illustrate Ownership The inherent uncertainty of risk events tends to make key stakeholders avoid the subject altogether. Therefore, it is up to the project manager to employ effective communications and clear ownership of risk elements. Potential risks need to be clearly identified and assessed, and accompanied by targeted, yet realistic, response strategies. Simply put, risk response strategies need to function as a rifle, not a shotgun. Also, the project leader must ensure that team members are properly aligned as owners for specific risk events. When key stakeholders know who to contact regarding a critical uncertainty, clear communication is better facilitated. Proper project risk management entails more than simply identification and analysis at the beginning of a project. Risk management must be integrated into the project plan, consistently applied, and clearly communicated throughout the life cycle of the project. Risk Management Options: Risk management as a shared or centralized activity must accomplish the following tasks: identity concerns; identify risks & risk owners - evaluate the
92

MUDASIR

risks as to likelihood and consequences; assess the options for accommodating the risks; prioritize the risk management efforts; develop risk management plans; authorize the implementation of the risk management plans; track the risk management efforts and manage accordingly. It is possibilities that are being accommodated. It is management's job to do the planning that will accommodate the possibilities. The customer is the final judge, but internal goals should be to a higher level than customer expectations. The key words in risk management are: proactive; management; accommodate; acceptably; professional; possibility. The need for new risk assessment and management techniques is required to continuously track down potential and critical risks, and to develop strategies for handling these risks, for example: during product development. It is obvious that without a strong risk management plan as part of the process, a company will waste time, money, and resources, and will fail to manage their projects correctly. Risk management is the sum of all proactive management directed activities within a programme that are intended to acceptably accommodate the possibility of failures in the elements of a programme. From an organizations perspective a failure is anything accomplished in less than a professional manner and/or with a less-than-adequate result. Risk management options are usually cited as risk handling options subdivided as: avoidance, control, assumption, risk transfer, and knowledge and research. Generally, the assessment of management options is a hip shot since the necessary decisions must occur early in a programme when things are still fuzzy. However, if experienced personnel are given the facts, one can expect
93

MUDASIR

very good decisions since there is seldom any real mystery about the practicality of options available. (The practicality of any option is usually just an issue of schedule and funding.) Avoidance: Use an alternate approach that does not have the risk. This mode is not always an option. There are programmes that deliberately involve high risks in the expectation of high gains. However, this is the most effective risk management technique if it can be applied. Control: Controlling risks involves the development of a risk reduction plan and then tracking to the plan. The key aspect is the planning by experienced persons. The plan itself may involve parallel development programmes, etc. Assumption: Simply accepting the risk and proceeding. However, there can be a tendency within organizations to gradually let the assumption of a risk take on the aura of a controlled risk. Risk Transfer: Means causing another party to accept the risk, typically by contract or by hedging. Liability among construction or other contractors is often transferred this way. Knowledge & Research: This mode is not "true" risk handling, but rather a technique for strengthening other techniques. This approach can best be viewed as an adaptation of the approach used by a student writing a thesis: intensive study with specialized testing - in other words doing your homework. Never expect initial risk management plans to be perfect. Practice, experience, and actual loss results will dictate changes in the plan to allow different decisions to be made in dealing with the risks being faced. In order for
94

MUDASIR

companies to succeed in the twenty-first century, they need to excel in all aspects of their business, which includes risk management, so they can fulfill their own and their customer's goals. All projects have risks and uncertainties. In some cases, for example in most research and development project the effect of such risks and uncertainties can be very significant. However many managers still did not employ proper project risks management processes for their projects. In many cases they dont believe, that establishing and implementation of such process will be beneficial, since it is difficult to predict all potential risks and their affect of the project. There is a classical example. One of the Intaver Institutes clients, the large oil company, performed a drilling of the well with total cost about $2M. Project schedule has been created based of analogs: drilling of similar wells in the similar geological conditions. At the middle of drilling the mud, required to this technological process, starts disappearing. Project engineers have tried different solutions. It delayed the project so significantly that total cost of the well has almost doubled. Later on the project manager has admitted that it would be cheaper to abandon the well and drill new one somewhere else. Or perhaps dont start drilling in the particular location in a first place. Unfortunately the company did not have well established project risk management process at this time. What should be done is to properly analyze project with risks and uncertainties at the stage of project planning, and then reassess risks during a course of the project. To explain how proper risk management process should help, lets analyze some physiological issue related to estimations. . In 2002, Daniel Kahneman was awarded the Nobel Prize in economics "for having integrated insights from psychological research
95

MUDASIR

into economic science, especially concerning human judgment and decisionmaking under uncertainty. According to this theory, fundamental limitations in human mental processes cause people to employ various simplifying strategies or heuristics to ease the burden of mentally processing the information required to make judgments and decisions. During the project managers rely on heuristics or rules of thumb to make estimations and manage the project. Under many circumstances heuristics lead to predictably faulty judgments or cognitive biases. One of such rules of thumb is availability heuristic. Decision makers assess the probability of an event by the ease with which instances or occurrences can be brought to mind. For example, project managers sometimes estimate the chance of risk occurrence based on similar tasks that have been previously completed. If they are making their judgment based on risks they remember, it can cause inaccurate estimation. The anchoring heuristic refers to the human tendency to remain close to the initial estimate. For example, during brainstorming meeting engineers estimated the chance of the risks equal 10%. During a discussion they said that actual chance will be between 8 and 12 percent. So they always remain close to the original estimate. Judgments concerning the probability of a scenario are influenced by amount and nature of details in the scenario in a way that is unrelated to the actual likelihood of the scenario. It is called the representativeness heuristic. For example the project has two potential risks. One of them is very well documented, but another one has a very limited descriptions. Decision maker sometimes may assume, that chance of occurrence of the first one will be higher than second, which in reality may not be the case. Decision makers can be exposed to many cognitive and motivational factors that can lead to biases in
96

MUDASIR

perceptions. This effect is often referred to as selective perception. For example, estimation of a tasks cost can be influenced by the intention to fit the task into the projects budget. As a result, some of the project parameters can be overestimated. Another type of biases is related to management push for a better project performance. Such management biases may cause underestimation of certain risks. With so many potential pitfalls in decision-making, is any way to reduce biases and provide more accurate estimation and analysis of project parameters? Many project managers recognize this problem. But in many cases they response is provide very basic project risk management or sometimes dont bother with risk analysis at all. Most uncertainties in project management are related to the lack of knowledge about the incoming activities and risk. For such so called epistemic uncertainties, there are two major strategies of performing risk analysis: 1. Properly capture all historical information and use it to make estimation and analysis. 2. Carefully track a project performance including information about risks and uncertainties; update estimation when new information about current project performance become available. Most real life projects have multiple risks and uncertainties, which affect project different way. In such cases computerized qualitative risk management tool could become the only feasible way not only to manage project uncertainties in current projects, but also to provide input for future projects. Lets see how qualitative risk analysis software can help to mitigate negative effect of heuristics and biases.

97

MUDASIR

If risks and uncertainties are registered in comprehensive database, it will help to mitigate availability heuristics. Decision maker will judge about probability of the events occurrence based of reliable set of data. In qualitative risk management software each risk has accompanied by the set of standard parameters: severity, impacts, mitigation plans, etc. It helps to mitigate representativeness heuristics, because decision will less likely be influenced by more detailed scenario. If risks are properly registered and updated during the course of the project, it helps to mitigate negative impact of selective perception and management biases. Assessment of risks of future project will be done based on objective analysis of risks in current project. If assessment of risk is done based on objective recorded historical data, the anchor for decision making may not be present. It can reduce negative impact of anchoring. Sets of risks recorded and analyzed in qualitative risk management software, can be a foundation of quantitative risk analysis. Quantitative risk analysis will help the manager to determine a chance, that project will be completed on time and within a budget, identify critical project parameters, which affect project schedule at most, determine project success rate, make a decision about viable project alternative, etc. All these wonderful things can be meaningless, if they are not based on reliable set of historical data about risks and uncertainties. Moreover such data must be updated during the course of project based on actual inputs. This principle of decision and risk analysis sometimes calls Garbage In Garbage Out. Quantitative risk analysis will be subject of the same heuristics and biases: availability, anchoring, etc. The most straightforward solution will be to import data for quantitative analysis from qualitative project risk management software. Such integration has been already
98

MUDASIR

implemented between some qualitative and quantitative risk management software tools. Quantitative risk analysis software can statistically process data from qualitative tools. Most quantitative risk analysis tools perform Monte Carlo simulation to determine how risks will affect project schedule. One of the methods of modeling risks and uncertainties calls Event Chain Methodology. According to this methodology, an activity in most real projects is not a continuous uniform process. It is affected by the external events, which transform task from one state to another. These events should be properly captured in qualitative risk management software. The events can cause other events, which will create the event chains. These event chains will significantly affect the course of the project. The identification of the critical chain of events makes it possible to mitigate their negative effects. Now we can come back to our original drilling example. If oil company had qualitative risk analysis software, they would have comprehensive historical data about events, which could happen during drilling, not just duration or cost of similar wells. It will help them to make an informed decision. In decision still has been made to perform drilling and mud disappearing has occurred, both qualitative and quantitative risk management software working together will help the engineers decide about further course of actions. Establishing proper project risk management process will help oil company to save millions of dollars. Contingency Reserves: In a financially responsible organization, contingency reserves refers to the amount of funds or other financial resources that is required to be allocated over
99

MUDASIR

and above the previously designated estimates to reduce the risk of overruns to an acceptable level. However, contingency reserves do not exclusively refer to monetary terms. It also can refer to a specific quantity of time in man hours that must be allocated above and beyond the previously determined quantity of hours. This can assure that any overtime or other unexpected hours of work required can be properly compensated for. Typically the contingency reserves, in terms of both finance and time, are determined at the outset of a project. However, as the project progresses, if it appears that the project requires additional funds or time allocation to complete, contingency reserves can be instituted or modified at any time to better prepare the organization for the possibility of their usage at some point in a projects life. Contingency reserves are funds allocated above the project budget. These funds are intended to be used when unexpected events occur and are designed to reduce the risks of cost overruns. Though it cannot account for everything unexpected and cover all unexpected costs, a properly created contingency reserve can facilitate smooth project execution even when costs go over budget. One way to define a good contingency reserve is through risk management processes. First, you need to identify the risks which can result in cost overruns. Then, you need to qualify the risks to identify the most critical ones, or those worth focusing on. Finally, you need to quantify those risks and express them in terms of financial impact on project budget and probability of their occurrence. The product of impact and probability is a monetary value called exposure. Exposure is the amount of money you determine to cost you as the maximum
100

MUDASIR

impact of the risk. It varies from the amount of money that the realized risk event is going to cost you if it occurs. Risk Process Implementation: Implementation of risk management process is a new addition to the risk management process. It clarifies what ongoing actions should be taken beyond planning. It ensures the risk process is implemented in manner that provides benefit to the management team. Additionally, it tailors suggestion and provides best practices given the size and complexity of a program. This process step, similar to the Planning step, focuses on the process and not on the particular risks of a program. This step should be ongoing and focus on the performance of the overall process and how it is integrated with the other metrics programs that measure the management processes in a program. Risk process implementation requires clear objectives, proper planning and resourcing, effective monitoring and control, and finally clear success criteria. Hence, organizations attempting to implement a formal structured approach to risk management need to treat the implementation itself as a project.

Risk Documentation :

101

MUDASIR

Risk documentation is the formal process of gathering, recording, reporting, and maintaining pertinent information needed to ensure successful risk management. The risk documentation includes all risk information that may be necessary for risk management of projects. A good risk documentation approach captures necessary information with respect to risk assessments, handling analysis and plans, and monitors results. It includes all plans, reports for management and decision authorities, and internal reporting forms. The risk documentation process includes basic documentation knowledge, associated tasks, job aids, templates, and samples. Risk Documentation Tasks: Risk documentation, sometimes overlooked as part of the entire risk management process, is a very important aspect of risk management. Tasks involved in risk documentation are explained and outlined in this area. Risk documentation includes data collected from: Planning Assessment Handling Monitoring activities Risk documentation involves documenting the risk management process comprehensively. As such, information from a variety of source documentation related to risk management requires to be captured. Though, there is no required list of particular risk documents, some of the examples of source information include:
102

MUDASIR

1. Risk management plans 2. Lists of identified risks 3. Risk assessment reports 4. Handling methods and techniques 5. Metrics for monitoring risks 6. Normal management documents, such as Earned Value Reports Successful reporting and documentation of risk management activities can be accomplished by creating: Risk Monitoring Documentation such as Program Metrics, Technical Reports, Schedule Performance Report, and Critical Risk Processes Reports Risk Management Plan Risk Information Form(s) Risk Assessment Report Risk Handling Priority List Risk Handling Plan of Action

Risk Management Tools

103

MUDASIR

As you know Risk management is the act or practice of controlling risk. This process includes identifying and tracking risk areas, developing risk management plans, monitoring risks and performing risk assessments to determine how risks have changed. For a risk management process to be successful you need to use risk management tools. There are many risk management tools that help in identifying, assessing and handling risks. Different risk management tools are used for different projects based on the requirements. Using appropriate risk management tools to identify and handle risks helps in establishing an effective risk management process. Some of the risk management tools and techniques are: Quality Control Tools Probability Techniques Flow Charts Fishbone Diagrams PERT/CPM Techniques Project Insurance Quality Control Tools Many companies use Quality Control tools to improve the quality of products, processes, and to manage risks. The Quality Control tools: Encourage and enhance teamwork as problems are addressed through groups
104

MUDASIR

 Help to anticipate potential problems and improve quality Are essential tools in the continuous improvement of processes Provide objective analysis of problems based on facts and data Provide greater customer satisfaction through superior quality and services There are seven Quality Control tools to manage risks. These tools are: Check Sheet Graphs Histogram Pareto Chart Cause and Effect Diagram Scatter Diagram Control Chart 1. Check Sheet Check sheet is a pre-designed format for collection of data; it encourages collection of data in an organized manner and grouping it into categories. A check mark is added for each example of a category. The marks are added to determine subtotals. A checklist is used to keep track of the parameters of an ongoing process. It can be used to track events and factors such as timeliness, reason for failure (appearance, performance, etc.); person accomplishing the
105

MUDASIR

task (sales calls per representative); complaints (customer complaints for each day of the month); and many other factors. The procedure to use it is to look at some preliminary data before developing the check sheet. This indicates what categories to use. The function of a check sheet is to present information in an efficient manner. This may be accomplished with a simple listing of items. Also, include information about who collected the data, the date and the total sample from which it was drawn. For example, a fertilizers company wants to check the weight of bags of fertilizers that are supposed to weigh 100 kg. The resulting checklist is shown in the following table. The checklist indicates that the machine is not filling all the bags within the specification. Table #5: Check sheet Lot No. : 503 Specification : Weight (Kg.) 98.00 98.50 98.75 99.00 99.25 99.50 99.75 100.00 Weigher : RTF 100kg. 1 Kg.Shift : 2 Tally 0 1111 11111111 111111111 11111 11111111 11111111111111111 Total 2 4 8 9 5 8 17

1111111111111111111111123
106

MUDASIR

100.25 100.50 100.75 101.00 101.25 101.50 101.75 102.00

111111111111 11111111 111111111 1111 111 1111 11 1

12 8 9 4 3 4 2 1

The check sheet shows the weight of bags of fertilizers and the number of bags that have less or more than 100 kg of fertilizer. 2. Graphs Graphs are the visual representation of data; they are used to show comparison of visual representation of data collected. The most commonly used graphs are Bar charts, Line charts, and Pie charts. 3. Histogram Histograms are used to display the distribution of data by category. They provide a simple, graphical view of accumulated data, including its dispersion and central tendency. It is a more convenient and effective way of displaying data than a table of figures because it gives a visual indication of relationships. Histograms are used to observe whether data falls into a specific pattern or not.

107

MUDASIR

To use histograms, find the range of the data to be displayed. Arrange the data range in ascending order on the horizontal scale and the numerical findings on the vertical scale. Draw a bar for each category representing the value. Figure # 11: Histogram

For example, a company produces a fertilizer in which a constituent A should be present more than 30 mgs in a cubic centimeter of volume. Quality control department is measuring the characteristics of the sample received from the reactor and displays it in a histogram. It might show the frequency with which various levels of defects turn up. A succession of histograms can be used for comparison. 4. Pareto Chart A Pareto chart is one of the special forms of bar chart which is intended to determine the most important factors in a situation. It is based on the idea that a few causes produce majority of variations. In most of the cases 20% of causes account for 80% of variations. Pareto chart is used when you want to determine the corrective actions that would yield the greatest quality benefits. It is a good way to set priorities and to focus on the quality efforts. To use Pareto chart, examine the data indicating the frequency with which each cause of a problem that occurs. List them from most to least frequent cause. Plot
108

MUDASIR

them on a bar graph. The left vertical scale indicates the frequency that each bar represents. The right vertical scale indicates the percentage of total occurrences that is covered by the sum of the causes. For each cause, add the per cent of problems that it accounts for to the per cent accounted for by the causes to the left to it and plot points against the right scale that represent this total. Connect these points with a line. For example, a travel company is analyzing and prioritizing complaints about quality received from its customers. The complaint data is as follows: Table # 6: Complaint data Type of complaint Baggage delay Missed connections Lost baggage Poor cabin service Ticketing error Number 23 15 7 3 2

By preparing the Pareto chart based on the above data, we can find out the relative magnitude of complaints and can identify the most important opportunity for improvement in quality of travel service. As shown in the Chart, 75% of customer complaints are related to baggage delay and missed connections only. Based on this finding, the airline staff can use cause and effect diagram to figure out the root causes of these two major problems. 5. Cause and Effect Diagram
109

MUDASIR

The Cause and Effect Diagram is used to associate multiple possible causes with a single effect. In a particular effect, the diagram is constructed to identify and organize possible causes for it. In other words, this diagram represents the relationship between a problem and its potential causes. It deals with factors and not quantities. This type of diagram is useful in any analysis, as it illustrates the relationship between cause and effect in a rational manner. To use Cause and Effect Diagram, define the effect or problem that you are analyzing. Write it down in a box on the right. List all possible potential causes on a separate sheet of paper without regard to relationships. Classify these causes by themes. Each theme represents a diagonal attached to the spine of the diagram. The individual causes are listed along the diagonal. Sub-branches can be created to break down factors in the causes. Once you have constructed the diagram, you can go on to investigate the causes. You can compare them by setting up a Pareto diagram. For example, a company wants to look at the causes for data processing errors. The causes are organized according to the cause and effect diagram. Three main causes of the error were identified as, client, time and typist. Various reasons to cause defect at these three classes are identified by cause and effect diagram, which are to be corrected from source level to eliminate the data processing errors.

6. Scatter Diagram
110

MUDASIR

Scatter diagrams are graphical tools that show the relationship between two variables. The diagram creates a coordinate for each variable and then plots the occurrences where the values intersect. This type of diagram is used to find out the correlation between the variables. It is often used to find the causes of problems. To use Scatter Diagram, establish vertical and horizontal axes with appropriate scales. Usually, the horizontal axis is the one over which you have control. Plot each data point. The more closely the dots group along an axis, the stronger the correlation. The more scattered they are, the weaker the correlation. If you determine a correlation, statistical analysis can give a more accurate indication of the relationship. For example, a company wants to investigate whether the operators errors are related to volume of work. The number of errors per month is tracked for operators with different level of work volume. The values are entered on a scatter diagram. The relationship of the data points indicates a strong positive correlation. The more the volume of work, higher the errors. Figure # 12: Scatter diagram

7. Control Chart
111

MUDASIR

The control chart is means of monitoring a process according to tolerance limits. The control chart is the fundamental tool of statistical process control, as it indicates the range of variability that is built into a system (known as common cause variation). The chart allows you to track the normal variations that indicate if a process is in control and to determine when it goes out of control. This chart is used for any process with frequent and measurable outcomes. Thus, a control chart helps you to determine whether or not a process is operating consistently or if a special cause has occurred to change the process variance. The use of statistical methods in a systematic manner to identify root causes of problem. To use control chart, take a random sample of outcomes and use statistical techniques to determine upper and lower control limits. These are not the same as specification tolerances. Rather, they are the values which, if the outcomes exceed them, indicate that the outcomes are not the result of random variation, but of some specific cause. Once the control limits have been determined, plot the outcomes over time or occurrence. If the data points fall outside these bounds, it represents variations due to special causes, which can typically be found and eliminated. If all the values are within the limits, then the process is under control. Example: An engineering company producing hardware components wants to control its shipping in order to have minimum inventory at its works using control chart.

Figure #13: Control Charts

112

MUDASIR

Time is measured on the horizontal axis, which usually corresponds to the average value of the quality characteristic being measured. Two other horizontal lines represent the upper and lower control limits. These are chosen so that there is a high probability that sample values will fall within these limits if the process is under control or affected only by common causes of variation. If points fall outside the control limits or if unusual patterns, such as, shifts up or down, trends up or down, cycles and so forth exist, then there is reason to believe that special causes might be present. Controlling Risk Risk control is a process of performing the risk management plan while, at the same time, ensuring that the plan is still valid. Risk monitoring control is performed at the concept phase of the project and ends at the closure phase. It should be included in the regular communication process of the project. In particular, risk control is performed prior and during the risk event. It is performed whenever there are changes to the project scope or as scheduled.

113

MUDASIR

Risk control involves: Monitoring the risks throughout the project closely Revisiting the risk list periodically Verifying if the risks still valid or perhaps if a particular risk is no longer important. Uncovering additional risks from new events or change requests Updating the risk plans. The actions defined in the mitigation and contingency plans should be implemented as part of risk control. The Risk Owner is responsible for the implementation of these actions. Before any action is taken to accept, avoid, or mitigate the risk, the cost of the same must be carefully considered. It is likely that documenting your actions, stating why you made certain choices, and describing the results, provide a good record for understanding upcoming risks, risks in future phases, and any risks that might affect the next project. You may choose to accept one or more of the risks, and you may not be able to absorb others. Based on project scenario, you may decide that you can accept additional project expenses, but cannot accommodate schedule delays. Accordingly, you can focus your control efforts onto such risks which have a need tube controlled. After this step, controlling of risks involves the formation of specific strategies for risk control. These strategies can include acceptance of risk, avoidance of risk or mitigation of risk. Even if some of the risks are costly, they need to be accepted or mitigated, based on the status of the project. While
114

MUDASIR

in some cases, risks can be avoided and it can be eliminated entirely. In some cases, project managers may need to change project scope, modify project plans, hire additional resources, or adopt different technical solutions to avoid the risk. Risk mitigation can be adopted when the project seeks to minimize the potential impact of a risk through alternative solutions. Mitigation is a combination of acceptance and avoidance. Plans and schedules can be altered; specific actions can be taken to minimize the chance that a risk will occur. Documenting your actions, stating why you made certain choices, and describing the results, provide a good record for understanding upcoming risks, risks in future phases, and any risks that might affect the next project. Need for Alerts and Flexibility Risk management involves analysis and collation of lot of data related to risks. To be able to effectively use this data during the course of the project, these plans must be have some checkpoints or alert points defined so that appropriate risk control can be planned before the risk occurs. The objective of such alerts should be to help the management take timely actions to avoid/mitigate the risks so that their impact can be reduced on the project. Without appropriate alerts, the risk identification, analysis and plans could be rendered ineffective. These alerts could be built as part of a regular assessment. The various parameters that constitute the alert should be checked to see if the alert is triggered. If the risk data is elaborate, you could also use one of the commonly available automated tools which can trigger the alerts as and when they occur.

115

MUDASIR

Once such alerts are in place, and they start giving the warnings, the organization must be ready to take up the changes, if required, to control and avoid risks. In a world of increasing uncertainties, the ability to accommodate changes plays an important role in project risk management. The need for flexibility applies to many aspects: Capital investments Employees and business partners Organizational structures Project timelines Financial commitments Information systems The formulation and implementation of efficient flexibility strategies have become important aspects of risk management. If a project is ready for changes to manage and control the eventual risks, it can actually avert the impact of risks. For being able to do so, the management must be pre-informed of the likely changes that can happen to handle risks. Crisis Management Crisis management is a new field of management that includes forecasting of potential crises and planning to deal with them, for example, how to recover if your computer system completely fails. Organizations have the time and resources to complete a crisis management plan before they experience a crisis.
116

MUDASIR

Crisis management includes identifying the real nature of a current crisis, intervening to minimize damage and recovering from the crisis. Crisis management also includes identifying the threats and risks to an organization and developing and implementing systems and strategies, which help in managing crises. A good crisis management gives your organization competitive advantage. But protecting your organizations reputation, environment, key business assets, employees and other stakeholders is an ongoing challenge, especially, in such extreme, complex and constantly changing risks. Hence crisis management requires good and effective leadership. To ensure an effective crisis management mechanism leadership support and involvement is absolutely essential. A leader must institutionalize the process of crisis management to anticipate, prepare and mitigate an impending crisis. Crisis Resolution the Ultimate Test Since crises are characterized by that dreaded element called surprise, so a strong emphasis on crisis resolution is part of crisis management. While no plan may manage a crisis but a practical plan and general preparedness for crisis may help in resolving crisis. Carefully designed crisis management plans might have been crafted and number of mock drills might have been conducted to ensure high levels of general preparedness, but that one critical decision which defines the organizational response and gives crisis resolution a specific direction and that

117

MUDASIR

affects the outcome and perception of stakeholders and general public in the big way depends on the values instilled by the leader over the years. A Trigger for Change Anticipating crisis is a part of strategic planning and risk management. Each crisis must be dealt with accurately by project managers, who also must consolidate the lessons learnt and communicate the same to the people for organizational learning and thus drive sense for initiating change in the organization. Figure #14: Trigger for Change

The above figure shows the cycle of identifying crises, managing them, and more importantly extracting learning from the act of managing the crisis and
118

MUDASIR

communicating the learning as a trigger for initiating a change programme to overcome the crisis of the organization and help organization in better performance. Outputs of Risk Monitoring and Control: Outputs of the Risk Monitoring and Control process are produced continuously. In addition, outputs of the process are used to update project and organizational documents for the benefit of future project managers. The outputs of Risk Monitoring and Control are: Corrective action: This includes anything that brings the expected performance back in line with the project plan. Corrective actions consist of two types: contingency plans and workaround plans. A contingency plan is a provision in the Project Management Plan that specifies how a risk will be handled if that risk occurs. The plan may be linked with money or time reserves that can be used to implement the plan. A workaround plan is a response to a negative risk that was passively accepted or not previously identified. Project change requests: Implementing a contingency plan or workaround frequently requires changing the risk responses described in the project management plan. Change requests are completed and submitted to the Integrated Change Control process. All requested changes must are documented, and that approvals at the right management levels are sought and obtained. Preventative Actions: Preventative actions assure the project follows the guidelines of the project management plan.
119

MUDASIR

Updated the risk response plan: Document the risks that occur. Risks that dont occur should also be noted and closed out in the risk response plan. It is important to keep this up-to-date, and it becomes a permanent addition to project records, eventually feeding into lessons learned. Updated Risk register/database: This is a repository for collection, maintenance, and analysis of data. It is used in risk management processes. Maintaining this register is very important for project records. An updated risk register has the outcomes from risk assessments, audits, and risk reviews. In addition it is updated with the resulting outcome of the project risk and risk response. The updated risk register is a key part of the historical record of risk management for the project and will be added to the historical archives. Updated the Organizational Process Assets: Organizational process assets should be documented in light of the risk management processes to be used in future projects. Documents as the probability and impact matrix, risk databases, and lessons-learned information, as well as all of the project files are archived for the benefit of future project managers.

120

MUDASIR

Risk Management Information Systems (RMIS) :

Are typically computerized systems that assist in consolidating property values, claims, policy, and exposure information and provide the tracking and management reporting capabilities to enable you to monitor and control your overall cost of risk. The management of risk data and information is key to the success of any risk management effort regardless of an organization's size or industry sector. Risk management information systems/services (RMIS) are used to support expert advice and cost-effective information management solutions around key processes such as:

Risk identification and assessment Risk control Risk financing

Typically, RMIS facilitates the consolidation of insurance related information, such as claims from multiple sources, property values, policy information, and exposure information, into one system. Often, Risk Management Information Services/Systems (RMIS) applies primarily to casualty claims/loss data systems. Such casualty coverage include Auto Liability, Auto Physical Damage, Workers' Compensation, General Liability and Products Liability.

121

MUDASIR

RMIS products are designed to provide their insured organizations and their brokers with basic policy and claim information via electronic access, and most recently, via the Internet. This information is essential for managing individual claims, identifying trends, marketing an insurance program, loss forecasting, actuarial studies and internal loss data communication within a client organization. They may also provide the tracking and management reporting capabilities to enable one to monitor and control overall cost of risk in an efficient and cost-effective manner. In the context of the acronym RMIS, the word risk pertains to an insured or self-insured organization. This is important because prior to the advent of RMIS, insurance company loss information reporting typically organized loss data around insurance policy numbers. The historical focus on insurance policies detracted from a clear, coherent and consolidated picture of a single customer's loss experience. The advent of RMIS in the 1980s was a breakthrough step in the insurance industry's evolution toward persistent and focused understanding of their end-customer needs. Typically, the best solution for your organization depends on whether it is enhancing an existing RMIS system, ensuring the highest level of data quality, or designing and implementing a new system while maintaining a focus on state-of-the-art technology. Common Types of RMIS Most major insurance companies (carriers), broker/agents, and Third Party Administrators (TPAs)offer/provide at least one external RMIS product to their insureds (clients) and any brokers involved in the insurance program. Most
122

MUDASIR

commonly, RMIS products allow individual claim detail look-up, basic trend report production, policy summaries and ad hoc queries. The resulting information can then be shared throughout the client's organization, usually for insurance program cost allocation, loss prevention and effective claim management at the local level. More advanced products allow multiple claim data sources to be consolidated into one Master RMIS, which is essential for most large client organizations with complex insurance programs. The primary users of RMIS are risk/insurance departments of insured organizations and any insurance broker involved. Interestingly, it is much less common for the insured's safety department and vehicle operations department to have access to RMIS despite similar interest in the data. In fact, safety and vehicle operations of larger organizations typically maintain their own separate database systems of accidents/incidents, many of which will correlate to RMIS claim data. Insurance companies normally use a different version of externally provided RMIS for internal use, such as by underwriting and loss control personnel. Occasionally, there could be timing or other differences that could cause data discrepancies between the internal system and externally provided RMIS. Insurance brokers have a similar need for access to their insured client's claim data. Brokers are normally added as an additional user to the RMIS product provided to their clients by the insurance carrier and TPAs. The information available from RMIS is critical to the broker for interfacing effectively with their counterparts in the insurance carrier and TPAs. Additionally, effectively

123

MUDASIR

presented RMIS information that shows trends and analysis is essential to successfully marketing their clients' insurance programs. Insurance carrier and Third-Party Administer (TPA) claim adjusters traditionally use claims management systems to collect and manage claim information and to administer claims. Some client organizations, however, may choose to manage certain types of claims or those within a loss retention layer and thus use this type of system as well. Typically, the claims management system provides the primary data to RMIS products. RMIS products in turn provide an externally accessed view into the client's claims data. RMIS products are commonly available directly from larger insurance carriers and TPAs, but the most advanced systems are often offered by independent RMIS vendors. Independent RMIS vendor systems are most desirable when a client organization needs to consolidate claims data from multiple current insurance programs and/or past programs with current program information. Key Vendor Attributes and Differences Along with insurance carriers, broker/agents and TPAs that offer their own proprietary systems, there are a variety of direct RMIS technology companies who sell to direct insureds and even the carriers, broker/agents and TPAs themselves. Major differences among RMIS vendors include:

Currency of technology (Internet-based vs. Internet-accessible);

124

MUDASIR

System speed (response time for screen changes, report generation time, etc.); Flexibility in meeting client requirements (custom screen views, clientdefined data fields, special reports, etc.); Ongoing support service quality (availability of senior/quality technical support, help desk availability, dedicated staff and stability, etc.); Data quality control (data conversion accuracy, data source cleanup, etc.); Pricing (first-year cost, ongoing cost, custom programming charges, data record storage fees); Availability of related modules (property exposure management, policy management, claim/incident setup, Occupational Safety and Health Administration (OSHA) record keeping, claims audits, etc.); Turnaround time for data loads; Foreign conversion/support (financial fields, language, fluent support staff, etc.)

RMIS system compatibility varies among carriers, broker/agents and TPAs. However, quality independent RMIS vendors by design can take almost any claim data source and convert or map the data to their particular system's file structure. A few major insurance carriers offer similar consolidation services, i.e., combining the insured client's current claim data with another carrier's or TPA's data for the same insured client. The other data sources can be for current separate insurance programs or from expired insurance programs. Usually, this type of consolidation service is performed to accommodate their major policyholder organizations. Major TPAs, however, more commonly offer such data consolidation services.
125

MUDASIR

Average RMIS Costs and RMIS Market Drivers: The cost of a typical independent RMIS product varies from $60,000 to $150,000 for the first year, and ongoing annual charges are slightly less. Insurance company RMIS product lines typically average around $50,000 for the first user, but they often offer less expensive light-weight versions for claim look-up only. More costly full-featured products are sometimes available with more advanced reporting systems. The products are usually priced on a per-user basis on a sliding scale for a larger number of users. Insured clients' brokers are given access at no cost or occasionally for a flat annual fee for multiple insured clients with a particular broker. TPAs commonly include one or two RMIS access IDs within their claims management pricing to encourage both the client's broker and the client to use their claim look-up product. Normally, beyond the first two access IDs, the pricing follows the same per-user range of the insurance companies. The cost drivers of RMIS include: Number of user/access IDs Number of outside claim data sources that must be converted (carriers and TPAs do not have to convert their own data) Frequency of outside claim data updates Special programming/report development charges Training of users (initial and annual users' conferences) Clearly, higher cost systems do not always correlate to better performance in terms of both usefulness and speed. While most carrier and TPA RMIS systems are similarly priced, the independent RMIS vendors' price range varies significantly, as previously mentioned.

126

MUDASIR

Opportunity management: The SEI has been conducting research and development in various aspects of risk management for nearly 20 years. The Continuous Risk Management (CRM) approach to managing project risk is still in use todayalmost 15 years after it was released. But the work at the SEI hasn't stopped because, despite the plethora of risk management approaches, methods, tools, and techniques, programs continue to fail from risks that turn into preventable catastrophes.

Figure # 15: Integrated Risk and Opportunity Management

From Continuous Risk Management to Mosaic The tactical, bottom-up approaches to analyzing numerous risk statements have, in today's complex, distributed programs and environments, led to partial views of the "big picture" and inefficient allocation of scarce resources. Many risk management processes have turned into time and resource-intensive bureaucratic nightmares that, in the end, do not provide the right information. The SEI recognized that something else clearly was needed to return risk
127

MUDASIR

management to its original purposesupporting effective management decisions that lead to program success. Current SEI research is focused on systemic risk managementtop-down, system-oriented analyses of risk in relation to program objectiveswhich is better suited to managing risk in distributed environments. This research has brought about the development of a suite of methodsMosaicthat can be used to manage risk and opportunity across the life cycle and supply chain, enabling decision makers to more efficiently engage in the risk management process, navigating through a broad tradeoff space (including performance, reliability, safety, and security considerations, among others) and strategically allocating their limited resources when and where they are needed the most. We have found systemic approaches to be better suited for managing risk and opportunity in distributed environments. In contrast to the bottom-up analyses employed in tactical risk management, systemic approaches incorporate topdown, system-oriented analyses of risk in relation to program objectives.

128

MUDASIR

Conclusion:

To summarize, I think that although many of the risks that initially faced the system have now been resolved, some risks still exist. However, with the contingency plans (particularly the standalone system) that we have put into action, we feel that these risks can be minimized. We feel that risk management is a useful technique and it would have been useful to have learnt more about it nearer to the beginning of the project rather than at this late stage. Still, I feel that even now it can be useful and we will try to use it to good effect in the remaining modules of the project. A risk management process does not have to be complicated or time consuming to be effective. By following a simple, tested, and proven approach that involves seven steps taken at the beginning of each project (fewer if a generic list of project risks has already been established), the project team can prepare itself for whatever may occur. Of course there will always be changes and there may still be surprises, but the end result is that they are fewer, that the team feels prepared and that the project is not taken off course.

129

MUDASIR

Glossary BP Biotic Prediction project RMP Risk Management Plan SEP Software Engineering / Development Plan TBD To Be Determined or To Be Developed

130

MUDASIR

REFERENCES 1. Hubbard, Douglas (2009). The Failure of Risk Management: Why It's Broken and How to Fix It. John Wiley & Sons. p. 46. 2. ISO/IEC Guide 73:2009 (2009). Risk management Vocabulary. International Organization for Standardization. http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics. htm?csnumber=44651. 3. ISO/DIS 31000 (2009). Risk management Principles and guidelines on implementation. International Organization for Standardization. http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?c snumber=43170. 4. "Committee Draft of ISO 31000 Risk management" (PDF). International Organization for Standardization. http://www.nsai.ie/uploads/file/N047_Committee_Draft_of_ISO_31000.p df. 5. CMU/SEI-93-TR-6 Taxonomy-based risk identification in software industry 6. Common Vulnerability and Exposures list 7. Crockford, Neil (1986). An Introduction to Risk Management (2 ed.). Cambridge, UK: Woodhead-Faulkner. p. 18. ISBN 0859413322. 8. Disaster Recovery Journal 9. Dorfman, Mark S. (2007). Introduction to Risk Management and Insurance (9 ed.). Englewood Cliffs, N.J: Prentice Hall. ISBN 0-13224227-3. 10.IADC HSE Case Guidelines for MODUs 3.2, section 4.7
131

MUDASIR

11.Roehrig, P (2006). "Bet On Governance To Manage Outsourcing Risk". Business Trends Quarterly. http://www.btquarterly.com/?mc=betgovernance&page=ss-viewresearch. 12.http://www.bowtiexp.com.au/bowtiexp.asp#aboutBowTies 13.Covello, Vincent T.; Allen., Frederick H. (April 1988). Seven Cardinal Rules of Risk Communication. Washington, DC: U.S. Environmental Protection Agency. OPA-87-020.

132

MUDASIR