Dynamics of Project Risk Management Lec-1 Overview of Project Risk Management

2. Dynamics of Project Risk ManagementLec-1Overview of Project Risk Management Dynamics of Project Risk Management Lec-03 PROJECT RISK IDENTIFICATION By: Engr.Dr.Attaullah Shah PhD ( Civil) Engg , Mphil (Eco),MScEngg ( Strs), BScEngg ( Gold Medalist), MBA, MA ( Eco), MScEnvir Design, PGD Computer Sc. Tel: 051-9250100 E-mail: pdaiou@yahoo.com.

3. Project Risk Management Process and questions for project managers

4. Identifying Risks in Software projectsA-Case study ( Paper from Communication of ACM Vol41-1998) • In 1995, annual U.S. spending on software projects reached approximately $250 billion and encompassed an estimated 175,000 projects • In 1995, U.S companies alone spent an estimated $59 billion in cost overruns on IS projects and another $81 billion on canceled software projects • No systematic attempts have been made to identify software project risks by tapping the opinions of those who actually have experience in managing such projects. • Software project risk has been defined as the product of uncertainty associated with project risk factors and the magnitude of potential loss due to project failure

5. Three questions about risk factors stand in the way of developing a more disciplined approach to software project risk management: 1. What are the typical risk factors software project managers face? • 2. Which risk factors do software project managers consider more deserving of their attention? • 3. Which countermeasures are the most effective in mitigating risk, given a particular set of risk factors? • One popular method for identifying risk factors, therefore, has been the use of checklists. With a risk factor checklist, project managers can avoid overlooking some risk factors. • Design of the Study and Research Method • THE AIM OF THIS STUDY IS TO DEVELOP an authoritative list of risk factors, and to determine which of those risk factors are most important. • An obvious source for such information is an expert in the field with years of experience in managing software development projects • A ranking-type Delphi survey [36], designed to elicit the opinion of a panel of experts through iterative controlled feedback, was chosen as the research method for this study

6. Composition of the Panels: • To achieve variation in respondents' background and cultural settings. Hong Kong (HKG). Finland (FIN), and the United States (USA) were chosen as the target populations from which the panelists were drawn. • Data Collection and Analysis Method • Delphi survey process is divided into three phases, as shown in Figure I. In the first phase, a brain-storming round is conducted to elicit as many items as possible from the panels. • All panels participate cooperatively in the first phase to ensure that they are all working from a common list of items with common definitions. Each panelist was asked to submit at least six factors, and to provide short descriptions of the factors, to aid the researchers in their collation effort • Then the two independently constructed lists were compared and reconciled by all authors working together. Exact duplicates were removed, and an explanation of the groupings was provided to the panelists. The combined list was circulated to all panelists for corrections, additions, and eventually validation.

7. In the second phase of the study, we separated the panels by country, allowing each panel to independently pare down the list of risk factors. We sought to narrow the list of factors to a manageable number • The panelists were asked to choose (but not to rank) at least ten factors that they considered most deserving of their attention and resources. • The ranking of the selected factors was done in the third phase. Here panels ranked the risk factors in order of priority—that is, the top-ranked factor would he the factor most deserving of the project manager's attention.

11. Risk Identification • Risk cannot be managed unless it is first identified. • Once the context of the business has been defined, the next step is to utilize the information to identify as many risks as possible. • The aim of risk identification is to identify possible risks that may affect, either negatively or positively, the objectives of the business and the activity under analysis. Answering the following questions identifies the risk:

12. Risk Identification Purpose: • Risk identification determines what might happen that could affect the objectives of the project, and how those things might happen.. Rationale: • The risk identification process must be comprehensive, as risks that have not been identified cannot be assessed, and their emergence at a later time may threaten the success of the project and cause unpleasant surprises. The process should be structured using the key elements to examine risks systematically, in each area of the project to be addressed. Inputs: • Information used in the risk identification process may include historical data, theoretical analysis, empirical data and analysis, informed opinions of the project team and other experts, and the concerns of stakeholders.

13. Method: Risk identification techniques may include: - Brainstorming; - Checklists; - Questionnaires circulated to a range of personnel; - Examination of previous similar projects; and - Specialist techniques. • Outputs - The output is a comprehensive list of possible risks to the successful outcome of the project. (Subsequent steps in the process will develop priorities for dealing with them.) • Documentation - Risk description - Risk register

