Risk guideline
3
@Copyright 2008–2012 Russell Pannone All rights reserved Risk Guideline A project, like life, is uncertain. We identify risks not for their own sake, but to anticipate and mitigate them, if possible, or to respond to them when our mitigation strategies fall short. Risk drives the iteration plans; iterations are planned around addressing specific risks, attempting to either bound the risk or reduce it. The risk list is periodically reviewed to evaluate the effectiveness of risk mitigation strategies, which in turn drives revisions to the project plan and subsequent iteration plans. The key to managing risk is not to wait until a risk materializes (and becomes a problem or a failure) to decide what to do about it. Just as a change of a few degrees in the path of a transcontinental flight has a large effect on where the plane lands, managing risk early is nearly always less costly and painful than cleaning-up after the fact. Risk Management Strategies Risk avoidance. Reorganize the project so that it cannot be affected by that risk. Risk transfer. Reorganize the project so that someone or something else bears the risk (customer, vendor, bank, another element, and so on). A specific strategy of risk avoidance. Risk acceptance. Decide to live with the risk as a contingency. Monitor the risk symptoms and decide on a contingency plan of what to do if a risk emerges. Initiate/ Select Conceptualize/ Commit Instantiate/ Actualize Realize/ Deploy
-
Upload
russell-pannone -
Category
Technology
-
view
1.173 -
download
3
description
Pragmatically dealing with agile product (solution-system-software) development risk.
Transcript of Risk guideline
@Copyright 2008–2012 Russell Pannone All rights reserved
Risk Guideline
A project, like life, is uncertain. We identify risks not for their own sake, but to anticipate and
mitigate them, if possible, or to respond to them when our mitigation strategies fall short.
Risk drives the iteration plans; iterations are planned around addressing specific risks, attempting
to either bound the risk or reduce it. The risk list is periodically reviewed to evaluate the
effectiveness of risk mitigation strategies, which in turn drives revisions to the project plan and
subsequent iteration plans.
The key to managing risk is not to wait until a risk materializes (and becomes a problem or a
failure) to decide what to do about it. Just as a change of a few degrees in the path of a
transcontinental flight has a large effect on where the plane lands, managing risk early is nearly
always less costly and painful than cleaning-up after the fact.
Risk Management Strategies
Risk avoidance. Reorganize the project so that it cannot be affected by that risk.
Risk transfer. Reorganize the project so that someone or something else bears the risk
(customer, vendor, bank, another element, and so on). A specific strategy of risk
avoidance.
Risk acceptance. Decide to live with the risk as a contingency. Monitor the risk
symptoms and decide on a contingency plan of what to do if a risk emerges.
Initiate/
Select Conceptualize/
Commit Instantiate/
Actualize
Realize/
Deploy
@Copyright 2008–2012 Russell Pannone All rights reserved
If you decide to accept the risk, you still may want to mitigate the risk, that is, take some
immediate action to reduce its impact.
What is Risk? Risks are future uncertain events with a probability of occurrence and a potential for loss.
Risk identification and management are the main concerns in every software project. Analysis of
risks will result in effective planning and assignments of work and getting the right things done
the right way.
Risks are identified, classified and managed.
Categories of Risks
Schedule Risk
Schedules often slip due to following reasons:
Wrong time estimation
Resources are not tracked properly
Failure to identify complex functionalities and time required to develop those
functionalities
Unexpected project scope expansion
Budget Risk
Wrong budget estimation
Cost overruns
Project scope expansion
Operational Risk
Causes of Operational risks:
Failure to address priority conflicts
Failure to identify and effectively deal with impact on existing business process
o Inadequate training
o Insufficient human resources
@Copyright 2008–2012 Russell Pannone All rights reserved
Technical Risks
Causes of technical risks are:
Continuous changing requirements
No advanced technology available or the existing technology is in initial stages.
Product is complex to implement.
Difficult integration
External Risks
These risks are outside the control of the project or program.
Running out of funding
Market development
Changing customer product strategy and priority
Government rule changes
