Project Risk Management

11 Key excerpts on "Project Risk Management"

• 

  eBook - ePub

  Managing Risks in Projects

  • K.A. Artto, K. Kahkonen(Authors)
  • 2013(Publication Date)
  • Spon Press

    (Publisher)

  2. Project Risk Management - definitions and tools

  There are several project management standards that provide a definition of Project Risk Management. The Project Risk Management content defined according to Project Management Institute’s (PMI) definition is shown in Fig. 1 [1]. Risk management content is also reported in recent documentation for the project management quality guideline ISO [2] that recognize following risk related processes:

  •  risk identification •  risk estimation •  risk response development •  risk control

  Fig. 1. Risk management overview (according to [1])

  The ISO [2] definition about risk management content above is similar to that of PMI’s, and in general, risk management literature defines risk management in similar manner. In some contexts, the terms risk analysis or risk appraisal are used to refer to the first stages of identification and estimation and quantification.

  In project companies, there are risk response sheets in use as empirical tools that are designed to guide identification, estimating, and risk response planning. The structure of those sheets in use usually is consistent with the standards (cf. [1] and [2] referred to above). A hypothetical and simplified presentation of a risk management sheet visualising a tool used in several Finnish project companies is depicted in Fig. 2 .

  Fig. 2. A risk management sheet as a visualisation about empirical tools in use

  3. Historical perspective - risk management of the 80’s

  3.1. Quantitative and risk analysis oriented risk management in the 80’s

  In the beginning of the 80’s, Project Risk Management was a well recognized area in project management literature. The content consisting of risk identification, estimation, risk response development and risk control was generally known. In the discussion of risk management at that time, quantitative risk analysis was emphasized. For example, the stochastic three point estimate features of the PERT methodology vere widely referred to. The PERT methodology with a probabilistic interpretation of optimistic, pessimistic and most probable value estimates has its origin in developing the PERT methodology in the 50’s.

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  COSO Enterprise Risk Management

  Establishing Effective Governance, Risk, and Compliance Processes

  • Robert R. Moeller(Author)
  • 2011(Publication Date)
  • Wiley

    (Publisher)

  Essentially every project effort, whether IT, production, financial, or any of many other areas will have some degree of risk-related potential issues in each of these areas. The responsible project manager needs to understand the interactions and any risks associated with each of these areas. Exhibit 14.6 Integrating Project Risk with Other Management Functions This concept of project risk and the values to be gained from a project over the various phases of the project's development life are important. The overall ERM framework has been described as a continuous but changing and ever-adapting process in the overall enterprise. The enterprise will manage a given risk situation, may adapt its processes to work with risks in a subsequent period, and will go on and on in that manner. A project is a fixed duration endeavor that will go through a series of fairly consistent phases until the termination of the project and, hopefully, the delivery or completion of the planned project outputs. With this limited time period duration, Project Risk Management is even more important. Exhibit 14.7 shows this level of risk over the life of a project. Any project will go through a series of initial planning and development steps and then will move to development and implementation phases. As Exhibit 14.7 shows, some of the highest project risks will be in the earliest phases of the project life cycle where developers face the risks of making some initial planning blunders regarding the project. However, as a project moves from planning and development to implementation, its costs and time constraints will increase. Thus, an individual project effort will face its highest risk during the implementation phase when many risks are still in place but have been covered and costs are increasing

  Sign up to read

  Learn more about book
• 

  eBook - PDF

  Project Risk Management Guidelines

  Managing Risk in Large Projects and Complex Procurements

  • Dale Cooper, Stephen Grey, Geoffrey Raymond, Phil Walker(Authors)
  • 2005(Publication Date)
  • Wiley

    (Publisher)

  Good Project Risk Management within an organization has the following characteristics: • Project Risk Management activities commence at the initiation of the project, risk man- agement plans are developed and risk management continues throughout the project life cycle; • Project Risk Management is not a discrete stand-alone process, but is integrated with other project management functions; and • the implementation of Project Risk Management is the responsibility of all project stake- holders and they participate actively in the process. This chapter provides a brief summary of the material that is developed in the following chapters. Approach The objective of risk management is to identify and manage significant risks. It involves several key phases, with feedback through a monitoring and review process. In most projects, risk management overlaps with other management processes and procedures, in that many of the steps are undertaken as part of normal project manage- ment. This provides the basis for integrating risk management and project management activities. The approach to Project Risk Management adopted in this book is consistent with the Australian and New Zealand Standard on risk management, AS/NZS 4360 (Figure 1.1). This approach is consistent with similar approaches adopted by the major project management professional bodies and government agencies that have issued project risk guidelines. The steps in the process address important questions for the project manager (Table 1.1). Extensions to quantitative risk analysis are discussed in Chapters 19 to 23. The Project Risk Management approach 15 Establish the context Establishing the context is concerned with developing a structure for the risk identification and assessment tasks to follow.

  Sign up to read

  Learn more about book