14. Risk Identification • Risk identification is the process of understanding what potential events might hurt or enhance a project • Identifying risks is an iterative process because new risks may evolve or become known as the project progresses through its life cycle • Participants in risk identification activities includes the project manager, project team members, customers, subject matter experts from outside the project team, end users, other project managers, stakeholders, and risk management experts

15. Risk Identification Tools and Techniques • Brainstorming; • Examination of local or overseas experience with similar activities and projects, including analysis of post-project completion reports and audits; • Checklists; • Interviews and focus group discussions; • Scenario analyses and Assumption Analysis • Surveys and questionnaires; and • Work Breakdown Structure analysis.

16. Brainstorming • Brainstorming is a technique by which a group attempts to generate ideas or find a solution for a specific problem by amassing ideas spontaneously and without judgment • An experienced facilitator should run the brainstorming session • Be careful not to overuse or misuse brainstorming • Psychology literature shows that individuals produce a greater number of ideas working alone than they do through brainstorming in small, face-to-face groups • Group effects often inhibit idea generation

17. Brainstorming • Brainstorming allows the identification process to draw on the creative capacity of the participants, reducing the danger of overlooking new and emerging issues, as can happen with checklists. • Brainstorming is a very useful technique for the initial identification of a wide range of risks, particularly for large or unique projects. • It is an interactive, team-based approach, depending for its success on the breadth of experience and skills present in the brainstorming group and the skills of the facilitator. • It usually involves the key members of the project team, together with any specialists who can bring additional necessary expertise to the process. • The aim of the brainstorming session is to cover all potential risks, without making judgments about their importance in the initial stages.

18. When objectives are stated clearly and understood by the participants, a brainstorming session drawing on the creativity of the participants can be used to generate a list of risks. • In the session risks that are known unknowns may emerge, and perhaps even some risks that were previously unknown unknowns may become known • Using a cross-functional team of employees greatly increases the value of the process because it sheds light on how risks and objectives are correlated and how they can impact business units differently. • With the team sharing experiences, coming from different backgrounds, and having different perspectives, brainstorming can be successful in identifying risk. • It is also powerful when used at the executive level or with the audit committee and/or board of directors.

19. Steps involved in structured brainstorming • The element is defined, by someone familiar with it, so that everyone understands what is being considered. • The team spends a few moments thinking about the possible risks and noting them on rough paper. • The member most familiar with the element writes the initial risk list on the white board, without comments from the other participants. • The other participants then make their contributions to the list. Typically, the list may double in size in this step. No judgments should be made up to this point. • The team reviews the list, classifying and grouping similar risks where appropriate, and adding new ones as ideas are generated. The list can then be simplified if necessary. • The aim is usually to generate a list of about ten risks for each item, although this will vary widely depending on the element being considered.

20. Whatever form of brainstorming is adopted, it is imperative that any checklists, or other predetermined views of the risks that might arise, be excluded from consideration until after the brainstorming, or at least that attention should not be drawn to them in advance.

21. Participants of the brainstorming workshops • Must include expertise from a cross section of disciplines and stakeholders that covers all areas of interest in the project. • People who might be included in a brainstorming group are: • The project manager and the project team; • Project sponsors and site representatives; • Discipline engineers; • Experts with specific knowledge in particular areas of concern, where there may be insufficient expertise in the project team; • Commercial specialists; • Health, safety and environmental specialists; • People with experience in similar previous or current projects; • Users of the project outcomes; • Key stakeholders who need to be confident in the project and the project management process before approvals are granted.

22. Checklists • Checklists are quick to use, and they provide useful guides for areas in which the organization has a depth of experience, particularly for projects that are standard or routine in nature. • Examples: • Standard check lists for inviting biddings • Standard design check lists • Standard quality checklist • More suitable for recurring and similar projects executed in the matured projects. • When a project is not the same as anything the organization has dealt with before, then a checklist can provide a constraint on creative thought (How?) • For projects that involve new features, a brainstorming approach is recommended initially, with checklists reserved for stimulating brainstorming sessions, reviewing the identification process and ensuring that no known issues have been left out.

