Презентация Risk management онлайн

Содержание слайда: Risk Management

Содержание слайда: Where are we? 1. Introduction 2. Project Life Cycles 3. Project Artifacts 4. Work Elements, Schedule, Budget 5. Risk Management Risk Management Plan Optional Inclusions

Содержание слайда: Outline What is Risk? Risk Identification: Threshold of Success Risk Management Plan Monitoring and Mitigation of Risks

Содержание слайда: Outcomes Understand the key parts of the Risk Management Plan Know how to identify the key parts of the Threshold of Success (TOS) for a project. Be able to write a TOS and begin writing Risks that can impact the TOS. Have a clear understanding of what it means to mitigate a Risk.

Содержание слайда: What is Risk? A risk is a potential future harm that may arise from some present action (-> all risks have some probability rate of occurrence)

Содержание слайда: What is Risk? There are a very few projects with no risk Software projects are fraught with cost overrun and schedule delays Risk management is an integral part of software project management

Содержание слайда: What is Risk? Risk is the result of making decisions Every decision has two outputs, a solutions and some risk Risk is neither good or bad it just is, the impact might be good or bad Risk has a probability and an impact “A problem is a risk whose time has come” All Risks should be based on a fact Examples: Good: A condition exists therefore this event might occur… Bad: A condition might exist therefore …

Содержание слайда: Key of Risk Management Risk Identification Risk Prioritization Risk Mitigation Also: Risk Analysis – Take some time to consider risk Risk Monitoring – Have a method to identify the status of risks as they change

Содержание слайда: Key of Risk Management

Содержание слайда: Adult games A team is put together to build some software. Neither the clients nor the team talk about the objectives of the project other than building "some software". After a few months, something goes wrong or someone doesn't like what's happening so someone changes the rules. Before too long, one side or the other is upset that they can't win, somebody throws a fit, and goes home. Instead of summoning invisible armor, software projects change the rules by cutting features, adding more requirements, moving due dates, wasting resources, and things like that.

Содержание слайда: Threshold of Success Defining and committing to a clear picture of success establishes the common ground rules for a project by making the basic project goals explicit. The technique is known as Threshold of Success.

Содержание слайда: Threshold of Success Clearly identifies what the project must minimally do to make the customer satisfied Establishes what are “must have” things versus “nice to have” items for the project Provides a clear view of what must be done and therefore a clear view of what might impact what must be done i.e., The risks of the project.

Содержание слайда: Threshold of Success A good Threshold of Success is made up of about 3-4 SMART goals (no more than a few bullets on a single PowerPoint slide).  SMART is a mnemonic which stands for - Short/Specific Measurable Achievable Relevant Time bound.

Содержание слайда: Threshold of Success Building a Threshold of Success The easiest way to create a Threshold of Success is to first create a minimum picture of failure, then convert failure into success. Example: Failure for my current project might look something like this. Essential features are not ready by the end of the second quarter. Team members are dissatisfied or bored with their jobs. Newly hired team members don't feel like they're part of the team by March 31. There isn't enough money to continue development after this fiscal year and we have to fire people.

Содержание слайда: Threshold of Success The threshold of success for my current project might look something like this. By the end of the second quarter, all "Must Have" features are implemented and pass acceptance tests with no known critical defects. All team members give average score of 5 or better on a job satisfaction survey taken quarterly. By March 31, the team has successfully executed at least three team building activities with all team members present. Funds of at least $1 million are secured by December 31 to allow for future development without a reduction in team size.

Содержание слайда: Threshold of Success ToS statement:s We MUST do X or have shown that our product has met at least Y to reach our ToS.

Содержание слайда: Risk management plan As part of a larger, comprehensive project plan, the risk management plan outlines the response that will be taken for each risk—if it materializes

Содержание слайда: Risk management plan Five main risk impact areas in SD: New, unproven technologies User and functional requirements Application and system architecture Performance Organizational

Содержание слайда: Risk management plan New, unproven technologies. The majority of software projects entail the use of new technologies. Training and knowledge are of critical importance, and the improper use of new technology most often leads directly to project failure.

Содержание слайда: Risk management plan User and functional requirements. Software requirements capture all user needs with respect to the software system features, functions, and quality of service. Change in elemental requirements will likely propagate throughout the entire project, and modifications to user requirements might not translate to functional requirements.

Содержание слайда: Risk management plan Application and system architecture. Taking the wrong direction with a platform, component, or architecture can have disastrous consequences. As with the technological risks, it is vital that the team includes experts who understand the architecture and have the capability to make sound design choices.

Содержание слайда: Risk management plan Performance. It’s important to ensure that any risk management plan encompasses user and partner expectations on performance. Consideration must be given to benchmarks and threshold testing throughout the project to ensure that the work products are moving in the right direction.

Содержание слайда: Risk management plan Organizational. Organizational problems may have adverse effects on project outcomes. Project management must plan for efficient execution of the project, and find a balance between the needs of the development team and the expectations of the customers.

Содержание слайда: Writing Risk Statements

Содержание слайда: Writing Risk Statements

Содержание слайда: Writing Risk Statements

Содержание слайда: Writing Risk Statements

Содержание слайда: Example Lack of executive sponsorship (maybe because of change in the Administration); time delays, frustrations, credibility, and morale, and [a department cosponsoring the project] may pull out of [the project]. The majority of software-to-software interfaces are not defined & controlled; incomplete interfaces results in no benefits from [the project]. There has been inadequate schedule discipline (milestones, slippage, monitor progress, good project management) on this project; with no intervention the project will continue to slip & slide.

Содержание слайда:

Содержание слайда: Risk prioritization Probability Very Improbable Improbable Probable Frequent Impact Negligible Marginal Critical Catastrophic Numerical Value Risk Exposure (RE)= P * C

Содержание слайда:

Содержание слайда: Table of risks

Содержание слайда: Key Ideas for Risk Management:

Содержание слайда: Risk mitigation Risk management includes the following tasks: Identify risks and their triggers Classify and prioritize all risks Craft a plan that links each risk to a mitigation Monitor for risk triggers during the project Implement the mitigating action if any risk materializes Communicate risk status throughout project

Содержание слайда: Risk mitigation

Содержание слайда: Summary: A work team identifying risks needs to agree on an end-point against which to identify and analyze the risks. There needs to be a standard way of capturing (documenting) a risk. Facilitators need practice to become comfortable writing risks in front of a group. There are many ways for program management to support good risk identification: Encourage documentation of risks privately at the working team level Integrate risk identification and management into normal project management Accept any risk identified into the repository – don’t “vet them out” Acknowledge that the program’s decision-makers are the real “risk managers,” and have the decision-makers step up to the job