Презентация на тему Risk management

Artifacts
4. Work Elements, Schedule, Budget
5. Risk Management
Risk Management Plan

Optional

Inclusions

Plan
Monitoring and Mitigation of Risks

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.

harm that may arise from some present action
(-> all

risks have some probability rate of occurrence)

with no risk
Software projects are fraught with cost overrun

and schedule delays
Risk management is an integral part of software project management

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 …

Analysis – Take some time to consider risk
Risk Monitoring

– Have a method to identify the status of risks as they change

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.

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.

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.

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.

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.

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.

or have shown that our product has met at

least Y to reach our ToS.

the risk management plan outlines the response that will

be taken for each risk—if it materializes

Risk management plan

technologies
User and functional requirements
Application and system architecture
Performance
Organizational

Risk management plan

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

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

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

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

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.

Risk management plan

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.

Example

* C

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

Threshold of Success
Identifying risks
Formulating risk statements
Mitigating, tracking and controlling

risk
Communicating about risk
Trading off resources to manage risk