• 

  eBook - PDF

  Empowering Project Teams

  Using Project Followership to Improve Performance

  • Marco Sampietro, Tiziano Villa(Authors)
  • 2014(Publication Date)
  • Auerbach Publications

    (Publisher)

  165 8 Project Risk Management KEYWORDS Acceptance Contingency plan Impact Investigate Mitigation Observe Opportunity Probability Remove Risk Risk analysis Risk identification Risk management Risk owner Risk response Transfer Uncertainty READER’S GUIDE This chapter is for people who • Have noted that many of a project’s negative occurrences could have been managed in advance and even resolved if only someone had thought about it beforehand 166 • Empowering Project Teams • Have noticed that a project is in a continuous state of emergency • Have unfortunately found that the occurrence of continuous emergen-cies has negative impacts on people as well as the project performance 8.1 WHY PROJECT RISK SHOULD BE MANAGED Risk and projects are in an inescapable combination. Projects are under-taken by organizations so they can seize market opportunities or improve the company’s internal efficiency. Projects, as we have stressed several times, are complex and innovative activities. Innovation brings a cer-tain level of uncertainty, or rather, imperfect knowledge of events that will occur during the project. Each project is therefore physiologically risky. It becomes pathologically risky if the uncertainty linked to it is not addressed and managed methodically and with conviction. A project risk is defined as “an uncertainty that matters” (Hillson 2009). “Uncertainty” insofar as it refers to a potential event, “that matters” insofar as the occurrence of the event affects the project. The risk is such if it affects the project objective. “It could rain tomorrow” is without doubt an uncertainty. It becomes a risk to the extent to which it prevents the project objective being achieved, for example, an open-air theatrical per-formance. It does not represent a risk if our objective is to stay comfortably at home and read a book.

  Sign up to read

  Learn more about book
• 

  eBook - PDF

  Information Technology Project Management

  • Kathy Schwalbe, , , (Authors)
  • 2018(Publication Date)
  • Cengage Learning EMEA

    (Publisher)

  L E A R N I N G O B J E C T I V E S After reading this chapter, you will be able to: • Explain the concept of risk as it relates to project management, and list the advantages of managing project risks according to best practices • Discuss the elements of planning risk management and the contents of a risk management plan • List common sources of risks on information technology (IT) projects • Describe the process of identifying risks and create a risk register and risk report • Discuss qualitative risk analysis and explain how to calculate risk factors, create probability/impact matrixes, and apply the Top Ten Risk Item Tracking technique to rank risks • Explain quantitative risk analysis and how to apply decision trees, simulation, and sensitivity analysis to quantify risks • Provide examples of using different risk response planning strategies to address both negative and positive risks • Discuss how to monitor risks • Describe how software can assist in Project Risk Management • Discuss considerations for agile/adaptive environments C H A P T E R 11 Project Risk Management Chapter 11 464 THE IMPORTANCE OF Project Risk Management Project Risk Management is the art and science of identifying, analyzing, and responding to risk throughout the life of a project and in the best interests of meeting project objectives. A frequently overlooked aspect of project management, risk management can often result in significant improvements in the ultimate success of projects. Risk management can have a positive impact on selecting projects, determining their scope, and developing realistic schedules and cost estimates. It helps project stakeholders understand the nature of the project, involves team members in defining strengths and weaknesses, and helps to integrate the other project management knowledge areas. Good Project Risk Management often goes unnoticed, unlike crisis management, which indicates an obvious danger to the success of a project.

  Sign up to read

  Learn more about book