26. The Delphi technique • The Delphi technique is a method by which a consensus of experts can be reached on a subject such as project risk. Project risk experts are identified but participate anonymously. • The Delphi technique helps reduce bias and minimizes the influence of any one person on the outcome. • A facilitator uses a questionnaire to solicit ideas about the important project risks. • The responses are submitted and put into risk categories by the facilitator. • These risks are then circulated to the experts for further comment. • Consensus on the main project risks may be reached after a few rounds of this process.

27. Interviewing • Risks can be identified by interviews with experienced project managers or with experts in the field. • The appropriate individuals are selected and briefed on the project. • The interviewees identify risks on the project based on their experience, the project information, and any other sources that they find useful.

28. SWOT Analysis • Strengths, weaknesses, opportunities and threats (SWOT) analysis • Ensures examination of the project from each of the SWOT perspectives to increase the breadth of the risks considered • A SWOT analysis is a classification of situation analysis that focuses on the strengths, weaknesses, opportunities, and threats inherent in a project. • By examining each of the SWOT analysis perspectives in turn, the project team ensures that the breadth of the risks considered is maximized. • SWOT analysis is a useful technique in project management risk, where it is desirable to reduce the probability and impact of a threat and increase the probability and impact of an opportunity. • SWOT analysis is a useful technique in project management risk, where it is desirable to reduce the probability and impact of a threat and increase the probability and impact of an opportunity.

29. SWOT

30. Assumption Analysis • Underpinning every project is the set of hypotheses, scenarios, or assumptions made initially. Assumptions are any piece of project information that is believed to be true at a point in time but which cannot be validated. • As the project progresses, initial assumptions should be validated and incorporated into the plans. • If an assumption cannot be validated, it may become a risk. As the project progresses, you should reassess the validity of these assumptions. • Assumption analysis is a technique that explores the validity of assumption by identifying risks to the project from inaccuracy, inconsistency, or incompleteness of assumptions. • It is also called sensitivity Analysis

31. Diagramming techniques • Cause-and-effect diagrams useful for identifying causes of risks. • System or process flowcharts—show how various elements of a system interrelate and the mechanism of causation. • Influence diagrams—a graphical representation of a problem showing causal influences, time ordering of events and other relationships among variables and outcomes

32. Machine Method Material Major Defect Energy Personnel Environment

33. Cause-Effect Diagram(Ishikawa) • Usually most effective when done in groups • Start from the right • The "Four-M" categories are typically used as a starting point: "Materials", "Machines", "Manpower", and "Methods”. • The subdivision into ever increasing specificity continues as long as the problem areas can be further subdivided. • The practical maximum depth of this tree is usually about four or five levels. • When the fishbone is complete, one has a rather complete picture of all the possibilities about what could be the root cause for the designated problem.

34. Documenting risks-Risk Registers • The description of the risk should include the main assumptions and mechanisms leading to the risk arising, the criteria likely to be affected, the phases of the project in which it is most likely to occur and notes on the consequences if it does arise. Sources of information should also be noted.

35. Sources of information • Historical records, often for similar or related projects; • Project experience, either specific to the kind of project being assessed or more general experience with large or complex activities or with similar kinds of contractors or suppliers; • Industry best practice and user experience, including relevant benchmarks and standards; • Relevant published literature and research reports, including appropriate theory, for example relating to failure modes or equipment reliability; • product brochures, technical manuals and audit reports; • Test marketing and market research, where there is benefit in seeking or creating new information relating to specific aspects of the project, and particularly its acceptability to its intended end-users or customers;

36. Experiments and prototypes, where there may be technical risks or areas in which more empirical rather than theoretical information may be useful; • Economic or other models, to provide the necessary theoretical foundations for specific and general risk assessments, including traditional cash-flow and sensitivity models where appropriate; • Expert commercial and technical judgment, including that of the project team and appropriate external advisers where necessary.

37. Brainstorming is not a structured meeting • Brainstorming is: • Idea generation • Issue generation • Divergent thinking • Open format • Structured meeting is: • Fixed agenda • Chairperson • Minutes • Action items

38. Risks associated with Highways projects

39. Risks in Supply Chain

40. Assignment:3 • Please visit the research paper Risk Analysis of Infrastructure Projects – A Case Study on “Build Operate and Transfer BOT” Projects in India at http://www.larsentoubro.com/lntcorporate/pmiv/pdf/riskanalysisofinfrastructureprojects.pdf • Explain what sources has been used for identifying the risks and what are these major risks?