• 

  eBook - PDF

  Leading IT Projects

  The IT Manager's Guide

  • Jessica Keyes(Author)
  • 2008(Publication Date)
  • Auerbach Publications

    (Publisher)

  Conversely, as the project moves into the later phases, the consequences become much more serious. This is attributed to the fact that as time passes, there is less flexibility in dealing with problems, significant resources have likely been already spent, and more resources may be needed to resolve the problem. Risk Management The first thing that needs to be done is identify risks. One method is to create a risk-item checklist. A typical project plan might list the following risks: Risk Analysis Risk Assessment Risk Identification Content Analysis Communication Risk Monitoring and Review Risk Treatment Risk Evaluation Risk Management Figure 9.1 Risk management feedback loop. Project Risk n 127 1. Customer will change or modify requirements. 2. End users will lack sophistication. 3. Delivery deadline will be tightened. 4. End users will resist the system. 5. Server may not be able to handle larger number of users simultaneously. 6. Technology will not meet expectations. 7. Number of users will be greater than the planned number. 8. End users will lack training. 9. Project team will be inexperienced. 10. System (security and firewall) will be hacked. Keil (1998) developed a framework for identifying software project risks by interviewing experi-enced software project managers (PMs) in different parts of the world. The following questions are ordered by their relative importance to the ultimate success of a project: 1. Have top software and customer managers formally committed to support the project? 2. Are end users enthusiastically committed to the project and the system or product to be built? 3. Are requirements fully understood by the software engineering team and their customers? 4. Have customers been fully involved in the definition of requirements? 5. Do end users have realistic expectations? 6. Is the project scope stable? 7. Does the software engineering team have the right mix of skills? 8.

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  Managing and Leading Software Projects

  • Richard E. Fairley(Author)
  • 2011(Publication Date)
  • Wiley-IEEE Computer Society Pr

    (Publisher)

  Appendix 9B to this chapter and in [Fairley05].

  Additional terms used in this chapter and throughout this text are defined in the Glossary at the end of the text. Presentation slides for this chapter and other supporting material are available at the URL listed in the Preface.

  9.3 AN OVERVIEW OF RISK MANAGEMENT FOR SOFTWARE PROJECTS

  Software projects are inherently risky endeavors because achieving a successful outcome (i.e., delivering an acceptable product on time and within budget) involves establishing and maintaining a balance among many technical, organizational, social, and political constraints, any or all of which may change as a project evolves. Each potential problem for a software project is called a risk factor because it represents a threat to a successful outcome. Table 9.2 lists some commonly occurring kinds of risk factors for software projects.

  The risk of inadequate calendar time may result from:

  • committing to a bad estimate,
  • customer or management compression of a schedule without a corresponding adjustment to resources and/or requirements,
  • addition of requirements without corresponding adjustments to schedule and resources, or
  • reduction in planned resources without corresponding adjustments.

  The risk of insufficient funds to conduct a project may involve lack of enough money in the budget to carry out all of the necessary work activities (perhaps caused by a bad estimate or by agreeing to a “mandated” budget), or it may involve not receiving the money in a timely manner. In the latter case, for example, the customer who is paying for a project may delay incremental payment of funds or your management may defer allocation of needed funds until next fiscal quarter or fiscal year.

  Lack of adequate requirements management can create may different kinds of potential and real problems. As indicated in Table 9.2

  Sign up to read

  Learn more about book
• 

  eBook - PDF

  Software Project Management

  A Process-Driven Approach

  • Ashfaque Ahmed(Author)
  • 2016(Publication Date)
  • Auerbach Publications

    (Publisher)

  61 Chapter 4 Risk Management In.the.previous.chapter,.we.learned ◾ How is an effort estimate for a project made? ◾ What are the different effort estimation techniques? ◾ How is a cost estimate for a project made? ◾ What are the different cost estimation techniques? ◾ How can a schedule estimate for a project be done? ◾ How can a resource estimate for a project be done? In.this.chapter,.we.will.learn ◾ What is a risk on a project? ◾ What kinds of risks exist for a project? ◾ What kind of impact may risks have on a project? ◾ What strategy is needed to deal with risks? 4.1 Introduction Risks are unforeseen or unplanned happenings, which, when they occur, devastate or at least adversely affect our future plans. When we analyze any software project, what kinds of risk come to our mind? Basically, a project has these components: budget, time, resources, quality, and technology. If any risk occurs that might affect any of these components, then the project may fail. What is the best way to reduce or mitigate the risks? There could be many aspects to any project. But a project manager must develop a comprehensive risk mitigation plan so that if any risk arises 62 ◾ Software Project Management: A Process-Driven Approach during execution, he will be able to handle it comfortably. If he has not made a proper risk plan, then if anything wrong happens, he will not be able to handle it (Figure 4.1). Risks can be categorized as external and internal. If a risk to the project arises due to an aspect being dealt with by the project team, then it is an internal risk. All other risks are external risks. Suppose a project is to be coded using a particular programming language, and one developer on the team is not conversant with it. In this case, he is given training so that he can pick up this language.

  Sign up to read

  Learn more about book
• 

  eBook - PDF

  The Making of an Expert Engineer

  • James Trevelyan(Author)
  • 2014(Publication Date)
  • CRC Press

    (Publisher)

  Others might be reputational risks, such as a high-profile employee being involved in court action related to allegations of misbehaviour. Still others might be technical risks: the possibility that a particular solution will not provide the performance that has been predicted. Risk management is a formal method in which engineers system-atically examine all of the potential risks and opportunities, deciding on appropriate planning to maximise the opportunity to take advantage of ‘upside’ risks and to limit the undesirable consequences of ‘downside’ risks. Now, let’s look at some fundamental ideas behind the management of uncertainty in engineering. Practice concept 56: Reliable performance requires a high level of predictability Student engineers often think that . . . Expert engineers know that . . . 50% is okay to pass and 70% is a 99.99% predictability is required distinction. Getting it 100% right (or more) for reliable performance. is for nerds. This almost seems trivial. However, the grading system that governs your behaviour as a student means that you rarely get the chance to learn how to perform engineering technical work to an extremely high level of predictability and reliability. You need to remember that engineers work under similar time pressure as you did when you were a student. There is simply never enough time to do everything. How, then, does an expert engineer manage to achieve such a high level of reliability in technical work performed by people who are no more predictable in their professional working life than they were as students? As unbelievable as that might sound, you can also learn how to achieve this. Practice concept 57: Uncertainty in engineering mostly arises from unpredictable human behaviour Novice engineers often think that . . . Expert engineers know that . . . Uncertainty is a probability, most Uncertainty is mostly due to unpredictable often following a statistical differences in human interpretation, normal distribution.

  Sign up to read

  Learn more about book
• 

  eBook - PDF

  Project Management

  A Systems Approach to Planning, Scheduling, and Controlling

  • Harold Kerzner(Author)
  • 2022(Publication Date)
  • Wiley

    (Publisher)

  The time and cost associated with the identification, analysis, and han-dling of technical risk dependencies could severely tax the project financially. As companies become successful in project management, risk management evolves into a structured process that is performed continuously throughout the life cycle of the project. The four most common factors supporting the need for continuous risk manage-ment are how long the project lasts, how much money is at stake, the degree of developmen-tal maturity, and the interdependencies between the different risks. For example, consider Boeing’s aircraft projects where designing and delivering a new plane might require 10 years and a financial investment of more than $5 billion. Table 17–8 shows the characteristics of risks at Boeing. The table does not mean to imply that risks are mutually exclusive of one another. New technologies can appease cus-tomers, but production risks increase because the learning curve is lengthened with new technology compared to accepted technology. The learning curve can be lengthened fur-ther when features are custom-designed for individual customers. In addition, the loss of suppliers over the life of a plane can affect the level of technical and production risk. The relationships among these risks require the use of a risk management matrix and continu-ous risk assessment. TABLE 17–7. RISK INTERDEPENDENCIES Action Possible Benefit Risk • Work overtime • Add resources • Parallel work • Reduce scope • Hire low-cost resources • Outsource critical work • Schedule compression • Schedule compression • Schedule compression • Schedule compression and lower cost • Lower cost • Lower cost and schedule compression • More mistakes; higher cost and longer schedule • Higher cost and learning curve shift • Rework and higher costs • Unhappy customer and no follow-on work • More mistakes and longer time period • Contractor possesses critical knowledge at your expense

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  Introduction to IT Project Management

  • Cynthia Snyder PMP, Frank Parth PMP(Authors)
  • 2006(Publication Date)
  • Berrett-Koehler Publishers

    (Publisher)

  •  IT projects have five overall sources of risk: team members, technology, project management, the organization, and external factors. Team member risks include skills and availability. Technical risks are comprised of technology, approach, and the technical environment. Project management risks include scope, schedule, budget, and the project management aspects of the project. Organizational risks are made up of the structure and culture of the organization. External risks are those risks that are outside of the control of the project manager, including risks external to the project and the organization.

  •  To identify risks, the project manager should review project documentation, conduct interviews, use checklists, and/or create a risk breakdown structure (RBS). An RBS is a source-oriented grouping of project risks that organizes and defines the total risk exposure of the project. It allows the team to identify risks in a structured fashion.

  •  To complete the process of risk identification, the project manager should create risk statements and enter them into a risk register.

  •  Analyzing project risks entails estimating the probability that a risk will occur and the impact if it does occur. A matrix of high, medium, and low probability and impact is used to analyze risks. A risk event can impact on the scope/performance/quality, the schedule, the budget, and stakeholder satisfaction.

  •  Tools for risk analysis include a preliminary risk analysis that considers the size, technology, and project management structure; a probability-impact matrix; and a project risk-profile form. •  Risk responses include avoiding the risk, mitigating the risk, transferring the risk, and accepting the risk.

  •  Contingency plans are put in place to deal with the risk if it occurs. Risk triggers alert the project manager that a risk has occurred or is about to occur. Secondary risks are risks that are the result of a risk response strategy. Residual risks are those risks that are left after the risk response is developed. Sometimes schedule or budget reserve can be used to reduce risk to the project. A fallback plan is used if the risk response does not work and the risk occurs.

  Sign up to read

  Learn more about book